Antología Bases de Datos Distribuidas

Academia de Informtica Ramn Edgardo Rincn Fernndez
L. I.
BASE DE DATOS DISTRIBUIDAS UNIDAD I FUNDAMENTOS DE BASE DE DATOS DISTRIBUIDAS 1.1. CONCEPTOS BSICOS:
Base de Datos Una base de datos es una coleccin de elementos de datos interrelacionados que pueden procesarse por uno o ms sistemas de aplicacin. Un sistema de base de datos est formado por una base de datos, un sistema de gestin de bases de datos (SGBD), as como por el hardware y personal apropiado. Los sistemas de bases de datos superan estas limitaciones de los sistemas orientados a los archivos. Los datos se controlan por medio de un diccionario de datos/directorio, que est controlado por los administradores de la base de datos. MODELOS Hay 3 modelos fundamentales: Jerrquico. Este modelo presume de que todas las interrelaciones entre los datos pueden estructurarse como jerarquas. Los archivos se conectan entre s mediante punteros fsicos (direcciones fsicas que identifican dnde se puede encontrar un registro en disco) o campos de datos aadidos a los registros individuales. Tiene algunas limitaciones, ya que no todas las relaciones se pueden expresar de forma jerrquica. En red. Debido a la necesidad de manipular las interrelaciones, se desarroll este modelo de base de datos que maneja relaciones en forma de red en lugar de jerrquicas. Tambin utiliza punteros fsicos. Relacional. La debilidad que tenan los punteros fsicos era que haba que definir las interrelaciones antes de que el sistema fuera puesto en explotacin. Codd argument que los datos deberan relacionarse mediante interrelaciones naturales, lgicas, inherentes a los datos. Propuso un modelo en el que los datos se representaran en tablas constituidas por filas y columnas, llamadas relaciones. Tambin propuso dos lenguajes para manipular los datos en las tablas: el lgebra relacional y el clculo relacional. En los sistemas de bases de datos relacionales, los archivos se pueden procesar con instrucciones sencillas, sin embargo, en los sistemas tradicionales se deben procesar de registro en registro Sistema de Base de Datos Es un sistema computarizado de registros que comprende: datos, hardware, software (DBMS) y usuarios. Dichos usuarios pueden dividirse en programadores de aplicaciones, usuarios finales y administrador de base de datos, quien es el responsable de administrar la base de datos y el sistema de base de datos, de acuerdo con las polticas establecidas por el administrador de datos. 1. Ventajas de una Base de Datos.
L. I.
a. b. c. d. e. f. g. h. i.
Los datos pueden compartirse. Posibilidad de reducir redundancia. Posibilidad de evitar la inconsistencia. Brinda manejo de Transacciones. Posibilidad de mantener la Integridad. Posibilidad de hacer cumplir la Seguridad Posibilidad de equilibrar los requerimientos en conflicto. Posibilidad de hacer cumplir los estndares. Independencia de los Datos.
Arquitectura de una Base de Datos. Nivel Interno: (Nivel Fsico) es el que est ms cerca del almacenamiento fsico; es decir, tiene que ver con la forma en que los datos estn almacenados fsicamente. Nivel Externo: (Nivel Lgico del Usuario) es el ms prximo a los usuarios; es decir, el que tiene que ver con la forma en que los usuarios individuales ven los datos. Nivel Conceptual: (Nivel Lgico) es un nivel de indireccin entre los dos. Divisin de las Bases de Datos segn su apertura. a. Monousuarios. b. Multiusuarios. Clasificacin de las BDD multiusuario. La arquitectura de un sistema de base de datos est influenciada en gran medida por el sistema informtico subyacente en el que se ejecuta, en particular por aspectos de la arquitectura de la computadora como la conexin en red, el paralelismo y la distribucin. a. La conexin en red de varias computadoras permite que algunas tareas se ejecuten en un sistema servidor y que otras se ejecuten en los sistemas clientes. Esta divisin ha conducido al desarrollo de sistemas de bases de datos cliente-servidor. b. El procesamiento paralelo dentro de una computadora permite acelerar las actividades del sistema de base de datos, proporcionando a las transacciones unas respuestas ms rpidas as como la capacidad de ejecutar ms transacciones por segundo. Las consultas pueden procesarse de manera que se explote el paralelismo ofrecido por el sistema informtico subyacente. La necesidad del procesamiento paralelo de consultas ha conducido al desarrollo de sistemas de bases de datos paralelos. c. La distribucin de datos a travs de las distintas sedes o departamentos de una organizacin permite que estos datos residan donde han sido generados o donde son ms necesarios, pero continuar siendo accesibles desde otros lugares o departamentos diferentes. En un sistema distribuido de bases de datos se almacena la base de datos en varias computadoras. Las computadoras de un sistema distribuido pueden ser diversas en tamao y funcin pudiendo abarcar desde las estaciones de trabajo o los grandes sistemas.
L. I.
Dependiendo del contexto en el que se mencionen existen diferentes nombres para referirnos a las computadoras que forman parte de un sistema distribuido, tales como sitios o nodos. Para enfatizar la distribucin fsica de estos sistemas se usa principalmente el trmino sitio. Las bases de datos distribuidos cuentan con las siguientes caractersticas: Se encuentran en varios lugares geogrficos distintos. Se administran de forma separada. Posen una interconexin lenta. Se producen dos tipos de transacciones: locales (aquella que accede a los datos del nico sitio en el cual se inicio la transaccin) y globales (aquella que, o bien accede a los datos situados en un sitio diferente de aquel en el que inicio la transaccin, o bien accede a datos de varios sitios distintos).
El hecho de guardar varias copias de la base de datos en diferentes sitios permite que puedan continuar las operaciones sobre la base de datos aunque algn sitio se vea afectado por algn desastre natural como inundacin, incendio o terremoto. Se han desarrollado los sistemas distribuidos de bases de datos para manejar datos distribuidos geogrfica o administrativamente a lo largo de mltiples sistemas de bases de datos. 1.2. OBJETIVOS DE LAS BASES DE DATOS DISTRIBUIDAS. 1. Autonoma Local: Los sitios de un sistema distribuido deben ser autnomos. La autonoma local significa que todas las operaciones en un sitio dado estn controladas por ese sitio; ningn sitio X debe depender de algn otro sitio Y para su operacin satisfactoria. Tambin implica que los datos locales son posedos y administrados localmente con contabilidad local: todos los datos pertenecen realmente a alguna base de datos local, an cuando estn accesibles desde otros sitios remotos. En un sistema distribuido, existe un administrador de base de datos global responsable de todo el sistema. Dependiendo del diseo del sistema distribuido de base de datos, cada administrador puede tener un grado diferente de autonoma local. 2. Datos Compartidos.- La principal ventaja de construir un sistema distribuido de base de datos es poder disponer de un entorno donde los usuarios pueden acceder desde una nica ubicacin a los datos residentes en otras ubicaciones. 3. No dependencia de un sitio central: la autonoma local implica que toso los sitios deben ser tratados como iguales. Por lo tanto, no debe haber particularmente ninguna dependencia de un sitio maestro central para algn servicio central (procesamiento centralizado de consultas) tal que todo sistema dependa de ese sitio central. La dependencia sera indeseable por: cuello de botella y fallas en el sistema central (fallara todo el sistema).
L. I.
4. Operacin Continua: Los sistemas distribuidos deben proporcionar mayor confiabilidad (la probabilidad de que el sistema est listo y funcionando en cualquier momento) porque pueden continuar operando cuando exista falla en un componente independiente; y mayor disponibilidad (la probabilidad de que el sistema est listo y funcionando continuamente a lo largo de un periodo especificado). 5. Independencia de Ubicacin: Es necesaria debido a que simplifica los programas de usuario y las actividades terminales; es decir, permite que los datos emigren de un sitio a otro sin invalidar ninguno de estos programas o actividades. Esta emigracin permite mover los datos por la red en respuesta a los diferentes requerimientos de desempeo. 6. Independencia de Fragmentacin: La fragmentacin es necesaria por razones de rendimiento: los datos pueden estar almacenados en la ubicacin donde son usados ms frecuentemente para que la mayora de las operaciones sean locales y se reduzca el trfico en la red. 7. Independencia de Replicacin: Un sistema soporta la replicacin de datos cuando una tabla almacenada (o fragmento de una tabla guardada) puede ser representada por muchas copias distintas, o rplicas, guardadas en muchos sitios distintos. Las rplicas son necesarias por: mejor rendimiento (porque se pueden hacer operaciones en las copias) y mejor disponibilidad (porque permanece disponible para su procesamiento). La desventaja es actualizar todas las copias cuando se haya modificado una. 8. Procesamiento de consultas distribuidas: 1. Un sistema relacional supera a uno que no lo es por varias rdenes de magnitud. 2. La optimizacin es ms importante que en uno centralizado; es decir, que las peticiones relacionales son optimizables. 9. Administracin de Transacciones Distribuidas: Existen dos aspectos principales en este punto: el control de la recuperacin y el control de la concurrencia. Ambos requieren un tratamiento amplio en el ambiente distribuido; y para ello est el agente (proceso realizado en nombre de una transaccin dada en un sitio dado). El sistema puede detectar el fallo de un sitio, y puede ser necesario acciones apropiadas para recuperase del fallo. En sistema no debe seguir utilizando los servicios del sitio que fallo. Finalmente cuando el sitio que fallo se recupera o repara, debe haber mecanismos disponibles para integrarlo sin problema de nuevo al sistema. Aunque la recuperacin ante un fallo es ms compleja en los sistemas distribuidos que en los sistemas centralizados, la capacidad que tiene muchos sistemas de continuar trabajando a pesar de fallo en uno de los sitios produce un mayor disponibilidad. La disponibilidad es crucial para los sistemas de base de datos que se utilizan en aplicaciones de tiempo real. 1.3 DISCIPLINAS DE ESTUDIO.
L. I.
Materias que lo estudian Ciencias Computacionales. Informtica. reas de Aplicacin Redes Mercadotecnia Administracin Recursos Humanos 1.4. ARQUITECTURA DE LA BASE DE DATOS DISTRIBUIDA. - Arquitecturas Centralizadas y Cliente Servidor Los sistemas de base de datos centralizados son aquellos que se ejecutan en un nico sistema informtico sin interaccionar con ninguna otra mquina. Una computadora moderna de propsito general se compone: Una o pocas unidad de procesamiento. Un nmero determinado de controladores de dispositivos conectados a travs de un bus comn, el cual proporciona acceso a la memoria compartida. Las UCP poseen memoria cach. Y tanto el UCP u el controlador de dispositivos pueden ejecutase concurrentemente compitiendo as por el acceso a la memoria. Se distinguen 2 formas de utilizar las computadoras: Como sistemas monousuarios. Como sistemas multiusuario. En la primera categora estn las computadoras personales y estaciones de trabajo, un sistema monousuario tpicamente es una unidad de mesa con una sola UCP, con un sistema operativo que solo permite un solo nico usuario. Un sistema multiusuario tpico tiene ms de dos discos duros y ms memoria, puede disponer de varios UCP y trabajan con sistema operativo multiusuario. Se encarga de dar servicios a un nmero de usuarios conectados al sistema a travs de terminales. Los sistemas cliente servidor tienen su funcionamiento dividida entre el sistema servidor y mltiples sistemas clientes. El concepto de cliente/servidor proporciona una forma eficiente de utilizar todos estos recursos de mquina, de tal forma que la seguridad y fiabilidad que proporcionan los entornos mainframe se traspasa a la red de rea local.
L. I.
La arquitectura cliente/servidor es un modelo para el desarrollo de sistemas de informacin, en el que las transacciones se dividen en procesos independientes que cooperan entre s para intercambiar informacin, servicios o recursos. Se denomina cliente al proceso que inicia el dilogo o solicita los recursos y servidor, al proceso que responde a las solicitudes. Es el modelo de interaccin ms comn entre aplicaciones en una red. No forma parte de los conceptos de la Internet como los protocolos IP, TCP o UDP, sin embargo todos los servicios estndares de alto nivel propuestos en Internet funcionan segn este modelo. Los principales componentes del esquema cliente/servidor son entonces los Clientes, los Servidores y la infraestructura de comunicaciones. En este modelo, las aplicaciones se dividen de forma que el servidor contiene la parte que debe ser compartida por varios usuarios, y en el cliente permanece slo lo particular de cada usuario. Los Clientes interactan con el usuario, usualmente en forma grfica. Frecuentemente se comunican con procesos auxiliares que se encargan de establecer conexin con el servidor, enviar el pedido, recibir la respuesta, manejar las fallas y realizar actividades de sincronizacin y de seguridad. Entre las principales caractersticas de la arquitectura cliente / servidor, se pueden destacar las siguientes: El servidor presenta a todos sus clientes una interfase nica y bien definida. El cliente no necesita conocer la lgica del servidor, slo su interface externa. El cliente no depende de la ubicacin fsica del servidor, ni del tipo de equipo fsico en el que se encuentra, ni de su sistema operativo. Los cambios en el servidor implican pocos o ningn cambio en el cliente. Una infraestructura Cliente/Servidor consta de tres componentes esenciales, todos ellos de igual importancia y estrechamente ligados: Plataforma Operativa. La plataforma deber soportar todos los modelos de distribucin Cliente/Servidor, todos los servicios de comunicacin, y deber utilizar, preferentemente, componentes estndar de la industria para los servicios de distribucin. Los desarrollos propios deben coexistir con las
L. I.
aplicaciones estndar y su integracin deber ser imperceptible para el usuario. Igualmente, podrn acomodarse programas escritos utilizando diferentes tecnologas y herramientas. Entorno de Desarrollo de Aplicaciones. Debe elegirse despus de la plataforma operativa. Aunque es conveniente evitar la proliferacin de herramientas de desarrollo, se garantizar que el enlace entre stas y el middleware no sea excesivamente rgido. Ser posible utilizar diferentes herramientas para desarrollar partes de una aplicacin. Un entorno de aplicacin incremental, debe posibilitar la coexistencia de procesos cliente y servidor desarrollados con distintos lenguajes de programacin y/o herramientas, as como utilizar distintas tecnologas (por ejemplo, lenguaje procedural, lenguaje orientado a objetos, multimedia), y que han sido puestas en explotacin en distintos momentos del tiempo. Gestin de Sistemas. Estas funciones aumentan considerablemente el costo de una solucin, pero no se pueden evitar. Siempre deben adaptarse a las necesidades de la organizacin, y al decidir la plataforma operativa y el entorno de desarrollo. Es necesario fijar los objetivos y el modo de conseguirlos en cada caso concreto utilizando una Metodologa de Infraestructura para Sistemas Distribuidos que permita definir una infraestructura para el sistema Cliente/Servidor y evale la puesta en marcha del proyecto sobre una base racional. El enfoque estructurado de dicha Metodologa comprende los pasos siguientes: Captacin de las necesidades. Definir, analizar y evaluar, aunando los requerimientos del negocio con las aportaciones tecnolgicas. Diseo conceptual en el que se sitan los principales bloques funcionales y de datos del sistema, mostrando la relacin y comunicacin entre ambos. Detalle de los principales componentes funcionales, seleccin de procesos, determinando los principios que deben aplicarse a la seleccin de software o diseo de los mdulos. Al final de los tres pasos anteriores, se definen los conceptos del sistema y la infraestructura tecnolgica, sin concretar, todava, en productos o plataformas especficos. Por ltimo, se llega a la seleccin de plataformas y principales productos y componentes para la implantacin. El resultado es la descripcin de una solucin que incluye infraestructura tecnolgica, plataformas y productos. Los clientes realizan generalmente funciones como: Manejo de la interfase del usuario. Captura y validacin de los datos de entrada. Generacin de consultas e informes sobre las bases de datos. Los Servidores proporcionan un servicio al cliente y devuelven los resultados.
L. I.
Por su parte los servidores realizan, entre otras, las siguientes funciones: Gestin de perifricos compartidos. Control de accesos concurrentes a bases de datos compartidas. Enlaces de comunicaciones con otras redes de rea local o extensa. La mayora de los sistemas Cliente/Servidor actuales, se basan en redes locales y por lo tanto utilizan protocolos no orientados a conexin, lo cual implica que las aplicaciones deben hacer las verificaciones. La red debe tener caractersticas adecuadas de desempeo, confiabilidad, transparencia y administracin.
Los sistemas centralizados actan hoy como sistema servidores que satisfacen las peticiones generadas por los sistemas clientes. Arquitectura del Sistema Distribuido Un sistema de base de datos distribuida consiste en una coleccin de sitios, conectados por medio de algn tipo de red de comunicacin, en el cual: a. cada sitio es un sistema de base de datos completo por derecho propio, pero b. los sitios han acordado trabajar juntos, a fin de que un usuario de cualquier sitio pueda acceder a los datos desde cualquier lugar de la red, exactamente como si los datos estuvieran guardados en el propio sitio del usuario. De aqu deducimos que es una base de datos virtual cuyas partes componentes estn almacenadas en varias bases de datos reales distintas que se encuentran en varios sitios distintos. Cada sitio tiene sus propias bases de datos reales, sus propios usuarios locales, su propio DBMS local y software de administracin de transacciones (incluyendo software local para bloqueo, registro de bitcora, recuperacin, etc.), as como su propio administrador de comunicacin de datos local. La combinacin de un componente de software y un DBMS existente, constituye un sistema de administracin de base de datos distribuida.
L. I.
Un sistema de Base de Datos Distribuida Tpico El primer aspecto importante es la atomicidad. Si una transaccin se ejecuta a lo largo de dos sitios, amenos que los diseadores del sistema sean cuidadosos, puede completarse en un sitio y cancelarse en otro, lo que conducira a un estado de inconsistencia. Los protocolos de compromiso se transacciones aseguran que tales situaciones no se produzcan. EL protocolo de compromiso de dos fases (C2F) es el ms utilizado en estos protocolos. La idea bsica del C2F es que cada sitio ejecuta la transaccin justo hasta antes del compromiso, y entonces deja la decisin del compromiso a un nico sitio coordinador; se dice que en ese punto la transaccin est en estado preparada en el sitio. El coordinador decide comprometer la transaccin slo si la transaccin alcanza el estado preparada en cada sitio donde se ejecut; en otro caso (por ejemplo, si la transaccin se cancel en algn sitio), el coordinador decide cancelar la transaccin. Todos los sitios donde la transaccin se ejecut deben acatar la decisin del coordinador. El control de concurrencia es otra caracterstica de una base de datos distribuida. Como una transaccin puede acceder a los elementos de datos de varios sitios, los administradores de transacciones de varios sitios pueden necesitar coordinarse para implementar el control de concurrencia. Se puede utilizar el bloqueo (Como casi siempre sucede en la prctica). El bloque se puede realizar de manera local en los sitios que contiene los datos accedidos, pero tambin existe la posibilidad de nterbloqueos que involucren a transacciones originadas en mltiples sitios. Por lo tanto, es necesario llevar la deteccin de nterbloqueos a lo largo de los mltiples sitios. Los fallos son ms comunes en los sistemas distribuidos, dado que no slo las computadoras pueden fallar, sino que tambin pueden fallar los enlaces de comunicaciones. La rplica de los elementos de datos, es la clave para el funcionamiento de una base de datos distribuida. Se utilizan tcnicas alternativas, basadas en mensajera persistente para las comunicaciones para implementar el C2F.
L. I.
En caso de que una empresa tenga que escoger entre una arquitectura distribuida y una arquitectura centralizada para implementar una aplicacin, el arquitecto del sistema debe sopesar las ventajas frente a las desventajas de la distribucin de datos. Los principales inconvenientes de los sistemas distribuidos de base de datos son: Coste de desarrollo del software.- La implementacin de un sistema de un sistema distribuidos de base de datos es ms difcil y, por lo tanto, ms costoso. Mayor probabilidad de errores.- Como los sitios que constituyen el sistema distribuidos operan en paralelo es ms difcil asegurarse de la correccin de los algoritmos, del funcionamiento espacial durante los fallos de parte del sistema as como de la recuperacin. Son probables errores extremadamente sutiles. Mayor sobrecarga de procesamiento.- El intercambio de mensajes y el cmputo adicional necesario para conseguir la coordinacin entre los distintos sitios constituye una forma de sobrecarga que no surge en los sistemas centralizados. Existen varios enfoques acerca del diseo de las base de datos distribuidas que abarca desde los diseos completamente distribuidos hasta los que incluyen un alto grado de centralizacin. Las bases de datos distribuidas y los sistemas cliente servidor se construyen en torno a las redes de comunicacin. Existen bsicamente dos clases de redes: Redes de rea local (LAN) Redes de rea amplia (WAN)
La diferencia entre ambas es a forma en que estn distribuidas geogrficamente. Las redes de rea local estn compuestas por procesadores distribuidos en reas geogrficas pequeas como un nico edificio o varios edificios adyacentes. Por su parte, las redes de rea amplia se componen por un determinado de procesadores autnomos que estn distribuidos a lo largo de una extensa rea geogrfica (como puede ser el mundo entero). Estas diferencias implican importantes variaciones en velocidad y en la fiabilidad de la red de comunicacin y quedan reflejadas en el diseo del sistema operativo distribuido. Existen 2 tipos de base de datos distribuidas: Base de datos Distribuidas Homogneas.- Donde todos los sitios tienen idntico software de sistema gestor de base de datos, son conscientes de la existencia de los dems sitios y acuerdan cooperar en el procesamiento de las solicitudes de los usuarios. Base de datos Distribuidas Heterogneas.Donde los sitios son diferentes pueden que utilicen esquemas diferentes y diferentes software de gestin de base de datos. Puede ser que unos sitios no sean conscientes de la existencia de los dems y puede que slo
L. I.
proporcionen facilidades limitadas procesamiento de las transacciones.
para
la
cooperacin
en
el
Diagrama de un Sistemas de Red de Base de Datos Distribuida Los sistemas cliente-servidor tienen su funcin dividida entre el sistema servidor y mltiples sistemas clientes. Como sabemos que una de las caractersticas de las bases de datos distribuidas es la posibilidad de compartir datos; debido a esto, la arquitectura de una base de datos para sistemas de esta caracterstica, debe plantearse como se muestra en el diagrama siguiente. Los sistemas de base de datos distribuidos, al igual que cualquier sistema servidor, puede ser servidor de datos y servidor de transacciones. Un sistema de Transacciones (o de Consultas) proporciona una interfaz a travs de la cual los clientes pueden enviar peticiones para realizar una accin que el servidor ejecutar y cuyos resultados se devolvern al cliente. Las peticiones se pueden especificar utilizando SQL o mediante la interfaz de una aplicacin especializada. Arquitecturas de Sistema de Servidor Los sistemas servidores de datos permiten a los clientes interaccionar con los servidores realizando peticiones de lectura o modificacin de datos en unidades talos como archivos o pginas; adems soportan unidades de datos de menor tamao (pginas, tuplas u objetos), facilidad de indexacin de los datos y facilidades de transaccin por si existe una falla. Los sistemas servidores pueden dividirse en servidores: De Transacciones.- Tambin llamados sistema de servidores de consultas, proporcionan una interfaz a travs de la cual los clientes pueden enviar peticiones para realizar una accin que el servidor ejecutara y cuyos resultados se devolvern al cliente. Normalmente, las maquinas clientes envan las transacciones a los sistemas servidores, lugar en el que estas transacciones se ejecutan y los resultados se regresan al usuario que son los encargados de visualizarlos. De Datos.- Permiten a los clientes interaccionar con los servidores realizando peticiones de lectura o modificacin de datos en unidades tales como archivos o pginas. El cliente puede leer, crea, modificar y borrar archivos, los servidores de datos de los sistemas de base de datos ofrecen ms funcionalidades como la indexacin y facilidades de transacciones. De estas la arquitectura del servidor de transacciones es, con mucho, la arquitectura mas ampliamente utilizada. Un sistema servidor de transacciones es el que ms se utiliza en la actualidad y consiste en mltiples procesos accediendo a los datos en una memoria compartida, cuya estructura se muestra en el diagrama. Los procesos incluyen: a. Proceso servidor: son procesos que reciben consultas del usuario (transacciones), las ejecutan y devuelven los resultados. Las consultas deben enviarse a los procesos servidor desde la interfaz
L. I.
b. c. d. e. f.
del usuario, o desde un proceso de usuario que ejecuta SQL, JDBC, ODBC o protocolos similares. Proceso gestor de bloqueos: implementa una funcin de gestin de bloqueos que incluye concesin de bloqueos, liberacin de bloqueos y deteccin de interbloqueos. Proceso escritor de base de datos: existen uno o ms procesos que vuelcan al disco los bloques de memoria intermedia modificados de forma continua. Proceso de escritor de registro: genera entradas del registro en el almacenamiento estable a partir de la memoria intermedia del registro. Proceso de punto de revisin. Establece estrategias de evaluacin del estado de ejecucin de las transacciones y de la consistencia de los datos. Proceso monitor de proceso: este proceso observa otros procesos y, si cualquiera de ellos falla, realiza opciones de recuperacin para el proceso; por ejemplo, cancelar cualquier transaccin que estuviera ejecutando el proceso fallido, y reinicia el proceso.
La memoria compartida contiene todos los datos compartidos como: Grupo de memorias intermedias. Tablas de bloqueos. Memoria intermedia de registros, que contiene las entradas del registro que esperan a ser volcados en el almacenamiento estable. Planes de consultas en cach, que se pueden reutilizar si se envan de nuevo las mismas consultas.
L. I.
Estructura de la Memoria compartida y de los procesos Los sistemas de servidores de datos se utilizan en redes de rea local. Envi de pginas o envi de elementos.- La unidad de comunicacin de datos puede ser de grano grueso, como una pagina, o de grano fino, como una tupla o elemento, donde se busca la preextracin, se denomina preextracin a la accin de buscar y enviar elementos antes de que sea estrictamente necesario. Si varios elementos residen en una pagina, el envi de la pagina puede considerase como una forma de preextracin, ya que, cuando un proceso desea acceder a un nico elemento de una pagina, se enviara todos los elementos de esa pgina. Bloqueo.- La concesin del bloqueo de los elementos de datos que el servidor enva a los clientes la realiza habitualmente el propio servidor. Existen los bloqueos de grano grueso, como es bloquear un pagina que bloquea implcitamente a todos los elementos preextrados incluso aunque no este accediendo a algunos de ellos. Cach de Datos.- Los datos que se envan al cliente a favor de una transaccin se puede alojar en una cach del cliente incluso una vez completada la transaccin. Las transacciones sucesivas en el mismo cliente pueden hacer uso de los datos de la cach. Sin embargo, se presenta el problema de la coherencia de la cach: si una transaccin encuentra los datos en la cach, debe asegurase de que esos datos estn al da. Por lo tanto se necesita entablar una comunicacin con el servidor para validar los datos y poder adquirir un bloqueo sobre ellos. Cach de Bloqueos.- Los bloqueos tambin pueden ser almacenados en la memoria cach del cliente si la utilizacin de los datos esta dividida
L. I.
entre los clientes, de manera que un cliente rara vez necesita los datos que estn siendo utilizados por otros clientes. Si el cliente tiene en memoria cach tanto el elemento de datos que busca como el bloqueo requerido para acceder al elemento de datos, entonces el cliente puede acceder al elemento de datos sin comunicar al servidor. No obstante el servidor debe rastrear los bloqueos en cach; sin un cliente solicita un bloqueo al servidor, ste debe comunicar a todos los bloqueos sobre el elemento de datos que se encuentran en las memoria cach de otros clientes. Sistemas Paralelos Los sistemas paralelos mejoran la velocidad de procesamiento y de E/S mediante la utilizacin de UCP y discos paralelos. El procesamiento paralelo se realiza muchas operaciones simultneamente mientras que en el procesamiento secuencial, los distintos pasos computacionales han de ejecutarse en serie. Una mquina paralela de grano grueso consiste en un pequeo nmero de potentes procesadores; una maquina masivamente paralela o de grano fino utiliza miles de procesadores ms pequeos. Las mquinas de grano fino se diferencia de las de gano grueso por su alto grado de paralelismo. Para medir el rendimiento de los sistemas de base de datos existen 2 medidas principales: Productividad.- Nmero de tareas que pueden completarse en un intervalo de tempo determinado. Tiempo de respuesta.- Cantidad de tiempo necesario para complementar una nica tarea a partir del momento en que se envi. En el estudio del paralelismo la ganancia de velocidad y la ampliabilidad son dos aspectos importantes. La ganancia de velocidad se refiere a la ejecucin en menos tiempo de una tarea dada mediante el incremento del grado del paralelismo. La ampliabilidad se refiere al manejo de transacciones ms largas mediante el incremento del grado de paralelismo.
L. I.
UNIDAD II DISEO DE BASE DE DATOS DISTRIBUIDA. En la presente unidad se mostrar los aspectos importantes referentes al diseo de una base de datos distribuida. Se revisar el problema de fragmentacin de los datos as como la transparencia que un sistema de datos distribuidos debe guardar respecto a la vista del usuario. Se presentarn los algoritmos para fragmentacin horizontal, fragmentacin horizontal derivada y fragmentacin vertical. En la parte final de este captulo se discute el problema de asignacin de fragmentos. 2.1. CONSIDERACIONES DISTRIBUIDA. DE DISEO DE BASE DE DATOS
El principio fundamental de las bases de datos distribuidas: desde el punto de vista del usuario, un sistema distribuido deber ser idntico a un sistema no distribuido. En otras palabras, los usuarios de un sistema distribuido debern comportarse exactamente como si el sistema no estuviera distribuido. Todos los problemas de los sistemas distribuidos son (o deberan ser) internos o a nivel de realizacin, no externos o a nivel del usuario. La diferencia principal entre los sistemas de bases de datos centralizados y los distribuidos es que en los primeros, los datos residen en una sola localidad, mientras que, en lo ltimos, se encuentran en varias localidades. Cada localidad puede procesar transacciones locales, es decir, aquellas que slo acceden a datos que residen en esa localidad. Adems, una localidad puede participar en la ejecucin de transacciones globales, es decir, aquellas que acceden a datos de varias localidades, sta requiere comunicacin entre las localidades. Una transaccin local es la que accede a cuentas en la localidad individual donde se inicio. En cambio, una transaccin global accede a cuentas de una localidad distinta a la localidad donde se inicio o a cuentas de varias localidades diferentes. El problema de diseo de bases de datos distribuidos se refiere, en general, a hacer decisiones acerca de la ubicacin de datos y programas a travs de los diferentes sitios de una red de computadoras. Este problema debera estar relacionado al diseo de la misma red de computadoras. La ubicacin de los programas, a priori, no debera suponer un excesivo problema dado que se puede tener una copia de ellos en cada mquina de la red. Sin embargo, puede optarse colocar los datos en una gran mquina que albergue a todos ellos, encargada de responder a todas las peticiones del resto de las estaciones (sistema de base de datos centralizado), u optar en repartir las relaciones, las tablas, por toda la red (sistema de base de datos distribuido). En el supuesto que nos inclinemos por esta segunda opcin, qu criterios se deberan seguir para llevar a cabo tal distribucin? Realmente este enfoque ofrecer un mayor rendimiento que el caso centralizado? Podra optarse por alguna otra alternativa? En los prrafos sucesivos se tratar de responder a estas cuestiones. Tradicionalmente se ha clasificado la organizacin de los sistemas de bases de datos distribuidos sobre tres dimensiones: el nivel de comparticin, las caractersticas de acceso a los datos y el nivel de conocimiento de esas caractersticas de acceso (vea la figura 2.1).
L. I.
Figura 2.1. Enfoque de la distribucin.
El nivel de comparticin presenta tres alternativas: 1. Inexistencia: cada aplicacin y sus datos se ejecutan en un ordenador con ausencia total de comunicacin con otros programas u otros datos 2. se comparten slo los datos y no los programas , en tal caso existe una rplica de las aplicaciones en cada mquina y los datos viajan por la red. 3. se reparten datos y programas, dado un programa ubicado en un determinado sitio, ste puede solicitar un servicio a otro programa localizado en un segundo lugar, el cual podr acceder a los datos situados en un tercer emplazamiento. Como se coment lneas atrs, en este caso se optar por el punto intermedio de comparticin. El Modo de Acceso: se refiere a los datos, existen dos alternativas principalmente: 1. Modo de acceso esttico: los datos no cambiarn a lo largo del tiempo a peticin de los usuarios. 2. Modo de Acceso dinmico. lo realmente importante radica, estableciendo el dinamismo como base, cmo de dinmico es, cuntas variaciones sufre a lo largo del tiempo. Esta dimensin establece la relacin entre el diseo de bases de datos distribuidas y el procesamiento de consultas. El nivel de conocimiento de las caractersticas de acceso: 1. Ausencia de Informacin: que los diseadores carezcan de informacin alguna sobre cmo los usuarios acceden a la base de datos. 2. Informacin Total: Sera muy laborioso abordar el diseo de la base de datos con ausencia de informacin. Lo ms prctico sera conocer con detenimiento la forma de acceso de los usuarios; 3. Informacin Parcial: o, en el caso de la imposibilidad de proporcionar toda la informacin de forma de acceso, conformarnos con una informacin parcial de sta. El problema del diseo de bases de datos distribuidas podra enfocarse a travs de esta trama de opciones. En todos los casos, excepto aquel en el que no existe comparticin, aparecern una serie de nuevos problemas que son irrelevantes en el caso centralizado.
L. I.
Existen dos estrategias generales para abordar el problema de diseo de bases de datos distribuidas: 1. El enfoque de arriba hacia abajo (top-down o descendente) . Este enfoque es ms apropiado para aplicaciones nuevas y para sistemas homogneos. Consiste en partir desde el anlisis de requerimientos para definir el diseo conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseo de la fragmentacin de la base de datos, y de aqu se contina con la localizacin de los fragmentos en los sitios, creando las imgenes fsicas. Esta aproximacin se completa ejecutando, en cada sitio, "el diseo fsico" de los datos, que se localizan en ste. En la Figura 2.2 se presenta un diagrama con la estructura general del enfoque topdown.
2. El diseo de abajo hacia arriba (bottom-up o ascendente) . Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseo bottom-up de una base de datos distribuida requiere de la seleccin de un modelo de bases de datos comn para describir el esquema global de la base de datos. Esto se debe es posible que se utilicen diferentes SMBD. Despus se hace la traduccin de cada esquema local en el modelo de datos comn y finalmente se hace la integracin del esquema local en un esquema global comn. La estrategia descendente (vea la figura 2.2) debera resultar familiar a la persona que posea conocimientos sobre el diseo de bases de datos, exceptuando la fase del diseo de la distribucin. Pese a todo, se resumirn brevemente las etapas por las que se transcurre.
Figura 2.2. Estrategia descendente.
L. I.
Anlisis de los requisitos: definirn el entorno del sistema en aras a obtener tanto los datos como las necesidades de procesamiento de todos los posibles usuarios del banco de datos. Los objetivos: que se deben cumplir respecto a unos grados de rendimiento, seguridad, disponibilidad y flexibilidad, sin olvidar el importante aspecto econmico. El diseo de las vistas: trata de definir las interfaces para el usuario final. El diseo conceptual: se encarga de examinar la empresa para determinar los tipos de entidades y establecer la relacin entre ellas. Existe un vnculo entre el diseo de las vistas y el diseo conceptual. El diseo conceptual puede interpretarse como la integracin de las vistas del usuario, este aspecto es de vital importancia ya que el modelo conceptual debera soportar no slo las aplicaciones existentes, sino que debera estar preparado para futuras aplicaciones. En el diseo conceptual y de las vistas del usuario se especificarn las entidades de datos y se determinarn las aplicaciones que funcionarn sobre la base de datos, as mismo, se recopilarn datos estadsticos o estimaciones sobre la actividad de estas aplicaciones. Dichas estimaciones deberan girar en torno a la frecuencia de acceso, por parte de una aplicacin, a las distintas relaciones de las que hace uso, podra afinarse ms anotando los atributos de la relacin a la que accede. Desarrollado el trabajo hasta aqu, se puede abordar la confeccin del esquema conceptual global. El diseo de la distribucin. El objetivo de esta etapa consiste en disear los esquemas conceptuales locales que se distribuirn a lo largo de todos los puestos del sistema distribuido. Sera posible tratar cada entidad como una unidad de distribucin; en el caso del modelo relacional, cada entidad se corresponde con una relacin. Resulta bastante frecuente dividir cada relacin en subrelaciones menores denominadas fragmentos que luego se ubican en uno u otro sitio. De ah, que el proceso del diseo de la distribucin conste de dos actividades fundamentales: la fragmentacin y la asignacin. El diseo fsico: el cual proyecta los esquemas conceptuales locales sobre los dispositivos de almacenamiento fsico disponibles en los distintos sitios. Las entradas para este paso son los esquemas conceptuales locales y la informacin de acceso a los fragmentos. DISEO DE LA DISTRIBUCIN Existen diversas formas de afrontar el problema del diseo de la distribucin. Las ms usuales se muestran en la figura 2.3. En el primer caso, caso A, los dos procesos fundamentales, la fragmentacin y la asignacin, se abordan de forma simultnea. Esta metodologa se encuentra en desuso, sustituida por el enfoque en dos fases, caso B: la realizacin primeramente de la particin para luego asignar los fragmentos generados. El resto de los casos se comentan en la seccin referente a los distintos tipos de la fragmentacin.
L. I.
Figura 2.3. Enfoques para realizar el diseo distributivo. El diseo de una base de datos distribuida, cualquiera sea el enfoque que se siga, debe responder satisfactoriamente las siguientes preguntas:

