Вы находитесь на странице: 1из 175

Introduccin

A lo largo de los aos la informacin se ha convertido en una herramienta indispensable en la toma de decisiones, y el hecho de almacenar y administrar esta informacin a tomado mayor importancia da con da. En los aos 70's, cuando las computadoras comenzaron a ser usadas no solo para realizar clculos, sino tambin para almacenar informacin, naci una nueva rea dentro de la informtica, el diseo e implementacin de sistemas de bases de datos. Estas bases de datos en sus inicios funcionaban en una sola

computadora, donde se realizaban todos los procesos de almacenamiento, consulta y actualizacin de la informacin. Con el surgimiento de las redes de rea local el procesamiento de la informacin fue ms fcil y rpido, aun cuando se tenia un nuevo problema, cada vez era mayor el volumen de la informacin que se tenia que almacenar en el nico servidor central. Con el crecimiento econmico mundial, aparecieron las grandes empresas transnacionales, con plantas y oficinas en diferentes ciudades y pases, por tanto, con diferentes redes de rea local en cada una de las reas geogrficas de la empresa. Es as como aparece un nuevo concepto en el rea de las bases de datos, las bases de datos distribuidas. Las bases de datos distribuidas surgen a partir de la necesidad de poder almacenar y administrar informacin en cada rea geogrfica, tener una red de computo en cada una de ellas, y poder compartir dicha informacin de manera transparente a todos y cada uno de los usuarios de las redes, formando a si una gigantesca base de datos distribuida.

Bases de Datos Distribuidas

Objetivo

Este trabajo es realizado con la intencin de proveer al alumno de un documento de consulta basado en el plan de estudio de la materia, lo que permitir un fcil acceso a la informacin requerida de una manera rpida y concisa, logrando as una fcil comprensin de los temas tratados en clase. Esto sin intentar sustituir a los libros existentes de bases de datos centralizadas y bases de datos distribuidas.

Bases de Datos Distribuidas

II

Bases de datos distribuidas Contenido


Capitulo 1 Fundamentos de las bases de datos distribuidas 1.1 Diferencias entre las bases de datos distribuidas y las bases de datos centralizadas ....................................................................... .............1 1.2 Ventajas de las bases de datos distribuidas contra las bases de datos centralizadas................................................................. .............4 1.3 Los doce objetivos de una base de datos distribuidas...........................6 1.4 Arquitectura cliente/servidor.................................................................11 1.4.1 Paradigma cliente/servidor .................................................................11 1.4.2 Procesamiento cliente/servidor...........................................................11 1.4.3 Ventajas de la arquitectura cliente/servidor........................................11 1.4.4 Desventajas de la arquitectura cliente/servidor..................................12 1.4.5 Caractersticas del cliente...................................................................12 1.4.6 Funciones del cliente..........................................................................13 1.4.7 Interfaz grafica de usuario estndar....................................................13 1.4.8 Caractersticas de[ servido.........................r.......................................14 1.4.9 Funciones del servidor ........................................................................15 1.4.10 El sistema X Windows.......................................................................18 1.5 Problemas de los sistemas distribuidos.................................................19 1.6 Soporte para bases de datos distribuidas..............................................23 1.7 Resumen del capitulo.............................................................................24 1.8 Preguntas de repaso..............................................................................31 Bibliografa...................................................................................................32 Capitulo II Bases de datos en mltiples servidores 2.1 Consideraciones para distribuir bases de datos....................................34 2.1.1 Objetivo del diseo de los datos distribuidos .....................................35 2.2 Diseo de bases de datos distribuidas ................................................36 2.2.1 Tcnicas de diseo Top-Down y Bottom-Up de bases de datos distribuidas ................................................................................... 36 2.2.2 Diseo de los fragmentos de la base de datos...................................37

Bases de Datos Distribuidas

III

2.2.3 Correctez de la fragmentacin............................................................37 2.2.4 Fragmentacin Horizontal...................................................................38 2.2.5 Fragmentacin Horizontal derivada....................................................40 2.2.6 Fragmentacin Vertical.......................................................................42 2.2.7 Fragmentacin Mixta..........................................................................46 2.2.8 Distribucin de los fragmentos...........................................................48 2.2.9 Criterios generales para la distribucin de los fragmentos................. 48 2.3 Procesamiento de consultas distribuidas..............................................49 2.3.1 rbol de operadores de una consulta................................................49 2.3.2 Ejemplos de consultas distribuidas....................................................50 2.4. Resumen del capitulo...........................................................................57 2.5. Preguntas de repaso............................................................................60 2.6. Ejercicios..............................................................................................60 Bibliografa..................................................................................................62 Capitulo III Optimizacin de estrategias de acceso 3.1 Importancia de la optimizacin de consultas........................................63 3.2 Transformaciones equivalentes.........................................................65 3.2.1 Transformaciones equivalentes por lgebra relacional...................66 3.2.2 Determinacin de subexpresiones comunes...................................68 3.3 Mtodos de ejecucin de JOIN..........................................................70 3.3.1 Iteracin simple.................................................................................71 3.3.2 Iteracin orientada a bloques...........................................................72 3.3.3 Merge - Join ..................................................................................73 3.3.4 Uso de ndices.................................................................................75 3.3.5 Hash Join ..................................................................................76 3.3.6 Tree - way join..................................................................................78 3.3.7 Estrategias para procesamiento paralelo........................................80 3.3.8 Join paralelo ..................................................................................80 3.3.9 Pipeline multiway join.......................................................................82 3.4. Principios de optmizacin.................................................................84 3.5. Resumen del capitulo.........................................................................88 3.6. Preguntas de repaso..........................................................................93 3.7. Ejercicios............................................................................................94
Bases de Datos Distribuidas

IV

Bibliografa................................................................................................94

CapitulolV Procesamiento de transacciones en bases de datos distribuidas 4.1 Control de concurrencia......................................................................95 4.1.1 Seriabilidad en bases de datos centralizadas..................................95 4.1.2 Seriabilidad en bases de datos distribuidas. ...................................98 4.1.3 Control de concurrencia basado en bloqueos centralizados .........100 4.1.4 Control de concurrencia basado en bloqueos distribuidos ............101 4.1.5 Bloqueo de 2 fases como un mtodo de control de concurrencia...................................................................................104 4.1.6 Etiquetas de tiempo en una base de datos distribuida...................106 4.1.7 Deadloks distribuidos.....................................................................109 4.2 Recuperacin.....................................................................................111 4.2.1 Transacciones................................................................................112 4.2.2 Manejo de mensajes......................................................................113 4.2.3 estructura general de los registros de bitcora..............................114 4.2.4 Tipos de fallas.................................................................................116 4.2-5 Fallas de transaccin......................................................................117 4.2.6 Bitcora en lnea.............................................................................118 4.2.7 Transacciones grandes..................................................................118 4.2.8 Compresin de bitcora.................................................................119 4.2.9 Fallas del sistema...........................................................................120 4.2.10 Fallas en el medio de almacenamiento........................................123 4.3 Integridad ..........................................................................................125 4.3.1 Reglas de integridad de dominio................................................. . .126 4.3.2 Reglas de integridad de relacin....................................................127 4.4 Seguridad. .......................................................................................131 4.4.1 Identificacin y autentificacin..................................................... . .133 4.4.2 Reglas de autorizacin...................................................................133 4.4.3 Encriptacin de datos. ................................................................ . .134 4.4.4 Encriptacin por sustitucin,........................................................ . .135 4.4.5 Encriptacin de llave publica....................................................... . .136 4.5. Resumen del capitulo.......................................................................139 4.6. Preguntas de repaso........................................................................151 4.7. Ejercicios..........................................................................................152 Bibliografa..............................................................................................153
Bases de Datos Distribuidas

Respuestas a preguntas de repaso y ejercicios.....................................154

Bases de Datos Distribuidas

VI

Fundamentos de las Bases de Datos Distribuidas

Captulo I

Fundamentos de las bases de datos distribuidas


Objetivo
El alumno conocer las caractersticas de las bases de datos distribuidas, el paradigma cliente / servidor, y los aspectos que se deben considerar al disear una base de datos distribuida.

Introduccin
En este captulo se tratan las diferencias entre las bases de datos centralizadas y distribuidas, las cuales proporcionan ventajas y desventajas que debern ser tomadas en cuenta al disear bases de datos distribuidas, as mismo, se tratan los objetivos a cumplir por dichas bases de datos. Se discutir tambin, una pequea descripcin del paradigma cliente / servidor, ya que las bases de datos no centralizadas hacen un uso extenso de ste.

1.1 Diferencias entre las bases de datos distribuidas y las bases de datos centralizadas
Las bases de datos distribuidas no son simples implementaciones distribuidas de bases de datos centralizadas, aun cuando presentan algunas caractersticas semejantes, los sistemas distribuidos no podran ser diseados con las tcnicas de diseo de los sistemas centralizados tradicionales. Sin embargo es posible comparar los sistemas tradicionales de bases de datos con los sistemas de bases de datos distribuidas en base a dichas caractersticas, las cuales son: control centralizado, independencia de datos, reduccin de redundancia, estructuras fsicas complejas para un acceso eficiente y seguridad.

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Control centralizado La posibilidad de proveer control centralizado sobre los recursos de informacin puede ser considerada como una de las razones ms atractivas para introducir bases de datos; esto es considerado como la evolucin de los sistemas de informacin, en los cuales cada aplicacin tiene sus archivos privados. En las bases de datos distribuidas, la idea de un control centralizado tiene poco nfasis. En las bases de datos distribuidas es posible identificar una estructura de control jerrquico basado en un Administrador global de bases de datos, el cual tiene la principal responsabilidad de la totalidad de la base de datos, y el Administrador local de bases de datos, quien tiene la responsabilidad de su respectiva base de datos local. Esto nos da como resultado una caracterstica llamada Autonoma de sitio. Las bases de datos distribuidas tienen diferentes grados de autonoma de sitio: desde la ms completa autonoma sin ningn administrador centralizado hasta el ms completo control centralizado. Independencia de datos. La independencia de datos quiere decir, que la organizacin actual de los datos es transparente a las aplicaciones. Los programas son escritos teniendo una vista La ventaja principal de la conceptual de los datos, llamada esquema conceptual. organizacin fsica de los datos. En las bases de datos, la independencia de los datos es tan importante como en las bases de datos tradicionales; sin embargo, una nueva caracterstica se agrega a la definicin de la independencia de datos, esta es la transparencia de distribucin. Gracias a la transparencia de distribucin es que se pueden escribir programas como si la base de datos no estuviera distribuida. La independencia de datos fue introducida en las bases de datos tradicionales por la arquitectura multinivel que tiene diferentes descripciones de los datos y mapeos entre ellos. Las definiciones de esquema conceptual, esquema externo y esquema interno fueron desarrolladas para esta arquitectura. introduccin de nuevos niveles y esquemas. De manera similar, la transparencia de distribucin es obtenida en las bases de datos distribuidas por la

independencia de datos es que los programas no son afectados por los cambios en la

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Reduccin de la redundancia. En las bases de datos tradicionales, la redundancia fue reducida en lo posible, por dos razones: primera, la inconsistencia entre varias copias de los datos es evitada automticamente teniendo solo una copia de los datos; la segunda razn, la recuperacin de espacio de almacenamiento al eliminar la redundancia. accesen los mismos archivos. En las bases de datos distribuidas, se tienen varias razones para considerar la redundancia de los datos como una caracterstica necesaria: primero, las aplicaciones pueden verse favorecidas si los datos son replicados en todos los sitios donde la aplicacin las necesita, y segundo, la razn de disponibilidad del sistema puede incrementarse por este medio, debido a que si el sitio en el que se encuentran los datos fallara, la ejecucin de la aplicacin no se detiene porque existe una copia en algn otro sitio. Estructuras complejas y acceso eficiente, Las estructuras de acceso complejas, como ndices secundarios y enlaces entre archivos, son aspectos comunes de las bases de datos tradicionales. El soporte para estas estructuras es una de las partes ms importantes del DBMS (Database Manager System, Sistema manejador de base de datos). El objetivo de estas estructuras es el de obtener un acceso eficiente a los datos. Escribir un acceso distribuido es muy parecido al hacerlo en un sistema centralizado, en el sentido de que el programador especifica de qu modo ser accesada la base de datos. De cualquier forma, el proceso es local a cada uno de los sitios donde se encuentran los grupos de datos. Es conveniente tomar en cuenta dos cuestiones muy importantes en el momento de accesar una base de datos distribuida, la optimizacin local y la optimizacin global de los accesos. La optimizacin global consiste en determinar qu datos sern accesados en qu sitios y qu archivos de datos sern transmitidos entre sitios. La optimizacin local consiste en decidir como llevar acabo el acceso a la base de datos local en cada sitio. La redundancia se reduce compartiendo los datos, permitiendo que varias aplicaciones

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Seguridad. En las bases de datos tradicionales, el administrador de la base de datos, tiene el control centralizado, puede asegurarse que nicamente se tenga el acceso a los datos autorizados. En las bases de datos distribuidas, el administrador local enfrenta el mismo problema que el administrador de bases de datos tradicionales. Sin embargo, vale la pena mencionar dos aspectos peculiares de las bases de datos distribuidas: en una base de datos distribuida con un alto nivel de autonoma, los dueos de los datos locales pueden proteger de diferentes maneras su informacin, esto dependiendo del DBMS local; y segundo, los problemas de seguridad son intrnsecos en los sistemas de bases de datos en general, esto debido a que las comunicaciones en las redes es su punto dbil con respecto a la proteccin.

1.2

Ventajas de las bases de datos distribuidas sobre las bases de

datos centralizadas
Razones organizacionales La mayor parte de las organizaciones estn descentralizadas, y las bases de datos distribuidas se acercan ms a las necesidades de la estructura de la organizacin distribuida. Interconexin de las bases de datos existentes. Las bases de datos distribuidas son la solucin natural cuando se tienen varias bases de datos existentes en la organizacin. las bases de datos locales existentes. En este caso, las bases de datos distribuidas son creadas utilizando una estrategia de diseo tipo bottom-up a partir de Este proceso requiere cierto grado de reestructuracin local; de cualquier forma, el esfuerzo requerido para esto es mucho menor que el necesario para la creacin de una base de datos local completamente nueva.

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Desarrollo incremental. Si una organizacin agrega una nueva unidad, relativamente autnoma, entonces las bases de datos distribuidas soportaran este crecimiento con el menor grado de impacto a las unidades ya existentes. En un sistema centralizado cualquier cambio en las dimensiones del sistema tendra un impacto mayor, no solo en las nuevas aplicaciones, sino tambin en las ya existentes. Reduccin en la sobrecarga de la comunicacin. En una base de datos distribuida geogrficamente, el factor que las aplicaciones locales veran claramente reducido es la sobrecarga de las comunicaciones, en relacin con bases de datos centralizadas. de datos distribuidas. Consideraciones en el desempeo. La existencia de varios procesadores autnomos dan como resultado un incremento en el desempeo por medio de un alto grado de paralelismo. Esta consideracin puede ser aplicada a un sistema multiprocesador y no nicamente a los sistemas de bases de datos distribuidas. Las bases de datos distribuidas tienen la ventaja en que la descomposicin de los datos permite maximizar el desempeo de las aplicaciones locales; de esta forma es minimizada la mutua interferencia entre diferentes procesadores. Confiabilidad y disponibilidad. Las bases de datos distribuidas obtienen, por medio de la replica de datos, un alto grado de confiabilidad y disponibilidad. Sin embargo, el lograr esta meta no es tan fcil, pues requiere del uso de ciertas tcnicas, las cuales son difciles de comprender. La capacidad de procesamiento autnomo en los diferentes sitios no es, por s misma, garanta de que exista una completa confiabilidad en el sistema, pero esto generara una fcil degradacin del sistema; en otras palabras, las fallas en una base de datos distribuida pueden ser ms frecuentes que en las centralizadas, debido al gran nmero de componentes, pero el efecto de cada falla es considerado por cada aplicacin que usa los datos en sitio que fall, y por lo tanto es raro que el sistema en su totalidad falle. Por eso, en el mximo de que las aplicaciones sean locales es uno de los objetivos primarios en el diseo de las bases

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

1.3 Los doce objetivos de una base de datos distribuidas.


La siguiente expresin se podra considerar como el principio fundamental de los sistemas distribuidos en general, y por tanto es aplicable a las bases de datos distribuidas: Desde el punto de vista del usuario, un sistema distribuido deber ser idntico a un sistema no distribuido. Esto quiere decir que, los usuarios de un sistema distribuido debern comportarse exactamente como si el sistema no estuviera distribuido. Al principio fundamental antes mencionado se le conoce como el "objetivo o regla cero" de los sistemas distribuidos. Existen doce reglas u objetivos ms, las cuales norman la existencia de un sistema distribuido y en este caso, de una base de datos distribuida. Dichos sistemas debern apegarse a ellas, en la medida, en que el diseo y la tecnologa lo permitan, tales reglas son: Autonoma local. Los sitios de un sistema distribuido debern ser autnomos. La autonoma local significa que todas las operaciones en un sitio se controlan en ese sitio; ningn sitio deber depender de algn otro sitio para su buen funcionamiento. La autonoma local implica tambin un propietario y una administracin local de los datos, con responsabilidad local: todos los datos pertenecen a una base de datos local, aunque -sean accesibles para algn sitio remoto. sitio local. Por tanto, la seguridad, integridad y representacin en almacenamiento de los datos locales permanecen bajo el control del

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

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. autonoma local completa. La dependencia de un sitio central seria indeseable al menos por dos razones: primero, el sitio central podra ser un cuello de botella; en segundo lugar, el sistema sera vulnerable; si el sitio central sufriera un desperfecto, todo el sistema dejara de funcionar. Operacin continua. En un sistema distribuido como en uno no distribuido, lo ideal seria que nunca hubiera la necesidad de apagar el sistema a propsito. Es decir, el sistema nunca deber necesitar apagarse para que se pueda realizar alguna funcin, como actualizar el DBMS de un sitio existente o aadir un nuevo sitio. Dependencia (o Transparencia) con respecto a la localizacin. La idea bsica de la independencia con respecto a la localizacin es simple; no debe ser necesario que los usuarios sepan donde estn almacenados fsicamente los datos, sino que ms bien deben 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 hace posible la migracin de datos de un sitio a otro sin anular la validez de ningn programa o actividad. Esta posibilidad de migracin es deseable porque permite modificar la distribucin de los datos dentro de la red en respuesta a cambios en las necesidades del desempeo. 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 locales y se reduzca el trfico de la red. Existen en esencia dos clases de fragmentacin, horizontal y vertical, La no dependencia de un sitio central es deseable por s misma, an si no se logra la

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Un fragmento puede ser cualquier subrelacin arbitraria que pueda generarse de la relacin original mediante ciertas operaciones. Un sistema que maneja la fragmentacin de los datos deber ofrecer tambin una independencia con respecto a la fragmentacin (transparencia de fragmentacin); es decir, las bases de datos distribuidas debern poder comportarse (desde el punto de vista lgico) como si los datos no estuvieran fragmentados en realidad. Independencia de rplica. Un sistema maneja rplica de datos si una relacin dada (o, un fragmento dado de una relacin) se puede representar en el nivel fsico mediante varias copias almacenadas o rplicas, en muchos sitios distintos. La rplica es deseable al menos por dos razones: primero, puede producir un mejor desempeo (las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos); En segundo lugar, tambin puede significar una mejor disponibilidad. La desventaja principal de las replicas es la actualizacin, ya que cuando se actualiza un objeto copiado, deben de ser actualizadas todas las replicas de este objeto: Esto es, el problema de la propagacin de actualizaciones. La rplica, como la fragmentacin, debe ser transparente al usuario. de los datos. Procesamiento distribuido de las consultas. La optimizacin es todava ms importante en un sistema distribuido que en uno centralizado. Lo esencial es que, en una consulta, donde estn implicados varios sitios, habr muchas maneras de trasladar los datos en la red para satisfacer la solicitud y es crucial encontrar una estrategia eficiente. Por ejemplo, una solicitud de unin de una relacin Rx almacenada en el sitio X y una relacin Ry almacenada en un sitio Y podra llevarse a cabo trasladando Rx a Y o trasladando Ry a X, o trasladando las dos a un tercer sitio Z. As, la importancia crucial de la optimizacin es obvia, y esto a su vez puede verse como otra razn ms por la cul los sistemas distribuidos siempre son relacinales (pues las solicitudes relacinales son optimizables). En otras palabras, la base de datos deber comportarse como si solo existiera una sola copia

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Manejo distribuido de transacciones. El manejo de transacciones tiene dos aspectos principales, el control de recuperacin y el control de concurrencia. En un sistema distribuido, una sola transaccin puede implicar la ejecucin de cdigo en varios sitios. Por tanto, se dice que cada transaccin est compuesta de varios agentes, donde un agente es el proceso ejecutado en nombre de una transaccin dada en un sitio determinado. Y el sistema requiere saber cundo dos agentes son parte de la misma transaccin; por ejemplo, es obvio que no puede permitirse un bloqueo mutuo entre dos agentes que sean de la misma transaccin. Para asegurar que una transaccin dada sea atmica en el ambiente distribuido, el sistema debe asegurarse de que todos los agentes correspondientes a esa transaccin se comprometan al unsono o retrocedan al unsono, Este efecto puede lograrse mediante el protocolo de compromiso de dos fases. En cuanto al control de concurrencia, esta funcin en un ambiente distribuido est basada con toda seguridad en el bloqueo, como sucede en los sistemas no distribuidos (se han estudiado otras estrategias para el control de concurrencia, pero en la prctica, el bloqueo parece seguir siendo la tcnica preferida). Independencia con respecto al equipo. Las instalaciones de cmputo en el mundo real por lo regular incluyen varias mquinas diferentes y existe una verdadera necesidad de poder integrar los datos en todos esos sistemas y presentar al usuario una sola imagen del sistema. Independencia con respecto al sistema operativo. Este objetivo es en parte un corolario del anterior. Resulta obvia la consecuencia no slo de poder ejecutar el mismo DBMS en diferentes equipos, sino tambin de poder ejecutarlo en diferentes sistemas operativos (aun en diferentes sistemas operativos del mismo equipo). Independencia con respecto a la red. Si el sistema ha de poder manejar mltiples sitios diferentes, con equipo distinto y diferentes sistemas operativos, resulta obvia la conveniencia de poder manejar tambin varias redes de comunicacin distinta.

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Independencia con respecto al sistema manejador de base de datos (DBMS). 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. Por ejemplo, si tanto INGRES como ORACLE manejaran nicamente el estndar de SQL (ambos lo manejan pero cada uno tiene caractersticas propias que los hacen prcticamente incompatibles), podra ser posible lograr una comunicacin entre los dos en el contexto de un sistema distribuido. Dicho de otro modo, el sistema distribuido podra ser heterogneo, al menos en cierto grado. Una vez ms, en la realidad las instalaciones de cmputo no solo suelen emplear mquinas distintas, varios sistemas operativos diferentes, sino tambin ejecutan diferentes DBMS; y seria agradable que todos esos DBMS distintos pudieran participar de alguna manera en un sistema distribuido.

1.4

Arquitectura Cliente/Servidor

1.4.1 Paradigma Cliente/Servidor. El paradigma que dispone que una aplicacin espere pasivamente a que otra inicie la comunicacin permea una parte tan grande del cmputo distribuido que tiene un nombre: paradigma de interaccin cliente/servidor. 1.4.2 Procesamiento Cliente/Servidor. El modelo de procesamiento cliente/servidor surgi como un concepto de alto nivel de procesamiento compartido de dispositivos, tpico en las redes de rea local. En el procesamiento de dispositivos compartidos en la red de rea local (LAN), las computadoras personales estn enlazadas a un sistema de dispositivos que permite a las computadoras personales (PCs) compartir recursos. En la terminologa LAN, tales dispositivos son llamados servidores (un servidor de archivos y un servidor de impresin seran un ejemplo). El nombre de servidor es apropiado, puesto que estos dispositivos compartidos son usados para recibir solicitudes de servicio de las computadoras personales (PCs). Al mismo tiempo, el rol de las estaciones de trabajo fue cambiando hasta convertirse en clientes de los servidores. Esto es, los clientes realizan solicitudes de servicios a los servidores.

Bases de Datos Distribuidas

10

Fundamentos de las Bases de Datos Distribuidas

El modelo de procesamiento cliente/servidor es una extensin natural del procesamiento de dispositivos compartidos. En este modelo, el procesamiento de aplicaciones esta dividido entre el cliente y el servidor. El procesamiento es inicializado y parcialmente controlado por el solicitante del servicio (cliente) pero no es un funcionamiento maestro-esclavo, 1.4.3 Ventajas de la arquitectura cliente/servidor. Permite a las corporaciones obtener cada vez mejores tecnologas de computo. En la actualidad las estaciones de trabajo tienen un rendimiento y una potencia, la cual solo se obtena con mainframes, que eran muy costosas.

Permite que el procesamiento de los datos se realice en el lugar en el que se encuentran. (La arquitectura cliente/servidor es una forma especial de procesamiento distribuido y cooperativo) Por lo tanto, el trfico en la red se ve reducido significativamente, y por consiguiente las necesidades de una red de banda ancha y el costo se ven reducido.

Facilita el uso de interfaces de usuario grficas (GUI) disponibles en estaciones de trabajo. Estas nuevas interfaces pueden ser usadas por una gran variedad de clientes y cuentan con diferentes tcnicas para mostrar la informacin, logrando con esto una fcil navegacin.

Permite el uso de sistemas abiertos. Esto es, el cliente y el servidor pueden correr en diferentes plataformas de software y hardware permitiendo a los usuarios finales decidir libremente que arquitectura utilizar o poder utilizar la ya existente.

1.4.4 Desventajas de la arquitectura cliente/servidor.


Si una parte significativa de la aplicacin lgica es movida al servidor, el servidor puede convertirse en cuello de botella. usuarios. Las aplicaciones distribuidas, especialmente las que son diseadas para el proceso cooperativo, son ms complicadas que las no distribuidas. Esto es verdad para las aplicaciones de desarrollo, ambientes run-time y herramientas usadas para el mantenimiento de este ambiente distribuido. Los recursos del servidor pueden verse disminuidos por el incremento de demanda debido al aumento de

Bases de Datos Distribuidas

11

Fundamentos de las Bases de Datos Distribuidas

1.4.5 Caractersticas del cliente Es un programa de aplicacin arbitrario que se vuelve cliente temporalmente cuando necesita acceso remoto, pero tambin lleva a cabo otro computo local.

Lo llama directamente el usuario y se ejecuta solo durante la sesin. Se ejecuta localmente en la computadora personal del usuario. Inicia el contacto con el servidor. Puede acceder a varios servicios, segn se necesite, pero contacta activamente con un servidor remoto a la vez.

No necesita hardware poderoso y un sistema operativo complicado.

1.4.6 Funciones del cliente La Funcin ms importante que desempea un sistema cliente en un ambiente cliente/servidor es la presentacin y algunas funciones lgicas. El usuario final interacta con una aplicacin desarrollada para la presentacin lgica del sistema. Las funciones tradicionales de presentacin basadas en caracteres, en donde el procesador desplegaba los caracteres recibidos secuencialmente desde una aplicacin en pantalla con caracteres de tamao fijo. La continua evolucin de las funciones de presentacin ha sido estrechamente ligada con el alto desempeo de las estaciones de trabajo que ofrecan caractersticas grficas. Las caractersticas grficas permiten al procesador controlar de manera individual los pxeles en la pantalla, por tanto, no esta limitado a un tipo de carcter o al nmero de columnas de la pantalla. Estas caractersticas permiten el desarrollo de interfaces grficas de usuario (GUI) capaces de manejar grficos, imgenes, y audio-video. 1.4.7 Interfaz Grfica de Usuario estndar Una interfaz consistente entre el usuario y la aplicacin representa un parte importante en los sistemas abiertos. Las interfaces de presentacin entre el usuario y la aplicacin son llamadas interfaces Grficas de Usuario (GUI), y son diseadas para presentar la informacin a los usuarios de forma grfica. Existe una gran variedad de interfaces, pero cada nueva interfaz requiere que los usuarios y los desarrolladores tengan una nueva capacitacin en sus usos, y las aplicaciones sean modificadas. Una nueva interfaz de usuario requiere que las aplicaciones sean reescritas para esta nueva plataforma. Las aplicaciones escritas

Bases de Datos Distribuidas

12

Fundamentos de las Bases de Datos Distribuidas

para una GUI especifica no son portabas a otro ambiente GUI. interfaces incompatibles es Linux, Windows y Unix.

Un ejemplo de

Aun cuando la industria del hardware y software, aunada a asociaciones de usuarios prefieren una GUI en particular, Se tiene una GUI estndar, la cual debe de cumplir los siguientes requisitos: Portabilidad.- Las aplicaciones deben de ser portabas a travs de varias plataformas de sistema abiertos. migrar de una plataforma a otra. Flexibilidad.- Una GUI estndar debe de ser flexible y extensible, permitiendo ajustarse a nuevos tipos de monitores y a otros dispositivos de entrada salida, que podran estar disponibles en un futuro. Herramientas de desarrollo: Cualquier GUI que sea considerada un estndar debe proporcionar un conjunto de herramientas para el desarrollo. Internacionalizacin: En la actualidad, la internacionalizacin es otra de la Una GUI estndar debe de proporcionar un API estable en cualquier plataforma, de esta manera permitira una fcil y rpida manera de

forma de lograr una portabilidad. Esto incluye otros lenguajes, nmeros, unidades monetarias, formatos de fecha y hora, y smbolos especiales, as como mensajes relacionados con la cultura de esos pases. Independencia de plataforma: Para ser un verdadero sistema abierto y un estndar, una GUI deber ser diseado para operar independientemente del sistema operativo o la plataforma de hardware, en el que se esta ejecutando. 1.4.8 Caractersticas del servidor Es un programa privilegiado de propsito especial dedicado a ofrecer un servicio, pero puede manejar varios clientes remotos a la vez. Se inicia automticamente al arranque del sistema y continua ejecutndose en varias sesiones. Espera pasivamente el contacto de los clientes remotos. Acepta el contacto de varios clientes, pero ofrece un solo servicio.
Bases de Datos Distribuidas 13

Fundamentos de las Bases de Datos Distribuidas

Necesita hardware poderoso y un sistema operativo complejo.

1.4.9 Funciones de los servidores El mejor ejemplo de servidores especializados con respecto a la funcionalidad y diseo son los servidores de bases de datos, Bsicamente, los servidores de bases de datos nos permiten un rpido almacenamiento en disco, un significativo poder de procesamiento, y la capacidad de interactuar con varia aplicaciones (clientes) de manera simultnea. Un servidor es un proceso lgico que provee servicios a solicitudes de procesamiento. En la computacin cliente/servidor, un cliente inicia la interaccin cliente/servidor para enviar las solicitudes a los servidores. La funcin que un servidor debe llevar a cabo es determinada, en gran parte, por el tipo de solicitud que los clientes puedan enviar al servidor. Si un servidor es incapaz de llevar a cabo la solicitud de un cliente, entonces el servidor no puede participar en una interaccin cooperativa cliente/servidor. Idealmente. Un cliente no enva una solicitud que no sea soportada por un servidor. En general, sin embargo, una vez que un cliente y un servidor se han interconectado a travs de una red, alguna de las siguientes funciones pueden ser solicitadas al servidor por el usuario:

Compartir archivos. En un ambiente de grupo de trabajo, los clientes tal vez necesiten compartir los mismos archivos de datos. Estos archivos se colocan en procesadores de archivos compartidos (Servidores de archivos) y los clientes envan a estos sus solicitudes de 110.

Impresin compartida. En un ambiente de grupo de trabajo, una impresora de alto desempeo puede reemplazar a todas las impresoras individuales de los clientes. Entonces todos los clientes pueden enviar sus solicitudes de impresin a los servidores de impresin. Un servidor de impresin mantiene todos los archivos a ser impresos en una cola, a la cual se envan todos los archivos de los usuarios, y en su tumo, cada una de ellos sern impresos.

Bases de Datos Distribuidas

14

Fundamentos de las Bases de Datos Distribuidas

Servicios de comunicacin.

En un ambiente de grupo de trabajo que se

encuentra conectado a un host remoto, todas las comunicaciones de software y hardware se concentran en un dispositivo especial conocido como servidor de comunicaciones, al cual los clientes envan sus solicitudes para ser procesadas.

Servicios de Fax

Esto requiere usualmente software y equipo especial,

conocido como servidor de fax. Los clientes envan y reciben documentos de fax por medio de una apropiada solicitud del servicio al servidor de fax.

Acceso a las bases de datos.

En un ambiente cliente/servidor, el

procesamiento esta dividido en el sistema cliente y el sistema servidor, El servidor puede ejecutar una parte de la lgica de la base de datos. Algo similar al servidor de archivos, el servidor de bases de datos provee al cliente de los datos que residen en el servidor por medio de una solicitud, Sin embargo, el sistema manejador de bases de datos (DBMS), es ms sofisticado que los mtodos de acceso bsicos. El DBMS de un acceso a los datos por medio de varios niveles de bloqueo y de integridad de datos. El DBMS elimina la Los redundancia permitiendo una transparencia de distribucin de datos.

clientes requieren acceder ciertos datos (a diferencia de un servidor de archivos en el cual se tiene acceso al archivo completo), y toda la manipulacin necesaria para dar respuesta a la solicitud se realiza en el servidor de bases de datos. Otras funciones solicitadas por los clientes pueden ser de correo electrnico, de red, manejo de configuracin y manejo de recursos, para los cuales se deber de tener los servidores apropiados. Un nodo servidor dentro del modelo cliente/servidor puede ser especializado para realizar cierta funcin. De cualquier forma, los servidores deben cumplir con los siguientes requerimientos generales:

Soporte multiusuario. Aun en un pequeo grupo de trabajo, un servidor debe de ser capaz de proporcionar servicio a mltiples usuarios concurrentes. Los

Bases de Datos Distribuidas

15

Fundamentos de las Bases de Datos Distribuidas

clientes ejecutan mltiples tareas esperando que el servidor sea capaz de soportar un procesamiento multitarea.

Escalabilidad.

Un servidor debe de ser capaz de satisfacer la creciente Escalabilidad no

demanda de los recursos, as como de las aplicaciones.

significa que usuarios deben comprar un sistema de servidor de mayor capacidad de procesamiento lo cual implicara un costo extra. Por el contrario, el sistema debe de satisfacer los requerimientos actuales y, al mismo tiempo, debe de permitir una fcil expansin.

Desempeo.

Un sistema servidor debe proveer niveles de desempeo

satisfactorios necesarios para la empresa y los requerimientos de los usuarios en un ambiente multiusuario cliente/servidor.

Almacenamiento. Como el nmero de aplicaciones ejecutndose y de usuarios aumentan, y los avances de la tecnologa de dispositivos de almacenamiento han hecho que los costos bajen, la demanda de almacenamiento de rpido acceso se ha convertido en un requisito esencial en un sistema servidor.

Gestin de redes. comunicacin de red.

La comunicacin cliente/servidor requiere de una Ambos, cliente y servidor deben de contar con

capacidades de red. Sin una red el cliente y el servidor no podran interactuar.

Multimedia. Las nuevas aplicaciones y las nuevas tecnologas cuentan con capacidades multimedia, es necesario dar soporte al almacenamiento y reproduccin de imagen, vdeo y sonido.

1.4.1 0 El sistema X Window El sistema X Window permite un manejo transparente de la interfaz grfica en estaciones de trabajo. Conocido tambin como X, fue desarrollado conjuntamente por el Instituto Tecnolgico de Massachussets, IBM, y DEC en un proyecto conocido como Athena. La arquitectura X est basada en el modelo cliente/servidor. X proporciona:

Bases de Datos Distribuidas

16

Fundamentos de las Bases de Datos Distribuidas

Un Protocolo de comunicacin transparente entre una aplicacin y su presentacin lgica, la cual puede residir en una estacin de trabajo remota.

Alto desempeo en la independencia de dispositivos grficos.

En la tecnologa cliente/servidor, el nodo que despliega y recibe informacin, e interacta con el usuario, es el nodo cliente. Los X clients contienen la aplicacin lgica funcional escrita por el desarrollador, aunque esta residira en un sistema servidor en la red cliente/servidor. El X Client es enlazado con las libreras X Window y las libreras de las herramientas basadas en X usadas para crear una aplicacin. Aun cuando la designacin de X Client y X Server pueden parecer contradictorias a la definicin de cliente y servidor del modelo cliente/servidor. De hecho: En el sistema X Window, el X cliente inicia la interaccin con su servidor, el X Server. El X Client solicita un X Server para las funciones de despliegue en pantalla. Un X Server puede dar servicio a mltiples X clients. X Client y X Server pueden estar en la misma mquina.

1.5 Problemas de los sistemas distribuidos El mayor problema en las redes de rea amplia es que son lentas. Por ejemplo algunas redes tienen una velocidad de transferencia de 1250 bytes por segundo, mientras que un disco duro representativo tiene un factor de transferencia de al rededor de 1 a 2 millones de bytes por segundo. Por lo tanto, un objetivo principal de los sistemas distribuidos es reducir el nmero y volumen de los mensajes. siguientes: Este objetivo a su vez da pie a problemas en varias reas secundarias, entre ellas las

Procesamiento de consultas.

Bases de Datos Distribuidas

17

Fundamentos de las Bases de Datos Distribuidas

El objetivo de reducir al mnimo el trfico en la red implica que el proceso mismo de optimizacin de consultas debe ser distribuido, adems del proceso de ejecucin de las consultas. En otras palabras, un proceso representativo consistir en un paso de optimizacin global, seguido de pasos de optimizacin local en cada uno de los sitios. Por ejemplo se requiere una consulta C en el sitio X, y que C implica una reunin de una relacin Ry de cien tuplas en el sitio Y con una relacin Rz de un milln de tuplas en el sitio Z. El optimizador ubicado en el sitio X escoger la estrategia global para ejecutar C; y resulta evidente la importancia de que decida trasladar Ry a Z y no Rz a Y (y ciertamente no Ry y Rz a X). Despus, una vez que haya decidido trasladar Ry a Z, el optimizador local en Z ser el que decida cul debe ser la estrategia para realizar la unin en este sitio. Administracin del catlogo. En un sistema distribuido, el catlogo del sistema incluir no solo la informacin usual acerca de las relaciones, ndices, usuarios, etctera; sino tambin toda la informacin de control necesaria para que el sistema pueda ofrecer la independencia deseada con respecto a la localizacin, la fragmentacin y la rplica. Existen varias tcnicas para el almacenamiento de los catlogos: 1. Centralizado: El catlogo total se almacena una sola vez, en un sitio central. 2. Replicas completas: El catlogo total se almacena por completo en todos los sitios. 3. Dividido: Cada sitio mantiene su propio catlogo para los objetos almacenados en ese sitio. El catlogo total es la unin de todos los catlogos locales no traslapados. 4. Combinacin de 1 y 3: Cada sitio mantiene su propio catlogo local, como en el punto 3; adems, un sitio central nico mantiene una copia unificada de todos los catlogos locales, como en el punto 1. Todos estos enfoques tienen algn problema. Es obvio que el enfoque 1 viola el objetivo de "no depender de un sitio central": el enfoque 2 adolece de una grave falta de autonoma, pues toda actualizacin del catalogo deber de ser propagada a cada uno de los sitios. El enfoque 3 hace muy costosas todas las operaciones no locales (no encontrar un objeto remoto requerir obtener acceso a la mitad de los sitios en promedio). El enfoque 4 es ms eficiente que el 3 (encontrar un objeto remoto requiere

Bases de Datos Distribuidas

18

Fundamentos de las Bases de Datos Distribuidas

slo el acceso a su catlogo remoto), pero viola una vez ms el objetivo de "no depender de un sitio central". Por lo tanto, los sistemas en la practica casi nunca usan ninguno de estos cuatro enfoques. Propagacin de actualizaciones. El problema bsico con la rplica de datos, como se seal es la necesidad de propagar cualquier modificacin de un objeto lgico dado a todas las copias almacenadas de ese objeto, Un problema que surge es algn sitio donde se mantiene una copia del objeto podra no estar disponible en el momento de la actualizacin. As, la estrategia de propagar las actualizaciones de inmediato a todas las copias podra ser inaceptable, porque implica que la modificacin ( y la transaccin) fracasara si cualquiera de estas copias no esta disponible en el momento. Un mtodo para manejar este problema es el llamado mtodo de "copia primaria", el cual funciona de la siguiente manera: Una de las copias del objeto se designa como copia primaria. Las dems sern copias secundarias. Las copias primarias de los diferentes objetos estn en sitios diferentes (de modo que, una vez ms, este mtodo es distribuido). Las operaciones de actualizacin se consideran completas tan pronto como se ha modificado la copia primaria. momento posterior. Este mtodo representa un problema, una violacin al objetivo de autonoma local, porque ahora una transaccin podra fallar cuando una copia (primaria) remota de algn objeto no estuviera disponible, aun cuando se dispusiera de una copia local. El sitio donde se encuentra esa copia se encarga entonces de propagar la actualizacin a las copias secundarias en un

Bases de Datos Distribuidas

19

Fundamentos de las Bases de Datos Distribuidas

Control de recuperacin. El control de recuperacin en los sistemas distribuidos se basa por lo regular en el protocolo de dos fases. El compromiso de dos fases es obligatorio en cualquier ambiente en el cual una sola transaccin puede interactuar con vados manejadores de recursos autnomos, pero tiene especial importancia en un sistema distribuido porque los manejadores de recursos en cuestin (DBMS locales) operan en sitios remotos distintos y por tanto son muy autnomos. De acuerdo a lo anterior surgen los siguientes puntos: 1. El objetivo de "no dependencia de un sitio central' dicta que la funcin de coordinador no debe asignarse a un sitio especifico de la red, sino que deben realizara diferentes sitios para diferentes transacciones. Por lo general se encarga de ella el sitio en el cual se inicia la transaccin en cuestin. 2. El proceso de compromiso en dos fases requiere una comunicacin entre el coordinador y todos los sitios participantes, lo cual implica ms mensajes y mayor costo. 3. El sitio Y acta como participante en un compromiso de dos fases coordinado por el sitio X, el sitio Y deber hacer lo ordenado por el sitio X (compromiso o retroceso), lo cual implica otra prdida de autonoma local. 4. En condiciones ideales el proceso de compromiso en dos fases funcionar an en caso de presentarse fallas de sitios o de la red en cualquier punto. Idealmente, el proceso debera ser capaz de soportar cualquier tipo concebible de falla. Control de concurrencia. Como en mayor parte de los sistemas distribuidos el control de concurrencia se basa en el bloqueo, tal como sucede en casi todos los sistemas no distribuidos. Pero en un sistema distribuido, las solicitudes de prueba, establecimiento y liberacin de

Bases de Datos Distribuidas

20

Fundamentos de las Bases de Datos Distribuidas

bloqueo se convierten en mensajes (suponiendo que el objeto en cuestin es un sitio remoto), y los mensajes implican costos adicionales. Por ejemplo, se considerara una transaccin T que necesita poner al da un objeto del cual existen rplicas en n sitios remotos. Si cada sitio se encarga de los bloqueos sobre los objetos almacenados en ese sitio (como suceder si se cumple la suposicin de autonoma local), la puesta en practica directa requerir por lo menos de 5 mensajes por cada sitio: solicitud de bloqueo concesiones de bloqueo mensajes de actualizacin verificaciones solicitudes de liberacin de bloqueo

As pues, el tiempo total invertido en la actualizacin podra con facilidad ser mayor que en un sistema centralizado. Otro problema con el bloqueo en un sistema distribuido es que puede conducir a un bloqueo mutuo, en el cual se veran implicados varios sitios. El problema con un bloqueo como ste es que ninguno de los sitios puede detectarlo empleando slo informacin interna de este sitio. Dicho de otro modo, no existen ciclos en las grficas de espera locales, aunque aparecer un ciclo si se combinan esas dos grficas locales para formar una grfica de espera global. En consecuencia, la deteccin de bloqueos mutuos globales implica mayores costos adicionales de comunicacin, pues requiere juntar de alguna manera las grficas locales individuales. 1.6 Soporte para bases de datos distribuidas Existen diversos Sistemas Manejadores de Bases de Datos (DBMS) comerciales, los cuales en sus inicios fueron diseados para el manejo de bases de datos centralizadas, logrando un hito en el manejo de datos puesto que permitieron el diseo de sistemas abiertos. Esto gracias al sublenguaje de datos con que trabajaban en la realizacin de consultas (por lo general SQL), los programadores de aplicaciones solo se preocupaban por generar las consultas en SQL y no por generar consultas para uno u otro DBMS en particular.

Bases de Datos Distribuidas

21

Fundamentos de las Bases de Datos Distribuidas

Al aumentar la cantidad de datos y la necesidad de informacin, y de la misma manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS tambin tuvieron que evolucionar a lo que actualmente se conoce como Sistemas Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS, adems de contar con el sublenguaje de datos deben tener nuevas caractersticas propias de las bases de datos distribuidas como son el soporte de fragmentacin, replicacin, y el procesamiento de consultas distribuidas. Sin dejar a un lado que un DDBMS debe de ser un sistema abierto, esto debido a que el DDBMS se debe de comunicar con otro sito en el cual tal vez no cuente con el mismo DDBMS. Algunos de los DDBMS comerciales con los que se cuenta son INFORMIX, DB2 y ORACLE. A continuacin se presenta una tabla en la cual se muestran algunas de las caractersticas de dichos DDBMS:

DDBMS INFORMIX VS.07 DB2 V5 ORACLE V8

DSL SQL SQL SQL

REPLICA Soportada Integrada Integrada

Existen muchos ms DDBMS con diferentes caractersticas, por ejemplo, Sybase ofrece las primitivas pero- las aplicaciones deben de implementar las transacciones distribuidas por si mismas, sin embargo, es posible disear de manera optima una base de datos distribuida con las herramientas que estos DDBMS comerciales proporcionan.

Bases de Datos Distribuidas

22

Fundamentos de las Bases de Datos Distribuidas

1.7 Resumen
Las caractersticas que deben de tener los sistemas de bases de datos son: Control centralizado: Un Administrador de base de datos (DBA) tiene la funcin de garantizar la seguridad de los datos, el administrador local tiene la responsabilidad de su respectiva base de datos, mientras que el administrador global tiene la principal responsabilidad de la totalidad de los datos de la base de datos. Independencia de datos: quiere decir que, la organizacin actual de los datos es transparente a las aplicaciones y en el caso de una base de datos distribuida se refiere tambin a la transparencia de distribucin. Reduccin de redundancia: la redundancia debe de ser reducida, por dos razones: evitar la inconsistencia entre varias copias de los datos, y recuperar espacio de almacenamiento en el sistema, an cuando en una base de datos distribuida, las aplicaciones podran verse favorecidas con la redundancia, ya que, debido a esta, la razn de disponibilidad puede aumentar. Estructuras fsicas complejas y acceso eficiente: El uso de estructuras de acceso podra ser una herramienta para el acceso eficiente a la base de datos, es conveniente tomar en cuenta la optimizacin local, el acceso a las bases de datos locales, y la optimizacin global, el acceso a los sitos que conforman la base de datos, de las consultas. Seguridad: En las bases de datos tradicionales, el administrador de la base de datos, tiene el control centralizado. En las bases de datos distribuidas, se tienen, adems, que considerar dos aspectos, el grado de autonoma y la seguridad en los accesos de los usuarios.

Bases de Datos Distribuidas

23

Fundamentos de las Bases de Datos Distribuidas

Las bases de datos distribuidas tienen algunas ventajas sobre las no distribuidas, estas son: Razones organizacionales: La mayor parte de las organizaciones estn ya descentralizadas. Interconexin de las bases de datos existentes: Las bases de datos distribuidas son la solucin cuando se tiene varias bases de datos en la organizacin. Desarrollo incrementar: Es posible agregar una nueva unidad en una base de datos distribuida si afectar a las ya existentes. Reduccin de la sobrecarga de la comunicacin: En una base de datos distribuida geogrficamente, se vera reducida la sobrecarga de las comunicaciones en comparacin con una base de datos no distribuida. Consideraciones en el desempeo: La existencia de varios procesadores autnomos da como resultado un alto grado de procesamiento en paralelo. Confiabilidad y disponibilidad: Por medio de la repica de datos, se logra un alto grado de contabilidad y disponibilidad. Existe un principio fundamental en los sistemas distribuidos, el cual es aplicable a las bases de datos distribuidas: Desde el punto de vista del usuario, un sistema distribuido deber ser idntico a un sistema no distribuido. Hay adems de este, 12 reglas para los sistemas distribuidos: 1. Autonoma local: Significa que todas las operaciones en un sitio se controlan en ese sitio.

Bases de Datos Distribuidas

24

Fundamentos de las Bases de Datos Distribuidas

2. No dependencia de un sitio central: Todos los sitios son iguales y no dependen de ningn otro sitio. 3. Operacin continua: Un sistema distribuido siempre esta disponible. 4. Independencia con respecto a la localizacin: Los usuarios nunca sabrn la localizacin real de los datos. 5. Independencia con respecto a la fragmentacin: Un sistema distribuido deber dar la apariencia de que se encuentra en una sola pieza. 6. Independencia de replica: Un sistema deber comportarse como si solo e)dstiera una sola copia de los datos. 7. Procesamiento distribuido de consulta: En una consulta, la cual involucro a ms de un sitio, siempre habr varias maneras de trasladar en la informacin para satisfacer la peticin y encontrar la estrategia ms eficiente. 8. Manejo distribuido de transacciones: Deber poder procesar una transaccin a travs de varios sitios. 9. Independencia con respecto al equipo: Deber poder procesar una transaccin a travs de diferentes plataformas de hardware y aparentar ante el usuario como si fuera uno solo. 10. Independencia con respecto al sistema operativo: Deber de ser capaz de trabajar en cualquier sistema operativo. 11. Independencia con respecto a la red: Deber de ser capaz de trabajar en diferentes redes. 12. Independencia con respecto al DBMS: Varios DBMS debern trabajar en conjunto y procesar las transacciones.

