You are on page 1of 10

DISENO DE BASE DE DATOS

CONTENIDO Unidad 1: Transacciones y control de concurrencia

Transacciones: El concepto de transacción: El término transacción hace referencia a un conjunto de operaciones que forman una única unidad lógica de trabajo. Por ejemplo, la transferencia de dinero de una cuenta a otra es una transacción que consta de dos actualizaciones, una para cada cuenta. Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Una transacción se inicia por la ejecución de un programa de usuario escrito en un lenguaje de manipulación de datos de alto nivel o en un lenguaje de programación (por ejemplo SQL, COBOL, C, C++ o Java), y está delimitado por instrucciones (o llamadas a función) de la forma inicio transacción y fin transacción. La transacción consiste en todas las operaciones que se ejecutan entre inicio transacción y el fin transacción. Para asegurar la integridad de los datos se necesita que el sistema de base de datos mantenga las siguientes propiedades de las transacciones: • Atomicidad. O todas las operaciones de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas. • Consistencia. La ejecución aislada de la transacción (es decir, sin otra transacción que se ejecute concurrentemente) conserva la consistencia de la base de datos. • Aislamiento. Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones Ti y Tj, se cumple que para los efectos de Ti, o bien Tj ha terminado su ejecución antes de que comience Ti , o bien que Tj ha comenzado su ejecución después de que Ti termine. De este modo, cada transacción ignora al resto de las transacciones que se ejecuten concurrentemente en el sistema. • Durabilidad. Tras la finalización con éxito de una transacción, los cambios realizados en la base de datos permanecen, incluso si hay fallos en el sistema. Estas propiedades a menudo reciben el nombre de propiedades ACID; el acrónimo se obtiene de la primera letra de cada una de las cuatro propiedades en inglés (Atomicity, Consistency, Isolation y Durability, respectivamente). Para comprender mejor las propiedades ACID y la necesidad de dichas propiedades, considérese un sistema bancario simplificado constituido por varias cuentas y un conjunto de transacciones que acceden y actualizan dichas cuentas. Por ahora se asume que la base de datos reside permanentemente en disco, pero una porción de la misma reside temporalmente en la memoria principal. El acceso a la base de datos se lleva a cabo mediante las dos operaciones siguientes: • leer (X), que transfiere el dato X de la base de datos a una memoria intermedia local perteneciente a la transacción que ejecuta la operación leer. • escribir (X), que transfiere el dato X desde la memoria intermedia local de la transacción que ejecuta la operación escribir a la base de datos. En un sistema de base de datos real, la operación escribir no tiene por qué producir necesariamente una actualización de los datos en disco; la operación escribir puede almacenarse temporalmente en memoria y llevarse a disco más tarde. Sin embargo, por el momento se supondrá que la operación escribir

