You are on page 1of 29

T18 - ADMINISTRACIN DE BASES DE DATOS.

1. ADMINISTRACIN DE SISTEMAS DE GESTIN DE BASES DE DATOS ........................................................... 2


2. FUNCIONES ...................................................................................................................................................................... 3
2.1. SELECCIN DE UN SGBD. IMPLEMENTACIN DE LA BASE DE DATOS ....................................................... 3
2.2. DEFINICIN DE PROCEDIMIENTOS DE RESPALDO Y RECUPERACIN ....................................................... 5
2.2.1. CONCEPTO DE RESPALDO Y RECUPERACIN............................................................................................. 6
2.2.2. ESTRATEGIA BSICA DE RESPALDO Y RECUPERACIN ............................................................................ 6
2.2.3. ESTRATEGIA DE RESPALDO ............................................................................................................................ 7
2.2.4. ESTRATEGIA DE RECUPERACIN .................................................................................................................. 7
2.3. AJUSTE DEL RENDIMIENTO................................................................................................................................... 8
3. RESPONSABILIDADES................................................................................................................................................... 8
3.1. INTEGRIDAD ............................................................................................................................................................. 9
3.1.1. INTEGRIDAD SEMNTICA ................................................................................................................................ 9
3.1.2. CONCEPTO DE TRANSACCIN........................................................................................................................ 9
3.1.3 PROBLEMAS CLSICOS DE CONCURRENCIA ............................................................................................. 10
3.1.4. PLANIFICACIN DE TRANSACCIONES. PLANES SERIALIZABLES............................................................ 12
3.1.5. TCNICAS DE CONTROL DE CONCURRENCIA ........................................................................................... 12
3.1.5.1. BLOQUEOS ..................................................................................................................................................................... 13
3.1.5.2. ORDENACIN POR MARCAS DE TIEMPO (TIMESTAMPING)............................................................................... 17
3.1.5.3. TCNICAS DE TRANSACCIONES ANIDADAS.......................................................................................................... 18
3.1.5.4. TCNICAS OPTIMISTAS............................................................................................................................................... 19
3.1.5.5. TCNICAS DE BLOQUEO ALTRUISTA ...................................................................................................................... 19
3.2. DISPONIBILIDAD.................................................................................................................................................... 20
3.2.1. LOG DIARIO O REGISTRO HISTRICO ......................................................................................................... 21
3.2.2. TCNICAS DE RECUPERACIN BASADAS EN MODIFICACIN DIFERIDA............................................. 22
3.2.3. TCNICAS DE RECUPERACIN BASADAS EN MODIFICACIN INMEDIATA.......................................... 23
3.3. SEGURIDAD ............................................................................................................................................................. 24
3.3.1. CONTROL DE ACCESOS.................................................................................................................................. 24
3.3.1.1. CONTROL DE ACCESO DISCRECIONAL ................................................................................................................... 24
3.3.1.2. CONTROL DE ACCESO OBLIGATORIO ..................................................................................................................... 25
4. ADMINISTRACIN DE DATOS .................................................................................................................................. 26
5. CONCLUSIN ................................................................................................................................................................. 27
6. BIBLIOGRAFA .............................................................................................................................................................. 27
7. ESQUEMA RESUMEN ................................................................................................................................................ 28

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 1 de 29
1. ADMINISTRACIN DE SISTEMAS DE GESTIN DE BASES DE DATOS
En algunas organizaciones se ha dividido la administracin de los recursos del sistema de informacin en dos
partes: Administracin de Datos y Administracin de Sistemas de Gestin de Base de Datos.

El Administrador de Datos es el responsable del control sobre todos los datos de una organizacin. Algunas de
las funciones principales son:

Establecer la arquitectura de los datos a nivel conceptual.


Establecer estndares para la descripcin y definicin de los datos y controlar el cumplimiento de estos
estndares.
Asegurar una documentacin adecuada para la descripcin de los datos.

Se puede definir un sistema de gestin de base de datos (SGBD) como un conjunto de programas,
procedimientos, lenguajes, etc. que proporciona a los distintos usuarios de la base de datos (ya sean usuarios
finales o usuarios informticos) los medios necesarios para describir y manipular la informacin incluida en la
base de datos; y para realizar todas las tareas de administracin necesarias para mantenerlas operativas,
garantizando su integridad, confidencialidad y seguridad

Un SGBD, como su propio nombre indica, existe para facilitar la gestin de la base de datos. Tpicamente
proporciona los servicios siguientes:

Herramientas para la definicin y el control centralizado de los datos: Definicin de todos los elementos
de datos en la base de datos en los tres niveles de abstraccin existentes (externo, conceptual, interno).
Descripcin de los datos (campos, grupos, registros, tablas) y las relaciones entre las diferentes
estructuras de datos.
Manipulacin de los datos: el SGBD debe ser capaz de atender las solicitudes del usuario para extraer,
modificar o aadir datos a la base de datos.
Mecanismos de seguridad e integridad de datos: proporcionando los medios para definir y gestionar las
autorizaciones de acceso, ya sea mediante claves de acceso al sistema o mediante la definicin de vistas
externas de usuario. Proporciona as mismo los medios para garantizar la integridad y la consistencia de
los datos definiendo restricciones sobre los valores que pueden tomar y proporcionando capacidades de
recuperacin ante fallos y de copia de seguridad.
Garantiza la disponibilidad de la informacin: asegurando el acceso concurrente a varios usuarios
simultneos.
Utilidades para la consulta, la manipulacin y la elaboracin de informes.
Utilidades para el desarrollo de sistemas de aplicacin.

Todos estos componentes, adems de la propia base de datos, necesitan de una funcin de administracin: la
Administracin de Sistemas de Gestin de Bases de Datos. La persona (o personas) sobre la que recae esta
tarea es el Administrador del Sistema de Gestin de Base de Datos.

A la funcin de administrar la base de datos se la llama Administracin de la Base de Datos, y a la persona que
ejercita la funcin, Administrador de la Base de Datos. Es bastante comn denominarle DBA, acrnimo del ingls
Data Base Administrator.

El Administrador del Sistema de Gestin de Base de Datos es un profesional experto en tecnologas de la


informacin, o al menos con una amplia formacin en ese terreno, que se encarga de crear la base de datos en s
y de aplicar los controles tcnicos necesarios para poner en marcha las polticas dictadas por el Administrador de
Datos. Tiene que tener por tanto un profundo conocimiento de las polticas y normas de la organizacin con
respecto a la informacin, y del criterio de aplicacin de dichas polticas y normas.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 2 de 29
Se encarga tambin de garantizar que la informacin est disponible para los usuarios y las aplicaciones de una
forma precisa y consistente, y en el momento en que sea requerida. Adems proporciona otros servicios de ndole
tcnica relacionados con todo lo anterior.

2. FUNCIONES
Las funciones del Administrador del SGBD se pueden englobar en tres aspectos: funciones de gestin, funciones
de seguridad y funciones diarias.

Entre las funciones de gestin estn:

Seleccin de un SGBD. Diseo fsico e implementacin de la base de datos.


Comunicacin con los usuarios. El DBA debe aconsejar a los usuarios sobre la forma ms apropiada de
utilizar el sistema: consultas sobre diseo de aplicaciones, instruccin tcnica, ayuda en la localizacin y
resolucin de problemas, etc. A su vez los usuarios informan al DBA de posibles deficiencias detectadas
en el sistema.
Hacer de enlace con la gerencia de la organizacin. El DBA informa a la gerencia sobre posibles
deficiencias y mejoras a introducir en el sistema, ya sea en las polticas operativas o en nuevos
requerimientos de los usuarios.
Mantenimiento del Catlogo o diccionario de datos. Es una parte de la base de datos que es
autodescriptiva: contiene informacin que describe la estructura de los datos.
Mantenimiento del software de la base de datos y de herramientas relacionadas. El DBA es el enlace con
los vendedores del software y es el encargado de mantener las licencias, instalar parches y nuevas
versiones del software, etc.

Entre las funciones relacionadas con la seguridad:

Concesiones de autorizacin para el acceso a los datos. Aqu entra el sistema de identificacin de
usuarios para acceder al sistema, otorgamiento y revocacin de privilegios, etc.
Definicin de los procedimientos de respaldo y recuperacin.

Entre las funciones diarias estn:

Monitorizacin de la capacidad. El objetivo es predecir el crecimiento del espacio requerido por la base de
datos, que estar en funcin de los patrones de uso de la misma.
Monitorizacin de la actividad y del rendimiento. Se deben generar informes peridicos sobre el uso de
recursos y sobre el rendimiento de las aplicaciones, as como investigar las quejas de los usuarios
respecto al mismo. Basndose en estos informes se estudia si es necesario realizar cambios en la
estructura de la base de datos o en el diseo de las aplicaciones. Analizando la actividad se pueden
detectar adems fallos en la seguridad.
Modificaciones en la base de datos. Estas modificaciones pueden incluir tanto al esquema conceptual
especfico como a la organizacin fsica o los parmetros de configuracin de la base de datos.

A continuacin vamos a estudiar con ms detalle algunas de estas funciones del Administrador de los SGBD.

2.1. SELECCIN DE UN SGBD. IMPLEMENTACIN DE LA BASE DE DATOS

La implementacin de la base de datos es una de las funciones ms importantes del DBA. En esta fase del ciclo
de vida del desarrollo de bases de datos:

Se selecciona un SGBD como paso previo a la implementacin de la base de datos.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 3 de 29
A partir del diseo conceptual de datos hecho por el Administrador de Datos, se crea el esquema lgico
especfico que ser descrito en el lenguaje de definicin de datos (DDL, Data Definition Language) del
SGBD que se est utilizando.
Se construye el diccionario de datos.
Se crea el diseo fsico de la base de datos
Se cargan los datos, para lo que se utiliza el lenguaje de manipulacin de datos (DML. Data Manipulation
Language).

Para seleccionar un SGBD hay que evaluar su capacidad para satisfacer los requisitos de informacin de la
organizacin. Es necesario considerar las funciones que proporciona y sus propiedades fundamentales.

Los puntos a considerar son:

Arquitecturas: qu arquitecturas de implantacin (por ejemplo, cliente/servidor, distribuida, centralizada)


permite el SGBD especfico y qu modelo de datos (relacional, orientado a objetos, etc.).
Dimensionamiento: el SGBD debe garantizar que es capaz de manejar el volumen de datos requerido.
Rendimiento transaccional: si se va a utilizar el SGBD en un entorno transaccional, debe ser capaz de
soportar el rendimiento transaccional y los tiempos de respuesta que se hayan determinado como
exigibles.
Plataformas: sobre que plataformas fsicas y lgicas puede funcionar el SGBD.
Seguridad e integridad de datos: capacidades que proporciona respecto a los controles de acceso,
controles de concurrencia, controles de recuperacin y cifrado de datos.
Herramientas de administracin: qu herramientas administrativas pone a disposicin del administrador.
Utilidades para la consulta, la manipulacin y la elaboracin de informes: qu lenguajes y herramientas
posee para la consulta y manipulacin de datos, o cual es la capacidad de generacin de informes en
varios formatos
Utilidades para el desarrollo de sistemas de aplicacin: qu facilidades posee para el desarrollo de
aplicaciones y sus pruebas.

Estos elementos dan una gua para determinar los criterios de evaluacin par la seleccin de un SGBD.

Un mtodo convencional para obtener informacin til para la evaluacin del rendimiento de un SGBD son las
pruebas de evaluacin. Lo que se pretende es simular el entorno de una aplicacin tipo para generar datos de
rendimiento realistas. Hay que considerar los siguientes factores a la hora de hacer la prueba de evaluacin:

Las pruebas deben ser representativas del entorno de la organizacin.


Hay que fijar la naturaleza de la prueba antes de realizarla.

Existen varias pruebas de rendimiento (benchmark) estndar que ofrecen datos tiles, entre ellas las del Consejo
para el Rendimiento del Procesamiento de Transacciones (TPC, Transaction Processing Performance Council).

El TPC es un organismo fundado en 1988 al que pertenecen ms de cuarenta fabricantes de plataformas fsicas y
lgicas de bases de datos, que ha definido una serie de normas estndares para pruebas de sistemas de bases
de datos.

La primera fue la TPC-A. Mide el rendimiento en entornos de bases de datos del tipo OLTP. La medida que utiliza
para el rendimiento es la productividad, expresada como transacciones por segundo (TPS).

La prueba TPC-B se dise para probar el rendimiento del ncleo del sistema de base de datos en el sistema
operativo en que se ejecuta.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 4 de 29
La prueba TPC-C se dise para modelar un sistema ms complejo que el modelado por la TPC-A. Mide el
comportamiento de los componentes del sistema asociados tanto con el proceso de transacciones on-line como
los de entrada de rdenes.

La prueba TPC-D se dise para examinar el rendimiento de los sistemas de bases de datos con respecto a las
consultas de ayuda a la toma de decisiones.

Se suelen utilizar mtodos formales para la evaluacin. De entre ellos, quiz, el ms sencillo sea el modelo de
puntuacin.

En el modelo de puntuacin:

se comienza por determinar las propiedades requeridas que pueden ser verificadas.
se clasifican estas propiedades en categoras. Por ejemplo, Codasyl propona la siguiente clasificacin:
obligatorias, opcionales, importantes, opcionales, innecesarias, no deseables. En la prctica muchas
veces se limita a dos categoras: obligatorias y deseables.
se asigna entonces un peso a cada categora o un peso individual a cada propiedad y un valor a cada
propiedad para cada uno de los SGBD que se estn evaluando.
se crea una tabla de puntuaciones finales: se obtiene primero la puntuacin de cada propiedad, en cada
SGBD, multiplicando el peso de la propiedad por el valor que se la ha asignado; y sumando estas
puntuaciones se obtiene la puntuacin final del SGBD.

Por ejemplo, consideremos que para la evaluacin de tres SGBD S1, S2 y S3 se han seleccionado como
propiedades obligatorias los controles de seguridad y recuperacin y las facilidades de cifrado, y como deseables
el entrenamiento a los usuarios y el lenguaje de consulta, y que se han asignado los siguientes pesos y valores a
cada propiedad:

Pesos Valores
Propiedades S1 S2 S3
Obligatorias Controles Seguridad 10 9 7 6
Facilidades Cifrado 10 7 7 7
Deseables Entrenamiento usuarios 8 0 10 10
Lenguaje de consulta 9 4 6 7

La tabla de puntuaciones finales sera entonces:

Pesos Puntuaciones
Propiedades S1 S2 S3
Obligatorias Controles Seguridad 10 90 70 60
Facilidades Cifrado 10 70 70 70
Deseables Entrenamiento usuarios 8 0 80 80
Lenguaje de consulta 9 36 54 63

PUNTUACION FINAL 196 274 273

2.2. DEFINICIN DE PROCEDIMIENTOS DE RESPALDO Y RECUPERACIN

Mantener unos buenos procedimientos de respaldo y recuperacin de la base de datos es fundamental en


cualquier organizacin. Los costes ocasionados por una prdida de datos o por no tenerlos disponibles durante
algn periodo de tiempo sensible pueden ser devastadores.

Los datos pueden perderse o corromperse por varias causas, por ejemplo,

Fallos fsicos del sistema

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 5 de 29
Fallos en el propio SGBD
Errores en procesos
Errores de aplicaciones o usuarios.

Realizando copias de seguridad frecuentes nos aseguramos de que podemos recuperar los datos perdidos.

2.2.1. CONCEPTO DE RESPALDO Y RECUPERACIN

Respaldo y recuperacin, en general, se refiere a las diversas estrategias y operaciones que intervienen en la
proteccin de la base de datos frente a la prdida de datos, y a la reconstruccin de esos datos en caso de que
se produzca la prdida.

Un respaldo (backup) es una copia de los datos por motivos de seguridad. Es una salvaguarda frente a errores de
las aplicaciones y prdidas inesperadas de datos.

Podemos clasificar los backups en:

Fsicos: son copias de los ficheros fsicos, de los ficheros de control y de los logs diarios de la base de
datos. Se pueden realizar con utilidades del propio SGBD o del sistema operativo. Los ficheros logs
diarios son los ficheros donde se guarda toda la informacin necesaria para deshacer (o rehacer si hay
que recuperar) las modificaciones a los datos de la base de datos. (Se ven con detalle en el punto 3.2.1.)
Lgicos: contienen datos que estn estructurados segn la estructura lgica de la base de datos. Se
realizan con utilidades del SGBD y se utilizan como un complemento de los backups fsicos.

Desde otro punto de vista, se pueden clasificar en:

Incrementales: contienen slo los bloques que han cambiado desde la ltima copia.
Totales: contienen todos los bloques.

Y desde el punto de vista de la consistencia se clasifican en:

En fro (consistentes): son los backups que se realizan despus de cerrar la base de datos (totalmente o
solo para consultas) de una manera limpia.
En caliente (inconsistentes): se realizan con la base de datos abierta (se permiten actualizaciones) o
despus de un cierre anormal de la misma.

Restaurar un fichero de datos es la accin de reconstruirlo a partir de una copia de seguridad y tenerlo disponible
para el SGBD. Recuperar un fichero de datos restaurado es actualizarlo aplicando los registros del log diario.

Al conjunto de ficheros necesarios para la recuperacin se le llama conjunto de redundancia. Este conjunto
depende del tipo de SGBD, pero por lo general comprende:

El ltimo backup de todos los ficheros de la base de datos.


Los logs diarios generados despus del ltimo backup.
Un duplicado de los ficheros de control y de configuracin de la base de datos.

2.2.2. ESTRATEGIA BSICA DE RESPALDO Y RECUPERACIN

Aunque las operaciones de respaldo y recuperacin pueden resultar complicadas a veces, los principios bsicos
para desarrollar una estrategia efectiva son:

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 6 de 29
Realizar copias frecuentes de los ficheros de datos y de los ficheros de control de la base de datos.
Mantener varias copias idnticas de los logs diarios en varios discos, es decir, tener los logs diarios en
modo dual.
Mantener varias copias concurrentes de los ficheros de control de la base de datos.

Incluso en el caso de prdida total, manteniendo backups de los ficheros de datos, de los ficheros de control y de
los logs diarios en almacenamientos seguros se podra recrear la base de datos original.

Una primera medida que se puede adoptar como regla de oro del respaldo y la recuperacin es mantener los
discos que contienen el conjunto de redundancia aparte de los discos que contienen los ficheros de datos, los
logs diarios y los ficheros de control. Esta estrategia nos va a asegurar que la perdida de un disco que contiene
un fichero de datos no va a provocar la prdida de los ficheros necesarios para su restauracin y recuperacin.

2.2.3. ESTRATEGIA DE RESPALDO