Bases de Datos Distribuidas

25

Fundamentos de las Bases de Datos Distribuidas

El paradigma que dispone que una aplicacin debe esperar pasivamente a que otra aplicacin inicie la comunicacin, tiene el nombre de interaccin cliente/servidor. El modelo de procesamiento cliente/servidor surgi del concepto de procesamiento compartido de las redes de rea local. As, las computadoras personales conectadas a un sistema pueden compartir recursos, la computadora que solicita el recurso pasa a ser un cliente, mientras que aquella que comparte el recurso y recibe la peticin se convierte en servidor. Esta arquitectura provee ciertas ventajas: Permite integrar mejores tecnologas al sistema. Permite que el procesamiento de los datos se realice en el lugar en el que estos residen Facilita el uso de interfaces grficas de usuario. Permite el uso de sistemas abiertos.

A pesar de todo esto, tambin cuenta con algunas desventajas: El servidor puede convertirse en cuello de botella, al verse disminuidos los recursos del servidor. El desarrollo de aplicaciones distribuidas es ms complicado que el de las no distribuidas. Tanto el cliente como el servidor, deben de cumplir con ciertas caractersticas para ser considerados como tales: Cliente Es un programa de aplicacin arbitrario que se vuelve cliente temporalmente cuando necesita acceso remoto, pero tambin lleva a cabo otro computo local. Lo llama directamente el usuario y se ejecuta solo durante la sesin. Se ejecuta localmente en la computadora personal del usuario. Inicia el contacto con el servidor.

Bases de Datos Distribuidas

26

Fundamentos de las Bases de Datos Distribuidas

Puede acceder a varios servicios, segn se necesite, pero contacta activamente con un servidor remoto a la vez. No necesita hardware poderoso y un sistema operativo complicado.

Servidor El Es un programa privilegiado de propsito especial dedicado a ofrecer un servicio, pero puede manejar varios clientes remotos a la vez. Se inicia automticamente al arranque del sistema y continua ejecutndose en varias sesiones. Opera en una computadora compartida (es decir, no en una computadora personal). Espera pasivamente el contacto de los clientes remotos. Acepta el contacto de varios clientes, pero ofrece un solo servicio. Necesita hardware poderoso y un sistema operativo complejo.

cliente debe de cumplir con la funcin de presentar la informacin al usuario, Por su parte el servidor debe de proveer servicios a solicitudes de

as como de realizar algunas funciones lgicas en el procesamiento de dicha informacin. procesamiento, el cliente inicia la interaccin cliente/servidor enviando solicitudes a los servidores, la funcin de un servidor debe llevar a cabo una determinada accin, de acuerdo a la solicitud enviada por el cliente. Algunas funciones que un servidor pudra realizar seria: Compartir archivos. Compartir impresoras. Servicios de comunicacin. Servicios de fax. Accesos a las bases de datos.

Un servidor deber, tambin, cumplir con ciertos requerimientos generales: Soporte multiusuario: Debe de ser capaz de proporcionar servicio a mltiples clientes.

Bases de Datos Distribuidas

27

Fundamentos de las Bases de Datos Distribuidas

Escalabilidad: Debe de ser capaz de satisfacer la creciente demanda de los recursos y las aplicaciones. Desempeo: Un servidor debe proveer niveles de desempeo satisfactorios. Almacenamiento: Debe de ser capaz de almacenar tanto aplicaciones, como los archivos generados por estas y los usuarios. Gestin de red: Tanto el servidor como el cliente deben de contar con capacidades de red. Multimedia: En la actualidad la necesidad de que un servidor soporte datos, vdeo y sonido son esenciales.

Debido a que un sistema distribuido involucro el procesamiento cooperativo entre vados servidores y clientes, se presentan algunos problemas que se deben de tomar en cuenta para ser solucionados: Procesamiento de consultas: El proceso deber de ser distribuido, por lo tanto, un proceso representativo consistir en una actualizacin global seguida de optimizaciones locales en cada sitio. Administracin del catalogo: En un sistema distribuido, el catalogo del sistema incluir la informacin a cerca de las relaciones, los ndices, los usuarios, y la localizacin de fragmentos y replicas de los datos. Propagacin de las actualizaciones: Es necesario propagar cualquier actualizacin de un objeto dado, en todas las copias existentes de ese objeto en el sistema. Control de recuperacin: Es necesario que un sistema distribuido cuente con un mtodo de recuperacin, esto, en caso de cadas del sistema. El control de recuperacin en los sistemas distribuidos se basa por lo regular en el protocolo de dos fases. El compromiso de dos fases es obligatorio en cualquier ambiente en el cual una sola transaccin puede interactuar con varios manejadores de recursos autnomos. Control de concurrencia: el control de concurrencia se basa en el bloqueo, las solicitudes de prueba, establecimiento y liberacin de bloqueo, los cuales se convierten en mensajes, y por lo tanto implica costos adicionales. La puesta en practica directa

Bases de Datos Distribuidas

28

Fundamentos de las Bases de Datos Distribuidas

requerir por lo menos de 5 mensajes por cada sitio involucrado en la transaccin: solicitud de bloqueo, concesiones de bloqueo, mensajes de actualizacin, verificaciones, solicitudes de liberacin de bloqueo. Al aumentar la cantidad de datos y la necesidad de informacin, y de la misma manera al evolucionar las bases de datos centralizadas a distribuidas, los DBMS tambin tuvieron que evolucionar a lo que actualmente se conoce como Sistemas Manejadores de Bases de Datos Distribuidas (DDBMS). Estos DDBMS debern contar con: el sublenguaje de consultas, el soporte de fragmentacin, replicacin, y el procesamiento de consultas distribuidas. Sin dejar a un lado que un DDBMS debe de ser un sistema abierto capaz de interactuar con otros DDBMS.

1.8 Preguntas de repaso


1.-Cuales son las caractersticas sobre las cuales, es posible hacer una comparacin entre bases de datos centralizadas y bases de datos distribuidas? 2.-Cuales son las ventajas que tienen las bases de datos distribuidas sobre las centralizadas? 3.-Cul es la regla cero de los sistemas distribuidos? 4.-Por qu la regla cero de los sistemas distribuidos es considerada el principio de las bases de datos distribuidas? 5.-A que se refiere la autonoma en el enfoque de las bases de datos distribuidas? 6.-Que significa transparencia dentro del entorno de las bases de datos distribuidas? 7.-Cmo describe la arquitectura cliente - servidor? 8.Cuales deben ser las caractersticas de un cliente? 9.-Cules deben ser las caracteristic as de un servidop 10.-Que requerimientos son necesarios para un servidor? 11.- Cuales son los principales problemas a los que se enfrentan los diseadores de bases de datos distribuidas?

Bases de Datos Distribuidas

29

Fundamentos de las Bases de Datos Distribuidas

Bibliografa [1] Date, C.J.; "An lntroduction to Databases Systems"; Volume 1-1 Fifth Edition; Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1990 [2] Date, C.J-; "An Introduction to Databases Systems"; Volume li; Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1995 [3] Korth, Henry F. Silberschatz, Abraham; "Database System Concepts"; Second Edition; McGraw-Hill; U.S.A-; Internacional Edition 1991 [4] Berson, Alex - "Client/ServerArchitecture'; McGraw-Hill; U.S.A.-, 1992 [5] Renuad, Paul E.; "Introduction to Client/Server Systems A practicar guide for systems professionals"; Wiley Professional Computing; U.S.A.; 1993

Bases de Datos Distribuidas

30

Fundamentos de las Bases de Datos Distribuidas

Captulo II

Bases de Datos en mltiples servidores


Objetivo
El alumno comprender las tcnicas de diseo de bases de datos distribuidas, as como cada uno de los tipos de fragmentacin existentes y las operaciones necesarias para realizarla.

Introduccin
En este captulo se tratarn las consideraciones que se debern tener al disear la distribucin de la base de datos, as como los tipos de fragmentaciones que existen y como se obtienen. Tambin se expondr la forma en como se debern llevar a cabo el procesamiento de las consultas en un sistema con datos distribuidos y los costos de dicho procesamiento, A continuacin se presenta una tabla con las operaciones del lgebra relaciona que se utilizarn a lo largo del captulo: Operacin Select Projecion Join Semi-join Union Producto cartesiano Natural Join Natural Semi-join Abreviacin SL Pi JN Si UN CP NJN NSJ X Smbolo

Bases de Datos Distribuidas

31

Fundamentos de las Bases de Datos Distribuidas

Diferencia

DF

2.1 Consideraciones en la distribucin de bases de datos Desde la primera etapa de las bases de datos distribuidas a la actualidad, se han desarrollado varias tcnicas para su diseo. De cualquier forma esta claro que el diseo de bases de datos distribuidas no es fcil, ya que por si mismas, las tcnicas y organizacin, en el diseo de un sitio sencillo son complicadas, stas se vuelven ms complicadas en el diseo de un sistema multisitio. Desde el punto de vista tcnico, los nuevos problemas que se presentan son la interconexin entre los sitios por medio de la red, y la distribucin optima de los datos y aplicaciones en los sitios para lograr un desempeo ptimo del sistema. Desde el punto de vista organizacional, la descentralizacin es crucial, puesto que se sustituir por un sistema distribuido al tpico y extenso sistema centralizado, y en el caso de la distribucin de una aplicacin tendra un gran impacto en la organizacin. El diseo de una base de datos centralizada consiste en: 1. 2. Disear el "esquema conceptual", el cual describe la base de datosDisear el 'esquema fsico", mapeando el esquema conceptual con las reas de almacenamiento y determinando los mtodos de acceso. En las bases de datos distribuidas estos dos puntos son utilizados para disear el esquema global y disear las bases de datos locales en cada sitio. La distribucin de las bases de datos requiere agregar dos nuevos puntos: 3. Disear la fragmentacin de los datos, determinando como las relaciones globales sern divididas, horizontalmente, verticalmente o en fragmentos mixtos. 4. Disear la distribucin de los fragmentos, determinando como se mapearn los fragmentos, con las imgenes fsicas. En este punto son determinadas las replicas de los fragmentos.

Bases de Datos Distribuidas

32

Fundamentos de las Bases de Datos Distribuidas

Estos dos puntos son caractersticos en el diseo de datos distribuidos.

2.1.1 Objetivos del diseo de los datos distribuidos En el diseo de los datos distribuidos, los siguientes objetivos debern ser tomados en cuenta: Procesamiento local. La distribucin de los datos aumenta el procesamiento local, esto correspondiendo a un principio bsico de que los datos son colocados lo ms cercano a las aplicaciones que los utilizan. Una manera simple de ejemplificar el procesamiento local, es considerar dos tipos de referencias a los datos: referencias "locales" y referencias "remotas". Claramente, una vez que los sitios de origen de las aplicaciones conocen la localizacin local y remota de los datos, la referencia depende nicamente de la distribucin de los mismos. Se deber, tambin, tomar en cuenta cuando una aplicacin tiene un procesamiento local completo, es decir la aplicacin se ejecuta completamente en el lugar de origen. La ventaja del procesamiento local completo no solamente reduce los accesos remotos, sino que adems, incremento la simplicidad en el control de la ejecucin de la aplicacin.

Disponibilidad y confiabilidad de los datos distribuidos. El almacenamiento de mltiples copias de la informacin permite lograr un alto grado de disponibilidad para las aplicaciones que solo leen o muestran los datos; el sistema puede conmutar a una copia alternativa, cuando la copia que comnmente era accesada no se encuentra disponible. La Confiabilidad se logra por medio del almacenamiento de mltiples copias de la informacin permitiendo recuperarla, de cadas del sistema o de daos fsicos en alguna de las copias, usando cualquier otra copia disponible.

Bases de Datos Distribuidas

33

Fundamentos de las Bases de Datos Distribuidas

Distribucin de la carga del trabajo. La distribucin de la carga del trabajo en los sitios es una caracterstica importante de los sistemas distribuidos. La distribucin de la carga del trabajo es hecha en relacin con el poder de cmputo y utilizacin del equipo de cada sitio, y para maximizar el grado de paralelismo en la ejecucin de las aplicaciones. La distribucin de la carga del trabajo puede provocar un efecto negativo en la ejecucin local.

Disponibilidad y costo del almacenamiento. La distribucin de las bases de datos se refleja en el costo y disponibilidad del medio de almacenamiento en los diferentes sitios. Esto es posible teniendo sitios especializados en la red para el almacenamiento de datos. Por lo general, el costo del almacenamiento de los datos nos es tan relevante, comparado con el costo de CPU, I/O, y el costo de la transmisin de las aplicaciones.

2.2 Diseo de bases de datos distribuidas


2.2.1 Tcnicas de diseo Top-Down y Bottom-Up de bases de datos distribuidas Se tiene dos alternativas en el diseo de las bases de datos distribuidas, las tcnicas Top-Down y Bottom-Up. En la tcnica top-down, se comienza diseando el esquema global, y se procede con el diseo de la fragmentacin de los datos, despus se distribuyen los fragmentos en los sitios, creando las imgenes fsicas. Esta tcnica es complementada con la construccin, en cada sitio, del "diseo fsico" de los datos que estarn almacenados ah. Cuando la base de datos distribuida es desarrollada como un complemento de una base de datos existente, no es tan fcil lograr esto con la tcnica top-down- De hecho, en este caso el esquema global est, por lo general, comprometido con los datos existentes.

Bases de Datos Distribuidas

34

Fundamentos de las Bases de Datos Distribuidas

Cuando una nueva base de datos va a ser agregada a una ya existente, la tcnica de diseo bottom-up puede ser utilizada. Esta tcnica consiste en la integracin de esquemas existentes en un solo esquema global. Para la integracin, se deber de unir definiciones de datos comunes y resolver conflictos entre diferentes representaciones del mismo dato. En resumen, la tcnica bottom-up requiere: 1. 2. 3. La seleccin de un modelo de base de datos comn para disear el esquema global de la base de datos. La traduccin de cada esquema local al modelo de datos comn. La integracin de los esquemas locales en el esquema global comn.

2.2.2 Diseo de los fragmentos de la base de datos El diseo de los fragmentos es la primera parte dentro de la tcnica top-down. El propsito de la fragmentacin es determinar fragmentos no traslapados, los cuales sern unidades lgicas de distribucin. Se podr ver que, las tuplas y atributos de la relacin no podrn ser considerados como "unidades individuales de distribucin'. El diseo de fragmentos consiste en agrupar tuplas (en el caso de la fragmentacin horizontal) o atributos (en el caso de la fragmentacin vertical), las cuales tienen las "mismas propiedades" desde el punto de vista de la distribucin. Cada grupo de tuplas o atributos que tienen las "mismas propiedades" puede constituir un fragmento. La idea bsica es que si dos elementos cualquiera de un mismo fragmento tiene las mismas propiedades" desde el punto de \Asta de la distribucin, cualquier mtodo usado para localizar un dato puede entonces localizar a cualquiera.