En particular se puede ver que ya no se conserva la suma A + B. leer(B). incluso si hay un fallo en el sistema después de completarse la ejecución de dicha transacción. A := A – 50. que un sistema puede en algún momento alcanzar un estado inconsistente. Ahora analizaremos cada una de las propiedades de una transacción tomando en cuenta la transacción anterior: Consistencia: en este caso el requisito de consistencia es que la suma de A y B no sea alterada al ejecutar la transacción. un estado inconsistente así no será visible excepto durante la ejecución de la transacción. pero antes de ejecutarse la operación escribir(B).000 €. Hay que asegurarse de que estas inconsistencias no sean visibles en un sistema de base de datos.actualiza inmediatamente la base de datos. si la transacción no completa su ejecución. Incluso si la transacción Ti se ejecuta por completo. En ese caso. los valores antiguos se recuperan para que parezca que la transacción no se ha ejecutado. B := B + 50. escribir(B). Eso lo maneja un componente llamado componente de gestión de transacciones. Se puede definir dicha transacción Como: Ti: leer(A). Durabilidad: una vez que se completa con éxito la ejecución de una transacción. el estado del sistema deja de reflejar el estado real del mundo que se supone que modela la base de datos. Ésta es la razón de que aparezca el requisito de atomicidad. Supóngase ahora que durante la ejecución de la transacción Ti se produce un fallo que impide que dicha transacción finalice con éxito su ejecución. y después de comunicar al usuario que inició la transacción que se ha realizado la transferencia de fondos. Atomicidad: supóngase que justo antes de ejecutar la transacción Ti los valores de las cuentas A y B son de 1. sin embargo. ¡la transacción podría crear o destruir dinero! Se puede comprobar fácilmente que si una base de datos es consistente antes de ejecutar una transacción. si la transacción no empieza nunca o se garantiza que se complete.000 €. Se han perdido 50 € de la cuenta A como resultado de este fallo. La propiedad de durabilidad asegura que. Ejemplos de este tipo de fallos pueden ser los fallos en la alimentación. sin embargo. Un estado así se denomina estado inconsistente. Así. . persisten todas las modificaciones realizadas en la base de datos.000 € y de 2. los fallos del hardware y los errores software. supóngase que el fallo tiene lugar después de ejecutarse la operación escribir(A). Sea Ti una transacción para transferir 50 € de la cuenta A a la cuenta B. sigue siéndolo después de ejecutar dicha transacción. lo cual constituye claramente un estado inconsistente. o ninguna de ellas. existe un punto en el que el valor de la cuenta A es de 950 € y el de la cuenta B es de 2. Si se proporciona la propiedad de atomicidad. Sin el requisito de consistencia. Además. Este estado. El sistema de base de datos mantiene los valores antiguos (en disco) de aquellos datos sobre los que una transacción realiza una escritura y. La responsabilidad de asegurar la consistencia de una transacción es del programador de la aplicación que codifica dicha transacción. no debe suceder que un fallo en el sistema produzca la pérdida de datos correspondientes a dicha transferencia. De este modo. los valores de las cuentas A y B que se ven reflejados en la base de datos son 950 € y 2. escribir(A). se sustituye eventualmente por otro estado consistente en el que el valor de la cuenta A es de 950 € y el de la cuenta B es de 2. como resultado del fallo.000 €. La comprobación automática de las restricciones de integridad puede facilitar esta tarea. La idea básica que hay detrás de asegurar la atomicidad es la siguiente. respectivamente. Nótese.050€. una vez que se completa con éxito una transacción. o todas las acciones de la transacción se ven reflejadas en la base de datos.

La información de las modificaciones realizadas por la transacción guardada en disco es suficiente para permitir a la base de datos reconstruir dichas modificaciones cuando el sistema se reinicien después del fallo. ESTADOS DE UNA TRANSACCIÓN: Una transacción debe estar en uno de los estados siguientes: • Activa. la transacción permanece en este estado durante su ejecución. después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción. como se ha visto antes. una tras otra. se pueden entrelazar sus operaciones de un modo no deseado. tras completarse con éxito. la transacción compensadora debería restar 20 € de la cuenta. tras descubrir que no puede continuar la ejecución normal. Una solución para el problema de ejecutar transacciones concurrentemente es ejecutarlas secuencialmente. Se puede garantizar la durabilidad si se asegura que: 1. • Comprometida. Si una segunda transacción que se ejecuta concurrente lee A y B en este punto intermedio y calcula A + B. La única forma de deshacer los cambios de una transacción comprometida es ejecutando una transacción compensadora. Las modificaciones realizadas por la transacción se guardan en disco antes de que finalice la transacción. si una transacción añade 20 €a una cuenta. Por ejemplo. Además. el estado inicial.A partir de ahora se asume que un fallo en la computadora del sistema produce una pérdida de datos de la memoria principal. • Fallida. la base de datos puede permanecer en un estado inconsistente aunque ambas transacciones terminen. si esta segunda transacción realiza después modificaciones en A y B basándose en los valores leídos. 2. La responsabilidad de asegurar la durabilidad es de un componente del sistema de base de datos llamado componente de gestión de recuperaciones. después de ejecutarse la última instrucción. La responsabilidad de asegurar la propiedad de aislamiento es de un componente del sistema de base de datos llamado componente de control de concurrencia. • Abortada. • Parcialmente comprometida. es decir. con el total deducido escrito ya en A y el total incrementado todavía sin escribir en B. si varias transacciones se ejecutan concurrentemente. . Aislamiento: incluso si se aseguran las propiedades de consistencia y de atomicidad para cada transacción. observará un valor inconsistente. pero los datos almacenados en disco nunca se pierden. produciendo un estado inconsistente. Por ejemplo. la base de datos es inconsistente temporalmente durante la ejecución de la transacción para transferir fondos de la cuenta A a la cuenta B.

