DISEÑO DE BASE DE DATOS

1. TRANSACCIONES DISEÑO DE BASE DE DATOS

2. Colección de operaciones que forman una única unidad lógica de trabajo. TRANSACCION

3. Atomicidad Consistencias Aislamiento -- Concurrencia Durabilidad Propiedad de una transaccion

4. Todas las operaciones de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas ATOMICIDAD

5. La ejecución aislada de la transacción (sin otra que se ejecute concurrentemente) conserva la consistencia de la base de datos) consistencia

6. Aunque se ejecuten varias transacciones concurrentemente, el sistema garantiza que para cada par de transacciones, no se entrelazaran en su ejecución, sino que se realizaran de forma independiente. aislamiento

7. 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. DURABILIDAD

8. Atomicity, Consistency, Isolation Durability Propiedades ACID

9. Mediante 2 operaciones • Leer (x) • Transfiere de BD a memoria intermedia de la tx • Escribir (x) • Transfiere de memoria intermedia a la base de datos ACCESO A LA BASE DE DATOS

10. Sea Ti una transacción para transferir Q. 50 de la cuenta A a la cuenta B. Se puede definir dicha transacción como • Ti: leer(A); • A := A – 50; • escribir(A); • leer(B); • B := B + 50; • escribir(B). EJEMPLO

11. Consistencia • Que no sea alterado el balance de las cuentas A y B al efectuar el traslado de fondos (transacción) • Responsabilidad: • Programador analizando

12. Atomicidad • Suponiendo que la cuenta A tiene Q.1,000 y la B tiene Q.2,000 antes de efectuar el traslado • Que pasaría si durante el proceso de ejecutar la transacción ocurriera un fallo en el sistema? • Alimentación • Hardware • Software analizando

13. Durabilidad • Una vez se completa con éxito una T(x) aunque ocurriera un fallo en el sistema no se puede corromper dicha T(x) • Que pasaría si durante el proceso de ejecutar la transacción ocurriera un fallo en el sistema? analizando

14. Aislamiento • Que pasaría si todas las 3 propiedades se cumplieran sin problema sin embargo 2 cuenta habientes hacen un retiro al mismo tiempo? • La solución es ejecutarlas secuencialmente las transacciones analizando

15. Volátil • Falta de energía eléctrica se pierde la información • No Volátil • Falta de energía NO se pierde la información • Discos duros, CDs, etc. • Permanente • No importa lo que pase siempre se dispondrá de la información • Múltiples copias Modelos de almacenamiento

16. Almacenamiento Secundario • No volátil • Almacenamiento Primario • Es volátil • RAM Modelos de almacenamiento

17. Procesamiento Concurrente • Es aquel que se da cuando varios procesos corren al mismo tiempo • Procesamiento Paralelo • Sistema operativo maneja recursos de un sistema y guarda la información en bloques (sectores) procesamiento

18. Bloque • Es la unidad de almacenamiento secundario • Buffer • Es la unidad de transferencia de información entre el almacenamiento primario y secundario • Es la unidad de almacenamiento primario Bloque y buffer

19. Por lo regular si el DBMS pide un registro trae todo el bloque • El cual puede contener varios registros. Bloque y buffer

20. Una transacción que termina su ejecución con éxito se dice que está comprometida Una transacción comprometida que haya hecho modificaciones transforma la base de datos llevándola a un nueva estado consistente, que permanece incluso si hay fallo en el sistema En ausencia de fallos, todas las transacciones se completan con éxito MODELO DE TRANSACCION

21. Una transacción que no termina su ejecución con éxito se dice que está abortada Para asegurar la atomicidad, las transacciones abortadas no deben tener efecto sobre el estado de la base de datos, cualquier cambio que haya hecho la transacción abortada debe deshacerse Una vez deshechos los cambios de una transacción abortada se dice que la transacción se ha retrocedido MODELO DE TRANSACCION

22. Una transacción debe estar en uno de los siguientes estados: Activa (estado inicial): la transacción permanece en este estado durante su ejecución Parcialmente Comprometida: la transacción pasa a este estado cuando acaba de realizar la última instrucción Fallida: la transacción pasa a este estado tras descubrir que no puede continuar la ejecución normal Abortada: la transacción pasa a este estado después de haber restablecido la base de datos a su estado anterior Comprometida: la transacción pasa a este estado tras completarse con éxito MODELO DE TRANSACCION

23. MODELO DE TRANSACCION comprometida parcialmente comprometida Commit Fin activa Consistente Consistente Fallo Fallo fallida abortada Rollback Puede estar inconsistente

24. En la norma SQL el comienzo de una transacción se especifica explícitamente (usualmente begin/starttransaction) Las transacciones terminan con una de las siguientes instrucciones: commitwork (compromete la transacción actual) rollbackwork (provoca que la transacción aborte) Si el programa termina sin ninguna de estas órdenes, los cambios se comprometen o abortan según indique cada sistema Implementación de transacciones sql

25. Programa pagar_cheque • Write (‘ingrese cuenta’) • Read (cta) • Write (‘valor’) • Read (valor) • Begintransaction • ReadDB (cta, saldo) • Saldo = saldo – valor • WriteDB (cta, saldo) • Write DB (cheque, ‘P’) • Commit • Write (‘Pague’) Implementación de transacciones sql