2.2.3 Correctez de la fragmentacin Para que una fragmentacin sea correcta, esta deber de cumplir con las siguientes caractersticas: Completez

Bases de Datos Distribuidas

35

Fundamentos de las Bases de Datos Distribuidas

La descomposicin de una relacin R en fragmentos RI,R2, ... ,Rn, es completa si y solo si cada elemento de datos en R puede ser encontrado en algn Ri Reconstruccin Si la relacin R es descompuesta en fragmentos Rl,R2, ... , Rn, debiera existir un operador relacional tal que: R Ri Exclyete Si la relacin R es descompuesta, en fragmentos Rl,R2, .... Rn, y datos de] elemento di estn en Rj entonces di no debiera estar en algn otro fragmento Rk k).

2.2.4 Fragmentacin horizontal La fragmentacin horizontal consiste en particionar las tuplas o registros de una Tabla global en subconjuntos de tuplas o registros; esto es muy utilizado en las bases de datos distribuidas, donde cada subconjunto pueden contener datos con propiedades geogrficamente comunes. Es importante, dentro de la fragmentacin horizontal, considerar las siguientes definiciones: Predicado simple Dado R[Al,A2, ... A.], un predicado simple pj es: pj: Ai Valor donde {= , , , , <, >}, Valor Di y Di es el dominio de A. Se tendr entonces R[pl,P2,P3,---,PMI Predicados minitermino Dado Ri y Pti = {p1,p2, ... pj definir M = {mi1, mi2, ... miz} como: Mi = {mij l mij = ^pik pri pik*}, 1 k m, 1 j z donde pi*= pi o pi* = ~pi selectividad de miniterminos sel(mj) Nmero de tuplas de la relacin que sera accesada por una consulta de usuario la cual es especificada acorde a un predicado minitermino mj dado.

Bases de Datos Distribuidas

36

Fundamentos de las Bases de Datos Distribuidas

frecuencias de acceso: acc(qj) Frecuencia con la cual la aplicacin qj accesa datos. La frecuencia de acceso por una predicado minitermino puede tambin ser definida. Considrese la siguiente relacin global: Proveedor(pclave, nombre, cveciudad)

pClave

Nombre

cveciudad

P01 P02 P03 P04 P05 P06

John Smith Jos Sanchz Juan Prez Steven Freeman Alex Tere

SF LA LA SF SD SD

Para la cual se tiene la siguiente aplicacin: q: Obtener la clave y el nombre de los proveedores de cada ciudad. Se tendrn los siguientes predicados simples: P1 = {cveciudad = "SF" } P2 = { cveciudad = "LA" } P3 = { cveciudad = "SD" } Dando como resultado los siguientes predicados miniterminos, los cuales se obtienen de las combinaciones de los predicados simples: m1 = {SF ^ LA ^ SD} m2 = {SF ^ ~LA ^ SD} m3 = {SF ^ ~LA ^ ~SD} .. M6 = {~SF ^ ~LA ^ ~SD} .. M7 = {~SF ^ LA ^ ~SD} M8 = {~SF ^ ~LA ^ SD} contradictorio contradictorio contradictorio

Bases de Datos Distribuidas

37

Fundamentos de las Bases de Datos Distribuidas

Eliminando los miniterminos contradictorios se obtiene el siguiente resultado, donde cada uno de estos miniterminos representa un fragmento de la relacin global: M3 = {SF ^ ~LA ^ ~SD} M7 = {~SF ^ LA ^ ~SD} M8 = {~SF ^ ~LA ^ SD} Entonces la fragmentacin horizontal estara dada de la siguiente forma:

Proveedor1 = SL cveciudad = SF Proveedor Select pclave, nombre, cveCiudad into Proveedor1 from Proveedor Where cveCiudad = SF
Pclave Nombre P01 John Smith P04 Steven Freeman Cveciudad SF SF

Proveedor2 = SL cveciudad = LA Proveedor Select pclave, nombre, cveCiudad into Proveedor2 from Proveedor Where cveCiudad = LA
Pclave Nombre P02 Jos Sanchz P03 Juan Prez Cveciudad LA LA

Proveedor3 = SL cveciudad = SD Proveedor Select pclave, nombre, cveCiudad into Proveedor3 from Proveedor Where cveCiudad = SD
Pclave Nombre P05 Alex P06 Tere Cveciudad SD SD

Bases de Datos Distribuidas

38

Fundamentos de las Bases de Datos Distribuidas

Las condiciones anteriores cumpliran con la definicin de fragmentacin, si los nicos valores posibles para el atributo Cveciudad fueran "SF", "LA" y SD; de otro modo no se sabra a que fragmento corresponden las tuplas que contengan otro valor. La reconstruccin de la Tabla global Proveedor se logra fcilmente, por medio de la siguiente condicin: Proveedor = Proveedor1 UN Proveedor2 UN Proveedor3 Create View ReconstruccionProveedor As Select * from Proveedor1 Union All Select * from Proveedor2 Union All Select * from Proveedor3 La reconstruccin de la relacin global siempre se lleva a cabo, por medio de la operacin de unin.

2.2.5 Fragmentacin horizontal derivada En algunas ocasiones, la fragmentacin horizontal de una tabla no se puede basar en alguna propiedad de sus propios atributos, pero se deriva de la fragmentacin horizontal de otra tabla. Considrese el siguiente ejemplo: Pedido(pclave, cveProducto, cant) Pclave P01 P01 P02 P03 P04 P04 cveProducto 2325 2547 3298 7895 741 0 2589 Cant 123 21 98 87 53 10

Bases de Datos Distribuidas

39

Fundamentos de las Bases de Datos Distribuidas

Donde pclave es la clave del proveedor. Esto es significativo para la particin de esta relacin ya que un fragmento contiene las tuplas para los proveedores con los cuales se obtiene la cveciudad. No obstante que cveciudad no es un atributo de la tabla Pedido, sino que es un atributo de la tabla Proveedor. Por lo tanto, se necesita una operacin de semi-join para determinar las tuplas de Pedido que corresponden con los proveedores en cierta cveciudad. Esto se logra de la siguiente manera:

Pedido1 = Pedido SJ pclave = pclave Proveedor1


Select A.* into Pedido1 From Pedido A Inner Join Proveedor1 B on (A.pclave=B.pclave)

Pclave P01 P01 P04 P04

Pnum 2325 2547 7410 2589

Depto Compras Compras Ventas Sistemas

Cant 123 21 53 10

Pedido2 = Pedido SJ pclave = pclave Proveedor2


Select A.* into Pedido2 From Pedido A Inner Join Proveedor2 B on (A.pclave=B.pclave)

Pclave P02 P03

Pnum 3298 7895

Depto Ventas Finanzas

Cant 98 87

Pedido3 = Pedido SJ pclave = pclave Proveedor3


Select A.* into Pedido3 From Pedido A Inner Join Proveedor3 B on (A.pclave=B.pclave)

El efecto de la operacin semi-join nos permite seleccionar de Pedido las tuplas que satisfacen la condicin de unin entre Proveedor1, o Proveedor2, o Proveedor3 y Pedido, de esta manera se determinaran aqullas tuplas de la Table Pedido que hacen referencia a proveedores en San Francisco, Los ngeles o San Diego, respectivamente. La reconstruccin de la Table global Pedido puede lograrse por medio de una operacin de unin como en el caso de la table Proveedor.

Bases de Datos Distribuidas

40

Fundamentos de las Bases de Datos Distribuidas

La integridad de un fragmento requiere que no existan claves de proveedores en la Table Pedido, los cuales no estn dentro de la tabla Proveedor. Esto es una restriccin tpica dentro de las bases de datos conocida como integridad referencial. 2.2.6 Fragmentacin vertical La fragmentacin vertical de una tabla global es la subdivisin de sus atributos en grupos, los fragmentos son obtenidos al proyectar la tabla global sobre cada grupo. La fragmentacin es correcta si cada atributo es mapeado por lo menos con un atributo de los dems fragmentos; por otra parte, es posible reconstruir la tabla original por medio de uniones de todos los fragmentos a la vez. Considrese el siguiente ejemplo: Emp(Cvemp, Nom, Sal, lmp, Depto)

Cvemp E12 E56 E78 E98 E32 Egl E73

Nom Juan Prez Jos Hernndez Luis Prez Maria SolsJohn Smith Rocio Snchez Carmen Campos

Sal 4500 756 9254 2345 5489 4600 753

Imp 15 15 15 25 2-5 15 15

Depto 15 9 17 22 22 8 15

Considrese las siguientes aplicaciones: q1: Obtener el nombre y departamento de todos los empleados q2: Obtener el clave, salado y tasa de impuestos por departamento q3: Obtener la clave, nombre y departamento de los empleados con salado mayor a 10,000 Se tiene la siguiente matriz de accesos: Total de S1 q1 q2 q3 2 2 1 S2 3 1 2 S3 2 2 1 accesos 7 5 4

Bases de Datos Distribuidas

41

Fundamentos de las Bases de Datos Distribuidas

Las aplicaciones se traduciran de la manera siguiente: q1= Select nom, depto From empleados q2= Select cvemp, sal, imp From empleados Where depto = X q3= Select cvemp, nom, depto From empleados Where sal > 10000 Con esto se podr obtener la matriz de uso, en la cual se colocara, de acuerdo con los atributos accesados en cada una de las aplicaciones, colocando en cada casilla un 1 si el atributo A es reverenciado en la aplicacin qj. A1 (cvemp) q1 q2 q3 0 1 1 A2 (nom) 1 0 1 A3 (sal) 0 1 1 A4 (imp) 0 1 0 A5 (depto) 1 1 1

Ahora se construir la matriz de afinidad, la cual se obtiene por medio de la siguiente formula aff(Ai,Aj) = todas las consultas que accesan A y Aj (accesos en consultas) accesos en consulta = todos los sitios frecuencia de accesos de una consulta aff(A1, A1)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A1, A2)= (1+2+1)(1) = 4 aff(A1, A3)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A1, A4)= (2 +1+2)(1) = 5 aff(A1, A5)= (2+1+2)(1) + (1+2+1)(1) = 9 aff(A2, A1)= (1 +2+ 1)(1) = 4

Bases de Datos Distribuidas

42

Fundamentos de las Bases de Datos Distribuidas

aff(A2, A2)= (2+3+2)(1) + (1+2+ 1)(1) = 11 aff(A2, A3)= (1+2+1)(1) = 4 aff(A2, A4)= 0 aff(A2, A5)= (2+3+2)(1) + (1 +2+ 1)(1) = 11

A1 Al A2 A3 A4 A5 9 4 9 5 9

A2 4 11 4 0 11

A3 9 4 9 5 9

A4 5 0 5 5 5

A5 9 11 9 5 16

En la diagonal debern aparecer los valores ms altos de cada columna, de no ser as, ser necesario reordenar dichas columnas para logrado. El paso restante ser seleccionar los campos necesarios para cada fragmento, esto, de acuerdo al orden en que las columnas se encuentran en la tabla. Emp= {A1, A2, A3, A4, A5} Emp1 { A1, A2), Emp2= { A1, A3, A4, A5) Emp1 = PJcvemp, Nom, Emp Emp2 = PJCemp, Sal, Imp, Emp1(Cvemp, Nom) Emp2(Cvemp, Sal, lmp, Depto)
Depto

Emp

o en otro caso Emp1= { A1, A2, A3} Emp2= { A1, A4, A5}

Bases de Datos Distribuidas

43

Fundamentos de las Bases de Datos Distribuidas

Emp1 = PJcvemp, Nom, Depto Emp Emp2 = PJCemp, Sal, Imp Emp Emp1(Cvemp, Nom, Sal) Emp2(Cvemp, Imp, Depto)

El atributo A1 aparece en ambos fragmentos debido a que es la llave primaria de la relacin global. La manera de seleccionar que atributos iran en cada fragmento depende de las necesidades del sistema. La reconstruccin de la relacin Emp se puede obtener por medio de: Emp = Emp1 JNcvemp = cvemp Emp2 Esto dado que Cvemp es la llave de la relacin global Emp. En general, la inclusin de la llave de la relacin en cada uno de los fragmentos es lo que hace posible la reconstruccin por medio de la operacin de join.

2.2.7 Fragmentacin mixta Los fragmentos son obtenidos por medio de las operaciones de fragmentacin, que pueden relacionarse precedentemente, es posible aplicar la operacin de fragmentacin (vertical y horizontal) de manera recursiva, dando como resultado las condiciones necesarias para la fragmentacin. La reconstruccin se logra aplicando las reglas de reconstruccin en orden inverso de acuerdo a la fragmentacin.

Bases de Datos Distribuidas

44

Fundamentos de las Bases de Datos Distribuidas

Para realizar la fragmentacin mixta se deber considerar la necesidad de informacin de cada uno de los sitios dentro de la base de datos distribuida, esto es considrese la siguiente tabla: Emp(Cvemp, Nom, Sal, lmp, Depto) Se tiene un sitio en el departamento fiscal el cual se encarga del clculo de los impuestos, y tres sitios ms, uno por cada uno de los tres departamentos restantes dentro de la empresa. Para el departamento fiscal, el nombre y el departamento del trabajador no son relevantes, necesitando nicamente los campos de clave del empleado, salario y tasa de impuesto. Por tanto, es conveniente realizar una fragmentacin vertical para obtener un fragmento con los campos necesarios (cvemp, sal y imp) para este departamento. El resto de la tabla global podra fragmentarse horizontalmente de acuerdo a cada departamento, obteniendo tres tablas, las cuales se situaran en cada uno de los tres sitios restantes dentro del sistema distribuido. Por medio de las siguientes operaciones se realizar una fragmentacin mixta, donde se aplica la fragmentacin vertical, seguida por una fragmentacin horizontal por Depto: Vertical Emp1 = PJcvemp, Sal. Imp Emp Select Horizontal Depto10 = SLdepto=10 PJ Cvemp, Nom, Select cvemp, nom, depto
Depto

cvemp, Sal, Imp

Into Emp1 Emp

From Emp

Into Depto10 from Emp Emp

Where depto=10

Depto20 = SLdepto=20 PJ Cvemp, Nom, Select cvemp, nom, depto

Depto

Into Depto20 from Emp Emp

Where depto=20

Depto30 = SLdepto=30 PJ Cvemp, Nom, Select cvemp, nom, depto

Depto

Into Depto30 from Emp

Where depto=30

La reconstruccin de la tabla Emp se define de la siguiente forma:

Bases de Datos Distribuidas

45

Fundamentos de las Bases de Datos Distribuidas

Emp = UN(Depto10, Depto20, Depto30) JNCvemp = Cvemp PJCvemp, Sal, Imp Emp1 Reconstruccion Horizontal Create View ReconstruccionHorizontal As Select * from Depto10 Union All Select * from Depto20 Union All Select * From Depto30

Reconstruccion Vertical Create View ReconstruccionVertical as Select A.cvemp, nom, imp, depto From ReconstruccionHorizontal A (A.cvemp=B.cvemp) inner join Emp1 B On

La fragmentacin mixta se representa generalmente por medio de un rbol de fragmentacin. En el rbol de fragmentacin, la raz corresponde a la tabla global, las hojas corresponden a los fragmentos, y los nodos intermedios corresponden a los fragmentos intermedios, resultantes de las operaciones. A continuacin se presenta el rbol de distribucin del ejemplo anterior: Emp Emp1

V
Depto10

H Depto20

Depto30

Bases de Datos Distribuidas

46

Fundamentos de las Bases de Datos Distribuidas

Es importante tomar en cuenta que el orden en el cual se realiza la fragmentacin horizontal y vertical afecta a la fragmentacin final.

fragmentacin vertical seguida de fragmentacin horizontal

fragmentacin horizontal seguida de fragmentacin vertical 2.2.8 Distribucin de los fragmentos La manera ms fcil para realizar la distribucin de los fragmentos es considerar cada fragmento como un archivo separado; sin embargo, este enfoque no es conveniente, por las siguientes razones: 1 . Los fragmentos no son modelados propiamente como archivos individuales, ya que de esta manera no se podra tomar en cuenta el hecho, de que tienen la misma estructura. 2. Hay muchos ms fragmentos que relaciones globales, y muchos modelos analticos no pueden procesar la solucin de problemas que involucran demasiadas variables. 3. El modelado del comportamiento de las aplicaciones en sistema de archivos es muy simple (tpicamente, las aplicaciones hacen un "acceso remoto a archivos"), mientras que en aplicaciones de bases de datos distribuidas pueden hacer un uso ms complejo de los datos. Algunos de estos problemas no tienen una solucin satisfactoria; por ejemplo el punto 3 es particularmente difcil, puesto que el correcto enfoque permitira evaluar la distribucin de los datos mediante cmo las aplicaciones pueden optimizar el acceso.

Bases de Datos Distribuidas

47

Fundamentos de las Bases de Datos Distribuidas

2.2.9

Criterios generales para la distribucin de fragmentos. En la distribucin de los fragmentos, es importante distinguir entre si se va a

disear una distribucin redundante o no redundante. La replicacin introduce una amplia complejidad en el diseo, porque: 1. El grado de replicacin de cada fragmento llega a ser una variable del problema. 1. El diseo de los mdulos de lectura en las aplicaciones es complicado por el hecho que las aplicaciones deben de seleccionar entre varios sitios alternativos, en cual accesarn el mismo fragmento replicado en estos sitios. Para determinar la redundancia en la distribucin de fragmentos, cualquiera de los dos mtodos siguientes puede ser utilizado: 1 . Determinar el conjunto de todos los sitios donde el beneficio de colocar una copia del fragmento es mayor que el costo, y colocar un fragmento en cada uno de los sitios de este conjunto; este mtodo selecciona "todos los sitios benficos'. 2. Determinar primero la solucin del problema sin rplica, y posteriormente introducir rplicas iniciando por las ms benficas; el proceso termina cuando una 'rplica adicional' no es benfica. Ambos mtodos tienen algunas desventajas. En el caso del mtodo de "los sitios benficos, el hecho de cuantificar el costo y el beneficio para cada fragmento es ms crtico que en el caso no redundante. El mtodo de "la rplica adicional' es un tpico enfoque heurstica; con este mtodo, es posible tomar en cuenta que el incremento en el grado de redundancia es cada vez menos benfico. fragmento. La disponibilidad y la confiabilidad del sistema se ve incrementado si se tienen dos o tres copias de un

2.3 Procesamiento de consultas distribuidas

Bases de Datos Distribuidas

48

Fundamentos de las Bases de Datos Distribuidas

2.3.1 rbol de operadores de una consulta Una manera de representar la secuencia en que se realizarn las operaciones de una consulta, es un rbol de operadores. Considrese la siguiente consulta: PJSNUM SL rea = Norte (Prevee JNNumdepto = Numdepto Depto Un ejemplo de un rbol de operadores para la consulta sera el que aparece en la figura siguiente. Obsrvese que las hojas del rbol son relaciones globales y cada nodo representa una operacin binaria o unitaria. Un rbol define un orden parcial en como las operaciones deben ser aplicadas para obtener el resultado deseado en la consulta, esto es, de abajo hacia arriba. -correspondera equivalente. un rbol tambin Un orden diferente de operaciones obteniendo una transformacin diferente,

PJSNUM

SLAREA="Norte"

JNNumdepto=Numdepto

PROVEE

DEPTO

El rbol de operadores de una expresin de lgebra relaciona] puede verse como un rbol gramatical, asumiendo la siguiente forma: R -> identificador R -> ( R ) R -> op_uni R

Bases de Datos Distribuidas

49

Fundamentos de las Bases de Datos Distribuidas

R -> R

op_bin R

op_uni -> SLF | PJA op_bin CP | UN | DF | JNF | NJNF | SJF | NSJF

2.3.2 Ejemplos de consultas distribuidas Supngase una universidad, que cuenta con las carreras de derecho, contadura y administracin- Dicha universidad tiene una base de datos distribuida con fragmentos en cada uno de los departamentos concernientes a cada carrera de la manera siguiente: Tabla global

Alumnos(no-control, nombre, domicilio, ciudad, edad, especialidad)

No-control D12 A32 C54 C78 A29 D90 D73 A99 C34

nombre Pedro H. Jos L. Juan J. Mario V. Adolfo A Adriana A Sandra F. Carmen G. Rocio S.

Domicilio Hidalgo 100 Morelos 23-4 Revolucin 987 A. L. Mateos 2345 Jurez 199 Guerrero 987 Revolucin 200 A. 1. Mateos 234 Guerrero 987

ciudad Celaya Salamanca Irapuato Celaya Celaya Irapuato Salamanca Celaya Celaya

edad 1-9 20 21 21 21 21 20 19 20

especialidad derecho Administracin Contadura contadura administracin derecho derecho administracin contadura

Debido a que cada departamento requiere tener la informacin de sus alumnos, se realizara una fragmentacin horizontal utilizando la siguiente aplicacin: Q: Seleccionar el nmero de control, nombre, domicilio, ciudad, edad, especialidad

para los alumnos de cada rea.

Bases de Datos Distribuidas

50

Fundamentos de las Bases de Datos Distribuidas

Esto dara como resultado los siguientes tres fragmentos horizontales: Alumnos1 = SLespecialidad = No-control D12 D90 D73 nombre Pedro H. Adriana A. Sandra F. domicilio Hidalgo 100 Guerrero 987 Revolucin Alumnos Edad 19 21 20 Especialidad Derecho Derecho Derecho

derecho

ciudad Celaya Irapuato Salamanca

Alumnos2 = SL especialidad = No-control C54 C78 C34 Nombre Juan J. Mario V. Roci S.

contadura

Alumnos ciudad Irapuato Celaya Celaya edad 21 2-1 2-0 especialidad contadura contadura contadura

domicilio Revolucin 987 A. L. Mateos 2345 Guerrero 987

Alumnos3 = SL especialidad =

administracin

Alumnos

No-control A32 A29 A99

Nombre domicilio ciudad Jos L. Morelos 234 Salamanca Adolfo A Jurez 199 Celaya Carmen G. A. L. Mateos 234 Celaya

edad 20 21 19

especialidad administracin administracin administracin

Como se puede observar cada departamento es un sitio dentro de nuestra base de datos distribuida, conteniendo un fragmento horizontal de la tabla global de acuerdo a la especialidad. Considrese, que se requiere una consulta en el departamento de administracin en la cual se deben de obtener el nombre y domicilio de los alumnos de la carrera de administracin que viven en la ciudad de Celaya, dicha consulta no tendra mayor complicacin para el sistema de bases de datos, dado que el proceso se realizara de manera local en el sitio de administracin.

Bases de Datos Distribuidas

51

Fundamentos de las Bases de Datos Distribuidas

Por lo tanto el DBMS local deber detectar que el procesamiento de la consulta se debe de realizar sobre los datos locales y, que no hay necesidad de efectuar consultas en otros sitios, esto seria como sigue: PJ nombre, domicilio SL especialidad = administracin AND ciudad = "Celaya Alumnos La cual sea traducida por el DBMS local, en el departamento de administracin a: PJ nombre, domicilio SL ciudad = "Celaya Alumnos3

nombre Adolfo A. Carmen G.

Domicilio Jurez 199 A. L. Mateos 234

Ahora supngase el caso de que el departamento de contabilidad requiere el nombre, nmero de control y especialidad de los alumnos que tienen 21 aos o ms. Esta consulta involucro a todos los fragmentos que se encuentran distribuidos en el sistema. La consulta global sera de la siguiente manera: PJ no-control, nombre, especialidad SL edad>=21 Alumnos

La cual se traducira en el sistema distribuido de la siguiente manera: PJ no-control, nombre, especialidad SL edad>=21 (Alumnos1 UN Alumnos2 UN Alumnos3) no control C54 C78 A29 D90 nombre Juan J. Mario V. dolfo A. Adriana A. especialidad contadura contadura administracin derecho

Bases de Datos Distribuidas

52

Fundamentos de las Bases de Datos Distribuidas

En la consulta es necesario realizar una unin entre los tres fragmentos existentes para reconstruir la relacin global y as poder ejecutar la seleccin sobre totalidad de las tuplas existentes en al base de datos. El rbol de operaciones quedara de esta manera:

PJNO CONTROL, NOMBRE.

ESPECIALIDAD

SLEDAD >= 21

UN ALUMNOS1 ALUMNOS2 ALUMNOS3

En este punto se debe de considerar un aspecto muy importante en el procesamiento de las consultas, sta no es la nica forma de realizar la consulta. Existen varias formas de realizar la misma consulta, esto es, se podra variar el orden de ejecucin de las operaciones o reemplazarlas por un conjunto de operaciones equivalentes. Por ejemplo el siguiente rbol arroja el mismo resultado que el anterior: PJNO CONTROL, NOMBRE.

ESPECIALIDAD

UN SLEDAD >= 21 ALUMNOS1 SLEDAD >= 21 ALUMNOS2 SLEDAD >= 21 ALUMNOS3

Bases de Datos Distribuidas

53

Fundamentos de las Bases de Datos Distribuidas

La diferencia que existe entre este rbol y el anterior no radica en el resultado de las operaciones, sino en el costo de la ejecucin de las mismas. Es decir en el rbol anterior los fragmentos eran transmitidos ntegramente a un sitio, por lo general es el sitio que lanz la consulta, y en l se realizan todas las operaciones. En este punto se debe de consideras el costo de la transmisin de los fragmentos y el costa en la ejecucin de cada una de las operaciones dentro del sitio. En el caso del segundo rbol, el costo de transmisin se reduce considerablemente al transmitir nicamente los datos del fragmento que cumplen con la condicin del select, y el costo de la ejecucin de las operaciones se distribuye en cada uno de los sitios de la base de datos distribuida, ya que el select se realizara de manera local en cada uno de los sitios, y la proyeccin, as como la unin, se realizaran en el sitio que lanz la consulta. Considrese ahora otro rbol de operaciones, en el cual se puede observar que la mayor parte del proceso se realiza en los sitios y se deja al sitio que lanz la consulta nicamente el trabajo de buscar en su fragmento y unir todos los datos que le sean enviados por cada uno de los otros sitios. Obsrvese tambin que el costo de transmisin se reduce considerablemente ya que no solo se envan nicamente los dato que cumplen con la condicin del select, sino que tambin se reduce el nmero de atributos de la relacin que se envan ( no se estaran enviando los atributos de domicilio, ciudad y edad).

UN

PJno_CONTROL,
NOMBRE, ESPECIALIDAD

PJno_CONTROL,
NOMBRE, ESPECIALIDAD

PJno_CONTROL,
NOMBRE, ESPECIALIDAD

SLEDAD >= 21

SLEDAD >= 21

SLEDAD >= 21

ALUMNOS1

ALUMNOS2

ALUMNOS3

Bases de Datos Distribuidas

54

Fundamentos de las Bases de Datos Distribuidas

An cuando se tienen menos operaciones que realizar en el sitio que lanz la consulta, se debe de considerar que se est generando una carga de trabajo para los dems sitios, los cuales, posiblemente estn ejecutando sus propias consultas. Por lo tanto, en el diseo de consultas se debe de considerar los costos en la ejecucin de las operaciones, tanto locales como las que se ejecutarn en otros sitios, esto quiere decir que, si existen sitios con mucha mayor potencia de computo que el sitio en el cual se gener la consulta, y existe poca carga de trabajo en estos sitios, convendr ms, que la mayor parte de las operaciones se realicen en dichos sitios y no en el que gener la consultaTambin se debe considerar el que posiblemente sea el costo ms importante en una base de datos distribuida, el costo de la transmisin de los datos entre sitios, esto dado que, los costos de transmisin son mucho mayores al transmitir dentro de una red WAN, en la que tal vez se involucren transmisiones va telefnica o va satlite, que entre sitios de una red LAN, la cual involucro transmisiones por medio de cables que interconectan directamente los sitios.

Bases de Datos Distribuidas

55

Fundamentos de las Bases de Datos Distribuidas

2.4 Resumen
El diseo de una base de datos distribuida requiere de una planeacin de las tcnicas y de la organizacin de dicha base de datos, esto, en cuanto al diseo de los mltiples sitios. Los problemas principales seran la interconexin de los diferentes sitios, as como la distribucin de los datos en dichos sitios. El diseo de una base de datos distribuida consiste en: 1. 2. 3. 4. Disear el esquema conceptual. Disear el esquema fsico. Disear la fragmentacin de los datos. Disear la distribucin de los fragmentos. Existen varios objetivos que una base de datos distribuida deber de lograr: Procesamiento local: Debido a que los datos son colocados donde se necesitan, el procesamiento local aumenta. Disponibilidad y confiabilidad de los datos distribuidos: El almacenamiento de mltiples copias en el sistema permite que las aplicaciones utilicen a cualquier otra copia cuando la copia que era accesada normalmente no est disponible. Distribucin de la carga de trabajo: La distribucin de la carga de trabajo se da a la par de la distribucin de los datos y esto permite que exista un alto grado de paralelismo en la ejecucin de las aplicaciones. Disponibilidad y costo del almacenamiento: la distribucin de las bases de datos refleja una reduccin en el costo del almacenamiento en los sitios. Existen dos tcnicas de diseo de bases de datos distribuidas: La tcnica topdown y la tcnica bottom-up. En la tcnica top-down se inicia diseando el esquema global y

Bases de Datos Distribuidas

56

Fundamentos de las Bases de Datos Distribuidas

la fragmentacin de los datos, continuando con la distribucin de los fragmentos en los diferentes sitios, esta tcnica es utilizada cuando no existe base de datos alguna. Cuando una base de datos distribuida se va a agregar a una base de datos ya existente, la tcnica que se utiliza es bottom-top. Esta tcnica consiste en: 1. 2. 3. La seleccin del modelo de datos, para el diseo del esquema global de la base de datos. La traduccin de cada esquema local a un modelo de datos comn. La integracin de los esquemas locales en el esquema global comn.

La fragmentacin permite determinar cuales sern las unidades lgicas de distribucin. Las tuplas y atributos de la relacin por si mismos, no podrn ser El diseo de los fragmentos considerados como unidades lgicas de distribucin.

consiste en agrupar tuplas y atributos que tengan las mismas propiedades lgicas. Existen dos tipos bsicos de fragmentacin, la horizontal y la vertical, existe un tercer mtodo de fragmentacin, el cual es la combinacin de los dos anteriores. La fragmentacin horizontal consiste en dividir las tuplas de la relacin global en subconjuntos de tuplas, donde cada subconjunto puede contener datos con propiedades geogrficamente comunes. La fragmentacin se realiza, por lo general por medios de una operacin select, mientras que la reconstruccin de la relacin global siempre se llevara a cabo por medio de una operacin de union. Existe un subtipo de fragmentacin horizontal conocida como fragmentacin horizontal derivada, esta consiste en la fragmentacin de una relacin que no se puede basar en sus propios atributos, pero se deriva de la fragmentacin de otra relacin. La fragmentacin vertical de una relacin global es la subdivisin de sus atributos en grupos; la fragmentacin se obtiene al proyectar la relacin global sobre cada grupo. La reconstruccin de la relacin global se obtiene por medio de la operacin join. El tercer tipo de fragmentacin es la mixta, esta es obtenida por medio de operaciones de fragmentacin realizadas de manera recursiva, y la reconstruccin se realizara aplicando las operaciones respectivas en orden inverso de acuerdo a la fragmentacin.

Bases de Datos Distribuidas

57

Fundamentos de las Bases de Datos Distribuidas

Despus de que se ha realizado la fragmentacin de los datos, es necesario analizar la forma en como se distribuirn dichos fragmentos, la manera ms fcil de realizar esta operacin seria considerar cada fragmento como archivos separados, pero este enfoque no es conveniente, por las siguientes razones: 1. 2. 3. Los fragmentos no son modelados propiamente como archivos individuales. Habra ms fragmentos que relaciones globales, y seria difcil procesar la solucin del problema al involucrar demasiadas variables. El modelado del comportamiento de las aplicaciones en sistemas de archivos difiere en demasa con relacin a las aplicaciones de bases de datos. En la distribucin de los fragmentos es importante decidir si se va disear una distribucin redundante o no redundante. complejidad en el diseo, porque: 1. 2. El grado de replicacin de cada fragmento llega a ser una variable del problema. El diseo de los mdulos de lectura de las aplicaciones es complicado por el hecho de que las aplicaciones deben de seleccionar entre varios sitios para el acceso del mismo fragmento. Existen dos mtodos para determinar la redundancia en la distribucin de fragmentos: Determinar el conjunto de todos los sitios donde el beneficio de colocar una copia del fragmento es mayor que el costo, y colocar un fragmento en cada uno de los sitios de este conjunto. Determinar primero la solucin sin replica del problema, y posteriormente introducir replicas iniciando por las ms benficas; este proceso termina cuando una replica no es benfica. En el anlisis del procesamiento de consultas distribuidas, existe una herramienta muy til llamada rbol de operadores, este rbol representa la secuencia en que se realizan las operaciones de una consulta, en este rbol, las hojas son las relaciones globales y cada nodo representa una operacin binaria o unitaria. Un rbol define un La replicacin introduce una amplia