Por qu hacer una fragmentacin de datos? Cmo realizar la fragmentacin? Qu tanto se debe fragmentar? Cmo probar la validez de una fragmentacin? Cmo realizar la asignacin de fragmentos? Cmo considerar los requerimientos de la informacin?
Figura 2.4. El problema de fragmentacin de relaciones.
2.2. DICCIONARIO DE DATOS. Una de las principales ventajas de cualquier DBMS es el control de los recursos mediante una organizacin. Para lograr ese control, existen dos elementos importantes para el manejo de un sistema de base: el administrador de la base de datos (DBA) y el diccionario de datos. El Administrador de la Base de Datos es un recurso compartido, distintos usuarios pueden tener requerimientos conflictivos para el sistema de la base. Las funciones ms importantes de un manejador de la base de datos son:
L. I.
a. Formular y coordinar los requerimientos de la base de datos. b. Disear los esquemas conceptuales y externos de la base. c. Implantar y mantener el sistema de la base de datos. Una de las herramientas que usa el Administrador de la Base de Datos para el manejo de los datos es el diccionario de datos. El diccionario de datos que contiene documentacin acerca de la base para su manejo. El Diccionario de Datos es una base de datos por derecho propio; contiene datos sobre los datos, es decir, describe todos los elementos de los datos de la base. La documentacin proporcionada por el Diccionario de Datos es valiosa para los usuarios, administradores y programadores. El Diccionario de Datos debe incluir: a. Descripciones externa, conceptual e interna de la base de datos. b. Descripciones de entidades (tipos de registro), atributos (campos), referencias cruzadas, origen y significado de los elementos de los datos. c. Sinnimos, homnimos y cdigos de autorizacin y seguridad. d. Qu esquemas son utilizados y por qu programas, quines son los usuarios y qu autorizaciones o derechos tienen. La importancia del Diccionario de Datos radica en dos puntos: 1. Fomenta la independencia de datos/programas; es decir, hace posible determinar la estructura y el contenido de la base de datos. No es necesario adivinar qu contiene, ni necesitamos mantener documentacin externa del archivo, o de los formatos de registro. 2. Si se cambia la estructura de los datos en la base, solo se introduce el cambio en el diccionario de datos. Estos sistemas tambin pueden hacer referencia a un diccionario de datos que tenga informacin sobra la distribucin de los datos entre los diferentes servidores SQL. En este enfoque, el servidor SQL recibe tambin el nombre de procesador de base de datos (DP: Database processor) o maquina dorsal, en tanto que el cliente se denomina procesador de aplicaciones (AP: applications processor) o maquina frontal. En un sistema distribuido, el catlogo del sistema incluir no solamente los datos usuales del catlogo con relaciones a la base, vistas, autorizaciones, etc., sino tambin toda la informacin de control necesaria para permitir que el sistema proporcione la independencia de ubicacin, fragmentacin y replica necesaria. 1. Centralizado: El catlogo total es almacenado exactamente una vez en un sitio central. 2. Completamente replicado: El catlogo total es almacenado por completo en cada uno de los sitios. 3. Dividido: Cada sitio mantiene su propio catlogo de los objetos que estn almacenados en ese sitio. El catlogo total es la unin de todos los catlogos locales disjuntos.
L. I.
4. Combinacin 1 y 3: Cada sitio mantiene su propio catlogo local, como en el punto 3; adems, un nico sitio central mantiene una copia unificada de todos esos catlogos locales, como en el punto 1. Cada uno de estos enfoques tiene sus problemas. El enfoque uno, viola: No dependencia de un sitio central. El enfoque dos, viola: Prdida de la autonoma. El enfoque tres, viola: Eleva en gran medida el costo de las operaciones. El enfoque cuatro, viola: No dependencia de un sitio central. 2.3. NIVELES DE TRANSPARENCIA. El propsito de establecer una arquitectura de un sistema de bases de datos distribuidas es ofrecer un nivel de transparencia adecuado para el manejo de la informacin. La transparencia se puede entender como la separacin de la semntica de alto nivel de un sistema de los aspectos de bajo nivel relacionados a la implementacin del mismo. Un nivel de transparencia adecuado permite ocultar los detalles de implementacin a las capas de alto nivel de un sistema y a otros usuarios. En sistemas de bases de datos distribuidos el propsito fundamental de la transparencia es proporcionar independencia de datos en el ambiente distribuido. Se pueden encontrar diferentes aspectos relacionados con la transparencia. Por ejemplo, puede existir transparencia en el manejo de la red de comunicacin, transparencia en el manejo de copias repetidas o transparencia en la distribucin o fragmentacin de la informacin. La independencia de datos es la inmunidad de las aplicaciones de usuario a los cambios en la definicin y/u organizacin de los datos y viceversa. La independencia de datos se puede dar en dos aspectos: lgica y fsica. 1. Independencia lgica de datos. Se refiere a la inmunidad de las aplicaciones de usuario a los cambios en la estructura lgica de la base de datos. Esto permite que un cambio en la definicin de un esquema no debe afectar a las aplicaciones de usuario. Por ejemplo, el agregar un nuevo atributo a una relacin, la creacin de una nueva relacin, el reordenamiento lgico de algunos atributos. 2. Independencia fsica de datos. Se refiere al ocultamiento de los detalles sobre las estructuras de almacenamiento a las aplicaciones de usuario. Esto es, la descripcin fsica de datos puede cambiar sin afectar a las aplicaciones de usuario. Por ejemplo, los datos pueden ser movidos de un disco a otro, o la organizacin de los datos puede cambiar. La transparencia al nivel de red se refiere a que los datos en un SBDD se acceden sobre una red de computadoras, sin embargo, las aplicaciones no deben notar su existencia. La transparencia al nivel de red conlleva a dos cosas:
L. I.
1. Transparencia sobre la localizacin de datos. Esto es, el comando que se usa es independiente de la ubicacin de los datos en la red y del lugar en donde la operacin se lleve a cabo. Es decir, No se exige a los usuarios que conozcan la ubicacin fsica de los datos. El sistema distribuido de base de datos debe poder hallar los datos siempre que la transaccin del usuario facilite la identificacin de los datos. 2. Transparencia sobre el esquema de nombramiento . Lo anterior se logra proporcionando un nombre nico a cada objeto en el sistema distribuido. As, no se debe mezclar la informacin de la localizacin con en el nombre de un objeto. La transparencia sobre replicacin de datos se refiere a que si existen rplicas de objetos de la base de datos, su existencia debe ser controlada por el sistema no por el usuario. Se debe tener en cuenta que al cuando el usuario se encarga de manejar las rplicas en un sistema, el trabajo de ste es mnimo por lo que se puede obtener una eficiencia mayor. Sin embargo, el usuario puede olvidarse de mantener la consistencia de las rplicas teniendo as datos diferentes. Los elementos de datos (como las relaciones, los fragmentos y las rplicas) deben tener nombres nicos. Esta propiedad es fcil asegurar en una base de datos centralizada. En las base de datos distribuidas, sin embargo, hay que tener cuidado para asegurar de que dos sitios no utilicen el mismo nombre para elementos de datos diferentes. Una solucin a este problema es exigir que todos los nombres se registren en un servidor de nombres central. El servidor de nombres ayuda asegurar que el mismo nombre no se utilice para los elementos de datos diferentes. Pero tienes dos desventajas: Cuello de botella. Si el servidor queda fuera de servicios. La transparencia a nivel de fragmentacin de datos permite que cuando los objetos de la bases de datos estn fragmentados, el sistema tiene que manejar la conversin de consultas de usuario definidas sobre relaciones globales a consultas definidas sobre fragmentos. As tambin, ser necesario mezclar las respuestas a consultas fragmentadas para obtener una sola respuesta a una consulta global. El acceso a una base de datos distribuida debe hacerse en forma transparente. La transparencia tiene como punto central la independencia de datos. Los diferentes niveles de transparencia se pueden organizar en capas como se muestra en la Figura 2.5. En el primer nivel se soporta la transparencia de red. En el segundo nivel se permite la transparencia de replicacin de datos. En el tercer nivel se permite la transparencia de la fragmentacin. Finalmente, en el ltimo nivel se permite la transparencia de acceso (por medio de lenguaje de manipulacin de datos). La responsabilidad sobre el manejo de transparencia debe estar compartida tanto por el sistema operativo, el sistema de manejo de bases de datos y el lenguaje de acceso a la base de datos distribuida. Entre estos tres mdulos
L. I.
se deben resolver los aspectos sobre el procesamiento distribuido de consultas y sobre el manejo de nombres de objetos distribuidos.
Figura 2.5. Organizacin en capas de los niveles de transparencia.
2.4. FRAGMENTACIN DE DATOS. El problema de fragmentacin El problema de fragmentacin se refiere a la particin de la informacin para distribuir cada parte a los diferentes sitios de la red, como se observa en la Figura 2.4. Inmediatamente aparece la siguiente pregunta: cul es la unidad razonable de distribucin? Se puede considerar que una relacin completa es lo adecuado ya que las vistas de usuario son subconjuntos de las relaciones. Sin embargo, el uso completo de relaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas con el procesamiento de consultas. La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual favorece la ejecucin concurrente de varias transacciones que acceden porciones diferentes de una relacin. Sin embargo, el uso de sub-relaciones tambin presenta inconvenientes. Por ejemplo, las vistas de usuario que no se pueden definir sobre un solo fragmento necesitarn un procesamiento adicional a fin de localizar todos los fragmentos de una vista. Aunado a esto, el control semntico de datos es mucho ms complejo ya que, por ejemplo, el manejo de llaves nicas requiere considerar todos los fragmentos en los que se distribuyen todos los registros de la relacin. En resumen, el objetivo de la fragmentacin es encontrar un nivel de particionamiento adecuado en el rango que va desde tuplas o atributos hasta relaciones completas (ver Figura 2.6). Ejemplo Considere la relacin J. J: JNO JNOMBRE PRESUPUE LUGAR
L. I.
STO J1 J2 J3 J4 J5 Instrumentaci n 150000 Monterrey Mxico Puebla Mxico Guadalajara
Desarrollo de 135000 bases de datos CAD/CAM Mantenimiento CAD/CAM 250000 310000 500000
La relacin J se puede fragmentar horizontalmente produciendo los siguientes fragmentos. J1: proyectos con presupuesto menor que $200,000
JNO J1 J2 JNOMBRE Instrumentaci n PRESUPUEST LUGAR O 150000 Monterrey Mxico
Desarrollo de 135000 bases de datos
J2: proyectos con presupuesto mayor que o igual a $200,000