La estrategia de respaldo desde luego depende del entorno en el que se est operando y de sus restricciones,
pero se pueden dar unas lneas generales a seguir en la determinacin de la estrategia.

Es esencial en cualquier estrategia de recuperacin hacer backups frecuentes. La frecuencia y el tipo de backups
que se deben realizar varan en funcin del entorno de operacin. Para determinar la frecuencia de las copias
peridicas nos debemos basar en la tasa de cambios; cambios como actualizacin (insercin, borrado o
modificacin) de datos de las tablas o creacin y eliminacin de tablas.

Se debe realizar un backup siempre que se realicen cambios estructurales en la base de datos.

Adems hay que mantener los respaldos antiguos durante un determinado periodo de tiempo por dos razones
fundamentales: posible corrupcin del ltimo backup o necesidad de recuperar algn objeto en algn momento
anterior al ltimo backup.

2.2.4. ESTRATEGIA DE RECUPERACIN

Se debe planificar la respuesta a dar tanto ante fallos en los medios como ante otro tipo de fallos.

Un fallo en los medios es un problema fsico que se presenta cuando se intenta leer o escribir en un fichero
necesario para la operacin de la base de datos y no se consigue. Los principales tipos son:

Corrupcin, borrado o sobreescritura accidental de algn fichero de datos, log diario o fichero de control.
Fallos de discos.

La estrategia de recuperacin depende del tipo de fallo en los medios pero los pasos bsicos son:

Determinar los ficheros que hay que recuperar.


Determinar el tipo de recuperacin necesaria: completa o incompleta.
Restaurar los ficheros necesarios.
Actualizar los ficheros restaurados con las entradas del log diario.

Los fallos en los medios son la principal preocupacin al desarrollar una estrategia de recuperacin, pero tambin
hay que tener en cuenta otros tipos de fallos como por ejemplo, una cada de la base de datos debida a un fallo
en el sistema operativo o a una interrupcin de corriente, errores de usuario o errores en procesos.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 7 de 29
Afortunadamente los SGBD poseen mecanismos de recuperacin automtica para muchos de estos fallos. Por
ejemplo, al abrir de nuevo la base de datos detectan que no se cerr de una manera limpia y ponen entonces en
marcha automticamente los procedimientos para sincronizar los datos utilizando las entradas de los logs diarios.

Otros fallos como cambios accidentales o errneos de la base de datos que producen prdida o corrupcin de
datos no es posible recuperarlos automticamente y se deben recuperar los datos perdidos manualmente.

2.3. AJUSTE DEL RENDIMIENTO

El punto fundamental para ajustar el rendimiento es el descubrimiento y eliminacin de los cuellos de botella.

Los administradores de las bases de datos pueden ajustar los sistemas a tres niveles:

Hardware
Parmetros del sistema
Esquema de la base de datos y transacciones.

Las opciones en el nivel inferior, el hardware, son, por ejemplo: aadir ms discos o mejores sistemas de E/S, si
el cuello de botella est en el sistema de E/S; aadir ms memoria, si el tamao de la memoria intermedia es el
cuello de botella; utilizar procesadores ms rpidos, si la CPU es el cuello de botella.

El segundo nivel consiste en ajustar parmetros del sistema de base de datos como pueden ser el tamao de la
memoria intermedia o los intervalos de comprobacin. El conjunto exacto de parmetros del sistema de base de
datos que pueden ajustarse depende de cada sistema.

En el tercer nivel, el nivel superior, se puede ajustar el diseo del esquema y las transacciones que se ejecutan
para mejorar el rendimiento.

Por ejemplo, si las consultas constituyen el cuello de botella, se suelen poder acelerar creando ndices adecuados
en las relaciones o creando clusters. Si el cuello son las actualizaciones puede que haya demasiados ndices que
mantener cuando se actualizan las tablas.

Tanto las transacciones de slo lectura como las de actualizacin pueden ajustarse. Los optimizadores actuales
pueden transformar incluso las consultas mal escritas y ejecutarlas eficazmente. Sin embargo, los optimizadores
tienen sus lmites en lo que pueden hacer. El administrador de la base de datos puede descubrir el plan de
ejecucin exacto de las consultas mediante utilidades proporcionadas por el SGBD, estudiarlo y aplicar (o
proponer a quien corresponda) los cambios necesarios en las mismas para mejorar su rendimiento.

3. RESPONSABILIDADES
Las tres responsabilidades bsicas de la Administracin del Sistema de Gestin de Bases de Datos son:

Mantener la integridad de los datos: hay que asegurar que las operaciones ejecutadas por los usuarios o
aplicaciones son correctas y mantienen la consistencia de los datos.
Mantener la disponibilidad de los datos: se tienen que proporcionar medios para el restablecimiento de la
base de datos a un estado correcto tras una corrupcin de la misma por desperfectos del sistema, ya
sean de hardware o de software. Por otra parte, el administrador debe tratar por todos los medios de
mantener la disponibilidad, desde el punto de vista del acceso a los datos, durante las 24 horas del da,
los 7 das de la semana y los 365 das de ao.
Mantener la seguridad: se debe limitar la ejecucin nicamente a las operaciones que estn permitidas y
proteger la base de datos de usos malintencionados o no autorizados (seguridad de datos).

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 8 de 29
3.1. INTEGRIDAD

Mantener la integridad de la base de datos consiste en mantener la correccin, validez y precisin de los datos.

Existen dos tipos de operaciones que pueden provocar prdida de integridad de los datos:

Operaciones inconsistentes semnticamente.


Interferencias debidas a accesos concurrentes.

3.1.1. INTEGRIDAD SEMNTICA

Existen operaciones que pueden violar las restricciones semnticas definidas al disear la base de datos. Para
prevenir la prdida de integridad por este motivo el SGDB debe:

Comprobar la coherencia de las reglas de integridad semntica que se definen.


Controlar las transacciones y detectar las violaciones de integridad.
Ejecutar lar acciones pertinentes en caso de que se produzca una violacin.

Adems en sistemas multiusuario son necesarios mecanismos de control de concurrencia para conservar la
integridad.

3.1.2. CONCEPTO DE TRANSACCIN

Para mantener la integridad de la base datos hay que poder asegurar que despus de una modificacin de los
datos, la base de datos queda en un estado consistente. Para conseguir esto se utilizan las transacciones.

Las transacciones constituyen unidades lgicas de proceso formadas por secuencias de operaciones que han de
ejecutarse de forma atmica, es decir, o bien se realizan todas las operaciones que comprenden la transaccin o
bien no se realiza ninguna.

Las principales propiedades de una transaccin son:

Atomicidad: se ejecutan todas las sentencias de la transaccin o ninguna.


Preservacin de la consistencia: la base de datos se encuentra en un estado consistente antes de la
ejecucin de la transaccin y debe estarlo cuando finalice la transaccin.
Aislamiento: no muestra los cambios que realiza hasta que termina.
Persistencia: los efectos de una transaccin finalizada con xito perduran en la base de datos.

En el nivel que estamos tratando las transacciones, para el control de la concurrencia y la recuperacin, las
operaciones de acceso a una base de datos que una transaccin puede incluir son:

Leer_tem(X): lee el tem X y almacena su valor en una variable del rea de trabajo de la transaccin.
Escribir_tem(X): graba el valor de la variable del rea de trabajo en el tem X.

Las operaciones de una transaccin hacen que esta vaya cambiando de estado. La siguiente figura muestra el
diagrama de transicin de estados de una transaccin.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 9 de 29
Estado activo: una transaccin pasa al estado activo inmediatamente despus de comenzar su ejecucin.
Las diversas operaciones de lectura y escritura no provocan un cambio de estado.
Estado parcialmente confirmado: cuando terminan las operaciones pasa a este estado. En este punto
algunas tcnicas de control de concurrencia (lo mismo que ciertos protocolos de recuperacin.) requieren
la realizacin de ciertas comprobaciones.
Estado confirmado: si se pasan todos los controles anteriores pasa al estado confirmado.
Estado fallido: si no se pasan los controles anteriores o si se produce un fallo desde el estado activo,
pasa a estado fallido.
Estado abortado: despus de un fallo y una vez desechos los cambios pasa a estado abortado.
Estado terminado: pasa al estado terminada cuando desaparece del sistema.

3.1.3 PROBLEMAS CLSICOS DE CONCURRENCIA

Los cuatro problemas tpicos de la concurrencia son:

El problema de la modificacin perdida.


El problema de la modificacin temporal.
El problema de la totalizacin incorrecta.
El problema de la lectura no repetible.

El problema de la modificacin perdida: dos transacciones concurrentes T1 y T2 acceden a los mismos datos,
tienen operaciones intercaladas y asignan incorrectamente el valor de algn elemento. Veamos un ejemplo:

Figura B1. Modificacin perdida

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 10 de 29
La transaccin T1 lee el elemento A y le resta N. La transaccin T2 lee el elemento A cuando T1 todava no ha
escrito su modificacin sobre A, y le suma N. T1 escribe el elemento A y T2 escribe el A. El resultado es que la
modificacin realizada por T1 sobre A se pierde.

Al problema de la modificacin temporal tambin se le conoce como problema de la lectura sucia. Se produce
cuando una transaccin modifica un tem y a continuacin la transaccin falla por alguna razn; otra transaccin
lee el tem modificado antes de que el cambio sea desecho y el tem vuelva a su valor original.

La figura siguiente muestra un ejemplo de lectura sucia.

