unidad 4 bdd

Unidad 4

Proceso de transacciones en base de datos distribuidas

Alumno

Juan José Cisneros Martínez

Asignatura

Base de datos distribuidos

Grado y grupo

6 E

Ing. sistemas computacionales

Docente: Arturo Iván Grajales Vázquez

29 de mayo de 2012

Base datos distribuidos

Índice

Introducción 3

4.1 Transacciones 4

4.1.1Estructura de transacciones 6

4.1.2Ejecucuion de transacciones centralizadas 7

4.1.4Ejecucion de transacciones distribuidas 7

4.2Algoritmos de control de concurrencias 8

4.2.1Basados en bloqueo 9

4.2.2Pruebas de validación optimistas 10

4.3Recuperacion 11

4.4Seguridad e integridad 11

Conclusión 13

Bibliografía 14

Proceso de transacciones Página 2


Introducción

La gran cantidad de avances e innovaciones tecnológicas que se produjeron en los últimos años tuvieron como resultado un cambio en la forma de observar a los sistemas de información, en general a las aplicaciones computacionales.

Existen avances tecnológicos que se realizan de forma constante en dispositivos de almacenamiento, circuitos, programas y metodologías. Dichos avances van de la mano junto con la demanda de los usuarios y programas para la explotación de dichos dispositivos mejorados.

Un área en la cual las soluciones están ocupando tecnología con nuevas arquitecturas, es en la de los

Sistemas distribuidos de información. Estos sistemas se refieren al manejo de datos almacenados en muchos

Sitios ligados a través de una red de comunicaciones. Un caso particular de estos sistemas distribuidos es lo que se conoce como base de datos distribuidas.

En los sistemas de base de datos distribuidos se persigue la integración de sistemas de base de datos diversos, no necesariamente homogéneos para dar a los usuarios una visión global de la información disponible. Este proceso de integración no implica la centralización de la información, más bien, con la ayuda de la tecnología de redes de computadoras la información se mantiene distribuida y los sistemas de bases de datos distribuidos permiten el acceso a ella como si estuviera localizada en un solo lugar. La distribución de la información permite tener accesos rápidos a la misma, tener copias de la información para accesos más rápidos y para tener respaldo en caso de fallas. Un sistema de base de datos distribuida es el resultado de la integración de una base de datos distribuida con un sistema para su manejo.

Existen diversos factores relacionados a la construcción de base de datos distribuidos que no se presentan en base de datos centralizadas.



Transacciones

Los sistemas distribuidos son muy confiables debido a la posibilidad de brindar redundancia y autonomía de recursos en diferentes nodos, esto posibilita detectar y localizar fallas, sin embargo tenemos varios aspectos que representan problemas para la integridad de los recursos y que a su vez motivan el uso de transacciones

Dificultad para mantener consistencia en los datos Una misma vía de comunicación no siempre puede ser utilizada para suministrar

interacción entre dos procesos Requerimientos de procesamientos en paralelo Manejo interactivo de uno o más usuarios

Integridad de transaccionesUna transacción es una serie de operaciones sobre la base de datos consideradas como una única operación, de manera que cuando se cierra la transacción la base de datos queda en un estado consistente.

Las restricciones de integridad de transacciones gobiernan las formas en que se puede manipular la base de datos. A diferencia de otras restricciones, las restricciones de transacción versan sobre el procesamiento y, por tanto, por sí mismas no son parte del modelo de datos. La base de datos debe respetar todas las restricciones de integridad definidas antes de que comience la transacción y una vez finalizada ésta, aunque se pueden violar temporalmente algunas de las restricciones durante la transacción.

Las transacciones pueden involucrar a múltiples registros, múltiples relaciones e incluso múltiples bases de datos. Siendo precisos, todas las operaciones sobre una base de datos son transacciones. Incluso la actualización de un único registro existente es una transacción. Estas transacciones de bajo nivel las realiza el motor de base de datos de forma transparente y, normalmente se puede ignorar este nivel de detalle.

APLICACIONES DE TRANSACIONES

