DISENO DE BASE DE DATOS

CONTENIDO Unidad 1: Transacciones y control de concurrencia

Transacciones: El concepto de transaccin: El trmino transaccin hace referencia a un conjunto de operaciones que forman una nica unidad lgica de trabajo. Por ejemplo, la transferencia de dinero de una cuenta a otra es una transaccin que consta de dos actualizaciones, una para cada cuenta. Una transaccin es una unidad de la ejecucin de un programa que accede y posiblemente actualiza varios elementos de datos. Una transaccin se inicia por la ejecucin de un programa de usuario escrito en un lenguaje de manipulacin de datos de alto nivel o en un lenguaje de programacin (por ejemplo SQL, COBOL, C, C++ o Java), y est delimitado por instrucciones (o llamadas a funcin) de la forma inicio transaccin y fin transaccin. La transaccin consiste en todas las operaciones que se ejecutan entre inicio transaccin y el fin transaccin. 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 transaccin se realizan adecuadamente en la base de datos o ninguna de ellas. Consistencia. La ejecucin aislada de la transaccin (es decir, sin otra transaccin 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 ejecucin antes de que comience Ti , o bien que Tj ha comenzado su ejecucin despus de que Ti termine. De este modo, cada transaccin ignora al resto de las transacciones que se ejecuten concurrentemente en el sistema. Durabilidad. Tras la finalizacin con xito de una transaccin, 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 acrnimo se obtiene de la primera letra de cada una de las cuatro propiedades en ingls (Atomicity, Consistency, Isolation y Durability, respectivamente). Para comprender mejor las propiedades ACID y la necesidad de dichas propiedades, considrese 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 porcin 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 transaccin que ejecuta la operacin leer. escribir (X), que transfiere el dato X desde la memoria intermedia local de la transaccin que ejecuta la operacin escribir a la base de datos. En un sistema de base de datos real, la operacin escribir no tiene por qu producir necesariamente una actualizacin de los datos en disco; la operacin escribir puede almacenarse temporalmente en memoria y llevarse a disco ms tarde. Sin embargo, por el momento se supondr que la operacin escribir

actualiza inmediatamente la base de datos. Sea Ti una transaccin para transferir 50 de la cuenta A a la cuenta B. Se puede definir dicha transaccin Como: Ti: leer(A); A := A 50; escribir(A); leer(B); B := B + 50; escribir(B). Ahora analizaremos cada una de las propiedades de una transaccin tomando en cuenta la transaccin anterior: Consistencia: en este caso el requisito de consistencia es que la suma de A y B no sea alterada al ejecutar la transaccin. Sin el requisito de consistencia, la transaccin podra crear o destruir dinero! Se puede comprobar fcilmente que si una base de datos es consistente antes de ejecutar una transaccin, sigue sindolo despus de ejecutar dicha transaccin. La responsabilidad de asegurar la consistencia de una transaccin es del programador de la aplicacin que codifica dicha transaccin. La comprobacin automtica de las restricciones de integridad puede facilitar esta tarea. Atomicidad: supngase que justo antes de ejecutar la transaccin Ti los valores de las cuentas A y B son de 1.000 y de 2.000 , respectivamente. Supngase ahora que durante la ejecucin de la transaccin Ti se produce un fallo que impide que dicha transaccin finalice con xito su ejecucin. Ejemplos de este tipo de fallos pueden ser los fallos en la alimentacin, los fallos del hardware y los errores software. Adems, supngase que el fallo tiene lugar despus de ejecutarse la operacin escribir(A), pero antes de ejecutarse la operacin escribir(B). En ese caso, los valores de las cuentas A y B que se ven reflejados en la base de datos son 950 y 2.000 . Se han perdido 50 de la cuenta A como resultado de este fallo. En particular se puede ver que ya no se conserva la suma A + B. As, como resultado del fallo, el estado del sistema deja de reflejar el estado real del mundo que se supone que modela la base de datos. Un estado as se denomina estado inconsistente. Hay que asegurarse de que estas inconsistencias no sean visibles en un sistema de base de datos. Ntese, sin embargo, que un sistema puede en algn momento alcanzar un estado inconsistente. Incluso si la transaccin Ti se ejecuta por completo, existe un punto en el que el valor de la cuenta A es de 950 y el de la cuenta B es de 2.000 , lo cual constituye claramente un estado inconsistente. Este estado, sin embargo, 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.050. De este modo, si la transaccin no empieza nunca o se garantiza que se complete, un estado inconsistente as no ser visible excepto durante la ejecucin de la transaccin. sta es la razn de que aparezca el requisito de atomicidad. Si se proporciona la propiedad de atomicidad, o todas las acciones de la transaccin se ven reflejadas en la base de datos, o ninguna de ellas. La idea bsica que hay detrs de asegurar la atomicidad es la siguiente. El sistema de base de datos mantiene los valores antiguos (en disco) de aquellos datos sobre los que una transaccin realiza una escritura y, si la transaccin no completa su ejecucin, los valores antiguos se recuperan para que parezca que la transaccin no se ha ejecutado. Eso lo maneja un componente llamado componente de gestin de transacciones. Durabilidad: una vez que se completa con xito la ejecucin de una transaccin, y despus de comunicar al usuario que inici la transaccin que se ha realizado la transferencia de fondos, no debe suceder que un fallo en el sistema produzca la prdida de datos correspondientes a dicha transferencia. La propiedad de durabilidad asegura que, una vez que se completa con xito una transaccin, persisten todas las modificaciones realizadas en la base de datos, incluso si hay un fallo en el sistema despus de completarse la ejecucin de dicha transaccin.

A partir de ahora se asume que un fallo en la computadora del sistema produce una prdida de datos de la memoria principal, pero los datos almacenados en disco nunca se pierden. Se puede garantizar la durabilidad si se asegura que: 1. Las modificaciones realizadas por la transaccin se guardan en disco antes de que finalice la transaccin. 2. La informacin de las modificaciones realizadas por la transaccin guardada en disco es suficiente para permitir a la base de datos reconstruir dichas modificaciones cuando el sistema se reinicien despus del fallo. La responsabilidad de asegurar la durabilidad es de un componente del sistema de base de datos llamado componente de gestin de recuperaciones. Aislamiento: incluso si se aseguran las propiedades de consistencia y de atomicidad para cada transaccin, si varias transacciones se ejecutan concurrentemente, se pueden entrelazar sus operaciones de un modo no deseado, produciendo un estado inconsistente. Por ejemplo, como se ha visto antes, la base de datos es inconsistente temporalmente durante la ejecucin de la transaccin para transferir fondos de la cuenta A a la cuenta B, con el total deducido escrito ya en A y el total incrementado todava sin escribir en B. Si una segunda transaccin que se ejecuta concurrente lee A y B en este punto intermedio y calcula A + B, observar un valor inconsistente. Adems, si esta segunda transaccin realiza despus modificaciones en A y B basndose en los valores ledos, la base de datos puede permanecer en un estado inconsistente aunque ambas transacciones terminen. Una solucin para el problema de ejecutar transacciones concurrentemente es ejecutarlas secuencialmente, es decir, una tras otra. La responsabilidad de asegurar la propiedad de aislamiento es de un componente del sistema de base de datos llamado componente de control de concurrencia. ESTADOS DE UNA TRANSACCIN: Una transaccin debe estar en uno de los estados siguientes: Activa, el estado inicial; la transaccin permanece en este estado durante su ejecucin. Parcialmente comprometida, despus de ejecutarse la ltima instruccin. Fallida, tras descubrir que no puede continuar la ejecucin normal. Abortada, despus de haber retrocedido la transaccin y restablecido la base de datos a su estado anterior al comienzo de la transaccin. Comprometida, tras completarse con xito. La nica forma de deshacer los cambios de una transaccin comprometida es ejecutando una transaccin compensadora. Por ejemplo, si una transaccin aade 20 a una cuenta, la transaccin compensadora debera restar 20 de la cuenta.

Una transaccin se dice que ha terminado si se ha comprometido o bien se ha abortado. Una transaccin comienza en el estado activa. Cuando acaba su ltima instruccin pasa al estado de parcialmente comprometida. En este punto la transaccin ha terminado su ejecucin, pero es posible que an tenga que ser abortada, puesto que los datos actuales pueden estar todava en la memoria principal y puede producirse un fallo en el hardware antes de que se complete con xito. Una transaccin abortada puede tener dos opciones ser Reiniciada pero slo si la transaccin se ha abortado a causa de algn error hardware o software que no lo haya provocado la lgica interna de la transaccin para luego ser considerada como una nueva transaccin. O la otra opcin ser Cancelada pero esto solo pasa si hay algn error interno lgico que slo se puede corregir escribiendo de nuevo el programa de aplicacin.

Transacciones en SQL:

Un lenguaje de manipulacin de datos debe incluir una constructora para especificar el conjunto de acciones que constituyen una transaccin.

En la norma SQL se especifica el comienzo de una transaccin explcitamente. Las transacciones se terminan con una de las instrucciones SQL siguientes: Commit work compromete la transaccin actual y comienza una nueva. Rollback work provoca que la transaccin actual aborte. La palabra clave work es opcional en ambas instrucciones. Si el programa termina sin ninguna de estas rdenes, los cambios o bien se comprometen o bien se retroceden. COMPROBACIN DE LA SECUENCIALIDAD: Cuando se disean esquemas de control de concurrencia hay que demostrar que las planificaciones que genera el esquema son secuenciables. Considrese una planificacin P. Se construye un grafo dirigido, llamado grafo de precedencia para P. Este grafo consiste en un par G = (V,A), siendo V un

conjunto de vrtices y A un conjunto de arcos. El conjunto de vrtices consiste en todas las transacciones que participan en la planificacin. El conjunto de arcos consiste en todos los arcos TiTj para los cuales se dan una de las tres condiciones siguientes: 1. Ti ejecuta escribir(Q) antes de que Tj ejecute leer(Q). 2. Ti ejecuta leer(Q) antes de que Tj ejecute escribir(Q). 3. Ti ejecuta escribir(Q) antes de que Tj ejecute escribir(Q). Por ejemplo, en la siguiente figura:

se muestra el grafo de precedencia de la planificacin 1. Slo contiene el arco T1 T2, puesto que todas las instrucciones de T1 se ejecutan antes de que lo haga la primera de T2. Anlogamente, la Figura (b) muestra el grafo de precedencia de la planificacin 2 con el nico arco T2T1, ya que todas las instrucciones de T2 se ejecutan antes de que lo haga la primera de T1. El grafo de precedencia de la planificacin 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). Tambin contiene el arco T2T1 debido a que T2 ejecuta leer(B) antes de que T1 ejecute escribir(B) la figura anterior contiene ciclos, lo que indica que esta planificacin no es secuenciable en cuanto a conflictos. Si el grafo de precedencia de P tiene un ciclo, entonces la planificacin P no es secuenciable en cuanto a conflictos. Si el grafo no contiene ciclos, entonces la planificacin P es secuenciable en cuanto a conflictos. El orden de secuencialidad se puede obtener a travs de la ordenacin topolgica, la cual determina un orden lineal que consiste en el orden parcial del grafo de precedencia. En general se pueden obtener muchos rdenes lineales posibles a travs de la ordenacin topolgica Por ejemplo, el grafo de la siguiente figura (a) tiene dos rdenes lineales aceptables, como se observa en las figuras (b) y (c).