Figura B2. Lectura sucia

T1 lee un valor de A, le resta N y lo escribe. T2 lee A le suma N y lo escribe. T1 lee B y falla y se hace rollback de
T1 dejando el valor de A a su valor original, con lo que el valor ledo por T2 es incorrecto.

El problema de la totalizacin incorrecta se produce si una transaccin est calculando una funcin de totalizacin
agregada sobre varios registros mientras otra transaccin est modificando algunos de estos registros. La funcin
agregada puede realizar el clculo con algunos valores antes de que sean modificados y otros despus.

Figura B3. Totalizacin incorrecta

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 11 de 29
T2 lee B despus de que T1 le haya restado N y lee C antes de que T1 le sume N, con lo que el valor de suma es
incorrecto.

El problema de la lectura no repetible ocurre cuando una transaccin lee un elemento dos veces y en el intervalo
entre ambas lecturas otra transaccin modifica el elemento.

Figura B4. Lectura no repetible

T2 lee A, T1 lo modifica y T2 vuelve a leer A, por lo que T2 recibe dos valores distintos de A.

3.1.4. PLANIFICACIN DE TRANSACCIONES. PLANES SERIALIZABLES.

Dado un conjunto de transacciones, a cada una de las ordenaciones que se pueden hacer combinando el orden
de ejecucin de las operaciones de las transacciones, con la restriccin de que el orden interno de las
operaciones en cada transaccin se debe mantener, se le denomina plan de ejecucin del conjunto de
transacciones.

Se dice que un plan es serial si para cada transaccin del plan todas sus operaciones se ejecutan
consecutivamente en el plan.

Es condicin necesaria y suficiente para que la ejecucin concurrente de varias transacciones sea correcta que
su efecto sea el mismo que el obtenido al realizar las mismas transacciones en serie.

Se dice que un plan es serializable si es equivalente a algn plan serial de las mismas transacciones.

Por tanto, para asegurar la consistencia tenemos que tener planes de ejecucin seriales o serializables.

3.1.5. TCNICAS DE CONTROL DE CONCURRENCIA

Las tcnicas de control de concurrencia son las que ayudan a resolver los problemas descritos en el apartado
3.1.3. Las tcnicas ms clsicas son las basadas en bloqueos y las que utilizan marcas de tiempo. Otra
modalidad de control de concurrencia la forman las tcnicas optimistas.

Hay, aplicaciones de bases de datos que necesitan otros mecanismos de control de concurrencia ms
avanzados, sobre todo en las bases de datos orientadas a objetos, o que permitan el anidamiento de
transacciones o transacciones de larga duracin (que pueden durar varios das). Entre las tcnicas ms
avanzadas estn las tcnicas de bloqueo altruista o las tcnicas de control de concurrencia basado en semntica.

A continuacin vemos cada una de estas tcnicas.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 12 de 29
3.1.5.1. BLOQUEOS

Se puede definir bloqueo (tambin llamado cerrojo) como una variable asociada con un tem de la base de datos
que describe su estado respecto a las posibles operaciones (lectura o actualizacin) que le pueden ser aplicadas.

Los bloqueos pueden ser:

Bloqueos exclusivos (o de escritura). Se utiliza cuando una transaccin quiere actualizar algn objeto. Si
una transaccin mantiene un bloqueo exclusivo sobre un objeto, ninguna otra transaccin puede acceder
a l, ni aplicar ningn tipo de bloqueo sobre ese objeto, hasta que sea liberado por la transaccin que lo
haba retenido.
Bloqueos compartidos (o de lectura). Se utiliza cuando una transaccin quieren impedir cualquier
modificacin de los datos mientras son consultados Si una transaccin tiene un bloqueo compartido sobre
un objeto, permite que otras transacciones retengan tambin ese mismo objeto en bloqueos compartidos,
pero no exclusivos.

El empleo sin ms de los tipos de bloqueos comentados no garantiza que los planes sean serializables. Para
garantizar la serializabilidad se suele utilizar el protocolo de bloqueo en dos fases (two phase locking), en el que
todas las operaciones de bloqueo preceden a la primera operacin de desbloqueo. Dicho de otra manera, una vez
que una transaccin libera un bloqueo no puede realizar ningn otro bloqueo adicional.

Un problema con las tcnicas de bloqueo es el interbloqueo o deadlock. Se produce una situacin de
interbloqueo cuando dos o ms transacciones estn en espera permanente al permanecer cada una de ellas
aguardando a que la otra libere algn objeto antes de seguir.

Se pueden adoptar dos aproximaciones para el problema del interbloqueo: la prevencin o la deteccin.

En la deteccin del interbloqueo se controla de forma peridica si se ha producido interbloqueo, generalmente


construyendo un grafo de espera (con un nodo para cada transaccin y arco de la transaccin A a la B si A est
esperando a que B libere un bloqueo). Si existe un ciclo en el grafo se tiene un interbloqueo. El sistema elige
entonces una transaccin para abortarla. Cada SGBD tiene su propia poltica para escoger las vctimas, aunque
suelen ser las transacciones ms recientes.

Entre las tcnicas de prevencin del interbloqueo se encuentran las basadas en marcas de tiempo, las basadas
en esperas, las basadas en time-out y el bloqueo en dos fases conservativo.

Las marcas de tiempo o estampillas, son identificadores nicos creados por el SGBD que se asignan a las
transacciones. La forma tpica de asignar los valores a las marcas de tiempo es por el orden segn el cual llegan
las transacciones al sistema, por lo que pueden considerarse como el tiempo de inicio de la transaccin. Si una
transaccin T1 tiene una marca de tiempo, TS(T1), menor que la marca de otra transaccin T2, TS(T2) se dice
que T1 es ms antigua que T2.

Existen dos mtodos simples para implementar ese esquema:

Usar el valor del reloj del sistema como marca temporal.


Usar un contador lgico que se incrementa cada vez que se asigna una nueva marca temporal.

Los dos protocolos principales para la prevencin del interbloqueo basados en marcas de tiempo son:

WAIT-DIE: si una transaccin T1 intenta bloquear un tem bloqueado por otra transaccin T2 y T1 es ms
antigua que T2 entonces T1 espera; en el caso de que T1 sea ms reciente entonces T1 muere (se
aborta y se reinicia ms tarde con la misma marca temporal). Es decir, la transaccin ms antigua espera
por la ms reciente pero la ms reciente no espera por la ms antigua sino que es forzada a morir.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 13 de 29
WOUND-WAIT: si una transaccin T1 intenta bloquear un tem bloqueado por otra transaccin T2 y T1 es
ms antigua que T2 entonces T2 es forzada a abortar y se reinicia con la misma marca temporal; si T1 es
ms reciente entonces puede esperar.

La prevencin basada en esperas no utiliza marcas de tiempo sino que sigue uno de los dos esquemas
siguientes:

Espera cautelosa (cautious waiting): Si T1 intenta bloquear un tem bloqueado por T2 se le permite
esperar siempre que T2 no est esperando por otra transaccin. Si este es el caso se fuerza a T1 a
abortar.
No esperar: Si T1 intenta bloquear un tem que est bloqueado por T2, T1 se aborta.

La idea bsica de los esquemas de prevencin basados en time-out es que una transaccin espera para poder
realizar un bloqueo durante un periodo de tiempo especificado, el time-out. Si ese tiempo es excedido entonces la
transaccin se aborta y se reinicia ms tarde. En una situacin de interbloqueo alguna de las transacciones
implicadas ser la primera en exceder el time-out, entonces se aborta y permite a la otra continuar.

Finalmente, la ltima tcnica de prevencin del interbloqueo mencionada, el bloqueo en dos fases conservativo
consiste en realizar todos los bloqueos antes de la ejecucin de la transaccin, se debe esperar a que todos los
bloqueos estn disponibles.

Otro problema que puede ocurrir con los bloqueos es el llamado bloqueo activo (livelock). Se produce cuando una
transaccin no puede procesarse durante un perodo de tiempo indefinido, mientras otras transacciones continan
normalmente. Por ejemplo, si la transaccin T2 est esperando a que T1 libere un elemento A, pero cuando lo
libera lo bloquea T3, luego T4, etc., de manera que T2 est esperando a poder bloquear el elemento A
indefinidamente, se dice que T2 est en un estado de bloqueo activo.

La solucin a este problema es implementar un algoritmo de esperas adecuado. Una de las tcnicas de gestin
de esperas utiliza una cola FIFO de forma que las transacciones tienen acceso al bloqueo sobre un tem en el
mismo orden en el que solicitaron dicho bloqueo.

Se denomina granularidad del bloqueo a los distintos niveles a los que se aplica:

a un registro (o a una tupla)


a un fichero (o a una relacin)
a la base de datos en su totalidad.

La granularidad ha de establecerse teniendo en cuenta que

una granularidad muy gruesa implica tener que gestionar un menor nmero de bloqueos, pero perjudica
la concurrencia retrasando la ejecucin de muchas transacciones.
una granularidad ms fina permite una mayor concurrencia, pero aparecen ms situaciones de
interbloqueo.

Para terminar este punto de las tcnicas de bloqueo vamos a recuperar los ejemplos de transacciones puestos
para ilustrar los problemas clsicos de concurrencia (seccin 3.1.3) y mostrar como desaparecen dichos
problemas con la tcnica de bloqueo en dos fases.