JNO JNOMBRE J3 J4 J5 CAD/CAM PRESUPUEST LUGAR O 250000 Puebla Mxico Guadalajara
Mantenimiento 310000 CAD/CAM 500000
Ejemplo La relacin J del ejemplo anterior se verticalmente produciendo los siguientes fragmentos: J1: informacin acerca de presupuestos de proyectos
JNO J1 J2 J3 J4 J5 PRESUPUEST O 150000 135000 250000 310000 500000
puede
fragmentar
L. I.
J2: informacin acerca de los nombres y ubicaciones de proyectos

JNO JNOMBRE J1 J2 J3 J4 J5 Instrumentaci n LUGAR Monterrey
Desarrollo de Mxico bases de datos CAD/CAM Mantenimiento CAD/CAM Puebla Mxico Guadalajara
Figura 2.6. El grado de fragmentacin.
Alternativas sobre replicacin para la asignacin de fragmentos La replicacin de informacin es de utilidad para obtener un mejor rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicacin se complica cuando es necesario hacer actualizaciones a las copias mltiples de un dato. Por tanto, respecto a la replicacin, en la asignacin de fragmentos se tienen tres estrategias: 1. No soportar replicacin. Cada fragmento reside en un solo sitio. 2. Soportar replicacin completa. Cada fragmento en cada uno de los sitios. 3. Soportar replicacin parcial. Cada fragmento en algunos de los sitios. Como regla general se debe considerar que la replicacin de fragmentos es de utilidad cuando el nmero de consultas de solo lectura es (mucho) mayor que el nmero de consultas para actualizaciones. En la Tabla 2.1 se comparan la complejidad de implementar o tomar ventaja de las diferentes alternativas de replicacin, respecto de los diferentes aspectos importantes en bases de datos distribuidas.
Replicacin Completa
Replicacin Parcial
Particin
Academia de Informtica Ramn Edgardo Rincn Fernndez Procesamiento Consultas de Fcil Fcil o existente Moderado no Moderado Difcil Alto Realista Moderado Moderado Fcil Bajo Aplicacin posible
L. I.
Manejo de Directorios Control Concurrencia Confiabilidad Realidad
de Moderado Muy alto Aplicacin posible
Tabla 2.1. Comparacin de las estrategias de replicacin de fragmentos.
Requerimientos de informacin Con el fin de realizar una fragmentacin adecuada es necesario proporcionar informacin que ayude a realizarla. Esta informacin normalmente debe ser proporcionada por el usuario y tiene que ver con cuatro tipos: 1. 2. 3. 4. Informacin Informacin Informacin Informacin sobre el significado de los datos sobre las aplicaciones que los usan acerca de la red de comunicaciones acerca de los sistemas de cmputo
Tipos de fragmentacin de datos 1. Fragmentacin horizontal 2. Fragmentacin vertical 3. Fragmentacin hbrida Fragmentacin horizontal La fragmentacin horizontal primaria de una relacin se obtiene usando predicados que estn definidos en esa relacin. La fragmentacin horizontal derivada, por otra parte, es el particionamiento de una relacin como resultado de predicados que se definen en otra relacin. Para poder construir una fragmentacin, es necesario proporcionar informacin acerca de la base de datos y acerca de las aplicaciones que las utilizan. En primer trmino, es necesario proporcionar la informacin acerca del esquema conceptual global. En este sentido es importante dar informacin acerca de las relaciones que componen a la base de datos, la cardinalidad de cada relacin y las dependencias entre relaciones. Por ejemplo, en la Figura 3.4 se presenta un diagrama mostrando el esquema conceptual de la base de datos de ejemplo del captulo 2. En segundo lugar se debe proporcionar informacin acerca de la aplicacin que utiliza la base de datos. Este tipo de informacin es cuantitativa y consiste de los predicados usados en las consultas de usuario.
L. I.
Fragmentacin horizontal primaria Consiste del particionamiento en tuplas de una relacin global en subconjuntos, donde cada subconjunto puede contener datos que tienen propiedades comunes y se puede definir expresando cada fragmento como una operacin de seleccin sobre la relacin global. Ejemplo Considere la relacin global SUPPLIER (SNUM, NAME, CITY) Entonces, la fragmentacin horizontal puede ser definida como: SUPPLIER1 = SLcity == "SF"SUPPLIER SUPPLIER1 = SLcity == "LA"SUPPLIER 1. Esta fragmentacin satisface la condicin de completes si "SF" y "LA" son solamente los nicos valores posibles del atributo CITY. 2. La condicin de reconstruccin se logra con: SUPPLIER = SUPPLIER1 union SUPPLIER2 3. La condicin de disjuntos se cumple claramente en este ejemplo. Fragmentacin horizontal derivada La fragmentacin derivada horizontal se define partiendo de una fragmentacin horizontal. Una fragmentacin horizontal derivada se define en la relacin miembro de una liga de acuerdo a la operacin de seleccin especificada en la relacin propietaria. La liga entre las relaciones propietaria y miembro se define como una equi-junta. Una equi-junta se puede implementar por semi-juntas. Esto es importante, ya que se quiere particionar una relacin miembro de acuerdo a la fragmentacin de su propietario, pero se quiere que los fragmentos resultantes queden definidos nicamente en los atributos de la relacin miembro. En esta operacin se requiere de Semi-junta (Semi-Join) el cual nos sirve para derivar las tuplas o registros de dos relaciones. Para llevar a cabo una fragmentacin horizontal derivada se requieren tres entradas: el conjunto de particiones de la relacin propietaria, la relacin miembro, y el conjunto de predicados semi-junta entre el propietario y el miembro. El algoritmo de fragmentacin es trivial y no ser presentado aqu. 2.4.2 Fragmentacin vertical La fragmentacin vertical es la subdivisin de atributos en grupos. Los fragmentos se obtienen proyectando la relacin global sobre cada grupo. La fragmentacin es correcta si cada atributo se mapea en al menos un atributo del fragmento. Una fragmentacin vertical de una relacin R produce fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un subconjunto de los atributos de R as como la llave primaria de R. El objetivo de la fragmentacin vertical es particionar una relacin en un conjunto de relaciones ms pequeas de manera que varias de las aplicaciones de usuario se ejecutarn sobre un fragmento. En este contexto, una fragmentacin "ptima" es aquella que
L. I.
produce un esquema de fragmentacin que minimiza el tiempo de ejecucin de las consultas de usuario. La fragmentacin vertical es inherentemente ms complicada que particionamiento horizontal ya que existe un gran nmero de alternativas para realizarla. Por lo tanto, se utilizan heursticas para hacer el particionamiento. Los dos enfoques bsicos son: 1. Agrupamiento. Inicia asignando cada atributo a un fragmento, y en cada paso, algunos de los fragmentos satisfaciendo algn criterio se unen para formar un solo fragmento. 2. Divisin. Inicia con una sola relacin realizar un particionamiento basado en el comportamiento de acceso de las consultas sobre los atributos. Como en el caso de la fragmentacin horizontal, es necesario proporcionar informacin para poder realizar una adecuada fragmentacin vertical. Ya que el particionamiento vertical coloca en un fragmento aquellos atributos que se acceden juntos, se presenta la necesidad de una medida que relacione la afinidad de los atributos, la cual indica qu tan relacionados estn los atributos. Esta medida se obtiene por datos primitivos. Ejemplo Considere la siguiente relacin global: EMP (empnum, name, sal, tax, mgrnum, depnum) Una fragmentacin vertical de esta relacin puede ser definida como: EMP1 = PJempnum, name, mgrnum, depnum EMP EMP2 = PJempnum, sal, tax EMP La reconstruccin de la relacin EMP puede ser obtenida como: EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP. Ejemplo Considere la relacin J de la Figura 3.4. Suponga que las siguientes consultas se definen sobre esta relacin: q1: Encuentre el presupuesto de un proyecto dado su nmero de identificacin. SELECT PRESUPUESTO FROM J WHERE JNO=valor q2: Encuentre los nombres y presupuestos de todos los proyectos. SELECT JNOMBRE, PRESUPUESTO FROM J q3: Encuentre los nombres de los proyectos en una ciudad dada. SELECT JNOMBRE FROM J WHERE LUGAR=valor q4: Encuentre el presupuesto total de los proyectos en cada ciudad.
L. I.
SELECT SUM (PRESUPUESTO) FROM J WHERE LUGAR=valor Sean A1=JNO, A2=JNOMBRE, A3=PRESUPUESTO, A4=LUGAR. La funcin use se puede representar por la siguiente matriz:
Algoritmo de Agrupamiento (Clustering) La tarea fundamental en el diseo de una fragmentacin vertical es encontrar algn medio para agrupar los atributos de una relacin basndose en los valores de afinidad entre atributos. La idea del algoritmo de agrupamiento es tomar la matriz de afinidades entre atributos (AA) y reorganizar el orden de los atributos para formar grupos en donde los atributos dentro de cada grupo presentan alta afinidad uno con otro. El algoritmo de energa acotada (BEA por sus siglas en ingls) encuentra un ordenamiento de los atributos, de tal manera, que se maximiza la siguiente medida de afinidad global (AM): Algoritmo de Particionamiento 1. El objetivo del particionamiento es encontrar conjuntos de atributos que son accedidos de manera nica, o a lo ms, por conjuntos disjuntos de consultas. 3.4.4 Fragmentacin hbrida En la que respecto a la fragmentacin hbrida, esta consiste en aplicar la fragmentacin vertical seguida de la fragmentacin horizontal o viceversa. En muchos casos una fragmentacin horizontal o vertical de un esquema de una base de datos no ser suficiente para satisfacer los requerimientos de aplicaciones de usuario. En este caso, una fragmentacin vertical puede ser seguida de uno horizontal, o viceversa, produciendo un rbol de particionamiento estructurado, como se muestra en la Figura 2.7. Ya que los dos tipos de particionamiento se aplican uno despus del otro, esta alternativa se le conoce como fragmentacin hbrida.
L. I.
Figura 2.7. Fragmentacin hbrida. Un buen ejemplo de la necesidad de la fragmentacin hbrida es la relacin J, con la cual se ha trabajado. En la Figura 2.8 se muestra el rbol de reconstruccin de la fragmentacin hbrida de J. Inicialmente se aplica una fragmentacin horizontal y posteriormente una fragmentacin vertical.
Figura 2.8. Fragmentacin hbrida de la relacin J. Ejemplo Considere la relacin global EMP (empnum, name, sal, tax, mrgnum, depnum) Las siguientes son para obtener una fragmentacin mixta, aplicando la vertical seguida de la horizontal: EMP1 = SL depnum <= 10 PJempnum, name, mgrnum, depnum EMP EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum EMP EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum EMP EMP4 = PJ empnum, name, sal, tax EMP La reconstruccin de la relacin EMP es definida por la siguiente expresin: EMP = UN (EMP1, EMP2, EMP3)JNempnum = empnumPJempnum, sal, tax EMP4 Finalmente, como otro ejemplo considere el siguiente esquema global EMP (EMPNUM, NAME, SAL, TAX, MGRNUM, DEPNUM) DEP (DEPNUM, NAME, AREA, MGRNUM) SUPPLIER (SNUM, NAME, CITY) SUPPLY (SNUM, PNUM, DEPNUM, QUAN)
L. I.
Despus de aplicar una fragmentacin mixta se obtiene el siguiente esquema fragmentado EMP1 = Sldepnum <= 10 PJempnum, name, mgrnum, depnum (EMP) EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum (EMP) EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum (EMP) EMP4 = PJ empnum, name, sal, tax (EMP) DEP1 = SL depnum <= 10 (DEP) DEP2 = SL 10 < depnum <= 20 (DEP) DEP3 = SL depnum > 20 (DEP) SUPPLIER1 = SL city == "SF" (SUPPLIER) SUPPLIER2 = SL city == "LA" (SUPPLIER) SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2 Ejemplos: 1. select * from alumno, (select * from boleta) as boleta where alumno.nc=boleta.nc (Fragmentacin horizontal) 2. select nombre,ape_paterno, ape_materno, grado, grupo from alumno, (select * from boleta where boleta.nc=1) as boleta where alumno.nc=boleta.nc (Fragmentacin horizontalvertical) 3. select * from alumno, (select folio, promedio, ciclo, nc from boleta) as boleta where alumno.nc=boleta.nc (Fragmentacin vertical-horizontal) ASIGNACIN DE FRAGMENTOS La asignacin de recursos entre los nodos de una red de computadoras es un problema que se ha estudiado de manera extensa. Sin embargo, la mayora de este trabajo no considera el problema de diseo de bases de datos distribuidas, en lugar de eso considera el problema de ubicar archivos individuales en redes de computadoras. El problema de asignacin Suponga que hay un conjunto de fragmentos F = { F1, F2, ..., Fn } y una red que consiste de los sitios S = { S1, S2, ..., Sm } en los cuales un conjunto de consultas Q = { q1, q2, ..., qq } se van a ejecutar. El problema de asignacin determina la distribucin "ptima" de F en S. La optimizacin puede ser definida de acuerdo a dos medidas: 1. Costo mnimo. Consiste del costo de comunicacin de datos, del costo de almacenamiento, y del costo procesamiento (lecturas y actualizaciones a cada fragmento). El problema de asignacin, entonces, pretende encontrar un esquema de asignacin que minimiza una funcin de costo combinada. 2. Rendimiento. La estrategia de asignacin se disea para mantener una mtrica de rendimiento. Las dos mtricas ms utilizadas son el tiempo de respuesta y el "throughput" (nmero de trabajos procesados por unidad de tiempo).
L. I.
En cualquier problema de optimizacin existen restricciones que se deben satisfacer. El caso de distribucin de fragmentos, las restricciones se establecen sobre las capacidades de almacenamiento y procesamiento de cada nodo en la red. En la fase de asignacin se necesita conocer informacin cuantitativa relativa a la base de datos, las aplicaciones que se utilizarn, la red de comunicaciones, las capacidades de procesamiento y de almacenamiento de cada nodo en la red.
Informacin sobre la base de datos. Es necesario conocer la selectividad de un fragmento Fj con respecto a una consulta qi, esto es, el nmero de tuplas de Fj que ser necesario acceder para procesar qi. As tambin, es necesario conocer el tamao de cada fragmento, el cual est dado por. Informacin sobre las aplicaciones. Es necesario distinguir el nmero de lecturas que una consulta qj hace a un fragmento Fj durante su ejecucin, del nmero de escrituras. Se requiere de una matriz que indique que consultas actualizan cuales fragmentos. Una matriz similar se necesita para indicar las lecturas de consultas a fragmentos. Finalmente, se necesita saber cual es el nodo de la red que origina cada consulta. Informacin sobre cada nodo de la red. Las medidas utilizadas son el costo unitario de almacenamiento de datos en un nodo y el costo unitario de procesamiento de datos en un nodo. Informacin sobre la red de comunicaciones. Las medidas a considerar son: la velocidad de comunicacin, el tiempo de latencia en la comunicacin y la cantidad de trabajo adicional a realizar para una comunicacin. 2.5.- Distribucin de Datos.
Un esquema de fragmentacin de una base de datos es una definicin de un conjunto de fragmentos que incluyen todos los atributos y tuplas de la base de datos y satisface la condicin de que la base de datos completa se puede reconstruir a partir de fragmentos mediante alguna secuencia de operaciones UNION EXTERNA ( REUNION EXTERNA) y UNION. Un esquema de reparto describe el reparto de fragmentos entre los sitios de la base de datos distribuida; por tanto, es una correspondencia que especifica el sitio o sitios donde se almacena cada fragmento. Si un fragmento se guarda en ms de un sitio, se dice que esta replicado.
2.5.1.- Algoritmos de distribucin de datos no replicados. Los algoritmos de distribucin de datos no replicados son los que cada fragmento se almacena exactamente en un sitio. En este caso todos los fragmentos deben ser disjuntos, con excepcin de la repeticin de la clave primaria entre los fragmentos. Esto tambin se denomina reparto no redundante.
L. I.
2.5.2.- Algoritmos de distribucin de datos replicados. Los algoritmos de distribucin de datos con replicacin resultan tiles para mejorar la disponibilidad de los datos. El caso ms extremo es la replicacin de toda la base de datos en todos los sitios del sistema distribuido, creado as una base de datos distribuida totalmente replicada. Esto puede mejorar la disponibilidad notablemente por que el sistema puede seguir operando mientras, por lo menos, uno de los sitios est activo. Tambin mejora el rendimiento de la obtencin de los datos en consultas globales, por que el resultado de semejantes consultas se puede obtener localmente en cualquier sitio; as, una consulta de obtencin de datos se puede procesar en el sitio local donde se introduce, si dicho sitio cuenta con un modulo servidor. La desventaja de la replicacin completa es que puede reducir drsticamente la rapidez de las operaciones de actualizacin, pues una sola actualizacin lgica se deber ejecutar con todas y cada una de las tuplas de las copias de la base de datos a fin de mantener la consistencia. Con esto las tcnicas de control de concurrencia y recuperacin se tornan ms costosas de lo que seria sin replicacin. Entre estos dos extremos, tenemos una amplia gama de replicacin parcial de los datos; es decir, algunos fragmentos de la base de datos pueden estar replicados y otros no. El nmero de copias de cada fragmento puede ir desde una hasta el nmero total de sitios en el sistema distribuido. En ocasiones se llama esquema de replicacin a una descripcin de la replicacin de los fragmentos. Cada fragmento o cada copia de un fragmento se deben asignar a un sitio determinado en el sistema distribuido. Este proceso se denomina distribucin de datos (Reparto de datos). La eleccin del sitio y el grado de replicacin dependen de los objetivos de rendimiento y disponibilidad para el sistema y el de los tipos y frecuencia de transacciones introducidas en cada sitio. Los datos que se utilizan en mltiples sitios se pueden replicar en esos sitios. Si se efectan muchas actualizaciones, puede ser conveniente limitar la replicacin. Encontrar una solucin optima, o siquiera buena, para el reparto de los datos distribuidos es un problema de optimizacin complejo.
L. I.
Unidad 3.- Procesamiento de Consultas Distribuidas