As, para probar la secuencialidad en cuanto a conflictos hay que construir el grafo de precedencia e invocar a un algoritmo de deteccin de ciclos. Los algoritmos de deteccin de ciclos se pueden encontrar en cualquier libro de texto sobre algoritmos. Los algoritmos de deteccin de ciclos, tales como los que se basan en la bsqueda primero en profundidad, requieren del orden de n2 operaciones, siendo n el nmero de vrtices del grafo (es decir, el nmero de transacciones). De este modo se tiene un esquema prctico para determinar la secuencialidad en cuanto a conflictos. Resumen: pagina 380 libro. Concurrencia en bases de datos: Cuando se ejecutan varias transacciones concurrentemente en la base de datos, puede que deje de conservarse la propiedad de aislamiento. Es necesario que el sistema controle la interaccin entre las transacciones concurrentes; dicho control se lleva a cabo a travs de uno de los muchos mecanismos existentes llamado esquemas de control de concurrencia. Protocolos basados en el bloqueo: Una forma de asegurar la secuencialidad es exigir que el acceso a los elementos de datos se haga en exclusin mutua; es decir, mientras una transaccin accede a un elemento de datos, ninguna otra transaccin puede modificar dicho elemento. El mtodo ms habitual que se usa para implementar este requisito es permitir que una transaccin acceda a un elemento de datos slo si posee actualmente un bloqueo sobre dicho elemento. Bloqueos: Existen muchos modos mediante los cuales se puede bloquear un elemento de datos. 1. Compartido. Si una transaccin Ti obtiene un bloqueo en modo compartido (denotado por C) sobre el elemento Q, entonces Ti puede leer Q pero no lo puede escribir. 2. Exclusivo. Si una transaccin Ti obtiene un bloqueo en modo exclusivo (denotado por X) sobre el elemento Q, entonces Ti puede tanto leer como escribir Q. Es necesario que toda transaccin 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. La peticin se hace al gestor de control de concurrencia. La transaccin puede realizar la operacin slo despus de que el gestor de control de concurrencia conceda el bloqueo a la transaccin. Dado un conjunto de modos de bloqueo, se puede definir sobre ellos una funcin de compatibilidad como sigue. Utilizamos A y B para representar dos modos de bloqueo arbitrarios. Supngase que la transaccin Ti solicita un bloqueo en modo A sobre el elemento Q, en el que la transaccin Tj (Ti Tj) posee actualmente un bloqueo de modo B. Si a la transaccin Ti se le puede conceder un bloqueo sobre Q a pesar de la presencia del bloqueo de modo B, entonces se dice que el modo A es compatible con el modo B. Tal funcin se puede representar convenientemente en forma de matriz. Un elemento comp(A, B) de la matriz tiene el valor cierto si y slo si el modo A es compatible con el modo B. Ntese que el modo compartido es compatible con otro modo compartido, pero no con el modo exclusivo. En todo momento se pueden tener varios bloqueos en modo compartido (por varias transacciones) sobre un elemento de datos en concreto. Una peticin posterior de bloqueo en modo exclusivo debe esperar hasta que se liberen los bloqueos en modo compartido que se poseen actualmente.

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

