Download - DISEÑO DE BASE DE DATOS
![Page 1: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/1.jpg)
DISEÑO DE BASE DE DATOSTRANSACCIONES
![Page 2: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/2.jpg)
TRANSACCION
Colección de operaciones que forman una única unidad lógica de trabajo.
![Page 3: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/3.jpg)
PROPIEDAD DE UNA TRANSACCION
Atomicidad Consistencias Aislamiento -- Concurrencia Durabilidad
![Page 4: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/4.jpg)
ATOMICIDAD
Todas las operaciones de la transacción se realizan adecuadamente en la base de datos o ninguna de ellas
![Page 5: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/5.jpg)
CONSISTENCIA
La ejecución aislada de la transacción (sin otra que se ejecute concurrentemente) conserva la consistencia de la base de datos)
![Page 6: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/6.jpg)
AISLAMIENTO
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.
![Page 7: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/7.jpg)
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.
![Page 8: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/8.jpg)
PROPIEDADES ACID
Atomicity, Consistency, Isolation Durability
![Page 9: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/9.jpg)
ACCESO A LA BASE DE DATOS
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
![Page 10: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/10.jpg)
EJEMPLO
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).
![Page 11: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/11.jpg)
ANALIZANDO
Consistencia Que no sea alterado el balance de las
cuentas A y B al efectuar el traslado de fondos (transacción)
Responsabilidad: Programador
![Page 12: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/12.jpg)
ANALIZANDO
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
![Page 13: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/13.jpg)
ANALIZANDO
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?
![Page 14: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/14.jpg)
ANALIZANDO
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
![Page 15: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/15.jpg)
MODELOS DE ALMACENAMIENTO
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
![Page 16: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/16.jpg)
MODELOS DE ALMACENAMIENTO
Almacenamiento Secundario No volátil
Almacenamiento Primario Es volátil RAM
![Page 17: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/17.jpg)
PROCESAMIENTO
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)
![Page 18: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/18.jpg)
BLOQUE Y BUFFER
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
![Page 19: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/19.jpg)
BLOQUE Y BUFFER
Por lo regular si el DBMS pide un registro trae todo el bloque
El cual puede contener varios registros.
![Page 20: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/20.jpg)
MODELO DE TRANSACCION
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
![Page 21: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/21.jpg)
MODELO DE TRANSACCION
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
![Page 22: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/22.jpg)
MODELO DE TRANSACCION
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
![Page 23: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/23.jpg)
MODELO DE TRANSACCION
parcialmente comprometida
fallida
comprometida
abortada
activa
Consistente
Puede estar inconsistente
Con
sis
ten
te
Fallo
Fin
Commit
Rollback
Fallo
![Page 24: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/24.jpg)
IMPLEMENTACIÓN DE TRANSACCIONES SQL
En la norma SQL el comienzo de una transacción se especifica explícitamente (usualmente begin/start transaction)
Las transacciones terminan con una de las siguientes instrucciones:
commit work (compromete la transacción actual) rollback work (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
![Page 25: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/25.jpg)
IMPLEMENTACIÓN DE TRANSACCIONES SQL
Programa pagar_cheque Write (‘ingrese cuenta’) Read (cta) Write (‘valor’) Read (valor) Begin transaction
ReadDB (cta, saldo) Saldo = saldo – valor WriteDB (cta, saldo) Write DB (cheque, ‘P’)
Commit Write (‘Pague’)
![Page 26: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/26.jpg)
IMPLEMENTACIÓN DE TRANSACCIONES SQL
Begin transaction ReadDB (cta, saldo) If saldo >= valor then
Begin Saldo = saldo – valor WriteDB (cta, saldo) Commit Write (‘Pague’)
End Begin
WriteDB (histo, x) Commit
End
![Page 27: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/27.jpg)
MODELO DE FALLO
A
B
C
D
E
Tiempo de verificación Tiempo de fallo
![Page 28: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/28.jpg)
RECUPERACION DEL SISTEMA
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>
![Page 29: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/29.jpg)
BITACORA (LOG)
Archivo especial que no conviene tenerlo en el mismo disco o directorio donde esta la base de datos.
bitacora
Almacenamiento primario
Almacenamiento secundario
![Page 30: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/30.jpg)
BITACORA (LOG)Transaction T1•Begin transaction• ReadDB(A)• A = A + 5000• WriteDB(A)
•Commit
Transaction T2•Begin transaction• ReadDB(B)• ReadDB(C)• B= B – 1000• C = C + 1000• WriteDB(B)• WriteDB(C)
•Commit
Transaction T3•Begin transaction• ReadDB(D)• ReadDB(G)• D= D – 1000• G= G + 1000• WriteDB(D)• WriteDB(G)
•Commit
Transaction T4•Begin transaction• ReadDB(A)• A= A – 10,000• WriteDB(A)
•Commit
Transaction T5•Begin transaction• ReadDB(B)• B= B + 10,000• WriteDB(B)
•Commit
Cuenta A = 10,000Cuenta B = 5,000Cuenta C = 1,000Cuenta D = 10,000Cuenta E = 10,000Cuenta F = 3,000Cuenta G = 8,000
![Page 31: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/31.jpg)
PROBLEMAS DE CONCURRENCIA
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
![Page 32: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/32.jpg)
TÉCNICAS DE BLOQUEO (LOCK)
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)
![Page 33: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/33.jpg)
DEADLOCKS
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!
![Page 34: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/34.jpg)
EN LA PRACTICA (ORACLE PL/SQL) DECLARE
importe NUMBER; ctaOrigen VARCHAR2(23); ctaDestino VARCHAR2(23);BEGIN importe := 100; ctaOrigen := '2530 10 2000 1234567890'; ctaDestino := '2532 10 2010 0987654321'; UPDATE CUENTAS SET SALDO = SALDO - importe WHERE CUENTA = ctaOrigen; UPDATE CUENTAS SET SALDO = SALDO + importe WHERE CUENTA = ctaDestino; INSERT INTO MOVIMIENTOS (CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO) VALUES (ctaOrigen, ctaDestino, importe*(-1), SYSDATE); INSERT INTO MOVIMIENTOS (CUENTA_ORIGEN, CUENTA_DESTINO,IMPORTE, FECHA_MOVIMIENTO) VALUES (ctaDestino,ctaOrigen, importe, SYSDATE); COMMIT;EXCEPTION WHEN OTHERS THEN dbms_output.put_line('Error en la transaccion:'||SQLERRM); dbms_output.put_line('Se deshacen las modificaciones); ROLLBACK;END;
![Page 35: DISEÑO DE BASE DE DATOS](https://reader038.vdocuments.co/reader038/viewer/2022110213/568144f7550346895db1c3e2/html5/thumbnails/35.jpg)
EN LA PRACTICA (ORACLE PL/SQL)
create or replace procedure prueba (nfilas number)as begin savepoint ninguna; insert into tmp values ('primera fila'); savepoint una; insert into tmp values ('segunda fila'); savepoint dos; if nfilas=1 then rollback to una; else if nfilas=2 then rollback to dos; else rollback to ninguna; end if; commit; exception when other then rollbackend prueba;