Consultas Centralizadas.- Para expresar una consulta en lenguaje de alto nivel como SQL, primero debe pasar por un examen lxico, un anlisis sintctico y una validacin. El anlisis lxico identifica los componentes del lenguaje (componentes lxicos) en el texto de consulta, y el analizador sintctico revisa la sintaxis de la consulta para determinar si est formulada de acuerdo a las reglas sintcticas (reglas gramaticales) del lenguaje de consulta. Adems las consultas deben validar, para lo cual ha de comprobarse que todos los nombres de los atributos y de relaciones sean validos y que tengan sentido desde el punto de vista semntico. A continuacin se crea una representacin interna de la consulta, por lo regular en forma de estructura de rbol o de grafo; esto se denomina rbol o grafo de consulta. En seguida se crea una estrategia de ejecucin para obtener el resultado de la consulta a partir de los archivos internos de la base de datos. Por lo regular, una consulta tiene muchas posibles estrategias de ejecucin, y el proceso de elegir la ms adecuada para procesar una consulta se conoce como optimizacin de consultas.
El modulo de optimizador de consultas se encarga de producir un plan de ejecucin, y el generador de cdigo genera el cdigo necesario para ejecutarlo. El procesador de la base de datos en tiempo de ejecucin se encarga de ejecutar el cdigo de consulta, sea compilado o interpretado,
L. I.
para producir el resultado de la consulta. Si se presenta un error durante la ejecucin, este procesador genera un mensaje de error. En realidad, el termino optimizador no es correcto porque, en algunos casos, el plan de ejecucin elegido no es la estrategia ms optima (la mejor); es tan solo una estrategia razonablemente eficiente para ejecutar la consulta. En general, encontrar la estrategia optima consume demasiado tiempo si la consulta no es muy simple, y pueden requerir informacin sobre como estn implementados los archivos o incluso el contenido de stos; informacin que tal vez no ste disponible en el catalogo del SGBD. As pues, tal vez sea ms correcto el termino planificar una estrategia de ejecucin que optimizar una consulta. Por lo general, todos los SGBD cuentan con varios algoritmos generales de acceso a la base de datos que implementan operaciones relacionales como: Seleccionar, Reunin o sus combinaciones. El mdulo de optimizacin de consultas slo puede considerar las estrategias de ejecucin que puedan poner en prctica los algoritmos de acceso del SGBD y que se apliquen al diseo particular de la base de datos. Para una base de datos centralizada el criterio principal para medir el coste de una estrategia dada es el nmero de acceso al disco. 3.1 Metodologa del procesamiento de consultas distribuidas. En un sistema distribuido varios factores adicionales complican aun ms el procesamiento de consultas. El primero el coste de transferir datos por la red. Esto incluye los archivos intermedios que se transfieren a otros sitios para continuar su procesamiento, as como los archivos de resultado finales que tal vez deban transferirse al sitio donde se necesita el resultado de la consulta. Aunque es posible que estos costos no sean demasiado altos si los sitios estn conectados a una red de rea local de alto rendimiento, adquieren una importancia considerable en otros tipos de redes. Por ello los algoritmos de optimizacin de consultas de los SGBDD consideran el objetivo de reducir la cantidad de transferencia de datos como criterio de optimizacin al elegir una estrategia de ejecucin de una consulta distribuida. La ganancia potencial en rendimiento si se hace en varios sitios procese en paralelo parte de las consultas. El acceso a los diferentes elementos de datos en los sistemas distribuidos suele realizarse mediante transacciones, que deben preservar las propiedades ACID. Hay dos tipos de transacciones: Transacciones Locales. Transacciones Globales. Cada sitio tiene su propio gestor local de transacciones cuya funcin es asegurar las propiedades ACID de las transacciones que se ejecuten en ese sitio. Los diferentes gestores de transacciones colaboran para ejecutar las transacciones globales. Para comprender el modo en que se pueden implementar estos gestores, considrese un modelo abstracto de sistema de transacciones, en el que cada sitio contenga dos subsistemas:
L. I.
El gestor de transacciones administra la ejecucin de las transacciones (o subtransacciones) que tiene acceso a los datos almacenados en un sitio local. Tngase en cuenta que cada una de esas transacciones pueden ser una transaccin local (es decir, una transaccin que se ejecuta slo en ese sitio) o parte de una transaccin global (es decir, una transaccin que se ejecuta en varios sitios). El coordinador de transacciones coordina la ejecucin de las diferentes transacciones (tanto locales como globales) iniciadas en ese sitio. La arquitectura global del sistema se muestra en la siguiente imagen.
La estructura de los gestores de transacciones es parecida en muchos aspectos a la de los sistemas centralizados. Cada gestor de transacciones es responsable de: 1. Mantenimiento de un registro histrico con fines de recuperacin. 2. Participacin en un esquema adecuado de control de la concurrencia para coordinar la ejecucin concurrente de las transacciones que se ejecuten en ese sitio. El subsistema de coordinacin de transacciones no se necesita en los entornos centralizados, dado que las transacciones slo tienen acceso a los datos en un sitio. Los coordinadores de transacciones, como su propio nombre implica, son responsables de la coordinacin de la ejecucin de todas las transacciones iniciadas en ese sitio. En cada una de esas transacciones el coordinador es responsable de: 1. Inicio de la ejecucin de la transaccin. 2. Divisin de la transaccin en varias subtransacciones y distribuir esas subtransacciones a los sitios correspondientes para su ejecucin. 3. Coordinacin de la terminacin de la transaccin, que puede ser que la transaccin se comprometa en todos los sitios o que se aborte en todos los sitios.
3.2 Estrategias de procesamiento de consultas distribuidas.
L. I.
3.2.1 rboles de Consulta. El analizador sintctico de una consulta de alto nivel la representacin interna (rbol de consulta), que despus se optimiza de acuerdo a las leyes de la heurstica. Definicin heurstica: De acuerdo con ANSI/IEEE Std 100-1984, la heurstica trata de mtodos o algoritmos exploratorios durante la resolucin de problemas en los cuales las soluciones se descubren por la evaluacin del progreso logrado en la bsqueda de un resultado final. Se suele usar actualmente como adjetivo, caracterizando tcnicas por las cuales se mejora en promedio el resultado de una tarea resolutiva de problemas (parecido al uso de "mtodo ptimo"). Se suele decir que hay bsquedas ciegas, bsquedas heursticas (basadas en la experiencia) y bsquedas racionales. La principal regla de la heurstica es aplicar las operaciones de SELECCIONAR y PROYECTAR antes de aplicar la REUNION u otras operaciones binarias. La REUNION es multiplicativa, mientras que PROYECTAR y SELECCIONAR reduce. Un rbol de consulta es una estructura de rbol que corresponde a una expresin de algebra relacional por el hecho que representa las relaciones de entrada como nodos hojas del rbol y las operaciones del lgebra relacional como nodos internos. Una ejecucin del rbol de consulta consiste en la ejecucin de un nodo interno siempre que sus operandos estn disponibles, sustituyendo despus en ese nodo interno por la relacin que resulte de ejecutar la operacin. La ejecucin termina cuando el nodo raz produce la relacin resultado. Por ejemplo se realizara la siguiente consulta: Para cada proyecto ubicado en Santiago, obtener su nmero, el nmero de departamento que lo controla, y el apellido, la direccin y fecha de nacimiento del gerente de ese departamento. La consulta en SQL seria:
SELECT NMEROP, NMP, APPELLIDO, DIRECCIN, FECHAN FROM PROYECTO, DEPARTAMENTO, EMPLEADO WHERE NMD=NMEROD AND NSSGTE=NSS LUGARP=Santiago
AND
NMEROP, NMP, APPELLIDO, DIRECCIN, FECHAN ((( LUGARP=Santiago (PROYECTO)) NMD=NMEROD(DEPARTAMENTO)) NSSGTE=NSS(EMPLEADO))
L. I.
En la figura (a) se representan las tres relaciones, PROYECTO, DEPARTAMENTO y EMPELADO con nodos hojas, en tanto que las operaciones del lgebra relacional de la expresin se representan en nodos internos del rbol. Cuando se ejecuta este rbol de consulta, el nodo numerado con (1) en la figura se ejecuta antes que el nodo (2) por que el resultado de la operacin (1) debe estar disponible para poder ejecutar la operacin (2). De manera similar, el nodo (2) debe ejecutarse antes que el nodo (3), y as sucesivamente. En general muchas expresiones diferentes de lgebra relacional y por lo tanto muchos rboles de consulta distintos pueden ser equivalentes; es decir, pueden corresponder a la misma consulta. Adems, una consulta se puede expresar de varias maneras en un lenguaje de consulta de alto nivel como SQL. El analizador sintctico de consultas casi siempre genera un rbol de consulta cannico (Figura b) estndar correspondiente a la misma consulta. Primero se aplica el producto cartesiano de las relaciones especificadas en la clusula FROM; luego las condiciones de seleccin y reunin de la clusula WHERE, seguida de la proyeccin sobre los atributos de la clusula SELECT. Semejante rbol de consulta cannico representa una expresin de lgebra relacional que es muy ineficiente si se ejecuta directamente, debido a las operaciones de producto cartesiano (X). Por ejemplo si la relacin PROYECTO, DEPARTAMENTO y EMPELADO tuvieran registros de 100, 50 y 150 bytes, y contuvieran 100, 20 y 500 tuplas, respectivamente, el registro del producto cartesiano contendra 1 milln de tuplas con tamao de registro de 300 bytes cada una.
L. I.
Sin embargo, el rbol de consulta esta en forma estndar simple; toca al optimizador de consultas heurstica transformar el rbol de consulta inicial en un rbol de consulta final cuya ejecucin sea ms eficiente. El optimizador debe incluir reglas de equivalencia entre expresiones del lgebra relacional que puedan aplicarse al rbol inicial, guiadas por las reglas de la heurstica de optimizar consultas, para producir el rbol de consulta final optimizado. 3.2.2 Transformaciones Equivalentes. En general muchas expresiones diferentes de lgebra relacional y por lo tanto muchos rboles de consulta distintos pueden ser equivalentes; es decir, pueden corresponder a la misma consulta. Ejemplo de Transformacin de una consulta. Consideremos una consulta C: Buscar los apellidos de los empleados nacidos despus de 1957 que trabajan en un proyecto llamado Acuario. Esta consulta se puede especificar en SQL as: SELECT APELLIDO FROM EMPLEADO, TRABAJA_EN, PROYECTO WHERE NOMBREP=Acuario AND NMEROD=NMD AND NSSE=NSS AND ND FECHA > 31-Dic-57 El rbol de consulta inicial para C se muestre en la figura (a). La ejecucin directa de este rbol crea un primer archivo muy grande que contiene el producto cartesiano de los archivos EMPLEADO, TRABAJA_EN y PROYECTO completos. Sin embargo, solo necesitamos un registro de PROYECTO, el del proyecto Acuario, y solo los registros de los empleados en los que la fecha de nacimiento sea posterior a 31-Dic-57. La figura (b) ilustra un rbol de consulta mejorado que primero aplica las operaciones SELECCIONAR para reducir el numero de tuplas que aparecen en el producto cartesiano. Se logra una mejora intercambiando las posiciones de la relacin EMPLEADO y PROYECTO en el rbol, como se aprecia en la figura (c).
L. I.
L. I.
Esto aprovecha la informacin de que NMEROP es un atributo de la relacin PROYECTO, y por ello la operacin SELECCIONAR sobre la relacin PROYECTO obtendr un solo registro. Podemos mejorar aun ms el rbol de consulta reemplazando todas las operaciones de PRODUCTO CARTESIANO seguidas de una condicin de reunin con una operacin REUNION, como la figura (d). Otra mejora consistente en conservar en las relaciones intermedias temporales slo los atributos requeridos por el rbol de consulta, como se aprecia en la figura (e). Esto reduce el nmero de atributos (columnas) de
L. I.
las relaciones intermedias temporales, mientras que las operaciones SELECCIONAR slo reduce el numero de tuplas (registros). 3.2.3 Mtodos de ejecucin del JOIN. Consiste en obtener el producto (multiplicacin) de todas las tuplas de una tabla con las de la otra, para posteriormente evaluar aquellas cuyo campo en comn sea igual generando como resultado una nueva tabla que tiene como tuplas (renglones) que cumplen con la condicin establecida. Se representa con la orden JOIN. Veamos las tablas que se han producido evaluando los pasos necesarios para una JOIN. Sean las siguientes tablas dadas:
R A | B | C ---+---+--1 | 2 | 3 4 | 5 | 6 7 | 8 | 9 S C | D | E ---+---+--3 | a | b 6 | c | d
Primero calculamos el producto cartesiano R S y tendremos:

R x S A | B | R.C | S.C | D | E ---+---+-----+-----+---+--1 | 2 | 3 | 3 | a | b 1 | 2 | 3 | 6 | c | d 4 | 5 | 6 | 3 | a | b 4 | 5 | 6 | 6 | c | d 7 | 8 | 9 | 3 | a | b 7 | 8 | 9 | 6 | c | d
Tras la seleccin R R.C=S.CS tendremos:

A | B | R.C | S.C | D | E ---+---+-----+-----+---+--1 | 2 | 3 | 3 | a | b 4 | 5 | 6 | 6 | c | d
Los algoritmos o estrategias ms comunes para la ejecucin de una operacin REUNIN (JOIN) son: Reunin en bucles anidados (Bsicamente consiste en un par de bucles for anidados. La relacin r se denomina relacin externa y s la relacin interna). Reunin en bucles anidados por bloques. Reunin en bucles anidados indexada. Reunin por mezcla. Reunin por asociacin. En un sistema distribuido varios factores adicionales complican aun ms el procesamiento de consultas: Costo por transferencia de datos por la red. Creacin te archivos temporales y finales. Transmitir el resultado al nodo que solicito.
L. I.
Supongamos que la relacin EMPLEADO y DEPARTAMENTO estn en dos sitos diferentes. Supondremos que en este ejemplo ninguna de las relaciones est fragmentada. El tamao de la relacin EMPLEADO es 100* 10000=1000000 bytes (10000 registros, y cada registro tiene una longitud de 100 bytes), y el tamao de la relacin DEPARTAMENTO es 35 * 100 = 3500 bytes (100 registros de 35 bytes cada registro). Consideremos la consulta C: Para cada empleado, obtener su nombre y el nombre de departamento al que pertenece. Esto se puede expresar como sigue en lgebra relacional:
C: NOMBREP, APELLIDO, NOMBRED (EMPLEADO ND=NMEROD DEPARTAMENTO)

El resultado de esta consulta incluir 10,000 registros, si todos los empleados estn relacionados con un departamento. Supngase que cada registro de resultado de la consulta tiene 40 bytes de longitud. La consulta se introduce en un sitio 3 distinto, que se denomina sitio del resultado por que ah es donde se necesita el resultado de la consulta. Ninguna de las dos relaciones, EMPLEADO y DEPARTAMENTO, residen en el sitio 3. Hay tres estrategias simples para ejecutar esta consulta distribuida: 1. Transferir la relacin EMPLEADO y DEPARTAMENTO al sitio del resultado, y efectuar la reunin en el sitio 3. En este caso necesitamos transferir un total de 1,000,000+3,500=1,003,500 bytes. 2. Transferir la relacin EMPLEADO al sitio 2, ejecutar la reunin en ese sitio y enviar el resultado al sitio 3. El tamao del resultado de la consulta es 40 * 100,000= 400,000 bytes, de modo que debemos transferir 400,000+1,000,000=1,400,000 bytes. 3. Transferir la relacin DEPARTAMENTO al sitio 1, ejecutar la reunin en ese sitio y enviar el resultado al sitio 3. En este caso tenemos que transferir 400,000+3,500=403,500 bytes. Si minimizamos la cantidad de transferencias de datos en nuestro criterio de optimizacin debemos elegir la estrategia 3. Consideremos ahora otra consulta C: Para cada departamento, obtener el nombre del departamento y el de su gerente. Esto se puede expresar como sigue en lgebra relacional:
C: NOMBRED, NOMBREP, APELLIDO (DEPARTAMENTO NSSGET=NSS EMPLEADO)

