Академический Документы
Профессиональный Документы
Культура Документы
ESCUELA DE CIENCIAS DE LA
COMPUTACIN E INFORMTICA
Elaborado por
Dra. Elzbieta Malinowski G.
Bases de Datos II: Material de apoyo by Dra. Elzbieta Malinowski Gajda is licensed under a
Creative Commons Attribution-NonCommercial 3.0 Costa Rica License.
Permissions beyond the scope of this license may be available at http://creativecommons.org.
Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica
PARTE I
PROCESAMIENTO Y OPTIMIZACIN DE CONSULTAS
El procesamiento de las consultas requiere varios pasos como se muestra en la
figura 1.1.
Validacin
Revisa si los nombres de las tablas y los atributos son los nombres existentes en
la BD.
Optimizador de consultas
De los posibles planes de ejecucin de la consulta se escoge uno que es el
mejor con respecto a los criterios aplicados (una estrategia razonablemente
eficiente).
Algunos ejemplos:
(OP1): NSS=123456789 (EMPLEADO)
(OP2): NUMEROD>5 (DEPARTAMENTO)
(OP3): ND=5 (EMPLEADO)
(OP4): ND=5 AND SALARIO> 30000 AND SEXO=F (EMPLEADO)
(OP5): NSSE=123456789 AND NUMP=10 (TRABAJA_EN)
Bsqueda lineal:
Se revisa registro por registro y se comprueba si el valor de sus atributos
satisface la condicin de seleccin.
Bsqueda binaria:
Se usa cuando la condicin contiene el smbolo de igualdad en la llave de
ordenamiento, por ejemplo, la consulta OP1 si NSS es un atributo de ordenacin
del archivo.
Condiciones compuestas:
Si una de las condiciones tiene posibilidad de usar alguna de las tcnicas
presentadas anteriormente, sela y revise la otra condicin.
Aplique la interseccin de los punteros a los registros, despus de
seleccionar por separado los registros que cumplen cada una de las
condiciones.
Si uno o ms atributos estn involucrado en la condicin compuesta y
existe el ndice compuesto con respecto a estos campos, selo.
R A=B S
Existen varias tcnicas para implementar la operacin join de dos tablas (two-
way join); conozcamos algunas de estas tcnicas:
Sort-merge join
Si las relaciones R y S estn fsicamente ordenadas por el valor del campo de
join, se revisan los dos archivos en el orden de los atributos del join,
seleccionando las tuplas que igualan sus valores en sus respectivos campos. Si
no existe ordenamiento, se necesita ordenar primero los dos archivos
Hash-join
Se pasa por el archivo que contiene menos registros (suponga R) aplicndole la
funcin hash para cada uno de los registros y ponindolos en las respectivas
cubetas en la memoria principal. Despus se aplica la funcin hash registro por
registro de la otra relacin S y se hace join con los registros de R que residen en
la misma cubeta.
Hybrid-hash join
En esta tcnica se supone que ninguna de las tablas cabe en la memoria
principal. Primero se aplica hash a la relacin R grabando cada uno de las
cubetas en archivos separados. Se repite este proceso para la relacin S.
Finalmente, se lee cubeta por cubeta y se aplica join para los registros de R y S
pertenecientes a la misma cubeta.
for each row in R produce a hash
assign the hash to hash bucket on disk
for each in S produce hash
assign the hash to hash bucket on disk
for each hash bucket with the same hash value of R and S
apply join
El resultado del join externo son todas las tuplas que tienen los valores comunes
en el atributo de join y las dems tuplas que estn especificadas en la clusula
de outer join (left o right).
Figura 1.2. Dos variantes de rbol lineal para la ejecucin de mltiples joins.
En este rbol el hijo derecho de cada nodo que no es hoja es siempre una
relacin. Tambin existe otro tipo de rbol, llamado bushy, que contiene nodos
hojas como relaciones, como se puede ver en la figura 1.3.
R1 R2 R3 R4
Figura 1.3. rbol bushy para la ejecucin de mltiples joins.
OPERACIONES DE CONJUNTOS
OPERACIONES DE SUBCONSULTAS
SELECT *
FROM Table1
WHERE Table1.column1 IN /* = ANY */
(SELECT Table2.column1
FROM Table2
WHERE Table2.column2 = 3);
Ejemplo de la BD COMPAA
SELECT P.NUMEROP
FROM PROYECTO P
WHERE P.NUMEROP
IN (SELECT T.NUMP
FROM TRABAJA_EN T, EMPLEADO E
WHERE T.NSSE=E.NSS AND E.APELLIDO= Silva);
SELECT *
FROM Table1
WHERE Table1.column1 IN /* = ANY */
(SELECT Table2.column1
FROM Table2
WHERE Table2.column1 = Table1.column1
AND Table2.column2 = 3);
Ejemplo de la BD COMPAA
Flattening (aplanar):
Transformar la consulta en join y despus procesar los join. Se aplica a
las subconsultas anidadas y correlacionadas. Por ejemplo, las consultas
anteriores se pueden escribir de la siguiente forma:
SELECT Table1.*
FROM Table1, Table2
WHERE Table1.column1 = Table2.column1
AND Table2.column2 = 3;
Los operadores de agregacin, como por ejemplo, MAX, COUNT, AVG, SUM
cuando se aplican a una tabla completa, se pueden calcular mediante la
exploracin de la tabla o utilizando el ndice apropiado. Por ejemplo,
SELECT MAX(Edad)
FROM Empleado;
OPTIMIZACIONES DE CONSULTAS
Los optimizadores de consultas transforman la consulta original en la versin
alternativa que mejora el tiempo de ejecucin de acuerdo a las reglas
especficas. Estos optimizadores pueden ayudar al implementador a mejorar el
desempeo del sistema. Sin embargo, en muchas ocasiones es necesario
tambin ajustar el sistema (tuning), esto implica la revisin de la estructura fsica,
las aplicaciones, los accesos, la configuracin del servidor y las conexiones,
OPTIMIZACIN HEURSTICA
Ejemplo:
Para entender mejor las heursticas en forma general, se presenta otra consulta
y la transformacin del rbol usando el sentido comn y recordando que el
objetivo es crear la menor cantidad de resultados intermedios posibles.
Consulta: Buscar los apellidos de los empleados nacidos despus de 1957 que
trabajan en el proyecto Acuario:
SELECT apellido
FROM EMPLEADO, TRABAJA_EN, PROYECT
WHERE nombrep = Acuario AND numerop = nump AND nsse = nss
AND fechanac > 31-DIC-57;
Las siguientes son las presentaciones del rbol cannico y sus sucesivas
transformaciones hasta llegar al rbol final:
c1 (c2(R)) c2 (c1(R))
Ejemplo
ND=3(Salario>40000 (Empleado) (salario>40000 (nd=3 (Empleado) )
R c SS c R
Ejemplo
Empleado ND=NumeroD Departamento Departamento ND=NumeroD Empleado
L(R cS)
L((A1, ..., An, An+1, ..., An+k (R)) c (B1, ..., Bm, Bm+1, ..., Bm+p (S)))
Ejemplo
Nombre,Apellido,NombreD(Empleado Nd=NumeroDDepartamento)
Nombre,Apellido,NombreD(Nombre,Apellido,ND (Empleado)) Nd=NumeroD
(NumeroD,NombreD(Departamento))
Usando como base estas reglas, se establecen algunas pautas que se usan en
los algoritmos de optimizacin de consultas. Como por ejemplo:
En general se puede decir que la regla es aplicar primero estas operaciones que
reducen el tamao de la relacin intermedia. Esto incluye la ejecucin de la
operacin de seleccin para reducir el nmero de tuplas en la relacin temporal
y la ejecucin de la operacin de proyeccin para reducir el nmero de atributos.
Algunos ejemplos:
(OP1): NSS=123456789 (EMPLEADO)
(OP2): NUMEROD>5 (DEPARTAMENTO)
(OP3): ND=5 (EMPLEADO)
(OP4): ND=5 AND SALARIO> 30000 AND SEXO=F (EMPLEADO)
(OP5): NSSE=123456789 AND NUMP=10 (TRABAJA_EN)
Bsqueda lineal:
Descripcin: Se revisa registro por registro y se comprueba si el valor de
sus atributos satisface la condicin de seleccin.
Estimacin del costo: igual al nmero de bloques (c = b). En promedio se
necesitan tener b/2 accesos si se localiza el registro y b accesos, si
ningn registro satisface la condicin.
Bsqueda binaria:
Descripcin: Se usa cuando la condicin contiene el smbolo de
igualdad en la llave de ordenamiento, por ejemplo, la consulta OP1 si
NSS es un atributo de ordenacin del archivo.
Estimacin de costo: c = log2 b + (s/bfr). Si la llave es nica el costo
es c= log2 b +1.
Sort-merge join
Descripcin: Si las relaciones R y S estn fsicamente ordenadas por el
valor del campo de join, se revisan los dos archivos en el orden de los
atributos del join, seleccionando las tuplas que igualan sus valores en sus
respectivos campos. Si no existe ordenamiento, se necesita ordenar
primero los dos archivos.
Hash-join
Descripcin: Se pasa por el archivo que contiene menos registros
(suponga R) aplicndole la funcin hash para cada uno de los registros y
ponindolos en las respectivas cubetas en la memoria principal. Despus
se aplica la funcin hash registro por registro de la otra relacin S y se
hace join con los registros de R que residen en la misma cubeta.
Hybrid-hash join
Descripcin: En esta tcnica se supone que ninguna de las tablas cabe
en la memoria principal. Primero se aplica hash a la relacin R grabando
cada una de las cubetas en archivos separados. Se repite este proceso
para la relacin S. Finalmente, se lee cubeta por cubeta y se aplica join
para los registros de R y S pertenecientes a la misma cubeta.
Nested Loop:
a) Se dispone de 2 buffers, uno para cada relacin
ndice secundario
ndice secundario
3) Merge Join
MergeSort MergeSort
Empleado Departamento
4) Hash
Si una de las relaciones cabe en el buffer de la memoria:
bE + bD = 2000+10 =2010
OPTIMIZACIN SEMNTICA
Ejemplo:
SELECT E.apellido, G.apellido
FROM EMPLEADO E, EMPLEADO G
WHERE E.nsssuper = G.nss AND E.salario > G.salario;
Esta consulta despliega los nombres de los empleados que ganan ms que sus
gerentes. Sin embargo, si se tiene una restriccin donde se especifica que
ningn empleado puede ganar ms que el gerente, el optimizador semntico de
consultas podra verificar primero esta restriccin y no necesita ejecutar la
consulta, porque sabe que el resultado est vaco.
PARTE II
PROCESAMIENTO DE LAS TRANSACCIONES
Transaccin
Ejecucin de una o varias operaciones que accedan o cambian el contenido de
la base de datos dejndola en estado consistente. Los lmites de una
transaccin se establecen por medio de las sentencias de
BEGIN_TRANSACTION y END_TRANSACTION. Las transacciones pueden
formar parte de una aplicacin o especificarse implcitamente.
Aunque las transacciones pueden incluir varias operaciones sobre los datos, de
nuestro inters son READ y WRITE, que permiten, respectivamente, leer los
datos desde la BD y escribirlos.
Ejemplos:
READ(A); READ(A);
A = A - N; A = A + M;
WRITE(A); WRITE(A);
READ(B);
B = B + N;
WRITE(B);
READ(X) WRITE(X)
1. Encuentra la direccin de X en la 1. Encuentra la direccin del bloque
base de datos. que contiene X.
2. Copia del disco al buffer de la 2. Si el bloque que contiene X no se
memoria principal el bloque que encuentra en la memoria principal, lo
contiene X. copia desde el disco al buffer de la
memoria (o sea, ejecuta una especie
de operacin read internamente).
3. Copia el dato X desde del buffer a la 3. Copia la variable del programa al
variable del programa llamada X. buffer que contiene el dato X.
4. Guarda el bloque modificado al
disco (actualiza la BD en disco).
UCP1
UCP2
tiempo
Figura 2.2. Concurrencia en ambiente multiusuario.
Ejemplo:
T1 T2
READ(X);
T
i X = X - N;
e READ(X);
m X = X + M;
p WRITE(X);
o
READ(Y);
WRITE(X);
Y = Y + N;
WRITE(Y);
2. Dirty read (lectura sucia): una transaccin lee el valor de la otra mientras la
ltima aborta su ejecucin; existe la dependencia write read entre las dos
transacciones.
Ejemplo:
T1 T2
READ(X);
T X = X - N;
i WRITE(X);
e
m
READ(X);
p X = X + M;
o WRITE(X);
READ(Y);
abort
T1 T2
READ(X);
T PRINT(X);
i READ(X);
e
m
X = X + M;
p WRITE(X);
o READ(X);
PRINT(X);
Ejemplo:
T1 T2
SELECT * FROM Table1 UPDATE Table1 SET column2 = 10
WHERE column1 = 5 SET column1 = 5
WHERE column1 = 8
5. Fallo del disco: Partes del disco que perdien datos por causa de las fallas
fsicas.
PARTE III
CONTROL DE CONCURRENCIA
Las tcnicas de control de concurrencia permiten las planificaciones
serializables, recuperables y sin la anulacin en cascada (cascadeless)
ofreciendo un conjunto de reglas llamado protocolo. Existe una gran variedad
de protocolos basados en:
Candados: bloquean los elementos de datos antes de operar sobre ellos
para evitar que otras transacciones accedan los mismos elementos.
Marcas de tiempo: asignan un identificador nico a cada transaccin y
ordenan las operaciones sobre los datos de acuerdo a estas marcas
permitiendo o evitando su ejecucin.
Multiversin: utilizan varias versiones del mismo elemento.
Validacin (optimistas): se realizan operaciones sobre copias de datos y
se comprueba su posible confirmacin antes de terminar la transaccin.
CANDADOS
Candados (bloqueos, locks) es una variable asociada al dato en la base de
datos que describe el estatus de este dato con respecto a las posibles
operaciones de read y write. El sistema operativo maneja los candados pero
distingue solo dos estados: lock y unlock. En la base de datos tenemos por lo
menos tres diferentes estados:
Cada transaccin que ocupa leer un dato o escribir sobre el debe solicitar un
candado adecuado. Solo los candados S son compatibles, o sea, dos
transacciones pueden tener el candado S sobre el mismo dato. Si una de ellas,
tiene candado X, ningn otro candado se puede adquirir sobre este dato. Esto
disminuye el nivel de concurrencia, o sea, el nmero de transacciones que se
pueden ejecutar en forma concurrente. Para aliviar este problema, se procedi
en dos direcciones: se permite solicitar un tipo de candado y convertirlo
despus en otro tipo diferente o se usan los candados de U (update).
ADQUIRIDO
MODO Ninguno S U X
SOLICITADO
S + + - -
U + + - - + compatible
X + - - -
Sin embargo, tener los candados y utilizarlos no asegura la ejecucin
serializable de las transacciones.
Ejemplo:
T1 T2
SLOCK(Y); SLOCK(X);
READ(Y); READ(X);
UNLOCK(Y); UNLOCK(X);
XLOCK(X); XLOCK(Y);
READ(X); READ(Y);
X = X + Y; Y = Y + X;
WRITE(X); WRITE(Y);
UNLOCK(X); UNLOCK(Y);
T1 T2
SLOCK(Y);
READ(Y);
UNLOCK(Y);
SLOCK(X);
READ(X);
UNLOCK(X);
XLOCK(Y);
READ(Y);
; Y = Y + X;
WRITE(Y);
UNLOCK(Y);
XLOCK(X);
READ(X);
X = X +Y;
WRITE(X);
UNLOCK(X);
Ejemplo:
T1
SLOCK(Y);
READ(Y);
XLOCK(X);
UNLOCK(Y);
READ(X);
X = X+Y;
WRITE(X);
UNLOCK(X);
Figura 3.1 resume los tres protocolos de 2PL. Como puede verse cada uno de
ellos tiene sus ventajas y desventajas:
2PL bsico:
o Asegura el mayor nivel de concurrencia.
o Se pueden dar los problemas de deadlocks (en la fase de
crecimiento) y lectura sucia o la anulacin en cascada (en la fase
de encogimiento), si no se aade otra componente al control.
2PL estricto:
o Se disminuye el nivel de concurrencia comparando con el 2PL
bsico.
o Se evita el problema de lectura sucia o el aborto de las
transacciones en cascada.
2PL conservativo:
o El menor nivel de concurrencia.
o Se evita los problemas de deadlocks y lectura sucia.
o Se puede dar el problema de inanicin (en la fase de crecimiento).
Nota:
Existe un tipo especial de candados llamado cerrojo (latch) que se mantiene
durante un periodo mucho ms corto que un candado normal. Los latches se
pueden utilizar antes de leer o escribir una pgina al disco con el fin de que la
operacin sea atmica. Puesto que el latch se utiliza simplemente para prevenir
conflictos, no se necesita su adaptacin al protocolo de 2PL.
Este tipo de candados se llama key-range (rango de llave) y se usa para poner
candados de S o X sobre las tuplas que pertenecen a un rango especfico de
valores. Este tipo de candados se usa sobre la estructura de ndice, o sea, si la
consulta en la condicin where se refiere a un valor especifico o a un rango de
valores, se ponen los candados en los nodos hoja del rbol B+ sobre este valor
o rango. La transaccin, para acceder el dato, primero tiene que adquirir el
candado sobre el ndice siguiendo las reglas de compatibilidad. Por ejemplo,
suponga que existe el ndice sobre el atributo del departamento en la tabla de
Empleado. Cuando la consulta lee los datos que se refieren a los empleados
que trabajan en el departamento 4, se establecen los candados S en las hojas
del rbol B+ para este valor. Esto impide que otra transaccin modifique, inserte
o borre los valores que pertenecen a este rango.
Los niveles de aislamiento: se pueden establecer por medio del comando: SET
TRANSACTION ISOLATION LEVEL [nombre del nivel]. Existen 5 niveles de
aislamiento, de los cuales el primer nivel no se implementa en la BD ni est
definido por el SQL estndar. Los niveles de aislamiento se establecen para
cada una de las transacciones por separado; en caso de omitirlo, se aplica a la
transaccin el nivel de aislamiento establecido por defecto para una DBMS
particular.
GRADO 0: Anarqua
Problemas de lost update, dirty read, unrepeatable read y phantom tuples.
No se pueden recuperar las transacciones.
No existen los candados S.
Solo existen candados cortos de X para la proteccin de escritura.
Se ve el resultado de write inmediatamente despus de ejecutarlo.
Mayor grado de concurrencia.
No se usa en BD.
Ejemplo:
T1 T2
READ(X);
READ(X);
X = X - N;
XLOCK(X);
WRITE(X);
UNLOCK(X);
X = X * 2.4;
XLOCK(X);
WRITE(X);
UNLOCK(X);
XLOCK(Y);
Y = Y * X;
UNLOCK(Y);
Ejemplo
T1 T2
READ(X);
READ(Y);
XLOCK(X);
XLOCK(Y);
X = X + Y;
WRITE(X);
READ(X);
UNLOCK(X);
Y = Y * 1.6;
WRITE(Y);
READ(Y);
UNLOCK(Y);
Ejemplo:
T1 T2
SLOCK(X);
READ(X);
UNLOCK(X);
XLOCK(X);
READ(X);
XLOCK(Y);
READ(Y);
Y = Y + X;
WRITE(Y);
UNLOCK(Y);
XLOCK(Y);
READ(Y);
X = X * 1.6;
WRITE(X);
UNLOCK(X);
GRADO 4: Serializable
No existe ninguno de los problemas mencionados anteriormente.
Existen los candados largos de tipo S y X.
Se sigue el protocolo 2PL con respecto a la lectura y escritura.
Se pueden recuperar las transacciones.
Es la verdadera planificacin serializable.
BD
r1 r2 rk
ADQUIRIDO
MODO Ninguno IS IX S SIX U X
SOLICITADO
IS + + + + + - -
IX + + + - - - -
S + + - + - - -
+ compatible
SIX + + - - - - -
U + - - + - - -
X + - - - - - -
MANEJO DE DEADLOCKS
Cuando un sistema utiliza el protocolo de control de concurrencia basado en
candados existe la posibilidad de que este sistema entre al estado de deadlock
(interbloqueo). Deadlock se produce cuando cada transaccin T en un conjunto
de dos o ms transacciones est esperando a algn elemento que est
bloqueado por otra transaccin. Por lo tanto, cada transaccin del conjunto est
detenida en espera de que una de los dems transacciones libere el bloqueo
sobre el elemento.
Ejemplo:
T1 T2
SLOCK(Y);
READ(Y);
SLOCK(X);
READ(X);
XLOCK(X);
XLOCK(Y);
Suponga que Ti trata de ocupar el dato X, pero este dato est bloqueado por
Tk con un candado en conflicto. Dos esquemas basados en TS que evitan los
deadlocks son:
wait-die (esperar-morir)
if TS(Ti) < TS(Tk)
then Ti espera
else aborte Ti (die) y reinicie con el mismo TS.
wound-wait (herir-esperar)
if TS(Ti) < TS(Tk)
then aborte Tk y reinicie con el mismo TS
else Ti espera
Ejemplo:
T1
T2 T4
T3
Si el grafo tiene un ciclo se sabe que ocurri una paralizacin. Para eliminarla se
procede de la siguiente forma:
Ejemplo
T1 T2
READ(B);
READ(B);
B = B - 50;
WRITE(B);
READ(A);
READ(A);
PRINT(A+B)
A = A +Y50
WRITE(A);
PRINT(A+B);
T1 T2
TS_read(B) =TS(T1)
TS_write(B)>TS(T2)? No existe TS_write(B),
entonces TS_read(B)=TS(T2)
TS_read(B)>TS(T2) o TS_write(B)>TS(T2)?
No, entonces TS_write(B) =TS(T2)
TS_write(A)>TS(T1)? No existe TS_write(A),
entonces TS_read(A)=TS(T1)
TS_write(A)>TS(T2)? No existe TS_write(A),
entonces TS_read(A)=TS(T2)
TS_read(A)>TS(T2) o TS_write(A)> TS(T2)?
No, entonces TS_write(A) =TS(T2)
Debido a los problemas que puede dar este protocolo para la escritura de los
datos, existen otras variaciones, por ejemplo, una de ellas combina el protocolo
de 2PL con ordenamiento de estampillas de tiempo multiversin.
Ti
Tj
PARTE IV
TCNICAS DE RECUPERACIN Y MANEJO DE BFER
Recuperarse del fallo de una transaccin normalmente significa que la BD se
restaura al estado consistente ms reciente, inmediatamente anterior al
momento de fallo. Para poder hacer las recuperaciones despus de las fallas el
mtodo ms usado es basado en la bitcora (log). La bitcora es un archivo
secuencial que incluye la informacin sobre todas las transacciones que afectan
los datos en la base de datos, tipo de operacin realizada y estado de la
transaccin. La bitcora tiene su espacio en la memoria principal y tambin se
guarda en el disco. La copia en el disco asegura la recuperacin de todas las
fallas, excepto fallas del disco.
BITCORA
Existen diferentes tipos de bitcoras que pueden tener estructuras de datos
variadas. En general, la bitcora debe incluir la informacin de:
El identificador de la transaccin, por ejemplo, T1.
La operacin ejecutada, por ejemplo read o write.
El identificador del elemento de datos, por ejemplo, salario.
El valor anterior antes de la modificacin llamado BFIM (before image).
En valor nuevo despus de la modificacin llamado AFIM (after image).
Ejemplo:
[T1, begin]
[T1, read, D, 5]
[T1, write, D, 5, 20]
[T1, commit]
[T2, begin]
[T2, read, B, 2]
[T2, write, B, 2, 10]
[T2, read, D, 20]
[T2, write, D, 20, 25]
[T2, commit]
En la ejecucin concurrente la diferencia consiste en que las operaciones de las
transacciones se intercalan entre s. Adems, en muchos sistemas reales no se
guarda la informacin sobre la operacin de lectura.
Actualizaciones diferidas:
T1 T2
READ(A); READ(B);
READ(D); WRITE(B);
WRITE(D) READ(D);
WRITE(D);
Bitcora BD
<T1, begin>
<T1, write, D, 20>
<T2, begin>
<T1, commit>
<T2, write, B,30>
D=20
<T2,write, D,55>
Fallo del sistema
Actualizaciones inmediatas
Ejemplo UNDO/NO-REDO:
T1 T2
READ(A); READ(B);
READ(D); WRITE(B);
WRITE(D) READ(D);
WRITE(D);
Bitcora BD
<T1, begin>
<T1, write, D, 10>
20
<T2, begin>
<T1, commit>
<T2, write, B, 15>
30
<T2, write, D, 40>
55
Fallo del sistema
La figura 4.3 ilustra el concepto de tabla pgina sombra (shadow page) y la tabla
de pginas actual. Para las pginas actualizadas por la transaccin, se guardan
La anulacin en cascada puede consumir bastante tiempo por ello es que casi
todos los mecanismos de recuperacin se disean de modo que la reversin en
cascada casi nunca sea necesaria. Adems, solo la anulacin en cascada
necesita conocer los valores ledos por la transaccin. Como este fenmeno no
se da, las bitcoras no guardan ninguna operacin de leer un dato.
PUNTOS DE REVISIN
Cuando ocurre un fallo del sistema se debe revisar toda la bitcora y hacer las
operaciones de UNDO/NO-UNDO y REDO/NO-REDO de acuerdo al tipo de
actualizaciones implementadas en una DBMS. Sin embargo, el proceso de
revisar la bitcora consume tiempo debido a que la bitcora tiene registradas las
operaciones de todas las transacciones. Como la mayora de las transacciones
terminan con xito, puede ser innecesario recorrer toda bitcora y re-grabar los
resultados. Para reducir la cantidad de trabajo durante la recuperacin, se
establecieron los puntos de revisin (checkpoints).
Ejemplo:
Considere la ejecucin de transacciones concurrentes como se presenta en la
figura 4.6.
Es importante primero hacer UNDO y solo despus REDO para no incurrir en los
errores. Por ejemplo, si se tiene la siguiente bitcora:
<T1, start>
<T1, A, 10, 20>
<T2, start>
<T2, A, 10, 30>
<T2, commit>
recorre la lista de UNDO desde el final hacia el checkpoint, A tendr valor 10, al
cual se aplicara regrabacin del valor modificado por la transaccin T2 que
termin con xito. De esta forma el valor final es A = 30, el cual es un valor
correcto.
Los bfers representan reas continuas en la memoria que se usan para guardar
los datos cargados desde la memoria secundaria con el propsito de su
procesamiento (por ejemplo, consulta, modificacin de datos). Los bfers son
organizados en, los as llamados, buffer pool como se puede ver en la figura
4.7, donde cada celda indica un bfer (como ejemplo, el color oscuro en la figura
indica que el bfer est ocupado; en otro caso est libre).
Pgina de disco
(bfer ocupado)
Bfer disponible
Cada vez cuando se ocupa realizar las operaciones sobre datos, estos datos
deben ser trados desde el disco al bfer. Si el dato se modifica, los cambios
primero se reflejan en el bfer y posteriormente en el disco. El almacenamiento
en cache y su respectivo reflejo al disco es normalmente responsabilidad del
sistema operativo. Sin embargo, debido a su importancia en la eficiencia de una
DBMS y su necesidad de coordinacin con el fin de recuperacin, es necesario
que la misma DBMS se encargue del proceso de asignacin de bfers y grabado
al disco duro, invocando a menudo las rutinas de bajo nivel del sistema
operativo.
El manejador de buffer mantiene una tabla (directorio) para poder rastrear los
elementos que se encuentran en la memoria principal. Esta tabla contiene la
informacin de la direccin fsica del dato en el disco duro y en la memoria
principal. Adems, cada bfer incluye la informacin adicional que se maneja por
medio de dos indicadores:
Bit sucio (dirty bit): se inicia con el valor 0 cuando se lee la pgina del
disco al bfer y se asigna el valor 1, cuando se modifica esta pgina.
Contador de pin: inicializado con el valor 0; se incrementa en 1 cada vez
que la pgina sea solicitada (por el usuario o proceso) y se disminuye el
valor 1 cada vez que es liberada.
Cuando alguna componente de DBMS solicita una accin sobre algn elemento,
se realizan los siguientes pasos:
Cuando una DBMS desea reflejar en el disco los cambios a los datos, el
manejador del buffer sigue las reglas que indican cuando un bloque puede
escribirse al disco y cuando se puede hacer la escritura:
No-steal Steal
No-force Ms rpido,
deseado
Force Ms lento,
trivial
No-steal Steal
Actualizaciones Actualizaciones
No-force Diferidas Inmediatas
No-undo/Redo Undo/Redo
Actualizaciones
Force Shadow paging
Inmediatas
No-undo/No-redo
Undo/No-redo
Figura 4.10 presenta la arquitectura simplificada de una DBMS con los diferentes
manejadores de recursos. Adems, por medio de flechas se indica un posible
intercambio de datos y controles, limitndolos para simplificar la figura. Como se
puede ver en la figura 4.10 el usuario o una aplicacin inician la accin que se
maneja como una consulta o transaccin. Recuerda que las operaciones de
modificacin (update, insert, delete) se consideran implcitamente como
transacciones.
Usuario/aplicacin
consultas comandos de
transaccin
Manejador de
Compilador de consultas
transacciones
comandos de pginas
Manejador de bfer
Bfers
lectura/escritura Tabla de candados
de pginas
Manejador de
almacenamiento
Flujo de control y de datos
Flujo de datos
Base de datos
Base de datos
Las consultas pasan por el compilador de consultas donde deben ser traducidas
y optimizadas formando un plan de ejecucin. Este plan o una secuencia de
acciones se pasa al motor de ejecucin. Para obtener los datos necesarios para
la ejecucin, el motor de ejecucin emite una secuencia de peticiones al
manejador de recursos que tiene la informacin sobre los archivos de datos,
formato y tamao de registros, adems de los ndices. Los datos solicitados se
expresan en trminos de pginas (bloques) solicitados y se enva la peticin
para su recuperacin al manejador de bfers. El ltimo es responsable de dividir
la memoria principal en partes llamadas bfers, que corresponden al tamao de
la pgina recuperada del disco. El manejador de bfers se comunica con el
manejador de almacenamiento para obtener los datos desde disco. Su
responsabilidad es el control de ubicacin de los datos en el disco y movimiento
de estos datos entre el disco y memoria principal. El manejador de
almacenamiento puede invocar los comandos de sistema operativo solicitando la
PARTE V
DIFERENTES TIPOS DE TRANSACCIONES
Transacciones planas
Este tipo de transacciones son adecuadas para las aplicaciones simples donde
solo se accede una base de datos. Las transacciones planas tienen dos
limitaciones: (1) cuando la transaccin aborta, el sistema restaura todos los
valores al estado previo de la ejecucin de esta transaccin y (2) no se puede
hacer commit de una parte de la transaccin para las aplicaciones ms
complejas.
Ejemplo:
BEGIN
Reserva de San Francisco a Miami.
Reserve de Miami a Berlin el mismo da
Reserve de Berlin a Varsovia el da siguiente
Reserve de Varsovia a Glogow el mismo da
BEGIN
Operation1 Operaciones
conservadas
Operation2
SAVEPOINT A
Operation3
SAVEPOINT B
Operation4 Operation8
Operation5 Operation9 Operaciones
Operaciones
Operation6 SAVEPOINT D conservadas
anuladas
SAVEPOINT C Operation10
Operation7 SAVEPOINT E
ROLLBACK A Operation11
Operation12 Operation15
SAVEPOINT F Operation16
Operaciones Operation13 SAVEPOINT G
anuladas Operation14 Operation17
ROLLBACK F COMMIT
Figura 5.3. Uso de savepoint dentro de la transaccin.
Cabe recordar que es diferente hacer rollback que abort. Para rollback la
transaccin en ejecucin tiene todos los recursos asignados (nmero de
transaccin, variables locales, entre otros) y comienza desde el principio con la
primera operacin mientras que abortar la transaccin significa que la
transaccin desaparece del sistema y pierde todos los recursos asignados.
candados) que tiene asignado el padre, pueden ser accedidos por sus
subtransacciones y stas pueden solicitar otros objetos que al terminar pasan
al padre.
Transacciones distribuidas
T1 T2 T3
BEGIN1
Modificacin de ... Modificacin de
Modificacin de cuentas 5001 - cuentas 995001
cuentas 1 -5000 10000 -1000000
1
El protocolo usado se llama Two Phase Commit.
T1 T2 Tn
BEGIN1
Modificacin de ... Modificacin de
Modificacin de cuentas 5001 - cuentas 995001
cuentas 1 -5000 10000 -1000000
N=5000 N=10000
RESUMEN
PARTE VI
SEGURIDAD EN BASES DE DATOS
INTRODUCCIN
La seguridad en las bases de datos representa los mecanismos que protegen a
la base de datos frente a amenazas intencionales o accidentales [CB05]. Esta
seguridad comprende muchos conceptos [EN07]:
Aspectos legales y ticos en relacin con el derecho de acceso a
determinada informacin.
Temas de polticas a nivel gubernamental, institucional o de empresa en
relacin con los tipos de informacin que no deberan estar disponibles
pblicamente.
Temas relativos al sistema, donde se pueden considerar diferentes
niveles reforzando adecuadas funciones de seguridad, por ejemplo, DBA
a nivel de DBMS.
Identificacin de diferentes niveles de seguridad por medio de la
clasificacin de los datos y los usuarios.
Una amenaza puede producir un dao tangible, como por ejemplo, prdida de
hardware, software o datos, o intangible, como por ejemplo prdida de
credibilidad o de la confianza de los clientes. Adems, las amenazas pueden
existir en diferentes niveles, por ejemplo a nivel de hardware, software,
comunicacin, personal, etc. La figura 6.1 presenta un sumario de amenazas
que puede afectar la seguridad de un sistema informtico.
El nivel de cuenta:
o El DBA especifica los privilegios que posee cada cuenta, por
ejemplo, privilegios sobre CREATE SCHEMA, CREATE TABLE,
CREATE VIEW, ALTER, DROP, SELECT.
o No forma parte del SQL estndar y depende de la DBMS usada.
o Se pueden asignar los privilegios usando la sentencia:
GRANT lista de privilegios TO usuario
Ejemplo: GRAN CREATE TABLE TO Juan
GRANT ALTER SCHEMA TO PUBLIC
o Se pueden revocar los privilegios por medio del comando:
REVOKE lista de privilegios FROM users
Ejemplo: REVOKE CREATE TABLE FROM Juan
REVOKE ALTER SCHEMA FROM PUBLIC
En nivel de la relacin:
o El DBA controla el privilegio de acceso a cada relacin o vista
individual en la base de datos.
o Forma parte de SQL estndar y permite diferentes tipos:
SELECT: Asigna a la cuenta los privilegios de recuperacin
de tuplas o atributos de R.
MODIFY: Permite realizar la modificacin de tuplas y se
subdivide en privilegios sobre UPDATE, DELETE e INSERT.
Adicionalmente, para los privilegios de INSERT y UPDATE
se pueden especificar solo algunos atributos que pueden ser
modificados.
REFERENCES: Permite a la cuenta referencias a las tuplas
de la relacin R en la especificacin de integridad
referencial. Se puede restringir este privilegio solo a
atributos especficos de la relacin R.
Otros
o Las sentencias de GRANT y REVOKE incluyen objetos
GRANT lista de privilegios ON objetos TO usuario
REVOKE lista de privilegios FROM users
Ejemplo: GRANT UPDATE ON Orders TO Maria
REVOKE UPDATE ON Orders FROM Maria
Cada vez que el dueo de la relacin R garantiza los privilegios a la otra cuenta,
lo puede hacer con dos opciones: permitiendo al otro usuario conceder
privilegios a otros usuarios o no permitiendo esta opcin.
Ejemplo.
Figura 6.2. Grafo con concesin de privilegios entre diferentes usuarios [SKS06].
DBA DBA
U1 U2 U3 U1 U2 U3
a) b)
DBA DBA
U1 U2 U3 U1 U2 U3
c) d)
Ejemplo:
Las clases de seguridad tpicas usadas en MAC son alto secreto (TS, top
secret), secreto (S, secret), confidencial (C, confidential) y no clasificado (U,
unclassified)3, donde TS S C U. El modelo ms conocido es Bell-LaPadula
3
Aunque existen esquemas ms complejos, solo se considera uno simple.
La primera regla impide que los sujetos lean un objeto que tiene clasificacin
ms alta que ellos mismos, por ejemplo, un sujeto con la clasificacin C, no
puede leer el objeto con la clasificacin TS. La segunda regla impide al sujeto
con la clasificacin mayor escribir los objetos de seguridad ms baja, por
ejemplo, evitar que el sujeto con la clasificacin de TS lea un objeto clasificado
como TS y haga una copia como U, o sea, propagando la informacin de alto
secreto a todos los sujetos sin importar su clase.
Figura 6.4. Tuplas y atributos que pueden ver los usuarios de la clase C y U
[EN07].
Figura 6.5. La relacin Cliente con un atributo adicional que muestra la clase de
seguridad de cada tupla [CB05].
Suponga que el usuario con nivel de seguridad C quiere insertar una tupla como
(CR74, David, Sinclaire). Esta insercin no es posible porque viola la restriccin
de integridad de la llave. Sin embargo, la imposibilidad de insertar esta nueva
tupla informa al usuario de nivel de seguridad C de que existe una tupla con la
llave CR74 y con nivel de seguridad superior a C. Esto pone en cuestin el
requisito de seguridad de que los usuarios no deben ser capaces de inferir
ningn tipo de informacin acerca de los objetos que tienen una clasificacin de
seguridad superior.
Figura 6.6. La relacin Cliente con dos tuplas con el mismo nmero de clientNo
[CB05].
Los usuarios con el nivel de seguridad C vern las primeras dos tuplas y la tupla
recin aadida, pero los usuarios con nivel de seguridad S o TS vern todas las
tuplas de la relacin. Como la aparicin de dos veces del mismo clientNo puede
ser confusa, se pueden establecer algunas reglas adicionales, por ejemplo, que
las tuplas con nivel de seguridad ms alto tienen prioridad sobre las tuplas con
nivel de seguridad ms bajo o mostrar solo las tuplas del nivel correspondiente.
El control DAC se caracteriza por un alto grado de flexibilidad para una gran
cantidad de aplicaciones debido a que es suficiente especificar a cuales objetos
tienen los usuarios derecho de realizar las operaciones especficas. El principal
inconveniente es la vulnerabilidad a ataques maliciosos debido a que no existen
mecanismos claros y eficientes sobre la propagacin. Por el contrario, las
polticas establecidas por MAC aseguran un alto grado de proteccin. Sin
embargo, son demasiado rgidas ya que requieren una clasificacin estricta de
los sujetos y de los objetos en niveles de seguridad y, por tanto, son aplicables a
muy pocos entornos. En la prctica, en la mayora de las situaciones se
prefieren DAC, porque ofrecen una mejor relacin entre seguridad y
aplicabilidad.
La idea bsica es que los permisos estn asociados a roles y a los usuarios se
les asignan los roles apropiadas. Los roles se pueden crear por medio de los
comandos CREATE ROLE nombre y se pueden borrar usando el comando
DESTROY ROLE nombre. Los privilegios se conceden a los roles de la misma
forma como para las cuentas usando DAC, o sea, usando los comandos de
GRANT y REVOKE.
Ejemplo
Suponga que tenemos los empleados John y Maria que son cajeros y tienen
derecho de consultar la relacin Cliente e insertar datos a la relacin Cuenta.
Adems, existen los usuarios Adam y Eva, que son gerentes de la empresa,
para los cuales se crea un rol director con derechos de revisar toda la base de
datos.
Adems, los roles se pueden conceder a otros roles. Por ejemplo, si existe un rol
de empleado, este rol se puede conceder al rol de cajero de la siguiente forma:
GRANT empleado TO cajero;
En control de acceso basado en roles es una alternativa entre DAC y MAC que
garantiza que solo los usuarios autorizados tienen acceso a determinados datos
o recursos. La jerarqua de roles es el modo natural de organizar los roles para
que reflejen la jerarqua de autoridad y de responsabilidades de organizacin.
Por convencin, los roles de menos responsabilidad de la parte inferior se
conectan con roles de responsabilidad cada vez mayores a medida que se sube
por la jerarqua.
CIFRADO
Los mtodos anteriores de acceso aunque representan un control bastante
fuerte, pero podran no ser suficientes para el control de los datos contra las
amenazas. Especialmente cuando se requiere la transmisin de datos por medio
inseguro existe peligro de que los datos sean receptados por los usuarios no
autorizados. Una de las protecciones que ofrecen algunas DBMSs es encryptar
los datos.
BIBLIOGRAFA
APPENDIX A
Esquema
EMPLEADO
NSS
NOMBRE PATERNO MATERNO NSS FECHAN DIRECCION SEXO SALARIO
SUPER
ND
DEPARTAMENTO
NOMBRED NUMEROD NSSGTE FECHAINICGTE
LUGARES_DEPTOS
NUMEROD LUGARD
PROYECTO
NOMBREP NUMEROP LUGARP NUMD
TRABAJA_EN
NSSE NUMP HORAS
DEPENDIENTE
NSSE NOMBRE_DEPENDIENTE SEXO FECHAN PARENTESCO
Instancias
EMPLEADO
NOMBRE IN APELLIDO NSS FECHAN DIRECCION SE SALA NSS N
IC XO RIO SUPER D
Jos B Silva 123456789 09-ENE-55 Fresnos 731, M 30000 33344555 5
Higueras, MX 5
Federico T Vizcarr 333445555 08-DIC-45 Valle 638, M 40000 88866555 5
Higueras, MX 5
Alicia J Zapata 999887777 19-JUL-58 Catillo, Sucre, F 25000 98765432 4
MX 1
Jazmin S Valdes 987654321 20-JUN-31 Bravo 291, F 43000 88866555 4
Belen, MX 5
Ramn K Nieto 666884444 15-SEP-52 Espiga 875, M 38000 33344555 5
Heras, MX 5
Josefa A Esparza 453453453 31-JUL-62 Rosas 5631, F 25000 33344555 5
Higueras, MX 5
Ahmed V Jabbar 987987987 29-MAR-59 Dallas 980, M 25000 98765432 4
Higueras, MX 1
Jaime E Botello 888665555 10-NOV-27 Sorgo 450, M 55000 Null 1
Higueras, MX
DEPARTAMENTO
NOMBRED NUMEROD NSSGTE FECHAINICGTE
Investagacin 5 333445555 22-MAY-78
Administracin 4 987654321 01-ENE-85
Direccin 1 888665555 19-JUN-71
LUGARES_DEPTOS
NUMEROD LUGARD
1 Higueras
4 Santiago
5 Beln
5 Sacramento
5 Higueras
PROYECTO
NOMBREP NUME LUGARP NUMD
ROP
Producto X 1 Beln 5
Producto Y 2 Sacramiento 5
Producto Z 3 Higueras 5
Automatizacin 10 Santiago 4
Reorganizacin 20 Higueras 1
Nuevasprestaciones 30 Santiago 4
TRABAJA_EN
NSSE NUMP HORAS
123456789 1 32.5
123456789 2 7.5
666884444 3 40
453453453 1 20
453453453 2 20
333445555 2 10
333445555 3 10
333445555 10 10
333445555 20 10
999887777 30 30
999887777 10 10
987987987 10 35
987987987 30 5
987654321 30 20
987654321 20 15
888665555 20 Null
DEPENDIENTE
NSSE NOMBRE_DE SEXO FECHAN PARTENE
PENDIENTE SCO
333445555 Alicia F 05-ABR-76 Hija
333445555 Teodoro M 25-OCT-73 Hijo
333445555 Jobita F 03-MAY-48 Cnyuge
987654321 Abdiel M 29-FEB-23 Cnyuge
123456789 Miguel M 01-ENE-78 Hijo
123456789 Alicia F 31-DIC-78 Hija
123456789 Elizabeth F 05-MAY-57 Cnyuge