Base de datos Base de datos distribuidas Sistema de archivos distribuidos Desarrollo de aplicaciones tolerantes a fallos



DEFINICIÓN DE TRANSACIONES

Las transacciones fueron originalmente desarrolladas para ser utilizadas dentro de los sistemas de base de datos, donde se usaba para ayudar en el mantenimiento de los datos de las aplicaciones y que dependían de la consistencia de la información almacenada.Las transacciones son mecanismos que ayudan a simplificar la construcción de sistemas confiables mediante procesos que proporcionan soporte uniforme para invocar y sincronizar operaciones como:

Operaciones de comparación de datos Aseguramiento de la seriabilidad de las transacciones con otras Atomicidad en su comportamiento Recuperación de fallas

La palabra transacción describe una secuencia de operaciones con uno o más recursos que transforman su estado actual en un nuevo estado de consistencia. Es un conjunto de operaciones sobre datos que son tratadas como una unidad. Una transacción puede terminar, haciendo sus cambios persistentes, o abortar voluntaria o involuntariamente.Dentro del área de los sistemas computacionales el concepto de transacciones fue inicialmente utilizado para definir la consistencia entre múltiples usuarios en una base de datos. Una transacción es una colección de operaciones que hacen transformaciones consistentes de los estados de un sistema conservando la consistencia del sistema. Una base de datos esta en estado consistente si cumple todas las restricciones de integridad definidas sobre ella. Los cambios de estado se dan debido a actualización, inserción y eliminación de la información. Se quiere asegurar que la base de datos no entre en un estado de inconsistencia, pero durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. Lo importante aquí es asegurar que la base de datos vuelva aun estado consistente al concluir la ejecución de una transacción.Lo que se persigue con el uso de transacciones es por un lado contar con una transparencia adecuada de las acciones concurrentes a una base de datos y por el otro tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos



Estructura de transacciones

La estructura de una transacción usualmente viene dada según el modelo de la transacción, estas pueden ser planas (simples) o anidadas.

Transacciones planas:

Consisten en una secuencia de operaciones primitivas encerradas entre las palabras clave BEGIN y END. Por ejemplo:

BEGIN _TRANSACTION Reservación....END.

Transacciones Anidadas:

Consiste en tener transacciones que dependen de otras, estas transacciones están incluidas dentro de otras de un nivel superior y se las conoce como subtransacciones. La transacción de nivel superior puede producir hijos (subtransacciones) que hagan más fácil la programación del sistema y mejoras del desempeño.En las transacciones anidadas las operaciones de una transacción pueden ser así mismo otras transacciones. Por ejemplo:

BEGIN _TRANSACTION Reservación..........BEGIN _TRANSACTION Vuelo........END.( Vuelo ) ......BEGIN _TRANSACTION Hotel ........END...... END.

Una transacción anidada dentro de otra conserva las mismas propiedades que las de su padre, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias en una transacción anidada: debe empezar después que su padre y debe terminar antes que el. El compromiso de una subtransaccion es condicional al compromiso de su padre, si el padre de una o varias subtransacciones aborta, las subtransacciones hijas también serán abortadas. Las transacciones anidadas brindan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varias transacciones es posible tener mayor concurrencia dentro de una sola transacción.



Así también, es posible recuperarse de fallas de forma independiente de cada su transacción. Esto limita el daño a una parte más pequeña de la transacción, haciendo que el costo de la recuperación sea el menor.

También se deben considerar el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a este tipo de transacciones se les conoce como Generales .Por el contrario, si se restringe o impone que un dato debe ser leído antes de que pueda ser escrito entonces se tendrán 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 acción para transacciones restringidas en donde se aplica aún más la restricción de que cada par < read , write > tiene que ser ejecutado de manera atómica.

Ejecución de transacciones centralizadas

