UNIDAD III.

- ESTRUCTURA
DISTRIBUIDA.

DE

UNA

BASE

DE

DATOS

3.1.- PROPIEDADES ACID.

3.1.1.- Propiedades de las transacciones.
Para afirmar que las transacciones son unidades de procesamiento consistente y confiables. Las
propiedades de una transaccin son las siguientes:
- Atomicidad: Se refiere al hecho de que una transaccin se trata como una unidad de operacin.
Por lo tanto, o todas las acciones de la transaccin se realizan o ninguna de ellas se lleva a cabo.
La atomicidad requiere que si una transaccin se interrumpe por una falla, sus resultados parciales
deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia
de abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se le llama
recuperacin de transacciones. La actividad de asegurar la atomicidad en presencia de cadas del
sistema se le llama recuperacin de cadas.
- Consistencia: La consistencia de una transaccin es simplemente su correctitud. En otras
palabras, una transaccin es un programa correcto que lleva a la BD de un estado consistente a
otro con la misma caracterstica. Debido a esto, las transacciones no violan las restricciones de
integridad de una base de datos.
- Aislamiento: Es la propiedad de las transacciones que asegura cuando la transaccin hace
commit, sus resultados son permanentes y no pueden ser borrados de la BD. Por lo tanto, los DBMS
aseguran que los resultados de una transaccin sobrevivirn a fallas del sistema. Esta propiedad
motiva el aspecto de recuperacin de BD, el cual trata sobre como recuperar la BD a un estado
consistente en donde todas las acciones que han hecho un commit queden reflejadas.
En resumen, las transacciones proporcionan una ejecucin atmica y confiable en presencia de
fallas, una ejecucin correcta en presencia de accesos de usuario mltiples y un manejo correcto de
rplicas (en el caso de que se soporten).

3.2.- MODELO DE TRANSACCIONES.

3.2.1.- Manejo de transacciones distribuidas.
Las primitivas bsicas de acceso que se han considerado son las consultas (queries), no se ha
discutido qu pasa cuando, por ejemplo, dos consultas tratan de actualizar el mismo elemento, de
datos, o si ocurre una falla del sistema durante la ejecucin de una consulta, de lectura o
actualizacin, a veces no se puede simplemente reactivar la ejecucin de una consulta, puesto que
algunos datos pueden haber sido modificados ante la falla. El no tomar en cuenta esos factores
puede conducir a que la informacin en la base de datos contenga datos incorrectos.
El concepto fundamental aqu es la nocin de ejecucin consistente o procesamiento confiable
asociada con el concepto de consulta. El concepto de una transaccin es usado dentro del dominio
de la BD como una unidad bsica de cmputo consistente y confiable.
3.2.2.- Definicin de una transaccin.
Es una coleccin de acciones que hacen transformaciones consistentes de los estados de un sistema
preservando la consistencia del sistema. Una base de datos est en un estado consistente si

obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren
debido a actualizaciones, inserciones y supresiones de informacin. Por supuesto, se requiere
asegurar que la BD nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecucin
de una transaccin, la base de datos puede estar temporalmente en un estado inconsistente. El
punto importante aqu es asegurar que la base de datos regresa a un estado consistente al fin de la
ejecucin de una transaccin.
Lo que se persigue en el manejo de transacciones es por un lado tener una transparencia adecuada
de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada
en el manejo de las fallas que se puedan presentar en una BD.

Figura de un modelo de transaccin.

3.2.3.- Condiciones de terminacin de una transaccin.

Una transaccin siempre termina, aun en la presencia de fallas. Si una transaccin termina de
manera exitosa se dice que la transaccin hace un commit. Si la transaccin se detiene sin terminar
su tarea, se dice que la transaccin aborta. Cuando la transaccin es abortada, su ejecucin es
detenida y todas sus acciones ejecutadas hasta el momento son deshechas (undone) regresando a
la BD al estado antes de su ejecucin. A esta operacin tambin se le conoce como rollback.

3.3.- MONITORES DE PROCESAMIENTO DE TRANSACCIONES.

El monitor de ejecucin distribuida consiste en dos mdulos:
- El administrador de transacciones (MT): Es el responsable de coordinar la ejecucin de la BD
de las operaciones que realiza en una aplicacin.
- El despachador (SC): Es responsable de implementar un algoritmo especfico de control de
concurrencia para sincronizar los accesos a la BD.
Un componente adicional que participa en el manejo de las transacciones distribuidas es el
administrador de recuperacin local cuya funcin es implementar procedimientos locales que
permitan a una BD local cuya funcin es implementar procedimientos locales que le permitan a esta
recuperarse a un estado consistente despus de una falla.

