pract4 transacciones

12
Práctica 4: Estudio del SGBD Oracle 10 Gestión de Transacciones El SGBD Oracle 10 Objetivos estudio de la gestión de transacciones. estudio de las estrategias para la comprobación de la integridad. estudio de las estrategias para el control de la concurrencia

Upload: rmacetas2047

Post on 26-Dec-2015

6 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: pract4 transacciones

1

Práctica 4: Estudio del SGBD Oracle 10Gestión de Transacciones

El SGBD Oracle 10Objetivos

•estudio de la gestión de transacciones.•estudio de las estrategias para la comprobación de la integridad.

•estudio de las estrategias para el control de la concurrencia

Page 2: pract4 transacciones

2

Secuencia de operaciones de acceso a la base de datos que constituyen una unidad lógica de ejecución

TRANSACCIÓN

Las operaciones de acceso a una BD se organizan en transacciones

El SGBD ORACLE 10

Empleado (dni, nombre, dir, dpto)CP: {dni} VNN={dpto}CAj: {dpto} → Departamento f(dpto)=código

Departamento (código, nombre, ubicación)CP: {código}

R1: "∀Dx (Departamento(Dx) →

∃Ex (Empleado(Ex) ∧ Dx.código = Ex.dpto ) )

Actualización de la BD:

“Inserción de un nuevo departamento <d2,“Personal”, “Planta 3ª”> y asignación al mismo del empleado de dni 20456 (ya existente en la base de datos)”

Gestión de Transacciones

Page 3: pract4 transacciones

3

1) Inserción en Departamento: <d2, “Personal”, “Planta 3ª”>

2) Modificación en Empleado: modificación del atributo dpto del empleado con dni 20456

1) Modificación en Empleado: modificación del atributo dpto del empleado con dni 20456

2) Inserción en Departamento: <d2, “Personal”, “Planta 3ª”>

ERROR: la restricción R1 no se cumple

ERROR: la restricción de CAj. no se cumple

¡ necesidad del concepto de transacción !

Gestión de Transacciones

INICIO T1

INSERT INTO Departamento VALUES (d2, “Personal”, “Planta 3ª”)

UPDATE Empleado SET dpto=d2 WHERE dni=20456

FIN T1

las restricciones se comprueban al final de la transacciónla transacción es rechazada si alguna restricción se viola

Gestión de Transacciones

Page 4: pract4 transacciones

4

Gestión de Transacciones

Grafo de transiciones de estado de una transacción

activa confirmada

fallada terminada

confirmada parcialmentefininicio

anulaciónanulación

confirmación

usuario

SGBD

usuario

SGBD

SGBD

usuario

Propiedades que deben cumplir las transacciones:•atomicidad: una transacción es una unidad atómica de ejecución (o se ejecutan todas sus operaciones o ninguna).

•consistencia: la transacción debe conducir la BD de un estado consistente a otro estado consistente (se cumplen todas las restricciones de integridad).

•aislamiento: una transacción no debe hacer visibles sus cambios a otras transacciones hasta que es confirmada.

•persistencia: cuando una transacción es confirmada sus cambios deben ser grabados en la BD y no deben perderse debido a fallos de otras transacciones o del sistema.

Gestión de Transacciones

Page 5: pract4 transacciones

5

Definición de transacciones en SQL:INICIO: no existe una instrucción para definir el inicio de una transacción. (INICIO implícito).

FIN (con confirmación): COMMIT [WORK ] (transacción confirmada parcialmente)

FIN (con anulación): ROLLBACK [WORK ] (transacción anulada)

Gestión de Transacciones

En SQL no se pueden anidar las transacciones.

[[NOT] DEFERRABLE]

[INITIALLY {IMMEDIATE | DEFERRED}]

Comprobación de la integridad en SQL:

Punto de comprobación de la integridad (se define para cada restricción del esquema):

después de cada operación SQL (IMMEDIATE)

al final de la transacción (DEFERRED) .

El punto de comprobación de una restricción puede ser fijo (NOT DEFERRABLE) o se puede cambiar dinámicamente durante la ejecución de una transacción (DEFERRABLE).

Gestión de Transacciones

Page 6: pract4 transacciones

6

La semántica de cada una de las versiones de la cláusula es: - si no se utiliza esta cláusula la restricción se define como no diferible y con modo inmediato. - la versión DEFERRABLE INITIALLY IMMEDIATE (resp. DEFERRED) define una restricción como diferible y con modo por defecto inmediato (resp. diferido). - la versión NOT DEFERRABLE INITIALLY IMMEDIATE coincide con los valores por defecto.- la versión NOT DEFERRABLE INITIALLY DEFERRED estáprohibida. - la versión DEFERRABLE (resp. NOT DEFERABLE) define una restricción como diferible (resp. no diferible) y con modo por defecto inmediato.- la versión INITIALLY IMMEDIATE define una restricción como no diferible y con modo inmediato.- la versión INITIALLY DEFERRED define una restricción como diferible y con modo inicial diferido.

Gestión de Transacciones

La instrucción SQL que permite cambiar, localmente en una transacción, el modo de una restricción definida como diferible (DEFERRABLE), es:

SET CONSTRAINT {nombre_restricción,... | ALL}{IMMEDIATE | DEFERRED}

Cada restricción especificada en la lista debe ser diferible y la opción ALL hace referencia a todas las restricciones diferibles del esquema de la base de datos.El alcance del cambio producido por la instrucción SET CONSTRAINT es la transacción en la que se incluye o el fragmento de transacción hasta la siguiente aparición de la misma instrucción.Si se incluye la instrucción en medio de la transacción con la opción IMMEDIATE, las restricciones afectadas por la instrucción son comprobadas cuando se ejecuta ésta, si alguna de estas restricciones falla, la instrucción SET falla y el modo de las restricciones permanece sin modificar.

Gestión de Transacciones

Page 7: pract4 transacciones

7

Gestión de TransaccionesEmpleado (dni, nombre, dir, dpto)

CP: {dni} VNN={dpto}CAj: {dpto} → Departamento f(dpto)=código

Departamento (código, nombre, ubicación)CP: {código}

R1: "∀Dx (Departamento(Dx) →

∃Ex (Empleado(Ex) ∧ Dx.código = Ex.dpto ) )

Actualización de la BD:“Inserción de un nuevo departamento <d2,“Personal”, “Planta 3ª”> y asignación al mismo del empleado de dni 20456 (ya existente en la base de datos)”

Gestión de TransaccionesCREATE TABLE Empleado(dni char(10) CONSTRAINT cp_socio PRIMARY KEY INITIALLY IMMEDIATE,nombre varchar2 (60)

CONSTRAINT emp_nulo NOT NULL INITIALLY IMMEDIATE,dir varchar2 (50),dpto char(5) CONSTRAINT dpto_nulo NOT NULL INITIALLY IMMEDIATECONSTRAINT caj_emp_dpto REFERENCES Departamento (codigo)

INITIALLY DEFERRED );

CREATE TABLE Departamento(codigo char(5) CONSTRAINT cp_dpto PRIMARY KEY INITIALLY IMMEDIATE,nombre varchar2 (50)

CONSTRAINT nombre_nulo NOT NULL INITIALLY IMMEDIATE,ubicación varchar2 (15),CONSTRAINT dpto-emp CHECK (NOT EXISTS (SELECT * FROM Departamento D

WHERE NOT EXISTS (SELECT * FROM Empleado EWHERE E.dpto=D.codigo)

INITIALLY DEFERRED);

Page 8: pract4 transacciones

8

INSERT INTO Departamento VALUES (d2, “Personal”, “Planta 3ª”)

SGBD: comprobación de las RI: cp_dpto, nombre_nulo

UPDATE Empleado SET dpto=d2 WHERE dni=20456

SGBD: comprobación de la RI: dpto_nulo

COMMIT WORK

SGBD: comprobación de las RI: caj_emp_dpto, dpto_emp

Actualización de la BD:“Inserción de un nuevo departamento <d2,“Personal”, “Planta 3ª”> y asignación al mismo del empleado de dni 20456 (ya existente en la base de datos)”

Transacción confirmada por el SGBD: sus cambios serán aplicados a la BD

Gestión de Transacciones

INSERT INTO Departamento (codigo, ubicación)

VALUES (d5, “Planta 2ª”)

SGBD: comprobación de la RI: cp_dpto,

comprobación de la RI: nombre_nulo

SGBD → ANULAR (transacción)

Actualizaciones de la BD:

transacción fallada por el SGBD: sus cambios que ya han sido grabados serán deshechos.

Gestión de Transacciones

Page 9: pract4 transacciones

9

INSERT INTO Departamento (codigo, nombre, ubicación)

VALUES (d8, “Proyectos”, “Planta 1ª”)

SGBD: comprobación de las RI: cp_dpto, nombre_nulo

COMMIT WORK

SGBD: comprobación de las RI: dpto_emp

SGBD → ANULAR (transacción)

Actualizaciones de la BD:

Gestión de Transacciones

transacción fallada por el SGBD: sus cambios que ya han sido grabados serán deshechos.

Transacciones diferibles:Gestión de Transacciones

CREATE SCHEMA esquema1

.....

CREATE ASSERTION R1 CHECK ( )

DEFERRABLE INITIALLY IMMEDIATE

.....

Page 10: pract4 transacciones

10

Transacciones diferibles:

Gestión de Transacciones

Instrucción(1)-SQL

....

Instrucción(i)-SQL (relevante para R1)

SGBD: comprobación de R1

....

COMMIT WORK

ANULAR(transacción)viola R1

satisface R1

Transacción T1

Transacciones diferibles:Gestión de Transacciones

SET CONSTRAINT R1 DEFERRED

Instrucción(1)-SQL

....

Instrucción(i)-SQL (relevante para R1)

....

COMMIT WORK

SGBD: comprobación de R1ANULAR(transacción)viola R1

satisface R1

CONFIRMAR (transacción)

Transacción T2

Page 11: pract4 transacciones

11

Definición de transacciones en ORACLE:INICIO: en el uso interactivo una transacción se inicia con la primera instrucción SQL ejecutada desde que finalizó la última transacción o desde que se inició la sesión. (INICIO implícito).

FIN (con confirmación): COMMIT [WORK ] (transacción confirmada parcialmente)

FIN (con anulación): ROLLBACK [WORK ] (transacción anulada)

FIN (implícito): cierre de la sesión (confirmada parcialmente) o anulación del SGBD (anulada)

Gestión de Transacciones

Comprobación de la integridad en ORACLE:La sintaxis de ORACLE para la definición del punto de comprobación de una restricción coincide con la sintaxis de SQL, con las siguientes excepciones:

restricción con modo inmediato (IMMEDIATE): se anula la operación SQL que ha provocado la violación. (statement rollback)

restricción con modo diferido (DEFERRED): se anula la transacción que ha provocado la violación. (transaction rollback)

Gestión de Transacciones

Page 12: pract4 transacciones

12

Práctica nº 4: Estudio del SGBD ORACLE10Gestión de transacciones.

Ejercicios