Una vez ms, supongamos que la consulta se introduce en el sitio 3. Las mismas tres estrategias de consulta C se aplican a C, excepto que el resultado de C incluye solo 100 registros, si suponemos que todos los departamentos tiene un gerente: 1. Transferir la relacin EMPLEADO y DEPARTAMENTO al sitio del resultado, y efectuar la reunin en el sitio 3. En este caso necesitamos transferir un total de 1,000,000+3,500=1,003,500 bytes.
L. I.
2. Transferir la relacin EMPLEADO al sitio 2, ejecutar la reunin en ese sitio y enviar el resultado al sitio 3. El tamao del resultado de la consulta es 40 * 100= 4,000 bytes, de modo que debemos transferir 4,000+1,000,000=1,004,000 bytes. 3. Transferir la relacin DEPARTAMENTO al sitio 1, ejecutar la reunin en ese sitio y enviar el resultado al sitio 3. En este caso tenemos que transferir: 3,500+400,000=403,500 Bytes. (Verificar: 4000+3500=7500 bytes). Una vez ms escogeramos la estrategia 3, en este caso por un margen abrumador sobre la estrategia 1 y 2. Las tres estrategias anteriores son las ms obvias para el caso en que el sitio del resultado (sitio 3) no es ninguno de los sitios que contienen archivos implicados en la consulta (sitio 1 y 2). Sin embargo, supongamos que el sitio de resultado es el 2; entonces tendremos dos estrategias simples: 1. Transferir la relacin EMPLEADO al sitio 2, ejecutar la consulta y presentar el resultado al usuario en ese mismo sitio. Aqu, necesitaramos transferir el mismo nmero de bytes 1,000,000 para C y C. 2. Transferir la relacin DEPARTAMENTO al sitio 1, ejecutar la reunin en ese mismo sitio y devolver el resultado al sitio 2. En este caso tenemos que transferir para C y 4,000 + 3,500 =7,500 para C. Una estrategia ms compleja que a veces funciona es la utilizacin de la operacin semirreunin. El procesamiento de consultas distribuidas mediante la operacin de semirreunin se basa en la idea de reducir el nmero de tuplas de una relacin antes de transferirla a otro sitio. Intuitivamente, la idea es enviar la columna de reunin de una relacin R al sitio donde se encuentra la otra relacin S; esta columna se rene entonces con S. Despus de ello, los atributos de reunin, junto con los atributos requeridos en el resultado, se extraen por proyeccin y se devuelven al sitio original donde se renen con R. As pues, solo se transfieren las columnas de reunin de R en una direccin, y un subconjunto de S que no contenga tuplas que no intervengan en el resultado se transfiera en otra direccin. Si slo una pequea fraccin de las tuplas de S participa en la reunin, esto puede ser una solucin bastante eficiente para minimizar la transferencia de datos. Consideremos la siguiente estrategia para ejecutar C o C: 1. Proyectar los atributos de reunin de Departamento en el sitio 2 y transferirlo al sitio 1. En el caso de C, transferimos F= NMEROD(DEPARTAMENTO), cuyo tamao es 4* 100=400 bytes; en el caso de C, transferimos F= NSSGTE (DEPARTAMENTO), cuyo tamao es 9*100=900 bytes.
2. Reunir el archivo con la relacin EMPLEADO en el sitio 1 y transferir los
atributos requeridos del archivo resultante al sitio 2. En el caso de C, transferimos R= <ND, NOMBREP, APELLIDO>(F NMEROD=ND EMPLEADO), cuyo tamao es 34*10,000=340,000 bytes; en el caso de C, transferimos R= <NSSGTE, NOMBREP, APELLIDO>(F NSSGTE=NSS EMPLEADO) cuyo tamao es 39*100=3,900 bytes.
L. I.
3. Ejecutar la consulta reuniendo el archivo transferido R R con DEPARTAMENTO, y presentar el resultado al usuario en el sitio 2. Si utilizamos esta estrategia, transferiramos 340, 400 bytes en el caso C y 4800 en el caso C. Limitamos los atributos y las tuplas de EMPLEADO transmitidos al sitio 2 en el paso 2 a slo los que se van a reunir efectivamente con una tupla DEPARTAMENTO en el paso 3. En el caso de la consulta C, esto incluy todas las tuplas de EMPELADO, por lo que no se logr una mejora significativa. En el caso de C solo se necesitaron 100 de 10000. 3.3 Optimizacin de Consultas. Por lo regular, una consulta tiene muchas posibles estrategias de ejecucin, y el proceso de elegir la ms adecuada para procesar una consulta se conoce como optimizacin de consultas. 3.3.1 Optimizacin Global de Consultas. En este caso se debe elegir la mejor estrategia de ejecucin de las consultas distribuidas, ya sea por la cantidad de transferencias a travs de la red o en su defecto por la estrategia de semirreunin, a dems de una correcta reparticin de transacciones entre todo y cada uno de los sitios. 3.3.2 Optimizacin Local de Consultas. Se busca un buen anlisis de la consulta a travs de los rboles de consulta y aplicado las leyes de la heurstica para reducir el nmero de acceso a los bloques de memoria o la creacin de demasiados archivos intermedio. As como reducir el nmero de reuniones o productos cartesiano para no multiplicar el nmero de tuplas a consultar y con ello aumentar el procesamiento de la misma. 3.3.3 Fragmentacin Hbrida. Hay dos esquemas diferentes de fragmentacin de las relaciones: Fragmentacin horizontal.- Divide la relacin asignando a cada dupla de r en uno o ms fragmentos. Fragmentacin vertical.- Divide la relacin descomponiendo el esquema R de la relacin r. Podemos entremezclar los dos tipos de fragmentacin, para obtener una fragmentacin hbrida o mixta.
L. I.
4. MANEJO DE TRANSACCIONES 4.1.-Transacciones. 4.1.1. Estructura de Transacciones. Una transaccin es una coleccin de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. Una base de datos est en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de informacin. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecucin de una transaccin, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aqu es asegurar que la base de datos regresa a un estado consistente al fin de la ejecucin de una transaccin (Ver Figura 5.1) Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.
Figura 5.1. Un modelo de transaccin. Ejemplo 1. Considere la siguiente consulta en SQL para incrementar el 10% del presupuesto del proyecto CAD/CAM de la base de datos de ejemplo. UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM" Esta consulta puede ser especificada, usando la notacin de SQL, como una transaccin otorgndole un nombre: Begin_transaction ACTUALIZA_PRESUPUESTO begin
L. I.
UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM" end. Ejemplo 2. Considere una agencia de reservaciones para lneas areas con las siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP ) CUST( CNAME, ADDR, BAL ) FC( FNO, DATE, CNAME, SPECIAL )
Una versin simplificada de una reservacin tpica puede ser implementada mediante la siguiente transaccin: Begin_transaction Reservacin begin input( flight_no, date, customer_name ); EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date EXEC SQL INSERT INTO FC( FNAME, DATE, CNAME, SPECIAL ) VALUES (flight_no, date, customer_name, null ) output("reservacin terminada"); end. Condiciones de terminacin de una transaccin Una transaccin siempre termina, aun en la presencia de fallas. Si una transaccin termina de manera exitosa se dice que la transaccin hace un commit (se usar el trmino en ingls cuando no exista un trmino en espaol que refleje con brevedad el sentido del trmino en ingls). Si la transaccin se detiene sin terminar su tarea, se dice que la transaccin aborta. Cuando la transaccin es abortada, su ejecucin es detenida y todas sus acciones ejecutadas hasta el momento son deshechas ( undone) regresando a la base de datos al estado antes de su ejecucin. A esta operacin tambin se le conoce como rollback. Ejemplo 3. Considerando de nuevo el Ejemplo 2, veamos el caso cuando no existen asientos disponibles para hacer la reservacin .
Begin_transaction Reservacin begin input( flight_no, date, customer_name ); EXEC SQL SELECT STSOLD, CAP INTO temp1, temp2 FROM FLIGHT WHERE FNO = flight_no AND DATE = date if temp1 = temp2 then output( "no hay asientos libres" )
Academia de Informtica Ramn Edgardo Rincn Fernndez Abort else
L. I.
EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date EXEC SQL INSERT INTO FC( FNAME, DATE, CNAME, SPECIAL ) VALUES (flight_no, date, customer_name, null ) Commit output("reservacin terminada");
end.
endif
Caracterizacin de transacciones Observe que en el ejemplo anterior las transacciones leen y escriben datos. Estas acciones se utilizan como base para caracterizar a las transacciones. Los elementos de datos que lee una transaccin se dice que constituyen el conjunto de lectura (RS). Similarmente, los elementos de datos que una transaccin escribe se les denominan el conjunto de escritura (WS). Note que los conjuntos de lectura y escritura no tienen que ser necesariamente disjuntos. La unin de ambos conjuntos se le conoce como el conjunto base de la transaccin (BS = RS WS). Ejemplo 4. Los conjuntos de lectura y escritura de la transaccin del Ejemplo 3 son: RS[Reservacin] = { FLIGHT.STSOLD, FLIGHT.CAP } WS[Reservacin] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME, FC.SPECIAL } Formalizacin del concepto de transaccin Sea Oij(x) una operacin Oj de la transaccin Ti la cual trabaja sobre alguna entidad x. Oj {read, write} y Oj es una operacin atmica, esto es, se ejecuta como una unidad indivisible. Se denota por OSi = j Oij al conjunto de todas las operaciones de la transaccin Ti. Tambin, se denota por Ni la condicin de terminacin para Ti, donde, Ni {abort, commit}. La transaccin Ti es un orden parcial, Ti = { i, <i }, donde 1. i = OSi {Ni} 2. Para cualesquiera dos operaciones, Oij, Oik OSi, si Oij = R(x) y Oik = W(x) para cualquier elemento de datos x, entonces, Oij <i Oik Oik <i Oij 3. Oij OSi, Oij <i Ni Ejemplo 5. Considere una transaccin simple T que consiste de los siguientes pasos: Read( x ) Read( y ) xx+y
L. I.
Write( x ) Commit La especificacin de su transaccin de acuerdo con la notacin formal que se ha introducido es la siguiente:
= { R(x), R(y), W(x), C } <i = { (R(x), W(x)), (R(y), W(x)), (W(x), C), (R(x), C), (R(y), C) }
Note que la relacin de ordenamiento especifica el orden relativo de todas las operaciones con respecto a la condicin de terminacin. Esto se debe a la tercera condicin de la definicin de transaccin. Tambin note que no se define el ordenamiento entre cualquier par de operaciones, esto es, debido a que se ha definido un orden parcial. Propiedades de las transacciones La discusin en la seccin previa clarifica el concepto de transaccin. Sin embargo, aun no se ha dado ninguna justificacin para afirmar que las transacciones son unidades de procesamiento consistentes y confiables. Las propiedades de una transaccin son las siguientes: 1. Atomicidad. Se refiere al hecho de que una transaccin se trata como una unidad de operacin. Por lo tanto, o todas las acciones de la transaccin se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transaccin se interrumpe por una falla, sus resultados parciales deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se le llama recuperacin de transacciones. La actividad de asegurar la atomicidad en presencia de cadas del sistema se le llama recuperacin de cadas. 2. Consistencia. La consistencia de una transaccin es simplemente su correctitud. En otras palabras, una transaccin es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma caracterstica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos. 3. Aislamiento. Una transaccin en ejecucin no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Ms an, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad). 4. Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transaccin hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transaccin sobrevivirn a fallas del sistema. Esta propiedad motiva el aspecto de recuperacin de bases de datos, el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas.
L. I.
En resumen, las transacciones proporcionan una ejecucin atmica y confiable en presencia de fallas, una ejecucin correcta en presencia de accesos de usuario mltiples y un manejo correcto de rplicas (en el caso de que se soporten). Tipos de Transacciones Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas fundamentales son los mismos para las diferentes clases, los algoritmos y tcnicas que se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones pueden ser agrupadas a lo largo de las siguientes dimensiones: 1. reas de aplicacin. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conoce como transacciones distribuidas. Por otro lado, dado que los resultados de una transaccin que realiza un commit son durables, la nica forma de deshacer los efectos de una transaccin con commit es mediante otra transaccin. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogneos se presentan transacciones heterogneas sobre los datos. 2. Tiempo de duracin. Tomando en cuenta el tiempo que transcurre desde que se inicia una transaccin hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en lnea. Estas se pueden diferencias tambin como transacciones de corta y larga vida. Las transacciones en lnea se caracterizan por tiempos de respuesta muy cortos y por acceder una porcin relativamente pequea de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y acceden grandes porciones de la base de datos. 3. Estructura. Considerando la estructura que puede tener una transaccin se examinan dos aspectos: si una transaccin puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transaccin. Estructura de transacciones Las transacciones planas consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave begin y end. Por ejemplo, Begin_transaction Reservacin ... end. En las transacciones anidadas las operaciones de una transaccin pueden ser as mismo transacciones. Por ejemplo, Begin_transaction Reservacin ... Begin_transaction Vuelo ...
L. I.
end. {Vuelo} ... Begin_transaction Hotel ... end. ... end. Una transaccin anidada dentro de otra transaccin conserva las mismas propiedades que la de sus padres, esto implica, que puede contener as mismo transacciones dentro de ella. Existen restricciones obvias en una transaccin anidada: debe empezar despus que su padre y debe terminar antes que l. Ms an, el commit de una subtransaccin es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas tambin sern abortadas. Las transacciones anidadas proporcionan un nivel ms alto de concurrencia entre transacciones. Ya que una transaccin consiste de varias transacciones, es posible tener ms concurrencia dentro de una sola transaccin. As tambin, es posible recuperarse de fallas de manera independiente de cada subtransaccin. Esto limita el dao a un parte ms pequea de la transaccin, haciendo que costo de la recuperacin sea menor. En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restriccin, entonces, a este tipo de transacciones se les conoce como generales. En contraste, si se restringe o impone que un dato deber ser ledo antes de que pueda ser escrito entonces se tendrn transacciones restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de dos pasos. Finalmente, existe un modelo de accin para transacciones restringidas en donde se aplica an ms la restriccin de que cada par <read, write> tiene que ser ejecutado de manera atmica. Ejemplo 5.6. Los siguientes son algunos ejemplos de los modelos de transaccin mencionados antes. General: T1: { R(x), R(y), W(y), R(z), W(x), W(z), W(w), C} Dos pasos: T2: { R(x), R(y), R(z), W(x), W(y), W(z), W(w), C} Restringida: T3: { R(x), R(y), W(y), R(z), W(x), W(z), R(w), W(w), C} Restringida y de dos pasos: T4: { R(x), R(y), R(z), R(w), W(y), W(x), W(z), W(w), C} Accin: T5: { [R(x), W(x)], [R(y), W(y)], [R(z), W(z)], [R(w), W(w)], C}
nota que cada par de acciones encerrado en [ ] se ejecuta de manera atmica
Aspectos relacionados al procesamiento de transacciones Los siguientes son los aspectos ms importantes relacionados con el procesamiento de transacciones:
L. I.
1. Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas. 2. Consistencia de la base de datos interna. Los algoritmos de control de datos semntico tienen que satisfacer siempre las restricciones de integridad cuando una transaccin pretende hacer un commit. 3. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicacin entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. As tambin, se requieren protocolos para la recuperacin local y para efectuar los compromisos (commit) globales. 4. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecucin de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. Protocolos de control de rplicas. El control de rplicas se refiere a cmo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA). 4.1.2. Ejecucin de Transacciones Centralizadas 4.2. Control de Concurrencia El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera ms simple de lograr este objetivo es ejecutar cada transaccin sola, una despus de otra. Sin embargo, esto puede afectar grandemente el desempeo de un DDBMS dado que el nivel de concurrencia se reduce al mnimo. El nivel de concurrencia, el nmero de transacciones activas, es probablemente el parmetro ms importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia. Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalas. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo trmino, pueden presentarse recuperaciones de informacin inconsistentes. Se hace la suposicin de que el sistema distribuido es completamente confiable y no experimente falla alguna. En el captulo siguiente, se considerar la presencia de fallas para obtener sistemas confiables.
4.3.- Serializacin de Transacciones.
L. I.
Transacciones distribuidas: La transaccin se divide en un nmero de subtransacciones, una por cada lugar en donde los datos accedidos por al transaccin estn almacenados Administrador de Transacciones: Encargado de supervisar la ejecucin de las transacciones y de coordinar las peticiones de la base de datos que realiza la transaccin Scheduler: Maximiza la concurrencia sin permitir la ejecucin concurrente de transacciones que interfieran en otra, y as comprometer la integridad o la consistencia de la base de datos. Teora de la Serializacin Establece que un algoritmo de control de concurrencia es correcto cuando sus resultados son los mismos que si se hubiese procesado secuencialmente. Ejecucin serial Acciones que se ejecutan una despus de otra (no hay acciones en paralelo) Una calendarizacin (schedule), tambin llamado una historia, se define sobre un conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la ejecucin de las operaciones de las transacciones. La calendarizacin puede ser especificada como un orden parcial sobre T. Ejemplo 1. Considere las siguientes tres transacciones: T1: Read( x ) Write( x ) Commit T2: Write( x ) Write( y ) Read( z ) Commit T3: Read( x ) Read( y ) Read( z ) Commit
Una calendarizacin de las acciones de las tres transacciones anteriores puede ser: H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 } Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que acceden el mismo dato de la base de datos x se dice que estn en conflicto si al menos una de ellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read) y write-write. Las dos operaciones en conflicto pueden pertenecer a la misma transaccin o a transacciones diferentes. En el ltimo caso, se dice que las transacciones tienen conflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica que su orden de ejecucin es importante. El orden de dos operaciones de lectura es insignificante.
L. I.
Una calendarizacin completa define el orden de ejecucin de todas las operaciones en su dominio. Formalmente, una calendarizacin completa STc definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = { T, <T } en donde
1. T = i i , para todos los i = 1, 2, ..., n 2. <T i <i , para todos los i = 1, 2, ..., n 3. Para cualesquiera dos operaciones en conflicto Oij y Okl T, Oij <T Okl Okl <T Oij
La primera condicin establece simplemente que el dominio de la calendarizacin es la unin de los dominios de las transacciones individuales. La segunda condicin define la relacin de ordenamiento como un superconjunto de la relacin de ordenamiento de transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro de cada transaccin. La condicin final define el orden de ejecucin entre dos operaciones en conflicto. Ejemplo 2. Considere las tres transacciones del Ejemplo 1, una posible calendarizacin completa est dada por la siguiente grfica dirigida acclica (DAG).
Una calendarizacin se define como un prefijo de una calendarizacin completa. Un prefijo de un orden parcial se define como sigue. Dado un orden parcial P = { , < }, P = { , < }, es un prefijo de P si
1. i 2. ei , e1 < e2, si y solamente si, e1 < e2, y 3. ei , si ej y ej < ei, entonces, ej

Las primeras dos condiciones definen a P como una restriccin de P en el dominio , en donde las relaciones de ordenamiento en P se mantienen por P. La ltima condicin indica que para cualquier elemento de , todos sus predecesores en deben ser incluidos tambin en .
Ejemplo 3. La siguiente calendarizacin es un prefijo de la calendarizacin del Ejemplo 2.
L. I.
Si en una calendarizacin S, las operaciones de varias transacciones no estn entrelazadas, esto es, si las operaciones de una transaccin ocurren de manera consecutiva, entonces se dice que la calendarizacin es serial. Si cada transaccin es consistente (obedece las reglas de integridad), entonces la base de datos se garantiza ser consistente al final de la calendarizacin serial. La historia asociada a este tipo de calendarizacin se le conoce como serial. Ejemplo 4. La siguiente es una historia serial para el Ejemplo 1. HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historia resultante sobre la base de datos es equivalente a alguna historia serial. Basada en la relacin de precedencia introducida por el orden parcial, es posible discutir la equivalencia de diferentes calendarizaciones con respecto a sus efectos sobre la base de datos. Dos calendarizaciones, S1 y S2, definidas sobre el mismo conjunto de transacciones T, se dice que son equivalentes si para cada par de operaciones en conflicto Oij y Okl (i k), cada vez que Oij <1 Okl, entonces, Oij <2 Okl. A esta relacin se le conoce como equivalencia de conflictos puesto que define la equivalencia de dos calendarizaciones en trmino del orden de ejecucin relativo de las operaciones en conflicto en ellas. Una calendarizacin S se dice que es serializable, si y solamente si, es equivalente por conflictos a una calendarizacin serial. Ejemplo 5. Las siguientes calendarizaciones no son equivalentes por conflicto: HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 } Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H2 es serializable: HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } H2 = { W2(x), R1(x), W1(x), C1, R3(x), W2(y), R3(y), R2(z), C2, R3(z), C3 } La funcin primaria de un controlador de concurrencia es generar una calendarizacin serializable para la ejecucin de todas las transacciones. El problema es, entonces, desarrollar algoritmos que garanticen que nicamente se generan calendarizaciones serializables.
L. I.
Seriabilidad en SMBD distribuidos En bases de datos distribuidas es necesario considerar dos tipos de historia para poder generar calendarizaciones serializables: la calendarizacin de la ejecucin de transacciones en un nodo conocido como calendarizacin local y la calendarizacin global de las transacciones en el sistema. Para que las transacciones globales sean serializables se deben satisfacer las siguientes condiciones:

cada historia local debe ser serializable, y dos operaciones en conflicto deben estar en el mismo orden relativo en todas las historias locales donde las operaciones aparecen juntas.
La segunda condicin simplemente asegura que el orden de serializacin sea el mismo en todos los nodos en donde las transacciones en conflicto se ejecutan juntas. Ejemplo 6. Considere las siguientes tres transacciones: T1: Read( x ) xx+5 Write( x ) Commit T2: Read( x ) xx*5 Write( x ) Commit
Las siguientes historias locales son individualmente serializables (de hecho son seriales), pero las dos transacciones no son globalmente serializables. LH1 = {R1(x), W1(x), C1, R2(x), W2(x), C2} LH2 = {R2(x), W2(x), C2, R1(x), W1(x), C1}
L. I.
4.4. Algoritmos de Control