Considerando las dos transacciones de la Figura B1 - Modificacin perdida, pero aplicando el bloqueo en dos
fases, tenemos ahora:

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 14 de 29
Al forzar a la transaccin T2 a esperar a que la transaccin T1 libere el tem A, cosa que sucede una vez que se
ha escrito A, la modificacin realizada por T1, restar N al valor original de A, es vista por T2. Al finalizar las dos
transacciones el valor de A es el que tena originalmente (T1 le resta N y T2 se lo suma).

Si consideramos ahora las dos transacciones de la Figura B2 Lectura sucia, con el bloqueo en dos fases, el
valor de A ledo ahora por T2 es el correcto ya que para leerlo ha tenido que esperar a que se completara el
rollback de T1 y se liberara el tem.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 15 de 29
Para el caso de las transacciones de la Figura B3 Totalizacin incorrecta, ahora se tiene

Todas las lecturas realizadas por T2 son consistentes entre s, pues se han hecho una vez que T1 ha actualizado
sus modificaciones.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 16 de 29
Y finalmente para el caso de las Figura B4 Lectura no repetible, con bloqueos pasa a

donde T2 siempre lee el mismo valor de A pues T1 no lo puede modificar hasta que no es desbloqueado por T2.

3.1.5.2. ORDENACIN POR MARCAS DE TIEMPO (TIMESTAMPING)

En los protocolos de bloqueo que se han descrito antes se determina el orden entre dos transacciones conflictivas
en tiempo de ejecucin a travs del primer bloqueo que solicitaran ambas y que trajera consigo modos
incompatibles. Otro mtodo para determinar el orden de secuenciacin es seleccionar previamente un orden entre
las transacciones. El mtodo ms comn para hacer esto es utilizar un esquema de ordenacin por marcas
temporales o marcas de tiempo. Esta tcnica se denomina ordenacin por marcas de tiempo.

Con las tcnicas de interbloqueo se sincronizaba la ejecucin de las transacciones consiguiendo un plan de
ejecucin de las transacciones que fuera equivalente a algn plan de ejecucin serial. Con la tcnica de
ordenacin por marcas de tiempo se consigue un plan de ejecucin que es equivalente a un plan de ejecucin
serial especfico: el definido por el orden cronolgico de las marcas de tiempo de las transacciones. Se selecciona
a priori el orden de serializacin y se fuerza a que las transacciones sigan ese orden.

Adems de las marcas de tiempo de las transacciones se mantiene para cada tem X en la base de datos dos
marcas de tiempo:

La marca de tiempo de lectura, TS_lectura(X): es la marca de tiempo mayor entre las marcas de tiempo
de todas las transacciones que han ledo el tem X.
La marca de tiempo de escritura, TS_escritura(Y): es la marca de tiempo mayor entre las marcas de
tiempo de todas las transacciones que han escrito el tem X.

Cuando una transaccin intenta leer o escribir un tem X, se compara su marca de tiempo con las marcas de
lectura y escritura del tem X para comprobar si se viola el orden de ejecucin. Si es as se aborta la transaccin y
se reinicia ms tarde con una nueva marca de tiempo. Con esta tcnica no se producen situaciones de
interbloqueo, pero si son posibles situaciones similares a los bloqueos activos. Si una transaccin quiere acceder
a algn dato que ha sido actualizado por otra transaccin ms reciente, se aborta y se vuelve a empezar. Podra

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 17 de 29
darse el caso de una transaccin que fuera abortada y restaurada de forma indefinida. Este problema se conoce
como restauracin cclica.

Una operacin de lectura de un tem X por una transaccin T se maneja de la siguiente manera:

Si TS_escritura(X) > TS(T)


Abortar T.
En otro caso
Ejecutar leer(X)
Hacer TS_lectura(X) = mximo (TS(T), TS_lectura(X)).

Y una operacin de escritura:

Si TS_lectura(X) > TS(T) o TS_escritura(X) > TS(T)


Abortar T.
En otro caso
Ejecutar escribir(X).
Hacer TS_escritura(X) = TS(T).

Esta tcnica de ordenacin por marcas de tiempo supone que slo existe una versin de los datos, por lo que
nicamente puede acceder a los mismos una transaccin. Se puede hacer ms flexible esta restriccin
permitiendo que varias transacciones lean y actualicen diferentes versiones del mismo dato, con tal de que cada
transaccin acceda a un conjunto consistente de versiones de todos los datos que necesite.

En la tcnica de ordenacin por marcas de tiempo multiversin cada tem de datos X tiene asociado una sucesin
de versiones X1, X2,, XN, donde cada versin del tem se crea cuando una transaccin realiza con xito una
operacin de escritura sobre X (en lugar de sobrescribir el valor del tem, se crea una nueva versin de ste con
el nuevo valor). Ahora se mantienen dos marcas de tiempo, de lectura y de escritura, por versin de tem y no por
tem como antes. Cuando una transaccin T crea una versin XK de X se inicializan TS_lectura(XK) y
TS_escritura(XK) a TS(T).

Una operacin de lectura de un tem X por una transaccin T se maneja de la siguiente manera:

Siempre se permite y la versin leda de X es aquella XK tal que TS_escritura(XK) es el mximo menor o
igual a TS(T).
Se hace TS_lectura(XK) = TS(T)

Una operacin de escritura de un tem X por una transaccin T se maneja de la siguiente manera:

Se calcula la versin de X, XK, cuyo TS_escritura(XK) es el mximo menor o igual a TS(T).


Si TS(T) < TS_lectura(XK), entonces se aborta la transaccin T.
En otro caso se crea una nueva versin XJ de X.

3.1.5.3. TCNICAS DE TRANSACCIONES ANIDADAS

Se basan en la descomposicin de las transacciones en otras ms pequeas.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 18 de 29
Una transaccin anidada es una composicin de un conjunto de subtransacciones que a su vez pueden ser
anidadas. Las subtransacciones se pueden ejecutar concurrentemente, pudiendo abortarse y restaurarse sin que
afecte a la transaccin principal de la que forma parte.

El resto de transacciones ve la transaccin anidada como una unidad, como si fuera una transaccin normal, por
lo que no afecta a la serializabilidad, pero si mejora el rendimiento.

3.1.5.4. TCNICAS OPTIMISTAS

En las tcnicas vistas anteriormente siempre era necesario realizar algn tipo comprobacin previa a la ejecucin
de cada operacin de la base de datos. Esta comprobacin produce una ralentizacin de la ejecucin de las
transacciones.

En las tcnicas optimistas, tambin llamadas tcnicas de validacin, no se hace ninguna verificacin mientras la
transaccin se est ejecutando. Para ello, las modificaciones que produce la transaccin no se aplican a los
elementos de la base de datos hasta que finaliza la transaccin. Durante la ejecucin los cambios se aplican a
copias locales de los elementos de datos. Al acabar la ejecucin, se realiza una fase de validacin que
comprueba si alguna de las modificaciones viola la serializabilidad. Si no se viola, se confirma la transaccin y se
actualiza la base de datos desde las copias locales. Si se viola la transaccin se aborta y se reinicia

La idea de este tipo de tcnicas es ejecutar las transacciones con una sobrecarga mnima de validacin. Si existe
una baja interferencia entre las transacciones, muchas transacciones sern validadas con xito. Si existe una
interferencia alta, muchas transacciones se ejecutarn pero tendrn que deshacer sus cambios y volver a ser
restauradas. Precisamente el nombre optimista viene de que se da por supuesto que habr poca interferencia
entre las transacciones.

En esta tcnica podemos distinguir tres fases en cada transaccin:

Fase de lectura: una transaccin puede leer valores de la base de datos, pero las modificaciones se
aplican slo a copias locales de los elementos de datos almacenadas en el rea de trabajo de la
transaccin.
Fase de validacin: se realizan controles para garantizar la serializabilidad. Si no se pasa la validacin se
descartan las modificaciones y se restaura la transaccin.
Fase de escritura: si se pasa la validacin las copias locales se hacen globales pasando las
modificaciones realizadas por la transaccin a la base de datos.

3.1.5.5. TCNICAS DE BLOQUEO ALTRUISTA

Se basan en hacer rpidamente una relajacin de los bloqueos una vez que se determina que no se acceder de
nuevo a los datos bloqueados. Para ello se utiliza la informacin de los patrones de acceso de los cuales se
especifican, o bien elementos que nunca sern accedidos por la transaccin (patrones de acceso negativos), o
bien elementos que sern accedidos y en que orden (patrones de acceso positivos).

Para informar al planificador de transacciones de que no se necesita acceder ms a un objeto que est bloqueado
se utiliza la operacin denominada donar. Las transacciones donan objetos antes de que sean desbloqueados
para que puedan ser bloqueados por otras transacciones.

3.1.5.6. TCNICAS DE CONTROL DE CONCURRENCIA BASADO EN SEMNTICA

Se utilizan sobre todo en los Sistemas de Gestin de bases de Datos Orientadas a Objetos (SGBDOO). Utilizan la
semntica de los mtodos para incrementar la concurrencia.

La mayora de las tcnicas semnticas de control de la concurrencia se pueden agrupar en dos categoras:

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 19 de 29
Basadas en la semntica de transacciones: define las propiedades de consistencia basndose en la
semntica de la transaccin y en la de los datos que manipula.
Basadas en la semntica de objetos: gestiona el acceso a cada objeto basndose en la semntica de las
operaciones definidas en el mismo.