Figura del modelo administrador de transacciones.

Los administradores de transacciones implementan una interfaz para los programas de aplicacin
que consiste de los comandos:
1.- Begin_transaction.
2.- Read.
3.- Write.
4.- Commit.
5.- Abort.

Ejecucin centralizada de transacciones.

Arquitectura requerida para la ejecucin centralizada de transacciones, las modificaciones

requeridas en la arquitectura para una ejecucin distribuida se pueden apreciar en la siguiente figura,
se presentan los protocolos de comunicacin necesarios para el manejo de transacciones
distribuidas.

Ejecucin distribuida de transacciones.

3.4.- ESTNDARES DE ADMINISTRACIN DE TRANSACCIONES.

Hay dos aspectos principales en la administracin de transacciones:
- El control de recuperacin, para asegurarse de que una transaccin dada sea atmica (todo o
nada) en el ambiente distribuido, el sistema debe por lo tanto asegurarse de que el conjunto de
agentes para esa transaccin sea confirmado o deshecho al unsono. Este efecto puede lograrse
por medio del protocolo de confirmacin de dos fases.
- El control de concurrencia, en la mayora de los sistemas distribuidos, est basado generalmente
en el bloqueo.
Ambos adquieren un tratamiento amplio en el ambiente distribuido, para explicar ese tratamiento
amplio se debe incluir un nuevo trmino, el agente. En los sistemas distribuidos, una sola transaccin
puede involucrar la ejecucin de cdigo en muchos sitios; en particular; puede involucrar
actualizaciones en muchos sitios. Por lo tanto, decimos que cada transaccin consiste en varios
agentes, donde un agente es el proceso realizado en nombre de una transaccin dada en un sitio
dado. Y el sistema necesita saber cundo dos agentes son parte de la misma transaccin; un ejemplo
seria; no permitir que dos agentes que son parte de la misma transaccin caigan en el bloqueo mortal
entre ellos.

3.4.1.- Commit.
Como con los protocolos de recuperacin local, las versiones distribuidas ayudan a mantener la
atomicidad y durabilidad de las transacciones. La ejecucin de los comandos begin_transaction,
read y write no provoca ningn cambio significativo. Sin embargo, la ejecucin de las operaciones

commit, abort y recover requieren del desarrollo de un protocolo especial para cada una de ellas
en el cual participan todos los nodos de la red que intervienen en una transaccin. De manera breve,
a continuacin se presentan algunos problemas que aparecen en sistemas distribuidos y que no se
presentan en sistemas centralizados.
Idealmente, la ocurrencia de una falla, cmo terminar una transaccin que se estaba ejecutando al
momento de la falla, idealmente un nodo con falla debera poder terminar una transaccin sin tener
que consultar a los otros nodos. Esta es una propiedad de independencia del nodo con falla, respecto
a los nodos con falla. Una recuperacin independiente supone que existe una estrategia nobloqueante en el manejo de fallas.
Para facilitar la descripcin de los protocolos de confiabilidad distribuida se supondr que en el nodo
que se origina una transaccin hay un proceso, llamado el coordinador, que ejecuta las operaciones
de la transaccin. El coordinador se comunica con procesos participantes en los otros nodos los
cuales lo ayudan en las operaciones de transaccin.

3.4.2.- Commit de dos fases.

Este protocolo es muy simple y elegante asegura la atomicidad de las transacciones distribuidas.
Extiende los efectos de una operacin local de commit a transacciones distribuidas poniendo de
acuerdo a todos los nodos involucrados en la ejecucin de una transaccin antes que los cambios
hechos sean permanentes.
Fase 1: El coordinador hace que todos los participantes estn listos para escribir los resultados en
la base de datos.
Fase 2: Todos escriben los resultados en la base de datos.
La terminacin de una transaccin se hace mediante la regla del compromiso global:
Fase 1: El coordinador aborta una transaccin si y solamente si al menos un participante vota por
que se aborte.
Fase 2: El coordinador hace un commit de la transaccin si y solo si todos los participantes votan
por que se haga el commit.

Acciones del compromiso en dos fallas.

Variante del compromiso en dos fases, estructura centralizada.

Estructura lineal de comunicaciones para el compromiso en dos fases.

Estructura distribuida de comunicaciones para el compromiso de dos fases.