Vous êtes sur la page 1sur 98

UNIVERSIDAD DE COSTA RICA

ESCUELA DE CIENCIAS DE LA
COMPUTACIN E INFORMTICA

Elaborado por
Dra. Elzbieta Malinowski G.

El siguiente material est basado parcialmente en el libro de R.


Elmasri y S. Navathe Fundamentos de Sistemas de Bases de Datos,
5 edicin, 2007 y de ninguna forma reemplaza este libro como libro
de texto para el curso de Bases de Datos II. Otra bibliografa usada se
encuentra especificada al final de folleto.

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.

Figura 1.1 Pasos para procesamiento de las consultas

Anlisis lxico (Scanner)


Identifica los elementos del lenguaje (tokens) en el texto de la consulta, como
por ejemplo, palabras reservadas de SQL (select, where), nombres de los
atributos y de las tablas.

Anlisis sintctico (Parser)


Revisa si la consulta est escrita de acuerdo a la sintaxis especificada.

Validacin
Revisa si los nombres de las tablas y los atributos son los nombres existentes en
la BD.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 2


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Forma intermediaria de consulta


Se crea una representacin de la consulta mediante una estructura de datos
denominada rbol de consulta o grafo de consulta.

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

Generador del cdigo de consultas


Genera el cdigo de la consulta para ser ejecutado.

Procesador de BD en tiempo de ejecucin (Runtime Database Processor)


Ejecuta el cdigo compilado o interpretado.

SQL es un lenguaje no procedimental, lo que significa que el programador define


los datos que requiere no como obtenerlos. Esto permite mejorar la eficacia en
programacin, sin embargo, DBMS tiene que incluir un conjunto de algoritmos
sofisticados para determinar los mejores mtodos de recuperacin de
resultados. Los DBMS incluyen una variedad de algoritmos para la
implementacin de diferentes operaciones presentes en la consulta. Estas
operaciones se compilan para obtener resultados deseados. Adicionalmente, si
la DBMS tiene optimizadores de consultas este cdigo puede cambiar con el fin
de disminiur el tiempo de ejecucin.

ALGORITMOS BASICOS PARA LA EJECUCION DE LAS OPERACIONES DE


CONSULTAS

Las DBMSs pueden usar diferentes algoritmos para la ejecucin de las


operaciones especificadas en la consulta.

OPERACIN DE SELECCIONAR (WHERE)

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)

Se pueden usar diferentes mtodos de bsqueda para la operacin de seleccin


dependiendo de la disponibilidad de los ndices.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 3


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

Usando el ndice primario o llave hash para recuperar un registro:


Se usa cuando la condicin es de igualdad con respecto a la llave primaria o
llave de hash, por ejemplo, la consulta OP1 si NSS se usa para el ndice
primario o llave hash.

Usando el ndice primario para recuperar varios registros:


Si la condicin es de <, , >, en el campo de la llave primaria, primero se
necesita encontrar el registro que iguala la condicin y despus se recuperan
todos los registros subsecuentes. Por ejemplo, en la consulta OP2, se buscar,
usando el ndice primario, el registro que satisface la condicin NUMEROD = 5
y despus se extraern los registros que siguen.

Usando un ndice de segmento:


Se usa si la condicin es de igualdad en el atributo no-llave, por ejemplo, para la
consulta OP3 si se usa el ndice de segmento con respecto al atributo ND en la
tabla de empleados.

Usando el ndice secundario:


Se usa en una condicin de igualdad para los registros que cumplen la
condicin. Al existir el ndice secundario y no de segmento, es posible que se
necesite acceder a un bloque de datos diferente por cada registro. Si los valores
son nicos, solo se requiere un acceso.

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.

OPERACIN DE PROYECTAR (SELECT)

La operacin <lista de atributos>(R) es fcil de implementar si el atributo a


proyectar es la llave primaria (o candidata) de la relacin, ya que al acceder los

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 4


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

atributos usando uno de los mtodos especificados anteriormente, solo es


necesario presentarlos; en este caso el resultado tendr el mismo nmero de
tuplas que la relacin original. En caso contrario, las tuplas duplicadas deben ser
eliminadas de acuerdo a la propiedad de conjuntos en la cual se basa el lgebra
relacional. Esto se hace normalmente ordenando el resultado de la operacin y
eliminando despus las tuplas duplicadas que aparecen consecutivamente. Esta
eliminacin se aplica en SQL solo si aparece la clusula DISTINCT.

OPERACIN JOIN DE DOS RELACIONES

Esta operacin consume ms tiempo de ejecucin comparada con las


operaciones anteriores. Suponga que la se necesita ejecutar la siguiente
operacin join:

R A=B S

Existen varias tcnicas para implementar la operacin join de dos tablas (two-
way join); conozcamos algunas de estas tcnicas:

Ciclos anidados (nested inner-outer loop):


Para cada registro t de R (ciclo externo) recupera cada registro s de la relacin S
(ciclo interno) y revisa si los dos registros satisfacen la condicin: t[A] = s[B].
Usando el pseudo-cdigo:

while (blocks in R) { /* outer loop */


read (block in R)
while (blocks in S) { /* inner loop */
read (block in S)
for (each row in R-block) {
for (each row in S-block) { En memoria
if (A = B) then join principal
else skip }
} } }

Ciclos anidados con ndice:


Si existe un ndice para la relacin S sobre el atributo B de join, se puede
recuperar cada registro t de R y posteriormente usar este ndice para recuperar
los registros s de S que satisfacen la condicin t[A] = s[B]

while (blocks in R) { /* outer loop */


read (block in R)
for (each row in block R) {
read (index tree levels)
read (record(s))
if (A = B) then join
else skip} }

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 5


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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

sort (R) /* opcional si la tabla R ya est ordenada */


sort (S) /* opcional si la tabla R ya est ordenada */
while (blocks in R or blocks in S) {
read (block in R)
read (block in S)
for (until no more rows in tables) {
If (R.A < S.B)
get next row in (Rable1)
elseif (R.A > S.B)
get next row in (S) Memoria principal
else {
join
get next row in (R)
get next row in (S) }}

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.

for each row in R produce a hash


assign the hash to hash bucket
for each row in S produce hash
if the hash is already in the hash bucket
apply join

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

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 6


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

OPERACIN DE JOIN EXTERNO

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

Esta operacin se puede ejecutar usando uno de los algoritmos de join


presentados anteriormente, por ejemplo, el de ciclos anidados. Sin embargo, se
debe posicionar en el ciclo externo la tabla para la cual se requiere obtener
todas las tuplas. Por ejemplo, esto impide usar la estrategia de poner la tabla
ms pequea en el ciclo interno.

Existen otras estrategias ms sofisticadas, sin embargo, sus variaciones y uso


dependen de la DBMS especfica.

OPERACIN DE JOIN DE VARIAS RELACIONES

La operacin de join entre varias relaciones normalmente se ejecuta como join


de dos relaciones creando el resultado intermedio, para el cual se aplica la
operacin de join con la otra relacin. Esto produce un rbol binario lineal o
izquierdo como se puede ver en la figura 1.2.

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 7


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

OPERACIONES DE CONJUNTOS

Las operaciones de conjuntos pueden tener las implementaciones muy


costosas, especialmente la operacin de producto cartesiano (tendra m * n
registros y j + k atributos).

Las operaciones de unin, interseccin y diferencia se aplican solamente a las


relaciones compatibles. La forma usual de efectuar estas operaciones es
ordenar las dos relaciones segn los mismos atributos y despus con una
pasada por cada relacin se produce el resultado. Tambin se puede aplicar la
funcin hash a los archivos, en lugar de ordenar.

OPERACIONES DE SUBCONSULTAS

Ya vimos anteriormente que las consultas pueden tener incluidas subconsultas,


o sea, la clusula SELECT con otro SELECT anidado. Las subconsultas pueden
ser de dos tipos:

Anidadas: cuando el SELECT interno no se refiere a la(s) columna(s) de


la(s) tabla(s) presentes en el ciclo externo, como por ejemplo:

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);

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 8


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Correlacionados: cuando el SELECT interno utiliza columna(s) de la(s)


tabla(s) del ciclo externo, como por ejemplo:

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

SELECT E.NOMBRE, E. APELLIDO


FROM EMPLEADO E
WHERE E.NSS IN (SELECT D.NSSE
FROM DEPENDIENTE D
WHERE D.NSSE=E.NSS
AND E.NOMBRE=
D.NOMBRE_DEPENDIENTE
AND D.SEXO = E.SEXO);

Existen tres posibilidades de procesamiento de este tipo de consultas:

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;

Despus se aplica alguno de los algoritmos de procesamiento de join.

In-to-out (de dentro a fuera):


Para cada tupla en la consulta interna, hacer una bsqueda en la consulta
externa. Se aplica a las subconsultas anidadas. Por ejemplo, primero se
evala el la consulta interna (where Table2.column2 = 3), despus se
ordena el conjunto resultante con respecto a Table2.column1 y se
eliminan los duplicados y al final, para cada valor del conjunto, se revisa
la igualdad con Table1.column1 (es importante tener ndices para este
campo).

Out-to-in (de afuera a dentro): para cada tupla en la consulta externa,


hacer bsqueda en la consulta interna. Se aplica a las subconsultas

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 9


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

anidadas y correlacionadas. La ejecucin para las consultas anidadas


puede representar menor tiempo de ejecucin debido a que solo se
necesita encontrar un elemento en el ciclo interno. Por ejemplo, el
siguiente pseudo-cdigo muestra la diferencia entre la ejecucin de
nested loop para la operacin join y para las subconsultas anidadas:

Nested loop for join Nested loop for subqueries (out-to-in)

for (each row in Table1) { for (each row in Table 1) {


for (each row in Table2) { for (each row in Table2) {
if match add to matchlist }} if match EXIT loop }}

Revisa todas combinaciones Necesita encontrar solo el primer


match

OPERACIONES DE AGREGACIN Y AGRUPACIN

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;

Si existe el ndice sobre el campo Edad, entonces el optimizador puede decidir si


debe utilizar el ndice para buscar el valor ms grande. El ndice tambin se
podra utilizar para los operadores de COUNT, AVG, SUM, pero solo si son
densos.

Cuando se utiliza la clusula GROUP BY en una consulta, el operador de


agregacin se debe utilizar para cada uno de los grupos. Por lo tanto, primero se
debe particionar la tabla en subgrupos de tuplas. La tcnica convencional es
utilizar la ordenacin o la dispersin por medio de hash sobre los atributos de
agrupacin. Posteriormente, se calcula el valor de agregacin para cada grupo.

Si existe el ndice de segmento sobre los atributos de agrupacin, los registros


ya se encuentran agrupados y en este caso solo se aplica el operador de
agregacin.

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,

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 10


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

entre otros. Este ajuste normalmente se da despus de un tiempo de usar el


sistema, cuando se detecta ineficiencia en su funcionamiento (largos tiempos de
respuesta, mucho espacio en el disco, bajo nivel de concurrencia, etc.).

En esta parte se presentan varias tcnicas de optimizacin. Este conocimiento


del optimizador de consultas puede ayudarle a entender las recomendaciones
sobre cmo escribir una buena consulta, qu ndices crear y analizar los planes
de ejecucin disponibles en varios DBMSs.

Existen dos tcnicas principales para optimizar las consultas:

Basada en heursticas: se crea y transforma el rbol cannico de la


consulta usando las reglas de transformacin de lgebra relacional a
expresiones equivalentes.

Basada en costo: se seleccionan las estrategias de ejecucin de la


consulta que minimizan el costo, eso es, el nmero de bloques que se
necesita leer del disco.

OPTIMIZACIN HEURSTICA

Cuando se procesa la consulta, el analizador sintctico crea un rbol de consulta


(lgebra relacional). Un rbol de consulta es una estructura de rbol que
corresponde a una expresin del lgebra relacional por el hecho de que
representa las relaciones de entrada como hojas del rbol y las operaciones del
lgebra relacional como nodos internos. Al inicio se crea el rbol cannico, al
cual se le aplican las transformaciones de acuerdo a las reglas heursticas. El
objetivo de estas transformaciones es mejorar el tiempo de ejecucin de
consulta por medio de la disminucin de la cantidad y volumen de los resultados
intermedios. Aplicando las reglas se llega al rbol de consulta final.

Una ejecucin del rbol de consulta consiste en la ejecucin de un nodo


interno siempre que sus operandos estn disponibles, sustituyendo despus ese
nodo interno por la relacin que resulte de ejecutar la operacin. La ejecucin
termina cuando se ejecuta el nodo raz y se produce la relacin resultado.

Ejemplo:

SELECT NUMEROP, NUMD, APELLIDO, DIRECCION, FECHANC


FROM PROYECTO, DEPARTAMENTO, EMPLEADO
WHERE NUMD = NUMEROD
AND NSSGTS = NSS
AND LUGARP =Santiago;

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 11


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Figura 4. rbol de consulta inicial (cannico).

El rbol cannico (como en la figura 4) es muy ineficiente si se ejecuta


directamente, debido a las operaciones de producto cartesiano. Por ejemplo, si
las relaciones de Proyecto, Departamento y Empleado tuvieran registros de 100,
50 y 150 bytes, y contuvieran 100, 20 y 5000 tuplas respectivamente, el
resultado de producto cartesiano contendra 10 millones de tuplas con un
tamao de registro de 300 bytes cada uno.

Sin embargo, al aplicar las heursticas el rbol cannico se puede transformar en


un rbol final como se muestra en la figura 1.5.

Figura 1.5. rbol de consulta final.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 12


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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:

Figura 1.6. rbol de consulta inicial (cannico).

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 13


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Figura 1.7. Desplazamiento de las operaciones seleccionar hacia abajo.

Figura 1.8. Aplicacin de la operacin seleccionar ms restrictiva primero.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 14


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Figura 1.9. Sustitucin de producto cartesiano y seleccionar por operaciones de


join.

Figura 1.10. Desplazamiento de las operaciones proyectar hacia abajo.

Las transformaciones del ejemplo anterior se dieron gracias a las reglas de


transformacin de lgebra relacional a expresiones equivalentes. Algunas de
estas reglas son:

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 15


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Cascada de : Una condicin de seleccin puede descomponerse en una


cascada (secuencia) de operaciones individuales :

c1 AND c2 AND AND cn (R) c1 (c2 ((cn(R))) )


Ejemplo
Salario>40000 AND ND=3 (Empleado) salario>40000 (nd=3 (Empleado) )

Conmutatividad de : La operacin es conmutativa;

