1. Base de Datos:
PROCESAMIENTO DE
TRANSACCIONES Y SEGURIDAD
EN LAS BD
Profesor:
MSC.
MSC Luis Serna Jherry

2. Objetivos del Día de Hoy
Concurrencia
Recuperación
Seguridad

3. Procesamiento de Transacciones
Transacción A Transacción B
Traer R ($250)
tiempo
t
Traer R ($250)
Actualizar R=R-20 ($230)
A li R R 20
Actualizar R=R-30 ($220)
“El problema de la modificación perdida”

4. Procesamiento de Transacciones
Para mantener la integridad de la base de
datos en ambientes multiusuario, el sistema
,
relacional proporciona:
Facilidades para el Control de Transacciones
Mecanismos de Seguridad para el control de
concurrencias
Sistema de registro y recuperación para restaurar
la base de datos después de una falla del sistema.

5. Procesamiento de Transacciones
Transacción
Unidad lógica de trabajo (LUW) o procesamiento. Debe
ser t t l
totalmente completada o no realizada en absoluto.
t l t d li d b l t
Delimitado por declaraciones (o llamadas a función) de la
forma inicio de transacción y fin de transacción
La transacción consiste en todas las operaciones que se
ejecutan entre el inicio y el final de la transacción
Cuando una transacción no pudo ser completada el
servidor efectúa un rollback de la transacción incompleta,
removiendo toda evidencia de que comenzó alguna vez.

6. Procesamiento de Transacciones
Propiedades ACID:
Atomicidad: se realizan todas las operaciones de la transacción, o
p ,
ninguna de ellas. (Gestor de Transacciones)
Consistencia: La ejecución de la transacción conserva la
consistencia de la BD. La BD debe ser consistente antes y después de
una transacción ( programador de la aplicación)
Aislamiento (Isolation): Aunque se ejecuten concurrentemente,
cada transacción no afecta a ninguna otra, es decir ignora al resto
qu
que esté ejecutándose y no se puede ver a una transacción en su
j u á do o pu d u a a a ó u
estado intermedio. (Control de Concurrencia)
Durabilidad: Tras la finalización exitosa de una transacción, los
cambios en la BD permanecen, incluso si hay fallos en el sistema
(Gestor de recuperaciones)

7. Procesamiento de
Transacciones
“Transferir 1000 dól
“ f dólares de la cuenta R a la
d l l
cuenta P.”
Leer
Lee el registro de la cuenta R
egist o c enta
Actualizar el registro de la cuenta R , restándole 1000
dólares
Leer el registro de la cuenta P
Actualizar el registro de la cuenta P, sumándole 1000
dólares
Si fallara el último paso (p.ej. debido a una interrupción de la
corriente eléctrica) y los previos se hubieran ejecutado la
ejecutado,
BD perdería consistencia.

8. Procesamiento de Transacciones
2 retiros de 20 y 30
Transacción A
ó Transacción B
ó
Begin transaction
Leer R ($250)
L
Begin transaction
tiemp
esperar
po
Actualizar R=R-20 ($230) esperar
Commit esperar
Traer R ($230)
Actualizar R=R-30 ($200)
($ )
commit

9. Procesamiento de
Transacciones
T i
Incluyendo transferencia de R a P
Transacción A Transacción B
Leer R ($250)
($ )
Actualizar R= R-20 ($230)
tiemp
Leer R ($230)
po
Leer P ($600)
Actualizar R=R-30 ($200)
Actualizar P = P+20 ($620)
Leer P ($620)
Actualizar P = P+30 ($650)

10. Procesamiento de
Transacciones
• El componente del DBMS encargado de lograr la
culminación efectiva de las transacciones es conocido
como el Subsistema de Recuperación
CO
COMMIT
ROLLBACK

11. Transición de Estados de una
Transacción
T ansacción
Read/write
Parcialmente
Commit
confirmada
endTransaction Confirmada
Abort
Activa
Terminada
Abort
Fallida

12. Concurrencia: lanificadores
Conc encia Pl ifi d
Sean n transacciones, T1, T2, ..., Tn.
Las llamadas a la BD de Ti son ci1, ci2, ..., ciimii
Un planificador para T1, T2, ..., Tn es una disposición lineal
de las cijj que preserva el orden de las llamadas dentro de
cualquier transacción dada.
I.E. si
d1, d2, ... es un planificador y
planificador,
ds = cij, dt = cik, con j < k,
s<t