26. Begintransaction • ReadDB (cta, saldo) • If saldo >= valor then • Begin • Saldo = saldo – valor • WriteDB (cta, saldo) • Commit • Write (‘Pague’) • End • Begin • WriteDB (histo, x) • Commit • End Implementación de transacciones sql

27. Modelo de fallo E D C B A Tiempo de verificación Tiempo de fallo

28. Para que el sistema se pueda recuperar ante fallos se necesita grabar cada operación con la BD en un fichero LOG (bitácora). Checkpoints. • Se escribe en el fichero LOG antes que en la BD • El fichero LOG debe estar en memoria estable • Por cada operación se escribe un reg. en LOG • <comienza-transacción, numt> • <escritura, numt, id_dato, val_viejo, val_nuevo> • <lectura, numt, id_dato, valor> • <termina_transacción_con_éxito, numt> • <punto_comprobación, numt, numc> RECUPERACION DEL SISTEMA

29. Archivo especial que no conviene tenerlo en el mismo disco o directorio donde esta la base de datos. Bitacora (log) Almacenamiento secundario bitacora Almacenamiento primario

30. Bitacora (log) • Transaction T2 • Begintransaction • ReadDB(B) • ReadDB(C) • B= B – 1000 • C = C + 1000 • WriteDB(B) • WriteDB(C) • Commit • Transaction T1 • Begintransaction • ReadDB(A) • A = A + 5000 • WriteDB(A) • Commit Cuenta A = 10,000 Cuenta B = 5,000 Cuenta C = 1,000 Cuenta D = 10,000 Cuenta E = 10,000 Cuenta F = 3,000 Cuenta G = 8,000 • Transaction T3 • Begintransaction • ReadDB(D) • ReadDB(G) • D= D – 1000 • G= G + 1000 • WriteDB(D) • WriteDB(G) • Commit • Transaction T5 • Begintransaction • ReadDB(B) • B= B + 10,000 • WriteDB(B) • Commit • Transaction T4 • Begintransaction • ReadDB(A) • A= A – 10,000 • WriteDB(A) • Commit

31. La ejecución concurrente de transacciones puede dar lugar a problemas: • Problema de la actualización perdida • Problema de leer una actualización temporal (lectura sucia) • Problema del resumen incorrecto • Problema de la lectura no repetible Problemas de concurrencia

32. A cada elemento de datos o gránulo X de la BD se le asocia una variable • operación lock_exclusivo(X): deja bloqueado al que lo pide si otro ya tiene cualquier lock sobre X • operación lock_compartido(X): deja bloqueado al que lo pide si otro ya tiene un lock exclusivo sobre X • operación unlock(X): libera su lock sobre X • Antes de leer X lock_compartido(X) • Antes de escribir (leer) X lock_exclusivo(X) • Si no se va a leer o escribir más unlock(X) Técnicas de bloqueo (lock)

33. Deadlock (o abrazo mortal o interbloqueo): Cuando una transacción T1 está bloqueada esperando a que otra T2 libere un lock, la cual también está bloqueada esperando a que T1 libere uno de sus lock. Se puede generalizar para N transacciones. • Prevención de deadlocks • Cada transacción obtiene todos los locks al principio y si no puede entonces no obtiene ninguno. Problema de livelock(inanición de algunas transacciones que pueden no obtener todos los que necesiten) • Los elementos de la BD están ordenados de alguna manera y los lock hay que obtenerlos en dicho orden. Los programadores deben controlarlo !! • Detección y recuperación de deadlocks. • A medida que se piden y conceden los lock se construye un grafo de las transacciones que están esperando a otras. Si existe un ciclo en dicho grafo: deadlock. Hay que proceder a abortar a alguna de las transacciones. Problema de livelock si se aborta siempre a la misma! Deadlocks

34. DECLAREimporteNUMBER;ctaOrigenVARCHAR2(23);ctaDestinoVARCHAR2(23);BEGINimporte := 100;ctaOrigen  := '2530 10 2000 1234567890';ctaDestino := '2532 10 2010 0987654321';UPDATE CUENTAS SET SALDO = SALDO - importeWHERE CUENTA = ctaOrigen;UPDATE CUENTAS SET SALDO = SALDO + importeWHERE CUENTA = ctaDestino;INSERTINTO MOVIMIENTOS     (CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO)VALUES     (ctaOrigen, ctaDestino, importe*(-1), SYSDATE);INSERTINTO MOVIMIENTOS     (CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO)VALUES     (ctaDestino,ctaOrigen, importe, SYSDATE);COMMIT;EXCEPTIONWHENOTHERSTHENdbms_output.put_line('Error en la transaccion:'||SQLERRM);dbms_output.put_line('Se deshacenlasmodificaciones);ROLLBACK;END; En la practica (Oracle pl/sql)

35. create or replace procedure prueba (nfilas number)asbeginsavepointninguna;insert intotmpvalues ('primerafila');savepointuna;insert intotmpvalues ('segundafila');savepoint dos;ifnfilas=1 thenrollback touna;else ifnfilas=2 thenrollback to dos;elserollback toninguna;end if;commit;exceptionwhen other then            rollbackendprueba; EN LA PRACTICA (ORACLE PL/SQL)