Bases de Datos Distribuidas

58

Fundamentos de las Bases de Datos Distribuidas

orden parcial en como las operaciones se deben de aplicar para obtener el resultado deseado en la consulta, esto es de abajo hacia arriba.

2.5 1.2.3.4.5.2.6

Preguntas de repaso Cuales son los cuatro pasos en el diseo de una base de datos distribuida? Mencione y describa los objetivos del diseo de datos distribuidos. Cundo es conveniente utilizar la tcnica bottom-up para disear una base de datos distribuida? Explique brevemente en que consiste cada uno de los tipos de fragmentacin que existen. Que representa y que partes conforman a un rbol de operadores? Ejercicios

1.- Usando la tabla de clientes, realizar una fragmentacin horizontal, si las aplicaciones son las siguientes: q1: q2: q3: Obtener los nombres de todos los clientes. Obtener el nmero del cliente por estado. Obtener el nombre del cliente por empresa.
No_cli C01 C02 C03 C04 C05 C06 Nom_cli Jurez Vidal vila Meja Herrera Cervantes Empresa Gamesa Lara Gamesa Lara Lara Gamesa Estado Gto Qro Jal Jal Gto Qro

2.-

Fragmentar horizontalmente la siguiente base de datos. Clientes


No_cli C01 C02 C03 C04 C05 C06 Nom_cli vila Soria Avalos Medina Trajo vila Edo Gto Gto Qro Mich Qro No_p P1 P2 P3 P4 P5 P6

Productos
Nom_p Lpiz Libreta Lapicero Borrador Escuadra Plumones Precio 1.20 3.50 3.20 1.50 3.10 15.20

Bases de Datos Distribuidas

59

Fundamentos de las Bases de Datos Distribuidas

Compras No_cli C02 C01 C02 C01 C03 C03 Nom_cli Pl P3 P4 P5 P1 P5 Cant 2 1 2 2 2 3

q1: q2: q3:

Obtener el nmero del cliente por estado. Obtener el nmero y nombre de los clientes del estado de Jalisco. Obtener el estado de los clientes cuyo nombre sea vila,

3.Usando la tabla de dientes, realizar una fragmentacin vertical, si las aplicaciones son las siguientes: q1: Obtener los nombres de todos los clientes. q2: Obtener el nmero y nombre de los clientes por estado. q3: Obtener el nombre de los clientes por empresa. Matriz de accesos S1 q1 q2 q3 4.3 2 1 S2 2 1 1

Fragmentar verticalmente la siguiente tabla A1 No_al AL1 AL2 AL3 AL4 A2 Nom_al Aguilar Jimnez Trejo Soria Edad 19 18 18 20 A3 A4 Dir Rev. 115 Hgo. 120 Rev. 315 Hgo. 422 A5 Ciudad Celaya Irapuato Celaya Len A6 Sem 3 1 1 4 A7 Esp Qumica Electrnica Sistemas Qumica A8 Prom 85.7 83.2 75.2 89.7

q1: Obtener el nmero de alumno por especialidad. q2: Obtener nmero y nombre del alumno por ciudad. q3: Obtener el nombre y edad por promedio. q4: Obtener el nmero y semestre del alumno por direccin.

Matriz de accesos. S1 q1 3 S2 1 S3 1

Bases de Datos Distribuidas

60

Fundamentos de las Bases de Datos Distribuidas

q2 q3 q4

2 2 3

0 1 5

1 2 1

Bibliografa
[1] Ceri, Stefano. Pelaggati, Giuseppe; 'Distributed Databases Principles and systems'; lntemational Edition; MeGraw-Hill; U.S.A.; 1985 [2] Date, C,J.; "An Introduction to Databases Systems"; Volume 1; Fifth Edition; Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1990 [3] Date, C.J.; "An lntroduction to Databases Systems"; Volume li; Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1995

Bases de Datos Distribuidas

61

Fundamentos de las Bases de Datos Distribuidas

Captulo III

Optimizacin de estrategias de accesos


Objetivo
El alumno comprender el concepto optimizacin de consultas distribuidas y entender las tcnicas para la ejecucin de la operacin join.

Introduccin
En este captulo se analizar el hecho de que an cuando se cuente con una buena estrategia de fragmentacin o un buen procesamiento de consultas, no implica que se tenga un funcionamiento correcto del sistema. Adems se tratara el concepto de optimizacin de consultas, lo cual implica reducidas a una forma equivalente ms pequea y fcil de manejar para el sistema, esto es, a su forma cannica. Tambin se analizaran los diferentes mtodos de ejecucin de la operacin Join.

3.1 Importancia de la optimizacin de consultas


El trmino optimizacin es algo inapropiado, puesto que las' tcnicas para optimizar la ejecucin de una consulta generalmente no lo logran y nicamente se obtienen estrategias para un "buen acceso. Por eso, al referirse a este hecho como optimizacin se debe de ser muy cuidadoso.

Bases de Datos Distribuidas

62

Fundamentos de las Bases de Datos Distribuidas

El desarrollo de una estrategia "buena" en el procesamiento de una consulta es necesaria en un ambiente distribuido, pero tambin pueden existir estrategias para el procesamiento de consultas "muy malas', las cuales se deben evitar. De esta manera, la eficiencia del sistema final depende en mucho de la calidad del optimizador de consultas, de la ausencia de un optimizador, y en la habilidad del programador de las aplicaciones. Puntos para estrategia de consultas. 1. La seleccin de estrategias alternativas para la ejecucin de las consultas, tanto en ambientes centralizados como distribuidos, es hecha de acuerdo al desempeo requerido. 2. Las medidas tpicas asumidas en un sistema centralizado de bases de datos son el nmero de operaciones I/O y el tiempo de uso del CPU requerido para realizar las consultas. 3. En bases de datos distribuidas de debe considerar adems, el costo de la transmisin de datos entre los sitios participantes de la consulta. No obstante, no existe ningn convenio en la importancia relativa del costo de transmisin contra I/O local. A pesar de esto, se deber de encontrar la sentencia que minimice el costo de transmisin, lo cual es nuestra meta ms importante. La seleccin de una estrategia de procesamiento de consultas involucro: 1 . Determinar las copias fsicas de los fragmentos sobre los cuales se ejecutar la consulta, obteniendo una expresin de consulta sobre fragmentos.. 2. Seleccionar el orden de ejecucin de las operaciones; como se puede ver, esto involucro la determinacin de una buena secuencia de operaciones join, semijoin y unin. 3. Seleccionar el mtodo para la ejecucin de cada operacin; esto involucro el cambio de ejecucin de algunas operaciones algebraicas. Los problemas anteriores no son independientes, por ejemplo, la eleccin de la mejor materializacin para una consulta depende del orden en el cual son ejecutadas las operaciones; por lo tanto, utilizar procedimientos para resolverlos de manera independiente producira errores. No obstante, una manera fcil de obtener mtodos

Bases de Datos Distribuidas

63

Fundamentos de las Bases de Datos Distribuidas

de optimizacin consiste exactamente en considerar estos problemas como independientes; de esta manera: 1. Una consulta dada se ejecuta sobre una sola copia no redundante de la base de datos distribuida.

2. El orden de ejecucin de las operaciones es ptima.


3. Las operaciones son agrupadas en los programas locales. En la prctica, el primer problema no es tomado en cuenta, el tercer problema es despreciable; por lo tanto solo se hace nfasis en el segundo problema.

3.2 Transformaciones equivalentes


Una consulta relacional puede expresarse utilizando diferentes lenguajes, para fines de estudio, se utilizar lgebra relacionar y SQL, esto debido a que es posible transformar una consulta SQL en expresiones equivalentes de lgebra relacional y viceversa. Adems, no solo se pude interpretar una expresin de lgebra relacional por sus especificaciones semnticas de una consulta, sino que adems se deber de tomar en cuanta la secuencia de las operaciones. Desde este punto de vista, dos expresiones con la misma semntica pueden describirse por medio de dos secuencias de operaciones diferentes. Por ejemplo, considrese la siguiente relacin:

Emp(Cvemp, Nom, Sal, Imp, Depto)

Cvemp E12 E56 E78 E98 E32 E91 E73

Nom Juan Prez Jos Hernndez Luis Prez Maria Sols John Smith Roci Snchez Carmen Campos

Sal 4500 8756 9254 12345 25489 4600 8753

Imp 15 15 15 25 25 15 15

Depto 15 9 17 22 22 8 15

Se tiene las siguientes consultas:

Bases de Datos Distribuidas

64

Fundamentos de las Bases de Datos Distribuidas

Select Nom, Depto From Emp Where Depto = 15 PJ Nom, depto SL depto=15 Emp Nom Juan Prez Carmen Campos y SL depto = 15 PJ Nom, depto Emp Nom Juan Prez Carmen Campos Depto 15 15 Depto 15 15

Son dos expresiones equivalentes, las cuales arrojan el mismo resultado, pero definidas por dos secuencias de operadores diferentes.

Transformaciones equivalentes por lgebra relacional Dos relaciones son equivalentes cuando sus tuplas representan el mismo mapeo de los atributos a los valores, incluso si el orden de los atributos es diferente. Considrense dos expresiones E1 y E2 de lgebra relacional, la equivalencia de dos expresiones se representa E1 E2. Se podrn obtener transformaciones equivalentes sistemticamente ms pequeas, es decir expresiones de dos o tres operadores relacionases. Estas transformaciones son clasificadas en categoras de acuerdo a las operaciones que involucro. Sean U y B operaciones unitarias y binaria respectivamente, R y S relaciones, entonces se tienen las siguientes propiedades:

Bases de Datos Distribuidas

65

Fundamentos de las Bases de Datos Distribuidas

Conmutatividad de operaciones unitarias: U1 U2 R U2 U1 R

Conmutatividad de operaciones binarias:

Una operacin binaria es conmutativa cuando el resultado de la operacin es el mismo, cualquiera que sea el orden de los elementos con los que se opera.
RBSSBR

Asociatividad de operaciones binarias:

Propiedad asociatividad: para cualesquiera elementos del conjunto A no importa el orden en que se operen las parejas de elementos, mientras no se cambie el orden de los elementos siempre dar el mismo resultado
R B (S B T) (R B S) B T

Idempotencia de operaciones unitarias:

El trmino idempotente se usa para describir una operacin que produce los mismos resultados si se ejecuta una o varias veces. sta es una propiedad muy til en numerosas situaciones, ya que su empleo hace que una operacin pueda ser repetida tantas veces como sea necesario sin causar efectos involuntarios. Con operaciones no idempotentes, el algoritmo podra tener que mantener un registro de si la operacin ya hubo sido realizada o no. Estrictamente, una secuencia que nunca produce efectos secundarios puede ser considerada idempotente (siempre y cuando no haya operaciones concurrentes sobre el mismo conjunto de recursos)1 UN EJEMPLO DE IDEMPOTENCIA ES LA MULTIPLICACION DE 1*1 = 1 o de 0*0 = 0 ASI COMO TAMBIEN LA MULTIPLICACION DE 1*1*1*1*1*1*1*1*1 = 1
U R U1 U2 R

Distributividad de operaciones unitarias con respecto a operaciones binarias:

Bases de Datos Distribuidas

66

Fundamentos de las Bases de Datos Distribuidas

U ( R B S) U ( R ) B U (S)

Factorizacin de operaciones unitarias: U(R)BU(S) U(RBS)

Las siguientes son propiedades que tambin pueden ser aplicadas dentro de la transformacin de expresiones:

R R R R R R

NJN R R UN R R DF R 0 NJN SLF R SLF R UN SLF R R DF SLF R SLNOT F R

(SLF1 R) NJN (SLF2 R) SL F1 AND F2 R (SLF1 R) UN (SLF2 R) SL F1 OR F2 R (SLF1, R) DF (SLF2 R) <-> SL F1 AND NOT F2 R

3.2.2 Determinacin de subexpresiones comunes Una parte importante en la transformacin de expresiones equivalentes es el descubrir las subexpresiones comunes; las cuales aparecen en ms de una vez en la consulta, esto es importante, ya que de esta manera solo se evaluara una sola vez dicha expresin. Una forma de reconocer la existencia de dichas expresiones, consiste en transformar la consulta en su correspondiente rbol de operadores. De esta manera es posible localizar las subexpresines iguales, las cuales utilizan las mismas

Bases de Datos Distribuidas

67

Fundamentos de las Bases de Datos Distribuidas

operaciones y operandos, enseguida se unen tanto los nodos y las hojas en una sola hoja o nodo. En el siguiente ejemplo se ilustrara este mtodo. Considrese las siguientes tablas de una base de datos: EMP(id-emp, nom, sal, deptnum, edad) DEPT(deptnum, descr, gtenum)

Se requieren los nombres de los empleados que trabajan en cierto departamento y cuyo gerente tiene el nmero de 373 pero que no ganan ms de $35,000. expresin para dicha consulta seria: Select A.nom From A EMP inner JOIN B DEPT in (A.deptnum = B.deptnum) Where B.gtenum = 373 < 35001 PJEMP.Nom((EMP JN DEPTNUM = DEPTNUM SL GTENUM=373 DEPT) DF (SL SAL>35000 EMP JN DEPTNUM=DEPTNUM SL GTENUM=373 DEPT)) Una

A simple vista se puede deducir que existe una subexpresin repetida en la consulta, esta es: EMP JN DEPTNUM=DEPTNUM SL GTENUM=373 DEPT Pero vase el rbol de operadores: PJ EMP_NOM

DF JNDEPTNUM=DEPTNUM JN DEPTNUM=DEPTNUM

EMP

SLGETNUM=373

SLSAL>35000

SLGETNUM=373

Bases de Datos Distribuidas

68

Fundamentos de las Bases de Datos Distribuidas

DEPT

EMP

DEPT

Se comienza factorizando el select sobre SAL con respecto al join (al hacer esto, el select es desplazado hacia arriba). PJ EMP_NOM

DF JNDEPTNUM=DEPTNUM EMP SLGETNUM=373 DEPT EMP SL SAL>35000 JNDEPTNUM=DEPTNUM SLGETNUM=373 DEPT

A continuacin se unen los nodos correspondientes al select sobre GTENUM, el nodo correspondiente al join y finalmente, uniendo las hojas correspondientes a las relaciones de EMP y DEPT. El resultado de esto seria un rbol de operadores PJEMP-NOM DF simplificado como se muestra a continuacin:

SLSAL>35000

JNDEPTNUM=DEPTNUM

Bases de Datos Distribuidas

69

Fundamentos de las Bases de Datos Distribuidas

EMP

SLGTENUM=373 DEPT

3.3 Mtodos de ejecucin de JOIN En la ejecucin de una operacin join, se debe de considerar el costo de procesamiento. En este punto influyen varios factores que se deben de tomar en cuenta, para lograr la eleccin de la estrategia correcta, dichos factores son: El orden fsico de las tuplas en la relacin. La presencia de ndices y el tipo de estos. El costo de creacin de un ndice temporal para el procesamiento de una consulta Para el resto de la seccin se considerar la siguiente expresin: deposito JN cliente Y se asumir que la relacin depsito cuenta con 10,000 tuplas y clientes consta de 200 clientes.

Mtodos de ejecucin del Join Existen diferentes algoritmos que pueden obtener transformaciones eficientes en el procesamiento de consultas. Join en bucles (ciclos) anidados Join en bucles anidados por bloques Join por mezcla Join por asociacin. Join por asociacin hbrida Join Complejos Outer Join (Join externos)

Bases de Datos Distribuidas

70

Fundamentos de las Bases de Datos Distribuidas

3.3.1 Iteracin simple (Join en bucles (ciclos) anidados)


Supngase que no se cuentan con ndices, y que es necesario examinar todos los pares posibles de tuplas td en depositas y tc en cliente. examinarla 10000 * 200 = 2000000 pares de tuplas. Si se ejecutar esta consulta de una manera ms optima, se reducira significativamente el nmero de bloques accesados ( considrese un bloque como un conjunto fsico de tuplas ). Supngase que se utiliza el siguiente procedimiento para procesar el join. En l se lee cada tupla de la relacin deposito, esto requerira accesar 10000 bloques de almacenamiento fsico bajo el peor de los casos, considerando que cada una de las tuplas de la relacin deposito se encuentran en bloques diferentes. Si se consideran que 20 tuplas de la relacin deposito se encuentran almacenadas en un bloque, entonces se tendrn 10000120 = 500 bloques distintos accesados. for each tupla d in deposito do begin for each tupla c in cliente do begin compara el par (d, c) para ver si alguna tupla es agregada al resultado final end end Si se compara cada tupla de clientes con cada una de las tuplas de la relacin deposito, esto llevar a hacer 10,000 referencias a cada tupla de clientes. El nmero exacto de accesos a disco depende del tamao del buffer y de otros factores. En el peor de los casos cada consulta requerir de un acceso a disco. Puesto que se tienen 200 tuplas en la relacin de clientes, se tendrn que hacer 2,000,000 lecturas a la relacin de clientes. Si se asume que 20 tuplas de la relacin clientes son almacenadas en un bloque, entonces se requieren de 10 accesos para leer la relacin completa, Por lo tanto, solo se requieren 10 accesos en lugar de 200. Esto implica que se accesarn 100,000 bloques de la tupla clientes para procesar la consulta. El costo de esta tcnica es de 500 accesos a depsitos ms 100,000 accesos a clientes para un total de 100,500 bloques accesados. De esta manera, se

Bases de Datos Distribuidas

71

Fundamentos de las Bases de Datos Distribuidas

3.3.2 Iteracin orientada a bloques


Se obtiene un mayor ahorro en el acceso si se procesa la relacin en base a un proceso por bloques en vez de un proceso basado en tuplas. Nuevamente, se asume que las tuplas de la relacin depsitos y de la relacin clientes son almacenadas de manera continua tambin, Se usar el procedimiento siguiente para procesar depsitos JN clientes. For each bloque Bd of deposito do begin for each bloque Be of dientes do begin for each tupla d in Bd do begin for cach tupla e in Be do begin compara el par (d,c) para ver s una tupla puede ser tomada para el resultado end end end end.

Este procedimiento desarrolla el join considerando un bloque entero de tuplas de la relacin deposito en vez de una tupla individual- An, se leer completa la relacin deposito a un costo de 500 accesos. Sin embargo, en lugar de realizar una lectura a la relacin cliente por cada tupla de la relacin depsito, se leer la relacin cliente por cada bloque de la relacin depsito. Entonces, se tienen 500 bloques de la relacin deposito y 10 bloques de la relacin diente, requieren 10*500= 5000 bloques accesados. De esta manera, el costo en trminos de bloques accesados es de 5500 accesos (5000 accesos a clientes ms 500 accesos a depsitos). con la tcnica anterior. Claramente se puede ver un significativo ahorro en el nmero de accesos necesarios en comparacin

Bases de Datos Distribuidas

72

Fundamentos de las Bases de Datos Distribuidas

3.3.3 Merge - Join


En aquellos casos en los cuales ninguna relacin se encuentra en la memoria principal, es posible realizar un join eficientemente si ambas relaciones se encuentran almacenadas en orden de acuerdo a un atributo por medio del cual se realizara el join. Supngase que ambas relaciones, clientes y depsitos, estn ordenados por nombre-cliente. Se podr entonces realizar una operacin merge-join. Para ejecutar un merge-join, se requiere de un punto de asociacin en cada relacin, Estos puntos son direccionados a la primera tupla de cada relacin. Los punteros son movidos a lo largo de la relacin y si un grupo de tuplas de la relacin contiene el mismo valor que el atributo del join, se leen dichas tuplas, puesto que las tuplas estn ordenadas, el conjunto de tuplas con el mismo valor estarn consecutivas. Esto permite leer cada tupla una sola vez y en el caso de que las tuplas estn almacenadas de manera ordenada, entonces se leer cada bloque exactamente una vez. A continuacin se muestra el esquema del merge-join aplicado al ejemplo de deposito JN cliente.

Pd := direccin de la primera tupla de deposito; Pc:= direccin de la primera tupla de clientes; while (pc null) do begin tc:= tupla a la cual pc apunta; sc {tc} mueve pc a la siguiente tupla en cliente; done := falso; while (not done and pc nuil ) do begin tc' := tupla a la cual pc apunta;

Bases de Datos Distribuidas

73

Fundamentos de las Bases de Datos Distribuidas