Teoría del procesamiento de transacciones:Consiste en una serie de modificaciones (transacciones) a un determinado recurso del sistema (por ejemplo una base de datos) y en donde se define un punto de inicio (Begin Tran) y un punto de terminación que define un bloque entre el conjunto de operaciones que son realizadas.Dentro de este proceso en bloque los demás usuarios no pueden modificar nada hasta que no se presente un estado estable de los datos, esto ocasiona inconsistencia temporal y conflictos

Ejecución de transacciones distribuidas

Ejecución distribuida de transacciones.

Métodos de implantación de transacciones.

Espacio de trabajo privado.

Consiste en realizar copias de los bloques que serán utilizados dentro de una transacción de manera que se trabaje con estas copias para realizar todas las modificaciones necesarias. Todo el espacio de trabajo con la información que será utilizada es contenido dentro de estas copias denominado espacio de trabajo privado. Los demás usuarios trabajarán con la copia original de los bloques pero no podrán obtener segunda copia de los mismos.



Bitácora de escritura anticipada.

Este método consiste en realizar una lista con todas las transacciones que van siendo ejecutadas hacia un bloque o espacio de trabajo que sea estable, a esta lista se le conoce como lista de intenciones.

Las transacciones serán actualizadas con la información una vez que se ha determinado el fin de la transacción

Algoritmos de control de concurrencias

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 más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin embargo, esto puede afectar grandemente el desempeño de un DDBMS dado que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, el número de transacciones activas, es probablemente el parámetro más 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 anomalías. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo término, pueden presentarse recuperaciones de información inconsistentes.

En este capítulo se hace la suposición de que el sistema distribuido es completamente confiable y no experimente falla alguna. En el capítulo siguiente, se considerará la presencia de fallas para obtener sistemas confiables.

El control de concurrencia y detección y manejo de bloqueos es un área de mucho estudio en las bases de datos distribuidas, a pesar de esto no hay ningún algoritmo aceptado para solucionar el problema. Esto se debe a varios factores de los cuales se consideran a los siguientes tres los más determinantes:

La data puede estar duplicada en un BDD, por tanto, el manejador de la BDD es responsable de localizar y actualizar la data duplicada. Si un nodo falla o la comunicación con un nodo falla mientras se realiza una actualización, el manejador debe asegurarse de que los efectos se reflejen una vez el nodo se recupere del fallo. La sincronización de transacciones en sitios o nodos múltiples es difícil ya que los nodos no pueden obtener información inmediata de las acciones realizadas en otros nodos concurrentemente.



Para el control de bloqueos mutuos no se ha desarrollado ninguna solución viable y la forma más simple y que la mayoría de productos utilizan es la implementación de un tiempo máximo de espera en las peticiones de bloqueos.Causa de estas dificultades más de 20 algoritmos de control de concurrencia se han propuesto en el pasado, y aun así siguen apareciendo nuevos. Una revisión bibliográfica muestra que la mayoría de los algoritmos son variantes del 2PL (2-phase locking o bloqueo de dos fases) o el algoritmo de time-stamp. A continuación se explican estos dos algoritmos básicos.

Bloqueo de dos fases (2PL)

El algoritmo 2PL utiliza bloqueos de lectura y escritura para prevenir conflictos entre operaciones. Consiste en los siguientes pasos para una transacción T:Obtiene bloqueo de lectura para un elemento L (bloqueo compartido) Obtiene bloqueo de escritura para un elemento E (bloqueo exclusivo) Lee el elemento L Escribe en el elemento E Libera el bloqueo de L Libera el bloqueo de E Las reglas básicas para manejar los bloqueos son: transacciones distintas no pueden tener acceso simultáneamente a un elemento (lectura-escritura o escritura-escritura), y una vez se libere un bloqueo no se puede pedir otro, es decir, los bloqueos de la transacción crecerán mientras no libere ninguno y luego de liberar alguno solo puede liberar los demás.Ejemplos del algoritmo 2PL sonLa básica en la que se sigue el esquema previamente explicado con la variante que el bloqueo de escritura se pide para todas las copias del elemento. 2PL de copia primaria: en vez de pedir bloqueo para cada copia del elemento de escritura se le pide a una copia primaria o principal. 2PL de voto: se pide a todos los nodos que voten para ver si se concede el bloqueo. 2PL centralizado: el manejador de bloqueos está centralizado y todas las peticiones de bloqueo las maneja el. Antes de implementar un algoritmo de control de concurrencia 2PL es necesario considerar distintos factores como cual es la unidad atómica más pequeña que el sistema permite bloquear, cual es el intervalo de sincronización para todas las copias de un elemento, donde se deben colocar las tablas con la información de los bloqueos y por último que tan probable es que ocurra por los factores anteriores un bloqueo mutuo.

Time-stamp

Cada transacción realizada se le asigna un timestamp (literalmente: sello de tiempo) único en el nodo que se originó. Este sello se adjunta a cada petición de lectura y escritura. En el caso de que se dé un conflicto de que dos operaciones de escritura traten de acceder al mismo elemento, este se resuelve serializandolo respecto a los sellos que tengan. A pesar de



que existen varios algoritmos de control de concurrencia basados en timestamps, muy pocos son utilizados en aplicaciones comerciales. Esto es en gran parte porque se requiere que el sistema distribuido cuente con un reloj sincronizado que es raro que se tenga implementado.

Pruebas de validación optimista

Los algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transacción conflictiva que accesa el mismo dato. Así, la ejecución de cualquier operación de una transacción sigue la secuencia de fases: validación (V), lectura ®, cómputo © y escritura (W) (ver Figura 6.6a). Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo antes de la fase de escritura (ver Figura 6.6b). De esta manera, una operación sometida a un despachador optimista nunca es retrasada.

Las operaciones de lectura, cómputo y escrita de cada transacción se procesan libremente sin actualizar la base de datos corriente. Cada transacción inicialmente hace sus cambios en copias locales de los datos. La fase de validación consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transacción es abortada y tiene que reiniciar

Los mecanismos optimistas para control de concurrencia fueron propuestos originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos las estampas de tiempo se asocian únicamente con las transacciones, no con los datos. Más aún, las estampas de tiempo no se asignan al inicio de una transacción sino justamente al inicio de su fase de validación. Esto se debe a que las estampas se requieren únicamente durante la fase de validación.

Cada transacción Ti se subdivide en varias subtransacciones, cada una de las cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransacción de Ti que se ejecuta en el nodo j. Supongamos que las transacciones se ejecutan de manera independiente y ellas alcanzan el fin de sus fases de lectura. A todas las subtransacciones se les asigna una estampa de tiempo al final de su fase de lectura. Durante la fase de validación se realiza una prueba de validación, si una transacción falla, todas las transacciones se rechazan.

La prueba de validación se realiza con una de las siguientes reglas:

1. Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su fase de escritura antes que Tij ha iniciado su fase de lectura entonces la validación tiene éxito. En este caso la ejecución de las transacciones es completamente serial como se muestra en la Figura 6.7a.

2. Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su fase de escritura mientras Tij está en su fase de lectura, entonces, la validación tiene éxito si



WS(Tk ) Ç RS(Tij ) = Æ . En este caso, las fases de lectura y escritura se traslapan, como se muestra en la Figura 6.7b, pero Tij no lee datos que son escritos por Tk.

3. Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su fase de lectura antes que Tij termine su fase de lectura, entonces, la validación tiene éxito si WS(Tk ) Ç RS(Tij ) = Æ y WS(Tk ) Ç WS(Tij ) = Æ .

Recuperación

La Recuperación de Transacción vence los defectos de recuperación tradicionales eliminando el tiempo de indisponibilidad y evitando la pérdida de datos buenos. La Recuperación de Transacción es “el proceso de borrar los efectos indeseados de transacciones específicas de la base de datos”. La recuperación tradicional está en el nivel de objeto de base de datos: por ejemplo, en el espacio de datos, espacio de mesa o nivel de índice. Realizando una recuperación tradicional, un objeto de base de datos específico es elegido. Entonces, una copia de seguridad de aquel objeto es aplicada, seguida volviendo a aplicar entradas de registro para cambios que ocurrieron después de que la copia de imagen fue tomada. Recuerde que todos los cambios hechos a una base de datos relacional son capturados en el registro de base de datos. De este modo, si los detalles de cambio pueden ser leídos del registro, la recuperación puede ser conseguida invirtiendo el impacto de los cambios registrados.