Una de las tcnicas de control de la primera categora es la propuesta por Garca-Molina. En ella las
transacciones se clasifican en tipos semnticos en funcin de las operaciones que realizan en la base de datos.
Para cada tipo se define un conjunto de compatibilidad que identifica los otros tipos compatibles con el tipo dado
(es decir, otros tipos de transacciones que se pueden intercalar con l). El usuario (diseador de la base de
datos) divide un tipo de transaccin en pasos atmicos donde cada paso representa alguna accin indivisible del
mundo real. Cualquier intercalacin que se permita est entre estos pasos atmicos. Cuando una transaccin
requiere el acceso a un objeto de datos hace una peticin de bloqueo. Si no existen otros bloqueos sobre el
objeto se autoriza la peticin. Si otra transaccin realiza una peticin de bloqueo sobre el mismo objeto, el
mecanismo de procesamiento de transacciones comprueba si el tipo de transaccin que realiza la nueva peticin
est en el conjunto de compatibilidad de la transaccin que mantiene el bloqueo. Si es as, se autoriza el bloqueo,
si no, debe esperar para acceder al objeto.

En esta tcnica se sustituye el criterio de serializabilidad por el de consistencia semntica para determinar si el
plan de ejecucin es correcto.

En las tcnicas de la segunda categora se incrementa la concurrencia explotando la semntica de los mtodos
de los objetos. Algunas siguen respetando la serializabilidad como criterio de correccin, pero otras aumentan la
concurrencia an ms relajando este criterio. El diseador define en el objeto la compatibilidad entre operaciones.
Esta compatibilidad puede o no ser serializable. Las restricciones de consistencia las determina el diseador y se
implementan a travs de relaciones de compatibilidad.

3.2. DISPONIBILIDAD

Para mantener la disponibilidad de los datos los SGBD proporcionan mecanismos que permiten recuperar la base
de datos cuando ocurran fallos lgicos o fsicos que destruyan los datos.

Desde el punto de vista del SGBD existen tres tipos importantes de fallos:

Fallos en las transacciones:


Por error lgico, como por ejemplo la interrupcin de la ejecucin de una transaccin por exceder el
uso de los recursos asignados o por problemas de datos no encontrados.
Por error del sistema. Interrupcin de transacciones debido a condiciones no deseadas como el
interbloqueo descrito anteriormente.
Cadas del sistema. Los que producen la prdida de la memoria voltil, debidos por ejemplo a un fallo de
hardware o a una interrupcin de corriente elctrica.
Fallos del disco donde residen los datos.

Ante cualquier tipo de fallo lo importante es asegurar que la base de datos se puede recuperar y queda en un
estado consistente. Para esto el SGBD se apoya en dos elementos bsicos: la atomicidad de las transacciones y
el log diario de operaciones o fichero de bitcora.

Para la recuperacin en un caso de fallo del disco que afecte de manera grave a los datos el principio bsico en el
que se apoya la recuperacin es la redundancia fsica (fsica en el sentido de que no es visible a nivel lgico). Se
utiliza una copia de seguridad de la base de datos, que junto con las entradas en los logs diarios que se han
producido despus de hecha la copia de seguridad, va a permitir reconstruir la base de datos y dejarla en el
mismo estado consistente que tena antes de producirse el fallo. A esto se le denomina recuperacin en fro.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 20 de 29
Si ocurre un fallo del tipo cada del sistema que provoque la prdida de la memoria voltil se realiza la
denominada recuperacin en caliente. El sistema consulta el log diario para determinar las transacciones que hay
que deshacer y las que hay que rehacer.

Para la recuperacin de fallos de transacciones hay dos grupos de tcnicas principales:

Las tcnicas de modificacin diferida (la base de datos no se actualiza hasta que una transaccin llega a
su estado confirmado).
Las tcnicas de modificacin inmediata (se permite que algunas operaciones de una transaccin pueden
modificar la base de datos antes de que llegue a su estado confirmado).

A la operacin de deshacer los cambios introducidos en la base de datos por una transaccin, cualquiera que sea
el motivo, se la denomina retroceso (rollback) de la transaccin.

Si hay que hacer rollback de una transaccin T, entonces cualquier otra transaccin S que utilice algn elemento
modificado por la transaccin X tambin debe ser retrocedida; y as sucesivamente. Este fenmeno se conoce
como retroceso en cascada. Si no se permite que una transaccin acceda a datos modificados por transacciones
sin confirmar entonces nunca se producirn retrocesos en cascada.

Vamos a ver a continuacin con ms detalle las tcnicas de modificacin diferida y de modificacin inmediata, y el
concepto de log diario o registro histrico en el que se apoyan.

3.2.1. LOG DIARIO O REGISTRO HISTRICO

Para permitir la recuperacin de transacciones fallidas, el sistema mantiene un fichero denominado log diario o
registro histrico. Tambin se le llama fichero de bitcora.

El registro histrico es una secuencia de anotaciones que mantiene un registro de todas las actividades de
actualizacin de la base de datos. Debe residir en almacenamiento estable. Aqu se guarda toda la informacin
necesaria para deshacer, en caso de fracaso, o rehacer, si hay que recuperar las transacciones.

Un registro del fichero de bitcora suele contener la siguiente informacin:

Identificador de la transaccin, que es nico.


Hora de la modificacin.
Tipo de accin.
Identificador del registro afectado, que es tambin nico del elemento de datos que se escribe.
Valor anterior del registro. Valor del elemento de datos antes de la escritura.
Valor nuevo. Valor del elemento de datos despus de la escritura.

Para representar desde un punto de vista conceptual las operaciones de las transacciones anotadas en el log
diario se suelen utilizar las siguientes estructuras:

[start_transaction, T]: la transaccin con identificador T comienza su ejecucin.


[write_tem, T, X, valor_viejo, valor_nuevo]: la transaccin T cambia el valor del tem X de valor_viejo a
valor_nuevo.
[read_tem, T, X]: la transaccin T lee el valor del tem X.
[commit, T]: la transaccin T ha completado todos sus accesos a la BD, y sus efectos pueden ser
confirmados (registrados permanentemente en la BD).
[rollback, T]: deshacer los cambios efectuados por la transaccin T.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 21 de 29
Para ahorrar grabaciones fsicas del mismo bloque del fichero diario es habitual no grabar un bloque hasta que su
rea o buffer en memoria principal est lleno. Sin embargo si ocurriera un fallo en el sistema slo las entradas del
log diario que han sido pasadas a disco estn disponibles para procesos de recuperacin, ya que los contenidos
de memoria principal se pueden perder. Para evitar esta posible prdida de informacin del log diario , cuando
una transaccin va a pasar a estado confirmado, antes de realizar las actualizaciones en la base de datos, se
pasan a almacenamiento estable todas las anotaciones del log diario correspondientes a dicha transaccin que
an no se hayan grabado. Este proceso se llama forzar la grabacin del fichero de bitcora (log write-ahead
protocol).

En los log diarios tambin se incluyen registros de punto de verificacin o punto de recuperacin (checkpoint). Su
objetivo es evitar la lectura de todo el fichero en caso de ser necesario rehacer o deshacer una transaccin. La
operativa del punto de recuperacin se ejecuta peridicamente y comprende:

Pasar el contenido del buffer de memoria al fichero diario.


Escribir un registro de punto de verificacin en el fichero.
Pasar el contenido de las memorias de rea intermedia de la base de datos a disco.

3.2.2. TCNICAS DE RECUPERACIN BASADAS EN MODIFICACIN DIFERIDA

La idea subyacente en estas tcnicas consiste en diferir cualquier modificacin en la base de datos hasta que se
completa la ejecucin de la transaccin y llega a su estado confirmado:

Una transaccin no puede cambiar la base de datos hasta que alcanza su estado de confirmacin.
Una transaccin no alcanza su estado de confirmacin hasta que todas las operaciones de actualizacin
estn registradas en el log diario y se fuerza la escritura de ste a disco.

Durante la ejecucin los cambios slo se reflejan en el log diario y en el rea de trabajo de la transaccin. Cuando
se confirma la transaccin y se fuerza la escritura a disco del diario (escritura forzada), las modificaciones se
registran en la propia base de datos.

En un entorno monousuario no influyen los problemas de control de concurrencia.

El algoritmo de recuperacin para fallos de transacciones con modificacin diferida en un entorno monousuario,
donde no influyen los problemas de concurrencia, es el siguiente:

Procedimiento RDU_S:
recorrer el diario desde atrs hacia adelante haciendo una lista de las transacciones confirmadas
(entradas con [commit, T]).
Aplicar el procedimiento REDO_W a todas las operaciones de escritura de dichas transacciones
confirmadas en el mismo orden en que se registraron en el diario.
Procedimiento REDO_W: rehacer una operacin Escribir_tem(X) consiste en buscar su entrada
[write_tem, T, X, valor_nuevo] en el diario y asignar a X el valor nuevo.

En sistemas multiusuario donde hay control de concurrencia, los procesos de recuperacin son ms complejos.
Un incremento en el grado de concurrencia supone una mayor dificultad en las tareas de recuperacin Es habitual
que los procesos de control de concurrencia y de recuperacin estn integrados en un nico mtodo que gestiona
ambas tareas.

Si consideramos el bloqueo en dos fases para controlar la concurrencia y la modificacin diferida utilizando
puntos de verificacin (checkpoints), un posible algoritmo de recuperacin para el fallo de una transaccin es el
siguiente:

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 22 de 29
Procedimiento RDU_M:
Recorriendo el diario, desde atrs hacia adelante, hasta la entrada ms reciente de punto de control
[checkpoint].
Hacer dos listas de transacciones, por un lado las transacciones confirmadas (tienen una entrada
[commit, T] en el registro histrico) despus del ltimo [checkpoint]; y por otro las transacciones T' no
confirmadas (tienen una entrada [start_transaction, T'] en el log diario, pero no tienen [commit, T']).
Rehacer todas las operaciones de escritura de las transacciones confirmadas en el orden en que
estn registradas en el log diario. Las transacciones no confirmadas deben ser canceladas y
reiniciadas de nuevo.

Un inconveniente de esta tcnica es que limita la ejecucin concurrente de transacciones pues todos los tems
permanecen bloqueados hasta que las transacciones llegan a sus puntos de confirmacin. El principal beneficio
es que nunca se necesita deshacer operaciones.

3.2.3. TCNICAS DE RECUPERACIN BASADAS EN MODIFICACIN INMEDIATA

En estas tcnicas cuando una transaccin ejecuta una modificacin, la base de datos puede ser actualizada
inmediatamente sin tener que esperar a que la transaccin llegue a su punto de confirmacin y, generalmente,
utilizan el protocolo de forzar la grabacin.

Como una transaccin puede fallar despus de que ha se hayan realizado algunas modificaciones en la base de
datos, los esquemas de recuperacin basados en la modificacin inmediata tienen que tener la capacidad de
retroceder las transacciones para deshacer las operaciones de escritura.

En un entorno monousuario, un posible algoritmo de recuperacin para el fallo de una transaccin sera:

Procedimiento RIU_S:
Recorriendo el fichero diario desde atrs hacia delante, hacer dos listas de transacciones:
confirmadas y no confirmadas.
Deshacer todas las operaciones de escritura de las transacciones no confirmadas usando el
procedimiento UNDO_W en orden inverso a como se registraron en el log diario.
Rehacer todas las operaciones de escritura de las transacciones confirmadas en el mismo orden en
que se registraron en el log diario, usando el procedimiento REDO_W.
Procedimiento UNDO_W: examinar la entrada en la bitcora [write_tem, T, X, valor_viejo, valor_nuevo] y
poner a X valor_viejo.

En un entorno multiusuario un algoritmo sera:

Procedimiento RIU_M:
Recorriendo el fichero diario desde detrs hacia adelante hasta la entrada ms reciente de punto de
control [checkpoint], hacer dos listas de transacciones: las confirmadas (tienen una entrada [commit,
T] en el diario) despus del ltimo [checkpoint]; y las no confirmadas (tienen una entrada
[start_transaction, T] pero no tienen confirmacin [commit, T]).
Hacer una lista de las transacciones que han ledo algn valor escrito por una operacin write_tem
de una transaccin no confirmada. Aplicar este paso recursivamente para obtener la lista de todas las
transacciones que deben ser retrocedidas en cascada.
Deshacer todas las operaciones de escritura de las transacciones no confirmadas y de las incluidas
en la lista de retroceso en cascada usando el procedimiento UNDO_W. Las operaciones debern ser
deshechas en orden inverso al de grabacin en el log diario.
Rehacer todas las operaciones de las transacciones confirmadas en el mismo orden en que se
registraron en el log diario.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 23 de 29
3.3. SEGURIDAD

La seguridad en los SGBD abarca varios temas:

Necesidad en las organizaciones de identificar mltiples niveles de seguridad y de clasificar los datos y
los usuarios segn estos niveles.
Cuestiones relacionadas con el sistema.
Cuestiones de poltica de la organizacin relacionadas con la informacin que no debe estar disponible
para el pblico.
Cuestiones legales relativas al derecho a tener acceso a cierta informacin.

Los tres aspectos fundamentales de la seguridad generalmente aceptados son:

Integridad. Permite asegurar que los datos son correctos.


Accesibilidad. La informacin debe estar disponible.
Confidencialidad. No desvelar a usuarios no autorizados los datos y mantener la privacidad de los
mismos (proteccin de datos personales).

Los dos primeros puntos ya han sido tratados, as que nos centraremos en la confidencialidad.

La mayora de los SGBD incluyen herramientas que limitan el acceso a los datos slo a las personas o los
procesos que estn autorizados a ello. Adems, restringen tambin el tipo de proceso que se puede realizar. Esto
se conoce como control de accesos.

Otro medio para mantener la confidencialidad de los datos que puede usarse en los SGBD es la criptografa. El
contenido de la base de datos se transforma en datos cifrados que no pueden ser interpretados por nadie que no
acceda con la clave de descifrado.

3.3.1. CONTROL DE ACCESOS

En primer lugar el sistema debe de identificar y autenticar al usuario (sujeto). La forma ms usual es por medio
del cdigo/contrasea, en la que el usuario da su cdigo de identificacin, el SGBD (u otro subsistema encargado
de la seguridad) le pide la contrasea y si ambos son vlidos le permite el acceso al sistema.

Una vez dentro del sistema hay que determinar a que objetos tiene acceso el sujeto y que operaciones puede
realizar sobre los mismos.

Existen dos tipos bsicos de control de acceso a los datos:

Control de acceso discrecional: se controla el acceso otorgando privilegios a los usuarios.


Control de acceso obligatorio: sirven para imponer seguridad de mltiples niveles clasificando a los datos
en niveles de confidencialidad y a los usuarios en niveles de autorizacin.

3.3.1.1. CONTROL DE ACCESO DISCRECIONAL

La estrategia de control de acceso discrecional se fundamenta en que los sujetos acceden a los objetos en base a
su identidad y a unas reglas de autorizacin. Las reglas indican para cada sujeto las acciones que puede realizar
sobre cada objeto del sistema.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 24 de 29
La forma ms comn de administrar las autorizaciones es aplicando el concepto de propiedad: cada objeto
pertenece a un propietario que es responsable de otorgar o revocar los derechos de acceso sobre los objetos de
su propiedad.

Para facilitar la gestin de la confidencialidad los SGBD suelen incorporar el concepto de rol o perfil. A los roles se
les asocia un conjunto de autorizaciones y a los usuarios se les hace miembros de los roles. De este modo los
usuarios consiguen permisos.

Se tienen diferentes clasificaciones de la autorizacin. Una primera distincin puede hacerse entre

Autorizacin positiva: la existencia de la regla de autorizacin indica que se puede realizar el acceso, su
no existencia lo prohbe.
Autorizacin negativa: es la denegacin explcita de una autorizacin, la existencia de la regla prohbe el
acceso.

Por otra parte podemos distinguir entre:

Autorizacin explcita: consiste en almacenar qu usuarios pueden acceder a qu objetos y con qu


privilegios. Para ello se suele utilizar una matriz de accesos.
Autorizacin implcita: se deduce automticamente por el sistema a partir del conjunto de autorizaciones
explcitas y de acuerdo a un conjunto de reglas.

Existen diversas polticas de propagacin de autorizaciones dependiendo, entre otras cosas, del tipo de sujeto u
objeto de que se trate. Por ejemplo, si se trata de una jerarqua de roles, al asignar una autorizacin positiva, sta
se propagara hacia todos los roles superiores en la jerarqua; y si la autorizacin es negativa, se propagara
hacia los roles inferiores en la jerarqua.

Finalmente distinguimos entre:

Autorizacin fuerte: no pueden ser invalidadas.


Autorizacin dbil: pueden ser invalidadas de acuerdo a unas reglas especficas.

3.3.1.2. CONTROL DE ACCESO OBLIGATORIO

En el control de acceso obligatorio los datos tienen un nivel de seguridad por s mismos, independientemente del
grado de seguridad que se de a los usuarios.

El control de acceso obligatorio se basa en el modelo de seguridad de Bell-LaPadula.

El modelo de Bell-LaPadula define un conjunto de niveles de seguridad de la forma [nivel de clasificacin,


conjunto de categoras], una relacin de orden entre los niveles y dos reglas. A cada objeto y a cada sujeto se le
asocia un nivel de seguridad.

El nivel de clasificacin tiene una estructura jerrquica. Generalmente es: alto secreto, secreto, confidencial, no
clasificado.

El conjunto de categoras es un conjunto de nombres no jerarquizado, por ejemplo: financiero, ventas, personal,
etc.

La relacin de orden es la siguiente: el nivel de seguridad A es superior o domina a B si y slo si el nivel de


clasificacin de A es mayor o igual que el de B, y el conjunto de categoras de B es un subconjunto del de A.

Las dos reglas son:

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 25 de 29
Regla de lectura no ascendente (no-read-up) o regla de seguridad simple: si el acceso es de lectura
entonces el nivel del sujeto que accede debe dominar al nivel del objeto accedido. Se encarga de
proteger a los datos contra accesos no autorizados.
Regla de escritura no descendente (no-write-down) o regla-* : si el acceso es de escritura entonces el
nivel del objeto debe ser igual al nivel del sujeto; si el acceso es para aadir, entonces el nivel del objeto
debe dominar al nivel del sujeto.

Finalmente hacer notar que en los SGBD que siguen la arquitectura en tres niveles de ANSI/X3/SPARC, y que
por tanto soportan los esquemas externos (vistas), estos esquemas externos (vistas) son un medio til de limitar
el acceso de los usuarios a determinados datos. La creacin de vistas diferentes para diferentes tipos de usuarios
consigue de forma automtica un alto grado de control de acceso.