if tc[nombre-Cliente] = tc'[nombre-Cliente] then begin si := se u {tc'}; mover pc a la siguiente tupla de cliente; end else done:= verdad; end td := tupla a la cual pd apunta; mueve pd a la siguiente tupla; while ( td[nombre-Cliente] < tc[nombre-Cliente]) do begin td := tupla a la cual pd apunta; mueve pd a la siguiente tupla de deposito; end while (td[nombre-Clientel = tc[nombre-Cliente]) do begin for each t in sc do begin ejecuta t JN td y agrega esto al resultado final; end mueve pd a la siguiente tupla de deposito; td := tupla a la cual pd apunta; end end. Una desventaja de este mtodo es que ambas relaciones deben de estar ordenadas fsicamente, es decir en el medio de almacenamientos.

3.3.4 Uso de ndices


Las tres estrategias que se han considerando dependen de la tcnica usada para almacenar fsicamente las relaciones. El merge-join requiere de un almacenamiento en orden. La iteracin orientada a bloques requiere que las tuplas de cada relacin estn ordenadas fsicamente. nicamente la iteracin simple, puede ser aplicada sin importar la forma en como estn almacenadas las tuplas de las relaciones. El costo de la iteracin simple para el ejemplo deposito JN diente es de 2 millones de accesos a
74

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

bloques.

Cuando se utiliza un ndice, sin importar la manera en como fueron

almacenadas fsicamente las tuplas de las relaciones, el join puede ser ejecutado con una reduccin de accesos significativa. Frecuentemente los atributos del join forman parte de la llave del ndice de una relacin. En estos casos se puede considerar una estrategia de join que utiliza estos ndices. La iteracin simple puede ser ms eficiente si existe un ndice en la relacin cliente para el atributo nombre ~ cliente. Cuando se tiene una tupla d de la relacin deposito no es necesario recorrer la relacin clientes completa. El ndice es usado para buscar las tuplas en clientes para los cuales el nombre-cliente sea igual a d[nombre-cliente]. Se requieren 10000 accesos para leer la relacin depsito. Si se asume que la relacin clientes tiene 200 tuplas, y que se almacenan 20 apuntadores por bloque, entonces, se requieren en promedio 2 accesos a bloques ms un bloque accesado para leer la relacin cliente. Con esto, son necesarios 3 accesos a bloques en la relacin deposito en lugar de 200. Entonces, si por cada tupla de la relacin depsito son necesarios 3 accesos a bloques daran como resultado un total de 30000 accesos, ms los 10000 de la relacin depsito. Aunque un costo de 40000 accesos pareciera alto, se debe tomar en cuenta que se obtendra un mejor resultado solo si las tuplas estn ordenadas fsicamente, Tambin se debe recordar que inicialmente, esta estrategia, tiene un costo de 2 millones de accesos a bloques. Entonces el hecho de obtener un ahorro tan alto de accesos es suficiente para justificar la creacin de ndices.

3.3.5 Hash join


La construccin de un ndice para la ejecucin de un join, convendra, si este ndice es un rbol B+. Dicho ndice sera usado una sola vez para la ejecucin de un simple join. Una funcin hash h es usada sobre las tuplas de ambas relaciones sobre los atributos bsicos del join. Si d es una tupla de la relacin deposito y en c es una tupla de la relacin clientes entonces d y c sern comparados solo si h(c) = h(d). Si h( c ) h( d ) , entonces d y c tendrn valores diferentes para nombre-cliente. Sin embargo es

Bases de Datos Distribuidas

75

Fundamentos de las Bases de Datos Distribuidas

posible que d y c tengan valores diferentes para nombre-cliente a pesar de que sus valores en la funcin hash sean iguales. A continuacin se muestra el algoritmo usado para el hash join que se aplicara en el ejemplo deposito JN cliente.

for each tupla c in cliente do begin i := h(c[nombre-Cliente]); Hci := Hci u {apuntador a c}, end for each tupla d in deposito do begin i := h(d[nombre-cliente]); Hdi := Hdi @ {apuntador a d}; end for i := 0 to max do begin rc:= 0; rd:= 0; for each apuntador pc in Hci do begin c:= tupla a la cual apunta pc; rc:= rc u {c ; end for each apuntador pd in Hdi do begin

Bases de Datos Distribuidas

76

Fundamentos de las Bases de Datos Distribuidas

d:= tupla a la cual apunta pd; rd := rd u {d}; end for each tupla d in rd do begin for each tupla c in rc do begin compara el par (d,c) para ver si una tupla puede ser agregada al resultado end end end

En el algoritmo anterior, se asume que:

h es una funcin hash que mapea valores de nombre-cliente con {0,1,2,...,max)


Hc0, Hc1, ... , Hcmax denotan el contenedor del apuntador a las tuplas de la relacin diente, cada uno vaco al inicio.

Hd0, Hd1, ... , Hdmax denotan el contenedor del apuntador a las tuplas de la relacin deposito, cada uno vaco al inicio.

Se usarn estas propiedades para estimar el costo del desempeo de un hash join. La asignacin de apuntadores a los contenedores hash en los primeros dos ciclos for del algoritmo generan una lectura completa de ambas relaciones. El costo de esta operacin es de 510 accesos a bloques si las tuplas de ambas relaciones, clientes y deposito, son almacenadas de forma continua fsicamente.

Bases de Datos Distribuidas

77

Fundamentos de las Bases de Datos Distribuidas

Desde el momento en que los contenedores almacenan solo apuntadores se asumir que se encuentran en la memoria principal, y por lo tanto no es necesario ningn acceso a disco para leer dichos contenedores. En la parte final del algoritmo se itera sobre el rango de h. Donde i es un valor del rango de h. El ciclo for final ejecuta:

rd JN rc

Donde el conjunto rd es el conjunto de las tuplas de la relacin deposito en el contenedor i y rc es el conjunto de tuplas de la relacin clientes localizadas en el contenedor i. Este join es procesado utilizando una iteracin simple, ya que rd y rc son lo suficientemente pequeos, ambos pueden estar en la memoria principal. Desde el momento que se aplico una funcin hash a una tupla y esta se coloco en un contenedor, cada tupla es leda una sola vez por el for final en el algoritmo. Cabe hacer notar que lo anterior requiere 510 accesos a bloques inicialmente. As, el costo total estimado de un hash join es de 1020 accesos, se requiere una lectura para la funcin hash, y una segunda lectura dentro de los contenedores. Es necesario elegir una funcin hash cuyo rango sea lo suficientemente extenso para que cada contenedor almacene la menor cantidad de apuntadores posible.

3.3.6 Tree - way join Ahora supngase que un join envuelve tres relaciones:

sucursal JN deposito JN cliente Se asume que ndd. = 10000, n,ii,,t, = 200 y n....., = 50. No solo se tiene que considerar la estrategia para procesar el join; sino que ahora se debe ver cual se realizara primero- Hay varias estrategias posibles a utilizar.

Bases de Datos Distribuidas

78

Fundamentos de las Bases de Datos Distribuidas

Estrategia 1: Se procesa el join deposito JN cliente usando alguna de las tcnicas antes mencionadas. Considerando que nombre - cliente es la llave para la relacin clientes. Es posible saber que el resultado de este join, tiene a lo ms 10000 tuplas ( nmero de tuplas en la relacin deposito). Si es posible construir un ndice para sucursal sobre el atributo nombre-sucursal, se podra procesar lo siguiente: sucursal JN (deposito JN cliente) Considerando que nombre - sucursal es la llave para sucursal es posible saber que se examinarn nicamente una tupla de la relacin sucursal para cada una de las 10000 tuplas de la operacin deposito JN cliente. El nmero exacto de bloques accesados en esta estrategia depende de la manera en que la operacin deposito JN cliente es ejecutada, y la forma en que la relacin sucursal es almacenada fsicamente. Estrategia 2: Es posible ejecutar el join con las tres relaciones sin utilizar ndices. Esto requerir el acceso de 50 * 10000 * 200 posibilidades, es decir un total de 10000000. Estrategia 3: En lugar de procesar dos joins, es posible hacer el proceso de un par de joins en uno solo. La tcnica primero requiere la construccin de dos ndices: En sucursal con nombre-sucursal. En cliente con nombre-cliente.

A continuacin se considera para cada tupla t en la relacin deposito, las correspondientes tuplas dentro de las relaciones clientes y sucursal.

Bases de Datos Distribuidas

79

Fundamentos de las Bases de Datos Distribuidas

As, se examinar por cada tupla en deposito - una sola en las otras dos relaciones.

La estrategia 3 presenta una forma de realizar una operacin que no tiene una correspondencia directa dentro del lgebra relacionar. en como las relaciones son almacenadas fsicamente. En cambio, combina 2 operaciones dentro de una operacin especial. El costo relativo depende de la forma

3.3.7 Estrategias para procesamiento paralelo


Las estrategias antes consideradas asumen que un solo procesador esta disponible para procesar un join. Ahora se vera el caso donde varios procesadores estn disponibles para el procesamiento paralelo de un join. Antes que nada se debe considerar que: Todos los procesadores tienen acceso a todos los discos. Todos los procesadores comparten la memoria principal.

Las tcnicas que se presentarn a continuacin pueden ser adaptadas en otras arquitecturas en las cuales cada procesador tiene su propia memoria privada.

3.3.8 Join paralelo


En las tcnicas antes mencionadas para el procesamiento de un join en un procesador solo, la eficiencia se logra reduciendo el nmero de pares de tuplas que

Bases de Datos Distribuidas

80

Fundamentos de las Bases de Datos Distribuidas

son comparadas. La meta de un algoritmo de join paralelo es dividir los pares de tuplas entre varios procesadores. Cada procesador entonces ejecuta una parte del join. En un paso final, el resultado individual de cada procesador es recolectado para producir el resultado final. Idealmente, el trabajo global para procesar el join es dividido equivalente sobre todos los procesadores. Esto sin que ningn procesador caiga en un overhead. Un join paralelo que utiliza N procesadores, tomar 1/N del tiempo que se tardara en ejecutar el mismo join en un solo procesador. En la practica la velocidad es ms dramtica por varias razones: Un overhead ocurre en la particin del trabajo entre procesadores. Un overhead ocurre en la recoleccin de los resultados arrojados por cada uno de los procesadores, para producir el resultado final. El esfuerzo hecho para dividir el trabajo equitativamente es una aproximacin, ya que algunos procesadores, tienen ms trabajo que otros. El resultado final obtenido hasta que el ltimo procesador haya terminado. El procesador tal vez tenga que competir por recursos compartidos del sistema. El resultado se retrasa debido a que un procesador espera a que otro procesador libere los recursos. Considerando nuevamente el ejemplo deposito JN cliente, se asume que se tiene N procesadores P1, P2, ..., PN. Se divide la relacin de deposito en N partes de igual tamao; deposito1, deposito2, ..., depositoN Se supone, por facilidad, que el tamao de la relacin deposito es mltiplo de N, entonces cada procesador Pi procesa depositoi JN cliente en paralelo. En el paso final, se realizara la unin de los resultados parciales obtenidos por cada procesador. El costo de esta estrategia depende de vados factores: La seleccin del algoritmo usado para cada procesador. El costo de la construccin del resultado final. El retraso generado por la retencin de recursos. Aunque cada procesador accesa su propia particin de la relacin deposito, todos los procesadores accesan a la relacin cliente. Si la memoria principal no es suficientemente grande para almacenar la relacin cliente, el procesador necesita sincronizar
81

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

sus accesos a la relacin cliente con otros procesadores para reducir el nmero de accesos a disco. Se sugiere que se utilice alguna tcnica para realizar la divisin del trabajo entre procesadores para reducir el espacio utilizado de memoria. Una tcnica simple es la de utilizar una versin de hash-join para trabajar en paralelo. En donde se escoger una funcin hash cuyo rango sea { 1, 2, ..., N }. Esto dara como resultado, que cada procesados trabaje con exactamente un contenedor hash.

3.3.9 Pipeline multiway join


Existe la posibilidad del procesamiento de varios joins en paralelo. Esto es un uso importante en algunos queries que se realizan en el mundo real, particularmente cuando se tienen vistas, que involucran a varias relaciones. Considere el siguiente join entre cuatro relaciones: r1 JN r2 JN r3 JN r4 Es posible ejecutar t1 (r1 JN r2) en paralelo con t2 (r3 JN r4) y cuando este proceso termine se ejecutar: t1 JN t2 Se puede lograr un alto grado de paralelismo si se tiene un "pipeline" que permita a los tres join ejecutarse en paralelo. Se asigna al procesador P1 la ejecucin de r1 JN r2 y al procesador P2 se asigna r3 JN r4. Como las tuplas resultantes del proceso de P1 estn disponibles para P3 , as como las tuplas resultantes del procesador P2 , entonces P3 podr comenzar el proceso ( r1 JN r2) JN (r3 JN r4 ) antes de que r1 JN r2 y r3 JN r4 hallan terminado.

r1

r2 r3

P1

P3
Bases de Datos Distribuidas 82

r4

Fundamentos de las Bases de Datos Distribuidas

P2

A continuacin se muestra el algoritmo utilizado por el procesador P3 para procesar el join. Las tuplas resultantes de P1 y P2 son colocadas en una cola para ser procesados por P3, P1 y P2 pueden haber utilizado cualquier tcnica para el procesamiento del join. La nica modificacin sera que cuando una tupla t es adicionada al resultado, debe de colocarse como disponible para P3 en la cola. Se deber considerar tambin, entradas especiales en la cola que consisten ENDP1 y ENDP2, que indican la finalizacin del procesamiento del join en los procesadores P1 y P2 respectivamente. Para ejemplo se utilizo un 4-way join pero pude extenderse para procesar N-way join.

done1:= falso; done2:= falso; from1:= 0; from2:= 0; result := 0 ; while not donel or not done2 do begin if la cola esta vaca then esperar hasta que no este vaca; t:= primer elemento de la cola; if t = ENDP1 then donel := verdadero else if t = ENDP2 then done2:= verdadero else if t proviene de Pl then

Bases de Datos Distribuidas

83

Fundamentos de las Bases de Datos Distribuidas

begin from1:= from1 {t}; result:= result ({t} JN from2); end else /* t proviene de P2 */ begin from2 := from2 {t}; result := result (from1 JN {t}); end end

3.4 Principios de optimizacin


Se pueden identificar cuatro pasos generales para el proceso de optimizacin de una consulta. 1.- Convertir la consulta en alguna representacin interna. El primer paso en el proceso de una consulta es convertirla en alguna representacin interna que sea ms apropiada para la manipulacin de la computadora, eliminando as, las consideraciones del nivel externo (tales como los rasgos concretos de la sintaxis de un lenguaje de consulta), preparando as el camino para los subsecuentes pasos de la optimizacin. Se deber hacer una eleccin de manera que se represente a la consulta por medio del lenguaje que pueda manejar el sistema de manera que los pasos subsecuentes no se vean afectados. Por ejemplo, se tiene la consulta "obtener los nombre de los proveedores que surten la pieza P2', es posible representar esto en un rbol de operadores: PJPnombre

Bases de Datos Distribuidas

84

Fundamentos de las Bases de Datos Distribuidas

SLprovee.prod=P2

JN

Proveedor

Provee

Esto da como resultado una expresin, dentro del lgebra relacional que se puede manejar ms fcilmente por el sistema:

PJ ( SL ( Proveedor JN Provee ) provee.prod=P2 ) nombre

2.- Convertir a forma cannica. La definicin de forma cannica es el punto central en muchas reas de las matemticas y disciplinas relacionadas. Es posible definirla como sigue: Se tiene un conjunto Q de objetos (Queries) y la definicin de equivalencia entre ellos (dos queries son equivalentes, si y solo si, producen el mismo resultado), se tiene tambin un subconjunto C de Q, el cual se llama conjunto de formas cannicas de Q ( bajo la definicin de equivalencia ), si y solo si, algn objeto q en Q es equivalente a solo un objeto c en C. El objeto c es llamado la forma cannica de q. Todas las propiedades que se aplican a q se aplican a la forma cannica c; As, es suficiente realizar el estudio del pequeo conjunto de formas cannicas, y no del gran conjunto de Q. Durante este paso, el optimizador ejecuta un nmero de transformaciones que son "garantizadas para ser correctas', en relacin con los datos actuales y las rutas de acceso que existen en la base de datos. El punto es que la mayora de los lenguajes de consulta permiten que hasta la ms simple consulta pueda ser expresada en una variedad de formas distintas. Tan solo en SQL, la consulta de la seccin anterior tiene ocho posibles representaciones.

Bases de Datos Distribuidas

85

Fundamentos de las Bases de Datos Distribuidas

La obtencin de expresiones equivalentes se logra por medio de reglas de transformacin bien definidas y permitidas dentro del lgebra relacionar.

3.- Elegir el procedimiento de bajo nivel. Habiendo convertido la representacin interna de la consulta en alguna forma ms deseable (forma cannica), se debe decidir como se evaluar la consulta, representada por su forma cannica. En este paso se debe considerar la existencia de ndices, rutas de acceso, distribucin de los datos almacenados, almacenamiento fsico de los registros, etc. La estrategia bsica es considerar la consulta como una serie de operaciones de "bajo nivel" join, select, project, etc.), con cierta interdependencia entre ellos. Para cada operacin de bajo nivel, se tendr un conjunto de procedimientos predefinidos; Por ejemplo, un conjunto de procedimientos para la seleccin sera, un procedimiento para cuando los campos estn indexados, y otro para cuando no lo estn, pero estn almacenados fsicamente en orden, etc. Cada procedimiento tiene asociado un costo.

4.- Seleccionar el procedimiento ms econmico. El paso final del proceso de optimizacin involucro la construccin de un conjunto de planes de ejecucin de consultas candidatas seguido de la eleccin del mejor (ms econmico) de estos planes. Cada plan es construido con la implementacin de los procedimientos necesarios para ejecutar la consulta. Ser necesario un procedimiento por cada operacin de bajo nivel en la consulta. No es necesario construir todos los planes posibles, basta con generar una cantidad razonable de procedimientos y realizar combinaciones entre ellos y seleccionar el conjunto ms econmico para la ejecucin de la consulta. utilizacin del CPU, etc. Dentro del costo de una consulta tambin deber tomar en cuenta la transmisin de los datos dentro del sistema en el cual se lleva a cabo dicha consulta. Es importante recordar que dentro de un sistema de bases de datos distribuidas, la informacin se La asignacin del costo a algn plan involucrar el nmero de accesos a disco, la

Bases de Datos Distribuidas

86

Fundamentos de las Bases de Datos Distribuidas

encuentra dispersa dentro de varios servidores y es utilizada por muchos clientes, los cuales pueden estar a corta distancia de los servidores o muy alejados de estos. Cuando una consulta es lanzada en un sistema de bases de datos distribuidos, en ese momento es posible saber que informacin se requiere y en que sitio se encuentra. Entonces se debe decidir la forma en que se realizar el proceso de recoleccin de datos. Es decir, la tabla es enviada ntegramente al sitio que lanzo la consulta o solo los registros que cumplen con la condicin, tal vez es necesario que otro sitio realice el proceso de recoleccin de resultados parciales y solo se reciba el resultado final o si el sitio que lanzo la consulta, realice el proceso integro, etc. En un sistema distribuido de bases de datos, el costo ms alto es el de la comunicacin, por ello es necesario utilizar estrategias para reducirlo. Como se vio en el captulo anterior (Ejemplos de consultas distribuidas), es necesario considerar, de cierta forma, la capacidad de procesamiento de los equipos para decidir que equipo o equipos realizaran los procesos ms demandantes.

El problema de optimizacin de consultas es minimizar una funcin de costo tal que funcin de costo total = costo deI /O + costo de CPU + costo de comunicacin.

Bases de Datos Distribuidas

87

Fundamentos de las Bases de Datos Distribuidas

3.5 Resumen
El desarrollo de una buena estrategia en el procesamiento de una consulta es necesario en un ambiente distribuido, la eficiencia del sistema final depende mucho de la calidad del optimizador de consultas. La seleccin de estrategias alternativas para la ejecucin de las consultas, tanto en ambientes centralizados como distribuidos, es hecha de acuerdo al desempeo requerido. Las medidas tpicas asumidas en un sistema centralizado de bases de datos son el nmero de operaciones I/O y el tiempo de uso del CPU requerido para realizar las consultas. En bases de datos distribuidas se debe considerar adems, el costo de la transmisin de datos entre los sitios participantes de la consulta. La seleccin de una estrategia de procesamiento de consultas involucro: 1. Determinar el nmero de copias de los fragmentos sobre los cuales se ejecutara la consulta, obteniendo una expresin de consulta sobre fragmentos. 2. 3. Seleccionar el orden de ejecucin de las operaciones. Seleccionar el mtodo para la ejecucin de cada operacin.

Una expresin de lgebra relacional no solo se expresa por medio de sus especificaciones semnticas, sino tambin por medio de una secuencia de operadores, y desde este punto de vista dos expresiones con la misma semntica se pueden

Bases de Datos Distribuidas

88

Fundamentos de las Bases de Datos Distribuidas

expresar por medio de dos secuencias de operadores diferente, esto conlleva a decir que estas dos expresiones son equivalentes. Dos expresiones son equivalentes cuando sus tuplas representan el mismo mapeo de los atributos a los valores, aun cuando el orden de los atributos no sea el mismo. La equivalencia de dos expresiones se representa por E1 E2. Es posible obtener expresiones equivalentes pequeas aplicando ciertas propiedades de operadores y conjuntos de operadores. unitaria y binaria respectivamente, R y S relaciones. propiedades: Sea U y B operaciones Se tienen las siguientes

Conmutatividad de operaciones unitarias: U1 U2 R U2 U1 R

Conmutatividad de operaciones binarias: RBSSBR

Asociatividad de operaciones binarias: R B (S B T) (R B S) B T

Idempotencia de operaciones unitarias: U R U1 U2 R

Distributividad de operaciones unitarias con respecto a operaciones binarias: U(RBS) U(R)BU(S)

Factorizacin de operaciones unitarias: U(R)BU(S U RBS

Las siguientes son propiedades que tambin pueden ser aplicadas dentro de la transformacin de expresiones:

Bases de Datos Distribuidas

89

Fundamentos de las Bases de Datos Distribuidas

R NJN R R R UN R R R DF R 0 R NJN SLF R SLF R R UN SLF R R R DF SLF R SLNOT F R (SLF1 R) NJN (SLF2 R) SL F1 AND F2 R (SLF1 R) UN (SLF2 R) SL F1 OR F2 R (SLF, R) DF (SLF2 R) <-> SL F1 AND NOT P2 R Una parte importante en la transformacin de expresiones equivalentes es el descubrir subexpresiones comunes, las cuales podran aparecer ms de una vez en la consulta, esto es importante, dado que, solo se tendran que evaluar una sola vez, ahorrando as, tiempo. Una manera de reconocer la existencia de dichas expresiones, consiste en transformar la consulta en su correspondiente rbol de operadores, de esta manera es posible localizar las subexpresiones iguales, que en este caso seran ramas similares, las cuales se convertirn en una sola rama. Algo que tambin se debe de considerar es el costo de procesamiento de las operaciones join. En esta parte influyen varios factores, los cuales se debern tomar en cuenta: El orden fsico de las tuplas en la relacin. La presencia de ndices y el tipo de los mismos. El costo de procesamiento de un ndice temporal para el procesamiento de una consulta. Dentro de las tcnicas de ejecucin de join se tiene las siguientes: Iteracin simple: Cada una de las tuplas de una relacin es comparada con todas las tuplas de la otra relacin.

Bases de Datos Distribuidas

90

Fundamentos de las Bases de Datos Distribuidas

Iteracin orientada a bloques: Se asume que las tuplas de la relacin estn almacenadas en orden y de manera continua. Esta tcnica leer un bloque de tuplas en lugar de una tupla individual, as se compara un bloque de una relacin contra los bloques de la otra relacin. Merge-join: Esta tcnica requiere que las tuplas estn almacenadas de forma ordenada de acuerdo al atributo por el cual se va a realizar el join. Cada relacin tendr un puntero que indica la posicin de lectura para el join, al ir leyendo, dichos punteros avanzarn. Al encontrarse la tupla que tiene el mismo valor que la tupla con la que se esta ejecutando el join, el recorrido sobre la relacin se detiene y el puntero se coloca de nuevo en la primera posicin, esto debido a que las tuplas estn ordenadas y no debe existir otro valor ms all de la posicin del puntero. Se repetir este proceso hasta que se recorran todas las tuplas de la primera relacin. Hash-join: Una funcin hash h es usada sobre las tuplas de ambas relaciones sobre los atributos bsicos del join. Si d es una tupla de la relacin deposito y en c es una tupla de la relacin clientes entonces d y c sern comparados solo s h(c) = h(d). Si h(c) h(d), entonces d y c tendrn valores diferentes para los atributos bsicos del join. Sin embargo es posible que d y c tengan valores diferentes para los atributos bsicos del join a pesar de que sus valores en la funcin hash sean iguales.

Three-way join: Si se tiene que un join envuelve tres relaciones, se podran utilizar algunas de las siguientes estrategias: 1 . Se procesa el join con cualquier tcnica, si es posible se deber construir un ndice sobre los atributos bsicos del join, se procesarn primero un par de relaciones y el resultado de este join se procesara con la tercer relacin, obteniendo as el resultado final. 2. 3. Es posible ejecutar el join con las tres relaciones sin utilizar ndices. En lugar de procesar dos joins, es posible hacer el proceso de un par de joins en uno solo.El resultado final ser la combinacin de los resultados de las relaciones. Esto requerir la utilizacin de ndices.

Bases de Datos Distribuidas

91

Fundamentos de las Bases de Datos Distribuidas

Join paralelo: La meta de un algoritmo de join paralelo es la de dividir los pares de tuplas entre varios procesadores. Cada procesador ejecutar una parte del join. En un paso final, el resultado individual de cada procesador es recolectado para producir el resultado final. El trabajo global para procesar el join ser dividido lo ms equitativamente posible, tratando de que ningn procesador caiga en un overhead.

Pipeline multiway join: Existe la posibilidad de procesar varios joins en paralelo. Considrese el siguiente join entre cuatro relaciones: r1 JN r2 JN r3 JN r4

Es posible ejecutar t1 (r1 JN r2) en paralelo con t2 (r3 JN r4) y cuando este proceso termine se ejecutar: t1 JN t2

Se puede lograr un alto grado de paralelismo si se tiene un "pipeline" que permita a los tres join ejecutarse en paralelo. Se asigna al procesador P1 la ejecucin de r1 JN r2 y al procesador P2 se asigna r3 JN r4. Como las tuplas resultantes del proceso de P1 estn disponibles para P3 , as como las tuplas resultantes del procesador P2 , entonces P3 podr comenzar el proceso (r1 JN r2 ) JN (r3 JN r4 ) antes de que r1 JN r2 y r3 JN r4 hallan terminado. Las tuplas resultantes de P1 Y P2 son colocadas en una cola para ser procesadas por P3 , para obtener el resultado final. Se tienen cuatro pasos generales en el proceso de optimizacin de una consulta: 1. Convertir la consulta en alguna representacin interna: El primer paso en el proceso de una consulta es convertirla en una representacin interna que sea

Bases de Datos Distribuidas

92

Fundamentos de las Bases de Datos Distribuidas

ms apropiada para la manipulacin de la informacin, esto de manera que los pasos subsecuentes no se vean afectados. 2. Convertir a una forma cannica: Se tiene un conjunto Q de objetos (Queries) y la definicin de equivalencia entre ellos (dos queries son equivalentes, si y solo si, producen el mismo resultado), se tiene tambin un subconjunto C de Q, el cual se llama conjunto de formas cannicas de Q (bajo la definicin de equivalencia), si y solo si, algn objeto q en Q es equivalente a solo un objeto c en C. El objeto c es llamado la forma cannica de q. Lo importante en este punto, es que, la mayora de los lenguajes de consulta permiten representar una consulta en varias formas distintas. As, la obtencin de expresiones equivalentes se logra por medio de reglas de transformacin definidas y permitidas dentro del lgebra relacional. 3. Elegir el procedimiento de bajo nivel: Se deber decidir como se evaluara la consulta, representada por su forma cannica, aqu, la estrategia bsica es considerar la consulta como una serie de operaciones de bajo nivel, para cada operacin se tendr un conjunto de procedimientos predefinidos. 4. Seleccionar el procedimiento ms econmico: El paso final es la contraccin de un conjunto de planes de ejecucin de consultas candidatas seguidas de la eleccin del mejor de los planes. Dentro del costo de una consulta tambin deber tomarse en cuenta la transmisin de los datos dentro del sistema en el cual se llevara a cabo la consulta. Cuando una consulta es lanzada dentro de un sistema de bases de datos distribuidas, es posible saber que informacin se requiere y en que sitio se encuentra. Entonces se deber de disear una estrategia de recoleccin de datos. Es necesario recodar que dentro de un sistema de bases de datos distribuidas el costo ms alto es el de la comunicacin, por lo tanto de deben de utilizar las estrategias que minimicen este costo en lo posible.

3.6 Preguntas de repaso


1.- Cuales son los tres puntos que se deben tomar en cuenta en la optimizacin de una consulta?
93

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

2.- Mencione que se debe de considerar para seleccionar una estrategia de procesamiento de consultas? 3.- Que condicin deben cumplir dos expresiones para que sean consideradas equivalentes? 4.5.Que es una subexpresin comn? Que puntos se deber tomar en cuenta para seleccionar una buena

estrategia de ejecucin de join? 6.7.8.Que mtodos de ejecucin de join existen? Explique brevemente el funcionamiento de la estrategia de join paralelo. Explique brevemente los pasos para el proceso de optimizacin de una

consulta.

3.7 Ejercicios
Para los siguientes ejercicios, se utilizaran las tablas EMP y DEPT del ejemplo de la seccin 3.2.2 y la siguiente consulta: EMP(id-emp, nom, sal, deptnum, edad) DEPT(deptnum, descr, gtenum)

Obtngase el nombre de los empleados mayores de 40 aos del departamento sistemas con sueldo mayor a $11,000. l.2.3.4.Dibuje el rbol de operadores de la consulta. Obtenga las subexpresiones comunes que contenga la consulta. Dibuje el rbol de operadores optimizado de la consulta. Considrese que las tablas de EMP y DEPT se encuentran en diferentes

Bases de Datos Distribuidas

94

Fundamentos de las Bases de Datos Distribuidas

sitios, y que el sitio en el cual se encuentra la tabla EMP tiene una capacidad de procesamiento muy reducida. Dibuje el rbol de operadores ms recomendable para este caso.

Bibliografia
[1] Ceri, Stefano. Pelaggati, Giuseppe; "Distributed Databases Principies and

systems'; Internacional Edition; McGraw-Hill; U.S.A.; 1985 [2) Date, C.J.; "An Introduction lo Databases Systems"; Volume 1; Fifth Edition; Addison-Wesley Publishing Company; U.S.A.; Repnted Juiy, 1990 [3] Date, C.J.; "An lntroduction lo Databases Systems"; Volume li; Addison-Wesley Publishing Company-, U.S.A.; Reprinted July, 1995

Captulo IV

Procesamiento de transacciones en bases de datos distribuidas

Bases de Datos Distribuidas

95

Fundamentos de las Bases de Datos Distribuidas

Objetivo
El alumno comprender y manejara los conceptos de control de concurrencia, seguridad y recuperacin dentro del mbito de las bases de datos distribuidas

Introduccin
Este captulo trata el aspecto del control de concurrencia, de cmo con etiquetas de tiempo o bloqueos de registros, es posible mantener la integridad de la base de datos en un ambiente multiusuario. Tambin se habla a cerca de los mtodos de recuperacin del sistema en base a bitcoras, check-points y respaldos. Por ultimo, el captulo expone algunas tcnicas para garantizar la seguridad del sistema, por medio de matrices de autorizacin, evitando as el acceso a usuarios no autorizados.

4.1 Control de concurrencia


4.1.1 Seriabilidad en bases de datos centralizadas Una transaccin accesa la base de datos usando primitivas de lectura y escritura. Sean Rj(x) y Wi(x) las operaciones de lectura y escritura respectivamente, usadas en la transaccin Ti para el elemento de datos X. X puede ser una tupla o un fragmento completo. El conjunto de elementos de lectura de datos para Ti es llamado conjunto lector y el conjunto de elementos de escritura de datos para Ti es llamado conjunto escritor. El conjunto lector y el conjunto escritor de una transaccin no estn separados sino por el contrario, trabajan en conjunto. Una entrada de bitcora es una secuencia de operaciones hechas por una transaccin. Por ejemplo, la siguiente serie de operaciones sera una planificacin: S1: Rj (x) Rj (x) Wi (y) Rk (X) Wj (X) Dos transacciones Ti y Tj se ejecutan en sede dentro de una planificacin S, si la ultima operacin de Ti precede a la primera operacin de Tj en S o viceversa); En otro caso las transacciones se ejecutaran concurrentemente.

Bases de Datos Distribuidas

96

Fundamentos de las Bases de Datos Distribuidas

Una planificacin es serial si las transacciones no se ejecutan concurrentemente, es decir, una detrs de otra. Por ejemplo, la siguiente planificacin S2 es serial:

S2: Ri (x) Wi (y) Ri (y) Rj (x) Wj (y) Rk (y) Wk (X)

Ti R(x) W(y) R(y)

Tj

Tk

R(x) W(y) R(y) W(x)

Esto sera S2: Ti Tj Tk

En una planificacin, si la operacin Oi precede a la operacin Oj,

se indica como

Oi < Oj, es decir Oi se ejecuta primero que Oj, entonces en S2 Ti < Tj y Tj < Tk. La ejecucin serial de una transaccin puede ser descrita por una planificacin seal (denominada por Serial (S1) ). De cualquier forma no es posible forzar a las transacciones a ejecutarse serialmente. Algo ideal sera que las transacciones se ejecutaran lo ms concurrentemente posible, cuidando que esta ejecucin sea correcta. La definicin ms aceptada de correcto en una planificacin es basada en la seriabilidad:

Bases de Datos Distribuidas

97

Fundamentos de las Bases de Datos Distribuidas

Una planificacin es correcta si esta es seriabilizable, esto es, que el resultado obtenido por esta sea equivalente al resultado de una planificacin serial. Teniendo el concepto de seriabilidad, es posible decir que un mecanismo de control de concurrencia es correcto si permite a las transacciones ejecutarse en una secuencia tal que solo una bitcora serializable podra producir. Un mecanismo de control de concurrencia restringe las posibles secuencias de operacin ejecutados por una transaccin que fuerza a otra transaccin a esperar mientras la primera termina de realizar sus operaciones. Un ejemplo es el bloqueo de registros, ya que fuerza a otras transacciones a esperar hasta que esta termine de realizar las operaciones sobre los datos. Las siguientes dos condiciones son suficientes para decir que dos planificaciones son equivalentes: 1. 2. Cada operacin de lectura lee los mismos valores que fueron producidos por La operacin de escritura final es igual en ambas planificaciones.

las mismas operaciones de escritura en ambas planificaciones.

Estas dos condiciones son suficientes ya que ambas transacciones leen y escriben los mismos datos. Es importante tambin considerar el hecho de que dos operaciones pueden llegar a caer en conflicto: Dos operaciones estn en conflicto si, ellas procesan el mismo dato y al menos una de estas operaciones es una operacin de escritura, y estas operaciones pertenecen a diferentes transacciones. Por ejemplo, [ Rj (x), Wj (x) ] y [ Wi (X), Wj (X) ] son pares de operaciones en conflicto mientras que [ Ri(x), Rj(x) Wi(x), Wj(y) ], y [ Wi(x), Rj(y) ] son pares que no se encuentran en conflicto. Usando este concepto es posible obtener una definicin de planificacin equivalente de otra manera:

Bases de Datos Distribuidas

98

Fundamentos de las Bases de Datos Distribuidas

Dos planificaciones S1 y S2 son equivalentes si por cada par de operaciones en conflicto Oi y Oj, donde Oi < Oj en S1, entonces Oi deber preceder a Oj en S2.

Por ejemplo, la estructura S3 es equivalente a la planificacin S4: S3: S4: Ri(x) Ri(x) Wj(y) Wi(x) Rj(x) Wj(y) Ri(x) Wi(x)

S3 Ti R(x) R(x) W(x) W(x) R(x) W(x) Tj Ti

S4 Tj R(x) W(y)

4.1.2 Seriabilidad en una base de datos distribuida En una base de datos distribuida, cada transaccin ejecuta operaciones en varios sitios. La secuencia de operaciones procesada por las transacciones en un sitio es una planificacin local. Una ejecucin de n transacciones distribuidas T 1, T2, .... Tn en m sitios es modelado por un conjunto de entradas de bitcora Sl, S2, .... Sm. Si se aplica en cada sitio un mecanismo de control de concurrencia se asegurara que todas las planificaciones locales son serializables. Sin embargo, la seriabilidad local no es suficiente para asegurar la exactitud de la ejecucin de un conjunto de transacciones distribuidas. Considere los siguientes ejemplos: S1 (Sitio 1): Ri(x) Wj(x) Ri(x) Wi(x) S2 (Sitio 2): Rj(y) Wi(y) Ri(y) Wj(y)

Bases de Datos Distribuidas

99

Fundamentos de las Bases de Datos Distribuidas

S1 Ti R(x) W(x) R(x) W(x) W(y) R(y) W(y) Tj Ti

S2 Tj R(y)

Ambas planificaciones son seriales, sin embargo, no hay una secuencia seal global de ejecucin de ambas transacciones porque Ti < Tj en Serial(S1) y Tj < Ti en Serial(S2). Para generalizar, la seriabilidad de transacciones distribuidas, es necesaria una condicin ms fuerte que la seriabilidad local. La ejecucin de las transacciones T1, ..., Tn es correcta si: 1. 2. Cada entrada local Sk es serializable. Existe un orden total de T1, ..., Tn tal que, si Ti < Tj en el orden total, entonces

hay una planificacin serial Sk tal que, Sk es equivalente a Sk y Ti < Tj en el Serial(Sk), para cada sitio k donde ambas transacciones tienen algn proceso en ejecucin. La anterior definicin puede ser explicada usando la definicin de conflicto: Sea T1, ..., Tn un conjunto de transacciones, y sea E una ejecucin de estas transacciones, modelado por el conjunto de planificaciones S1, ..., Sm E es correcto (serializable) si existe un orden total de las transacciones, y adems para cada par de operaciones en conflicto Oi y Oj de las transacciones Ti y Tj respectivamente, Oi precede a Oj en cualquier entrada S1, ..., Sn si y solo si Ti precede Ti en el orden total.

Bases de Datos Distribuidas

100

Fundamentos de las Bases de Datos Distribuidas

Esta condicin determina si una ejecucin de una transaccin distribuida es correcta. Un mecanismo de control de concurrencia es correcto si permite solo la ejecucin de transacciones distribuidas.

4.1.3 Control de concurrencia basado en bloqueos centralizados La idea bsica del bloqueo (lock) es que cuando una transaccin requiera accesar un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una transaccin intente bloquear un registro que anteriormente ya fue bloqueado por otra transaccin, la primera deber esperar a que la otra transaccin libere dicho bloqueo (unlock). De hecho, los mecanismos tpicos de bloqueo son ms complejos, debido al concepto de modo de bloqueo: una transaccin puede bloquear un registro en modo compartido (shared) si nicamente se desea leerlo y en modo exclusivo (exclusiva) si se va a escribir en l. Una transaccin siempre deber bloquear un registro de forma compartida antes de leer el contenido, y bloquear de modo exclusivo antes de escribir. Existen dos reglas de compatibilidad entre los modos de bloqueo: 1. Una transaccin puede bloquear un registro, si este no esta bloqueado o si lo esta de manera compartida. 2. Una transaccin puede bloquear de manera exclusiva, solo si el registro no esta bloqueado.

Otro aspecto importante en el bloqueo es la granularidad. Esto se refiere al tamao del "objeto" que se bloquea con una operacin simple, esto es, se puede bloquear un registro o un archivo con una sola instruccin. Otra condicin que se deber de tener en cuenta es que, una transaccin no debe de requerir de un nuevo bloque despus de que se libere algn registro, esto quiere

Bases de Datos Distribuidas

101

Fundamentos de las Bases de Datos Distribuidas

decir que la transaccin debe de tener un bloqueo de dos fases (2PC), esto porque la primera fase sera el bloqueo de todos los registros necesarios para realizar la transaccin, y la segunda fase es en la cual se hace la liberacin de todos los registros antes bloqueados. Teniendo en cuenta lo anterior, se podra asumir que las transacciones estn estructuradas de la siguiente forma: Inicia transaccin Se realizan todos los bloqueos para escritura o lectura Se hace todo el proceso de la transaccin (Commit) Se liberan todos los bloqueos

Un problema que se puede presentar al usar los mecanismos de bloqueo es el deadlock. Un deadlock entre dos transacciones surge cuando cada una de las Ambas transacciones pueden quedar transacciones tiene bloqueado un registro y estn esperando para bloquear el registro que la otra transaccin ya tiene bloqueado. esperando a la otra para siempre. El sistema debe de ser capaz de detectar el

deadlock y forzar a alguna de las dos transacciones a liberar el registro que se tenia bloqueado y a que se reinice posteriormente, permitiendo que la otra transaccin termine correctamente.

4.14 Control de concurrencia basado en bloqueos distribuidos


Se asume que, el manejador local de transacciones (LTM, Local Transaction Manager) permite al agente local realizar los bloqueos y liberaciones de registros locales, y el proceso de la transaccin se lleva acabo de acuerdo con la siguiente figura:

ROOT AGENT

Mensaje
AGENT

Mensaje
AGENT

Transaccin Distribuida

2
DTMAGENT

2
DTMAGENT

2
DTMAGENT

Bases de Datos Distribuidas

102

Fundamentos de las Bases de Datos Distribuidas

Mensaje

Mensaje

Manejador distribuido de transacciones

1
LTM en sitio i

1
LTM en sitio j

1
LTM en sitio k

Manejadores de transacciones locales

Interface 1': Bloqueo local compartido, Bloqueo local exclusivo, desbloqueo local Interface 2': Bloqueo compartido, Bloqueo exclusivo, desbloqueo

Entonces, los LTMs interpretan las primitivas locales de bloqueo (bloqueo local compartido, bloqueo local exclusivo y, liberacin local), mientras que los agentes de la transaccin procesan las primitivas globales (bloqueo compartido, bloqueo exclusivo, y liberacin). Entender los aspectos peculiares del control distribuido de concurrencia es equivalente a comprender lo que el manejador distribuido de transacciones (DTM, Distributed Transaction Manager) tiene que hacer para garantizar que la transaccin global tenga las caractersticas de seriabilidad y aislamiento. Un problema principal que se presenta es la administracin de mltiples copias de datos, el cual, el DTM debe resolver. Los mecanismos de bloqueo fueron desarrollados para bases de datos centralizadas con la suposicin implcita de que solo existe una copia nica de los datos; de esta manera, una transaccin se da cuenta de que otra transaccin est trabajando con un registro al momento de intentar accesarla. En las bases de datos distribuidas, la redundancia que existe entre los datos es almacenada en diferentes sitios puede generar un conflicto de bloqueo entre dos transacciones, al accesar dos copias del mismo dato almacenados en diferentes sitios, para los cuales la existencia mutua es inadvertida para dichas transacciones. Una manera de evitar este problema seria que el DTM tiene que traducir la primitiva de bloqueo emitida por un agente en un registro de tal manera que sea imposible que
Bases de Datos Distribuidas 103

Fundamentos de las Bases de Datos Distribuidas

un bloqueo pase inadvertido por una transaccin. Esta es una manera sencilla de hacer que de manera local, los LTMS, realicen todos los bloqueos en cada uno de los sitios en donde se encuentran almacenadas las copias de los datos; de esta manera, una primitiva de bloqueo es traducida en varias primitivas de bloqueo, tantas como copias de datos se deseen bloquear. Este enfoque trabajara, porque dos transacciones en conflicto de bloqueo podran darse cuenta de esto en todos los sitios donde se encuentren copias de los mismos datos. Existen esquemas alternativos para lograr evitar conflictos en los bloqueos: 1. Write-locks-all, read-locks-one. En este esquema los bloqueos exclusivos son adquiridos en todas las copias, mientras que los bloqueos compartidos son adquiridos nicamente en alguna copia arbitrada. Un conflicto es siempre detectado, porque un bloqueo compartido - exclusivo es detectado en el sitio donde este se encuentra o es requerido el bloqueo compartido, y un bloqueo exclusivo - exclusivo es detectado en todos los sitios. 2. Mayora de bloqueos. En ambos bloqueos compartido y exclusivo son requeridos en una mayora de las copias de los registros (el nmero de copias que se bloquean son estrictamente ms grande que el nmero de copias que no se bloquean); de esta manera si dos transacciones requieren bloquear el mismo registro, hay por lo menos una copia de l en donde se descubrira el conflicto.

3. Bloqueo de copia primaria. Una de las copias de cada dato es privilegiada


(llamada copia primaria); todos los bloqueos son solicitados a esta copia, y as es descubierto el conflicto en el sitio en donde se encuentra esta copia.

4.1.5

Bloqueo de 2 fases como un mtodo de control de concurrencia

Considrese primero que, si todas las transacciones logran un bloqueo de 2 fases, entonces todas las entradas de bitcora son serializables. Considrese tambin un sitio donde una transaccin ejecuta alguna operacin, la cual es nicamente una parte de] conjunto total de operaciones ejecutadas por la transaccin distribuida, entonces se tendr que, si una transaccin distribuida logra un bloqueo de dos fases entonces