c1 (c2(R)) c2 (c1(R))
Ejemplo
ND=3(Salario>40000 (Empleado) (salario>40000 (nd=3 (Empleado) )

Cascada de : En una cascada (secuencia) de operaciones , todas, excepto


la ltima, pueden ser ignoradas:

lista1(lista2((lista n(R)))) lista1(R)


Ejemplo
NSS(NSS, Apellido( NSS, Apellido, Nombre (Empleado))) NSS(Empleado)

Conmutatividad de con : Si la condicin de seleccin c, involucra slo los


atributos A1,, An en la lista de proyeccin, las dos operaciones pueden ser
conmutadas:
A1, A2,,An (c(R)) c (A1, A2,,An(R))
Ejemplo
NSS, Apellido, ND (ND=3(Empleado)) ND=3 (NSS, Apellido, ND (Empleado))

Conmutatividad de (o X): La operacin es conmutativa:

R c SS c R
Ejemplo
Empleado ND=NumeroD Departamento Departamento ND=NumeroD Empleado

Conmutatividad de con (o X): Si todos los atributos en la condicin de


seleccin c involucran slo los atributos de una de las relaciones que participan
en el join (o sea R), las dos condiciones pueden ser conmutadas de la siguiente
manera:
c(R S) (c (R)) S
Ejemplo
ND=3 and Sexo = F(Empleado Departamento)
(ND=3 and Sexo = FEmpleado) Departamento

Alternativamente, si la condicin de seleccin c puede ser escrita como (c1 y


c2), donde la condicin c1 involucra slo los atributos de R y la condicin c2

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 16


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

involucra slo los atributos de S, las operaciones conmutan de la forma


siguiente:

c(R S) (c1 (R)) (c2 (S))


Ejemplo
NombreD=Investigacin and Sexo = F(Empleado Departamento)
(Sexo = F(Empleado) (NombreD=Investigacin (Departamento)

Las mismas reglas se aplican si se reemplaza por la operacin X. Estas


transformaciones son muy tiles durante la optimizacin heurstica.

Conmutatividad de con (o X): Suponga que la lista de proyeccin es


L= {A1, ..., An, B1, ..., Bm}, donde A1, ..., An son atributos de R y B1, ..., Bm son
atributos de S. Si la condicin de join c involucra slo atributos en L, las dos
operaciones pueden ser conmutadas as:

L(R c S) (A1, ..., An (R)) c (B1, ..., Bm (S))

Si la condicin de join c contiene atributos adicionales que no estn en L,


stos podran ser aadidos a la lista de proyeccin y se necesitara una
operacin final . Por ejemplo, si los atributos An+1, ..., An + k de R y Bm +1, ...,
Bm+p de S estn involucrados en la condicin de join c pero no estn en la lista
de proyeccin L, las operaciones conmutan de esta manera:

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))

Para X, no hay condicin c, as que la primera regla aplica siempre


reemplazando c con X.

Conmutatividad de un conjunto de operaciones: El conjunto de


operaciones y son conmutativas, pero no lo es.

Asociatividad de , X, y : Estas cuatro operaciones son


individualmente asociativas, esto es, si es una de estas cuatro operaciones,
se tiene:
(R S) T R (S T)

Conmutatividad de con un conjunto de operaciones: La operacin


conmuta con , y . Si es una de estas tres operaciones, se tiene:

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 17


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

c(R S) (c (R)) (c (S))

Conmutatividad de con . La operacin conmuta con :

L(R S) (L (R)) (L (S))

Otras transformaciones: una seleccin o condiciones de join c pueden ser


convertidas en una condicin equivalente usando Leyes de DeMorgan`s):

c NOT (c1 AND c2) (NOT c1) OR (NOT c2)


c NOT (c1 OR c2) (NOT c1) AND (NOT c2)

Usando como base estas reglas, se establecen algunas pautas que se usan en
los algoritmos de optimizacin de consultas. Como por ejemplo:

Paso 1: Separe las operaciones de seleccin con las condiciones complejas


en cascada de las operaciones de seleccin (usando la regla 1).

Paso 2: Ejecute primero las operaciones de seleccin.

Paso 3: Aplique primero las operaciones de seleccin que producen la


relacin temporal con menos tuplas.

Paso 4: Combine las operaciones del producto cartesiano junto con


seleccin a una operacin join.

Paso 5: Aplique las operaciones de proyeccin lo ms pronto posible.

Paso 6: Identifique subrboles que representen grupos de operaciones que


se puedan ejecutar en un solo algoritmo.

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.

OPTIMIZACIN BASADA EN COSTOS

Un optimizador de consultas no debe depender exclusivamente de reglas


heursticas; tambin debe estimar y comparar los costos de ejecutar una
consulta con diferentes estrategias de ejecucin y elegir la estrategia con el ms
bajo costo estimado. Este costo, como ya se vio para los ndices, se calcula en
trminos de nmeros de bloques ledos.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 18


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

El costo no se expresa en trminos exactos, sino se calcula su estimacin. Por


lo tanto, la optimizacin podra elegir una estrategia que no fuese la ptima.
Adems, se debe limitar el nmero de estrategias de ejecucin que se
considerarn; de lo contrario, se invertir demasiado tiempo en elaborar
estimaciones de costo.

Estimaciones de costo para diferentes operaciones

Para entender mejor el proceso de optimizacin de consultas basado en costo


es necesario repasar algunos algoritmos de ejecucin vistos anteriormente y
estimar los costos.

En la estimacin de costo, sern necesarios los siguientes trminos:


r = nmero de registros (tuplas)
b = nmero de bloques
bfr = factor de bloqueo (blocking factor)
d = nmero de valores distintos del atributo de indizacin
x = nmero de niveles de ndice
s = cardinalidad de seleccin; el nmero promedio de los registros que
satisfacen la condicin: s = r/d
c = simplificacin de costo indicando el nmero de bloques accedidos
f = factor de selectividad; nmero de registros que satisface la
condicin con respecto al total de registros: f = s/r = 1/d

Operacin de seleccionar (where)

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)

De acuerdo al mtodo de bsqueda, la estimacin del costo ser diferente (note


que aqu se repasa las operaciones vistas antes, expandiendo la explicacin con
la estimacin del costo):

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 19


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

Usando el ndice primario o llave de hash para recuperar un registro:


Descripcin: Se usa cuando la condicin es de igualdad con respecto a la
llave primaria o llave de hash, por ejemplo, la consulta OP1 si NSS se usa
para el ndice primario o llave de hash.
Estimacin del costo: c = x+1

Usando el ndice primario para recuperar varios registros:


Descripcin: Si la condicin es de <, , >, en el campo de la llave
primaria, primero se necesita encontrar el registro que iguala la condicin
y despus recuperar todos los registros subsecuentes. Por ejemplo, en la
consulta OP2, se buscar, usando el ndice primario, el registro que
satisface la condicin NUMEROD = 5 y despus se extraern los
registros que siguen.
Estimacin del costo: Se supone que la mitad de los registros satisfacen
la condicin dando el costo c = x + b/2

Usando un ndice de segmento:


Descripcin: Si la condicin es de la igualdad en el atributo no-llave. Por
ejemplo, para la consulta OP3 si se usa el ndice de segmento con
respecto al atributo ND en la tabla de empleados.
Estimacin del costo: es c = x + s/bfr.

Usando el ndice secundario:


Descripcin: En una condicin de igualdad s registros cumplen la
condicin. Al existir el ndice secundario y no de segmento, es posible que
por cada registro se necesita acceder a un diferente bloque de datos. Si
los valores son nicos, solo se requiere un acceso.
Estimacin del costo: c = x + s para valores no nicos y c = x + 1 para
valores nicos.

Operacin de join de dos relaciones

Suponga que se necesita ejecutar la siguiente operacin join:


R A=B S

En la siguiente parte se vuelve mencioar los diferentes algoritmos vistos


anterirmente y adicionalmente, se presenta la estimacin de costo para cada

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 20


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

uno de ellos. En el clculo no se considera la grabacin de los resultados al


disco.

Ciclos anidados (nested inner-outer loop):


Descripcin: Para cada registro t de R (ciclo externo) recupera cada
registro s de la relacin S (ciclo interno) y revisa si los dos registros
satisfacen la condicin: t[A] = s[B]. Usando el pseudo-cdigo:

while (blocks in R) { /* outer loop */


read (block in R)
while (blocks in S) { /* inner loop */
read (block in S)
for (each row in R-block) {
for (each row in S-block) { no importante para
if (A = B) then join el costo
else skip }
} } }
Estimacin del costo:
bR + bR * bS. Sin embargo, si la tabla interna cabe toda en la memoria
principal, el costo se reducir a bR + bS

Si se tiene disponible nb buffers y de esto se usa 1 para ciclo interno y


nb-1 para ciclo externo, la frmula de costo cambia a:
bR + bR/( nb-1) * bS

Ciclos anidados con ndice:


Descripcin: Si existe un ndice para la relacin S sobre el atributo B de
join, se puede recuperar cada registro t de R y posteriormente usar este
ndice para recuperar los registros s de S que satisfacen la condicin t[A]
= s[B]

while (blocks in R) { /* outer loop */


read (block in R)
for (each row in block R) {
read (index tree levels)
read (record(s))
if (A = B) then join
else skip}
}

Estimacin del costo: Depende del tipo de ndice:


o ndice secundario sobre B: bR + (rR * (xB + sB))
o ndice de segmento sobre B: bR + (rR * (xB + sB/ bbfr))
o ndice primario sobre B: bR + (rR * (xB + 1))

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 21


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

sort (R) /* opcional si la tabla R ya est ordenada */


sort (S) /* opcional si la tabla R ya est ordenada */
while (blocks in R or blocks in S) {
read (block in R)
read (block in S)
for (until no more rows in tables) {
If (R.A < S.B)
get next row in (Rable1)
elseif (R.A > S.B)
get next row in (S) no importante para
else { el costo
join
get next row in (R)
get next row in (S) }
}

Estimacin del costo: bR + bS si los archivos ya estn ordenados y bR + bS


+ bR *log2bR + bS *log2bS si se necesita ordenarlos.

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.

for each row in R produce a hash


assign the hash to hash bucket
for each row in S produce hash
if the hash is already in the hash bucket
apply join

Estimacin del costo: bR + bS

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 22


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

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

Estimacin del costo: 3*( bR + bS)

Los costos pueden cambiar si se usa ms que 2 buffers para la operacin de


join.

Ejemplos de clculo de los costos:

1) EMPLEADO ND=NUMBERD DEPARTAMENTO


Suponga
rE= 10000
rD= 50
bE =2000 bloques de disco (5 reg / bloq)
bD = 10 bloques de disco (5 reg / bloq)

Nested Loop:
a) Se dispone de 2 buffers, uno para cada relacin

bE en el ciclo externo: bE + (bE * bD) = 2000 + 2000*10 = 22000


bD en el ciclo externo: bD + (bD * bE) = 10 + 2000*10 = 20010

b) Se tiene nB buffers y usamos nB1 para la relacin en el ciclo externo y 1


para la relacin en el ciclo interno:
nB = 6
bE en el ciclo externo: bE + bE /(nB 1) * bD
= 2000+(2000/5)* 10 = 2000+4000= 6000

bD en el ciclo externo: bD + bD /(nB 1) * bE


= 10+( 10 / 5 *2000) = 10+4000=4010

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 23


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

2) DEPARTAMENTO NSSGTE=NSS EMPLEADO

Suponga que el ndice secundario existe en dos relaciones (para campos


NSSGTE de la tabla Departamento y para campo NSS de la tabla Empleado) y
el nmero de niveles de dichos ndices es 2 y 4 respectivamente. Se puede
implementar join de dos formas:

a) bE en el ciclo externo bE + rE * (x NSSGTE +1) = 2000+ (10000*3 ) = 32000

ndice secundario

b) bD en el ciclo externo: bD + rD * (x NSS +1) = 10+ ( 50 * 5 ) = 260

ndice secundario

3) Merge Join

Si los archivos estn ordenados: bE + bD = 2000+10 =2010

Si los archivos no estn ordenados: (bE + bD+ bE *log2 bE + bD *log2 bD)

MergeSort MergeSort
Empleado Departamento

4) Hash
Si una de las relaciones cabe en el buffer de la memoria:
bE + bD = 2000+10 =2010

Para hybrid hash join: 3 * (bE + bD) = 3*(2000+10) = 6030

La optimizacin de consultas basada en el costo es ms apropiado para


consultas compiladas, debido a que la optimizacin se efecta en el momento
de la compilacin y el cdigo de la estrategia resultante se almacena y ejecuta
directamente en el momento de ejecucin. En las consultas interpretadas,
donde todo el proceso (construccin del rbol, optimizacin, etc.) se realiza en el
momento de ejecucin, una optimizacin puede hacer muy lenta la respuesta.

En los ejemplos anteriores, se estim los costos considerando los accesos al


disco. Sin embargo, esta estimacin se podra extender por otros componentes,
por ejemplo:
Costo de almacenamiento intermedio.
Costo de computacin.
Costo de uso de memoria.
Costo de comunicacin.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 24


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

En las situaciones reales aunque estos componentes pueden ser importantes,


resulta difcil considerarlas y la prctica comn es solo minimizar el costo de
accesos al disco, ignorando los otros factores.

Aunque para las BD de menor tamao otras componentes pueden ser


importantes, resulta difcil considerarlas y la prctica comn es tambin
minimizar el costo de accesos al disco.

La informacin necesaria para estimar los costos, se encuentra en el catlogo,


por ejemplo, el nmero de registros, el tamao medio de registro, el nmero de
bloques, factor de bloqueo, nmero de valores distintos de un atributo y su
selectividad, entre otros. Para tener mejores estimaciones es importante que el
catlogo contenga la informacin actualizada sobre los elementos que entran en
el clculo. Para tales propsitos muchos DBMSs recomiendan el uso de alguna
variante del comando UPDATE STATISTICS.

OPTIMIZACIN SEMNTICA

Se ha sugerido otros enfoques para la optimizacin de consultas, como por


ejemplo la optimizacin semntica de consultas: Esta tcnica puede usarse
en combinacin con otras tcnicas y se basa en las restricciones especificadas
sobre el esquema de BD.

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 25


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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:

Transferencia de fondos de Depsito a la cuenta A


la cuenta A a la cuenta B

READ(A); READ(A);
A = A - N; A = A + M;
WRITE(A); WRITE(A);
READ(B);
B = B + N;
WRITE(B);

El funcionamiento de las operaciones de READ y WRITE es el siguiente:

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

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 26


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

ESTADOS DE UNA TRANSACCIN

Una transaccin es una unidad atmica que se completa en su totalidad o no se


lleva a cabo en absoluto. Para fines de recuperacin y para asegurar la
consistencia de los datos, el sistema debe hacer seguimiento de los diferentes
estados de la transaccin:

BEGIN_TRANSACTION: marca el inicio de la transaccin.

END_TRANSACTION: especifica que las operaciones de READ y


WRITE se terminaron y marca el lmite de la
ejecucin de la transaccin.

READ(X) lee los datos X desde la BD y lo pone en una


variable X en la memoria.

WRITE(X) escribe el valor de la variable X de la memoria


principal a la base de datos.

COMMIT_TRANSACTION seala la ejecucin exitosa de la transaccin.

ROLLBACK (ABORT) seala que la transaccin se termin sin xito.

Podemos representar estos diferentes estados de la transaccin por medio del


siguiente grafo (ver la figura 2.1):

Figura 2.1. Diagrama de transicin de estados para la ejecucin de una


transaccin.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 27


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

EJECUCIN CONCURRENTE DE LAS TRANSACCIONES

Las transacciones pueden ejecutarse en un ambiente de un solo usuario


(monousuario) simple o mltiples usuarios. Los ambientes de un solo usuario
son normalmente de uso personal. Cuando se utiliza una DBMS en el ambiente
de mltiples usuarios, la ejecucin de las transacciones puede ser interpolada si
solo se tiene un procesador (las transacciones A y B en la figura 2.2) o paralela
si se tiene ms procesadores (las transacciones C y D en la figura 2.2).

UCP1

UCP2

tiempo
Figura 2.2. Concurrencia en ambiente multiusuario.

La ejecucin concurrente de las transacciones permite que varias de ellas


accedan simultneamente la base de datos. Esto incrementa el nmero total de
transacciones en ejecucin (throughput), permite utilizar en forma ms eficiente
el procesador y disminuye el tiempo de respuesta para las transacciones
individuales. Sin embargo, se pueden presentar varios problemas si esta
ejecucin concurrente se realiza en forma no controlada. Algunos de estos
problemas son:

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 28


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

1. The lost update problem (prdida de actualizaciones): una transaccin


sobrescribe el valor de la otra; existe la dependencia write write entre las
dos transacciones.

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

3. Unrepeatable read (lectura no repetida): una transaccin lee el valor varias


veces mientras otra transaccin lo modifica; existe la dependencia read-write
entre las dos transacciones.

T1 T2
READ(X);
T PRINT(X);
i READ(X);
e
m
X = X + M;
p WRITE(X);
o READ(X);
PRINT(X);

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 29


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

4. Phantom tuples (tuplas fantasma): una transaccin lee el valor de varias


tuplas mientras otra transaccin inserta o borra los registros.

Ejemplo:
T1 T2
SELECT * FROM Table1 UPDATE Table1 SET column2 = 10
WHERE column1 = 5 SET column1 = 5
WHERE column1 = 8

La posibilidad de que estos problemas existan hace necesario el desarrollo de


sistemas de control de concurrencia. Existen dos grandes grupos de tcnicas
de control de concurrencia que proponen evitar los problemas mencionados
anteriormente: uno basado en la planificacin a priori de la ejecucin de las
transacciones concurrentes y otra basada en reglas (protocolos) que al seguirlos
se aseguran los resultados correctos de la ejecucin concurrente de las
transacciones.

Adems de control de concurrencia es necesario asegurar que el sistema


ejecute toda la transaccin o que no ejecute nada, siendo la transaccin la
unidad de ejecucin. En un sistema perfecto eso no es ningn problema. Sin
embargo, en un sistema real pueden ocurrir diferentes tipos de fallos:

1. Fallos de la computadora: Ocurre un error de hardware o software


durante la ejecucin de la transaccin. As el contenido de la memoria
principal de puede perder.

2. El error en la transaccin o en el sistema: Errores en la transaccin


(divisin entre cero, overflow de enteros, etc).

3. Errores locales o condiciones de excepcin: Algunas condiciones pueden


ocurrir durante la ejecucin de la transaccin, por ejemplo, el dato para la
transaccin no se encuentra, el dinero no es suficiente en la cuenta
bancaria para satisfacer el retiro.

4. Refuerzo para el control de concurrencia: El sistema de control de


concurrencia decide abortar alguna transaccin para proteger el sistema
de posibles inconsistencias.

5. Fallo del disco: Partes del disco que perdien datos por causa de las fallas
fsicas.

6. Problemas fsicos y catastrficos: Descarga elctrica, terremotos,


inundaciones, etc.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 30


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Los errores tipo 1, 2, 3 y 4 ocurren ms a menudo que los problemas 5 y 6. La


idea principal es mantener la suficiente informacin para recuperar el sistema de
los fallos tipo 1-4. De esto se encarga el sistema de recuperacin.

PROPIEDADES DESEABLES DE UNA TRANSACCIN

Para asegurar que las transacciones devuelvan resultados correctos despus de


su ejecucin, se establecieron las propiedades llamadas ACID por las
correspondientes letras en ingls:

Atomicity (atomicidad) la transaccin es una unidad atmica de


ejecucin; se ejecuta toda o no se ejecuta
nada. El sistema de recuperacin es el
responsable de esta propiedad. Si por alguna
razn una transaccin no puede completarse,
por ejemplo, una cada del sistema en mitad
de la ejecucin, el mtodo de recuperacin
deber cancelar todo lo ejecutado por la
transaccin.

Consistency (consistencia) la ejecucin correcta de la transaccin debe


llevar la base de datos de un estado
consistente a otro. El sistema de control de
concurrencia y el programador son los
responsables de esta propiedad.

Isolation (aislamiento) la transaccin no debe hacer visible las


modificaciones a otra transaccin hasta que no
se haga commit. El sistema de control de
concurrencia es el responsable de esto.

Durability (permanencia) si la transaccin cambia algunos datos en la


base de datos y tiene commit, estos cambios
no pueden perderse por culpa de fallos del
sistema. El sistema de recuperacin es el
responsable de esto.

Como se puede ver, el sistema de control de concurrencia y el sistema de


recuperacin son muy importantes para el funcionamiento de un sistema de
base de datos.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 31


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

CONTROL DE CONCURRENCIA BASADO EN CANDADOS

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:

read_lock(A) (Slock(A)): candado compartido (share, S) o de lectura


write_lock(A) (Xlock(A)): candado exclusivo (exclusive, X) o de escritura
unlock(A): liberacin del candado

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

La conversin puede ser de promocin (de candado S a candado X) o de


degradacin (de candado X a candado S). Por ejemplo, una transaccin T
solicita Slock(A) y ms tarde antes de grabar el dato A lo convierte en candado
Xlock(A). Esto permite un mayor grado de transacciones concurrentes
accediendo el mismo dato.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 32


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

El candado U (update) se solicita cuando se lee el dato con la intencin de la


futura escritura sobre l. El candado U es compatible con el candado S, esto es,
si un dato A es ledo por la transaccin T1, la transaccin T2 puede solicitar el
candado U sobre este dato. Sin embargo, no existe la compatibilidad inversa, o
sea, cuando la transaccin T1 tiene asignado el candado U sobre el datos A,
ninguna otra transaccin puede solicitar el candado S.

La siguiente tabla resume la compatibilidad de los candados:

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:

Tenemos las dos siguientes transacciones:

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);

Suponiendo los valores iniciales son: X = 20 y Y = 30 si las transacciones se


ejecuta en serie T1 y despus T2 obtenemos: X = 50 y Y = 80; si se ejecutan T2
y despus T1 obtenemos X = 70 y Y = 50.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 33


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Sin embargo la ejecucin concurrente de la siguiente forma:

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);

da resultados X = 50 y Y = 50 que no corresponden a ningn resultado de


ejecucin de estas transacciones en serie.

PROTOCOLO DE TWO-PHASE LOCKING (2PL)


Para que el uso de los candados asegure seriabilidad se necesita algn
protocolo que establezca las reglas sobre la utilizacin de los candados. Uno de
los protocolos ms conocidos se llama Two Phase Locking (2PL). Su nombre
indica que este protocolo divide la transaccin en dos fases:

Fase de crecimiento (expanding): los nuevos candados pueden ser


solicitados, pero ningn candado puede ser liberado. Si se permite la
conversin de los candados, en esta fase solo se puede usar la
promocin de los candados (de lectura a escritura).

Fase de encogimiento (shrinking): los candados existentes pueden ser


liberados pero nuevos candados no pueden ser solicitados. Si se permite
la conversin de los candados, en esta fase solo se puede usar la
degradacin de los candados (de escritura a lectura).

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 34


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Ejemplo:

T1
SLOCK(Y);
READ(Y);
XLOCK(X);
UNLOCK(Y);
READ(X);
X = X+Y;
WRITE(X);
UNLOCK(X);

Si cada transaccin de una planificacin obedece el protocolo de 2PL, la


planificacin es serializable. Como puede verse en el ejemplo anterior, la
ejecucin de dos transacciones concurrentes no sigue este protocolo y da
resultados incorrectos. Aunque el protocolo de 2PL puede limitar la cantidad de
concurrencia que puede darse en el sistema, asegura obtener los resultados
correctos.

El protocolo descrito anteriormente se llama 2PL bsico. Adems, existen otras


variaciones de este protocolo:

2PL estricto: se da la fase de crecimiento al igual que en el 2PL bsico,


sin embargo, no liberar sus candados hasta que no se confirme o aborte
la transaccin. De esta forma la transaccin retiene los candados,
aunque ya puede no usar algunos de los datos

2PL conservativo: requiere que una transaccin bloquee todos los


elementos a los que tendr acceso antes de comenzar a ejecutarse. Si
no es posible bloquear alguno de los elementos necesarios, la
transaccin no bloquear ningn elemento; en vez de ello esperar hasta
que todos los elementos estn disponibles para bloquearlos.

# de candados # de candados # de candados

time time time


Begin Commit Begin Commit Begin Commit
Trans. Trans. Trans. Trans. Trans. Trans.
a) b) c)

Figura 3.1. Protocolo de 2PL: a) bsico, b) estricto y c) conservativo

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 35


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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

El protocolo de 2PL se refina cuando el sistema permite la conversin de


candados o uso de candados U.

Fase de crecimiento (expanding):


o Se puede solicitar los candados S, U o X
o Se puede convertir los candados S o U a candados X

Fase de encogimiento (shrinking):


o Se puede liberar los candados S o X
o Se puede convertir los candados X a candados S.

La adquisicin de candados se hace en forma automtica sin llamada explcita.


Existe una componente de software llamada lock manager (gestor de candados)
que se encarga de esto. Este gestor ejecuta lo siguiente para la operacin de
read(A):

if Ti tiene candado sobre A


then
read(A)
else begin
if necesario, espera liberacin del candado X sobre A;
asigna el candado S sobre A para la transaccin Ti;
read(A)
end

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 36


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Para la operacin de write(A):

if Ti tiene candado X sobre A


then
write(A)
else begin
if necesario, espera liberacin de cualquier candado sobre A;
if Ti tiene el candado S o U sobre A
then
upgrade al candado X sobre A
else
asigna el candado X sobre A para la transaccin Ti;
write(A)
end

Todos los candados son liberados despus de hacer commit o abort.

El lock manager puede ser implementado como un proceso separado hacia el


cual las transacciones envan mensajes solicitando o liberando los candados.
Este proceso utiliza lo que se llama lock table (tabla de candados). Esta tabla es
indexada (o hash) por nombre del elemento que est actualmente bloqueado
(elementos I7, I23, I912, I4, e I44 en la figura 3.2). Para cada uno de estos
elementos se mantiene una lista enlazada con los identificadores de las
transacciones que solicitan el dato siguiendo el orden de llegada de las
solicitudes (por ejemplo, T1, T8 y T12 solicita el dato I23 en la figura 3.2). Se
anota que tipo de candado se solicita y si ya se concedi el candado (en la figura
3.2 el no concedido es de color blanco y el concedido de color negro). Por
ejemplo, en la figura 58 se puede ver que la transaccin T23 ha concedido los
candados para datos I7, I912 y est en espera al candado sobre el dato I4.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 37


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Figura 3.2. Tabla de bloques.

El gestor de bloqueos procesa la solicitud de la siguiente manera:


Cuando llega una solicitud nueva:
o Si ya existe la cola para el dato
Aade el registro al final de la cola de espera con el
identificador de la transaccin y el tipo de candado
solicitado.
Verifica la compatibilidad entre el candado ya adquirido por
otra transaccin y el solicitado. Si los candados son
compatibles, concede el candado sobre el dato para la
nueva transaccin. En otro caso, espere la liberacin del
candado.
o Si no existe la cola:
Crea una nueva lista enlazada poniendo el registro con el
identificador de la transaccin que lo solicita y el tipo de
candado.
Asigna el candado a la transaccin que lo solicita
Cuando llega una solicitud de desbloqueo:
o Borra el registro de la cola que corresponde a la transaccin que
solicit desbloqueo.
o Verifica la existencia de otras solicitudes en la cola y la
compatibilidad de candados que se solicitan para determinar si
ahora se puede conceder la solicitud. Si se puede, se concede el

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 38


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

candado y se procesa de manera similar la siguiente solicitud en la


cola.
Cuando llega una solicitud de aborto de una transaccin:
o Borra cualquier solicitud en espera realizada por la transaccin.
o Cuando el sistema de recuperacin lo indique, libera todos los
candados que mantena la transaccin abortada.

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.

USO DE CANDADOS PARA CONTROL DE CONCURRENCIA EN LOS


NDICES

El control de concurrencia se podra aplicar a la estructura de ndice


considerando cada pgina de ndice como un elemento de datos y aplicando el
protocolo de 2PL. De esta forma en lugar de bloquear la pgina donde est el
dato se realiza el bloqueo en la pgina de ndice. Esto introduce dos
restricciones:
Cada relacin tiene que tener por lo menos un ndice.
Cada transaccin puede acceder las tuplas solamente despus de
encontrarlas en uno o ms ndices existentes para la relacin.

Sin embargo, los ndices se acceden de manera frecuente, particularmente en


los niveles altos del rbol y de esta forma el ndice se podra convertir en un
cuello de botella o dar origen a un deadlock (bloque mutuo). Afortunadamente,
no es necesario tratar de la misma forma a los ndices que a los datos ya que es
aceptable que una transaccin busque dos veces en un ndice encontrando cada
vez una estructura diferente de ndice. Por esta razn, se utilizan protocolos
diferentes para controlar accesos concurrentes a ndices.

Existen varias tcnicas para el control de concurrencia aplicado a ndices. Una


de ellas llamada crabbing (protocolo de cangrejo) establece lo siguiente:
Cuando se busca un valor en ndice
o Primero se pone el candado sobre el nodo raz en modo
compartido.
o Recorriendo el rbol hacia abajo, se adquiere un nuevo candado
sobre el nodo hijo tambin en modo compartido.
o Se libera el candado en el nodo padre.
o Se repite este proceso hasta alcanzar el nodo hoja.
Cuando se inserta o borra un valor en el rbol de ndices:
o Se sigue el mismo protocolo que para la bsqueda hasta alcanzar
el nodo hoja deseado.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 39


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

o Se pone candado sobre el nodo hoja en modo exclusivo (X) y se


inserta o borra el valor llave.
o Si se necesita dividir un nodo o fusionarlo con sus hermanos, o
distribuir los valores llave entre hermanos, se bloquea el nodo
padre en el modo exclusivo.
o Si el padre requiere divisin, fusin, o redistribucin de valores
llaves, se sigue propagando la adquisicin de candados de la
misma manera.
o Despus de realizar las acciones de transformacin del rbol se
liberan los candados.

Como se puede ver, el presente protocolo se considera optimista (con respecto


a las operaciones de modificacin) ya que solo utiliza candados compartidos
conforme avanza en el rbol, con la esperanza que al llegar al nodo hoja
encuentra espacio para, por ejemplo, insertar un nuevo valor. Otra variante
pesimista de este protocolo utiliza los candados exclusivos desde la raz hasta
las hojas y solo si encuentra el espacio en la hoja (o sea no necesita hacer
divisiones, fusiones, o redistribuciones) libera estos candados. Como se puede
notar, con el protocolo pesimista, se disminuye considerablemente el nivel de
concurrencia.

Los candados sobre el ndice ofrecen la solucin para eliminar el problema de


tuplas fantasmas. Note que utilizando los ndices sobre las pginas de datos,
sera necesario poner candado a toda la tabla para evitar este problema. Esto
disminuira considerablemente el nivel de concurrencia.

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 40


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

GRADOS DE AISLAMIENTO (NIVELES DE CONSISTENCIA)


El concepto de serialibilidad es un concepto muy importante para asegurar que
las transacciones que se ejecutan en forma concurrente, dejen la base de datos
en forma consistente. Sin embargo, es posible que los protocolos que se
necesitan para garantizar la seriabilidad, permitan un nivel de concurrencia muy
limitado. Debido a esto surgieron los niveles de aislamiento que determinan el
tipo de problema de concurrencia que el sistema puede tolerar (lost update, dirty
read, unrepeatable read, phantom tuples) para la ejecucin de la transaccin. En
consecuencia, delegan al programador la responsabilidad sobre la consistencia
de la BD y las posibilidades de recuperacin.

Los niveles de aislamiento sirven para establecer:


Lo sensible que ser aplicacin a los cambios realizados por otras
transacciones.
Cuando tiempo tendr que mantener la transaccin los candados para
protegerse de los cambios realizados por los otros.
Nmero de transacciones concurrentes admitidas en el sistema

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 41


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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);

GRADO 1: Read uncommited (Browse)


No existe el problema de lost update.
Se pueden dar los problemas de dirty read, unrepeatable read y phantom
tuples.
No existen los candados S.
Se usan los candados largos de X y se usa el protocolo 2PL con
respecto a operaciones write.
Se pueden recuperar las transacciones.
Se usa en los anlisis, revisin de la situacin general, Internet, donde no
importa la precisin de los datos.

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);

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 42


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

GRADO 2: Read committed (cursor stability)


No existe el problema de lost update ni de dirty read.
No se garantiza repeatable read y pueden aparecer las tuplas fantasmas.
Existen los candados cortos de S.
Existen los candados largos de X.
Se sigue el protocolo de 2 PL con respecto a las escrituras.
Se pueden recuperar las transacciones.
Se usa cuando la transaccin no requiere volver a leer los mismos datos
de nuevo, por ejemplo, las transacciones con solo una sentencia de SQL

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 3: Repeatable read


No existe el problema de lost update, dirty read o unrepeatable read.
Puede darse el problema de tuplas fantasmas.
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.
Se usa en las transacciones que contienen las condiciones sobre una
tupla simple.

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 43


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

El menor grado de concurrencia.


Es el nivel por defecto de SQL estndar.
DBMS tiene que poner los candados al nivel de la tablas o usar los
protocolos basados en diferentes granularidades o candados de key
range.
Se usa en aplicaciones crticas, donde es importante la precisin de
datos, por ejemplo, en reportes bancarios de todas las cuentas.

En resumen, dependiendo de los niveles de aislamiento se pueden dar o no


los siguientes problemas:

Isolation level Lost update Dirty read Unrepeatable Phantom


read tuples
Read No Si Si Si
uncommitted
Read No No Si Si
committed
Repeatable No No No Si
read
Serializable No No No No

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 44


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

PROTOCOLO DE GRANULARIDAD MLTIPLE


En el protocolo de concurrencia anterior se vio el caso cuando el bloqueo se
hace en el nivel de dato. Sin embargo, podran existir situaciones donde es
recomendable agrupar los datos y tomarlos como una unidad de sincronizacin
para la reservacin de los candados. Por ejemplo, si una transaccin necesita
acceder toda la base de datos se tendra un overhead muy grande para la
peticin y liberacin de los candados.

Adems, se necesita ms espacio en el disco para guardar la tabla con la


informacin sobre los datos ocupados por las transacciones. En general
podemos distinguir diferentes tamaos de los elementos para la peticin del
candado. Este tamao se denomina con frecuencia granularidad. La figura 3.3
presenta la BD en forma de rbol donde cada nivel se refiere a una diferente
granularidad de los elementos.

BD

file1 file2 filen

blo1 blo2 blom

r1 r2 rk

Figura 3.3. La BD representada como un rbol de elementos de diferente


granularidad.

La granularidad fina se refiere al dato (registro), mientras que la granularidad


gruesa se refiere a los elementos grandes (archivos, base de datos). Por
ejemplo, en SQL Server si se modifica un nmero grande de registros el bloqueo
se har a nivel de bloque o tabla; si el acceso es a un registro especfico el
bloqueo ser a nivel de registro, por ejemplo una transaccin de la cuenta de un
cliente.

En este tipo de control de concurrencia se utilizan nuevos candados llamados


candados de intencin. Estos candados indican, en los niveles ms altos del
rbol, la existencia de candados explcitos en niveles ms bajos. De esta forma,
las transacciones en ejecucin concurrente no ocupan descender el rbol para
verificar si es posible adquirir un candado. Existen tres tipos de candados de
intensin:
Intencin compartida (IS): indica que se solicitar un (o varios) candado
compartido en algn (o varios) nodo descendiente.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 45


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Intencin exclusiva (IX): indica que se solicitar un (o varios) candado


exclusivo en algn (o varios) nodo descendiente.
Compartido con intencin exclusiva (SIX): indica que el nodo actual
est bloqueado en modo compartido, pero se solicitar un (o varios)
candado exclusivo en algn (o varios) nodo descendiente.

El protocolo de concurrencia de granularidad mltiple funciona de la siguiente


forma:

1. Se adquieren los candados de la raz a las hojas.


2. Se liberan los candados de las hojas a la raz.
3. Para adquirir el candado en el modo S o IS en un nodo no raz, el padre
tiene que tener el modo IS o mayor (IX, S, SIX, U, X).
4. Para adquirir un candado de tipo X, U, SIX o IX todos los padres tienen
que estar en modo IX o mayor ((X, SIX, U, X).
5. Para la adquisicin de los candados en cada uno de los niveles se debe
cumplir con la siguiente tabla de compatibilidad:

La siguiente tabla resume la compatibilidad de los candados usados en el


protocolo de concurrencia de granularidad mltiple:

ADQUIRIDO
MODO Ninguno IS IX S SIX U X
SOLICITADO
IS + + + + + - -
IX + + + - - - -
S + + - + - - -
+ compatible
SIX + + - - - - -
U + - - + - - -
X + - - - - - -

Por ejemplo, si se quiere poner un candado X a un registro, los niveles


antecedentes en el rbol tienen que tener el candado IX (intencin de escritura).
Si la otra transaccin quiere usar el mismo camino del rbol puede poner los
candados IS o IX, pero no puede poner ningn candado especifico (S, U o X)
sobre el mismo elemento del rbol.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 46


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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);

Existen dos acercamientos para tratar los deadlocks:


Prevencin.
Deteccin y recuperacin.

Protocolos de prevencin de deadlocks:

La prevencin de los bloqueos puede realizarse usando:

Candados: se emplea el protocolo conservador de 2PL. La transaccin


bloquea todos los candados que necesita antes de comenzar su ejecucin. Si
alguno de los candados no se puede obtener, ningn dato se bloquea (la
transaccin espera).

Estampillas de tiempo (timestamps, TS): cada transaccin tiene asignado un


identificador basado en el orden en el cual las transacciones comenzaron su
ejecucin llamado estampilla de tiempo. Si T1 comenz antes que T2
entonces TS(T1) < TS(T2). En otras palabras la transaccin ms vieja tiene
TS ms pequeo.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 47


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

Si la transaccin que solicita recursos es ms vieja, se le permite esperar


hasta que se liberen los recursos. Si la transaccin es ms joven, debe
abortar y reiniciar su ejecucin con la misma estampilla de tiempo. Esto le
asegura que en algn momento adquiere el estatus de la transaccin vieja y
se le permite esperar los recursos.

wound-wait (herir-esperar)
if TS(Ti) < TS(Tk)
then aborte Tk y reinicie con el mismo TS
else Ti espera

Si la transaccin que solicita recursos es ms vieja, sta hiere a la ms joven


(la obliga a abortar) y obtiene recursos para su ejecucin. La transaccin
abortada, reinicia su ejecucin con la misma estampilla de tiempo,
asegurando de esta forma pasar al estatus de ms vieja y esperar por los
recursos. Si la transaccin que solicita los recursos es ms joven, se le
permite esperar hasta que la transaccin ms vieja libere los recursos.

Ambos esquemas hacen que se aborte la ms reciente de las dos


transacciones que podran interferir en el deadlock. Sin embargo, ambas
hacen que algunas transacciones se aborten y reinicien a pesar de que tal
vez nunca provoquen realmente un deadlock.

Limitacin del tiempo (timeout): si la transaccin espera ms de un tiempo


preestablecido por el sistema se asume que la transaccin se paraliz y se
aborta, aunque pueda ser que no existe ninguna situacin real de
paralizacin.

Protocolos de deteccin de deadlocks

Si el sistema no utiliza algn protocolo de prevencin de los deadlocks, entonces


se debe usar un esquema de deteccin y recuperacin. Peridicamente se
invoca un algoritmo que examina el estado del sistema para determinar si hay un
deadlock. Estos dedlocks se pueden describir por medio de la construccin de
un grafo de espera donde se seala que una transaccin especfica espera
datos que otra transaccin est ocupando.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 48


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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:

Se elige la vctima para abortar la transaccin; normalmente la vctima es:


o La transaccin ms joven que participa en el ciclo del grafo.
o La transaccin que no haya ejecutado muchas actualizaciones.
o La transaccin que participe en ms de un ciclo de deadlock.
Se retrocede esta transaccin; se debe considerar el:
o Retroceso total: se aborta la transaccin y se vuelve ejecutar.
o Retroceso parcial: solo se aborta la parte que permite la liberacin
de candado conflictivo. Para esto se necesita informacin adicional
sobre el estado de todas las transacciones que estn en ejecucin.
Se inicia otra vez o sigue con la ejecucin a partir del punto hasta donde
se hizo aborte parcial.

La seleccin de la vctima puede llevar a inanicin, si siempre se escoge la


misma transaccin como vctima. Por esta razn, se debe asegurar que una
transaccin pueda elegirse como vctima slo un nmero finito (y pequeo) de
veces.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 49


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

CONTROL DE CONCURRENCIA BASADO EN ESTAMPILLAS DE TIEMPO


La idea de desarrollar este tipo de protocolos surgi debido al overhead
relacionado con el manejo de peticiones y liberaciones de candados y posibles
problemas de deadlocks que pueden ocurrir en el sistema.

Estampillas de tiempo (timestamps, TS) es un identificador nico generado


por la DBMS de acuerdo al orden en el que las transacciones entraron en el
sistema. Existen dos mtodos simples para implementar las estampillas de
tiempo:
Usar el valor de reloj del sistema: a cada transaccin que entra en la
ejecucin se le asigna el valor actual del reloj.
Usar un contador lgico: a cada transaccin que entra en la ejecucin se
le asigna un valor nuevo establecido como siguiente por el contador.

Estas estampillas se usan para establecer el orden en la ejecucin de las


operaciones de las transacciones concurrentes. Por ejemplo, si TS(Ti) < TS(Tk),
entonces el sistema debe asegurar que toda planificacin que produzca sea
equivalente a una planificacin en serie en la cual la transaccin Ti aparezca
antes de la transaccin Tk.

Protocolo de ordenacin por estampillas (marcas) temporales

Para implementar este sistema, se asocia a cada elemento de datos D dos


estampillas adicionales:
TS_read(D): ms grande TS dentro de todas las TS de las transacciones
que leyeron el dato D con xito.
TS_write(D): ms grande TS de todas las TS de las transacciones que
escribieron el dato D con xito.

Cada vez que la transaccin T trata de leer o escribir el dato D el algoritmo de


timestamp ordering (ordenamiento de estampillas de tiempo) asegura que el
orden establecido de TS no se viola. Si el orden es violado (sera una ejecucin
no serializable) la transaccin T se aborta y se hace un restart con una nueva
TS. Si la transaccin Ti es abortada y canceladas sus operaciones (valores que
guard) y otra transaccin Tk us estos valores, ella tambin tiene que ser
abortada. Esto se llama cascading rollback (anulacin en cascada) y es el
problema principal de este protocolo.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 50


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

La violacin de orden de TS se da en dos casos:


1. Transaccin T quiere hacer write(D):

if TS_read(D) > TS(T) or TS_write(D) > TS(T)


then aborta T, haga rollback y reinicie con el nuevo TS
else ejecuta write(D) y ponga TS_write(D) = TS(T)

2. Transaccin T quiere hacer read(D):


if TS_write(D) > TS(T)
then abort, rollback y restart con el nuevo TS
else ejecuta read(D) y ponga TS_read(D) = max (TS(T), current
TS_read(D))

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);

Suponemos que a la transaccin se le asigna TS inmediatamente antes de la


ejecucin de la primera instruccin. De esta forma TS(T1) < TS(T1).

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)

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 51


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

La ventaja de este protocolo es que asegura la ejecucin serializable y no da


deadlocks; sin embargo, este protocolo puede dar el problema de inanicin
cuando la transaccin es continuamente abortada y vuelve a comenzar su
ejecucin. Adems, no se garantiza la planificacin recuperable y la ausencia de
cascading rollback. Para evitar estos problemas existen variantes de este
protocolo. En este caso si la transaccin T2 quiere realizar una operacin de
read(A) o write(A) de modo que TS_read(A)<TS(T2) (o sea, T2 tiene derecho de
leer o escribir), atrasa su operacin de escritura o lectura hasta que la
transaccin T1 que modific el valor de A haga el commit o abort. Para
implementar esto, es necesario simular el candado sobre el dato A que ha sido
modificado por la transaccin T1 hasta que sta haga commit o abort. Esta
variante del protocolo no provoca deadlock ya que T2 espera por T1 solo si
TS(T2) >TS(T1).

Existen otras modificaciones de este protocolo que aseguran aumentar el nivel


de concurrencia.

Protocolo de ordenacin por estampillas temporales multiversin

Los protocolos descritos hasta ahora aseguran la seriabilidad retrasando la


operacin (2PL) o abortando la transaccin (ordenacin por estampillas de
tiempo). En los esquemas de control de concurrencia multiversin se utiliza un
mtodo diferente donde cada operacin de write(D) crea una nueva versin de
D. Cuando se realiza una operacin de read(D), el gestor de control de
concurrencia debe elegir la versin adecuada para asegurar la ejecucin
serializable.

De forma parecida al protocolo anterior, a cada transaccin se le asigna su


estampilla de tiempo TS. La diferencia consiste en que a cada dato D se le
asocia una secuencia de versiones (D1, D2, Dn). Cada versin Di tiene tres
campos:
Contenidoi: valor D de la versin i
TS_write(Di): TS de la transaccin que cre (escribi) la versin Di
TS_read(Di): el mayor TS de todas las transacciones que hayan ledo con
xito la versin Di

En otras palabras, cuando la transaccin Tj crea una nueva versin Dj (escribe el


nuevo valor D), TS_write(Dj) = TS(Tj) y TS_read(Dj) = TS(Tj). Cuando la
transaccin Tk lee el dato Dj y TS_read(Dj) < TS(Tk), entonces TS_read(Dj) =
TS(Tk).
No es necesario guardar todas las versiones viejas. Se pueden borrar estas
versiones donde TS_write(Di) < TS(Tms antigua en el sistema).

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 52


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

El protocolo de ordenacin de estampillas de tiempo multiversin asegura la


ejecucin serializable y sigue las siguientes condiciones:

Si la transaccin Ti emite una operacin de read(D)


o Se busca la versin de Dk con max(TS_write(Dk) ) < = TS(Ti)
o Se establece la marca de TS_read(Dk) = max (TS(Ti),
TS_read(Dk))
Si la transaccin Ti emite una operacin de write(D)
o Se busca la versin de Dk con max(TS_write(Dk) ) < = TS(Ti)
o If TS_read(Dk) > TS(Ti)
then aborta Ti
else crea una nueva versin de D y establezca la marca de
TS_read(Dk) = TS_write(Dk) ) = TS(Ti)

Observe que la operacin de lectura no tiene que esperar ya que la versin


apropiada de datos se accede inmediatamente. La operacin de escritura se
rechaza si alguna otra transaccin ms joven ley el dato (la escritura lleg
demasiado tarde).

Este protocolo asegura la planificacin serializable, sin embargo, puede darse el


problema de cascading rollback. Adems, la lectura del dato demanda tambin
la actualizacin de su respectivo TS_read, lo que puede incrementar el nmero
de accesos al disco.

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.

CONTROL DE CONCURRENCIAS BASADAS EN VALIDACIN


En los protocolos de control de concurrencia anteriores se realiza la
comprobacin (de candados o TS) antes de ejecutar la operacin. En este tipo
de ambientes se supone que las transacciones pueden entrar en conficto
frecuentemente (muchas escrituras) y se necesita una proteccin adecuada.
Este tipo de protocolos pertenecen al grupo de tcnicas pesimistas.

Al contrario, las tcnicas de control de concurrencia optimistas, se basan en la


suposicin que en algunos sistemas con muchas transacciones de lectura
pueden existir muy pocos conflictos. Por ejemplo, las aplicaciones relacionadas
con catlogos de productos donde muchas transacciones pueden solo leer la
informacin sobre el precio y descripcin de los productos. Para este tipo de
sistemas se podra mantener la consistencia sin usar ningn control de
concurrencia. Esto podra reducir la sobrecarga relacionada con la ejecucin de
cdigo referente al control de concurrencia.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 53


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

El protocolo optimista basado en validacin no realiza ninguna comprobacin


mientras la transaccin se encuentre en ejecucin. Cuando una transaccin
desea confirmar los cambios realizados, se verifica si se ha producido un
conflicto. Si lo ha habido, la transaccin deber ser anulada y reiniciada.

Para poder realizar las operaciones, se asume que cada transaccin Ti se


ejecuta en dos o tres fases diferentes dependiendo si es una transaccin de solo
lectura o de modificacin:
1. Fase de lectura: la transaccin puede leer los valores, los cuales se
almacenan en variables locales. Todas las operaciones de modificacin se
aplican a variables locales sin actualizar la base de datos. Como
consecuencia, otras transacciones no ven los cambios aplicados a los datos.
Note que al final de esta fase, se conoce el conjunto de atributos que se ley
y sobre los cuales es posible que se ejecute la escritura.
2. Fase de validacin: la transaccin est lista para hacer commit y verifica si
se puede copiar a la base de datos las variables locales que tienen los
resultados de modificaciones sin causar una violacin de la serializabilidad.
Si no es el caso, la transaccin aborta. Si no hay violacin, se pasa a la
siguiente fase.
3. Fase de escritura: las modificaciones locales se aplican a la base de datos.
Start Validation Finish

La fase de validacin requiere el uso de tres estampillas de tiempo TS asignadas


a cada transaccin:
Start(Ti): momento en el cual la transaccin Ti comienza su ejecucin.
Validation(Ti): momento en el cual la transaccin Ti termina su fase de
lectura y comienza su fase de validacin.
Finish(Ti): momento en el cual la transaccin Ti termina su fase de
escritura.

Para pasar el test de validacin, se considera el concepto de serializabilidad


buscando las condiciones donde si TS(Ti) < TS(Tj), la transaccin Ti realiza sus
operaciones primero que la transaccin Tj. Esto se garantiza cuando para TS(Ti)
< TS(Tj) al menos una de las siguientes condiciones es cierta:

1. Finish(Ti) < Start(Tj): todas las transacciones con estampillas de tiempo


ms antiguas terminaron antes de que la nueva transaccin iniciara

Ti
Tj

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 54


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

2. Start(Tj) < Finish(Ti) < Validation(Tj): la transaccin Tj comenz antes de


que terminara la transaccin Ti con una condicin adicional de que la
validacin de Tj se realiz despus de la terminacin de la transaccin Ti y
el conjunto de datos escritos por la transaccin Ti no corresponde al
conjunto de datos ledos por la transaccin Tj
Ti
No tems comunes
Tj

3. Start(Tj) < Finish (Ti): la transaccin Tj comenz antes de que terminara la


transaccin Ti y ni el conjunto de lectura ni el conjunto de escritura de la
transaccin Tj tienen elementos comunes con el conjunto de escritura de
Tj.
Ti
No tems comunes
Tj

Este protocolo evita el cascading rollback ya que la anulacin afecta solo la


copia local y se retrocede solo la transaccin que entr en conflicto. Sin
embargo, existe la posibilidad de inanicin de las transacciones largas debido a
la presencia de transacciones cortas que pueden producir conflictos y provocar
reinicios repetidos de la transaccin larga.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 55


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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

As, si la transaccin T1 ejecuta la escritura sobre un dato A y lo modifica del


valor 5 a 10, la entrada a la bitcora tendra el siguiente registro:
< T1, write, A, 5, 10>

Tambin se especifican otros sucesos importantes de procesamiento de


transacciones:
<Ti, begin> comienza de la ejecucin de la transaccin
<Ti, commit> termina exitosamente la ejecucin de la transaccin
<Ti, abort> aborto de la ejecucin de la transaccin
<Ti, rollback> cancela la ejecucin de todas las operaciones de la
transaccin
<Ti, savepoint> marca el punto hasta el cual se puede rollback la
transaccin
<Ti, checkpoint> escribe al disco todas las modificaciones hechas
hasta el momento

Durante el procesamiento de las transacciones, cada solicitud de


lectura/escritura involucra el manejador de buffer (DB buffer manager en la figura
4.1) como se explic anteriormente para el procesamiento de consultas y
tambin manejador de recuperacin (recovery manager, RM en la figura 4.1). En
la memoria principal adems del buffer para datos existe un buffer que
representa los registros de la bitcora para las transacciones que actualmente

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 56


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

estn en ejecucin (Log buffer en la figura 4.1). Cuando la transaccin modifica


los datos, estas modificaciones primero se representan en la bitcora de
memoria principal (Log buffer en la figura 4.1) y despus en el buffer de los
datos (DB buffers en la figura 4.1). Tanto la informacin de la bitcora como la
de los datos debe pasar al disco (Stable log y stable DB en la figura 4.1). Los
protocolos que primero graban la informacin en la bitcora y despus en la
base de datos se llaman Write Ahead Logging (WAL).

Como ejemplo de la aplicacin real, observe en la figura 4.2 un ejemplo de la


arquitectura de Oracle y la existencia de los dos tipos de bfers (datos y
bitcora) y alamacenamientos estables.

Figura 4.1. Los elementos de bitcora y datos en la memoria principal y disco.

Figura. 4.2 Ejemplo de la arquitectura simplificada de Oracle.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 57


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Ejemplo:

Suponga que tenemos las siguientes transacciones:


T1 T2
READ(D); READ(B);
D = D + 15; B = B + 8;
WRITE(D); WRITE(B);
READ(D);
D = D + 5;
WRITE(D);

Si las transacciones se ejecutan en serie, se crea la siguiente bitcora:

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

Despus de la falla, el sistema de recuperacin lee la bitcora que se encuentra


en el disco desde el final hasta el principio (simplificando un poco la explicacin)
y realiza diferentes pasos de recuperacin de acuerdo al protocolo usado por la
DBMS.

DIFERENTES TCNICAS DE MODIFICACIN Y RECUPERACIN


Los pasos de recuperacin del sistema dependen de las tcnicas usadas para la
modificacin o actualizacin del sistema.
Las actualizaciones diferidas - no se actualiza la BD hasta despus del
commit da la transaccin.
Las actualizaciones inmediatas la BD puede ser modificada antes de
que la transaccin obtenga su commit.

Las tcnicas de recuperacin se refieren a las acciones necesarias para las


transacciones que fallaron en su ejecucin (no tienen commit en la bitcora) y
las que se realizaron con xito (tiene commit en la bitcora). Dependiendo de la
tcnica, puede ser necesario deshacerse de los cambios realizados por la

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 58


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

transaccin fallida (UNDO) o no hacer nada (NO-UNDO) y regrabar los datos


(REDO) para la transaccin exitosa o no hacer nada (NO-REDO).

Por ltimo existe la tcnica llamada paginacin en la sombra (shadow paging)


que no requiere la existencia de la bitcora.

Actualizaciones diferidas:

Cuando la transaccin escribe algo sobre un dato, este cambio se guarda en el


buffer y no se actualiza la base de datos inmediatamente. La actualizacin se
hace de la siguiente forma:
Primero se guardan los cambios en la bitcora antes del commit de la
transaccin.
Despus se graba el commit en la bitcora.
De ltimo se escriben los cambios en la base de datos.

Cuando el sistema falla, algunas de las transacciones pueden tener commit en la


bitcora y para otras esta entrada no existe (el sistema fall antes de terminar la
transaccin). Durante el proceso de recuperacin se revisa la bitcora y se
realizan las siguientes acciones:
Si la transaccin no tiene commit en la bitcora, no se necesita hacer
nada porque la base de datos no se modific. Esta parte del protocolo se
llama NO-UNDO (no deshacer los cambios).
Si la transaccin tiene commit se necesita reflejar los cambios en la BD
porque no existe seguridad que estos cambios ya se representaron en la
BD. Esta parte del protocolo se llama REDO (rehacer los cambios). La
forma de grabar los resultados en la base de datos debe ser
idempotente, es decir, guardar los resultados varias veces debe ser lo
mismo que grabarlos la primera vez.

Este protocolo tiene nombre NO-UNDO/REDO y, como puede verse, la bitcora


requiere solo los valores AFIM (after image), o sea, valores nuevos producidos
por las transacciones.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 59


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Ejemplo (solo se seala las operaciones de read y write)

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

Durante la recuperacin se analiza la bitcora desde la ltima grabacin:


Como la transaccin T2 no tiene commit, se inserta <T2,abort> en la
bitcora y no se aplica ningn cambio en la BD.
Como la transaccin T1 tiene commit se vuelve a grabar el valor 20 en la
BD porque existe la posibilidad de que todava no se haya grabado o el
fallo pudo ocurrir durante la grabacin desde la bitcora a la BD.

Actualizaciones inmediatas

Cuando la transaccin escribe algo sobre un dato, este cambio se guarda en el


buffer y tambin inmediatamente se modifica la BD sin importar que la
transaccin todava no tenga su estado de commit. Las actualizaciones se
pueden hacer de dos formas dependiendo de cundo se graba el commit en la
bitcora:
Primero se guardan los cambios en la bitcora.
Despus se modifica la BD.
Al final se graba el commit en la bitcora usando una de las opciones:
o Antes de que todas las modificaciones sean reflejadas en la BD.
o Despus de que todas las modificaciones fueron reflejadas en la
BD.

Durante el proceso de recuperacin se revisa la bitcora y se realizan las


siguientes acciones:
Si la transaccin no tiene commit en la bitcora, se necesita deshacer los
cambios porque la base de datos se modific y la transaccin tiene que
abortar. Esta parte del protocolo se llama UNDO (deshacer los cambios).
Si la transaccin tiene commit ocurre uno de los dos casos:

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 60


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

o Si el commit se puso en la bitcora antes de que se reflejaran los


cambios en la BD, se necesita rehacer todos los cambios debido a
que no existe seguridad que estos cambios se hayan reflejado
debidamente. Esta parte de la tcnica se llama REDO (rehacer los
cambios).
o Si el commit se puso en la bitcora despus de que se reflejaran
los cambios en la BD, no se necesita rehacer los cambios debido a
que todos los cambios ya estn reflejados debidamente en la BD.
Esta parte de la tcnica se llama NO-REDO (no rehacer los
cambios).

Como se puede ver las actualizaciones inmediatas permiten dos variaciones de


la tcnica de recuperacin: UNDO/REDO y UNDO/NO-REDO. Las dos opciones
requieren la existencia en la bitcora de los valores BFIM. Adicionalmente, la
tcnica UNDO/REDO requiere los valores AFIM.

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

Durante la recuperacin se analiza la bitcora desde la ltima grabacin:


Como la transaccin T2 no tiene commit, se inserta <T2,abort> en la
bitcora y se graban los valores viejos (15, 40, respectivamente para B y
D).
Como la transaccin T1 tiene commit no se hace nada en la BD.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 61


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Pgina sombra (shadow paging)

Shadow paging considere la base de datos hecha de un nmero de pginas de


disco (o bloques de disco) de tamao fijo, para propsitos de recuperacin.
Durante las actualizaciones se realizan los siguientes pasos (figura 4.2):
Se construye un directorio con n entradas, donde la entrada i apunta a la
pgina i de la BD en disco. La tabla de pginas se guarda en memoria
principal si no es demasiado grande y todas las referencias (lecturas o
escrituras) a las pginas de la base de datos en el disco van a travs de
esta tabla de pginas.
Se copia al disco la tabla actual de pginas en la tabla llamada shadow
page antes de comenzar la ejecucin de una transaccin. Esta tabla
nunca es modificada durante la ejecucin de la transaccin actual.

Cuando la transaccin quiere modificar el dato de la pgina i:


o Se crea una nueva copia de esta pgina en un lugar disponible,
diferente de la localizacin original.
o Se modifica el valor en esta pgina.
o Se modifica la entrada de la tabla actual de pginas apuntando a la
nueva versin y descartando la vieja.

Figura 4.3. Shadow paging

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

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 62


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

dos versiones. La versin vieja es referenciada por la tabla shadow page y la


nueva versin por la tabla de pginas actual.

Durante la recuperacin despus de la falla


Si la transaccin no pudo terminar su ejecucin con xito, es suficiente
liberar las pginas de la BD modificadas y desechar la tabla de pginas
actuales. El estado de la base de datos antes de ejecutarse la transaccin
est disponible por medio de la tabla shadow page, as que llega a ser la
tabla de pginas actuales una vez ms.
Si la transaccin termin su ejecucin con xito, se desecha la tabla
shadow page previa y libera las tablas viejas de pginas a las que hace
referencia.

Como la recuperacin no deshace ni rehace ninguno de los valores sobre los


datos, esta tcnica puede ser categorizada como una tcnica NO-UNDO/NO-
REDO.

La ventaja de shadow paging es que deshace el efecto de la transaccin de


forma muy simple. No es necesario deshacer o rehacer ninguna operacin de la
transaccin.

Una desventaja de este mtodo es que las pginas actualizadas de la base de


datos cambian de lugar en el disco. Esto dificulta mucho mantener juntas las
pginas relacionadas sin emplear estrategias de manejo de almacenamiento
muy complejas. Una desventaja adicional es la forma de realizar la recoleccin
de basura cuando una transaccin se confirma: las pginas viejas a las que
hace referencia el directorio sombra y que se han actualizado debern liberarse
y aadirse a una lista de pginas libres para su uso posterior. Esas pginas ya
no se necesitarn despus de que la transaccin se confirme.

ANULACIN DE TRANSACCIONES EN CASCADA


Cuando el protocolo de recuperacin garantiza las planificaciones recuperables,
pero no garantiza unas planificaciones cascadeless (sin anulacin en cascada) o
estrictas, puede ocurrir el fenmeno de cascading rollback (anulacin en
cascada). Este fenmeno tiene lugar debido a que una transaccin modific los
datos y fall su ejecucin, pero otra transaccin ley un dato modificado por la
primera transaccin. As, que la segunda transaccin tambin debe cancelarse
para mantener la consistencia de la BD. La figura 4.4 presenta un ejemplo de
cascading rollback donde se puede ver el uso de la bitcora para su realizacin.

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

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 63


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

necesita conocer los valores ledos por la transaccin. Como este fenmeno no
se da, las bitcoras no guardan ninguna operacin de leer un dato.

Figura 4.4. Cascading rollback: (a) las operaciones de escritura y de lectura de


tres transacciones, (b) bitcora del sistema en el momento de la cada y (c)
operaciones antes de la cada.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 64


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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

Para poder incluir la marca de checkpoint en la bitcora, se requiere lo siguiente


(pueden variar de acuerdo a la DBMS especfica):
Suspender la ejecucin temporalmente de todas las transacciones.
Crear una lista L de transacciones activas en el momento de checkpoint.
Forzar a escribir el contenido de la bitcora al disco.
Forzar la escritura al disco de todos los buffers de datos de la memoria
principal que se hayan modificado.
Escribir [checkpoint] en la bitcora.
Resumir la ejecucin de las transacciones.

Con la presencia de checkpoint en la bitcora, la recuperacin se realiza de la


siguiente manera (suponga que las transacciones se ejecutaron en serie como
en la figura 4.5):
Revisar la bitcora desde el final hasta ltimo checkpoint.
Buscar la ltima transaccin que comenz su ejecucin antes del ltimo
checkpoint (este checkpoint puede mantener la lista L con esta
transaccin), por ejemplo T3 en la figura 4.5.
Identificar todas las transacciones que comenzaron su ejecucin despus
de esta ltima transaccin, por ejemplo T4, T5, y T6 en la figura 4.5.
Aplicar operaciones de recuperacin a este conjunto de transacciones.

Figura 4.5. Ubicacin en tiempo de checkpoint y crash con respecto a la


ejecucin en serie de las transacciones.

En forma parecida se realiza la recuperacin de las transacciones en ejecucin


concurrente. Por ejemplo, suponiendo que el protocolo de recuperacin es
UNDO/REDO, crea dos listas:
Lista REDO: cada transaccin que tiene commit en la bitcora.
Lista UNDO: cada transaccin que tiene start y no est en la lista de
REDO.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 65


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Adems, para cada transaccin que est en la lista L, si no est en la lista de


REDO, ponerla en la lista de UNDO. Al tener estas listas se realiza lo siguiente:
Se recorre de nuevo la bitcora hacia atrs anulando los resultados de las
transacciones indicadas en la lista de UNDO.
Se localiza el ltimo punto de checkpoint (puede ser necesario moverse
adelante como en el ejemplo al hacer UNDO de T1).
Se recorre la bitcora hacia delante desde el ltimo registro de checkpoint
regrabando los resultados de las transacciones que estn en la lista
REDO.

Ejemplo:
Considere la ejecucin de transacciones concurrentes como se presenta en la
figura 4.6.

Figura 4.6. Ubicacin en tiempo de checkpoint y crash con respecto a la


ejecucin concurrente de las transacciones.

Se tiene la lista L= {T1,T4} con las transacciones que estaban en la ejecucin


cuando se grab checkpoint. Se recorre la bitcora para crear las listas de
REDO = {T4,T5} y lista de UNDO = {T1,T6}. Con estas listas, se recorre desde el
final de la bitcora anulando las operaciones de las transacciones T1,T6, se
posiciona en el punto de checkpoint y se regraban los resultados de las
transacciones T4,T5.

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>

Durante la recuperacin si se recorre cada entrada haciendo UNDO y REDO


simultneamente, se terminara con el valor de A = 10. Al contrario, si primero se

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 66


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

OTROS ELEMENTOS DE LA BITCORA

Adems de checkpoint la bitcora puede incluir las marcas de rollback y


savepoint. Rollback deshace el trabajo realizado por la transaccin actual
(cambios sobre los datos realizados en la BD) sin abortar la transaccin, o sea,
la transaccin tendr asignado su TS y su rea de trabajo.

Savepoint (contrario a lo que significa la palabra) no guarda nada en la base de


datos sino que se usa como una especie de etiqueta, o sea, identifica un punto
en la transaccin hasta el cual se podr hacer rollback. Savepoint es til para
programas interactivos o programas de aplicacin que contienen subprogramas
ya que se puede crear y nombrar los pasos intermedios, por ejemplo:

UPDATE Empleado SET salario = 2000 WHERE nombre = Juan;


SAVEPOINT Juan_salario;
UPDATE Empleado SET salario = 1500 WHERE nombre = Maria;
SAVEPOINT Maria_salario;
SELECT SUM(salario) FROM Empleado; /* se pago demasiado a Maria */
ROLLBACK TO SAVEPOINT Juan_salario;
UPDATE Empleado SET salario = 1300 WHERE nombre = Maria;
COMMIT;

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 67


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

MANEJADOR DE BFERS Y SU RELACIN CON EL SISTEMA DE


RECUPERACIN

El sistema de recuperacin est ntimamente ligado con el sistema de manejo de


bfers. Este sistema es responsable de la asignacin de bfer de datos a las
pginas del disco.

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

Figura 4.7. Buffer pool para datos en la memoria principal.

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:

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 68


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Buscar en buffer: revisar si la pgina est en el bfer. Si la encuentra,


aumenta el valor de contador de pin y devuelve su direccin, si no:
Encontrar buffer disponible: revisar si hay un bfer vaco. Si hay, asignarlo
a la pgina solicitada con los valores de bit sucio igual a cero y contador
de pin igual a uno. Si no:
Buscar un bfer con el contador de pin igual a cero. Si hay varios bfer
con esta caracterstica, determinar la vctima de reemplazo segn
algoritmo usado (recordar del semestre pasado), realizando las acciones
necesarias para liberar el espacio requerido (por ejemplo, grabar al disco
las pginas con el bit sucio igual a uno). Asignar el bfer a la pgina
solicitada inicializando los valores de bit sucio a cero y de contador de pin
a uno.
Si no hay bfers con el contador de pin igual a cero, el manejador de
bfer tiene que esperar hasta que se libere algn espacio.
Traer la pgina al bfer liberado.

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:

Steal (robar): el bloque puede ser grabado al disco antes de que la


transaccin haga su commit.
o La pgina puede tener datos sucios (sin commit de la transaccin).
o Si el sistema falla, se necesita deshacer (UNDO) cambios para las
transacciones que no terminaron su ejecucin con xito.
o Buen desempeo del sistema.
No-steal (no-robar): un bloque actualizado por una transaccin (dirty bit
= 1) no puede escribirse al disco antes que la transaccin confirme.
o Solo datos confirmados se graban al disco.
o Si el sistema falla no se necesitan deshacer cambios (NO-UNDO).
o Puede causar mal desempeo.
o Se requiere el espacio de memoria principal bastante grande para
acomodar todas las pginas sucias de las transacciones
concurrentes activas en el sistema.
Force (forzar): todos los bloques actualizados por una transaccin son
escritos inmediatamente al disco cuando la transaccin confirma.
o Provee durabilidad (permanencia).
o No se necesita hacer REDO (la poltica de NO-REDO) (mejora el
proceso de recuperacin).
o Pobre desempeo: operaciones I/O son aleatorias debido a que se
puede requerir varias grabaciones al disco de la misma pgina si
sta est siendo usada por varias transacciones que hagan su
commit, en lugar de solo una cuando terminan todas.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 69


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

No-force (no-forzar): la confirmacin de la transaccin no obliga a


reflejar los resultados inmediatamente en el disco.
o Trabajo adicional para garantizar la durabilidad.
o Si el sistema falla se necesita REDO para las transacciones que
terminaron su ejecucin con xito.
En la figura 4.8 se resumen las caractersticas de desempeo:

No-steal Steal

No-force Ms rpido,
deseado

Force Ms lento,
trivial

Figura 4.8. Eficiencia en el uso de diferentes polticas de manejo de bfer.

Como puede verse de lo anterior, las diferentes tcnicas de recuperacin son


estrechamente sincronizadas con las polticas de manejo de bfer. En resumen:
cuando se ven juntos las polticas de manejo de buffer y el sistema
recuperacin, se dan 4 casos como se puede ver en la figura 4.9.

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.9. La correspondencia entre las polticas de manejo de buffer y las


tcnicas de recuperacin.

Otra caracterstica importante de los manejadores de bfer es que pueden tener


implementadas estrategias para mejorar la eficiencia de una DBMS. Estas
estrategias permiten un trabajo asncrono entre el manejador de bfer y otros
procesos relacionados:
Pre-fetching: recuperar las pginas antes de ser solicitadas, por ejemplo,
durante un escaneo secuencial de la relacin, durante la operacin join o
la recuperacin del sistema (creado la lista de undo, se puede tambin
crear la lista de redo).

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 70


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Pre-flushing: escribir la pgina al disco durante el tiempo de ocio del


sistema, disminuyendo el trabajo especialmente cuando se usa la poltica
de manejo de bfer tipo no-force.

VISIN GLOBAL DE LOS MANEJADORES DE RECURSOS DE UNA DBMS


Diferentes sistemas que se vieron en captulos anteriores se pueden considerar
como un grupo de tres componentes llamados manejadores de recursos:
Manejador de almacenamiento (storage manager) - responsable por el
almacenamiento de datos, metadatos, ndices y bitcoras.
Manejador de consultas (query manager) responsable por realizar el
anlisis sintctico de las consultas, elaborar un (optimizado) plan de
ejecucin y ejecutar la consulta.
Manejador de transacciones (transaction manager) - asigna el
identificador a cada transaccin y coordina los procesos del manejador de
recuperacin y de control de concurrencia.

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 71


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Usuario/aplicacin
consultas comandos de
transaccin

Manejador de
Compilador de consultas
transacciones

plan de ejecucin Identificador de la


transaccin
Manejador de sistema
Motor de ejecucin
de recuperacin Identificador de la
transaccin
solicitudes de ndices,
registros, archivos, ...

Manejador de ndices/ Manejador de control de


archivos/regstros concurrencia

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

Figura 4.10 Los componentes principales de una DBMS y sus interacciones.

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

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 72


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

cooperacin o, en muchos casos, emite los comandos directamente al


controlador del disco (depende de la DBMS especfica). De esta forma todas las
componentes que necesitan la informacin desde disco tienen que interactuar
con el manejador de bfers primero.

El manejador de transacciones acepta los comandos desde la aplicacin que le


indican donde comienza y donde termina la transaccin y cules son los niveles
de aislamiento requeridos. Las transacciones ejecutadas tienen que cumplir con
las caractersticas ACID. Dos manejadores de recursos ayudan en esta tarea: el
manejador del sistema de recuperacin y el manejador de control de
concurrencia. El manejador del sistema de recuperacin asegura la durabilidad
guardando cada cambio realizado sobre los datos en la bitcora del disco duro.
El sistema de control de concurrencia (llamado tambin planificador, scheduler)
asegura que las acciones individuales de mltiples transacciones ejecutadas en
forma concurrente dan el mismo resultado a que si fueran ejecutadas por
separado, en serie. Muchos de los protocolos usados se basan en los candados
y es necesario mantener la informacin de su uso en una tabla, donde se indica
el recurso y el candado puesto o solicitado.

La descripcin presentada es una forma genrica de ver los componentes de un


sistema. En general, hay una gran variedad de componentes no vistos en este
curso, como por ejemplo, de manejo de procesos paralelos, replicaciones, entre
otros. Adems, cada DBMS difiere en la forma como implementa sus
manejadores de recursos como pueden ver en la figura 4.11, donde se presenta
la arquitectura simplificada de Oracle.

Figura 4.11 Arquitectura simplificada de Oracle.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 73


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

PARTE V
DIFERENTES TIPOS DE TRANSACCIONES
Transacciones planas

Las transacciones vistas hasta ahora, normalmente se caracterizan por su corta


duracin y la simplicidad en su estructura. Ellas pasan por diferentes estados:
activa, confirmada (committed), fallida (aborted). Para describir estas
transacciones planas se puede emplear el diagrama de la figura 5.1 (ya visto
anteriormente).

Figura 5.1. Los estados y sus transiciones en la ejecucin de la transaccin


plana.

Estas transacciones contienen una o varias sentencias de SQL y su estado final


es fcil de deducir de acuerdo a si se ejecutaron todas las operaciones (commit)
o fall alguna (abort). Estas transacciones se llaman transacciones planas (ver
figura 5.2) y tienen las siguientes caractersticas:
Es un bloque bsico de construccin para organizar las aplicaciones en
forma de acciones atmicas.
Puede contener un nmero arbitrario de operaciones simples. Cabe
mencionar, que si las acciones se ejecutan secuencialmente o en forma
paralela es irrelevante, porque no hay forma de acceder los resultados
intermedios que produce la transaccin (la estructura de ejecucin no
tiene ninguna relevancia).
Existe solamente un nivel de control encerrado entre begin (start) y end
(commit).
Se ejecuta todo o nada.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 74


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

BEGIN BEGIN BEGIN


Operation1 Operation1 Operation1
Operation2 Operation2 Operation2
... ... ... CRASH
Operationk
COMMIT ROLLBACK
Ejecucin existosa Cancelacin por Cancelacin
96% de aplicacin 3% de forzada 1% de
transacciones transacciones transacciones
Figura 5.2. Los diferentes resultados de la ejecucin de la transaccin plana
[GR93].

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:

Planificacin de viaje: el usuario quiere viajar desde San Francisco, California


a Glogow, Polonia. Como no existe un vuelo directo, se necesita hacer varias
conexiones (aviones, buses, trenes o alquiler de carros). El agente puede
elaborar algo como esto:

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

Problema: no existe la conexin de Varsovia a Glogow en el mismo da, excepto


por el alquiler de un carro, pero no se quiere viajar de noche. En este caso si se
usa la transaccin plana, se deben abortar todas las reservaciones aunque
algunas de ellas pueden servir.
Solucin: ofrecer selectividad en abortar partes de la transaccin.

Transacciones planas con savepoints

Para solucionar parcialmente las deficiencias de las transacciones planas, se


pueden usar los savepoints para informar al sistema sobre el estado actual del
programa de aplicacin (los cambios hechos). Este punto se puede usar
posteriormente para su referencia, por ejemplo, para invocar la operacin de
rollback hasta savepoint en lugar de cancelar la ejecucin de toda la transaccin.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 75


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Si estos puntos se establecen en las partes parcialmente consistentes, con


facilidad se pueden usar dentro del programa de aplicacin como puntos de
regreso si algo no funciona bien.

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.

Figura 5.3 presenta un ejemplo de los estados de ejecucin de la transaccin


con savepoints. Cada rollback hacia un savepoint especfico obliga a deshacer
los cambios hechos por la transaccin, lo que se indica en la figura como
operaciones anuladas. Sin embargo, es importante recordar que los savepoints
deberan llamarse puntos de anulacin, porque en verdad no afectan el estado
de BD y solo sirven para mejorar el desempeo de programas de aplicacin en
el caso de que algo falle (no referente al fallo del sistema). Adems, la aplicacin
de savepoints y rollbacks incontrolada puede crear programas de aplicaciones
muy poco estructurados y difciles de entender.

Para poder usar el modelo con savepoints, se necesita establecer algunas


reglas:

Estructura: la aplicacin debe poder claramente dividirse en acciones


atmicas y cada savepoint es la seal de finalizacin de una accin y
comienzo de una nueva accin que es estructuradamente dependiente de su
predecesor.

Regla de commit: solo la ltima accin puede generar el commit debido a


que cualquier accin se puede realizar solamente en la parte de la
transaccin que est actualmente activa, o sea, se ejecuta. La accin de
commit final se propaga por todas las acciones atmicas anteriores hasta
cubrir toda la transaccin.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 76


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Regla de rollback: la accin de rollback se propaga en el orden inverso en el


cual fueron ejecutadas las acciones y cancela todas las acciones presentes
entre los sevepoints (la invocacin es similar a la invocacin de la seal de
commit, solamente la accin es diferente). Sin embargo, el alcance de
rollback depende del parmetro especificado.

Regla de visibilidad: Los resultados de cada parte entre savepoints no son


visibles hasta que la transaccin no emite su commit. Los candados se
liberan al terminar la ejecucin 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.

Transacciones anidadas (nested transactions)

Las transacciones anidadas son la generalizacin de savepoints. Mientras que


los savepoints permiten organizar la transaccin como una secuencia de
acciones que pueden ser anuladas individualmente, las transacciones anidadas
forman una jerarqua de partes de trabajos atmicos (ver la figura 5.4).

Figura 5.4. La idea bsica de las transacciones anidadas [GR93].

La figura 5.5 presenta un ejemplo de transacciones anidadas para la


planificacin del viaje. Como se pude ver en la figura existe una transaccin de
nivel superior T1 controlando toda la actividad de la planificacin. Otras
subtransacciones estn anidadas controlando cada uno de las reservaciones
parciales de vuelo, hotel y carro. En lugar de usar los savepoints, cada una de

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 77


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

estas subtransacciones se convierte en autocontenida, pero dependiente de


otras acciones. Los niveles de anidacin se pueden extender de acuerdo a las
necesidades de la aplicacin.

Figura 5.5. Un ejemplo de uso de las transacciones anidadas para la


planificacin del viaje [CB05].

La definicin de las transacciones anidadas se puede dar considerando varios


aspectos:

Estructura: La transaccin anidada es un rbol de transacciones, donde


cada subrbol es una transaccin plana o anidada. En el nivel de hojas se
encuentran las transacciones planas. Las distancias entre la raz y las hojas
pueden ser diferentes para diferentes partes del rbol. La transaccin en el
nivel de raz se llama top-level transaction (transaccin de nivel superior).

Regla de commit: la subtransaccin puede realizar commit; su commit no se


hace efectivo hasta que su padre haga tambin commit. Por induccin,
cualquier subtransaccin puede hacer finalmente su commit solo si la
transaccin en la raz lo hace.

Regla de rollback: la operacin de rollback en cualquier nivel de rbol causa


que todas sus subtransacciones hagan rollback tambin, aplicando la regla
recursivamente hasta llegar a las hojas. Por induccin, si la transaccin raz
aborta, tambin abortan todas sus subtransacciones aunque tengan su
commit. Sin embargo, el abort de una subtransaccin no indica abort para su
correspondiente transaccin padre. El padre es simplemente notificado que
su subtransaccin abort.

Regla de visibilidad: Los resultados de cada subtransaccin confirmada se


hacen visibles solamente para la transaccin padre y no son visibles para las
transacciones hermanas (siblings). Todos los objetos (por ejemplo,

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 78


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

candados) que tiene asignado el padre, pueden ser accedidos por sus
subtransacciones y stas pueden solicitar otros objetos que al terminar pasan
al padre.

Se puede notar que las transacciones anidadas no son totalmente equivalentes


a las transacciones planas debido a que son vlidas en el contexto de la
transaccin del contorno de nivel ms alto; se puede ver que cualquier
subtransaccin es A, C, I, pero no D. Son atmicas desde la perspectiva del
padre, son consistentes con respecto a la funcin local que implementan, son
aisladas de otras actividades de dentro (subtransacciones) y afuera (otras
transacciones) de la transaccin padre, pero no son permanentes (durable)
considerando la regla de commit presentada arriba.

Si los sistemas no ofrecen la implementacin de transacciones anidadas, se


pueden simular por medio de savepoints como se puede ver en la figura 5.6. Si
se genera savepoint al principio de cada subtransaccin, al hacer rollback hasta
este punto, se simula abortar esta subtransaccin con todas las
subtransacciones hijas. Sin embargo, existe una diferencia significativa con
respecto al manejo de los candados. Como ya se mencion para las
transacciones anidadas, la subtransaccin puede heredar los candados del
padre (algunos o todos) y siendo sta otra transaccin tambin puede adquirir
sus propios candados los cuales al terminar la subtransaccin se pasan al
padre. Al contrario, usando savepoints, el padre debe tener todos los candados,
debido a que en realidad se est ejecutando una transaccin plana.

Figura 5.6. Simulacin de transacciones anidadas por medio de savepoints

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 79


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Transacciones distribuidas

La transaccin distribuida es tpicamente una transaccin plana que corre en un


ambiente distribuido donde necesita visitar varios nodos (servidores) de acuerdo
a los datos solicitados. Por ejemplo, para un sistema bancario existen varios
nodos ubicados en San Ramn, Liberia, Cartago y San Jos como se puede ver
en la figura 5.7. Cada una de estas localidades funciona a nivel local como la
base de datos centralizada, pero a nivel global todos los nodos forman una base
de datos distribuida.

Figura 5.7. Ejemplo de arquitectura de bases de datos distribuidas.

Suponga que la transaccin T corre en el nodo de San Jos y requiere sumar el


valor de depsito sobre prstamos que se ejecutaron este mes. Debido a que los
datos estn en el nodo local de San Jos y adems, en otros tres nodos, la
transaccin T, emite tres subtransacciones T1, T2 y T3 a nodos remotos de
Liberia, San Ramn y Cartago. De esta forma se crea una jerarqua de la
ejecucin de subtransacciones como se puede ver en la figura 5.8.
San Jos

T1 T2 T3

Liberia San Ramn Cartago

Figura 5.8. Invocacin de subtransacciones en un ambiente de BD distribuidas.

Estructura: A diferencia de las transacciones anidadas, la descomposicin


entre las subtransacciones en la transaccin distribuida no depende del
programador y no refleja la estructura jerrquica de ejecucin, sino que se da
debido a la existencia de datos ubicados en otros servidores. En

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 80


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

consecuencia, las subtransacciones forman parte de una transaccin T que


se encarga de la coordinacin.

Regla de commit: la subtransaccin puede realizar commit; su commit no se


hace efectivo hasta que su padre haga tambin commit1. Por induccin,
cualquier subtransaccin puede hacer finalmente su commit solo si la
transaccin en la raz lo hace.

Regla de rollback: la operacin de rollback en cualquier nivel del rbol causa


el aborto de todas las subtransacciones aunque stas tengan un (pre)commit.

Regla de visibilidad: Los resultados de cada subtransaccin confirmada se


hacen visibles solamente para la transaccin padre y no son visibles para las
transacciones hermanas (siblings). La asignacin de los objetos (candados),
se hace siguiendo diferentes tipos de protocolos que funcionan en ambientes
distribuidos.

Transacciones en cadena (chained transactions)

Transacciones en cadena pueden ser tiles cuando se puede dividir la


transaccin en partes y construir una cadena (chain) de subtransacciones. En
esta cadena, cada subtransaccin comienza su ejecucin de forma automtica
cuando se hace commit de la subtransaccin anterior de la cadena. De esta
forma los cambios de cada una de las subtransacciones son duraderos y se
tiene menos trabajo de recuperacin que usando las transacciones planas con
savepoints o transacciones anidadas, donde se pierde todo el trabajo realizado.

Este tipo de transacciones es muy til en las as llamadas long-living


transactions (LLT, transacciones de larga duracin), como por ejemplo, el
clculo de intereses y la modificacin de un milln de cuentas bancarias como
se puede ver en la figura 5.9.
T1 T2 Tn

BEGIN1
Modificacin de ... Modificacin de
Modificacin de cuentas 5001 - cuentas 995001
cuentas 1 -5000 10000 -1000000

COMMIT1 COMMIT2 COMMITn

Figura 5.9 La cadena de transacciones.

Estructura: Se divide la transaccin en una secuencia de grupos de acciones


atmicas donde cada commit es la seal de la finalizacin de un grupo de
acciones y el comienzo del otro (esta accin se considera atmica).

1
El protocolo usado se llama Two Phase Commit.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 81


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Regla de commit: cada una de las subtransacciones realiza commit sobre


las operaciones ejecutadas.

Regla de rollback: solo se puede hacer rollback de la subtransaccin activa,


o sea, los resultados de las subtransacciones que ya hicieron su commit no
pueden ser revertidos.

Regla de visibilidad: los resultados de cada subtransaccin de la cadena


son visibles despus de realizar el commit. Adems, se liberan los candados
usados.

Con la especificacin anterior se puede ver que la regla de aislamiento


(isolation) no se cumple debido a que al liberar los candados despus de hacer
commit en la subtransaccin, algunas otras transacciones pudieron modificar
estos datos. Tampoco la transaccin entera es atmica. Si ocurre el fallo, la
DBMS no puede anular los resultados debido a que algunas subtransacciones
iniciales ya hicieron su commit y los resultados son duraderos, o sea, se
grabaron en la base de datos. Como consecuencia no se puede realizar abort de
la forma usual por dos razones:
Las subtransacciones ya hicieron commit y de acuerdo a las reglas de
atomicidad, el sistema de recuperacin no debe cambiar los valores
modificados por estas transacciones.
Si otras transacciones M ya modificaron los datos usados previamente
por las sub-transacciones, se necesitara hacer cascading rollback de
todas estas transacciones (pueden ser muchas ya que la transaccin en
cadena es de larga duracin). Si no se realiza el cascading rollback para
las transacciones M, para representar que la transaccin en cadena
abort, se deben grabar los valores BFIM (physical logging) haciendo
perder todas las modificaciones realizadas por las transacciones M.

Para solucionar este problema se propusieron tres soluciones. La primera es la


recuperacin hacia adelante, o sea, seguir ejecutando las subtransacciones en
cadena despus de la ltima subtransaccin de la cadena que se ejecut con
xito. Para esto la aplicacin puede determinar cunto trabajo ya fue realizado
con xito (y es duradero), por ejemplo, que 500 000 cuentas ya fueron
modificadas. Esto significa que cada una de las subtransacciones debe indicar a
su sucesor el estado de ejecucin (el contexto global de la base de datos), por
ejemplo, el contador del nmero de registros actualizados se incrementar en
5000 despus de la ejecucin de cada subtransaccin. Sin embargo, la
comunicacin entre subtransacciones sucesivas no puede realizarse por medio
del uso de variables locales ya que el contenido de stas puede perderse
durante el fallo del sistema. Es necesario utilizar la base de datos para la
comunicacin del contexto entre diferentes subtransacciones como se puede ver
en la figura 5.10.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 82


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

T1 T2 Tn

BEGIN1
Modificacin de ... Modificacin de
Modificacin de cuentas 5001 - cuentas 995001
cuentas 1 -5000 10000 -1000000

COMMIT1 COMMIT2 COMMITn

N=5000 N=10000

Figura 5.10 Contexto global de la base de datos modificado despus de la


ejecucin exitosa de cada subtransaccin.

Si la transaccin falla en la ejecucin de modificaciones de, por ejemplo, 5200


tuplas, se anulan los resultados de las ltimas 200 modificaciones debido a que
una de las subtransacciones no logr hacer el commit (como cada
subtransaccin es atmica, el sistema de recuperacin es capaz de hacerlo).
Despus, se sigue con la cadena de subtransacciones indicada por el ltimo
contexto grabado en la base de datos, o sea, a partir de la tupla 5001.

En la segunda solucin se incluy una nueva operacin cadena (chain)2. Esta


operacin reemplaza el commit con la diferencia de que se mantiene todo el
contexto de la parte de la subtransaccin antes del commit, o sea la siguiente
parte de la cadena opera sobre el mismo contexto que la parte anterior tena
despus de su ltima operacin. Adems, no se liberan los candados, as
evitando el problema de lectura sucia y cascading rollback. Sin embargo, esta
solucin requiere un protocolo de recuperacin muy complejo y no se mejora el
desempeo del sistema.

La tercera solucin propuesta es usar las transacciones de compensacin


(logical logging), o sea, para cancelar los resultados de la ejecucin de la
transaccin en cadena en lugar de modificar los valores en la base de datos, se
realizan las operaciones opuestas, por ejemplo, si la subtransaccin original
suma el valor 10 a la cuenta, la transaccin de compensacin realizar la resta
de este valor o si la subtransaccin inserta un estudiante, la transaccin de
compensacin lo borra. Como pueden ver con las transacciones de
compensacin no se logra la durabilidad de la cadena debido a que se deshacen
los cambios de las subtransacciones que ya hicieron su commit.
2
Sistemas comerciales permiten implementar esta operacin, por ejemplo el producto CICS de
IBM establece la palabra syncpoint que se refiere al punto de conexin entre una y otra
transaccin que forman la cadena.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 83


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

La idea de usar las transacciones de compensacin se origin con la propuesta


de sagas presentada por Garcia-Molina y Salem en 1987. El concepto es la
extensin de transacciones en cadena, donde:

Estructura: saga es una unidad de control que representa la cadena de


transacciones planas T1, T2, T3,..,Tn. Para cada transaccin simple Tj existe
una transaccin de compensacin CTj que semnticamente deshace los
cambios realizados por la transaccin correspondiente proveyendo la
atomicidad a la cadena entera. Se permiten slo dos niveles de anidacin: el
nivel tope de la saga y de cada una de sus subtransacciones.
Regla de commit: cada una de las subtransacciones realiza commit sobre
las operaciones ejecutadas, permitiendo ver los resultados a las otras
transacciones.
Regla de rollback: Si saga tiene que abortar debido a la falla en alguna de
las subtransacciones, se realizan sus correspondientes transacciones de
compensacin, o sea, si falla Ti, tenemos: T1, T2,..., Ti (abort), TCi,TCi-1,...
TC2, TC1.
Regla de visibilidad: igual como para las transacciones en cadena, o sea,
los resultados de cada subtransaccin de la cadena son visibles despus de
realizar el commit y adems, se liberan los candados usados.

RESUMEN

Los modelos de transacciones tratan de proveer un marco adecuado de


patrones de procesamiento en una aplicacin. La forma ms simple de las
transacciones son las transacciones planas con sus caractersticas ACID. Estas
transacciones se pueden extender por medio de savepoints.

Otra forma es usar la transaccin T compuesta por un conjunto de transacciones


T1, T2, Tn. Si no se permite a las subtransacciones realizar commit antes de
que la transaccin padre lo haga, la transaccin T se llama transaccin anidada.
Si se permite a las subtransacciones realizar el commit independientemente del
padre, estas transacciones se llaman transacciones en cadena. Cuando una
transaccin en cadena es de larga duracin a veces recibe el nombre de saga.

Las transacciones de larga duracin son un balance entre la cantidad de trabajo


perdida en el caso de falla y la cantidad de trabajo que hay que realizar para
determinar el estado correcto de procesamiento despus de la falla. La
computacin se divide en partes. Estas transacciones asumen que en el caso de
falla slo se necesita la recuperacin hacia delante o la existencia de
transacciones de compensacin que deshacen el trabajo previo de las
transacciones. Tiene que tener claro que este tipo de suposiciones es vlido en
casos especficos de las aplicaciones.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 84


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

Falta de adecuada seguridad en las bases de datos expone a varias amenazas.


Amenaza es cualquier accin o suceso, intencionado o accidental, que pueda
afectar a un sistema y como consecuencia a una organizacin [CB05]. Las
amenazas pueden referirse a:
Robo y fraude: fsicamente robar parte o todo equipo que contiene datos
de la organizacin/compaa.
Prdida de confidencialidad: acceso a ciertos datos secretos (crticos o
privados) por las personas no autorizadas.
Prdida de integridad: aparicin de datos invlidos o corrompidos
debido a modificaciones (inserciones, actualizaciones, borrado).
Prdida de disponibilidad: imposibilidad de acceder las bases de datos.
Esto puede afectar econmicamente a la organizacin o abrir las
posibilidades de corrupcin (por ejemplo, falta de transferencia de la
informacin).

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 85


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Figura 6.1. Resumen de amenazas en los sistemas informticos [CB05].

Las tcnicas de seguridad de bases de datos se enfocan en minimizar las


prdidas causadas por los eventos previstos de la forma ms barata posible y
sin restringir innecesariamente la actividad de los usuarios. Existen varias
posibilidades de implementar esta seguridad, por ejemplo, control de acceso,
control de inferencias, control de flujo y cifrado para el control de datos. Este
curso solo se enfoca en el control de acceso.

En los sistemas de multiusuario, la DBMS debe proporcionar tcnicas que


permiten a determinados usuarios o grupos de usuarios el acceso a partes
concretas de la base de datos sin tener acceso al resto de la misma. Una DBMS
incluye por lo general un subsistema de autorizaciones y seguridad en bases de
datos responsable de garantizar la seguridad de partes de una base de datos
frente a accesos no autorizados. Existen dos grupos de mecanismos de
seguridad en bases de datos:
Control de acceso discrecional (DAC, discretionary access control):
se utiliza para conceder permisos a los usuarios, incluyendo la
capacidad de acceso a determinados archivos de datos, registros o
campos en algn modo concreto (lectura, insercin, borrado o
actualizacin).

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 86


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Control de acceso obligatorio (MAC, mandatory access control): se


utiliza para reforzar la seguridad a varios niveles mediante la
clasificacin de los datos y de los usuarios en varias clases de niveles
(seguridad), por ejemplo, permitir ver a los operarios, los datos
generales de los clientes y no sus rangos de salario.

El control de acceso generalmente es la tarea del DBA (database administrador,


administrador de bases de datos). El DBA dispone de una cuenta de DBA,
llamada tambin a veces cuenta de sistema o de superusuario. Este tipo de
cuenta permite la creacin de cuentas nuevas, concesin y retiro de permisos,
como tambin asignacin de un nivel determinado de seguridad.

CONTROL DE ACCESO DISCRECIONAL


El mtodo tradicional para el control de acceso discrecional est basado en
privilegios. Privilegio es un permiso que se concede a un usuario sobre uno o
varios objetos de la base de datos. En general, existen dos niveles de
asignacin de privilegios sobre el sistema de base de datos:

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 87


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica


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

La concesin y revocacin de privilegios se puede representar por medio del


modelo de autorizacin llamado el modelo de matriz de acceso (the access
matrix model), donde:
Cada fila i de la matriz M representa los sujetos (usuarios, cuentas,
programas).
Cada columna j de la matriz M representa los objetos (relaciones,
registros, columnas, vistas, operaciones).
Cada posicin de la matriz M(i,j) representa los tipos de privilegios
(lectura, escritura, modificacin) que el sujeto i tiene sobre el objeto j.

Para controlar la concesin y revocacin de privilegios de una relacin, a cada


relacin R de una base de datos se le asigna una cuenta de propietario (owner)
que es, por general, la cuenta que se utiliz cuando se cre la relacin la
primera vez. Al propietario de una relacin se le conceden todos los privilegios
sobre esa relacin. El DBA o el poseedor de la cuenta de propietario puede
traspasar los privilegios que posee a otros usuarios.

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.

El U1 es propietario de la relacin R y concede los privilegios al otro usuario U4


permitiendo a l tambin conceder privilegios sobre R a otros usuarios.

GRANT INSERT ON Orders TO U4 WITH GRANT OPTION;

La propagacin de los privilegios puede crear una situacin donde diferentes


usuarios tienen acceso a las cuentas sin el conocimiento del propietario de la
relacin (o DBA). En la figura 6.2 se puede ver que DBA concede privilegios al
usuario U1 con GRANT OPTION y ste a la vez concede privilegios al usuario U4
sin el conocimiento de DBA.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 88


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Figura 6.2. Grafo con concesin de privilegios entre diferentes usuarios [SKS06].

Suponga otra situacin como se presenta en la figura 6.3.

DBA DBA

U1 U2 U3 U1 U2 U3

a) b)

DBA DBA

U1 U2 U3 U1 U2 U3

c) d)

Figura 6.3. Intento de eludir la retirada de autorizaciones [SKS06].

El DBA concede privilegios como se muestra en la figura 6.3a). El usuario U2


concede los privilegios al usuario U3 y viceversa. Aunque el DBA retira los
privilegios a U3 (figura 6.3b)), ste siempre los tienes debido a la concesin que
le dio el usuario U2. Peor an, cuando se retira los privilegios a U2 (figura 6.3c)),
los dos, U2 y U3, tienen privilegios asignados.

Para asegurar la concesin de privilegios controlada se crean grafos con el


propsito de prevenir los ciclos de concesin de privilegios que no pasan por la
raz (DBA), o sea, solo se permite mantener los privilegios si hay un camino
desde la raz del grafo de autorizacin (DBA en la figura) hasta el nodo que
representa este usuario. Esto indica que el grafo solo puede tener los caminos
que comiencen en el DBA. Por esta razn, el grafo resultante queda como en la
figura 6.3d).

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 89


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Adems, se han desarrollado otras tcnicas para limitar la propagacin de los


privilegios, aunque no han sido implementadas en la mayora de las DBMSs y
tampoco forman parte de SQL estndar. En estas tcnicas se establecen dos
formas de limitacin de la propagacin:
Horizontal: indica que a una cuenta U1 que permite dar concesiones a
otras cuentas, se debe limitar el nmero de estas concesiones por un
parmetro i.
Vertical: establece el nmero de concesiones que un usuario U1 puede
dar a otros usuarios con la GRANT OPTION que debe ser menor que el
parmetro especificado j.

Ejemplo:

Suponga que U1 concede SELECT a U2 sobre la relacin Empleado con


propagacin horizontal 1 y propagacin vertical igual a 2. U2 podra entonces
conceder SELECT a, como mucho, una cuenta por la limitacin de propagacin
horizontal. Adems, tomando en cuenta el parmetro de propagacin vertical, U2
solo puede conceder el privilegio a un usuario U3 sin GRANT OPTION
(profundidad vertical = 0) o al otro usuario U3 con GRANT OPTION y parmetro
vertical = 1. Para el ltimo caso, los hijos de U3 ya no pueden propagar el
privilegio con GRANT OPTION.

Vistas forman otro mecanismo del DAC, por ejemplo, si el dueo U1 de la


relacin R quiere que otra cuenta U2 solo acceda algunos campos de la relacin
R, U1 puede crear una vista V sobre R que incluya slo estos atributos.
Posteriormente concede el privilegio de SELECT sobre la vista V a la cuenta U2.
De forma parecida se puede limitar el acceso a solo un subconjunto de las
tuplas. Note que para la creacin de la vista el usuario debe tener los privilegios
de SELECT para todas las relaciones involucradas en la definicin de la vista.

CONTROL DE ACCESO OBLIGATORIO


La tcnica anterior de acceso discrecional ha sido el principal mecanismo de
seguridad en bases de datos, donde el usuario tiene o no tiene determinado
privilegio. Sin embargo, en muchas aplicaciones se necesita una poltica de
seguridad adicional que clasifique los datos y los usuarios en clases de
seguridad. Este modelo, conocido como control de acceso obligatorio (MAC,
mandatory access control), se combina habitualmente con los mecanismos de
control de acceso discrecional. La mayora de los DBMSs no proporcionan este
control en su forma limpia, aunque existe una necesidad de tenerlo.

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 90


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

(1974), donde se clasifica cada sujeto (usuario, cuenta, programa) y objeto


(relacin, tupla, columna, vista, operacin) en una de las clases de seguridad de
TS, S, C, U. Suponga que se llama clase(S) al nivel de autorizacin
(clasificacin) de un sujeto S y clase(O) a la clasificacin de un objeto O. Se
definen las siguientes reglas:
1. Propiedad de seguridad simple: A un sujeto S no se le permite el
acceso de lectura a un objeto O a menos que clase(S) clase(O).
2. Propiedad estrella: A un sujeto S no se le permite escribir sobre un
objeto O a menos que la clase(S) = clase(O).

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.

Para poder aplicar polticas de MAC en DBMSs relacionales, se debe asignar


una clase de seguridad a cada objeto de la base de datos. La granularidad de
dichos objetos puede estar en el nivel de las relaciones, de las tuplas o incluso
de los atributos individuales. Esto conduce al concepto del esquema de relacin
multinivel donde a cada atributo Ai se le asigna un atributo de clasificacin Ci y
tambin a cada tupla t se le asigna el atributo de clasificacin de tupla TC:
R(A1,C1,A2,C2, , An,Cn,TC). El valor de cada atributo TC en cada tupla t es el
ms alto de todos los valores de clasificacin de atributos dentro de t. Un
ejemplo se puede ver en la figura 6.4.

Figura 6.4. Un ejemplo de la relacin Empleado con clasificacin de atributos y


tuplas [EN07].

La operacin SELECT * FROM Empleado da diferentes resultados de acuerdo al


nivel de seguridad del usuario que la emita. Por ejemplo, el usuario con nivel de
seguridad S vera la misma relacin que se muestra en la figura 6.4. Sin
embargo, el usuario con nivel de seguridad C no estara autorizado a ver los
valores de desempeo de trabajo (JobPerformance) de Smith y del salario de
Brown, como se puede ver en la figura 6.4a). El usuario con seguridad U solo
podra ver las tuplas y atributos como se presenta en la figura 6.4b).

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 91


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Figura 6.4. Tuplas y atributos que pueden ver los usuarios de la clase C y U
[EN07].

La existencia de relaciones de multinivel introduce un concepto llamado


poliinstanciacin. Por ejemplo, suponga una relacin Cliente con la llave primaria
clientNo y con los niveles de seguridad de las tuplas como se muestra en la
figura 6.5.

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.

Este problema de inferencia se puede resolver incluyendo el atributo de la


clasificacin de seguridad como parte de la llave principal de la relacin. De esta
forma se permite insertar la nueva tupla como se puede ver en la figura 6.6.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 92


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

La presencia de tuplas que parecen tener diferentes valores para distintos


usuarios segn su nivel de seguridad se denomina poliinstanciacin. Este tipo
de situaciones puede llegar a ms complejidad si se consideran otras
operaciones de modificaciones (update, delete) de los usuarios con diferentes
niveles de seguridad.

COMPARACIN DE DAC Y MAC

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.

CONTROL DE ACCESO BASADO EN ROLES


En sistemas DBMS existen grupos de usuarios para los cuales probablemente
es necesario asignar los mismos privilegios. Por ejemplo, los empleados del
banco que trabajan como cajeros deben tener el mismo tipo de autorizacin para
el mismo conjunto de relaciones. Para esto en los aos 90 surgi el control de
acceso basado en roles.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 93


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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.

CREATE ROL cajero;


GRANT SELECT ON Cliente TO cajero;
GRANT INSERT ON Cuenta TO cajero;
GRANT cajero TO Jon, Maria;

CREATE ROL director;


GRANT ALL PRIVILEGES TO director
GRANT director TO Adam, Eva;

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.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 94


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

Cifrado es la codificacin de los datos mediante un algoritmo especial que hace


que stos no sean legibles por ningn programa que no disponga de la clave de
descifrado.

El estndar de cifrado de datos (Data Encryption Standard, DES) es un


algoritmo desarrollado por IBM y aceptado por el gobierno de Estados Unidos
como estndar de cifrado. Este algoritmo proporciona cifrado entre el emisor A y
el receptor B y se llama cifrado simtrico ya que necesita la misma clave para
cifrar y descifrar los mensajes. En forma simplficada, el algoritmo recibe el texto
en trozos de 64 bits y realiza una serie de transformaciones (sustituciones y
permutaciones) para obtener los mismos 64 bits pero cifrados, o sea imposible
de entender sin la clave de cifrado. Para realizar estas transformaciones DES
utliza a clave de 56 bits que es usada cuando se necesita descifrar el mensaje.
Como resultado, primero se puede enviar el mensaje cifrado y despus la clave
(en archivo separado) para que el emisor puede descifrar el mensaje. Sin
embargo, DES no se considera actualmente como un cifrado seguro ya que su
tamao es demasiado pequeo para las capacidades computaciones existentes.
Por esta razn, existe un nuevo estndard llamado el estndar de cifrado
avanzado (Advanced Encription Standard, AES) donde recibe texto de 128 bits
y utiliza la clave de 128, 192 o 256 bits.

La otra forma es el cifrado asimtrico que es ms complejo y ms seguro. Para


este cifrado se require dos claves relacionadas: clave pblica y clave privada.
La clave pblica es conocida por todos y todos la pueden usar para cifrar el
mensaje. La clave privada solo se facilita a estas personas las que tienen
autorizacin de entender el mensaje.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 95


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

BIBLIOGRAFA

[BN09] Bernstein, Ph. y Newcomer, E. Principles of Transaction Processing,


segunda edicin, Morgan Kaufmann, 2009.
[CB05] Connolly, T. y Begg, C. Sistemas de bases de datos: un enfoque
prctico para diseo, implementacin y gestin, Pearson Addison Wesley,
2005.
[EN07] Elmasri, R.. y Navathe, S. Fundamentos de Sistemas de Bases de
Datos, quinta edicin, Person Addison Wesley, 2007
[GR93] Gray, J. y Reuter, A. Transaction Processing: Concepts and
Techniques, Morgan Kaufmann, 1993
[SKS06] Silberschatz, A., Korth, H. y Sudarshan, S. Fundamentos de Bases de
Datos, quinta edicin, McGraw-Hill, 2006.
[WV02 ] Weikum, G. y Vossen, G. Transactional Information Systems: Theory,
Algorithms, and the Practice, Morgan Kaufmann, 2002.

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 96


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

APPENDIX A

Esquemas e instancias de la BD Compaas usadas en el curso de BDI

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

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 97


Universidad de Costa Rica. Escuela de Ciencias de la Computacin e Informtica

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

CI-1314 Material de apoyo. Dra. Elzbieta Malinowski Gajda 98