figura 2 figura 1

figura 1

Pag 396 pdf

1.1.1 1.1.2

Problemas de concurrencia: Bloqueo y Deadlocks:

1.1.3 1.1.4

Introduccin a pl-sql: Procedimientos Almacenados:

1.1.5

Triggers:

Unidad 2: Respaldo y Recuperacin 2.1. Clasificacin de fallos: 2.2. Tipos de respaldo: 2.3. Recuperacin basada en bitcora: 2.4. Alta disponibilidad: 2.4.1. Hardware y software en alta disponibilidad: 2.4.2. Redundancia: 2.4.2.1. Bases de datos en stand by: 2.4.3. Clustering: 2.4.3.1. Definicin de Cluster: 2.4.4. Fail Over: 2.5. Distribucin y paralelismo:

Unidad 3: Anlisis multidimensional y Datawarehouse

3.1 Bases de datos OLAP ROLAP MOLAP:

3.2 El esquema estrella y el esquema snowfake:

3.3 Jerarquas y resmenes:

3.4 Datawarehouse y Datamart:

3.4.1 Definicin de Datawarehouse: 3.4.2 Definicin de Datamart: 3.5 El proceso ETT: 3.6 Sistemas de soporte de decisiones DSS: 3.7 Data mining: 3.8 Inteligencia del negocio (Bussiness Inteligent):