Bases de Datos Distribuidas

104

Fundamentos de las Bases de Datos Distribuidas

todas las subtransacciones en los diferentes sitios, lograrn separadamente un bloqueo de dos fases. En el momento que el bloqueo de 2 fases es un mtodo correcto para el control de concurrencia para una base de datos centralizada, la ejecucin de las subtransacciones es serializable. Considrese ahora que, las transacciones T1, T2, ..., Tn requieren de un bloqueo de dos fases, esto tal vez no llegue a ocurrir. Considere el estado intermedio en el conjunto T1 tiene bloqueado a X, T2 tiene bloqueado Y, ..., Tn-1 tiene bloqueado V y Tn tiene bloqueado Z. Cada una de estas transacciones requieren de bloquear un dato el cual, ya esta bloqueado por otra transaccin; por lo tanto cada una de ellas tendr que esperar hasta que otra transaccin libere el bloqueo. Sin embargo, desde el momento en que las transacciones utilizan el bloqueo de dos fases, estas no pueden liberar el bloqueo, sino hasta que se logran todos los bloqueos requeridos por dicha transaccin. Por lo tanto n transacciones alcanzarn un estado de deadlock, y pueden estar esperando por siempre. Entonces, una de estas transacciones deber ser abortada por algn algoritmo de solucin de deadlock. transacciones no podr ocurrir. Lo anterior es independiente del nmero de transacciones y de la secuencia de ejecucin, pero s depende nicamente del orden de los pares de operaciones en conflicto. Por tanto, un algoritmo de deteccin y resolucin de deadlock es necesario en un bloqueo de dos fases. Considrense dos transacciones Ti y Tj, las cuales transfieren fondos de una cuenta x localizada en el sitio 1 a una cuenta localizada en el sitio 2. Dichas transacciones pueden ser descritas por la siguiente secuencia de operaciones: Ti : Ri1(x) Wi1(x) Ri2(Y) Wi2(Y) Tj : Rj1(x) Wj1(x) Rj2(Y) Wj2(Y) En cualquier caso, el conjunto de

Ti Ri(x) Wi(x) R2(Y) W2(Y)

Ti Ri(x) Wi(x) R2(Y) W2(Y)

Bases de Datos Distribuidas

105

Fundamentos de las Bases de Datos Distribuidas

Se asume que cada transaccin lee X, decrementa su valor, escribe el nuevo valor, lee Y, incremento su valor, y escribe su nuevo valor. Supngase que ambas transacciones son activadas de manera simultnea. Un bloqueo de 2 fases asegura la ejecucin serializable de estas transacciones, y habra un orden total en el que Ti < Tj o Tj < Ti; esto significara que Wi1(x) < Rj1(x) y Wi2(y) < Rj2(y) o que Wj1(x) < Ri1(x) y Wj2(y) < Ri2(y)- Dado que existe una simetra, se podr considerar cualquiera de los dos casos. Para ejemplo considrese Ti < Tj. Para lograr un anlisis del grado de concurrencia que es permitido por el algoritmo de control de concurrencia, es necesario incluir en el modelo de ejecucin la nocin de "operaciones concurrentes" en diferentes sitios. Se representarn dos operaciones concurrentes colocndolas una sobre otra, en la ejecucin concurrente de transacciones. Por ejemplo: Sl: S2: Ri(x) Wi(x) Ri(y) Wi(y) Rj(x) Wj(x) Rj(y) Wi(y) S1 Ri(x) Wi(X) Ri(y) Wi(Y) S2 Rj(x) Wi(X) Rj(y) Wi(Y)

En esta representacin de la ejecucin, el hecho de que la operacin Ri(y) aparezca abajo de Rj(x) significa que estas dos operaciones inician al mismo tiempo. Por lo tanto, Tj inicia leyendo x, e inmediatamente Tj tiene que escribir x, aunque Ti no termine aun. concurrencia. Esta ejecucin de E es serializable y permite el m)dmo grado de

4.1.6 Etiquetas de tiempo en una base de datos distribuida


En un sistema distribuido, es necesario, algunas veces, conocer si un evento A en algn sitio ocurri antes o despus que un evento B en un sitio diferente. Determinar el orden de los eventos es sencillo en un sistema centralizado, ya que es posible utilizar
106

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

el mismo reloj para determinar el tiempo en que cada uno ocurre. En un sistema distribuido, en cambio, no es prctico asumir que los relojes disponibles en todos los sitios estn perfectamente sincronizados. Varios mtodos de control de concurrencia y algoritmos de prevencin de deadlock requieren determinar el orden en que se realizarn los eventos. La determinacin de un orden de eventos consiste en asumir que a cada evento A, el cual ocurre en un sistema distribuido, se asigna una etiqueta de tiempo TS(A) (timestamp) con las siguientes propiedades: 1. 2. TS(A) identifica de manera Unica a A (diferentes eventos tienen diferentes etiquetas de tiempo). Para dos eventos cualquiera A y B, si A ocurre antes que B, entonces TS(A) < TS(B). El principal inconveniente de la definicin anterior es que el manejo de la relacin "ocurre antes" no est definida, de manera precisa, si dos eventos A y B ocurren en dos diferentes sitios, esto, debido a que no se tiene un "reloj global" para medir el tiempo exacto de ocurrencia de todos los eventos en el sistema distribuido. Una definicin precisa de la relacin "ocurre antes" en un sistema distribuido es la siguiente. Se asume que se conoce el significado de la declaracin " el evento A ocurri antes que el evento B en el sitio i", La relacin "ocurre antes", denotada por puede ser generalizada en un sistema distribuido por medio de las siguientes reglas: 1. 2. 3. Si A y B son dos eventos en el mismo sito y A ocurre antes que B, entonces A B. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir el mensaje de A, entonces A B. Si A B y B C, entonces A C.

La relacin es parcialmente ordenada. Se puede llamar a dos eventos A y B pseudosimultneos debido a que en ocasiones no es posible saber cual de los casos ocurre realmente A B o B A.

Bases de Datos Distribuidas

107

Fundamentos de las Bases de Datos Distribuidas

Considrese el siguiente ejemplo, Los eventos A y D, B y E, B y F, C y E, C y F son pseudosimultneos. La relacin de tiempo entre dos eventos pseudosimultneos no puede ser determinada. La segunda propiedad de la definicin de estampa del tiempo se puede ver de una manera precisa como sigue: Ntese que, si Ay B son pseudosimultneos, es posible que TS(timestamp) (A) < TS(B) o

Sitio 1 A Mensaje M1

Sitio 2 D

Mensaje M2

C Tiempo Local

Tiempo Local

que TS(B) < TS(A). De cualquier forma, Cuando se tienen asignadas las etiquetas a los eventos, el orden es definido entre ellos, aun si algunos son pseudosimultneos. Considrese ahora la generacin de las etiquetas de tiempo. El primer requisito, que sean nicas, se puede satisfacer de manera sencilla en un sistema distribuido. Es suficiente con que cada sitio agregue a cada etiqueta de tiempo local nica, el identificador del sitio en el cual fue generada, en la posicin menos significativa. Lo anterior es necesario para evitar que las etiquetas generadas por un sitio sean consideradas como mayores a las generadas en otros sitios.

Bases de Datos Distribuidas

108

Fundamentos de las Bases de Datos Distribuidas

El segundo requerimiento es el ms complicado de satisfacer.

Primero, es

necesario utilizar en cada sitio un contador, el cual ser incrementado cada vez que se genere una nueva etiqueta, esto con el fin de mantener un orden de estas dentro de un mismo sitio. Sin embargo, la sincronizacin entre los contadores de diferentes sitios podra llegar a ser difcil. Es posible que el sitio 1 genere ms etiquetas que el sitio 2, y por lo tanto el contador del sitio 1 se incrementara ms rpido. Los contadores de dos sitios se pueden mantener aproximadamente alineados, esto se logra, aadiendo a cada mensaje el valor del contador del sitio que lo enva. Si un sitio recibe un mensaje con una etiqueta con valor TS mayor al actual en este sitio, este incremento su contador a TS + 1. De esta manera los contadores de sitios cooperativos se mantendrn aproximadamente sincronizados; en el caso de que los dos sitios no sean sitios cooperativos, no es muy importante la sincronizacin de sus contadores. Considrese el ejemplo anterior, se asume que el contador en el sitio 1 tiene un valor inicial de 0 y el sitio 2 tiene un valor inicial de 10 en su contador. (x,y) representa al sitio y, el cual tiene un contador con valor x. Por lo tanto, inicialmente se tiene que TS(A)=(0,1) y TS(B)=(10,2). A y B son seudo simultneas con un orden arbitrario. Cuando el mensaje M2 llega al sitio 1, este genera la etiqueta de tiempo B; Ahora el contador local 1 es incrementado 4y pasa a ser TS(A)=(1 1, l). Cuando el mensaje Ml llega al sitio 2, y dado que la etiqueta de tiempo es menor en este sitio, el contador es simplemente incrementado y pasara a ser TS(B)=(1 1,2). Ntese que TS(A) y TS(B) difieren nicamente en el identificador del sitio en donde se generaron.

Finalmente, se vera que se tendrn que usar siempre contadores y no relojes, en la implementacin de etiquetas de tiempo. Sin embargo, en algunas implementaciones ser conveniente usar relojes en lugar de contadores. De esta manera se reflejar de manera ms real la secuencia en la ocurrencia de eventos.

4.1.7 Deadlocks distribuidos

Bases de Datos Distribuidas

109

Fundamentos de las Bases de Datos Distribuidas

La deteccin y solucin de deadlocks constituye una actividad importante de un sistema manejador de bases de datos. La deteccin de deadlocks es ms difcil en un sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro varios sitios. En la siguiente figura se muestra una grfica wait-for distribuido (Distributed Wait-for Graphics, DWFG) el cual contiene un ciclo y este corresponde a un deadlock. La notacin TAj hace referencia al agente A de la transaccin Ti.

Sitio 1

Sitio 2

Sitio 1

T1A1

T1A2

T1A1

T1A2

T2A1

T2A2

T2A1

T2A2

En la figura, hay dos sitios y dos transacciones Ti y T2, cada una consiste de dos agentes. Por simplicidad, se asumir que cada transaccin tiene solo un agente en cada sitio donde esta se ejecuta. Una flecha directa de] agente TAj a un agente TA, significa que TAj es bloqueado y espera al agente TrAs. Hay dos razones por las cuales un agente esperara a otro: 1. El agente TAj espera que el agente TAj libere un recurso que l

necesita; en este caso, Ti es una transaccin diferente de Tr, y los dos agentes estn en el mismo sitio, porque los agentes requieren nicamente recursos locales. En la figura de ejemplo, TIA, espera que T2A, libere recursos en el sitio 1. Este tipo de espera se representa por una flecha continua en la grfica. 2. El agente TiAj espera por el agente TiA, para realizar alguna solicitud de funcin; En este caso, los dos agentes pertenecen a la misma transaccin, y el agente TAj requiere que el agente TjA, ejecute alguna funcin en un sitio diferente. Este tipo de espera es representado por una flecha discontinuo en la grfica.

Bases de Datos Distribuidas

110

Fundamentos de las Bases de Datos Distribuidas

La porcin de una DWFG que contiene nicamente los nodos y flechas concernientes a un solo sitio se llama grfica wait-for local (Local Wait-For Graphics, LWFG). Dichas LWFG se extienden con flechas, desde y hacia los nodos los cuales representan a agentes que tienen conexin con el nodo local. En el ejemplo, la segunda figura representa una LWFG, los nodos cuadrados son llamados puertos de entrada si tienen una flecha hacia dentro de la grfica, y puertos de salida si las flechas salen. Un deadlock es local si es causado por un ciclo en una LWFG o distribuido si es causado por un ciclo en una DWFG el cual no esta contenido en una LWFG. La deteccin de un deadlock distribuido es una tarea que requiere el intercambio de informacin entre los diferentes sitios del sistema. La solucin a un deadlock involucro la seleccin de una o ms transacciones que pueden se abortadas y reiniciadas. Cuando la transaccin es abortada, esta libera los recursos, para que otras transacciones puedan ser procesadas. Un criterio para seleccionar que transaccin ser abortada, pudiera ser el que se aborte la transaccin que implique el menor costo en dicha operacin (l abortar una transaccin requiere de operaciones de deshacer). Otros criterios podran ser, el abortar la transaccin ms joven; abortar la transaccin que tiene la menor cantidad de recursos; o abortar la transaccin que requiere ms tiempo para terminar. La redundancia incremento la posibilidad de un deadlock. Considrense, por ejemplo, dos transacciones Ti y T2, ambas bloquean de manera exclusiva el mismo dato X. Si X no esta replicada, entonces una transaccin obtendra el bloqueo y se ejecutara mientras que la otra tendra que esperar. En el otro caso, X esta replicado, se tiene dos copias X, Y X2 en los sitios 1 y 2 y ambas transacciones utilizan la estrategia write-locks-all, entonces, la siguiente secuencia de eventos en los sitios 1 y 2 determina un deadlock: Sitio 1: T1 bloquea X1 ; T2 espera Sitio2 : T2 bloquea X2; T1 espera En este punto la DWFG contiene un ciclo, y por lo tanto un deadlock.

Bases de Datos Distribuidas

111

Fundamentos de las Bases de Datos Distribuidas

4.2 Recuperacin
Nada trabaja perfectamente el 100% de las veces. Esta simple observacin al

parecer trivial, tiene grandes consecuencias en el diseo de sistemas para computadoras, en general, y para sistemas de bases de datos, en particular. Tales sistemas deben incorporar, no solamente una variedad de verificaciones y controles para reducir la posibilidad de una falla, sino adems y de manera ms significativa un conjunto exacto de procedimientos para recuperacin de las fallas que, inevitablemente, ocurren a pesar de estas verificaciones y controles. La recuperacin en un sistema de bases de datos, significa, primero que nada recuperar la propia base de datos, esto es, restaurar la base de datos a un estado que se sabe es correcto, despus de que una falla la ha llevado a un estado incorrecto o al menos incierto. Existen muchas causas de falla, por ejemplo, errores en la programacin en una aplicacin, en el sistema operativo de apoyo, en el propio manejador de bases de datos, errores en el hardware en un dispositivo, virus, ete. El principio en el cual se basa la recuperacin se puede resumir en una sola palabra, redundancia. Esto es la forma de proteger la base de datos y asegurarla de manera de que cualquier parte de la informacin almacenada en ella pueda ser reconstruida de alguna otra informacin almacenada redundantemente en alguna parte del sistema, aunque, el hecho de incluir algn mtodo de procesamiento o almacenamiento en espejo, no nos garantiza que no ocurra alguna falla, por lo que de cualquier manera se debe incluir algn procedimiento de recuperacin, el cual puede consistir en forma general de lo siguiente:

1. 2.

Peridicamente, tal vez diario, hacer una copia de respaldo de la base de datos completa. Cada vez que se haga un cambio en la base de datos, se escribe un registro que contiene los valores anteriores y los nuevos del registro modificado en un conjunto de datos especial llamado bitcora.

3.

Si ocurre una falla hay dos posibilidades: a) Que la base de datos no se halla daado pero su contenido es incierto (por ejemplo, la terminacin anormal de un programa en medio de una
112

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

secuencia de actualizaciones lgicamente relacionadas) en este caso la base de datos se restaura a un estado correcto utilizando la bitcora para deshacer todas las actualizaciones "INCIERTAS' que hayan sido realizadas en ese programa. b) La base de datos se daa fsicamente (por ejemplo, debido a algn problema de hardware) la solucin en este caso, consiste en recuperar la base de datos utilizndola copia de respaldo ms reciente, y despus aplicndole la bitcora para hacer los cambio hechos desde el momento en que se hizo el respaldo hasta el momento en el que ocurri la falla.

4.2.1 Transacciones
El propsito fundamental de un sistema de bases de datos es realizar transacciones. Una transaccin es una unidad de trabajo, que consiste de la ejecucin de una secuencia de operaciones lgicamente relacionadas de una aplicacin especifica que inicia con el operador especial "BEGIN TRANSACTION y termina con la operacin COMMIT o ROLLBACK. El commit se usa para indicar una terminacin exitosa (la unidad de trabajo ha terminado con xito), el rollback se utiliza para indicar una terminacin no exitosa, es decir, la unidad de trabajo no puede ser terminada completamente debido a que ha ocurrido una condicin excepcional. La ejecucin de un programa puede corresponder a una secuencia de vanas transacciones, una detrs de otra.

Las transacciones no se pueden anidar, esto es el begin transaction puede ser ejecutado solamente cuando la aplicacin no tiene una transaccin en progreso, por otro lado el commit y el rollback se pueden ejecutar solamente cuando se esta ejecutando una transaccin. Todas las acciones recuperables deben ser ejecutadas dentro de los limites de una transaccin, una operacin recuperable es una operacin que puede ser deshecha o rehecha en el caso de alguna falla, es decir son las operaciones que se deben registrar en la bitcora. Las actualizaciones en la base de datos y los mensajes de entrada-salida son operaciones recuperables.
113

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

Las transacciones son proposiciones de todo o nada, se debe garantizar al usuario que cada transaccin es ejecutada completamente o no se ejecuta en lo absoluto. El requerimiento es que el sistema considerado como procesador de transacciones deber ser confiable, las transacciones no se debern perder o ser hechas parcialmente o hechas ms de una vez. Al aceptar el mensaje de entrada deber garantizar que una transaccin se ejecute una vez que cualquier actualizacin sobre la base de datos producida por la transaccin sea aplicada una vez y que cualquier mensaje de salida producido por la transaccin sea transmitido al usuario solamente una vez, el manejador de recuperacin es el responsable de proveer esa confiabilidad.

4.2.2 Manejo de mensajes


La recuperacin tiene varias aplicaciones tanto con el manejo de mensajes como de la base de datos, considerando el aspecto del manejo de mensajes de una transaccin, esta no solo actualiza la base de datos sino que adems enva mensajes al usuario final, si la transaccin llega a su terminacin planeada (commit o rollback explcito) se debe enviar un mensaje al usuario. Si la transaccin falla, es decir, no llega a su terminacin planeada a causa de un error, entonces el sistema debe deshacerla automticamente, el efecto en este caso ser como si la transaccin nunca se hubiera iniciado, sus actualizaciones en la base de datos debern ser deshechas y ningn mensaje generado por la transaccin deber ser mostrado. Los mensajes de salida debern ser transmitidos al usuario hasta que ocurra una terminacin planeada en la transaccin. El componente responsable del manejo de los mensajes es el manejador de comunicaciones de datos (DC manager), este manejador recibe el mensaje de entrada inicial dado por el usuario y al recibir el mensaje escribe un registro de bitcora que contiene el texto del mensaje. La transaccin utiliza una operacin get para obtener una copia del mensaje de una cola de entrada y una operacin put para colocar un mensaje de salida en una cola de mensajes de salida. Las operaciones commit y rollback explcitos, es decir planeados, provocan que el DC Manager escriba un registro en la bitcora. Para los mensajes contenidos en la cola de salida, realiza la transmisin de estos mensajes al usuario y remueve el mensaje de entrada de la cola de correspondiente. Si la transaccin falla, el sistema automticamente genera un

Bases de Datos Distribuidas

114

Fundamentos de las Bases de Datos Distribuidas

rollback (implcito) y esto provoca que el DC Manager descarte los mensajes de la cola de salida. 4.2.3 Estructura general de los registros de bitcora Registro de control

Identificadores (id, transaccin, fecha y hora, usuario, id. equipo, etc.)


Comandos (Begin transaction, Commit, Rollback) Mensajes ldentificadores Tipo de mensaje (entrada o salida) Texto de mensaje Operaciones identificadores Id. del registro Valores anteriores Valores actuales Considrese la siguiente tabla y transacciones para ejemplo: T1 Transferir 400 pesos de la cuenta Cl a C4 T2 Depositar a la cuenta C5, 3000 pesos T3 Dar de alta la cuenta C7 con 5000 pesos T4 Transferir 1000 pesos de la cuenta Cl a C3

Id cuenta C1 C2 C3 C4 C5 C6

Saldo 1000 500 3200 8000 1532 4553

Bases de Datos Distribuidas

115

Fundamentos de las Bases de Datos Distribuidas

En la bitcora se almacenan los mensajes de entrada y salida, las operaciones de alta, baja, depsito y retiro, as como los registros de control para cada una de las transacciones: T1 T1 T1 T1 T1 T1 T2 T2 T2 T2 T2 T3 T3 T3 T3 T3 T4 T4 T4 T4 T4 usr23 usr23 usr23 usr23 usr23 usr23 usrO2 usrO2 usrO2 usrO2 usr02 usr45 usr45 usr45 usr45 usr45 usr87 usr87 usr87 usr87 usr87 Begin transaction MsgEntrada Transferencia C1 C4 400 (Retiro) (Deposito) (mensaje) Commit Begin Transaction ME D MS Commit Begin ME A ms Commit Begin Transaction ME R MS Rollback Transferencia C1 C3 1000 C1 600 Fondos C1 -400 Insuficientes Transaction Alta C7 5000 C7 5000 Registro Completado Deposito C5 3000 C5 1532 C5 4532 Deposito Completado C1 1000 C1 600 C4 8000 C4 8400 Transferencia Completada

Dando como resultado siguiente la tabla:

Id cuenta C1 C2 C3

Saldo 600 500 3200

Bases de Datos Distribuidas

116

Fundamentos de las Bases de Datos Distribuidas

C4 C5 C6 C7

8400 4532 4553 5000

4.2.4 Tipos de fallas


Una operacin rollback permite asegurarse de que una falla no corrompa la base de datos, en el caso de que la transaccin por si misma descubra la condicin de la falla, desafortunadamente la mayor parte de las fallas no se pueden anticipar fcilmente y no se puede dejar al programador de la aplicacin el manejarlas de esta manera. Los tipos de fallas que pueden ocurrir, caen en las siguientes categoras: 1. Fallas locales de la transaccin, que son detectadas por el cdigo de la aplicacin (Por ejemplo, una condicin de fondos insuficientes en una transaccin bancaria). 2. Fallas locales de transaccin, que no son explcitamente manejadas por el cdigo de la misma, por ejemplo un overflow aritmtico, una divisin entre cero, una violacin de seguridad, etc. 3. Fallas del sistema que afectan a todas las transacciones que se encuentran en ejecucin, pero que no daan la base de datos (por ejemplo, una falla en el CPU). 4. Fallas en el medio que daan la base de datos o alguna porcin de esta y afectan a todas las transacciones que estn utilizando esta parte (Por ejemplo, un aterrizaje de las cabezas de un disco duro).

4.2.5 Fallas de transaccin


Este trmino se usa para indicar una falla causada por una terminacin no planeada y anormal de un programa. Las condiciones que pueden causar esta terminacin no planeada, incluyen overflow aritmtico, divisin entre cero, Colaciones de seguridad, lo que ocurre cuando se da una condicin de este tipo, por regla general es lo siguiente:

Bases de Datos Distribuidas

117

Fundamentos de las Bases de Datos Distribuidas

1. Cuando se presenta una condicin de error, el sistema enciende una condicin para ese tipo de error en particular por ejemplo, divisin entre cero. El programador tiene la opcin de incluir explcitamente el cdigo correspondiente para manejar esta condicin, si no se incluye este cdigo, el sistema realiza la siguiente accin. 2. El sistema enciende una condicin de error generalizada, de nuevo el programador tiene la opcin de incluir el cdigo correspondiente para manejar esta condicin o permitir que el sistema tome la siguiente accin. 3. En este punto el sistema provoca la terminacin anormal del programa y enva el mensaje correspondiente al usuario, y es solamente en este punto que se dice que a ocurrido una falla de transaccin. En general se dice que una falla de transaccin ocurre si y solo si el programa termina de manera no planeada, es decir, si ocurre un error para el cual no hay un cdigo incluido en la aplicacin que maneje explcitamente ese error. La ejecucin de un rollback explcito no esta considerado como una falla de transaccin, sino como una terminacin anormal planeada de la transaccin, no del programa. Una falla de transaccin significa que la transaccin no ha llegado a su terminacin planeada, por lo que es necesario que el sistema force un rollback, esto es, que deshaga cualquier cambio que haya hecho la transaccin en la base de datos y que cancele cualquier mensaje de salida que se haya producido para hacer como si nunca se hubiera iniciado. Deshacer los cambios involucro el trabajar hacia atrs en la bitcora leyendo todos aquellos registros de bitcora generados por la transaccin hasta que se encuentre un registro de inicio de transaccin (begin transaction) para cada registro localizado en la base de datos. El cambio que representa un registro de bitcora se deshace reemplazando los nuevos valores en la base de datos por los valores antiguos registrados en la bitcora.

4.2.6 Bitcora en lnea


De la descripcin del procedimiento para deshacer una transaccin dada anteriormente se puede observar que el manejador de recuperacin necesita tener la posibilidad de accesar los registros de bitcora de una manera selectiva en lugar de

Bases de Datos Distribuidas

118

Fundamentos de las Bases de Datos Distribuidas

una manera secuencias, por lo tanto, es conveniente que la bitcora se pueda guardar en un dispositivo de acceso directo, sin embargo, un sistema de base de datos grande puede generar al orden de varios gigabites de bitcora al da, por lo que es claramente inconveniente el mantener la bitcora completa en lnea. Una posible solucin podra ser lo siguiente: La bitcora activa es mantenida en el dispositivo de acceso directo. Cuando el archivo de bitcora se llena, el administrador de la bitcora, activa otro archivo de bitcora, donde se almacenaran los siguientes registros de bitcora, mientras que el otro archivo se respalda en algn medio. Si una transaccin es muy larga y en dado momento el archivo de bitcora se llena y esta transaccin aun no termina, el sistema provoca un rollback y todas las operaciones realizadas por esta se deshacen, y es reiniciada posteriormente, cuando el nuevo archivo de bitcora este activo.

4.2.7 Transacciones grandes


Una transaccin es tanto una unidad de recuperacin como una unidad de trabajo, esto sugiere que, una transaccin debe de ser corta con el fin de reducir la cantidad de trabajo que se tiene que deshacer y quizs, posteriormente rehacer en el caso de una falla, esta, adems reduce la posibilidad de que una transaccin falle debido a un overflow en la bitcora. Si una aplicacin es muy grande, lo ms adecuado es subdividirla en varia transacciones sin afectar el concepto de transaccin.

4.2.8 Compresin de bitcora


Al momento de hacer el respaldo de la bitcora se puede eliminar parte de la informacin contenida en la misma. Con el fin de ocupar menor cantidad de espacio de almacenamiento posible, sin perjudicar el proceso de recuperacin, este proceso se puede realizar de la siguiente manera:

Bases de Datos Distribuidas

119

Fundamentos de las Bases de Datos Distribuidas

1. Debido a que la bitcora en cinta (respaldo) solo se utiliza para rehacer transacciones en el caso de que ocurra una falla en el medio, se pueden eliminar los registros de las transacciones que terminaron con rollback. 2. Se pueden eliminar tanto los mensajes de entrada como los de salida. 3. Se pueden eliminar los registros de control, debido a que no es necesario hacer la recuperacin, transaccin por transaccin, pues se hace un barrido y se rehacen todas. 4. Se puede eliminar el identificador de la transaccin, el del usuario, fecha, hora, etc. (identificador de transaccin no es lo mismo que tipo de transaccin). 5. Se puede eliminar la parte UNDO de cada registro que representa una actualizacin sobre la base de datos.

6. Se eliminan los apuntadores al registro anterior y registro siguiente. 7. Se eliminan los registros de la bitcora que modifican el mismo registro de la
base de datos quedando registrado nicamente la ltima actualizacin. Considerando la bitcora de la seccin 4, 2, 3, la cual despus de la compresin, quedara como sigue:

T1 T1 T2 T3

R D D A

C1 C4 8400 C5 4532 C7 5'000

600

Con el fin de optimizar el proceso de recuperacin se puede ordenar los registros de la bitcora de acuerdo con el orden fsico que tienen los registros en la base de datos, cuya actualizacin representan los registros de la bitcora.

4.2.9 Fallas del sistema


"Fallas del sistema significa que algn evento caus que el sistema se detuviera y esto requerir un subsecuente reinicio del sistema: El contenido del almacenamiento primario, en particular el contenido de todo los buffers de entrada/salida (I/O), se

Bases de Datos Distribuidas

120

Fundamentos de las Bases de Datos Distribuidas

pierde, pero la base de datos no sufre dao alguno. As, las transacciones que en el momento de la falla se estuvieran ejecutando, se debern de deshacer, esto, si es que estas no haban terminado. Pero, como podra el manejador de recuperacin saber al momento del restablecimiento, que transacciones deshacer. Esto se puede resolver buscando en la bitcora desde el principio, identificando aquellas transacciones para las cuales hay un registro de inicio de transaccin (BT), pero no un registro de terminacin (commit o rollback). Sin embargo, tal bsqueda podra consumir demasiado tiempo. Se puede reducir fuertemente la cantidad de bsqueda, introduciendo el principio de punto de verificacin (Checkpoint). El principio de check-point es muy simple: A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o nmero de entradas de bitcora, el sistema realiza un check-point que consiste en los siguientes pasos: 1. Forza el contenido de los buffers de bitcora hacia la bitcora fsica. Esto obliga la escritura de cualquier registro de bitcora que aun permanezca en la memoria principal. 2. Forza la escritura de un registro de check-point en la bitcora. 3. Forza la escritura del contenido de los buffers de la base de datos, en la base de datos almacenada fsicamente. Esto obligar la escritura de cualquier actualizacin que aun se encuentre en la memoria principal. 4. Escribe la direccin del registro de check-point incluido en la bitcora en un archivo de restablecimiento.

El registro de check-point contiene la siguiente informacin: 1. Una lista de todas las transacciones activas al momento del check-point. 2. La direccin del registro de bitcora ms reciente de cada una de estas transacciones.

Bases de Datos Distribuidas

121

Fundamentos de las Bases de Datos Distribuidas

Al momento del restablecimiento, el manejador de recuperacin obtiene la direccin del registro de check-point ms reciente del archivo de restablecimiento, localiza este registro de bitcora y procede a buscar adelante en la bitcora, desde este punto hasta el final. Como resultado de este proceso el manejador de recuperacin tiene la posibilidad de determinar, tanto las transacciones que tiene que deshacer, como las transacciones que tienen que ser rehechas, con el fin de llevar la base de datos a un estado correcto. Para el propsito del restablecimiento, las transacciones pueden ser clasificadas en 5 categoras:

Tipo T1 T2 T3 T4 T5