Este grafo consiste en un par G = (V. Se construye un grafo dirigido. Transacciones en SQL: Un lenguaje de manipulación de datos debe incluir una constructora para especificar el conjunto de acciones que constituyen una transacción. En este punto la transacción ha terminado su ejecución. Las transacciones se terminan con una de las instrucciones SQL siguientes: • Commit work compromete la transacción actual y comienza una nueva. Una transacción comienza en el estado activa. Cuando acaba su última instrucción pasa al estado de parcialmente comprometida.A). COMPROBACIÓN DE LA SECUENCIALIDAD: Cuando se diseñan esquemas de control de concurrencia hay que demostrar que las planificaciones que genera el esquema son secuenciables. La palabra clave work es opcional en ambas instrucciones. Considérese una planificación P. los cambios o bien se comprometen o bien se retroceden. O la otra opción ser Cancelada pero esto solo pasa si hay algún error interno lógico que sólo se puede corregir escribiendo de nuevo el programa de aplicación. pero es posible que aún tenga que ser abortada. llamado grafo de precedencia para P. Una transacción abortada puede tener dos opciones ser Reiniciada pero sólo si la transacción se ha abortado a causa de algún error hardware o software que no lo haya provocado la lógica interna de la transacción para luego ser considerada como una nueva transacción. puesto que los datos actuales pueden estar todavía en la memoria principal y puede producirse un fallo en el hardware antes de que se complete con éxito. siendo V un .Una transacción se dice que ha terminado si se ha comprometido o bien se ha abortado. • Rollback work provoca que la transacción actual aborte. En la norma SQL se especifica el comienzo de una transacción explícitamente. Si el programa termina sin ninguna de estas órdenes.

Sólo contiene el arco T1 → T2. Ti ejecuta leer(Q) antes de que Tj ejecute escribir(Q). Ti ejecuta escribir(Q) antes de que Tj ejecute leer(Q). ya que todas las instrucciones de T2 se ejecutan antes de que lo haga la primera de T1. Si el grafo de precedencia de P tiene un ciclo. En general se pueden obtener muchos órdenes lineales posibles a través de la ordenación topológica Por ejemplo. Análogamente. El grafo de precedencia de la planificación 4 se representa en la siguiente figura: Contiene el arco T1 → T2 debido a que T1 ejecuta leer(A) antes de que T2 ejecute escribir(A). El conjunto de arcos consiste en todos los arcos Ti→Tj para los cuales se dan una de las tres condiciones siguientes: 1. Ti ejecuta escribir(Q) antes de que Tj ejecute escribir(Q). entonces la planificación P no es secuenciable en cuanto a conflictos. el grafo de la siguiente figura (a) tiene dos órdenes lineales aceptables.conjunto de vértices y A un conjunto de arcos. . El conjunto de vértices consiste en todas las transacciones que participan en la planificación. entonces la planificación P es secuenciable en cuanto a conflictos. 2. la cual determina un orden lineal que consiste en el orden parcial del grafo de precedencia. Por ejemplo. en la siguiente figura: se muestra el grafo de precedencia de la planificación 1. como se observa en las figuras (b) y (c). Si el grafo no contiene ciclos. También contiene el arco T2→T1 debido a que T2 ejecuta leer(B) antes de que T1 ejecute escribir(B) la figura anterior contiene ciclos. El orden de secuencialidad se puede obtener a través de la ordenación topológica. puesto que todas las instrucciones de T1 se ejecutan antes de que lo haga la primera de T2. la Figura (b) muestra el grafo de precedencia de la planificación 2 con el único arco T2→T1. 3. lo que indica que esta planificación no es secuenciable en cuanto a conflictos.