Seguridad e integridad

Desde hace ya varios años las bases de datos son ampliamente utilizadas en departamentos de gobiernos, empresas comerciales, bancos, hospitales, etc. Actualmente se está cambiando el esquema bajo el cuál se utilizan las bases de datos, ya no son utilizadas únicamente de forma interna, sino que se tiene muchos accesos externos de tipos distintos. Estos cambios que se han introducido en el uso de las bases de datos ha creado la necesidad mejorar las prácticas de seguridad ya que el ambiente ya no es tan controlado como el esquema antiguo.

Los problemas de mayor importancia en seguridad son autenticación, identificación, y refuerzo de los controles de acceso apropiados. El sistema de seguridad de niveles múltiples. Éste consiste en muchos usuarios con distintos niveles de permisos para una misma base de datos con información de distintos niveles. En las bases de datos distribuidas se han investigado dos acercamientos a este modelo: data distribuida y control centralizado, y data y control distribuidos.En el acercamiento de data distribuida y control centralizado se divide en dos soluciones: particionado y replicado. En el primero de estos lo que se tiene es un conjunto de nodos y cada uno de ellos opera a cierto nivel de seguridad, así el usuario con nivel de permisos X accede al servidor que maneja la data para X. El replicado surgió debido a que si alguien con altos derechos de seguridad deseaba



consultar data con de bajo nivel de seguridad debía enviar su petición a un servidor de bajo nivel de seguridad por lo cual se podría divulgar información sensible. En el esquema replicado entonces la data se repite en cascada de tal forma que el nivel más alto tiene una copia entera de la base de datos, y el más bajo solamente la información de más bajo nivel. El otro acercamiento de data y control distribuido cada nodo contiene información de distintos niveles y está diseñado para aceptar peticiones de cualquier nivel de usuario.

El problema de inferencia consiste en usuarios tratando de ejecutar consultas sobre la BD y estos infiriendo información sobre la respuesta legítima que la base de datos debe responder. Las herramientas para minería de datos hacen este problema aún más peligroso ya que hacen que sea más fácil para cualquier novato poder deducir patrones e información importantes de simplemente probar consultas.



Conclusiones

Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas en diferentes espacios lógicos (pej. un servidor corriendo 2 máquinas virtuales) e interconectados por una red de comunicaciones. Dichas BDD tienen la capacidad de realizar procesamiento autónomo, esto permite realizar operaciones locales o distribuidas. Un sistema de Bases de Datos Distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones de tal forma que, un usuario en cualquier sitio puede acceder los datos en cualquier parte de la red exactamente como si estos fueran accedidos de forma local.

Un sistema distribuido de bases de datos se almacenan en varias computadoras. Los principales factores que distinguen un SBDD de un sistema centralizado son los siguientes:

Hay múltiples computadores, llamados sitios o nodos.Estos sitios deben de estar comunicados por medio de algún tipo de red de comunicaciones para transmitir datos y órdenes entre los sitios.

Hay varios factores que han hecho que las bases de datos evolucionen a bases de datos distribuidas. En el mundo de los negocios se ha dado una globalización y a la vez las operaciones de las empresas son cada vez más descentralizadas geográficamente. También el poder de las computadoras personales aumentó y el costo de los Mainframes ya no tenía sentido. Además la necesidad de compartir datos ha hecho que crezca el mercado de las bases de datos distribuidas.



Bibliografía

Shaku,atre Distribución de base de datos “Corporatividad de procesos y redes “

McGraw-Hill

Stefano Seri“Distribución de base de datos, principios y sistemas”McGraw-Hill

Henry,silberchate Abraham“Fundamentos de base de datos”

McGraw-Hill


unidad 4 bdd

Documents