Descripcin Terminan antes del check-point Inician antes del check-point y terminan despus de este Inician antes del check-point, sin embargo no han terminado al momento de la falla. Inician despus del check-point y terminan antes de que ocurra la falla Inician despus del check-point, pero no termina porque se presenta la falla.

T1 T2 T3 T4 T5

Bases de Datos Distribuidas

122

Fundamentos de las Bases de Datos Distribuidas

Check Point

Momento de la falla

Al momento del restablecimiento, las transacciones del tipo T3 y T5 se deben deshacer y las del tipo T2 y T4 debern ser rehechas, ya aunque las transacciones se realizaron completas, no hay garanta de que sus actualizaciones hayan sido escritas en la base de datos. Las transacciones del tipo Tl no se consideran en al proceso de recuperacin, ya que al realizar el paso 3 del check-point sus actualizaciones se escribieron en la base de datos. Para la recuperacin se procede a deshacer todos los cambios hechos por las transacciones que estn en la lista UNDO de la siguiente manera: 1. Se lee hacia atrs, secuencialmente la bitcora desde el final hasta el registro de check-point, s el registro recuperado pertenece a una transaccin de la lista UNDO, se deshace el movimiento que este representa. 2. A partir del registro de check-point se hace una lectura selectiva de las transacciones que estn tanto listadas en el registro de check-point como en la lista de UNDO, hasta localizar el begin transaction de cada una de ellas.

3. Para rehacer las transacciones del tipo T2 y T4, es necesario iniciar una lectura
secuencial de la bitcora a partir del registro de check-point y rehacer el cambio que representa cada registro de la bitcora que pertenezca a las transacciones de la lista REDO.

4.2.10 Fallas en el medio de almacenamiento


Este tipo de falla en el que se daa el medio de almacenamiento, daa parte o toda la base de datos, y las transacciones que estaban usando esa parte se ven afectadas, en este caso, los respaldos realizados peridicamente, juegan un papel fundamental, el proceso de recuperacin consiste en lo siguiente:

Bases de Datos Distribuidas

123

Fundamentos de las Bases de Datos Distribuidas

Una vez detectada la falla se procede a reemplazar el medio de almacenamiento y se restaura la base de datos a partir del ultimo respaldo, y enseguida se le aplican los movimientos registrados en la bitcora de las transacciones que terminaron con commit. La bitcora debe contener todos los movimientos efectuados desde que se hizo el ultimo respaldo hasta el momento de la falla. La bitcora implica todos los movimientos que se encuentran en la parte activa, como las partes que se respaldaron. Considrese la tabla de la seccin 4.2.3. La tabla cuentas fue respaldada antes de que se realizaran las transacciones Tl, T2, T3 y T4, dichas transacciones fueron registradas en la bitcora, la cual fue sometida a un proceso de compactacin y respaldo. Supngase que el disco duro en el cual estaba almacenada la tabla de cuentas se daa, y es necesario recuperarla a partir del respaldo en el disco duro nuevo, siguiendo el proceso de recuperacin.

1.-

Se restaura la base de datos del medio de respaldo. Cuentas Id_cuenta C1 C2 C3 C4 C5 C6 Saldo 1000 500 3200' 8000 1532 4553

2.- Se aplican los movimientos almacenados en la bitcora, substituyendo directamente el valor almacenado en la tabla por el valor obtenido de la bitcora. Bitcora T1 T1 T2 T3 Id_cuenta C1 C2 Saldo 600 500 R D D A C1 600 C4 8400 C5 4532 C7 5000

Bases de Datos Distribuidas

124

Fundamentos de las Bases de Datos Distribuidas

C3 C4 C5 C6

3200 8400 1532 4553

Id_cuenta C1 C2 C3 C4 C5 C6

Saldo 600 500 3200 8000 1532 4553

Id_cuenta C1 C2 C3 C4 C5 C6

Saldo 600 50 3200 8400 4532 4553

Id_cuenta C1 C2 C3 C4 C5 C6 C7

Saldo 600 500 3200 8400 4532 4553 5000

Bases de Datos Distribuidas

125

Fundamentos de las Bases de Datos Distribuidas

La tabla que resulta de la operacin de recuperacin es ahora idntica a la tabla que se tena antes de la falla del disco duro.

4.3 Integridad
El trmino integridad se usa en el contexto de la base de datos con el significado de correctez o validez, el problema de la integridad es el asegurarse que la base de datos sea correcta, esto es, proteger la base de datos de transacciones invalidas que pueden ser provocadas por errores al introducir los datos, por errores por parte del operador o del programador de la aplicacin, por fallas del sistema, y aun por falsificacin deliberada. El ultimo caso, sin embargo, no tiene que ver con la integridad, sino con la seguridad- El proteger la base de datos de operaciones que son legales es responsabilidad del subsistema de seguridad, por lo tanto, se asume que el usuario esta autorizado para la actualizacin en cuestin y que la actualizacin es valida. Se asume la existencia de un subsistema de integridad con las siguientes responsabilidades: 1. 2. Monitorear las transacciones especialmente, operaciones de actualizacin y deteccin de violaciones a la integridad de la base de datos. En el caso de una violacin, tomar la accin apropiada, por ejemplo, rechazando la operacin, reportando la violacin o corrigiendo el error. Con el fin de ejecutar estas acciones, se le debe de proveer al subsistema de integridad, un conjunto de reglas que define que errores debe verificar y que hacer si se detecta el error. La estructura general de una regla de integridad es la siguiente: Etiqueta: [condicin de activacin] Restriccin [ELSE respuesta en caso de violacin]

Bases de Datos Distribuidas

126

Fundamentos de las Bases de Datos Distribuidas

La condicin de activacin define el momento en el que se verifica que se cumpla la regla. Una restriccin indica las acciones que se deben de realizar para que la base de datos cumpla con la regia, y la respuesta en caso de violacin, corresponde a un conjunto de instrucciones que se van a ejecutar en el caso de que no se cumpla con la restriccin. Las reglas de integridad se expresan en lenguajes de alto nivel, por ejemplo SQL, y son compilada y almacenadas en el diccionario de datos de la base de datos. La mayor ventaja de esto es que las validaciones son manejadas por el DBMS, en lugar de las aplicaciones individuales. Otra de las ventajas es que las reglas se concentran en el diccionario de datos en lugar de estar distribuidas en los programas de aplicacin, por lo que es ms fcil entenderlas en su totalidad, y por lo tanto modificarlas en caso de ser necesario. Se tiene, adems, mayor oportunidad de detectar contradicciones y redundancias en ellas, as como tambin conseguir que el proceso de validacin se ejecute ms eficientemente. Debido a que las reglas son almacenadas en el diccionario de datos, es posible utilizar el lenguaje de consulta normal del sistema para hacer preguntas con respecto a las mismas. Las reglas de integridad se pueden dividir en dos categoras: Reglas de integridad de dominio. Reglas de integridad de relacin.

Las reglas de integridad de dominio conciernen a la admisibilidad de un valor determinado como valor candidato para un atributo determinado, considerado de manera aislada, esto es, independientemente de su relacin con otros valores en la base de datos. Las reglas de integridad de relacin conciernen a la admisibilidad de una tupla determinada como candidato para la insercin en una relacin determinada o la asociacin entre tuplas de una relacin con otra.

4.3.1 Reglas de integridad de dominio

Bases de Datos Distribuidas

127

Fundamentos de las Bases de Datos Distribuidas

Cada atributo de cada relacin esta definido sobre un dominio identificado en la definicin de la relacin, para el atributo A de la relacin R que se define sobre el dominio D, cualquier valor dado como candidato del atributo A debe pertenecer a D. La definicin del dominio D entonces constituye una importante regla de integridad, la cual deber verificar en todas las operaciones de insercin y actualizacin que involucran cualquier atributo definido sobre D. La regla de integridad de dominio, no es otra que, la definicin de ese dominio. Las violaciones a las reglas de integridad de dominio ocurren lo suficientemente seguido como para justificar algunas utileras especiales para facilitar su manejoCada dominio es un subconjunto de un dominio base y hereda por lo tanto, las caractersticas de ese dominio base (los dominios base son el conjunto de todas las cadenas de caracteres, el conjunto de todos los nmeros enteros, el conjunto de todos los nmeros reales, etc.). La sintaxis de una definicin de dominio puede ser la siguiente: DLC nombre del dominio [PRIMARY] DOMAIN Tipo de datos [PREDICADO] [ELSE respuesta en caso de violacin]

4.3.2 Reglas de integridad de relacin


La sintaxis de una regla de integridad de relacin puede ser la siguiente: Etiqueta: [Condicin de activacin] restriccin [ELSE respuesta en caso de violacin de la regia] Condicin de activacin: WHEN COMMITING BEFORE INSERTING nombre-del-registro [FROM estructura] BEFORE UPDATING nombre-del_registro [FROM estructura]

Bases de Datos Distribuidas

128

Fundamentos de las Bases de Datos Distribuidas

BEFORE UPDATING nombre-de-columna [FROM nombre-de-campol BEFORE DELETING nombre del registro AFTER INSERTING nombre-del-registro AFTER UPDATING nombre-del-registro AFTER UPDATING nombre-de-columna AFTER DELETING nombre-del-registro

Las siguientes notas explican la sintaxis de las reglas de integridad:

1. La condicin de activacin, si se especifica, consiste de una sola clusula when


commiting o de una lista de clusulas Before y/o After separadas por comas, en el caso de que no se especifique una condicin de activacin, se asume por default las siguientes condiciones de activacin: AFTER INSERTING tabla AFTER UPDATING tabla 2. Todos los parmetros mencionados en una condicin de activacin deben tener el mismo cursor, ya sea explcito o implcito, en esta regla se asegura que todas las clusulas Before y/o After incluidas en una regla de integridad determinada se refiere al mismo registro, por lo que cualquier referencia al registro por sus campos en la restriccin o en la respuesta en caso de violacin no es ambigua. 3. Si se especifica la clusula FROM en una sentencia BEFORE se asume que la estructura destinada, tiene la misma estructura interna que el registro a que se esta haciendo referencia, esto permite hacer referencia a los campos de la estructura indicada en el FROM de la restriccin y/o la respuesta en caso de violacin.

4. Si se especifican mltiples clusulas FROM en la condicin de activacin


determinada, entonces todas estas clusulas deben incluir un nombre de estructura como si se indicaran de forma aislada y esos nombre de estructura deben ser la misma.

Bases de Datos Distribuidas

129

Fundamentos de las Bases de Datos Distribuidas

5. Un cursor es un objeto cuyo valor es la direccin de algn registro especifico de


la base de datos, es decir, es un apuntador la un registro especfico, la expresin C R se refiere a una instancia especfica de un registro tipo R que el cursor C se encuentra apuntando. Cada cursor esta restringido a apuntar a registros de un tipo en particular y cada tipo de registro tiene un cursor de default que se llama de la misma manera que el tipo de registro.

6. La restriccin puede incluir referencias a parmetros, esto es referencias a cursores que estn en la lista de condiciones de activacin, as como tambin referencias a las variables o estructuras indicadas en la clusula, as como tambin pueden hacer referencia a registros y campos de las tablas implcitas en la regla. 7. La regla de integridad i: BEFORE cambio restriccin ELSE respuesta en caso de violacin; Es lgicamente equivalente a: i : si se va a realizar el cambio entonces sino (restriccin) entonces ejecuta respuesta en caso de violacin fin_si fin_si Si se ejecuta la respuesta en caso de violacin y este incluye la operacin REJECT entonces el cambio se realiza, de otra manera se realiza y regresa a la aplicacin.

8. La regla de integridad i: AFTER cambio restriccin ELSE respuesta en caso de violacin; Es lgicamente equivalente a: i : ejecuta el cambio

Bases de Datos Distribuidas

130

Fundamentos de las Bases de Datos Distribuidas

entonces sino (restriccin) entonces ejecuta respuesta en caso de violacin fin_si Si respuesta en caso de violacin y este incluye la operacin REJECT entonces el cambio se deshace 9. Las reglas de integridad de relacin pueden involucrar a ms de una relacin, por esta razn, se especifica generalmente en forma separada en lugar de incluirse como parte de la definicin de una relacin. En el ejemplo de la seccin 4.2.3, se tiene que la transaccin 4 fue desecha debido a que no se contaba con el saldo suficiente para realizar la operacin, esta validacin puede ser hecha por medio de reglas de integridad, por ejemplo: After Updating cuentas cuentas.saldo >= 0 Else Set return code to "Saldo insuficiente Reject; Esta regla verifica que el saldo sea igual o mayor a cero, despus de que se realizo la actualizacin, en caso de ser negativo la operacin es forzada a deshacerse y se enva el mensaje de "Saldo insuficiente". Otro ejemplo, sera una regla que revisara la base de datos antes de dar de alta una nueva cuenta, para evitar que, por error, se asigne un id que ya exista en la tabla de cuentas: Before inserting cuentas from variable-de-programa Not exist (cuentas. Id-cuenta = variable-de-Programa. ld_cuenta) Else Set return code lo El Id de la cuenta ya existe" Reject,

Bases de Datos Distribuidas

131

Fundamentos de las Bases de Datos Distribuidas

Supngase que se tiene una tabla en la cual se almacenan los movimientos mensuales de las cuentas (retiros, depsitos). En el momento en el que se desea borrar una cuenta de la tabla de cuentas, todos los movimientos de la cuenta debern de ser borrados para mantener la integridad de la base de datos. Esto se puede lograr por medio de una regla de integridad, definida como sigue: After deleting cuentas from variable-de-Programa Not exist (Movimientos where movimiento. Id-cuenta variable-de_programa.ld-cuenta) Else Delete from movimientos where movimientos.ld-cuenta = variable_de_programa.ld-cuenta; De esta manera se realizara un borrado en cascada de todos los movimientos de la cuenta eliminada.

4.4 Seguridad
Se utiliza el trmino de seguridad en un contexto de bases de datos para indicar la proteccin de la base de datos, acerca del acceso, alteracin o destruccin no autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los siguientes: 1. Aspectos legales, sociales y ticos. solicitada. 2. Controles fsicos. Considera si el cuarto de la computadora o las terminales debern estar cerrados o protegidos de alguna otra manera. 3. Polticas de acceso. Por ejemplo, como decide la empresa quien deber tener acceso a que datos. 4. Problemas de operacin. Por ejemplo, si se utiliza un esquema de control de acceso por password, como se mantiene estos en secreto. Por ejemplo, la persona que hace la

solicitud, tal vez un usuario de crdito, tiene acceso legal a la informacin

Bases de Datos Distribuidas

132

Fundamentos de las Bases de Datos Distribuidas

5. Controles de hardware. Por ejemplo, provee el procesador central de alguna caracterstica de seguridad, tales como llaves de proteccin de almacenamiento, o un modo de operacin privilegiada. 6. Seguridad del sistema operativo. proteccin. 7. Situaciones que conciernen especficamente al propio manejador de la base de datos. Por ejemplo, puede un usuario tener acceso al campo A y no tener acceso al campo B, si tanto A como B pertenecen al mismo registro. Algunos ejemplos de lo que podra verificar el subsistema de seguridad de una base de datos son los siguientes. Considerando la relacin empleados (num - emp, nombre, direccin, departamento, sueldo, evaluacin-desempeo), los niveles de acceso a esta relacin que podran ser otorgados a algn usuario en particular son: 1. El usuario tiene acceso sin restricciones a la relacin completa para cualquier tipo de operacin. 2. El usuario no tiene acceso a la relacin para ningn tipo de operacin. 3. El usuario puede consultar cualquier parte de la relacin pero no modificarla. 4. Puede ver exactamente un registro en la relacin (del cual es propietario) pero no cambiarlo. 5. Puede ver exactamente un registro (del cual es propietario) y dentro del registro puede alterar nicamente el nombre y la direccin. 6. Puede ver nicamente el nmero de empleado, el nombre, la direccin y el departamento de cualquier registro de la relacin y puede modificar solamente los valores del nombre, direccin y departamento. 7. Puede ver los campos del nmero de empleado, sueldo y puede modificar el sueldo pero solamente entre las 9 y 17 horas, y en una terminal localizada en la oficina de personal. 8. Puede ver los nmeros de empleado y sueldo, y puede alterar el valor del sueldo pero solo si el valor actual de este es menor de 5000. 9. El usuario puede aplicar operadores estadsticos al campo de sueldo, pero no leer o alterar valores individuales. Por ejemplo, cual es el esquema de

Bases de Datos Distribuidas

133

Fundamentos de las Bases de Datos Distribuidas

10. El usuario puede ver los campos de nmero de empleado, nombre y la evaluacin del desempeo, y puede alterar la evaluacin al desempeo si y solo si es el gerente del departamento.

4.4.1 Identificacin y autentificacin


De la definicin de seguridad se deduce que el sistema no debe permitir que se ejecute cualquier operacin sobre la base de datos a menos que el usuario este autorizado para realizada. En los sistemas multiusuario, el sistema operativo requiere de un nombre de usuario (Login Name) y de una contrasea (Password) para permitir al usuario el acceso al sistema. Existen algunos DBMS, tales como DB2 UDB de IBM, los cuales confan el control de acceso al sistema operativo, esto es, si el usuario logro ingresar al sistema operativo es un usuario valido para el DBMS y puede acceder a los datos. Existen, tambin, otros DBMS en los que el sistema mantiene un registro en el que se especifican los objetos que el usuario esta autorizado para accesar y las operaciones que tiene autorizado ejecutar sobre los objetos. Antes de accesar la base de datos, los usuarios se tendrn que identificar, esto es, decir quienes son. Este paso direcciona el sistema al registro del usuario (USER PROFILE) apropiado. Normalmente los usuarios necesitan autentificar su identidad a travs de password. El proceso de identificacin puede involucrar el que se provea al usuario con una cuenta que el puede teclear directamente en su termina] o a travs de algn otro medio (voz, huellas digitales o tarjetas). El proceso de autentificacin involucro el proporcionar informacin solamente conocida por el usuario propietario de la cuenta.

4.4.2 Reglas de autorizacin


El sistema debe permitir la definicin de reglas que debern ser expresadas en algn lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT

Bases de Datos Distribuidas

134

Fundamentos de las Bases de Datos Distribuidas

SELECT ON empleado TO Jones, esta instruccin especifica que el usuario Jones esta autorizado para ejecutar operaciones de seleccin sobre la relacin empleados, esta informacin se almacena en el USER PROFILE de Jones. Las reglas de autorizacin sern compiladas y almacenadas en el diccionario de datos y una vez incluidas en este, el DBMS forzar que se cumplan. Es conveniente considerar al conjunto de todos los USER PROFILES como una matriz de autorizacin en la cual, los renglones corresponden a los usuarios y las columnas a los objetos de datos, de tal forma que A[I,J] representa al conjunto de reglas de integridad que se aplican al usuario I con respecto al objeto J. La granularidad de los objetos para los cuales pueden existir columnas en la matriz de autorizaciones es una medida de lo sofisticado del sistema; por ejemplo algunos sistemas soportan solamente a nivel de relaciones completas, mientras que otras permitirn la autorizacin a nivel de campos individuales. Sin embargo una medida significativa esta dada por el rango de caractersticas que se permite incluir en el cuerpo de la matriz.

4.4.3 Encriptacin de datos


Se ha asumido que los usuarios intentaran acceder la base de datos por los medios normales de acceso, esto es, accesado a la red por medio de un usuario y contrasea, a si mismo, que existe dentro del DBMS existe una matriz de accesos para este usuario en la cual se han especificado reglas de autorizacin para este. Considrese ahora el caso en que un "usuario" intenta acceder a la informacin rompiendo o eludiendo los mtodos de seguridad establecidos, por ejemplo, robando parte de la informacin almacenada en algn medio de respaldo, o corriendo algn programa que logre romper la seguridad del sistema operativo y del DBMS, o interceptando las lneas de comunicacin, es importante recordar que la mayor parte de la comunicacin dentro de una base de datos distribuida es hacia y desde fuera de la red de rea local. Una forma efectiva de prevenir que estos "usuarios puedan ver la informacin contenida en la base de datos, es la encriptacin de datos, esto es, almacenar y transmitir todos los datos, mensajes, contraseas en una forma encriptada. En el concepto de la encriptacin, los datos originales son llamados texto plano. El texto plano es encriptado por algn algoritmo de encriptacin, el cual requiere del texto
135

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

plano y de una llave de encriptacin, obteniendo as, la forma encriptada del texto plano, conocida como texto cifrado.

4.4.4 Encriptacin por sustitucin


El mtodo de sustitucin es uno de los mtodos ms sencillos de encriptacin de datos, es necesario tener una llave para determinar los caracteres de texto cifrado los cuales sustituirn a los caracteres del texto plano. A continuacin se presenta un ejemplo: Teniendo como llave de encriptacin la palabra ELIOT, se encriptar el siguiente texto: AS KINGFISHERS CATCH FIRE 1.llave: AS_KI 2.NGFIS HERS_ CATCH _FIRE Dividir el texto plano en grupos de caracteres de la misma longitud de la

Remplazar cada carcter del texto plano por un entero en el rango de 0-26,

usando_= 00, A=01, B=02, ..., Z=26: 0119001109 1407060919 0805181900 0301200308 0006091805 3.Repetir el paso 2 para la llave de encdptacin: 0512091520 4.Para cada grupo del texto plano, remplazar cada carcter por la suma,

mdulo 27, de su cdigo y el cdigo de la llave de encriptacin: 0119001109 1407060919 0805181900 0301200308 0006091805 0512091520 0512091520 0512091520 0512091520 0512091520 064092602 1919152412 1317000720 0813021801 0518180625

Bases de Datos Distribuidas

136

Fundamentos de las Bases de Datos Distribuidas

5.-

Remplazar cada cdigo por su correspondiente carcter, de acuerdo al del paso 2: FDIZB SSOXL MQ_GT HMBRA ERRFY

cdigo

El problema que se podra presentar en este mtodo es, como dificultarle a un posible "usuario infiltrado el hecho de determinar la llave de encriptacin. Es posible tambin combinar con este mtodo, el mtodo de permutacin, el cual consiste en reordenar los caracteres resultantes de a cuerdo a alguna secuencia, previamente definida.

4.4.5 Encriptacin de llave publica


En este esquema de encriptacin, la llave de encriptacin es conocida por todos, y cualquier persona puede convertir texto plano a texto cifrado. Pero la llave de desencriptacin es mantenida en secreto ( este esquema involucro dos llaves, una para encriptar y otra para desencriptar). La llave de desencriptacin no puede ser deducida a partir de la llave de encriptacin; de esta manera la persona que ejecuta la encriptacin no podr ejecutar la desencriptacin si no esta autorizada para hacerlo. Este mtodo de encriptacin se basa en los siguientes hechos: 1.- Existe un algoritmo rpido para determinar si cualquier nmero grande es primo. 2.- No hay un algoritmo rpido para determinar los factores primos de un nmero grande. Este mtodo funciona de la siguiente manera: 1.- Se eligen, de forma aleatoria, dos numero primos largos distintos p y q, para mayor seguridad deben de ser superiores a 80 dgitos. Obtngase el producto r = p * q

Bases de Datos Distribuidas

137

Fundamentos de las Bases de Datos Distribuidas

2.- Se elige, aleatoriamente, un entero grande e que es primo con respecto a (p -1) * (q - l); y que el mayor comn divisor entre e y (p -1) * (q - 1) es 1. Entonces e es la llave de encriptacin. 3.- Se calcula la llave de desencriptacin, d, la cual corresponde al nico inverso multiplicativo de e, mdulo (p -1) * (q - l); esto es: (d * e) mdulo (p -1) * (q - 1) = 1 4.- Se dan a conocer e y r, pero no d, la cual es la llave de desencriptacin. 5.- Para encriptar una parte del texto plano P ( se asume por simplicidad que es un entero menor a r ), y se reemplaza por el te)do cifrado C, obtenido de la siguiente manera: C = Pe mdulo r 6.- Para desencriptar una parte del texto cifrado, este es reemplazado por P, que se obtiene de la siguiente manera: P = Cd mdulo r A continuacin se presenta un ejemplo, por razones de facilidad se utilizaran nmeros pequeos: Dados p = 3, q = 5, P = 13 r = 3 *5 = 15 (p 1) * (q - 1) = (3 -1) * (5 - 1) = 8 se tiene e = 11 (es un numero primo mayor a p y q) ahora se calcula d

Bases de Datos Distribuidas

138

Fundamentos de las Bases de Datos Distribuidas

(d * 3) mdulo 8 = 1 La funcin mdulo obtiene nicamente el residuo de la divisin y se tiene que d = 3 cumple con esta condicin Ahora se encripta P de la manera siguiente: C = Pe mdulo r C = 1311 mdulo 15 = 1792160394037 mdulo 15 = 7 (este es el residuo de la divisin entera de 1792160394037 entre 15) Para desencriptar C se realiza el siguiente proceso: p = Cd mdulo r P = 73 mdulo 15 = 343 mdulo 15 = 13 este es el residuo de la divisin entera de 343 entre 15)

Bases de Datos Distribuidas

139

Fundamentos de las Bases de Datos Distribuidas

4.5 Resumen
Una transaccin accesa la base de datos usando primitivas de lectura y escritura. El conjunto de elementos de lectura de datos para una transaccin es llamado conjunto lector y el conjunto de elementos de escritura de datos para una transaccin es llamado conjunto escritor. Dos transacciones Ti y Tj se ejecutan serialmente en una planificacin S, si la ultima operacin de Ti precede a la primera operacin de Tj en S. En otro caso las transacciones se ejecutaran concurrentemente. En una planificacin, si la operacin O precede a la operacin O, se indica como O < Oj, es decir Oi se ejecuta primero que O. Las transacciones se ejecutarn lo ms concurrentemente posible, cuidando que esta ejecucin sea correcta. La definicin ms aceptada de correcto en una bitcora es basada en la seriabilidad: Una planificacin es correcta si esta es seriabilizable, esto es, que sea equivalente a una planificacin serial. Un mecanismo de control de concurrencia es correcto si permite a las transacciones ejecutarse en una secuencia tal que solo una planificacin sealizaba podra producir. Un mecanismo de control de concurrencia restringe las posibles secuencias de operacin ejecutados por una transaccin que fuerza a otra transaccin a esperar mientras la primera termina de realizar sus operaciones. Las siguientes dos condiciones son suficientes para decir que dos planificaciones son equivalentes: 1. 2. Cada operacin de lectura lee los mismos valores que fueron producidos por La operacin de escritura final es igual en ambas planificaciones.

las mismas operaciones de escritura en ambas planificaciones.

Bases de Datos Distribuidas

140

Fundamentos de las Bases de Datos Distribuidas

Es importante tambin considerar el hecho de que dos operaciones pueden llegar a caer en conflicto: Dos operaciones estn en conflicto si, ellas procesan el mismo dato y al menos una de estas operaciones es una operacin de escritura, y estas operaciones pertenecen a diferentes transacciones. Usando este concepto es posible obtener una definicin de planificacin equivalente de otra manera: Dos planificaciones S1 y S2 son equivalentes si por cada par de operaciones en conflicto O y Oj, donde O < Oj en S1, entonces O deber preceder a Oj en S2. En una base de datos distribuida, cada transaccin ejecuta operaciones en vanos sitios. La secuencia de operaciones procesada por las transacciones en un sitio es una planificacin local. Si se aplica en cada sitio un mecanismo de control de concurrencia se asegurara que todas las planificaciones locales son serializables. Sin embargo, la seriabilidad local no es suficiente para asegurar la exactitud de la ejecucin de un conjunto de transacciones distribuidas. La ejecucin de las transacciones T1, ..., Tn es correcta s:

1. 2.

Cada entrada local Sk es serializable. Existe un orden total de T1, ..., Tn tal que, si Ti < Ti en el orden total, entonces hay una entrada serial Sk tal que, Sk es equivalente a Sk ' y Ti < Tj en el Seal(Sk'), para cada sitio k donde ambas transacciones tienen algn proceso en ejecucin.

La anterior definicin puede ser explicada usando la definicin de conflicto: Sea T1, ..., Tn un conjunto de transacciones, y sea E una ejecucin de estas transacciones, modelado por el conjunto de entradas de bitcora Sl,... Sm. E es correcto (serializable) si existe un orden total de las

Bases de Datos Distribuidas

141

Fundamentos de las Bases de Datos Distribuidas

transacciones, y adems para cada par de operaciones en conflicto O y Oj de las transacciones Ti y Ti respectivamente, O precede a O en cualquier entrada Sl,.. Sn, si y solo si Ti precede Tj en el orden total. La idea bsica del bloqueo (lock) es que cuando una transaccin requiera accesar un registro, esta bloquee dicho registro antes de intentar el acceso, y cuando una transaccin intente bloquear un registro que anteriormente ya fue bloqueado por otra transaccin, la primera deber esperar a que la otra transaccin libere dicho bloqueo (unlock). Una transaccin siempre deber bloquear un registro de forma compartida antes de leer el contenido, y bloquear de modo exclusivo antes de escribir. Existen dos reglas de compatibilidad entre los modos de bloqueo: 1. 2. Una transaccin puede bloquear un registro, s este no esta bloqueado o s lo esta de manera compartida. Una transaccin puede bloquear de manera exclusiva, solo si el registro no esta bloqueado. Otra condicin que se deber de tener en cuenta es que, una transaccin no debe de requerir de un nuevo bloque despus de que se libere algn registro, esto quiere decir que la transaccin debe de tener un bloqueo de dos fases (2PL), esto porque la primera fase sera el bloqueo de todos los registros necesarios para realizar la transaccin, y la segunda fase es en la cual se hace la liberacin de todos los registros antes bloqueados. Los manejadores de transacciones locales interpretan las primitivas locales de bloqueo (bloqueo local compartido, bloqueo local exclusivo y, liberacin local), mientras que los agentes de la transaccin procesan las primitivas globales (bloqueo compartido, bloqueo exclusivo, y liberacin). Entender los aspectos peculiares del control distribuido de concurrencia es equivalente a comprender lo que el manejador distribuido de transacciones tiene que hacer para garantizar que la transaccin global tenga las caractersticas de sociabilidad y aislamiento.

Bases de Datos Distribuidas

142

Fundamentos de las Bases de Datos Distribuidas

El manejador de transacciones distribuidas tiene que traducir la primitiva de bloqueo emitida por un agente en un registro de tal manera que sea imposible que un bloqueo pase inadvertido por una transaccin. De esta manera, una primitiva de bloqueo es traducida en varias primitivas de bloqueo, tantas como copias de datos se deseen bloquear. Existen esquemas alternativos para lograr evitar conflictos en los bloqueos: 1. Write-locks-all, read-locks-one. En este esquema los bloqueos exclusivos son adquiridos en todas las copias, mientras que los bloqueos compartidos son adquiridos nicamente en alguna copia arbitraria. 2. Mayora de bloqueos. En ambos bloqueos compartido y exclusivo son requeridos en una mayora de las copias de los registros (el nmero de copias que se bloquean son estrictamente ms grande que el nmero de copias que no se bloquean). 3. Bloque de copia primaria. Una de las copias de cada dato es privilegiada (llamada copia primaria) y todos los bloqueos se hacen sobre esta copia. Considrese primero que si todas las transacciones logran un bloqueo de 2 fases, entonces todas las entradas de bitcora son serializables. Si una transaccin distribuida logra un bloqueo de dos fases entonces todas las subtransacciones en los diferentes sitios, lograrn separadamente un bloqueo de dos fases. Considrese ahora que, las transacciones T1, T2, ..., Tn requieren de un bloqueo de dos fases, cada una de estas transacciones requieren de bloquear un dato el cual, ya esta bloqueado por otra transaccin. Por lo tanto cada una de ellas tendr que esperar hasta que otra transaccin libere el bloqueo. Sin embargo, desde el momento en que las transacciones utilizan el bloqueo de dos fases, estas no pueden liberar el bloqueo, sino hasta que se logran todos los bloqueos requeridos por dicha transaccin. Por lo tanto n transacciones alcanzarn un estado de deadlock, y pueden estar esperando por siempre. Entonces, una de estas transacciones deber ser abortada por algn algoritmo de solucin de deadlock. En cualquier caso, el conjunto de transacciones no podr ocurrir.

Bases de Datos Distribuidas

143

Fundamentos de las Bases de Datos Distribuidas