4. ADMINISTRACIN DE DATOS
La informacin es uno de los activos ms valiosos de las organizaciones por lo que su administracin debe estar
a un nivel gerencial de responsabilidad. Es necesario contar con una persona que conozca la informacin y las
necesidades de la organizacin en este aspecto. Esta persona es el Administrador de Datos.

El alcance de la actividad de la Administracin de Datos es la organizacin completa, mientras que el alcance de


la Administracin de los Sistemas de Gestin de Bases de Datos queda restringido a un SGBD en particular.

El trabajo del Administrador de Datos se centra en dos aspectos:

decidir que datos deben almacenarse en la base de datos, es decir, identificar las entidades que
intervienen en la organizacin y la informacin que debe registrarse acerca de esas entidades
definir las polticas para mantener y gestionar los datos una vez que estn almacenados.

El Administrador de Datos es por lo general, un gerente, no un tcnico. El tcnico responsable de implantar las
decisiones del Administrador de Datos es el Administrador de la Base de Datos. Entre sus funciones, destacan:

Diseo conceptual de la base datos.


Coordinacin de los requerimientos de los usuarios y la integracin de estos requerimientos en el entorno
de base de datos.
Definicin de las polticas de control de privacidad y de seguridad de datos.
Definicin de las polticas de control de integridad de datos.
Desarrollo del diccionario de datos.

El Administrador de Datos es fundamental en las etapas iniciales del ciclo de vida de la base de datos:

Planificacin de la base de datos.


Estudio de viabilidad.
Definicin de requisitos.
Diseo conceptual.

Durante la planificacin de la base de datos se recoge informacin para determinar:

Las aplicaciones que estn en uso y las funciones que realizan.


Los datos asociados con cada una de estas aplicaciones.
Las nuevas aplicaciones que estn en desarrollo o planificndose, y los datos asociados a ellas.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 26 de 29
Con esta informacin pueden identificarse las relaciones entre las aplicaciones actuales y los usos que estas
aplicaciones hacen de los datos. Adems ayuda a identificar futuros requisitos del sistema.

El estudio de viabilidad comprende los tres aspectos siguientes:

Viabilidad tecnolgica. Determina si la tecnologa adecuada para dar soporte al desarrollo de la base de
datos est disponible. Hay que analizar si las capacidades y recursos necesarios existen ya en la
organizacin o hay que adquirirlos.
Viabilidad operacional. Incluye el anlisis de los conocimientos y los requisitos laborales necesarios para
desarrollar el sistema.
Viabilidad econmica. Se trata de cuantificar los costes y los beneficios del sistema.

En la etapa de definicin de requisitos se determina el alcance de la base datos, se identifican los requerimientos
de informacin de cada rea funcional y administrativa, y se determinan los requerimientos software y hardware.

En la etapa de diseo conceptual se crea el esquema conceptual de la base de datos y se desarrollan las
especificaciones hasta el punto en que pueda empezar la implementacin.

La poltica de seguridad de los datos viene determinada por el nivel de seguridad que se quiera establecer para
los datos y debe basarse principalmente en los datos sensibles.

5. CONCLUSIN
La administracin efectiva del sistema de informacin de una organizacin requiere un establecimiento de
polticas y procedimientos generales para el sistema de informacin y una puesta en prctica de dichas polticas y
procedimientos. Para ello en algunas organizaciones se hace una distincin entre la Administracin de Datos y la
Administracin de Sistemas de Gestin de Base de Datos. De la primera se encarga el Administrador de Datos y
del la segunda el Administrador del Sistema de Gestin de Base de datos.

Los objetivos fundamentales de la Administracin del Sistema de Gestin de Base de Datos son mantener la
integridad, la disponibilidad y la seguridad de la base de datos.

La integridad de los datos, que se refiere a su fiabilidad y consistencia, se mantiene fundamentalmente aplicando
el concepto de transaccin atmica, segn el cual o se completa todo el procesamiento de la transaccin o no se
realiza procesamiento alguno, y los controles de concurrencia.

Para mantener la disponibilidad de los datos se deben aplicar buenos procedimientos de respaldo y recuperacin
que permitan garantizar que ante cualquier tipo de fallo, ya sea lgico o fsico, se pueden recuperar los datos y
dejar a la base de datos en el mismo estado consistente que tena antes de producirse.

Finalmente, para mantener la seguridad se aplican mtodos que limiten el acceso a los datos slo a los usuarios y
procedimientos que estn autorizados para ello. Adems se puede aplicar la criptografa para mantener la
confidencialidad de informaciones especialmente sensibles.

6. BIBLIOGRAFA

Gary W. Hansen, James V. Hansen: Diseo y Administracin de Bases de Datos.


Adoracin de Miguel, Mario Piattini: Fundamentos y modelos de Bases de Datos.
Oracle 8i Backup and Recovery Guide.
Guas Tcnicas Aplicables a la Contratacin de Bienes y Servicios de Tecnologas de la Informacin y las
comunicaciones, CSI MAP.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 27 de 29
7. ESQUEMA RESUMEN
En algunas organizaciones se ha dividido la administracin de los recursos del sistema de informacin en dos
partes: Administracin de Datos y Administracin de Sistemas de Gestin de Base de Datos.

El Administrador de Datos se encarga del establecimiento de las polticas y de los procedimientos generales para
el sistema de informacin de la organizacin. El alcance de su actividad es la organizacin completa.

El Administrador del SGBD se encarga de garantizar que la informacin est disponible para los usuarios y las
aplicaciones de una forma precisa y consistente, y en el momento en que sea requerida. El alcance de su
actividad queda restringido a un SGBD en particular.

Se pueden clasificar las funciones del Administrador del SGBD en tres categoras:

Funciones de gestin.
Seleccin de un SGBD.
Diseo fsico e Implementacin de la base de datos.
Comunicacin con los usuarios
Hacer de enlace con la gerencia de la organizacin.
Mantenimiento del diccionario de datos.
Mantenimiento del software de la base de datos y de las herramientas relacionadas.
Funciones de seguridad.
Concesiones de autorizacin para el acceso a los datos.
Definicin de los procedimientos de respaldo y recuperacin
Funciones diarias.
Monitorizacin de la capacidad.
Monitorizacin de la actividad y del rendimiento.
Modificaciones en la base de datos

Por respaldo y recuperacin se entienden las diversas estrategias y operaciones que intervienen en la proteccin
de la base de datos frente a la prdida de datos, y la reconstruccin de esos datos en caso de que se produzca la
prdida.

Un respaldo (backup) es una copia de los datos por motivos de seguridad. Es una salvaguarda frente a errores de
las aplicaciones y prdidas inesperadas de datos

Los backups se pueden clasificar en:

Fsicos o lgicos.
Incrementales o totales.
En fro o en caliente.

Los principios bsicos para desarrollar una estrategia efectiva de respaldo y recuperacin son:

Realizar copias frecuentes de los ficheros de datos y de los ficheros de control de la base de datos.
Mantener varias copias idnticas de los ficheros diarios en varios discos.
Mantener varias copias concurrentes de los ficheros de control de la base de datos.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 28 de 29
La estrategia de recuperacin depende del tipo de fallo pero los pasos bsicos son:

Determinar los ficheros que hay que recuperar.


Determinar el tipo de recuperacin necesaria: completa o incompleta.
Restaurar los ficheros necesarios.
Actualizar los ficheros restaurados con las entradas del fichero diario.

Las tres responsabilidades bsicas de la Administracin del Sistema de Gestin de Bases de Datos son:

Mantener la integridad de los datos: hay que asegurar que las operaciones ejecutadas por los usuarios o
aplicaciones son correctas y mantienen la consistencia de los datos.
Mantener la disponibilidad de los datos. se tienen que proporcionar medios para el restablecimiento de la
base de datos a un estado correcto tras una corrupcin de la misma por desperfectos del sistema, ya
sean de hardware o de software.
Mantener la seguridad: se debe limitar la ejecucin nicamente a las operaciones que estn permitidas y
proteger la base de datos de usos malintencionados o no autorizados (seguridad de datos).

Para mantener la integridad el SGBD debe poseer controles de integridad semntica y aplicar tcnicas de control
de concurrencia.

Entre las principales tcnicas de control de concurrencia estn:

Bloqueos
Marcas de tiempo
Otras tcnicas como las tcnicas optimistas, tcnicas de bloqueo altruista tcnicas basadas en
semntica.

Para mantener la disponibilidad de los datos los SGBD proporcionan mecanismos que permiten recuperar la base
de datos cuando ocurran fallos lgicos o fsicos que destruyan los datos. Para esto el SGBD se apoya en dos
elementos bsicos: las transacciones y el fichero diario de operaciones o fichero de bitcora.

Para la recuperacin de fallos de transacciones hay dos grupos de tcnicas principales:

Las tcnicas de modificacin diferida: la base de datos no se actualiza hasta que una transaccin llega a
su estado confirmado.
Las tcnicas de modificacin inmediata: algunas operaciones de una transaccin pueden modificar la
base de datos antes de que llegue a su estado confirmado, previo registro de dichas modificaciones en el
log diario.

Para mantener la seguridad un punto clave es el control de acceso al SGBD.

Existen dos tipos bsicos de control de acceso a los datos:

Control de acceso discrecional: se controla el acceso otorgando privilegios a los usuarios.


Control de acceso obligatorio: sirven para imponer seguridad de mltiples niveles clasificando a los datos
en niveles de confidencialidad y a los usuarios en niveles de autorizacin.

TEMARIO-TICC-mar04 T18
Actualizado en marzo de 2004 Pgina 29 de 29

You might also like