13. Concurrencia: Planificadores
C11: l R
leer
T1 T2 C12: actualizar R
C11: leer R C21: leer R C21: leer R
C12: actualizar R C22: actualizar R C13: leer P
C13: leer P C23: leer P C22: actualizar R
C14: actualizar P C24: actualizar P
C14: actualizar P
C23: leer P
Planificador
Las llamadas a la BD de Ti son ci1, ci2, ..., cimi C24: actualizar P

14. Concurrencia: Tipos de Planificadores
En Serie
No hay intercalación de las operaciones de las
transacciones en ejecución: primero T1 y después T2, o
viceversa
No en Serie
Las operaciones de las transacciones en ejecución se
intercalan de alguna manera
Seriable
Equivalente a algún plan en serie de las transacciones
en ejecución

15. Concurrencia
- Planificador Seriable -
Un planificador para transacciones T1, T2, ..., Tn es
seriable si existe una permuta (i1, i2, ..., in) de (1, 2, ...,
p ( , ( , , ,
n), tal que el estado de la BD que resulte de efectuar las
llamadas de BD en la secuencia del planificador es el
mismo que el alcanzado si se corren las transacciones en
aislamiento en el orden Ti1, Ti2, ..., Tin
El resultado será equivalente al de la ejecución en algún
orden arbitrario, escogido por la BD.

16. Concurrencia
- Prueba de Seriabilidad por Conflictos -
Dos operaciones de un plan están en
conflicto si cumplen las siguientes
p g
condiciones:
1. Pertenecen a diferentes transacciones
2. Tienen acceso al mismo elemento
3.
3 Al menos una de las operaciones es de
escritura

17. Concurrencia
- Prueba de Seriabilidad por Conflictos -
Crear un nodo Ti en el Grafo de Precedencia, para cada
transacción en el plan P
Cuando Tj ejecuta una orden read(X) después que Ti ejecute una
orden write(X) crear un arco (Ti Tj) en el grafo
Cuando Tj ejecuta una orden write(X) después que Ti ejecute una
orden read(X) crear un arco (Ti Tj) en el grafo
d d(X) l f
Cuando Tj ejecuta una orden write(X) después que Ti ejecute una
orden write(X) crear un arco (Ti Tj) en el grafo
El plan P es serializable si y solo si el grafo de precedencia no
tiene ciclos

18. Planes y sus Grafos de
Precedencia
T1 T2
PLAN A
Read X
X:= X-N
Write X T1 T2
tiempo Read Y
Y:= Y + N X
Write Y
Read X En T1 se transfieren reservas
X:= X + M de un avión a otro
Write X
En
E T2 simplemente se reserva
i l t
asientos en un avión

19. Planes y sus Grafos de
Precedencia
T1 T2
PLAN B
Read X X
X:= X + M
Write X
tiempo Read X T1 T2
X:= X-N
Write X
Read
R dY
Y:= Y + N
Write Y

20. Planes y sus Grafos de
Precedencia
T1 T2
PLAN C
Read X X
X:= X-N
Read X
tiempo X:= X + M T1 T2
Write X X
Read Y
Write X ***
Y:= Y + N ***ACTUALIZACION
Write Y PERDIDA: El valor de X
es incorrecto, el numero de
asientos es inconsitente

21. Planes y sus Grafos de
Precedencia
T1 T2
PLAN D
Read X
X:= X-N
Write X
tiempo Read X
ead T1 T2
X:= X + M
X
Write X
Read
R dY
Y:= Y + N
Write Y

22. Control de Concurrencia
Métodos estándar para garantizar la seriabilidad:
Bloqueos
Marcas de Tiempo
Multiversión
Validación o Certificación
(Protocolos optimistas)

23. Control de Concurrencia: Bloqueo
El bloqueo asegura que un objeto que va a ser utilizado por una transacción no
cambie de manera impredecible, si esto puede afectar la confiabilidad del
resultado. El efecto del bloqueo es no permitir que otras transacciones
tengan acceso al objeto.
Bloqueo Exclusivo:
Si una Transacción A tiene un bloqueo X sobre el objeto R cualquier otra
R,
Transacción B que solicite un bloqueo (de cualquier tipo) sobre R, entrará en
un estado de espera, hasta que A libere el bloqueo sobre R.
Bloqueo Compartido:
Si una Transacción A tiene un bloqueo S sobre el objeto R:
ó
Si otra Transacción B solicita un bloqueo X sobre R, entrará en un estado de
espera, hasta que A, libere a R.
Si en cambio B, solicita un bloqueo S, su solicitud será concedida
X: escritura, S:lectura

24. Control de Concurrencia
Bloqueo y operaciones sobre Registros
A X S
B
X N N
S N S
N: Hay conflicto, la transacción B entra en espera.
S: Compatibilidad, se concede el bloqueo solicitado por B

25. Protocolos de Bloqueo
Reglas que indican el momento en que una transacción
puede bloquear o desbloquear un elemento de la BD.
Si Ti solicita un bloqueo de un tipo M sobre un elemento
R, se le concede si:
No hay otra transacción con bloqueo sobre R que
esté en conflicto con M
No hay otra transacción esperando un bloqueo
sobre R, solicitado antes que T
Evita el fenómeno de inanición para Ti

26. Protocolos de Bloqueo
Bloqueo de dos fases:
Fase de Crecimiento: una transacción puede obtener
bloqueos pero no puede liberarlos ni rebajar su
intensidad
Fase de decrecimiento: una transacción puede liberar
bloqueos pero no puede obtener ninguno nuevo.
Si se retienen los bloqueos hasta completar la transacción
se conoce como bloqueo estricto de dos fases

27. Control de Concurrencia
Bloqueo Mutuo, Punto Muerto o Interbloqueo :
Transacción A Transacción B
Solicita bloqueo X sobre R1
- concedido -
Solicita bloqueo X sobre R2
q
tiempo
t
- concedido -
Solicita bloqueo X sobre R2
Esperar Solicita bloqueo X sobre R1
esperar esperar
esperar esperar
-------- --------

28. Control de Concurrencia
El problema de la “lectura sucia”.
Transacción A
ó Transacción B
ó
Leer R ($250)
Actualizar R= R-20 ($230)
tiempo
Leer R ($230)
o
rollback
Actualizar R=R-30 ($200)
commiti

29. Solución de bloqueo para la “lectura sucia”
Transacción A
ió Transacción B
ió
Obtener bloqueo S para R -
concedido
Leer R ($250)
Obtener bloqueo X para R –
concedido
tiempo
t
Actualizar R= R-20 ($230)
Obtener bloqueo S para R – esperar
rollback - esperar -
Bloqueo concedido
Leer R ($250)
L
Obtener bloqueo X para R -
concedido
Actualizar R=R-30 ($220)
commit

30. Control de Concurrencia
El problema de la “lectura irrepetible”
Transacción A
T ió Transacción B
T ió
Leer R ($250)
Leer R ($250)
tiempo
Actualizar R=R-30 ($220)
commitit
Leer R ($220)
¡interferencia detectada!

31. Solución de bloqueo para la “lectura irrepetible”
q p p
Transacción A Transacción B
Obtener bloqueo S para R –
concedido
Leer R ($250)
($ )
Obtener bloqueo S para R –
tiemp
concedido
Leer R ($250)
po
Obtener bloqueo X para R - esperar
Leer R ($250) esperar
(lectura repetible)
esperar
............... ....................

32. Control de Concurrencia
El problema de la aparición de “fantasmas”,
resumen incompleto o análisis inconsistente
Transacción 1 Transacción 2
Traer C1(40):Suma=40
(40):Suma 40
Traer C2(50):Suma=90
Traer C3(30)
tiempo
Actualizar C3(20)
Traer C1(40)
Actualizar C1(50)
A t li
COMMIT
Traer C3(20):Suma=110

33. Solución de bloqueo para el problema de la
aparición d “f
i ió de “fantasmas”
”
Transacción 1 Transacción 2
Obtener bloqueo S sobre C -
concedido
Traer C1(40):Suma=40
Traer C2(50):Suma=90
Obtener bloqueo X sobre C - esperar
Traer C3(30):Suma=120 Esperar
commit esperar
Conceder bloqueo
..............
..............

34. Control de Concurrencia
El bloqueo estricto de dos fases evita los problemas de lectura sucia,
lectura irrepetible y aparición de fantasmas, pero no evita el
punto muerto o iinterbloqueo
bl
Niveles de Aislamiento:
Especifican la cantidad de interferencia tolerable:
Lectura no Confirmada: Operación sin bloqueos y 3 violaciones
Lectura Confirmada: Bloqueo X para actualizaciones, sin
bloqueo S. Evita lectura sucia
S
Lectura Repetible: Bloqueos X y S (sobre objetos individuales).
Evita lectura sucia y no repetibles.
Serializable: Bloquea criterios de búsqueda que evitan lecturas
q q q
sucias, lecturas no repetibles ni fantasmas

35. Nivel de Aislamiento /
Interferencia
Nivel de Situación de Interferencia
Aislamiento Lectura sucia
L t i Lectura no
L t Fantasma
F t
repetible
Lectura no Posible Posible Posible
registrada
Lectura registrada No posible Posible Posible
Lectura repetible
L t tibl No
N posible
ibl No
N posible
ibl Posible
P ibl
Seriable No posible No posible No posible

36. Seriabilidad
S i bilid d por marcas temporales
t l
Asegura la secuencialidad asignando un orden entre
todo par de transacciones:
Por el reloj del sistema
Usando un contador lógico
Si la marca de MT(Ti) es menor que MT(Tj), asegura
que la planificación a ejecutar equivale a una
secuencial, con Ti antes que Tj
i l t
Asegura la ausencia de interbloqueos

37. Seriabilidad
S i bilid d por marcas temporales
t l
Se asocia a cada tupla dos valores de marca temporal:
tu es la marca temporal de la transacción más reciente
p
que ha actualizado o creado la tupla
tr es la marca temporal de la transacción más reciente
que h observado l tupla
ha b d la l
Obsérvese que siempre tu ≤ tr
(una transacción siempre observa la tupla antes de
actualizarla)

38. Seriabilidad
S i bilid d por marcas temporales
t l
Si la transacción t solicita leer una tupla:
Si t >= tu se ejecuta la operación leer y se actualiza
tr por max (t, tr )
Si t < tu una transacción más reciente (posterior en
el tiempo) ya escribió el valor de la tupla, antes de
que t tuviera oportunidad de leerla. T se retrocede y
vuelve a iniciarse con una marca t’ más grande.
l i i i á d

39. Seriabilidad
S i bilid d por marcas temporales
t l
Si t solicita actualizar una tupla:
Si t ≥ tr se ejecuta la actualización, dado que ninguna
transacción más reciente que t ha leído siquiera la tupla
Si t < tr ó t < tu se retrocede (rollback) la transacción t y se
reinicia con una marca temporal mayor, porque alguna
transacción posterior a t ya leyó o escribió la tupla antes de
que t pueda hacerlo
Si un rollback comprende la reinstalación de valores p
p previos, el
,
rollback debe tener una marca de hora nueva, que actualizará tu y
tr de la tupla reinstalada

40. Prevención de Interbloqueos
P ió d I t bl
Evitar esperas cíclicas, ordenando las peticiones de
bloqueo o exigiendo que todos los bloqueos se
adquieran juntos
Realizar retrocesos de las transacciones en lugar de
g
esperar un bloqueo, si éste puede llevar
potencialmente a un interbloqueo.

41. Prevención de interbloqueos
P ió d i t bl
Esperar o Morir
Si Ti solicita un elemento que posee Tj, Ti puede esperar sólo si Ti < Tj (Ti es
más antigua que Tj) en otro caso Ti se retrocede (muere)
Herir o Esperar
Si Ti solicita un elemento que posee Tj, Ti espera sólo si Ti > Tj (Ti es más
reciente que Tj); en otro caso Tj se retrocede (Ti hiere a Tj).
No-espera
Si Ti no puede obtener un bloqueo se aborta de inmediato y se reinicia
después de un cierto lapso sin comprobar si ocurriría o no un bloqueo mortal
Espera Cautelosa
E C t l
Si Ti solicita un elemento que posee Tj, Ti espera sólo si Tj no está detenida
(no está esperando que se libere ningún otro elemento bloqueado); en caso
contrario Tj aborta.
aborta

42. Recuperación
ó
Transaction Log
T i L
Es una tabla del catálogo de la BD. Contiene una
lista
li t secuencial de todas las modificaciones a cada
i ld t d l difi i d
objeto dentro de la BD (bitácora), así como también
toda la información necesaria para mantener la
integridad de los datos.
Es compartido por todos los usuarios de una BD
BD.
Los datos se escriben primero en esta tabla y luego
en las tablas correspondientes de la BD.

43. Transaction Log
Programa de
Se modifican
Aplicación los datos
(a) Transaction
(a) (b)
Log
(b)
DBMS
(a) ante-imagen
Acceso (b) post-imagen
Actualización
de los datos
Base de
Datos

44. Recuperación
Transaction Log con actualizaciones diferidas:
Cuando comienza una transacción T se registra su inicio
g
en el log
Durante la transacción, la escritura de un nuevo valor para
cualquier registro provoca la escritura de un registro en el
log.
Cuando todas las acciones de T se ejecutan exitosamente,
j ,
se escribe el registro COMMIT en el log
Por último, se realizan las operaciones de escritura en la
BD desde los registros del log

45. Recuperación
Recuperación con actualizaciones diferidas:
Cuando ocurre un fallo, el DBMS examina el log para
, gp
determinar las transacciones que deben rehacerse
(REDO):
Si el log registra el inicio y el fin de la transacción T (hasta
el commit), significa que la transacción T se debe volver a
aplicar.
Si no figura el commit en el log, la transacción T no se
completó, y al reiniciar no es necesario tomar acción, pues
la BD permanece consistente T tiene que reiniciarse
consistente. reiniciarse.

46. Recuperación
Transaction Log con actualizaciones
inmediatas:
1° Cuando comienza una transacción T se registra su inicio
en el log
g
2° Durante la transacción, la escritura de un nuevo valor
para cualquier registro provoca la escritura de un registro
en el log (primero) y luego en la BD
ll ( i ) l l
3° Cuando todas las acciones de T se ejecutan exitosamente,
se esc be e registro CO
escribe el eg st o COMMIT e e log
en el og

47. Recuperación
Recuperación con actualizaciones inmediatas:
Cuando ocurre un fallo, el DBMS examina el log para
determinar las transacciones que deben rehacerse (REDO)
o deshacerse (UNDO):
Si el log registra el inicio y el fin de la transacción T (hasta
el commit), significa que la transacción T se debe volver a
aplicar (REDO)
Si no figura el commit en el log, la transacción T no se
completó, y al reiniciar es necesario restablecer los valores
antiguos de los datos (UNDO). T tiene que reiniciarse.

48. Recuperación de la BD
Progresiva: Se restaura el último backup y se aplican
luego todas las transacciones válidas desde la bitácora,
aplicando las imágenes posteriores (post-imágenes).
Regresiva: Se deshacen los cambios efectuados por
transacciones erróneas o procesadas parcialmente,
mediante la aplicación de las imágenes anteriores. Las
transacciones válidas que estaban en proceso al momento
de la falla se vuelven a iniciar.

49. Recuperación
Recuperación del Sistema y de los Medios de
Almacenamiento
• Fallas del Sistema (por ejemplo corte del fluido eléctrico), las cuales
afectan a todas las transacciones que se están efectuando pero no dañan
los datos físicos en la base de datos.
• Fallas de los medios de almacenamiento (por ejemplo pérdida de
direcciones o pistas dañadas), que sí causan daño a la base de datos o a
una porción de ella.
• Falla computador (error de hardware o de software);
• Error en transacción (división entre 0, overflow, malos parámetros, etc.);
• Catástrofes.

50. Recuperación
p
- Fallas del Sistema -
Se pierde el contenido de la memoria principal y de las áreas de
almacenamiento temporal. Por lo tanto, se perderá el estado preciso de la
transacción que se está ejecutando y no podrá ser completada con éxito.
Por este motivo será preciso anularla (retroceder) cuando se reinicie el
p ( )
sistema (aplicación de los registros ante-imagen desde el Log de
transacciones).
Para reducir este proceso, se introducen periódicamente Puntos de
Revisión o Verificación.

51. Recuperación
Fallas del Sistema
Punto de Revisión (checkpoint):
• Detiene el inicio de nuevas transacciones
• Escribe todos los registros del log de transacciones que radican
en la memoria volátil (los buffers de la memoria principal), en
almacenamiento estable (en disco)
• Graba físicamente un registro de Punto de Revisión especial en
la bitácora física. Este incluye una lista de todas las
física
transacciones en ejecución en ese momento.
• Reactiva las transacciones en ejecución

52. Recuperación
tv tf
T1
T2
T3
T4
T5
Punto de Falla del
verificación Sistema
• Deberá anularse las transacciones T3 y T5 (UNDO)
• D b á aplicarse nuevamente las transacciones T2 y T4 (REDO)
Deberá li t l t i
• La transacción T1 no interviene en el proceso de reinicio, porque
sus modificaciones ya estaban grabadas en la BD en el momento
y g
tv, como parte del proceso de punto de revisión.

53. Recuperación
Fallas de los Medios de Almacenamiento
Se pierden direcciones del disco o se producen averías en las
p
pistas o falla el controlador del disco. La consecuencia es la
destrucción física de una porción de la base de datos.
La recuperación de una falla semejante, implica en esencia,
cargar d nuevo o restaurar (restore) la base de datos a partir de
de t ( t )l b d d t ti d
una copia de respaldo (backup) y después utilizar el transaction
log, para realizar de nuevo todas las transacciones terminadas
desde que se efectuó este último backup (aplicación de los
registros post-imagen)

54. Seguridad en Bases de Datos
Seguridad en la BD implica asegurar que los usuarios
están autorizados para llevar a cabo las tareas que tratan de
realizar
Subsistema de Seguridad del DBMS
Aspectos éticos y legales relativos al derecho de acceso a cierta
información
Políticas gubernamentales o institucionales relacionadas con la
clase de información que no debe estar disponible para el público,
como la clasificación de crédito o el historial médico: la empresa
decide ié
d id quiénes tienen acceso y a qué.
i é
Identificación de niveles de seguridad y de clasificar los datos y
usuarios según estos niveles: top secret, secreto, confidencial, no
confidencial

55. Seguridad en el DBMS
Mecanismos de Seguridad:
Discrecionales: conceden privilegios a los usuarios para
acceder a elementos específicos de la BD en un
determinado modo (lectura, escritura o actualización)
Obligatorios: imponen seguridad de múltiples niveles
Obli t i i id d d úl i l i l
clasificando los datos y los usuarios. Permitir a los
usuarios de cierto nivel acceder a los elementos de
información de su mismo nivel o de niveles inferiores

56. La seguridad de la BD y el
DBA
Creación de Cuentas
Para crear cuentas y contraseñas para un usuario o
grupo con el fin de que puedan acceder al DBMS
Concesión de Privilegios
g
Para conceder (GRANT) ciertos privilegios
(authority) a ciertas cuentas
Revocación de privilegios (REVOKE)
ó
Asignación de niveles de seguridad
Asigna cuentas de usuario al nivel de clasificación
de seguridad apropiado

57. Protección de Acceso y Auditoría
de la
d l BD
Cuando un usuario entra (log in), el DBMS puede
registrar su nombre y asociarlo al terminal de donde
se conectó. Todas las operaciones sobre la BD de ese
terminal se asocian a la cuenta del usuario hasta que
q
éste salga del sistema.
Se puede modificar el log de transacciones (diario del
sistema), ampliando las entradas para incluir la cuenta
it ) li d l t d i l i l t
de usuario y el terminal desde donde se aplicó cada
operación. El diario del sistema se denomina en esos
p
casos diario de auditoría

58. Privilegios Discrecionales
A Nivel de Cuenta
Se asignan a cada cuenta de usuario,
g ,
independientemente de las relaciones de la BD
Ejemplos: CREATE, ALTER, DROP, MODIFY, SELECT
A Nivel de Relación (o tabla):
Controla privilegios para acceder a cada relación
individual de la base de datos o a columnas
concretas de ellas.
Ejemplos: SELECT (lectura), MODIFY (update, insert,
j p ( ), ( p , ,
delete)

59. Seguridad – Consideraciones
Adicionales
Controles Físicos: Límite de accesos a la sala de
máquinas (servidores).
(servidores)
Problemas Operativos: Mantenimiento de los passwords,
su confidencialidad y tiempo de validez.
p
Controles del equipo: Claves para protección de áreas de
almacenamiento.
Seguridad de Sistema Operativo: Mantenimiento de los
d dd d l
espacios de almacenamiento, compactación.

60. Bibliografia
Fundamentos de Sistemas de Base de
Datos. Ramez Elmasri, Shamkant
Navathe