En todo momento se pueden tener varios bloqueos en modo compartido (por varias transacciones) sobre un elemento de datos en concreto. Es necesario que toda transacción solicite un bloqueo del modo apropiado sobre el elemento de datos Q dependiendo de los tipos de operaciones que se vayan a realizar sobre Q. Resumen: pagina 380 libro. Concurrencia en bases de datos: Cuando se ejecutan varias transacciones concurrentemente en la base de datos. La petición se hace al gestor de control de concurrencia. puede que deje de conservarse la propiedad de aislamiento.Así. Los algoritmos de detección de ciclos. entonces se dice que el modo A es compatible con el modo B. B) de la matriz tiene el valor cierto si y sólo si el modo A es compatible con el modo B. Tal función se puede representar convenientemente en forma de matriz. Exclusivo. De este modo se tiene un esquema práctico para determinar la secuencialidad en cuanto a conflictos. Si a la transacción Ti se le puede conceder un bloqueo sobre Q a pesar de la presencia del bloqueo de modo B. Bloqueos: Existen muchos modos mediante los cuales se puede bloquear un elemento de datos. mientras una transacción accede a un elemento de datos. Nótese que el modo compartido es compatible con otro modo compartido. entonces Ti puede tanto leer como escribir Q. Compartido. el número de transacciones). dicho control se lleva a cabo a través de uno de los muchos mecanismos existentes llamado esquemas de control de concurrencia. 2. ninguna otra transacción puede modificar dicho elemento. . entonces Ti puede leer Q pero no lo puede escribir. Un elemento comp(A. pero no con el modo exclusivo. se puede definir sobre ellos una función de compatibilidad como sigue. La transacción puede realizar la operación sólo después de que el gestor de control de concurrencia conceda el bloqueo a la transacción. tales como los que se basan en la búsqueda primero en profundidad. 1. Si una transacción Ti obtiene un bloqueo en modo exclusivo (denotado por X) sobre el elemento Q. Una petición posterior de bloqueo en modo exclusivo debe esperar hasta que se liberen los bloqueos en modo compartido que se poseen actualmente. en el que la transacción Tj (Ti ≠ Tj) posee actualmente un bloqueo de modo B. Si una transacción Ti obtiene un bloqueo en modo compartido (denotado por C) sobre el elemento Q. Dado un conjunto de modos de bloqueo. El método más habitual que se usa para implementar este requisito es permitir que una transacción acceda a un elemento de datos sólo si posee actualmente un bloqueo sobre dicho elemento. Protocolos basados en el bloqueo: Una forma de asegurar la secuencialidad es exigir que el acceso a los elementos de datos se haga en exclusión mutua. Los algoritmos de detección de ciclos se pueden encontrar en cualquier libro de texto sobre algoritmos. Es necesario que el sistema controle la interacción entre las transacciones concurrentes. requieren del orden de n2 operaciones. Supóngase que la transacción Ti solicita un bloqueo en modo A sobre el elemento Q. siendo n el número de vértices del grafo (es decir. es decir. Utilizamos A y B para representar dos modos de bloqueo arbitrarios. para probar la secuencialidad en cuanto a conflictos hay que construir el grafo de precedencia e invocar a un algoritmo de detección de ciclos.

De forma similar se solicita un bloqueo exclusivo a través de la instrucción bloquear-X(Q). La transacción Ti puede desbloquear un elemento de datos que haya bloqueado en algún momento anterior. una transacción Ti debe en primer lugar bloquear dicho elemento. Para acceder a un elemento de datos. considérese de nuevo el sistema bancario simplificado. Si por el contrario estas transacciones se ejecutan concurrentemente. Sean A y B dos cuentas a las que acceden las transacciones T1 y T2. Si estas dos transacciones se ejecutan secuencialmente. no siempre es aconsejable que una transacción desbloquee un elemento de datos inmediatamente después de finalizar su acceso sobre él. T2 como en el orden T2. Nótese que la transacción debe poseer un bloqueo sobre un elemento de datos durante todo el tiempo que acceda a dicho elemento. De este modo Ti debe esperar hasta que se liberen todos los bloqueos incompatibles que posean otras transacciones. Si éste ya se encuentra bloqueado por otra transacción en un modo incompatible. T1. lo cual es incorrecto. En ese caso la transacción T2 visualiza 250 €. La transacción T2 visualiza la cantidad total de dinero de las cuentas A y B —es decir. Supóngase que los valores de las cuentas A y B son 100 € y 200 € respectivamente.C(Q). la suma A + B (Figura 2). ya que puede dejar de asegurarse la secuencialidad. tanto en el orden T1. La transacción T1 transfiere 50 € desde la cuenta B a la A (figura 1). lo cual provoca que T2 perciba un estado inconsistente. Se puede desbloquear un elemento de datos Q por medio de la instrucción desbloquear(Q). Como ejemplo. que se muestra en la Figura 3. Además. El motivo por el que se produce esta incorrección es que la transacción T1 desbloquea el elemento B demasiado pronto. figura 2 figura 1 figura 1 . entonces puede darse la planificación 1. el gestor de control de concurrencia no concederá el bloqueo hasta que todos los bloqueos incompatibles que posean otras transacciones hayan sido liberados.Una transacción solicita un bloqueo compartido sobre el elemento de datos Q a través de la instrucción bloquear. entonces la transacción T2 visualizará el valor 300 €.

1.5 El proceso ETT: 3.1 Bases de datos OLAP ROLAP MOLAP: 3.3 1.4.4.1.1.4.6 Sistemas de soporte de decisiones DSS: 3. Fail Over: 2. Clustering: 2.1.2. Hardware y software en alta disponibilidad: 2.2 El esquema estrella y el esquema snowfake: 3.4.5.4.3 Jerarquías y resúmenes: 3.1. Distribución y paralelismo: Unidad 3: Análisis multidimensional y Datawarehouse 3.3.4.4.2.2.1.2 Definición de Datamart: 3. Tipos de respaldo: 2.1 Definición de Datawarehouse: 3.4 Introducción a pl-sql: Procedimientos Almacenados: 1.1. Bases de datos en stand by: 2.1 1.3.5 Triggers: Unidad 2: Respaldo y Recuperación 2.4. Definición de Cluster: 2.4.2 Problemas de concurrencia: Bloqueo y Deadlocks: 1. Clasificación de fallos: 2.1. Redundancia: 2.1.4 Datawarehouse y Datamart: 3.3.8 Inteligencia del negocio (Bussiness Inteligent): .4. Recuperación basada en bitácora: 2.Pag 396 pdf 1.7 Data mining: 3. Alta disponibilidad: 2.

3 Replicación: 6.3.2 Algoritmos y plan de ejecución: 4. Clasificación de datos: 5.2.2 Distribuida: 6.1 Centralizada: 6.5.2 Replicación simétrica (Multi-maestra): 6.Unidad 4: Optimización y alto rendimiento 4. Identificación y autenticación: 5.4 Consistencia y convergencia: 6.3 Optimización de aplicaciones: Unidad 5: Seguridad 5.2 Evaluación del rendimiento: 4.1 Parámetros de medición: 4.1 Optimización de consultas: 4.3.1 El proceso de ejecución de consultas: 4.1.1. Seguridad en SQL: Unidad 6: Sistemas Distribuidos de Bases de Datos 6.1.6.1 Definiciones: 6.3.2.6. Reglas de autorización: 5.3.5 Diseño de sistemas distribuidos: 6.1.2 Las 12 reglas de CODD: 6.6 La distribución de los datos: 6.6.1 Modelos de replicación: 6.6.4. Consideraciones generales: 5.6.6.2 El Hit ratio y Estadísticas de medición: 4.3 Conflictos de replicación: .1 Localidad primaria e instantáneas: 6.3.3 El commit de dos fases: 6.1.2.1.3 Optimización por reglas y por costos: 4.1.6.

3 SQL de objetos y SQL ANSI 2003: 7.2 Estructura de Objetos y jerarquías: 7.6 Tablas anidadas y jerarquías: 7.4 Ref objetos y llaves primarias: 7.Unidad 7: Bases de datos orientadas a objetos 7. orientado a objetos y objeto relacionales: 7.7 Operaciones DDL y DML en objetos: .1 Basados en Objetos.5 Campos múltiples y vrrays: 7.