Algoritmos de Control de Concurrencia
Pesimistas Optimistas
Locking Centralized Primary Copy Distributed
Timestamp Ordering Basic
Hybrid
Locking
TimeStamp Ordering
Multiversion Conservative
4.4.1. Basado en Bloques Una transaccin debe reclamar un bloqueo de lectura (compartida) o escritura (exclusiva) sobre los datos, antes de la ejecucin de la correspondiente operacin de lectura o escritura. 4. Protocolos basados en Bloqueo Centralizado: Uno de los sitios designado como sitio primario con Copia Primaria: Si hay mltiples copias, una es designada como primaria y ah debo hacer lock Distribuido: Todos los sitios participan en el lock managment. 5. El bloqueo se realiza en dos fases distintas: Fase de Crecimiento (upgrading) - adquiere bloqueos Fase de Decrecimiento (downgrading) - libera bloqueos 6. Centralizado Hay un nico Lock Manager para la totalidad del sistema distribuido que puede adquirir o liberar bloqueos Comunicacin entre el TM del sitio que inici la transaccin (coordinador), el Lock Manager del sitio central y los procesadores de datos de los otros sitios participantes. Problemas de cuello de botella 4. Con Copia Primaria Tratar de manejar las desventajas Cada Lock Manager local es responsable de un conjunto de datos, se elige una copia como copia primaria; el resto se las llaman copias esclavas. Hay que indicar quien es la copia primaria antes de lock
L. I.
Obtiene bloqueo Libera bloqueo
Comienz ozo
Punto de Bloqueo
Fin
Duracin de la transacci n
1. Centralizado Hay un nico Lock Manager para la totalidad del sistema distribuido que puede adquirir o liberar bloqueos Comunicacin entre el TM del sitio que inici la transaccin (coordinador), el Lock Manager del sitio central y los procesadores de datos de los otros sitios participantes. Problemas de cuello de botella 2. Con Copia Primaria Tratar de manejar las desventajas Cada Lock Manager local es responsable de un conjunto de datos, se elige una copia como copia primaria; el resto se las llaman copias esclavas. Hay que indicar quien es la copia primaria antes de lock 3. Distribuido Existe un Lock Manager en cada sitio. Cada uno es responsable de la gestin de bloqueos de los datos que hay en ese nodo. Implementa el protocolo de control de concurrencia ROWA (Read One Write All) Se puede utilizar cualquier copia de un dato para ser leido, pero para escribir se deben ser bloqueadas todas las copias. 4.4.2. Etiquetas de Tiempo 1. A diferencia de los basados en bloqueo, no pretenden mantener la seriabilidad por exclusion mutua. Seleccionan un orden de serializacin a priori y ejecutan las transacciones de acuerdo a ellas. 2. Cuando una transaccin Ti se inicia, el TM le asigna un timeStamp unico ts(Ti). 3. Propiedades de los TimeStamp: unicidadad: identifica unvocamente a cada transaccin monoticidad: dos timeStamp generadas por el mismo TM deben ser monoticamente crecientes (ordenado)
L. I.
Regla TO: Dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y solo si, ts(Ti) < ts(Tk). En este caso Ti se dice ser una transaccin ms vieja y Tk se dice ser una transaccin ms joven. El algoritmo bsico trata de ejecutar una operacin tan pronto como se recibe una operacin. La ejecucin de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones (considerar sitios inactivos que producen ts bajos.) Cuando un sitio B recibe un mensaje de un sitio A, B adelanta el reloj local a: Max(ts del mensaje, reloj B)
4.4.3. Pruebas de Validacin Optimista 1. Para asegurar la atomicidad de la transaccin todas las actualizaciones de los datos son realizadas en copias locales y slo son propagadas a la base de datos cuando no se hayan detectado conflictos 2. Si hay conflicto la transaccin es rechazada y debe reiniciarse 3. Las transacciones se ejecutan en 3 pasos: Fase de lectura: representa el cuerpo de la transaccin a ser cometida (no hay escrituras en la base de datos durante esta fase). Fase de validacin: los resultados (actualizaciones) de la transaccin son examinados para detectar conflictos. Fase de escritura: si la transaccin es validada, entonces las actualizaciones se propagan desde la copia local a la base de datos. Si durante la fase de validacin se encontraron conflictos que pueden resultar en una prdida de integridad, entonces la transaccin es deshechada y reiniciada. 4.5. Seguridad Un sistema de manejo de bases de datos confiable es aquel que puede continua procesando las solicitudes de usuario an cuando el sistema sobre el que opera no es confiable. En otras palabras, aun cuando los componentes de un sistema distribuido fallen, un DDMBS confiable debe seguir ejecutando las solicitudes de usuario sin violar la consistencia de la base de datos. La confiabilidad se puede ver como una medida con la cual un sistema conforma su comportamiento a alguna especificacin. Tambin se puede interpretar como la probabilidad de que un sistema no haya experimentado ninguna falla dentro de un periodo de tiempo dado. La confiabilidad se utiliza tpicamente como un criterio para describir sistemas que no pueden ser reparados o donde la operacin continua del sistema es crtica.
L. I.
Disponibilidad, por otro lado, es la fraccin del tiempo que un sistema satisface su especificacin. En otras palabras, la probabilidad de que el sistema sea operacional en un instante dado de tiempo El comportamiento del sistema al responder a cualquier estmulo del medio ambiente necesita establecerse por medio de una especificacin, la cual indica el comportamiento vlido de cada estado del sistema. Su especificacin es no slo necesaria para un buen diseo sino tambin es esencial para definir los siguientes conceptos de confiabilidad. Cualquier desviacin de un sistema del comportamiento descrito en su especificacin se considera como una falla. Cada falla necesita ser rastreada hasta su causa. En un sistema confiable los cambios van de estados vlidos a estados vlidos. Sin embargo, en un sistema no confiable, es posible que el sistema caiga en un estado interno el cual no obedece a su especificacin; a este tipo de estados se les conoce como estados errneos. Transiciones a partir de este estado pueden causar una falla. La parte del estado interno que es incorrecta se le conoce como error del sistema. Cualquier error en los estados internos de las componentes del sistema se le conoce como una falta en el sistema. As, una falta causa un error lo que puede inducir una falla del sistema. Tipos de fallas en SMBDD Disear un sistema confiable que se pueda recuperar de fallas requiere identificar los tipos de fallas con las cuales el sistema tiene que tratar. As, los tipos de fallas que pueden ocurrir en un SMBD distribuido son: 1. Fallas de transacciones. Las fallas en transacciones se pueden deber a un error debido a datos de entrada incorrectos as como a la deteccin de un interbloqueo. La forma usual de enfrentar las fallas en transacciones es abortarlas. Experimentalmente, se ha determinado que el 3% de las transacciones abortan de manera anormal. 2. Fallas del sistema. En un sistema distribuido se pueden presentar fallas en el procesador, la memoria principal o la fuente de energa de un nodo. En este tipo de fallas se asume que el contenido de la memoria principal se pierde, pero el contenido del almacenamiento secundario es seguro. Tpicamente, se hace diferencia entre las fallas parciales y fallas totales del nodo. Una falla total se presenta en todos los nodos del sistema distribuido. Una falla parcial se presenta solo en algunos nodos del sistema. 3. Fallas del medio de almacenamiento. Se refieren a las fallas que se pueden presentar en los dispositivos de almacenamiento secundario que almacenan las bases de datos. Esas fallas se pueden presentar por errores del sistema operativo, por errores del controlador del disco, o del disco mismo. 4. Fallas de comunicacin. Las fallas de comunicacin en un sistema distribuido son frecuentes. Estas se pueden manifestar como prdida de mensajes lo que lleva en un caso extremo a dividir la red en varias subredes separadas.
L. I.
Protocolos locales En esta seccin se discutirn las funciones realizadas por el administrador de recuperacin local (LRM) el cual debe existir en cada nodo. Esas funciones mantienen las propiedades de atomicidad y durabilidad de las transacciones locales. Ellas estn relacionadas a la ejecucin de los comandos que son pasados al LRM, las cuales son begin_transaction, read, write, commit y abort. Informacin de recuperacin En esta seccin se asumir que ocurren nicamente fallas del sistema. Ms adelante se considerar el caso de los otros tipos de fallas. Cuando una falla del sistema ocurre, el contenido de la base de datos voltil se pierde. Por lo tanto, el DBMS tiene que mantener cierta informacin acerca de su estado en el momento de la falla con el fin de ser capaz de llevar a la base de datos al estado en el que se encontraba antes de la falla. A esta informacin se le denomina informacin de recuperacin. La informacin de recuperacin que el sistema mantiene depende del mtodo con el que se realizan las actualizaciones. Existen dos estrategias para efectuarlas: en el lugar ( in place) y fuera de lugar (out-of-place). En el primer caso, cada actualizacin se hace directamente en los valores almacenados en las pginas de los buffers de la base de datos. En la segunda alternativa, al crear un nuevo valor para un dato, ste se almacena en forma separada del valor anterior. De esta manera, se mantiene los valores nuevo y anterior. 4.6.2. Protocolos UNDO / REDO Recuperacin in-place Dado que la actualizacin in-place hacen que los valores anteriores se pierdan, es necesario mantener suficiente informacin de los cambios de estado en la base de datos. Esta informacin se mantiene, por lo general, en el registro de la base de datos (database log). As cada actualizacin, no solo cambia la base de datos, sino es tambin guardada en el registro de la base de datos (Figura 7.4).
Figura 7.4. Ejecucin de una operacin de actualizacin.
L. I.
El registro de la base de datos contiene informacin que es utilizada por el proceso de recuperacin para restablecer la base de datos a un estado consistente. Esta informacin puede incluir entre otras cosas:

el identificador de la transaccin, el tipo de operacin realizada, los datos accedidos por la transaccin para realizar la accin, el valor anterior del dato (imagen anterior), y el valor nuevo del dato (imagen nueva).
Considere el escenario mostrado en la Figura 7.5. El DBMS inicia la ejecucin en el tiempo 0 y en el tiempo t se presenta una falla del sistema. Durante el periodo [0,t] ocurren dos transacciones, T1 y T2. T1 ha sido concluida (ha realizado su commit) pero T2 no pudo ser concluida. La propiedad de durabilidad requiere que los efectos de T1 sean reflejados en la base de datos estable. De forma similar, la propiedad de atomicidad requiere que la base de datos estable no contenga alguno de los efectos de T2.
Figura 7.5. Ejemplo de una falla del sistema. A pesar que T1 haya sido terminada, puede suceder que el buffer correspondiente a la pgina de la base de datos modificada no haya sido escrito a la base de datos estable. As, para este caso la recuperacin tiene que volver a realizar los cambios hechos por T1. A esta operacin se le conoce como REDO y se presenta en la Figura 7.6. La operacin de REDO utiliza la informacin del registro de la base de datos y realiza de nuevo las acciones que pudieron haber sido realizadas antes de la falla. La operacin REDO genera una nueva imagen.
Figura 7.6. Operacin REDO.
L. I.
Por otra parte, es posible que el administrador del buffer haya realizado la escritura en la base de datos estable de algunas de las pginas de la base de datos voltil correspondientes a la transaccin T2. As, la informacin de recuperacin debe incluir datos suficientes para permitir deshacer ciertas actualizaciones en el nuevo estado de la base de datos y regrasarla al estado anterior. A esta operacin se le conoce como UNDO y se muestra en la Figura 7.7. La operacin UNDO restablece un dato a su imagen anterior utilizando la informacin del registro de la base de datos.
Figura 7.7. Operacin UNDO. De forma similar a la base de datos voltil, el registro de la base de datos se mantiene en memoria principal (llamada los buffers de registro ) y se escribe al almacenamiento estable (llamado registro estable). Las pginas de registro se pueden escribir en el registro estable de dos formas: sncrona o asncrona. En forma sncrona, tambin llamada un registro forzado, la adicin de cada dato en el registro requiere que la pgina del registro correspondiente se mueva al almacenamiento estable. De manera asncrona, las pginas del registro se mueven en forma peridica o cuando los buffers se llenan. Independientemente de que la escritura del registro sea sncrona o asncrona, se debe observar un protocolo importante para el mantenimiento del registro de la base de datos. Considere el caso donde las actualizaciones a la base de datos son escritas en el almacenamiento estable antes de que el registro sea modificado en el registro estable para reflejar la actualizacin. Si una falla ocurre antes de que el registro sea escrito, la base de datos permanecer en forma actualizada, pero el registro no indicar la actualizacin lo que har imposible recuperar la base de datos a un estado consistente antes de la actualizacin. Por lo tanto, el registro estable siempre debe ser actualizado antes de la actualizacin de la base de datos. A este protocolo se le conoce como registro antes de la escritura (writeahead logging) y se puede especificar de la manera siguiente: 1. Antes de que la base de datos estable sea actualizada, las imgenes anteriores deben ser almacenadas en el registro estable. Esto facilita la realizacin de un UNDO. 2. Cuando la transaccin realiza un commit, las imgenes nuevas tienen que ser almacenadas en el registro estable antes de la actualizacin de la base de datos estable. Esto facilita la realizacin de una operacin REDO.
L. I.
La interfaz completa del registro de la base de datos voltil y estable se presenta en la Figura 7.8.
Figura 7.8. Interfaz entre el registro de la base de datos voltil y estable. Recuperacin out-of-place Las tcnicas de recuperacin ms comunes son de tipo in-place. Por lo tanto, aqu se presenta solo una breve descripcin de las tcnicas out-ofplace. 1. Shadowing. Cuando ocurre una actualizacin, no se cambia la pgina anterior, sino se crea una pgina sombra con el nuevo valor y se escribe en la base de datos estable. Se actualizan los caminos de acceso de manera que los accesos posteriores se hacen a la nueva pgina sombra. La pgina anterior se retiene para propsitos de recuperacin, para realizar una operacin UNDO. 2. Archivos diferenciales. Para cada archivo F se mantiene una parte de solo lectura (FR), un archivo diferencial que consiste de la parte de inserciones DF+ y la parte de supresiones DF-. As, el archivo completo consistir de la unin de la parte de lectura ms la parte de inserciones y a todo esto se le eliminan las supresiones realizadas.
F = (FR DF+) DFTodas las actualizaciones se tratan como la supresin de un valor anterior y la insercin de un nuevo valor. Peridicamente, el archivo diferencial tiene que ser mezclado con el archivo base de solo lectura. 4.6.3.-Verificacin La operacin de recuperacin requiere recorrer todo el registro de la base de datos. As, el buscar todas las transacciones a las cuales es necesario aplicarles un UNDO o REDO puede tomar una cantidad de trabajo considerable. Para reducir este trabajo se pueden poner puntos de verificacin (checkpoints) en el registro de la base de datos para indicar que en esos puntos la base de datos est actualizada y consistente. En este caso, un REDO tiene que iniciar desde un punto de verificacin y un UNDO
L. I.
tiene que regresar al punto de verificacin ms inmediato anterior. La colocacin de puntos de verificacin se realiza con las siguientes acciones: 1. Se escribe un "begin_checkpoint" en el registro de la base de datos. 2. Se recolectan todos los datos verificados en la base de datos estable. 3. Se escribe un "fin_de_checkpoint" en el registro de la base de datos.
4.6.4 Protocolos 2PC

Como con los protocolos de recuperacin local, las versiones distribuidas ayudan a mantener la atomicidad y durabilidad de las transacciones. La ejecucin de los comandos begin_transaction, read y write no provoca ningn cambio significativo. Sin embargo, la ejecucin de las operaciones commit, abort y recover requieren del desarrollo de un protocolo especial para cada una de ellas en el cual participan todos los nodos de la red que intervienen en una transaccin. De manera breve, a continuacin se presentan algunos problemas que aparecen en sistemas distribuidos y que no se presentan en sistemas centralizados. Cmo ejecutar un comando commit para transacciones distribuidas? Cmo asegurar la atomicidad y durabilidad de las transacciones distribuidas? Si ocurre una falla, cmo pueden, los nodos que permanecen funcionando, seguir operando normalmente? Idealmente, la ocurrencia de la falla en un nodo no debe forzar a los otros nodos a tener que esperar a que se repare la falla en el nodo para terminar una transaccin. A esta propiedad se le conoce como no-bloqueante. De manera similar, cuando ocurre una falla cmo terminar una transaccin que se estaba ejecutando al momento de la falla? Idealmente un nodo con falla debera poder terminar una transaccin sin tener que consultar a los otros nodos. Esta es una propiedad de independencia del nodo con falla con respecto a los nodos sin falla. Una recuperacin independiente supone que existe una estrategia no-bloqueante en el manejo de fallas. Para facilitar la descripcin de los protocolos de confiabilidad distribuida se supondr que en el nodo que se origina una transaccin hay un proceso, llamado el coordinador, que ejecuta las operaciones de la transaccin. El coordinador se comunica con procesos participantes en los otros nodos los cuales lo ayudan en las operaciones de la transaccin. Compromisos de dos fases El compromiso de dos fases (two-phase commit) es un protocolo muy simple y elegante que asegura la atomicidad de las transacciones distribuidas. Extiende los efectos de una operacin local de commit a transacciones distribuidas poniendo de acuerdo a todos los nodos involucrados en la ejecucin de una transaccin antes de que los cambios hechas por la transaccin sean permanentes.
L. I.
Las fases del protocolo son las siguientes:

Fase 1: el coordinador hace que todos los participantes estn listos para escribir los resultados en la base de datos. Fase 2: Todos escriben los resultados en la base de datos.
La terminacin de una transaccin se hace mediante la regla del compromiso global: 1. El coordinador aborta una transaccin si y solamente si al menos un participante vota por que se aborte. 2. El coordinador hace un commit de la transaccin si y solo si todos los participantes votan por que se haga el commit. La operacin del compromiso de dos fases entre un coordinador y un participante en ausencia de fallas se presenta en la Figura 7.9, en donde los crculos indican los estados y las lneas entrecortadas indican mensajes entre el coordinador y los participantes. Las etiquetas en las lneas entrecortadas especifican la naturaleza del mensaje. En la Figura 7.10 se presentan las dos fases de comunicacin para realizar un commit en sistemas distribuidos. El esquema presentado en la figura se conoce como centralizado ya que la comunicacin es solo entre el coordinador y los participantes; los participantes no se comunican entre ellos.
Figura 7.9. Acciones del compromiso de dos fases. Otra alternativa es una comunicacin lineal, en donde los participantes se pueden comunicar unos con otros. Existe un ordenamiento entre los nodos
L. I.
del sistema. La estructura se presenta en la Figura 7.11. Un participante, P, recibe un mensaje vote-abort o vote-commit de otro participante, Q. Si P no est listo para hacer un commit, enva un vote-abort al siguiente participante, R, y la transaccin se aborta en este punto. Si P el participante est de acuerdo en hacer un commit, enva un vote-commit a R y entra al estado de LISTO. Este proceso contina hasta el ltimo participante poniendo fin a la primera fase. En la segunda fase, si el ltimo participante est de acuerdo en hacer un commit enva un global-commit al participante anterior. En caso contrario, enva un global-abort. As en la segunda fase, P recibe un mensaje de R informndole si se hace un global-commit o un global-abort. Este mensaje se propaga a Q y as hasta alcanzar al coordinador.
Figura 7.10. Estructura centralizada de comunicaciones para el compromiso de dos fases.
Figura 7.11. Estructura lineal de comunicaciones para el compromiso de dos fases. Otra estructura de comunicacin usual para implementar los compromisos de dos fases involucra la comunicacin entre todos los participantes durante la primera fase del protocolo de manera que todos ellos alcanzan su punto de terminacin en forma independiente. Esta versin, llamada la estructura distribuida, no requiere la segunda fase. En la Figura 7.12 se presenta la estructura distribuida en la cual el coordinador enva el mensaje de preparacin a todos los participantes. Cada participante, entonces, enva su decisin a todos los otros participantes y al coordinador indicndola como un vote-commit o vote-abort. Cada participante espera los mensajes de todos los otros participantes y toma su decisin de acuerdo a la regla de compromiso global.
L. I.
Figura 7.12. Estructura distribuida de comunicaciones para el compromiso de dos fases. Independientemente de la forma en que se implemente el compromiso de dos fases, ste puede ser modelado por medio de un diagrama de transicin de estados. En la Figura 7.13 se presentan los diagramas de transicin para el coordinador y los participantes.
Figura 7.13. Diagrama de transicin de estados para el compromiso de dos fases del coordinador y de un participante. Protocolos de terminacin Las fallas de nodo se pueden manifestar tanto en el coordinador como en los participantes.
Timeouts del coordinador
1. Timeout en el estado WAIT. El coordinador est esperando por las decisiones locales de los participantes. El coordinador no puede de manera unilateral realizar un commit. Sin embargo, l puede decidir abortar globalmente la transaccin. En este caso, escribe un comando abort en el registro de la base de datos y enva un mensaje global-abort a todos los participantes. 2. Timeout en los estados COMMIT o ABORT . En este caso el coordinador no esta seguro que los procedimientos de commit o abort se han terminado por los administradores de recuperacin local en todos los
L. I.
nodos participantes. As, el coordinador enva mensajes globalcommit o global-abort de manera repetida a todos los nodos que no han respondido y espera por su reconocimiento.
Timeouts de los participantes
1. Timeout en el estado INITIAL. En este estado el participante est esperando por un mensaje prepare. El coordinador pudo haber fallado en el estado INITIAL por lo que el participante puede abortar de manera unilateral la transaccin. Si el mensaje prepare llega en un tiempo posterior al participante, esto se puede manejar de dos formas. Puede responder con un vote-abort o simplemente ignorar el mensaje y dejar que ocurra el timeout en el lado del coordinador. 2. Timeout en el estado READY. En este estado el participante ha votado por realizar un commit pero desconoce la decisin global del coordinador. No se puede de manera unilateral ni hacer un commit ni hacer un abort. As permanecer bloqueado hasta que pueda conocer de alguien, el coordinador u otro participante, cual fue la decisin final sobre la transaccin. Protocolos de recuperacin En la parte anterior se discuti como implementar los compromisos de dos fases cuando se presentan fallas en nodos pero desde la perspectiva de los nodos que se mantienen trabajando. En esta parte, se examinar el otro punto de vista, esto es, como un coordinador o participante se pueden recuperar cuando sus nodos fallas y tienen que reiniciar su trabajo.
Fallas del coordinador
1. El coordinador falla en el estado INITIAL . Esto es antes de que el coordinador ha iniciado el procedimiento para hacer un commit. Por lo tanto, cuando el coordinador reinicia tiene que empezar el proceso para hacer el commit. 2. El coordinador falla en el estado de WAIT . En este caso el coordinador ha enviado el comando prepare y despus falla. Para recuperarse de una falla, tendr que reiniciar el proceso de commit para la transaccin desde el envo nuevamente del mensaje prepare. 3. El coordinador falla en los estados COMMIT o ABORT . En este caso el coordinador ha tomado una decisin y la ha informado a los participantes. As, si todos los reconocimientos se han recibido cuando se trata de recuperar, entonces no se hace nada. De otra manera, se invoca al protocolo de terminacin. Fallas de los participantes 1. Un participante falla en el estado INICIAL . En este caso se aborta la transaccin de manera unilateral cuando se trata de recuperar. Lo anterior es aceptable ya que el coordinador de la transaccin debe estar en el estado INITIAL o WAIT. Si est en el primero, enviar un mensaje prepare y pasar al estado de WAIT en donde no recibir respuesta del participante que ha fallado y eventualmente abortar globalmente la transaccin.
L. I.
2. Un participante falla en el estado READY. En este caso el participante ha informado su decisin al coordinador. Cuando se recupere, el participante en el nodo fallido puede tratar esto como un timeout en el estado de READY y manejar la transaccin incompleta sobre su protocolo de terminacin. 3. Un participante falla en el estado ABORT o COMMIT . Esos estados representan las condiciones de terminacin, de manera que, cuando se recupere, el participante no necesita tomar acciones especiales.
L. I.
Anexo A.Arquitecturas.
Dentro de una organizacin, los sistemas de informacin se apoyan en una infraestructura de informacin. Esta infraestructura ha estado ligada en el pasado al propio modelo de la organizacin. Tradicionalmente, las organizaciones han tenido una estructura centralizada y jerrquica, estructurada en unos departamentos con cometidos concretos. Las relaciones entre los distintos departamentos, dentro de la jerarqua, estaban perfectamente definidas. El modelo actual de organizacin, por el contrario, se articula segn unidades ms operativas y autnomas, que funcionan por cumplimiento de objetivos. Existen menos niveles jerrquicos y las relaciones que existen entre las distintas unidades son ms directas y pueden variar con el tiempo. Pero, por otra parte se tiende a centralizar los datos corporativos que son importantes desde el punto de vista estratgico. Debido a esto, la infraestructura informtica se ha dividido histricamente en dos tipos de arquitecturas, en extremos opuestos: Arquitectura centralizada, en la que existe un servidor central, donde residen todos los datos y tratamientos de los mismos. Arquitectura distribuida, donde la inteligencia est distribuida en diferentes mquinas y los datos pueden estar centralizados en diferentes servidores.
La Arquitectura Centralizada nace en torno a una concepcin tradicional de la organizacin, con estructura centralizada y jerrquica, dividida en departamentos. Cada departamento tiene actividades muy concretas. Las relaciones que pueda establecer con otros departamentos estn muy definidas y limitadas y suelen realizarse a travs de la jerarqua. El sistema informtico es nico y est relacionado con el departamento administrativo financiero para la realizacin de nminas, contabilidad, etc. La arquitectura est centralizada en un servidor central al que slo tienen acceso los usuarios del departamento correspondiente. Caractersticas funcionales: El ordenador central es el nico ordenador de la organizacin. El, contiene todos los datos y es el responsable de la consolidacin de la informacin. Desde el ordenador central se controla el acceso a mltiples terminales conectados a travs de productos integrados en la arquitectura de red del suministrador. Los terminales funcionan como "esclavos" del ordenador central. Cada usuario tiene un nmero asignado, y derechos y prioridades de ejecucin en la mquina, de sus programas o peticiones.
Arquitectura Centralizada.
L. I.
Caractersticas fsicas: nico ordenador corporativo dimensionado para soportar todos los procesos de la organizacin, todos los datos y las posibles comunicaciones con las delegaciones. Una gran base de datos donde residen todos los datos del organismo. Impresoras y terminales (u ordenadores personales con emulacin de Terminal) como puestos de trabajo conectados en grupos (clusters), al ordenador central. Caractersticas lgicas: Ejecucin de todos los procesos en el ordenador corporativo. Si la empresa est dispersa geogrficamente y dispone de comunicaciones, todos los puestos de trabajo estn conectados al ordenador formando una "estrella". Principales ventajas: Alto rendimiento transaccional. Alta disponibilidad. Entorno probado y personal experimentado. Control total del ordenador, al ser ste nico y residente en un nico Centro de Proceso de Datos. Concentracin de todo el personal de explotacin y administracin del sistema en un nico Centro de Proceso de Datos. Principales Inconvenientes: Alto precio del ordenador, al requerirse mucha potencia de tratamiento para dar servicio a todos los usuarios que estn conectados y gran espacio en disco para albergar todos los datos del organismo. Alta dependencia de las comunicaciones, si existen. En caso de cada de una lnea, todos los puestos de trabajo dependientes de dicha lnea quedan inoperantes. Interfaces de usuario de caracteres (no grficos) y, por lo tanto, poco amigables. Arquitecturas propietarias.
Arquitectura Distribuida.
Surge con los nuevos modelos organizativos, en los que la empresa se divide en unidades ms o menos autnomas que establecen relaciones ms definidas y directas entre s. Aparecen entonces entornos informticos departamentales adecuados a las necesidades de cada departamento en concreto. Un sistema distribuido es un caso especial de una red de computadoras. Interconecta los lugares que tienen recursos computacionales, para capturar y almacenar datos, procesarlos y enviar datos e informacin a
L. I.
otros sistemas, tales como un sistema central. El rango de recursos computacionales vara. Algunos lugares utilizan terminales, otros microcomputadoras, otros incluso, grandes sistemas de cmputo. No existe el requisito de que todo el equipo sea del mismo fabricante. De hecho se espera que estn implicadas varias marcas de hardware. Esto permite al usuario tener el tipo ms adecuado a sus necesidades. Todos los lugares (reciben el nombre de nodos en el procesamiento distribuido) tienen la capacidad de capturar y procesar datos en donde ocurran los eventos. En otras palabras, si un lugar especfico usa una microcomputadora, los usuarios capturan y procesan datos en su minicomputadora. Reciben respuestas rpidas a sus consultas, almacenan datos en el sistema y preparan reportes cuando se necesitan. Sin embargo, tambin pueden transmitir datos o reportes desde su sistema a otro enlazado en la red, compuesta por todos los sistemas interconectados. Un sistema de procesamiento distribuido incluye: Mltiples componentes de procesamiento de propsito general. Pueden asignarse tareas especficas a los sistemas de procesamiento sobre una base dinmica. Los sistemas no necesitan ser de una misma marca o tamao. Sistema operativo de alto nivel. Los nodos de procesamiento individual tienen su propio sistema operativo, el cual est diseado para la computadora especfica. Pero tambin hay un sistema operativo que los enlaza e integra al control de los componentes distribuidos. Distribucin fsica de los componentes.- Las computadoras y otras unidades de procesamiento estn separadas fsicamente. Interactan entre s por medio de una red de comunicaciones. Transparencia del sistema.- Los usuarios no conocen la ubicacin de un componente en el sistema distribuido o nada de su fabricante, modelo, sistema operativo local, velocidad o tamao. Todos los servicios se piden por su nombre. El sistema operativo distribuido lleva a cabo todas las actividades que implican la ubicacin fsica y atributos de procesamiento para satisfacer la demanda del usuario. Papel dual de los componentes.- Los componentes individuales de procesamiento pueden operar independientemente del marco de trabajo del sistema distribuido Estn fuera de la clasificacin como sistemas distribuidos, los siguientes: Una computadora multifuncional grande, que distribuye el procesamiento entre varios procesadores de entrada/salida y perifricos. Un procesador primario, que controla las comunicaciones del sistema al cual fue aadido. Un conjunto de terminales remotas, que recogen y transmiten datos a un sistema anfitrin. La interconexin de varias computadoras anfitrionas, que transmiten mensajes y llevan a cabo funciones y tareas exclusivas.
L. I.
Una computadora que puede ser particionada, es decir capaz de operar diversas sesiones de procesamiento en forma simultnea, utilizando un sistema operativo especial. La diferencia de una red de computadoras y un sistema distribuido es que en una red de computadoras el usuario se conecta explcitamente con otra mquina. Explcitamente lanza tareas remotas, mueve archivos, etc. La diferencia radica en quin invoca las funciones del sistema. Sntomas de Distribucin: Multiproceso (concurrencia): El hardware permite el progreso simultneo de varias actividades (varias CPUs, con memoria local, etc.). Interconexin: Permite la comunicacin entre las actividades. Relacin: Uso compartido de recursos, informacin, etc. Fallo independiente: Permite buscar soluciones resistentes en caso de fallo (ojo: las comunicaciones tambin pueden fallar). Propiedades: Nombrado global: el mismo nombre es vlido en todo el sistema. Acceso global: los mismos mtodos actan en objetos, en cualquier parte del sistema. Seguridad global: autenticacin y acceso uniformes en todo el sistema. Disponibilidad global: funcionamiento correcto en presencia de fallos parciales. Gestin global: posibilidad de gestin centralizada del sistema. Caractersticas funcionales: Cada usuario trabaja con su terminal local inteligente, con lo que obtiene mejores tiempos de respuesta. Los recursos necesarios que no estn disponibles sobre el terminal local (ordenador personal o estacin de trabajo), pueden tomarse del ordenador central a travs de la red de telecomunicaciones. Caractersticas fsicas: Sistemas informticos distribuidos en los que los ordenadores, a travs de la organizacin, estn conectados por medio de una red de telecomunicaciones. Cada ordenador sobre la red tiene capacidad de tratamiento autnomo que permite servir a las necesidades de los usuarios locales. Tambin proporciona acceso a otros elementos de la red o a servidores centrales. Toma importancia la red de comunicacin de datos. Caractersticas lgicas: Cada tarea individual puede ser analizada para determinar si puede distribuirse o no. En general, las tareas ms complejas o de carcter
L. I.
estratgico para la organizacin se mantienen en el ordenador central. Las tareas de complejidad media o especfica para un determinado grupo de usuarios, se distribuyen entre las mquinas locales de ese grupo. La plataforma fsica seleccionada puede ajustarse a las necesidades del grupo de usuarios, con lo que surgen los ordenadores especializados para determinados tipos de tareas. Ventajas: Funcionamiento autnomo de los sistemas locales, lo que origina un buen tiempo de respuesta. Los sistemas de informacin llegan a todos los departamentos de la empresa. Abre posibilidades de trabajo mucho ms flexibles y potentes. Inconvenientes: Requiere un intenso flujo de informaciones (muchas veces no tiles, como pantallas y datos incorrectos) dentro de la red, lo que puede elevar los costos de comunicaciones. Supone una mayor complejidad. Si los sistemas no estn integrados, pueden producirse problemas de inconsistencia de datos.

Antología Bases de Datos Distribuidas

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Antología Bases de Datos Distribuidas

Загружено:

Авторское право:

Доступные форматы

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

proporcionen facilidades limitadas procesamiento de las transacciones.

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Figura 2.1. Enfoque de la distribucin.

Academia de Informtica Ramn Edgardo Rincn Fernndez

Figura 2.2. Estrategia descendente.

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Figura 2.4. El problema de fragmentacin de relaciones.

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Figura 2.5. Organizacin en capas de los niveles de transparencia.

Academia de Informtica Ramn Edgardo Rincn Fernndez

STO J1 J2 J3 J4 J5 Instrumentaci n 150000 Monterrey Mxico Puebla Mxico Guadalajara

Desarrollo de 135000 bases de datos

J2: proyectos con presupuesto mayor que o igual a $200,000

Mantenimiento 310000 CAD/CAM 500000

Academia de Informtica Ramn Edgardo Rincn Fernndez

J2: informacin acerca de los nombres y ubicaciones de proyectos

Figura 2.6. El grado de fragmentacin.

Manejo de Directorios Control Concurrencia Confiabilidad Realidad

de Moderado Muy alto Aplicacin posible

Tabla 2.1. Comparacin de las estrategias de replicacin de fragmentos.

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Unidad 3.- Procesamiento de Consultas Distribuidas

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

3.2 Estrategias de procesamiento de consultas distribuidas.

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Academia de Informtica Ramn Edgardo Rincn Fernndez

Primero calculamos el producto cartesiano R S y tendremos:

Tras la seleccin R R.C=S.CS tendremos:

Academia de Informtica Ramn Edgardo Rincn Fernndez

C: NOMBREP, APELLIDO, NOMBRED (EMPLEADO ND=NMEROD DEPARTAMENTO)

C: NOMBRED, NOMBREP, APELLIDO (DEPARTAMENTO NSSGET=NSS EMPLEADO)

Academia de Informtica Ramn Edgardo Rincn Fernndez

2. Reunir el archivo con la relacin EMPLEADO en el sitio 1 y transferir los