Para lograr un anlisis del grado de concurrencia que es permitido por el algoritmo de control de concurrencia, es necesario incluir en el modelo de ejecucin la nocin de "operaciones concurrentes" en diferentes sitios. transacciones. En un sistema distribuido, es necesario, algunas veces, conocer si un evento A en algn sitio ocurri antes o despus que un evento B en un sitio diferente. Varios mtodos de control de concurrencia y algoritmos de prevencin de deadlock requieren determinar el orden en que se realizarn los eventos. La determinacin de un orden de eventos consiste en asumir que a cada evento A, el cual ocurre en un sistema distribuido, se asigna una etiqueta de tiempo TS(A) (timestamp) con las siguientes propiedades: 1. 2. TS(A) identifica de manera nica a A (diferentes eventos tienen diferentes etiquetas de tiempo). Para dos eventos cualquiera A y B, si A ocurre antes que B, entonces TS(A) < TS(B). La relacin ocurre antes, denotada por puede ser generalizada en un sistema distribuido por medio de las siguientes reglas: 1. Si A y B son dos eventos en el mismo sito y A ocurre antes que B, entonces AS. 2. Si el evento A consiste en enviar un mensaje y el evento B consiste en recibir el mensaje de A, entonces AB. 3. Si AB y BC, entonces AC. Se representan dos operaciones concurrentes colocndolas una sobre otra, en la ejecucin concurrente de

La deteccin y solucin de deadlocks constituye una actividad importante de un sistema manejador de bases de datos. La deteccin de deadlocks es ms difcil en un sistema distribuido que un centralizado, esto, debido a un ciclo de espera involucro varios sitios.

Bases de Datos Distribuidas

144

Fundamentos de las Bases de Datos Distribuidas

La figura se muestra una grfica wait-for distribuido (DWFG):

Sitio 1

Sitio 2

Sitio 1

T1A1

T1A2

T1A1

T1A2

T2A1

T2A2

T2A1

T2A2

Hay dos razones por las cuales un agente esperara a otro: 1. 2. T1A1 espera que T2A1 libere recursos en el sitio 1. Este tipo de espera se representa por una flecha continua en la grfica. El agente TiAj requiere que el agente TiAs ejecute alguna funcin en un sitio diferente. Este tipo de espera es representado por una flecha discontinuo en la grfica. La porcin de una DWFG que contiene nicamente los nodos y flechas concernientes a un solo sitio se llama grfica wait-for local. Dichas LWFG se extienden con flechas, desde y hacia los nodos los cuales representan a agentes que tienen conexin con el nodo local. Los nodos cuadrados son llamados puertos de entrada si tienen una flecha hacia dentro de la grfica, y puertos de salida si las flechas salen. Un deadlock es local si es causado por un ciclo en una LWFG o distribuido si es causado por un ciclo en una DWFG el cual no esta contenido en una LWFG. La solucin a un deadlock involucro la seleccin de una o ms transacciones que pueden se abortadas y reiniciadas. Un criterio para seleccionar que transaccin ser abortada, pudiera ser el que se aborte la transaccin que implique el menor costo en

Bases de Datos Distribuidas

145

Fundamentos de las Bases de Datos Distribuidas

dicha operacin.

Otros criterios podran ser, el abortar la transaccin ms joven;

abortar la transaccin que tiene la menor cantidad de recursos; o abortar la transaccin que requiere ms tiempo para terminar. Algo que se debe de tener en cuenta es que, la redundancia incremento la posibilidad de un deadlock. La recuperacin en un sistema de bases de datos, significa, primero que nada recuperar la propia base de datos, esto es, restaurar la base de datos a un estado que se sabe es correcto, despus de que una falla la ha llevado a un estado incorrecto o al menos incierto. El principio en el cual se basa la recuperacin es la redundancia. Esto es la forma de proteger la base de datos y asegurarla de manera de que cualquier parte de la informacin almacenada en ella pueda ser reconstruida de alguna otra informacin almacenada redundantemente en alguna parte del sistema. de lo siguiente: 1. 2. 3. Peridicamente, tal vez diario, hacer una copia de respaldo de la base de datos completa. Cada vez que se haga un cambio en la base de datos, se escribe un registro en un conjunto de datos especial llamado bitcora. Si ocurre una falla hay dos posibilidades: a) Que la base de datos no se halla daado pero su contenido es incierto en este caso la base de datos se restaura a un estado correcto utilizando la bitcora. b) La base de datos se daa fsicamente, la solucin en este caso consiste en recuperar la base de datos utilizndola copia de respaldo ms reciente. El propsito fundamental de un sistema de bases de datos es realizar transacciones. Una transaccin es una unidad de trabajo que inicia con el operador especial "BEGIN TRANSACTION" y termina con la operacin 'COMMIT' o "ROLLBACK". El commit se usa para indicar una terminacin exitosa, el rollback se utiliza para indicar una terminacin no exitosa. Se debe incluir algn procedimiento de recuperacin, el cual puede consistir en forma general

Bases de Datos Distribuidas

146

Fundamentos de las Bases de Datos Distribuidas

Todas las acciones recuperables deben ser ejecutadas dentro de los limites de una transaccin, una operacin recuperable es una operacin que puede ser deshecha o rehecha en el caso de alguna falla, que se deben registrar en la bitcora. Las transacciones son proposiciones de todo o nada, se debe garantizar al usuario que cada transaccin es ejecutada completamente o no se ejecuta en lo absoluto. Una operacin rollback permite asegurarse de que una falla no corrompa la base de datos, en el caso de que la transaccin por si misma descubra la condicin de la falla. Los tipos de fallas que pueden ocurrir, caen en las siguientes categoras: 1. Fallas locales de la transaccin, que son detectadas por el cdigo de la aplicacin. 2. Fallas locales de transaccin, que no son explcitamente manejadas por el cdigo de la misma. 3. Fallas del sistema que afectan a todas las transacciones que se encuentran en ejecucin, pero que no daan la base de datos. 4. Fallas en el medio que daan la base de datos o alguna porcin de esta y afectan a todas las transacciones que estn utilizando esta parte. El trmino fallas de transaccin se usa para indicar una falla causada por una terminacin no planeada y anormal de un programa. Lo que ocurre cuando se da una condicin de este tipo, por regla general es lo siguiente: 1. Cuando se presenta una condicin de error, el sistema enciende una condicin para ese tipo de error en particular. El programador tiene la opcin de incluir explcitamente el cdigo correspondiente para manejar esta condicin. 2. El sistema enciende una condicin de error generalizada, de nuevo el programador tiene la opcin de incluir el cdigo correspondiente para manejar esta condicin. 3. En este punto el sistema provoca la terminacin anormal del programa y enva el mensaje correspondiente al usuario, y es solamente en este punto que se dice que a ocurrido una falla de transaccin.

Bases de Datos Distribuidas

147

Fundamentos de las Bases de Datos Distribuidas

La ejecucin de un rollback explcito no esta considerado como una falla de transaccin, sino como una terminacin anormal planeada de la transaccin, no del programa. Una falla de transaccin significa que la transaccin no ha llegado a su terminacin planeada, por lo que es necesario que el sistema force un rollback. El trmino faltas del sistema significa que algn evento causo que el sistema se detuviera y esto requerir un subsecuente reinicio del sistema: El contenido del almacenamiento primario, se pierde, pero la base de datos no sufre dao alguno. As, las transacciones que en el momento de la falla se estuvieran ejecutando, se debern de deshacer, esto si es que estas no haban terminado. Esto se puede resolver buscando en la bitcora desde el principio, identificando aquellas transacciones para las cuales hay un registro de inicio de transaccin (BT), pero no un registro de terminacin (commit o rollback). El principio de check-point es muy simple: A cierto intervalos preestablecidos, por ejemplo, cada cierto tiempo o nmero de entradas de bitcora, el sistema realiza un check-point que consiste en los siguientes pasos: 1. 2. 3. 4. Forza el contenido de los buffers de bitcora hacia la bitcora fsica. Forza la escritura de un registro de check-point en la bitcora. Forza la escritura del contenido de los buffers de la base de datos, en la base de datos almacenada fsicamente. Escribe la direccin del registro de check-point incluido en la bitcora en un archivo de restablecimiento. El registro de check-point contiene la siguiente informacin: 1. Una lista de todas las transacciones activas al momento del check-point.

Bases de Datos Distribuidas

148

Fundamentos de las Bases de Datos Distribuidas

2.

La direccin del registro de bitcora ms reciente de cada una de estas

transacciones.

Al momento del restablecimiento, el manejador de recuperacin obtiene la direccin del registro de check-point ms reciente del archivo de restablecimiento, localiza este registro de bitcora y procede a buscar adelante en la bitcora, desde este punto hasta el final. Para el propsito del restablecimiento, las transacciones pueden ser clasificadas en 5 categoras: Tipo T1 T2 T3 T4 T5 Descripcin Terminan antes del check-point Inician antes del check-point y terminan despus de este Inician antes del check-point, sin embargo no han terminado al momento Inician despus del check-point y terminan antes de que ocurra la falla Inician despus del check-point, pero no termina porque se presenta la falla. Las transacciones del tipo T3 y T5 se deben deshacer y las del tipo T2 y T4 debern ser rehechas. Las transacciones del tipo T1 no se consideran en al proceso de recuperacin, ya que al realizar el paso 3 del check-point sus actualizaciones se escribieron en la base de datos. El trmino integridad se usa en el contexto de la base de datos con el significado de correctez o validez, el problema de la integridad es el asegurarse que la base de datos sea correcta. Se asume la existencia de un subsistema de integridad con las siguientes responsabilidades: 1. Monitorear las transacciones especialmente, operaciones de actualizacin y deteccin de violaciones a la integridad de la base de datos.

de la falla.

Bases de Datos Distribuidas

149

Fundamentos de las Bases de Datos Distribuidas

2.

En el caso de una violacin, tomar la accin apropiada, por ejemplo, rechazando la operacin, reportando la violacin o corrigiendo el error.

Con el fin de ejecutar estas acciones, se le debe de proveer al subsistema de integridad, un conjunto de reglas que define que errores debe verificar y que hacer si se detecta el error. Las reglas de integridad se expresan en lenguajes de alto nivel, por ejemplo SQL, y son compilada y almacenadas en el diccionario de datos de la base de datos. La mayor ventaja de esto es que las validaciones son manejadas por el DBMS, en lugar de las aplicaciones individuales. Otra de las ventajas es que las reglas se concentran en el diccionario de datos en lugar de estar distribuidas en los programas de aplicacin Las reglas de integridad se pueden dividir en dos categoras: Reglas de integridad de dominio. Reglas de integridad de relacin.

Se utiliza el trmino de seguridad en un contexto de bases de datos para indicar la proteccin de la base de datos, acerca del acceso, alteracin o destruccin no autorizada. Existen numerosos aspectos del problema de seguridad, entre ellos los siguientes: 1. 2. 3. 4. 5. 6. 7. Aspectos legales, sociales y ticos. Controles fsicos. Polticas de acceso. Problemas de operacin. Controles de hardware. Seguridad del sistema operativo. Situaciones que conciernen especficamente al propio manejador de la base

de datos.

Bases de Datos Distribuidas

150

Fundamentos de las Bases de Datos Distribuidas

De la definicin de seguridad se deduce que el sistema no debe permitir que se ejecute cualquier operacin sobre la base de datos a menos que el usuario este autorizado para realizarla, por lo que para cada usuario, el sistema debe mantener un registro, especificar los objetos que el usuario esta autorizado para accesar y las operaciones que tiene autorizados ejecutar sobre los objetos. Este paso se direcciona el sistema al registro del usuario (USER PROFILE) apropiado. El sistema debe permitir la definicin de reglas que debern ser expresadas en algn lenguaje de alto nivel, por ejemplo SQL utiliza el comando GRANT, GRANT SELECT, esta instruccin especifica que el usuario esta autorizado para ejecutar operaciones de seleccin sobre una relacin, esta informacin se almacena en el USER PROFILE. Las reglas de autorizacin sern compiladas y almacenadas en el diccionario de datos y una vez incluidas en este, el DBMS forzar que se cumplan. Es conveniente considerar al conjunto de todos los USER PROFILES como una matriz de autorizacin en la cual, los renglones corresponden a los usuarios y las columnas a los objetos de datos, de tal forma que A[I,J] representa al conjunto de reglas de integridad que se aplican al usuario 1 con respecto al objeto J. Se ha asumido que los usuarios intentaran acceder la base de datos por los medios normales de acceso, esto es, accesado a la red por medio de un usuario y contrasea, a si mismo, que existe dentro del DBMS existe una matriz de accesos para este usuario en la cual se han especificado reglas de autorizacin para este. Una forma efectiva de prevenir que "usuarios" no autorizados puedan ver la informacin contenida en la base de datos, es la encriptacin de datos, esto es, almacenar y transmitir todos los datos, mensajes, contraseas en una forma encriptada. En el concepto de la encriptacin, los datos originales son llamados texto plano. El texto plano es encriptado por algn algoritmo de encriptacin, el cual requiere del texto plano y de una llave de encriptacin, obteniendo as, la forma encriptada del texto plano, conocida como texto cifrado. El mtodo de sustitucin es uno de los ms sencillos mtodos de eneriptacin de datos, es necesario tener una llave para determinar los caracteres de texto cifrado

Bases de Datos Distribuidas

151

Fundamentos de las Bases de Datos Distribuidas

los cuales sustituirn a los caracteres del texto plano. Es posible tambin combinar con este mtodo, el mtodo de permutacin, el cual consiste en reordenar los caracteres resultantes de a cuerdo a alguna secuencia, previamente definida. En el esquema de encriptacin de llave publica, la llave de encriptacin es conocida por todos, y cualquier persona puede convertir texto plano a texto cifrado. Pero la llave de desencriptacin es mantenida en secreto (este esquema involucro dos llaves, una para encriptar y otra para desencriptar). La llave de desencriptacin no puede ser deducida a partir de la llave de encriptacin; de sta manera la persona que ejecuta la encriptacin no podr ejecutar la desencriptacin si no esta autorizada para hacerlo.

4.6 Preguntas de repaso


1.Cul es la condicin para que dos transacciones sean serializables?

Dos transacciones Ti y Tj se ejecutan serialmente en una planificacin S, si la ltima operacin de Ti precede a la primera operacin de Tj en S. 2.Cundo dos transacciones son concurrentes?

Dos transacciones son concurrentes si no cumplen la condicin de seriabilidad. 3.Cules son las dos condiciones que deben cumplir dos planificaciones para

que sean equivalentes? 4.Por qu dos operaciones pueden caer en conflicto?

Dos operaciones estn en conflicto, cuando procesan el mismo dato y al menos una de ellas es una operacin de escritura, y dichas operaciones pertenecen a diferentes transacciones.

5.6.-

Cmo funciona el control de concurrencia basado en bloqueos distribuidos? Mencione y describa los esquemas o mtodos que existen para evitar los

conflictos entre bloqueos.

Bases de Datos Distribuidas

152

Fundamentos de las Bases de Datos Distribuidas

Write - lock - all, read - lock - one : Los bloqueos exclusivos se hacen en todas las copias que existen del fragmento, mientras que los bloqueos compartidos se hacen solo en una de las copias.

Mayora de bloqueos: Tanto los bloqueos exclusivos como los compartidos son hechos en la mayora de las copias existentes, tomando en cuenta que el nmero de copias bloqueadas sea mayor que el nmero de las no bloqueadas.

Bloqueo de copia primaria: Todos los bloqueo son hechos en una sola copia del fragmento, llamada copia primaria.

7.8.-

Explique brevemente en que consiste el bloqueo de 2 fases. En que consisten las etiquetas de tiempo?

Una etiqueta de tiempo, es un identificador nico asignado a cada transaccin lanzada en el sistema. Esta etiqueta es utilizada para saber en que orden fueron lanzadas cada una de las transacciones y en dado momento, poder decidir cual podra ser abortada en caso de presentarse un interbloqueo. 9.10.Que se entiende por deadlocks distribuidos? Que es la recuperacin?

La recuperacin de un sistema de bases de datos consiste en llevarla a un estado correcto despus de que ha ocurrido una falla y la base de datos se encuentra en un estado incorrecto o incierto. 11.De que manera garantizamos que en dado momento, una base de datos

pueda ser recuperada? 12.- Adems de la replicacin de la base de datos, qu es recomendable hacer? Junto con la replicacin, es necesario llevar una bitcora de todos y cada uno de las actualizaciones hechas a la base de datos, esto para que en caso de una falla, se realicen un recorrido secuencias a la bitcora y se rehagan todas stas actualizaciones

Bases de Datos Distribuidas

153

Fundamentos de las Bases de Datos Distribuidas

despus de haber recuperado la base de datos a partir de la copia, esto para que las prdidas de informacin sean mnimas o casi nulas.

13.14.-

Que tipos de fallas pueden darse en un sistema de base de datos? Que se entiende por integridad en un sistema de bases de datos?

Una base de datos es integra cuando todos los datos almacenados en ella son correctos o validos en el contexto de la definicin de la base de datos. 15.16.Cuales son las responsabilidades de un subsistema de integridad? Explique la regla de integridad de dominio?

Cada atributo de la relacin esta definido sobre un dominio, identificado en la definicin de la relacin y todo valor de este atributo debe estar definido dentro del domino. 17.- A que se refiere la palabra seguridad dentro del mbito de las bases de datos? 18.- Mencione 5 aspectos que se deben tomar en cuenta dentro de la seguridad de las bases de datos? 19.20.La existencia de controles de seguridad fsicos. Las polticas de acceso. Los controles de acceso por medio de hardware. La seguridad del sistema operativo. Las situaciones concernientes al DBMS. Que son las reglas de autorizacin? Que es la encriptacin de datos?

La encriptacin de datos es el hecho de almacenar o transmitir la informacin de manera que no seria entendible para cualquier persona que intentara accesaria

4.7

Ejercicios

1.-

Para las siguiente tabla defina las reglas de integridad para el retiro de

Bases de Datos Distribuidas

154

Fundamentos de las Bases de Datos Distribuidas

fondos, creacin de una cuenta, transferencia de fondo y para la cancelacin de una cuenta (considerando que existe una tabla de movimientos). Cuentas Id_cuenta C12 C23 C54 C78 Saldo 458 8541 2369 500

2.- Tomando en cuenta la tabla y regla de integridad anteriores, realice las siguientes transacciones y regstrelas en una bitcora, T1: T2: T3: T4: T5: 3.Transferencia de la cuenta C23 a C12 por 1500. Deposito de 1234 a la cuenta C78. Retiro de 2000 de la cuenta C12. Transferencia de [a cuenta C12 a C78 por 1960. Cancelacin de la cuenta C54. Utilizando el mtodo de encriptacin de llave publica, y teniendo encuentra que p = 5 y q = 7, realice la encriptacin y desencriptacin de los siguientes nmeros: 8, 9.

Bibliografa
[1] Date, C.J.; "An lntroduction to Databases Systems"; Volume 1; Fifth Edition; Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1990 [2] Date, C.J.; "An lntroduction to Databases Systems"; Volume 11; Addison-Wesley Publishing Company; U.S.A.; Reprinted July, 1995 [3] Korth, Henry F. Silberschatz, Abraham; @Database System Concepts"; Second Edition McGraw-Hili; U.S.A.; lnternational Edition 1991

Bases de Datos Distribuidas

155

Fundamentos de las Bases de Datos Distribuidas

Respuestas a preguntas y ejercicios de repaso


Captulo I Preguntas de repaso 2. La mayor parte de las organizaciones ya estn distribuidas. Permiten interconexin de las bases de datos existentes. Es posible realizar un desarrollo incrementar. Permite reducir la carga de las lneas de comunicacin. Existe un incremento en el desempeo del sistema. Son ms confiables. La mayor parte del tiempo se encuentra disponible la informacin.

Bases de Datos Distribuidas

156

Fundamentos de las Bases de Datos Distribuidas

4.Porque describe la forma en como deber de funcionar una base de datos distribuida. Vista desde el exterior la distribucin ser completamente transparente, 6.Significa que el usuario nunca vera la base de datos como un conjunto de fragmentos situados en diferentes sitios, sino por el contrario, para l, la base de datos se encuentra ntegramente en su estacin de trabajo o sitio de trabajo. 8. 10. Deber ser capaz de soportar mltiples usuarios. Deber ser capaz de satisfacer las demandas de los clientes. Deber de proveer altos niveles de desempeoDeber de contar con capacidad de red. Es llamado por el usuario y se ejecuta durante la sesin. Se ejecuta de modo local. Tiene capacidad de iniciar la comunicacin con el servidor.

Captulo II Preguntas de repaso 2. Procesamiento local: Los datos son colocados en el sitio o cerca del sitio donde residen las aplicaciones que los utilizan. Disponibilidad y confiabilidad de los datos distribuidos: Debido a que e>dsten vanas copias de la informacin, es posible conmutar a una copia altema cuando la copia que era accesada comnmente no se encuentre disponible. Distribucin de la carga de trabajo: La carga de trabajo es distribuida en relacin con la capacidad de cmputo de cada uno de los sitios participantes, permitiendo un grado ms alto de paralelismo-

Bases de Datos Distribuidas

157

Fundamentos de las Bases de Datos Distribuidas

Costo de almacenamiento: Los costos del almacenamiento son reducidos al fragmentar la base de datos global en diferentes sitios, y esto garantiza espacio disponible en algn sitio para el almacenamiento de nueva informacin.

4. Fragmentacin horizontal primaria: Consiste en particionar las tuplas de una relacin global en subconjuntos de tuplas, donde cada uno de estos tiene propiedades geogrficas comunes. La reconstruccin de la relacin global se lleva a cabo por medio de la operacin unin. Fragmentacin horizontal derivada: Esta genera cuando una relacin no puede ser fragmentada en base a alguna propiedad de sus atributos, entonces, su fragmentacin se deriva de la fragmentacin horizontal de otra relacin. Fragmentacin vertical: se obtiene por la subdivisin de sus atributos en grupos. Los fragmentos son obtenidos por medio de proyecciones sobre la relacin global. La reconstruccin de la relacin global se da por medio de una operacin join. Fragmentacin mixta: Los fragmentos son obtenidos a partir de la aplicacin de fragmentaciones iterativas sobre la relacin global. La reconstruccin de la relacin se logra al aplicar las operaciones en orden inverso a la fragmentacin. Ejercicios de repaso 1.q1: q2: q3: Obtener los nombres de todos los clientes. Obtener los nmeros de cliente (no_cli) por estado. Obtener los nombres de los clientes (nom_cli) por empresa.

No_cli C01 C02 C03 C04 C05 C06

Nom_cli Jurez Vidal vila Meja Herrera Cervantes

Empresa Gamesa Lara Gamesa Lara Lara Gamesa

Estado Gto Qro Jal Jal Gto Qro

Bases de Datos Distribuidas

158

Fundamentos de las Bases de Datos Distribuidas

q2= { Estado = Gto, Estado = Qro, Estado = Jal q3= { Empresa = Gamesa, Empresa = Lara}

P1={Ciudad = Gto}, P2={Ciudad = Oro}, P3={Ciudad = Jal} P4={Empresa = Gamesa}, P5={Empresa = Lara}

M1 = Gto ^ ~Qro ^ ~Jal ^ ~Gamesa ^ Lara m2 = Gto ^ ~Qro ^ ~Jal ^ Gamesa ^ ~Lara m3 = ~Gto ^ Qro ^ ~Jal ^ ~Gamesa ^ Lara m4 = ~Gto ^ Oro ^ ~Jal ^ Gamesa ^ ~Lara m5 = ~Gto ^ ~Qro A Jal ^ ~Gamesa ^ Lara m6 = ~Gto ^ ~Qro ^ Jal ^ Gamesa ^ ~Lara

si si si si si si

m7 = ~Gto ^ ~Oro ^ ~Jal ^ ~ Gamesa ^ ~Lara m8 = Gto ^ Oro ^ Jal ^ Gamesa ^ Lara m9 = Gto ^ Oro ^ Jal ^ Gamesa ^ ~Lara m10 = Gto ^ Oro ^ Jal ^ ~Gamesa ^ Lara m11 = Gto ^ Oro ^ Jal ^ ~ Gamesa ^ ~-Lara m12 = Gto ^ Qro ^ ~ Jal ^ Gamesa ^ Lara . . . m1 = Gto ^ Lara m2 = Gto ^ Gamesa m3 = Oro ^ Lara m4 = Oro ^ Gamesa m5 = Jal ^ Lara

no no no no no no no

Bases de Datos Distribuidas

159

Fundamentos de las Bases de Datos Distribuidas

m6 = Jal ^ Gamesa

m1 No_cli C05 Nom_cli Herrera Empresa Lara Estado Gto

m2 No_cli C01 Nom_cli Jurez Empresa Gamesa Estado Gto

m3 No_cli C02 Nom_cli Vidal Empresa Lara Estado Qro

m4 No_cli C06 Nom_cli Cervantes Empresa Gamesa Estado Qro

m5 No_cli C04 Nom_cli Meja Empresa Lara Estado Jal

m6 No_cli C03 Nom_cli vila Empresa Gamesa Estado Jal

3.q1: q2: Obtener los nombres de todos los clientes. Obtener los nmeros y nombres de los clientes por estado.
160

Bases de Datos Distribuidas

Fundamentos de las Bases de Datos Distribuidas

q3:

Obtener los nombres de los clientes por empresa.

Matriz de accesos S1 Ql q2 q3 3 2 1 S2 2 1 1

q1= Select Nom_cli From clients q2= Select no_cli, Nom_cli From clients Where Estado q3= Select Nom-cli From clientes Where Empresa = y

A1 no_cli accesos q1 q2 q3 0 1 0

A2 nom_cli 1 1 1

A3 Empresa 0 0 1

A4 Estado 0 1 0

Tot de 5 3 2

Al Al 3

A2 3

A3 0

A4 3

Bases de Datos Distribuidas

161

Fundamentos de las Bases de Datos Distribuidas

A2 A3 A4

3 0 3

10 2 3

2 2 0

3 0 3

F1={No_cli, Nom_cli} F2={No_cli, Empresa, Estado} O F1={ No_cli, Nom_cli, Empresa} F2={ No el, Estado}

Captulo III Preguntas de repaso 2. Es necesario definir el nmero de copias fsicas de cada uno de los fragmentos que existen en el sistema, y obtener una expresin de consulta sobre cada uno de los fragmentos. 4.Son expresiones que aparecen ms de una vez dentro de una misma consulta y que solo deber ser ejecutada una sola vez para optimizar la ejecucin de la consulta. 6. Iteracin simple. Iteracin orientada a bloques. Se deber seleccionar el orden de ejecucin del conjunto de consultas sobre cada uno de los sitios. Seleccionar el mtodo optimo para la ejecucin de cada operacin.

Bases de Datos Distribuidas

162

Fundamentos de las Bases de Datos Distribuidas

8.

Merge - join. Hash - join. Tree - way join. Join paralelo Pipeline muitiway join.

Convertir la consulta a alguna expresin apropiada par el sistema administrador de la base de datos, para que de esta manera pueda ser ejecutada adecuadamente, eliminando las caractersticas de la sintaxis del lenguaje de nivel externo con el cual fue hecha la consulta.

Convertir la consulta a su forma cannica, es decir, llevar a la expresin hasta su forma ms simple posible, eliminando expresiones comunes y repetidas, y reduciendo su costo de procesamiento.

Elegir el procedimiento para evaluar la consulta, sta, expresada en su forma cannica, generando, generando subprocedimientos para la ejecucin de las operaciones de bajo nivel, tales como join, select, etc.

Por ultimo, se construyen un conjunto de planes de ejecucin de la consulta y se elige el ms econmico de ellos. Donde econmico se refiere a la ejecucin de menor costo en el sistema.

Bases de Datos Distribuidas

163

Fundamentos de las Bases de Datos Distribuidas

Ejercicios de repaso 1.PJEMP:NOM DF JNDEPTNUM=DEPTNUM JNDEPTNUM=DEPTNUM

EMP

SLDESC=X

SLSAL<=11000

SLDESC=x

DEPT 3. PJEMP:NOM DF

EMP

DEPT

SLSAL>35000

JNDEPTNUM=DEPTNUM

EMP

SLDESC=X DEPT

Bases de Datos Distribuidas

164

Fundamentos de las Bases de Datos Distribuidas

Captulo IVPreguntas de repaso 2.Dos transacciones son concurrentes si no cumplen la condicin de seriabilidad. 4.Dos operaciones estn en conflicto, cuando procesan el mismo dato y al menos una de ellas es una operacin de escritura, y dichas operaciones pertenecen a diferentes transacciones. 6. Write - lock - all, read - lock - one : Los bloqueos exclusivos se hacen en todas las copias que existen del fragmento, mientras que los bloqueos compartidos se hacen solo en una de las copias. Mayora de bloqueos: Tanto los bloqueos exclusivos como los compartidos son hechos en la mayora de las copias existentes, tomando en cuenta que el nmero de copias bloqueadas sea mayor que el nmero de las no bloqueadas. Bloqueo de copia primaria: Todos los bloqueo son hechos en una sola copia del fragmento, llamada copia primaria. 8.Una etiqueta de tiempo, es un identificador nico asignado a cada transaccin lanzada en el sistema. Esta etiqueta es utilizada para saber en que orden fueron lanzadas cada una de las transacciones y en dado momento, poder decidir cual podra ser abortada en caso de presentarse un interbloqueo. 10.La recuperacin de un sistema de bases de datos consiste en llevarla a un estado correcto despus de que ha ocurrido una falla y la base de datos se encuentra en un estado incorrecto o incierto.

Bases de Datos Distribuidas

165

Fundamentos de las Bases de Datos Distribuidas

12.Junto con la replicacin, es necesario llevar una bitcora de todos y cada uno de las actualizaciones hechas a la base de datos, esto para que en caso de una falla, se realicen un recorrido secuencias a la bitcora y se rehagan todas stas actualizaciones despus de haber recuperado la base de datos a partir de la copia, esto para que las perdidas de informacin sean mnimas o casi nulas.

14.Una base de datos es integra cuando todos los datos almacenados en ella son correctos o validos en el contexto de la definicin de la base de datos.

16.Cada atributo de la relacin esta definido sobre un dominio, identificado en la definicin de la relacin y todo valor de este atributo debe estar definido dentro del domino.

18. La existencia de controles de seguridad fsicos. Las polticas de acceso. Los controles de acceso por medio de hardware. La seguridad del sistema operativo. Las situaciones concernientes al DBMS.

19.La encriptacin de datos es el hecho de almacenar o transmitir la informacin de manera que no seria entendible para cualquier persona que intentara accesaria.

Bases de Datos Distribuidas

166

Fundamentos de las Bases de Datos Distribuidas

Ejercicios de repaso 1. Para una transferencia o retiro After Update ng cuentas cuentas.saldo >= 0 Else Set retum code to "Saldo insuficiente Reject;

Para alta de cuenta: Before inserting cuentas from variable-de-programa Not exist (cuentas.Id-cuenta = variable-de-Programa.ld-cuenta) Else Set retum code to " El Id de la cuenta ya existe Reject;

Para el borrado de una cuenta: After deleting cuentas from variable-de-programa Not exist (Movimientos where movimiento.Id-cuenta = variable-de-Programa.ld-cuenta) Else Delete from movimientos where movimientos.ld-cuenta variable-de-Programa.id_Cuenta;

3. p = 5, q = 7 r = 5 * 7 = 35

Bases de Datos Distribuidas

167

Fundamentos de las Bases de Datos Distribuidas

(5 - 1) * (7 -1) = 24 e = 11 (d * 11) modulo 24 = 1 d=11

Encriptacin C1 = (8)11 mdulo 35 = 22 C2 = (9)11 mdulo 35 = 4

Desencriptacin P1 = (22)11 mdulo 35 = 8 P2 = (4)11 mdulo 359

Bases de Datos Distribuidas

168

Fundamentos de las Bases de Datos Distribuidas

Conclusiones

Durante la realizacin de este trabajo se trato de cubrir la mayor parte del programa de estudio de la materia de base de datos distribuida, y se logro obtener un texto que puede ser utilizado por el maestro como apoyo, y por el alumno como libro de texto, permitiendo as una rpida asimilacin de los temas y conceptos que en esta obra se tratan. Es tambin, un texto que podra ser utilizado por personas autodidactas con conocimientos de generales de computacin y de bases de datos, permitiendo un entendimiento claro del concepto de lo que son las bases de datos distribuidas.

Bases de Datos Distribuidas

169

Вам также может понравиться