Unidad 4: Optimizacin y alto rendimiento

4.1 Optimizacin de consultas: 4.1.1 El proceso de ejecucin de consultas: 4.1.2 Algoritmos y plan de ejecucin: 4.1.3 Optimizacin por reglas y por costos: 4.2 Evaluacin del rendimiento: 4.2.1 Parmetros de medicin: 4.2.2 El Hit ratio y Estadsticas de medicin: 4.3 Optimizacin de aplicaciones:

Unidad 5: Seguridad

5.1. Consideraciones generales: 5.2. Identificacin y autenticacin: 5.3. Reglas de autorizacin: 5.4. Clasificacin de datos: 5.5. Seguridad en SQL:

Unidad 6: Sistemas Distribuidos de Bases de Datos

6.1 Definiciones: 6.2 Las 12 reglas de CODD: 6.3 El commit de dos fases: 6.4 Consistencia y convergencia: 6.5 Diseo de sistemas distribuidos: 6.6 La distribucin de los datos: 6.6.1 Centralizada: 6.6.2 Distribuida: 6.6.3 Replicacin: 6.6.3.1 Modelos de replicacin: 6.6.3.1.1 Localidad primaria e instantneas: 6.6.3.1.2 Replicacin simtrica (Multi-maestra): 6.6.3.1.3 Conflictos de replicacin:

Unidad 7: Bases de datos orientadas a objetos

7.1 Basados en Objetos, orientado a objetos y objeto relacionales:

7.2 Estructura de Objetos y jerarquas:

7.3 SQL de objetos y SQL ANSI 2003:

7.4 Ref objetos y llaves primarias:

7.5 Campos mltiples y vrrays:

7.6 Tablas anidadas y jerarquas:

7.7 Operaciones DDL y DML en objetos: