transacciones Base de datos con SQL SERVER

Transacciones, Recuperación y
Control de Concurrencia
Diseño de Bases de Datos Relacionales
Curso 2011/2012
Sergio Ilarri
[email protected]

Transacciones (I) 
Transacción

Secuencia de operaciones que deben ejecutarse
de forma atómica (unidad lógica)

La operación más simple con verificación de
consistencia

Ejemplo motivador: transferencia bancaria

Deben definirse las transacciones necesarias
de forma adecuada (tan pequeñas como sea
posible pero asegurando la integridad)

Transacciones (II)

Ciclo de vida de una transacción

Inicio

Lecturas/escrituras de elementos de la BD

Final (pueden necesitarse verificaciones)

Confirmación (COMMIT)

Anulación (ROLLBACK)

Control de concurrencia

Sistema multi-usuario

Fallo de una transacción recuperación

Transacciones (II)

Propiedades ACID:

Atomicidad(
atomicity
) método de recuperación

Se ejecuta todo (
commit
) o nada (
rollback
)

Consistencia(
consistency
) programador y/o SGBD
(restricciones de integridad)

Se pasa de un estado consistente a otro

aIslamiento(
isolation
)método de control de concurrencia
y a veces también el programador (ej., bloqueo en 2 fases)

No interfiere con otras, no lee resu ltados intermedios de transacciones
no terminadas

Durabilidad(
durability
) método de recuperación

En caso de éxito (
commit
), los cambios son persistentes, incluso si hay
fallos de otras


La ejecución concurrente de transacciones de forma
incontrolada puede dar lugar a problemas:

Problema de la actualización perdida

Problema de la lectura sucia

También: problema de la actualización temporal, problema de la
lectura de datos no confirmados

Problema del resumen incorrecto (resultados incoherentes)

Problema de la lectura no repetible

También: problema de valores contradictorios de los datos

Para evitarlos, el control de la concurrencia es
necesario
Problemas de concurrencia (I)


Problema de la actualización perdida

T1 lee las existencias disponibles de un producto (E)

T2 también lee las existencias disponibles (E)

T1 incrementa dichas existencias en 100 unidades (E+100)

T2 también incrementa dichas existencias en 100 unidades
(E+100)

El resultado final (E+100) sería incorrecto (debería ser
E+200), ya que se ha perdido la actualización de T1

Ambas transacciones leen el valor antes de que lo cambie
la otra…
Problemas de concurrencia (II)


Problema de la lectura sucia

T1 lee las existencias disp onibles de un producto (E)

T1 incrementa dichas existencias en 100 unidades (E+100)

T2 lee las existencias disp onibles de dicho producto (E+100)

T1 aborta, debido a un error, deshaciéndose sus cambios
(las existencias pasan de nuevo a valer E)

T2 incrementa las existencias en 100 unidades (E+200)

El resultado final (E+200)sería incorrecto (debería ser E+100)
ya que T1 ha abortado su actualización

Una transacción actualiza un ítem que luego lee otra. Después
falla (por tanto, la segunda l ee un dato que “nunca existió”)
Problemas de concurrencia (III)

Problemas de concurrencia (IV)

Problema del resumen incorrecto

T1: cálculo del saldo total de todas las cuentas de un banco

T2: transferencia de una cuenta bancaria a otra (c1 c2)

T2 sustrae X del saldo de c1

T1 lee el saldo de c1

T1 lee el saldo de c2

T2 añade X al saldo de c2

El saldo total calculado por T1 serámenor que el real por X

Una transacción calcula un agregado de registros mientras
otra actualiza algunos de esos registros algunos valores
se consideran antes de la actualización y otros después

Problemas de concurrencia (V)

Problema de la lectura no repetible

T1 consulta asientos disponibles en varios vuelos:

Hay N asientos disponibles en IB245 y N’ en FJ143

T2 reserva X asientos en el vuelo IB245

T1 decide finalmente reservar en el vuelo IB245

Al volver a leer los asientos disponibles en dicho vuelo, se
obtiene N-X (no coincide con los de antes)

Incluso podría no haber ya asientos disponibles…

Una transacción lee dos valores diferentes para un ítem, debido
a una modificación intermedia por parte de otra

Problema de la lectura fantasma (tuplasque no
existían antes)


Dadas las transacciones T1, T2, ... Tn,

T1 operaciones O
11
,O
12
,..O
1 m1

T2 operaciones O
21
,O
22
,..O
2 m2

…

Tnoperaciones O
n1
, O
n2
..O
nmn

Plan de ejecución:

Ej.: O
11
, O
21
, O
n1
, O
n2
, O
12
, O
22
, …, O
1 m1
, O
2 m2
, …, O
nmn

Una intercalación de todas las operaciones O
ij
donde para todo
i, O
i1
se ejecuta antes que O
i2
... O
imi

Plan serializableresultado igual al producido por
alguno de los posibles planes seriales

Ej.: operaciones de T2, de T1, de Tn, ...., de T3
Planes serializables

Serializabilidad

Utilizada como criterio de corrección

Determinar si un determinado plan es
serializablees un problema NP-completo

Idea: imponer restricciones a la libre
intercalación de operaciones de
transacciones para garantizar que el plan
resultante es serializable

Técnicas de control de
concurrencia (I)

Objetivo: evitar interferencias entre
transacciones aislamiento

Solución trivial: cada transacción se ejecuta
en exclusión mutua

Muy restrictivo

Evita la concurrencia y las BD están pensadas
para acceso multi-usuario (múltiples aplicaciones)

En lugar de eso, intercalar acciones para que el
resultado sea como en exclusión mutua…

Aquí es donde el concepto de serializabilidad juega un
papel fundamental


Principales técnicas utilizadas:

Técnicas pesimistas

Técnicas optimistas

Técnicas de control de concurrencia
multi-versión
Técnicas de control de
concurrencia (II)

Técnicas pesimistas

Técnicas pesimistas:

Técnicas de bloqueo (
locks
)

Técnicas de marcas de tiempo (
time-stamping
)

Se impiden ciertas operaciones si son
sospechosas de producir planes no serializables.
Control de las transacciones durante
la ejecución (no sólo al final)

Utilizan protocolos (reglas) para garantizar la
serializabilidadde los planes de ejecución
(
schedules
)

Técnicas de bloqueo (I)

Utilizadas en la mayoría de los SGBD comerciales

Idea: bloquear ítems de datos para evitar su acceso
concurrente desde múltiples transacciones
(sincronizar el acceso)

Cerrojo (
lock
):

Variable asociada a un ítem de datos, que describe su
estado con respecto a las operaciones permitidas

Riesgos: bloqueo mortal (
deadlock
), inanición (
starvation
)


Cerrojos binarios:

0 ó1 (accesible o no accesible)

Operaciones
lock()
y
unlock()
indivisibles
(exclusión mutua, región crítica, cola de espera)

Simples pero restrictivos no usados

Cerrojos multi-modo (3 posibles estados):

Sharedlocks
(S locks, readlocks)

Exclusive locks
(X locks, writelocks)

Operaciones read_lock(), write_lock(), unlock()indivisibles

Permiten accesos simultáneos en modo lectura Técnicas de bloqueo (II)


Granularidad de los ítems de datos X:

Un atributo

Una tupla

Una tabla

Un bloque de disco

Un fichero entero

La BD entera

…

Sobrecarga de adquisición y gestión de cerrojos vs.
menor nivel de concurrencia si la granularidad de los
ítems de datos es mayor
Operaciones básicas de acceso a la BD:
read(X), write(X)
Técnicas de bloqueo (III)


Los cerrojos no garantizan la serializabilidad
por sísolos

Hace falta un protocolo adicional referente al
posicionamiento de las operaciones de bloqueo y
desbloqueo dentro de una transacción

Protocolo más utilizado: protocolo de bloqueo en
2 fases

¡No confundir con el protocolo de
commit
en 2 fases!
(bases de datos distribuidas)
Técnicas de bloqueo (IV)

Protocolo de
bloqueo en 2 fases
(2PL)

Idea: no hacer ningún
lock()
después de algún
unlock()

2 fases:

Fase de crecimiento/expansión: solicitud de
locks

Fase de devolución: realización de
unlocks

Garantiza la serializabilidad evita la necesidad de
comprobarla

Pero puede limitar la concurrencia (restrictivo) impide algunos
planes serializables

Variante más popular: 2PL estricto (planes estrictos)

No se libera ningún cerrojo exclusivo (de escritura)hasta que se finaliza

ninguna transacción podrá leer o escribir ese ítem evita
rollback
en cascada

permite una fácil recuperación (resta urar valores viejos antes del write)

Bloqueos mortales (I)

Prevención

Cada transacción obtiene todos los cerrojos al principio:
o todos o ninguno (2PL conservador):
problema de
livelock

Los elementos están ordenados y los cerrojos hay que
obtenerlos en orden (responsabilidad del programador)

Ordenación de transacciones por marcas de tiempo

Wait-die
si TS(Ti) < TS(Tj), entonces Ti puede esperar; de otro
modo, Ti muere. Transacciones+ viejasesperanporotras+ jóvenes .

Wound-wait
si TS(Ti) < TS(Tj), entonces Ti hiere a Tj (que
aborta); de otro modo, Ti puede esperar.
Transacciones+ jóvenesesperanporotras+ viejas .

Las transacciones se reinician con la misma marca de tiempo

Otras: abortarsino esposibleobtenerun cerrojo, etc. Ciclos no
posibles


Detección y recuperación

Grafo de esperas si hay un ciclo abortar a una

Problema de
livelock

¿Cuándo se comprueba? #transacciones, tiempo de
espera por cerrojos, periódicamente, etc.

Selección de la víctima

La transacción que lleva menos tiempo ejecutándose

La transacción que está bloqueando un mayor
número de transacciones

La transacción que menos veces se ha abortado

…

Uso de
timeouts
Bloqueos mortales (II)

Técnicas de marcas de tiempo (I)

Marca de tiempo (
timestamp
)

Identificador único de cada transacción

Generado automáticamente por el sistema

A cada elemento X de la BD se le asigna también
la marca de tiempo de la transacción más nueva
(mayor marca de tiempo) que lo ha leído y escrito:

TS_lect(X) y TS_escr(X)

Uso del orden de las marcas de tiempo para
garantizar la serializabilidad

Pero puede haber planes serializablesque los impida…


Si una transacción T quiere escribir en X

Si TS_lect(X) > TS(T) entonces abortar

Una transacción más nueva ya ha leído X antes de que T
tuviera la oportunidad de modificarlo

Si TS_escr(X) > TS(T) entonces no escribir y
seguir (regla de escritura de Thomas)

Una transacción más nueva ya ha escrito el valor de X,
por lo que se puede ignorar la escritura por parte de T

Problema potencial: la transacción más nueva puede
abortar…seguir la pista a las escrituras tentativas y a
sus valores previos

En otro caso escribir y TS_escr(X):=TS(T)
Técnicas de marcas de tiempo (II)


Si una transacción T quiere leer de X

Si TS_escr(X) > TS(T) entonces abortar

Una transacción más nueva escribióX antes de
que T tuviera la oportunidad de leer su valor

Si TS_escr(X) <= TS(T) entonces leer de X
y TS_lect(X):=máximo(TS(T), TS_lect(X))
Técnicas de marcas de tiempo (III)

Técnicas optimistas (I)

También llamadas técnicas de validación o técnicas
de certificación

No imponen restricciones, no requieren bloqueo, se
comprueban posibles interferencias al final

3 fases:

Fase de lectura

Fase de validación (¿ha habido algún conflicto? ¿alguna
actualización violaría la serializabilidad?)

Fase de escritura (si se valida satisfactoriamente; de otro
modo, abortar, dado que puede haber habido interferencias)

Las actualizaciones se realizan inicialmente sobre
copias locales (≈versiones)


Adecuadas cuando hay pocas interferencias entre
transacciones (optimismo); si no, coste de reiniciar

Vamos a ver una técnica concreta

Esta técnica utiliza:

Marcas de tiempo de las transacciones, instantes de inicio y fin
de algunas fases

Conjuntos de escritura y lectura de las transacciones

En la fase de validación de una transacción, se
comprueba que esta no interfiere con ninguna otra
transacción confirmada ni con otras actualmente en su
fase de validaciónTécnicas optimistas (II)


Fase de validación para Ti

Antes de hacer
commit
se comprueba si hay interferencias

Para cada Tjconfirmada o actualmente en su fase de
validación, Ti y Tjno tienen interferencias si:
1.
Tj ha terminado su fase de escritura antes de que Ti haya
comenzado su fase de lectura
2.
Ti comienza su fase de escritura después de que Tj complete su
fase de escritura y Ti no lee elementos escritos por Tj
3.
No hay elementos en común entre los que lee y escribe Ti con los
que escribe Tj, y Tj ha terminado su fase de lectura antes de que
Ti termine su fase de lectura
Si, para cada Tj, se cumple cualquiera de es tas 3 condiciones no hay interferencia. Se
comprueban en orden (dado que están ordenadas por complejidad de su evaluación)
Técnicas optimistas (III)

Fase de validación: 1.
Tj ha terminado su fase de escritura antes de que Ti haya
comenzado su fase de lectura
Ti
Lectura Escritura
Tj
Lectura Escritura
En este caso tenemos una ejecución en serie
Técnicas optimistas (IV)

Fase de validación: 2.
Ti comienza su fase de escritura después de que Tj complete su
fase de escritura y Ti no lee elementos escritos por Tj
Ti
Lectura Escritura
Tj
Lectura Escritura
-Las escrituras de Tj no afectan a las lecturas de Ti (por la condición en azul).
-Tj termina de escribir antes de que empiece Ti no puede sobreescribir cambios de Ti
-Ti no puede afectar a la fase de lectura de Tj
read-set(Ti) write-set(Tj) = Técnicas optimistas (V)

Fase de validación: 3.
No hay elementos en común entre los que lee y escribe Ti con
los que escribe Tj, y Tj ha terminad o su fase de lectura antes de
que Ti termine su fase de lectura
Ti
Lectura Escritura
Tj
Lectura Escritura
working-set(Ti) = read-set(Ti) write-set(Ti)
working-set(Ti) write-set(Tj) = 
-Lo que escribe Tj no influye en lo que pued a leer Ti (debido a la condición en azul)
-Todas las lecturas de Tj se hacen antes de que Ti empiece a escribir
Técnicas optimistas (VI)

Técnicas de control de
concurrencia multi-versión (I)

Utilizan múltiples versiones de los ítems de datos

Objetivo: permitir lecturas que en otras circunstancias
podrían lleva a la transacción que lee a abortar

Marca de tiempo para escrituras:

Se genera una nueva versión cada vez que se escribe un objeto

Su marca de tiempo de escritura es la marca de tiempo de la
transacción correspondiente

Cada transacción T lee la versión de un ítem que es apropiada
para ella, que es la versión escr ita inmediatamente antes de la
ejecución teórica de T (marca temporal de T)


Marca de tiempo para lecturas:

Cada versión tiene una marca de tiempo que indica la marca
de tiempo de la última transacción que la leyó (la marca de
tiempo de transacción más alta que la leyó)

Si una transacción intenta realiz ar una escritura sobre un ítem
pero la marca de tiempo de dicha escritura sería inferior a la
marca de tiempo de lectura de la versión previa, entonces se
aborta la escritura

Si una versión tiene un tiempo de escritura tal que no existe
ninguna transacción activa con marca temporal menor,
entonces todas las versiones anteriores a dicha versión
pueden eliminarse
Técnicas de control de
concurrencia multi-versión (II)

Recuperación (I)

Tipos de fallos:

Fallo informático (
system crash
): hardware, software, red

Error del sistema o transacción: desbordamiento de un entero,
división por 0, errores de parámetros, errores de programación, etc.

Errores locales o condiciones de excepción detectadas por una
transacción: datos que no se encuentran, saldo insuficiente, etc.

Control de concurrencia: transacciones abortadas para garantizar la
serializabilidad o para romper un abrazo mortal

Fallo del disco (lectura/escritura)

Problemas físicos y catástrofes: fu ego, inundación, robo, sabotaje,
fallos humanos (sobreescritura de datos incorrecta, borrado de
datos, …), etc.


Fichero de
log
(bitácora) + backups

Registros de
log
(caso general,
undo/redo logging
)

<comienza-transacción, numTrans>

<escritura, numTrans, idDato, valViejo, valNuevo>

<lectura, numTrans, idDato, val>

<termina_transacción_con_éxito, numTrans>

<punto_comprobación, numTrans, numPuntoComprob>

Puntos de comprobación / salvaguarda (
checkpoints
)

Se escribe en el fichero de
log
antes que en la BD

Debe almacenarse de forma persistente
Salvo si el protocolo evita
rollbacks en cascada
Recuperación (II)


Tipos de registros:

Undologging

<escritura, numTrans, idDato, valViejo>

Sólo deshace transacciones incompletas

Para hacer
commit
, se requiere antes escribir todos los datos
cambiados en la BD en disco

Redologging

<escritura, numTrans, idDato, valNuevo>

Sólo rehace cambios realizados por transacciones confirmadas

Es preciso actualizar el fichero de
log
incluyendo el
commit
,
antes de modificar los datos en disco

Las transacciones incompletas se pueden tratar durante la
recuperación como si nunca hubieran existido
Recuperación (III)


Tipos de registros (II):

Undo/redo logging

<escritura, numTrans, idDato, valViejo, valNuevo>

Más flexibilidad en cuanto al orden relativo con el que los
registros de commit de
log
y los cambios en la BD se
escriben en el disco

Antes de cambiar un dato en disco hay que escribir el
cambio en el
log
en disco

Rehace las transacciones confirmadas (empezando por
las más antiguas) y deshace las transacciones
incompletas (empezando por las más nuevas)
Recuperación (IV)


¿Puedo eliminar todos los registros del log
para transacciones ya confirmadas?

No, podría haber un fallo catastrófico de
disco…recurrir a una copia de
seguridad +
log
(
logonline
,
log
archivado)
Recuperación (V)

Concurrencia en Oracle (I)
validación de transacciones pendientes:
COMMIT;
deshacer transacciones pendientes:
ROLLBACK;
establecer un pto. de “salvaguarda”:
SAVEPOINT nombrePuntoSalvaguarda;
ROLLBACK TO nombrePuntoSalvaguarda;
bloquear registros recuperados:
CURSOR nombreCursor IS
sentenciaSelect
FOR UPDATE [of listaColumnas] [NOWAIT];
SELECT listaColumnas
FROM tablas
FOR UPDATE [OF atributosTablas];
bloquear una tabla:
LOCK TABLE tabla IN modoBloqueo MODE;
ROW SHARE, ROW EXCLUSIVE,
SHARE UPDATE, SHARE,
SHARE ROW EXCLUSIVE,
EXCLUSIVE
SET AUTOCOMMIT ON; SET AUTOCOMMIT OFF;
La desconexión finaliza una transacción, no hay
un comenzar_transacción() explícito ROLLBACK y
COMMIT implícitos

SET TRANSACTION READ ONLY SET TRANSACTION READ WRITE
prohibición de modificaciones:
situación por defecto:
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
Nivel de aislamiento:
SET TRANSACTION ISOLATION LEVEL READ COMMIT;
Niveles de aislamiento: READ_COMMITTED, SERIALIZED
Modo de
acceso
•No hay unlocksexplícitos en Oracle implícitos al confirmar o abortar una transacción
Concurrencia en Oracle (II)

Comprobación diferida de
restricciones (I)
CREATE TABLE Gallina(
idGallina
INT PRIMARY KEY
,
idHuevo
INT REFERENCES
Huevo(idHuevo));
CREATE TABLE Huevo(
idHuevo
INT PRIMARY KEY,
idGallina
INT REFERENCES Gallina(idGallina)
);

CREATE TABLE Gallina(idGallina INT PRIMARY KEY, idHuevo INT);
CREATE TABLE Huevo(idHuevo INT PRIMARY KEY, idGallina INT);
ALTER TABLE Gallina ADD CONSTRAINT fkRefHuevo
FOREIGN KEY(idHuevo) REFERENCES Huevo(idHuevo)
INITIALLY DEFERRED DEFERRABLE;
ALTER TABLE Huevo ADD CONSTRAINT fkRefGallina
FOREIGN KEY(idGallina) REFERENCES Gallina(idGallina)
INITIALLY DEFERRED DEFERRABLE;
INSERT INTO Gallina VALUES(4, 5);
INSERT INTO Huevo VALUES(5, 4);
COMMIT;
Comprobación diferida de
restricciones (II)

ALTER TABLE HuevoDROP CONSTRAINT fkRefGallina;
ALTER TABLE GallinaDROP CONSTRAINT fkRefHuevo;
DROP TABLE Huevo;
DROP TABLE Gallina;
Comprobación diferida de
restricciones (III)

Niveles de Aislamiento (I)

En algunos casos, podemos reducir la sobrecarga de
la gestión de cerrojos

SQL92 define 4 niveles de aislamiento: Nivel
Lectura sucia
Lectura no
repetible
Lectura
fantasma
Read
uncommitted
Posible
Posible
Posible
Read
committed
No posible
Posible
Posible
Repeatable
read
No posible
No posible
Posible
Serializable
No posible
No posible
No posible


Oracle ofrece 2 niveles de aislamiento:

Readcommitted
(por defecto)

Evita el problema de la lectura sucia

Evita el problema de la actualización perdida

Serializable

Además, ofrece un modo de sólo lectura (no parte del estándar)

SET TRANSACTION READ ONLY

Sólo se verán los cambios confirmados antes
de que empezara la transacción
Niveles de Aislamiento (II)

Transacciones SQL: Confirmar,
Revertir, Guardar
Las transacciones SQL se utilizan para mantener la fiabilidad de
los datos al garantizar que una secuencia de instrucciones SQL
server se ejecute por completo o no se ejecute.
A través de las transacciones SQL se gestionan secuencias de
sentencias SQL que deben ejecutarse como una única unidad de
trabajo, de modo que la base de datos nunca contenga los
resultados de operaciones parciales.
Cuando una transacción SQL realiza varios cambios en la base de
datos, todos los cambios se realizan correctamente cuando se
confirma la transacción o todos los cambios se deshacen cuando se
revierte la transacción.

¿Cuándo usar transacciones SQL?

Las transacciones SQL son primordiales en situaciones en las que
la integridad de los datos estaría en riesgo en caso de que fallara
cualquiera de una secuencia de instrucciones SQL.
Por ejemplo, si estuviera moviendo dinero de una cuenta bancaria
a otra, necesitaría deducir dinero de una cuenta y agregarlo a la
otra. No querrá que falle a la mitad, de lo contrario, el dinero
podría debitarse de una cuenta, pero no acreditarse en la otra. Las
posibles razones de la falla podrían incluir fondos insuficientes,
número de cuenta no válido, falla de hardware, etc.
Control de transacciones
Los siguientes comandos se utilizan para controlar las
transacciones.
• COMMIT − para guardar los cambios.
• ROLLBACK : para revertir los cambios.
• SAVEPOINT: crea puntos dentro de los grupos de
transacciones en los que ROLLBACK.
• SET TRANSACTION : coloca un nombre en una
transacción.
Sintaxis de transacciones SQL
BEGIN TRY
BEGIN TRANSACTION
--Insertaremos el código de la transacción
END TRY
BEGIN CATCH
--recoger y mostrar los errores
ROLLBACK TRANSACTION;
END CATCH

IF @@TRANCOUNT > 0
COMMIT TRANSACTION
END
Lista de cosas para recordar mientras se trabaja en las
transacciones SQL.
• Cada transacción SQL debe comenzar con BEGIN
TRANSACTION, BEGIN TRAN o BEGIN TRANSACTION.
• Cada transacción en SQL Server debe terminar con
instrucciones COMMIT o ROLLBACK.
• COMMIT TRANSACTION: esta declaración le dice al SQL
que guarde los cambios realizados entre BEGIN y COMMIT.
Hay varias formas de escribir esta declaración. Puede escribir
COMMIT, COMMIT TRAN, COMMIT TRANSACTION o
COMMIT TRANSACTION.
• ROLLBACK TRANSACTION: esta declaración le dice al SQL
que borre todos los cambios realizados entre BEGIN y
ROLLBACK. Hay varias formas de escribir esta declaración.
Puede escribir ROLLBACK, ROLLBACK TRAN, ROLLBACK
TRANSACTION o ROLLBACK TRANSACTION.

Ejemplo de transacción SQL
En este ejemplo de SQL Server, colocaremos una instrucción
INSERT INTO y DELETE dentro de la transacción BEGIN y
COMMIT.
Create table cuenta(
Idcuenta integer primary key,
Saldo numeric(7,2) check(saldo>=0.00)
)

Ejemplo 1:
Begin transaction
Insert into cuenta values (1,125.00)
Go
Commit tran

Rollback tran

Ejemplo 2:
--transaccion 1

begin transaction
insert into cuenta values (2,130.00)
go
commit tran

rollback tran

select * from cuenta
--transaccion 2
begin transaction
insert into cuenta values (3,150.00)
go
commit tran

select * from cuenta

rollback tran

Ejemplo 3
BEGIN TRAN
BEGIN TRY
insert into cuenta values (1,150.00)
COMMIT TRAN
END TRY
BEGIN CATCH
ROLLBACK TRAN
END CATCH

select * from cuenta;

La declaración TRY-CATCH implementa el manejo de errores en
SQL Server. Puede encerrar cualquier grupo de declaraciones en
transacciones SQL en un TRYbloque. Luego, si ocurre un error en
el TRYbloque, el control se pasa a otro grupo de sentencias que está
encerrado en un CATCHbloque.
En este caso, usamos el CATCH bloque para revertir la
transacción. Dado que está en el CATCHbloque, la reversión solo
ocurre si hay un error.
SAVEPOINT:
Es un punto de guardado en las transacciones SQL define una
ubicación a la que una transacción puede regresar si parte de la
transacción se cancela condicionalmente. En SQL Server,
especificamos un punto de guardado con
(donde savepoint_name es el nombre que le damos al punto de
guardado).SAVE TRANSACTION savepoint_name
Por ejemplo, si ocurre algún desastre después de ese punto, o
cualquier comando de reversión ejecutado no elimina los datos
antes del punto de guardado de la transacción SQL.
BEGIN TRANSACTION
INSERT INTO cuenta VALUES (9,100.00)
go
SAVE TRANSACTION uno
DELETE FROM cuenta WHERE idcuenta=9
SELECT * FROM cuenta
ROLLBACK TRANSACTION uno
COMMIT TRANSACTION

Transacciones en SQL Server

En SQL Server las instrucciones equivalentes a las genéricas que acabamos
de ver son:
• BEGIN TRANSACTION o BEGIN TRAN: marca el inicio de una
transacción. TRAN es un sinónimo de TRANSACTION y se suele usar
más a menudo por abreviar.
• ROLLBACK TRANSATION o ROLLBACK TRAN: fuerza que se
deshaga la transacción en caso de haber un problema o querer
abandonarla. Cierra la transacción.
• COMMIT TRANSACTION O COMMIT TRAN: confirma el conjunto de
operaciones convirtiendo los datos en definitivos. Marca el éxito de la
operación de bloque y cierra la transacción.
Los niveles de aislamiento que nos ofrece SQL Server son:
• SERIALIZABLE: No se permitirá a otras transacciones la inserción,
actualización o borrado de datos utilizados por nuestra transacción.
Los bloquea mientras dura la misma.
• REPEATABLE READ: Garantiza que los datos leídos no podrán ser
cambiados por otras transacciones, durante esa transacción.
• READ COMMITED: Una transacción no podrá ver los cambios de otras
conexiones hasta que no hayan sido confirmados o descartados.
• READ UNCOMMITTED : No afectan los bloqueos producidos por otras
conexiones a la lectura de datos.
• SNAPSHOT: Los datos seleccionados en la transacción se verán tal y
como estaban al comienzo de la transacción, y no se tendrán en
cuenta las actualizaciones que hayan sufrido por la ejecución de otras
transacciones simultáneas.
Una transacción es un conjunto de operaciones Transact SQL que se
ejecutan como un único bloque, es decir, si falla una operación Transact SQL
fallan todas. Si una transacción tiene éxito, todas las modificaciones de los
datos realizadas durante la transacción se confirman y se convierten en una
parte permanente de la base de datos. Si una transacción encuentra errores

y debe cancelarse o revertirse, se borran todas las modificaciones de los
datos.
La transacción más simple en SQL Server es una única sentencia SQL. una
transacción ‘autocommit’, una transacción autocompletada.
UPDATE clientes SET sexo='F' WHERE sexo ='FEMENINO'
Cuando enviamos esta sentencia al SQL Server se escribe en el fichero de
transacciones lo que va a ocurrir y a continuación realiza los cambios
necesarios en la base de datos. Si hay algún tipo de problema al hacer esta
operación el SQL Server puede leer en el fichero de transacciones lo que se
estaba haciendo y si es necesario puede devolver la base de datos al estado
en el que se encontraba antes de recibir la sentencia.
Por supuesto este tipo de transacciones no requieren de nuestra
intervención puesto que el sistema se encarga de todo. Sin embargo si hay
que realizar varias operaciones y queremos que sean tratadas como una
unidad tenemos que crear esas transacciones de manera explícita.
Sentencias
La sentencia que se utiliza para indicar el comienzo de una transacción es
‘BEGIN TRAN’. Si alguna de las operaciones de una transacción falla hay que
deshacer la transacción en su totalidad para volver al estado inicial en el que
estaba la base de datos antes de empezar. Esto se consigue con la sentencia
‘ROLLBACK TRAN’.
Si todas las operaciones de una transacción se completan con éxito hay que
marcar el fin de una transacción para que la base de datos vuelva a estar en
un estado consistente con la sentencia ‘COMMIT TRAN’.

Realizar lo siguiente:
Un ejemplo
Trabajaremos con la base de datos Northwind en nuestros ejemplos. Vamos a realizar una
transacción que modifica el precio de dos productos de la base de datos.
USE NorthWind
select * from Products
where ProductName ='Chai'
DECLARE @Error int
--Declaramos una variable que utilizaremos para almacenar un posible código de error

BEGIN TRAN
--Iniciamos la transacción
UPDATE Products SET UnitPrice=20

--Ejecutamos la primera sentencia
SET @Error=@@ERROR
--Si ocurre un error almacenamos su código en @Error
--y saltamos al trozo de código que deshara la transacción. Si, eso de ahí es un
--GOTO, el demonio de los programadores, pero no pasa nada por usarlo
--cuando es necesario
IF (@Error<>0) GOTO TratarError

--Si la primera sentencia se ejecuta con éxito, pasamos a la segunda
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
SET @Error=@@ERROR
--Y si hay un error hacemos como antes
IF (@Error<>0) GOTO TratarError

--Si llegamos hasta aquí es que los dos UPDATE se han completado con
--éxito y podemos "guardar" la transacción en la base de datos
COMMIT TRAN

TratarError:
--Si ha ocurrido algún error llegamos hasta aquí
If @@Error<>0
BEGIN
PRINT 'Hay error. Abortamos la transacción'
--Se lo comunicamos al usuario y deshacemos la transacción
--todo volverá a estar como si nada hubiera oc urrido
ROLLBACK TRAN
END

select * from Products
where ProductName ='Chai'

Como se puede ver para cada sentencia que se ejecuta miramos si se ha producido o no un
error, y si detectamos un error ejecutamos el bloque de código que deshace la transacción.

Hay una interpretación incorrecta en cuanto al funcionamiento de las transacciones que esta
bastante extendida. Mucha gente cree que si tenemos varias sentencias dentro de una
transacción y una de ellas falla, la transacción se aborta en su totalidad.
¡Nada más lejos de la realidad! Si tenemos dos sentencias dentro de una transacción.
USE NorthWind
BEGIN TRAN
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
UPDATE Products SET UnitPrice=20 WHERE ProductName='Chang'
COMMIT TRAN
Estas dos sentencias se ejecutarán como una sola. Si por ejemplo en medio de la transacción
(después del primer update y antes del segundo) hay un corte de electricidad, cuando el SQL
Server se recupere se encontrará en medio de una transacción y, o bien la termina o bien la
deshace, pero no se quedará a medias.
El error está en pensar que si la ejecución de la primera sentencia da un error se cancelará la
transacción. El SQL Server sólo se preocupa de ejecutar las sentencias, no de averiguar si lo
hacen correctamente o si la lógica de la transacción es correcta. Eso es cosa nuestra.
Por eso en el ejemplo que tenemos más arriba para cada sentencia de nuestro conjunto
averiguamos si se ha producido un error y si es así actuamos en consecuencia cancelando
toda la operación.
Transacciones anidadas
Otra de las posibilidades que nos ofrece el SQL Server es utilizar transacciones anidadas.
Esto quiere decir que podemos tener transacciones dentro de transacciones, es decir,
podemos empezar una nueva transacción sin haber terminado la anterior.
Asociada a esta idea de anidamiento existe una variable global @@TRANCOUNT que tiene
valor 0 si no existe ningún nivel de anidamiento, 1 si hay una transacción anidada, 2 si
estamos en el segundo nivel de anidamiento. y así sucesivamente.
La dificultad de trabajar con transacciones anidadas está en el comportamiento que tienen
ahora las sentencias 'COMMIT TRAN' y 'ROLLBACK TRAN'
• ROLLBACK TRAN: Dentro de una transacción anidada esta sentencia deshace todas
las transacciones internas hasta la instrucción BEGIN TRANSACTION más externa.
• COMMIT TRAN: Dentro de una transacción anidada esta sentencia únicamente
reduce en 1 el valor de @@TRANCOUNT, pero no "finaliza" ninguna transacción ni
"guarda" los cambios. En el caso en el que @@TRANCOUNT=1 (cuando estamos en
la última transacción) COMMIT TRAN hace que todas las modificaciones efectuadas
sobre los datos desde el inicio de la transacción sean parte permanente de la base de
datos, libera los recursos mantenidos por la conexión y reduce @@TRANCOUNT a 0.
Como siempre un ejemplo es lo mejor para entender como funciona.

CREATE TABLE Test (Columna int)
GO
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
COMMIT TRAN TranInterna2 -- Reduce @@TRANCOUNT a 2.
-- Pero no se guarda nada en la base de datos.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.
-- Pero no se guarda nada en la base de datos.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.
-- Se lleva a cabo la transacción externa y todo lo que conlleva.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test

Por cierto que lo de usar nombre para las transacciones es por claridad, puesto que COMMIT
TRAN como ya hemos dicho solamente reduce en 1 el valor de @@TRANCOUNT.
Veamos ahora un ejemplo de transacción anidada con ROLLBACK TRAN
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
ROLLBACK TRAN --@@TRANCOUNT es 0 y se deshace
--la transacción externa y todas las internas
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test

En este caso no se inserta nada puesto que el ROLLBACK TRAN deshace todas las
transacciones dentro de nuestro anidamiento hasta la transacción más externa y además hace
@@TRANCOUNT=0
¿Supone este funcionamiento asimétrico del COMMIT y del ROLLBACK un problema? Pues la
verdad es que no. La manera de tratar las transacciones por el SQL Server es la que nos
permite programar de manera natural los anidamientos. De todos modos, si queremos ir un

poco más lejos hay una cuarta sentencia para trabajar con transacciones: SAVE TRAN Save
Tran
Esta sentencia crea un punto de almacenamiento dentro de una transacción. Esta marca sirve
para deshacer una transacción en curso sólo hasta ese punto. Por supuesto nuestra
transacción debe continuar y terminar con un COMMIN TRAN (o los que hagan falta) para que
todo se guarde o con un ROLLBACK TRAN para volver al estado previo al primer BEGIN
TRAN.
BEGIN TRAN TranExterna -- @@TRANCOUNT ahora es 1
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (1)
BEGIN TRAN TranInterna1 -- @@TRANCOUNT ahora es 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (2)
SAVE TRAN Guadada
BEGIN TRAN TranInterna2 -- @@TRANCOUNT ahora es 3.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
INSERT INTO Test VALUES (3)
ROLLBACK TRAN Guadada -- se deshace lo hecho el punto guardado.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
--Ahora podemos decidir si la transacción se lleva a cabo
--o se deshace completamente
--Para deshacerla un ROLLBACK bastará como hemos visto
--Pero para guardar la transacción hace falta reducir @@TRANCOUNT a 0
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 2.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranInterna1 -- Reduce @@TRANCOUNT a 1.
-- Pero no se guarda nada en la base de datos.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
COMMIT TRAN TranExterna -- Reduce @@TRANCOUNT a 0.
-- Se lleva a cabo la transacción externa y todo lo que conlleva.
SELECT 'El nivel de anidamiento es', @@TRANCOUNT
SELECT * FROM Test

Si no ponemos el nombre del punto salvado con SAVE TRAN al hacer un ROLLBACK TRAN
se deshace la transacción más externa y @@TRANCOUNT se pone a 0.
Como podemos ver el uso de transacciones no es complicado, e incluso las transacciones
anidadas si se tratan con cuidado son fáciles de manejar.

Un par de ejemplos más
Veamos otro par de ejemplos para dejar claro como funcionan las sentencias BEGIN,
COMMIT y SAVE

BEGIN TRAN
-- Primer BEGIN TRAN y ahora @@TRANCOUNT = 1
BEGIN TRAN
-- Ahora @@TRANCOUNT = 2
COMMIT TRAN
-- Volvemos a @@TRANCOUNT = 1
-- Pero no se guarda nada ni se hacen efectivos los posibles cambios
COMMIT TRAN
-- Por fin @@TRANCOUNT = 0
-- Si hubiera cambios pendientes se llevan a la base de datos
-- Y volvemos a un estado normal con la transacción acabada

Uso del COMMIT
BEGIN TRAN
-- Primer BEGIN TRAN y @@TRANCOUNT = 1
BEGIN TRAN
-- Ahora @@TRANCOUNT = 2
COMMIT TRAN
-- Como antes @@TRANCOUNT = 1
--Y como antes nada se guarda
ROLLBACK TRAN
-- Se cancela TODA la transacción. Recordemos que el COMMIT
-- de antes no guardo nada, solo redujo @@TRANCOUNT
-- Ahora @@TRANCOUNT = 0
COMMIT TRAN
-- No vale para nada porque @@TRANCOUNT es 0 por el efecto del ROLLBACK

Uso del ROLLBACK
En cuanto al SAVE TRAN podemos recordarlo con el siguiente ejemplo:
CREATE TABLE Tabla1 (Columna1 varchar(50))
GO

BEGIN TRAN
INSERT INTO Tabla1 VALUES ('Primer valor')
SAVE TRAN Punto1
INSERT INTO Tabla1 VALUES ('Segundo valor')
ROLLBACK TRAN Punto1
INSERT INTO Tabla1 VALUES ('Tercer valor')
COMMIT TRAN

SELECT * FROM Tabla1
Columna1
--------------------------------------------------
Primer valor
Tercer valor
(2 filas afectadas)

Un ROLLBACK a un SAVE TRAN no deshace la transacción en curso ni modifica
@@TRANCOUNT, simplemente cancela lo ocurrido desde el 'SAVE TRAN nombre' hasta su
'ROLLBACK TRAN nombre'
Transacciones y procedimientos almacenados.
Cuando trabajamos con procedimientos almacenados debemos recordar que cada
procedimiento almacenado es una unidad. Cuando se ejecuta lo hace de manera
independiente de quien lo llama. Sin embargo si tenemos un ROLLBACK TRAN dentro de un
procedimiento almacenado cancelaremos la transacción en curso, pero si hay una transacción
externa al procedimiento en el que estamos trabajando se cancelará esa transacción externa.
Con esto no quiero decir que no se pueda usar, simplemente que hay que tener muy claras las
4 normas sobre las sentencias BEGIN, ROLLBACK y COMMIT que comentamos al principio
de este artículo. Veamos como se comporta una transacción en un procedimiento almacenado
llamado desde una transacción.
CREATE PROCEDURE Inserta2
AS
BEGIN TRAN --Uno
INSERT INTO Tabla1 VALUES ('Valor2')
ROLLBACK TRAN --Uno
GO

CREATE PROCEDURE Inserta1
AS
BEGIN TRAN --Dos
INSERT INTO Tabla1 VALUES ('Valor 1')
EXEC Inserta2
INSERT INTO Tabla1 VALUES ('Valor3')
COMMIT TRAN --Dos
GO

En principio parece que si ejecutamos el procedimiento 'Inserta1' el resultado sería:
EXECUTE inserta1
SELECT * FROM tabla1

txt
--------------------------------------------------
Valor1
Valor3

(2 filas afectadas)
Pero lo que obtenemos es:
EXECUTE inserta1
SELECT * FROM tabla1

(1 filas afectadas)
(1 filas afectadas)
Servidor: mensaje 266, nivel 16, estado 2, procedimiento Inserta2, línea 8
El recuento de transacciones después de EXECUTE
indica que falta una instrucción COMMIT o ROLLBACK TRANSACTION.
Recuento anterior = 1, recuento actual = 0.
(1 filas afectadas)
Servidor: mensaje 3902, nivel 16, estado 1, procedimiento Inserta1, línea 8
La petición COMMIT TRANSACTION no tiene la correspondiente BEGIN TRANSACTION.
txt
--------------------------------------------------
Valor3
(1 filas afectadas)

Si analizamos estos mensajes vemos que se inserta la primera fila, se salta al segundo
procedimiento almacenado y se inserta la segunda fila. Se ejecuta el 'ROLLBACK TRAN -Dos'
del segundo procedimiento almacenado y se deshacen las dos inserciones porque este
ROLLBACK cancela la transacción exterior, la del primer procedimiento almacenado. A
continuación se termina el segundo procedimiento almacenado y como este procedimiento
tiene un 'BEGIN TRAN -Dos' y no tiene un COMMIT o un ROLLBACK (recordemos que el
'ROLLBACK TRAN -Dos' termina el 'BEGIN TRAN -Uno') se produce un error y nos avisa que
el procedimiento almacenado termina con una transacción pendiente. Al volver al
procedimiento almacenado externo se ejecuta el INSERT que inserta la tercera fila y a
continuación el 'COMMIT TRAN --Uno'. Aquí aparece otro error puesto que este 'COMMIT
TRAN -Uno' estaba ahí para finalizar una transacción que ya ha sido cancelada anteriormente.
El modo correcto
Para que nuestras transacciones se comporten como se espera dentro de un procedimiento
almacenado podemos recurrir al SAVE TRAN.
Veamos como:
CREATE PROCEDURE Inserta2
AS
SAVE TRAN Guardado
INSERT INTO Tabla1 VALUES ('Valor2')
ROLLBACK TRAN Guardado
GO

CREATE PROCEDURE Inserta1
AS
BEGIN TRAN
INSERT INTO Tabla1 VALUES ('Valor 1')
EXEC Inserta2

INSERT INTO Tabla1 VALUES ('Valor 3')
COMMIT TRAN
GO

Ahora el 'ROLLBACK TRAN guardado' del segundo procedimiento almacenado deshace la
transacción sólo hasta el punto guardado. Además este ROLLBACK no decrementa el
@@TRANCOUNT ni afecta a las transacciones en curso.
El resultado obtenido al ejecutar este procedimiento almacenado es:
EXECUTE inserta1
SELECT * FROM tabla1

(1 filas afectadas)
(1 filas afectadas)
(1 filas afectadas)
txt
--------------------------------------------------
Valor 1
Valor 3
(2 filas afectadas)

Una vez vistos estos ejemplos queda claro que no hay problema en utilizar transacciones
dentro de procedimientos almacenados siempre que tengamos en cuenta el comportamiento
del ROLLBACK TRAN y que utilicemos el SAVE TRAN de manera adecuada.

Rollback Transaction in SQL Server
Confirmar y revertir transacciones en SQL Server es un tema enorme en sí mismo. En este artículo, explicaré
cómo usar un Try. Captura de bloque para confirmar y revertir la transacción. En artículos posteriores,
también exploraremos cómo revertir transacciones anidadas.
Considere este ejemplo, donde primero escribiremos un código T-SQL que confirma la transacción y agrega
un nuevo registro en una tabla.
CREATE TABLE TT (num int)
GO
CREATE PROC SP1
AS
BEGIN TRY
BEGIN TRANSACTION
INSERT INTO TT(num) VALUES (630)
INSERT INTO TT(num) VALUES (890)
COMMIT TRANSACTION
END TRY

BEGIN CATCH
IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION
-- Error Message
DECLARE @Err nvarchar(1000)
SET @Err = ERROR_MESSAGE()
RAISERROR (@Err,16,1)
END CATCH
GO
EXEC SP1
Ejecute el código que se muestra arriba y consulte la tabla
SELECT * FROM TT
Debería obtener el siguiente resultado

Desde el Usuario SQL

Oracle --- Transacciones
Contenido
Oracle --- Transacciones ....................................................................................................... 1
1.0 ¿Qué es una transacción? ....................................................................................................... 2
2.0 Las características de la transacción ....................................................................................... 2
2.1 Atomicidad .......................................................................................................................... 2
2.2 Consistencia ........................................................................................................................ 2
2.3 Aislamiento (Isolation) ........................................................................................................ 2
2.4 Durabilidad .......................................................................................................................... 3
3.0 Los datos son anormales ......................................................................................................... 3
3.1 Lectura sucia ........................................................................................................................ 3
3.2 Lectura no repetible ............................................................................................................ 3
3.3 Lectura fantasma ................................................................................................................. 3
4.0 Nivel de aislamiento de transacciones .................................................................................... 4
5. Estados de las transacciones ..................................................................................................... 4
5.1 Estado de actividad ............................................................................................................. 4
5.2 Estado de envío parcial ....................................................................................................... 4
5.3 Estado de falla ..................................................................................................................... 5
5.4 estado de envío ................................................................................................................... 5
5.5 Estado de aborto ................................................................................................................. 5
6.0 Comandos de control de transacciones .................................................................................. 5
6.1 Configurar transacciones..................................................................................................... 5
6.1.1, configurar transacciones de solo lectura .................................................................... 5
6.1.2 Configurar transacciones de lectura y escritura .......................................................... 6
6.1.3 Establecer la transacción de lectura confirmada ......................................................... 6
6.1.4 Establecer transacción serializable .............................................................................. 6
6.1.5. Configurar una sola transacción .................................................................................. 6
6.2 Compromiso de transacción ............................................................................................... 6
6.2.1. Estado SGA antes de la presentación .......................................................................... 7
6.2.2 Trabajo presentado ...................................................................................................... 7
6.2.3 La forma de presentación ............................................................................................ 7
6.3 Reversión de transacciones ................................................................................................. 8
6.4 Punto de reversión de transacciones .................................................................................. 8
6.4.1 Crear un punto de guardado ........................................................................................ 8
6.4.2 Usar puntos de guardado ............................................................................................. 9

1.0 ¿Qué es una transacción?
Transacción (Transacción) es una secuencia de operaciones de base de datos
definida por el usuario, que es un todo indivisible. Estas operaciones requieren
todas o ninguna de ellas. Una transacción es la unidad lógica más básica para operar
una base de datos. Puede ser un conjunto de declaraciones SQL, una declaración SQL
o el programa completo. Por lo general, una aplicación contiene múltiples
transacciones. Además, la transacción es la unidad básica de respuesta y control de
concurrencia.
2.0 Las características de la transacción.
Las transacciones tienen las siguientes 4 características más importantes, que se
combinan en atributos ACID de acuerdo con las características.
2.1 Atomicidad
Atomicidad significa que una transacción es una unidad de trabajo indivisible, y
todas las adiciones, eliminaciones y cambios de datos en la transacción se ejecutan
o no se ejecutan.
2.2 Consistencia
Cuando se completa la transacción, todos los datos deben mantenerse en un estado
consistente, es decir, todas las modificaciones de datos realizadas a través de la
transacción deben reflejarse en todas las tablas relacionadas.
2.3 Aislamiento (Isolation)
Incluso si cada transacción puede garantizar la coherencia y la atomicidad, si se
ejecutan varias transacciones al mismo tiempo, si hay una intersección entre las
transacciones durante el proceso de ejecución, la base de datos será inconsistente.
El aislamiento de transacciones significa que la ejecución de una transacción no
puede ser interferida por otras transacciones, es decir, las operaciones internas y
los datos utilizados por una transacción están aislados de otras transacciones
concurrentes, y cada transacción ejecutada simultáneamente no puede interferir
entre sí.

2.4 Durabilidad
La persistencia significa que una vez que se confirma una transacción, sus cambios
en los datos de la base de datos son permanentes y otras operaciones posteriores y
fallas de la base de datos no deberían tener ningún impacto en ella.

3.0 Los datos son anormales
Dado que Oracle admite la ejecución simultánea de varias transacciones, se
producirán las siguientes excepciones de datos:
3.1 Lectura sucia
Cuando una transacción modifica datos, otra transacción lee los datos, pero la
primera transacción cancela la modificación de datos por algún motivo y los datos
vuelven al estado original. En este momento, los datos leídos por la segunda
transacción están en la base de datos. es inconsistente, lo que se denomina lectura
sucia.
3.2 Lectura no repetible
Significa que después de que una transacción lee los datos en la base de datos, otra
transacción actualiza los datos. Cuando la primera transacción lee los datos
nuevamente, encontrará que el verso ha cambiado, lo cual es una lectura no
repetible. El resultado de la lectura no repetible es que los datos leídos dos veces
antes y después de una transacción son diferentes.
3.3 Lectura fantasma
Si una transacción lee datos en función de una determinada condición, otra
transacción actualiza los datos en la misma tabla. En este momento, cuando la
primera transacción vuelve a leer los datos, se devuelven diferentes filas de acuerdo
con las condiciones de búsqueda. Esta es una lectura mágica.

4.0 Nivel de aislamiento de transacciones
En vista de las inconsistencias que pueden ocurrir al leer datos, se definen cinco
niveles de aislamiento de transacciones en el estándar SQL92:
• NO_TRANSACTION: no admite transacciones
• READ_UNCOMMITTED: Permitir lectura sucia, lectura no repetible, lectura
fantasma
• READ_COMMITTED: lecturas no repetibles, se permiten lecturas fantasmas, no se
permiten lecturas sucias
• REPETIBLE: permite lecturas fantasmas, no lecturas sucias, lecturas no repetibles
• SERIALIZABLE: No se permiten lecturas sucias, lecturas no repetibles y lecturas
fantasmas

El nivel de aislamiento predeterminado de Oracle es READ_COMMITTED
Oracle admite dos de los 5 niveles de aislamiento anteriores: READ_COMMITTED y
SERIALIZABLE.
Oracle también define los niveles de aislamiento READ ONLY y READ WRITE:
• SOLO LECTURA: No puede haber declaraciones operativas que modifiquen los
datos en la base de datos en la transacción, que es un subconjunto de
SERIALIZABLE.
• LEER ESCRIBIR: Es la configuración predeterminada, esta opción significa que
puede haber declaraciones de acceso y declaraciones de modificación en una
transacción, pero no se usa con frecuencia.

5. Estados de las transacciones
Hay 5 estados para varias transacciones que operan en la base de datos:
5.1 Estado de actividad
El estado de la transacción durante la ejecución se denomina estado activo.
5.2 Estado de envío parcial
El estado posterior a la ejecución de la última instrucción de la transacción se
denomina estado de confirmación parcial. Aunque la transacción se ha completado,

debido a que la salida real puede estar en la memoria, puede ocurrir una falla de
hardware antes de que la transacción sea exitosa y, a veces, se debe abortar y entrar
en el estado de cancelación.
5.3 Estado de falla
El estado en el que la transacción no se puede ejecutar normalmente se denomina
estado fallido. Las posibles razones que causan que ocurra el estado de falla están
relacionadas con errores de hardware o lógicos, por lo que la transacción debe
revertirse y entrar en el estado de cancelación.
5.4 estado de envío
Una vez que la transacción se ha confirmado parcialmente, los datos se escribirán
en el disco duro. El estado posterior a la escritura de la última información se
denomina estado de confirmación y la transacción que entra en el estado de
confirmación se completa con éxito.
5.5 Estado de aborto
La transacción se revierte y la base de datos se ha restaurado al estado en el que
estaba antes de que comenzara la transacción, llamado estado abortado.
Nota: Las transacciones en estado comprometido y abortado se denominan
colectivamente transacciones resueltas, y las transacciones en estado activo,
parcialmente comprometido y fallido se denominan transacciones
pendientes.

6.0 Comandos de control de transacciones
6.1 Configurar transacciones
6.1.1, configurar transacciones de solo lectura
Si la transacción está configurada como de solo lectura, no se establecerá la
información de reversión, que es adecuada para transacciones compuestas por
declaraciones de consulta SQL.

set transaction read only;

6.1.2 Configurar transacciones de lectura y escritura
Establecer la transacción como una transacción de lectura-escritura es el modo
predeterminado de la transacción, y se establecerá la información de reversión
set transaction read write

6.1.3 Establecer la transacción de lectura confirmada
Configure la transacción para leer comprometida, permitir lecturas no repetibles,
lecturas fantasmas y no permitir lecturas sucias
set transaction isolation level read committed

6.1.4 Establecer transacción serializable
Configure la transacción como serializable, no permita lecturas repetidas, lecturas
fantasmas, lecturas sucias
set transaction isolation level serializable

6.1.5. Configurar una sola transacción

alter session set transaction isolation level read committed

Nota: Estas transacciones son mutuamente excluyentes y no se pueden
configurar dos o más opciones al mismo tiempo.

6.2 Compromiso de transacción
En el sistema de gestión de la base de datos Oracle, a fin de asegurar la consistencia
de los datos, se establecerá un área de trabajo para cada cliente en la memoria del
SGA. Las transacciones que el cliente realiza en la base de datos se completan en el
área de trabajo, y solo cuando el Se ingresa el comando de confirmación de
transacción Después de eso, el contenido modificado en el área de trabajo se escribe

en la base de datos, lo que se denomina escritura física. Esto asegura que los datos
en la base de datos leídos por otros clientes sean completos y consistentes antes de
que cualquier cliente confirme físicamente la modificación.
6.2.1. Estado SGA antes de la presentación
Antes de que se confirme la transacción, se ejecuta la instrucción SQL de Oracle y el
estado en la memoria SGA es el siguiente:

• El búfer de reversión genera registros de reversión y la información de reversión
contiene todos los valores antiguos que se han modificado.
• El búfer de registro genera un registro de la transacción, que se ha escrito en el
disco físico antes de que se confirme la transacción.
• El búfer de la base de datos se modifica y estas modificaciones se escriben en el
disco físico una vez confirmada la transacción.

6.2.2 Trabajo presentado
El envío de la transacción completará las siguientes tareas principales:

• Registre las transacciones enviadas en la tabla de transacciones correspondiente
y asigne a cada transacción un Número de cambio de sistema (SCN) único y
regístrelo en la tabla.
• Los datos del búfer de datos SGA se escriben en la tabla de datos físicos.
• Por LGWR (proceso de escritura de registro), las entradas de registro en el búfer
de registro SGA se escriben en el archivo de registro en línea.
• Desbloquea registros y tablas.
• Marque que la transacción se ha completado.

6.2.3 La forma de presentación
Hay 3 formas de confirmar transacciones:
Mostrar presentación: usar commit El comando es la transacción actual efectiva.
• Envío automático: piense en configurar el envío automático: set autocommit on,
Solo para la conexión actual
• Sumisión implícita:
• (1) Declaraciones DDL que normalmente se ejecutan: crear, modificar, eliminar
• (2) Declaraciones DCL que se ejecutan normalmente: conceder, revocar

• (3) Clientes como SQLPlus o SQL Developer que salen normalmente
• (4) Cierre la base de datos normalmente

6.3 Reversión de transacciones
La reversión de transacciones se refiere a revocar la modificación de datos realizada
por comandos SQL en transacciones no confirmadas, y las transacciones
confirmadas no se pueden revertir. La reversión de toda la transacción completará
las siguientes tareas principales:
• Utilice los datos almacenados en el segmento de reversión para deshacer las
modificaciones realizadas por el comando SQL en la transacción no confirmada
• Desbloquea todas las transacciones de datos
• Finalizar la transacción

6.4 Punto de reversión de transacciones
El punto de reversión también se conoce como punto de guardado, que se refiere a
la marca de reversión establecida en medio de una transacción que contiene más
declaraciones SQL, y su función es similar al punto de interrupción del depurador.
Use los puntos de guardado para dividir la transacción en varias partes pequeñas,
de modo que no necesite revertir toda la transacción, puede revertir al punto de
guardado especificado, con mayor flexibilidad.
Retroceder al punto de guardado especificado completará el siguiente trabajo:

• Parte de la transacción después de que se deshaga el punto de guardado.
• Después de eliminar y cambiar todos los puntos de guardado, los puntos de
guardado se conservan para más reversiones.
• Desbloquea la tabla o la fila después del punto de guardado.

6.4.1 Crear un punto de guardado
savepoint sp_test01

6.4.2 Usar puntos de guardado
rollback to sp_test01

Ejemplo:
CREATE TABLE AHORROS(IDCUENTA VARCHAR(5) PRIMARY KEY,
SALDO DECIMAL(18,2)
)
CREATE TABLE MOVIMIENTOS (IDCUENTA VARCHAR(5) ,
SALDO_ANTERIOR DECIMAL(18,2),
NUEVO_SALDO DECIMAL(18,2)
)
ALTER TABLE MOVIMIENTOS ADD FOREIGN KEY (IDCUENTA) REFERENCES AHORROS (IDCUENTA)

INSERT INTO AHORROS VALUES ('11111',500.00)
INSERT INTO AHORROS VALUES ('22222',1000.00)
INSERT INTO AHORROS VALUES ('33333',1500.00)
INSERT INTO AHORROS VALUES ('44444',2000.00)

DECLARE @Monto DECIMAL(18,2),
@CuentaADecrementar VARCHAR(5),
@CuentaAIncrementar VARCHAR(5)

/* Asignamos el monto de la transacción y las cuentas a afectar*/

SET @Monto = 125
SET @CuentaADecrementar = '11111'
SET @CuentaAIncrementar = '22222'

BEGIN TRANSACTION
BEGIN TRY

/* Descontamos el monto de la cuenta a decrementar */
UPDATE AHORROS SET SALDO = SALDO - @Monto WHERE IDcUENTA = @CuentaADecrementar

/* Registramos el movimiento */
INSERT INTO MOVIMIENTOS (IDCUENTA, SALDO_ANTERIOR, NUEVO_SALDO)

/* Incrementamos el monto de la cuenta a incrementar */
UPDATE AHORROS SET SALDO = SALDO + @Monto WHERE IDCUENTA = @CuentaAIncrementar

/* Registramos el movimiento */
INSERT INTO MOVIMIENTOS (IDCUENTA, SALDO_ANTERIOR, SALDO_POSTERIOR)

/* Confirmamos la transaccion*/
COMMIT TRANSACTION

END TRY

BEGIN CATCH

/* Ocurrió un error, deshacemos los cambios*/
ROLLBACK TRANSACTION
PRINT 'Ha ocurrido un error!'

END CATCH

Bloqueos…
Ejemplos de Lock
LOCK TABLE Ahorros IN SHARE MODE;
SELECT *
FROM Ahorros
WHERE idcuenta=’11111’';

Tiene una transacción con varias instrucciones UPDATE. Dado que cada una de
las instrucciones individuales adquiere solo unos pocos bloqueos de nivel de fila,
la transacción no actualizará automáticamente los bloqueos a un bloqueo de
nivel de tabla. Sin embargo, colectivamente, las instrucciones UPDATE
adquieren y liberan un gran número de bloqueos, lo que puede dar lugar a
interbloqueos. Para este tipo de transacción, puede adquirir un bloqueo
exclusivo a nivel de tabla al comienzo de la transacción. Por ejemplo:

LOCK TABLE ahorros IN EXCLUSIVE MODE;
UPDATE ahorros
SET saldo=saldo+50.00 WHERE idcuenta ='22222';

Bloqueo de datos en ORACLE
ORACLE usa automáticamente diferentes tipos de bloqueos para el control del acceso
concurrente a los datos y prevenir la interacción destructiva entre usuarios.
Bloquea automáticamente los datos fuente durante la transacción para evitar que otras
transacciones hagan algo requiriendo acceso exclusivo de los mismos datos fuente.
Oracle clasifica los bloqueos en estas categorías:
·Data Locks (DML Locks) El Data Locks protege los datos (Table Locks: protege la tabla
entera, Row Locks a nivel de filas).
·Dictionary Locks (DDL Locks) Protege la estructura de los objetos, las definiciones de las
tablas y de las vistas.
·Internal Locks and Latches Protege las estructuras internas de la base de datos como los
archivos de datos. Son totalmente automáticos.
·Distributed Locks Aseguran que los datos y otras fuentes distribuidas entre varias
instancias del servidor en paralelo de Oracle sean consistentes.
·Parallel ce management (PCM) locks Son bloqueos distribuidos que cubren uno o más
bloques de datos (bloques de tablas o índices) en el buffer de la caché.

Los bloqueos que se han producido están dentro de las dos primeras categorías.
Obtenemos un tipo de bloqueo de la segunda categoría cuando trabajamos con el índice.
Dentro de la categoría Data Locks obtenemos:

El propósito de un data lock es garantizar la integridad de los datos durante el acceso
concurrente de múltiples usuarios.
TX Row Locks Una transacción adquiere un bloqueo de datos exclusivo para cada fila
individual modificada por una de los siguientes cláusulas INSERT, UPDATE, DELETE and
SELECT with the FOR UPDATE.
Se mantiene el bloqueo hasta que la transacción no haga commit o rollback.
TM Table Locks Una transacción adquiere un table locks en las siguientes instrucciones:
INSERT, UPDATE, DELETE and SELECT with the FOR UPDATE.
Estas operaciones DML requieren bloqueos de tabla para dos propósitos: uno para
controlar el acceso a la tabla durante la transacción y dos para prevenir los conflictos que
estas operaciones pudieran producir.
Un bloqueo de tabla se puede mantener en varios modos RS(Row Share) , RX (Row
exclusive), S (share), SRX (share row exclusive) y X (exclusive).
Row Exclusive Locks (RX) Indica que la transacción que mantiene el bloqueo ha hecho uno
o más updates sobre filas de la tabla.

Un row exclusive es adquirida automáticamente para una tabla que ha sido modificada
por uno de las siguientes cláusulas:

INSERT INTO table
UPDATE table
DELETE FROM table .....
LOCK TABLE table IN ROW EXCLUSIVE MODE;

Se permite a otras transacciones para consultas como insert, update, delete o bloqueos de
filas concurrentes en la misma tabla. Permiten a múltiples transacciones obtener
simultáneamente bloqueos exclusivos y compartidos sobre la misma tabla.
No se permite otra transacción no puede bloquear concurrentemente la tabla usando las
siguientes cláusulas.

LOCK TABLE table IN SHARE MODE;
LOCK TABLE table IN SHARE EXCLUSIVE MODE;
LOCK TABLE table IN EXCLUSIVE MODE;

Exclusive Table Locks (X) Es el modo más restrictivo de la tabla de bloqueos, permite a la
transacción que tiene el bloqueo exclusivo escrituras en la tabla.
Es adquirido mediante:

LOCK TABLE table IN EXCLUSIVE MODE;

Sólo una transacción puede obtener el bloqueo exclusivo para una tabla. Sólo permite a
otras transacciones hacer consultas (query).
La transacción que obtiene el bloqueo impide a las demás transacciones realizar cualquier
tipo de operaciones de manejo de datos o realizar cualquier tipo de bloqueo.
Share Table Locks (S) Un bloqueo compartido es adquirido automáticamente por la tabla
especificada en la siguiente sentencia.

LOCK TABLE table IN SHARE MODE;

Una transacción que mantiene un bloqueo compartido permite a otras transacciones sólo
consultas a la tabla, bloquear filas específicas con SELECT ... FOR UPDATE, o ejecutar LOCK
TABLE ... IN SHARE MODE. No permite que otras transacciones hagan actualizaciones.
Múltiples transacciones pueden mantener bloqueos compartidos para la tabla.
No permite que otras transacciones modifiquen la tabla que una transacción mantiene
bloqueada por un bloqueo compartido.

LOCK TABLE table IN SHARE ROW EXCLUSIVE MODE;
LOCK TABLE table IN EXCLUSIVE MODE;
LOCK TABLE table IN ROW EXCLUSIVE MODE;

Ejemplo:

set transaction name 'uno';
create table cuenta(id integer primary key,
saldo numeric (7,2) check(saldo>=0.00)
);

LOCK TABLE cuenta IN SHARE MODE;
insert into cuenta values(1,100.00);
insert into cuenta values(2,150.00);
insert into cuenta values(5,175.00);

select * from cuenta;
commit

Facultadde Estadísticae Informática
BASES DE DATOS
AVANZADAS

Facultadde Estadísticae Informática
Clase 5. Repaso Tema Bases de Datos
Distribuidas
▪Tema 2. Bases de Datos Distribuidas (BDD)
▪Definición BDD
▪Componentes del Sistema de Administración de Base de Datos Distribuida
▪Características de SMBD BDD
▪Clasificación de las BDD
▪Características de las BDD (Ventajas, Desventajas)
▪Características de Transparencia en los Sistemas Manejadores de Bases de
Datos Distribuidos (SMBDD)
▪Arquitectura de los sistemas de administración de base de datos
distribuida
▪Diseño de una base de datos distribuidas

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Bibliografía
Bell, David (1992). Distributeddatabasesystems. Wokingham, Eng. : Addison-Wesley.
Connolly, Thomas M. (2005). Sistemas de bases de datos: un enfoque práctico para diseño,
implementaciony gestión. (4ta ed.). Madrid : Pearson Educación Limited.
Date, C. J. (2001). Introducción a los sistemas de bases de datos. (7ma ed.). México: Pearson Educación:
Addison Wesley.
Marqués, M. (2001). Apuntes de ficheros y bases de datos. UniversitatJaume I, Campus de RiuSec.
España. consultado el 13 de noviembre de 2007, en:
http://www3.uji.es/~mmarques/f47/apun/apun.html Si no encuentras el documento, pulsa aquí.
Rob, Peter (2004). Sistemas de bases de datos: diseño, implementación y administración. (5ta ed.).
México, D.F.: Thomson.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Definición
Una Base de Datos Distribuidao por sus siglas en inglés DDB
(DistributedDatabase), la podemos entender como una base de
datos tradicional, dividida en diferentes partes físicamente dispersas
y que se acceden de forma lógica, tal como se accede a una base de
datos centralizada por medio de un Sistema de Administración de
Bases de Datos.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Definición
Un sistema de administración de bases de datos distribuidao por
sus siglas en inglés DDBMS(DistributedDatabaseManagment
System), rige el almacenamiento y procesamiento de datos
lógicamente relacionados a través de sistemas de computadoras
interconectadas en las cuáles, tanto las funciones de datos como de
procesamiento, se distribuyen entre varios sitios (Rob, Peter 2004).

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Componentes del Sistema de Administración de
Base de Datos Distribuida
➢Estaciones de trabajo (sitios y nodos)
➢Componentes de software y hardware
➢Medios de comunicación
➢El procesador de transacciones
➢El procesador de datos

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Características de un SMBD BDD
1.Recibe la solicitud de una aplicación (o de un usuario).
2.Valida, analiza y descompone la solicitud. Operaciones
matemáticas o lógicas, o ambas, tales como, seleccionar
a todos los clientes con saldos de más de $1000. Datos
de una sola tabla, o acceso a varias.
3.Descompone la solicitud en varias operaciones I/O de
disco.
4.Busca, localiza, lee y valida los datos.
5.Garantiza la consistencia, la seguridad y la integridad.
6.Valida los datos de conformidad con las condiciones, si
las hay, especificadas por la solicitud.
7.Presenta los datos seleccionando en el formato
requerido.
8.Todas estas actividades son transparentes para el
usuario.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Clasificación de las BDD
❖Clasificación de Peter Rob(Rob, 2004) los sistemas de
administración de base de datos generalizado.
❖Las BD se clasifican con base en cómo la distribución de los
procesos y datos son soportados: DB centralizada, DB distribuida;
procesamiento de datos en un solo sitio o en varios.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Clasificación de las BDD
DATOS EN UN SOLO
SITIO
DATOS EN SITIOS
MÚLTIPLES
Proceso en un solo sitioUn sólo DBMS anfitrión
No aplicable
(requiere procesos
múltiples)
Proceso en múltiples
sitios
Servidor de archivos
Varios DBMS de LAN
DDBMS Cliente/Servidor
totalmente distribuido

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Clasificación de las
BDD.
Procesamiento en un solo
sitio y datos en un solo
sitio SPSD.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Clasificación de las
BDD.
❖Procesamiento en sitios
múltiples y datos en un
solo sitioMPSD

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Escenario procesamiento en sitios múltiples y
datos en sitios múltiples.
❖Describe un Sistema de administración de base de
datos (SMBDD) totalmente distribuida con soporte
para múltiples procesadores de datos y de
transacciones en diversos sitios.
❖Homogéneas y Heterogéneas

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Procesamiento
en sitios
múltiples y
datos en sitios
múltiples.
❖SMBDD
Homogéneas

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Procesamiento
en sitios
múltiples y
datos en sitios
múltiples.
❖SMBDD
Heterogéneas

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Ventajas de los sistemas de administración de base de
datos distribuida (DDBMS).
1.Los datos se localizan cerca del sitio de "mayor demanda".
2.Acceso más rápido a los datos.
3.Procesamiento más rápido de los datos
4.Facilita el crecimiento
5.Comunicaciones mejoradas
6.Costos de operación reducidos
7.Interface de usuario fácil de usar.
8.Menos peligro de falla en un solo punto
9.Independencia del procesador

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Problemas que se presentan en las bases de
datos distribuidas
i.El rendimiento puede afectarse por la carga de trabajo
ii.La confiabilidad de los sistemas distribuidos, por la complejidad de
los componentes: ordenadores, red, almacenamiento,
transacciones, replicación, etc.
iii.Por mayor complejidad, altos gastos de construcción y
mantenimiento.
iv.Mayor complejidad en el diseño e implementación del sistema.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una
base de datos distribuida

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
La transparencia se puede entender como la
separación de la semántica de alto nivel de un
sistema de los aspectos de bajo nivel relacionados a
la implementación del mismo.
Las características de transparencia del sistema de administración de bases de datos distribuida
(DDBMS) tienen la propiedad común de permitir que el usuario sienta que es el único que está
utilizando la base de datos

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de distribución.
❖Transparencia de transacción.
❖Transparencia de replicación.
❖Transparencia de falla.
❖Transparencia de desempeño.
❖Transparencia de heterogeneidad.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖La transparencia de distribución permite manejar una
base de datos físicamente dispersa como si fuera
centralizada.
❖Se reconocen tres niveles de transparencia de
distribución (Rob, 2004):
❖La transparencia de fragmentación.
❖La transparencia de ubicación.
❖La transparencia de ubicación local.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
Ejemplo:
Tabla EMPLEADOque contiene los atributos:
EMP_NOMBRE, EMP_NAC, EMP_DIR, EMP_DEPy EMP_SALARIO.
Los datos EMPLEADOestán distribuidos en tres lugares: Veracruz,
Monterreyy DF.
La tabla está dividida por ubicación, es decir, todos los datos de los
empleados de Veracruz están guardados en el fragmento E1, los datos
de los empleados de Monterrey en el fragmento E2 y los de DF en el
fragmento E3.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
Listar todos los empleados con fecha de nacimiento
anterior al 1 de enero de 1980.
➢Supongamos que la tabla EMPLEADOestá
fragmentada y que cada fragmento es único (la
condición de fragmento únicoindica que todas las
filas son únicas, sin poner atención en qué fragmento
esté localizado).
➢Ninguna parte de la base de datos está replicada en
algún otro sitio de la red.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
Según el nivel de soporte de la transparencia de
distribución, pueden examinarse tres casos de
consulta:
CASO1:LABASEDEDATOSSOPORTATRANSPARENCIADE
FRAGMENTACIÓN:
SELECT *
FROM EMPLEADO
WHERE EMP_NAC < '01-ENE-1940';

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
CASO 2: LA BASE DE
DATOS SOPORTA
TRANSPARENCIA DE
UBICACIÓN
SELECT *
FROM E1
WHERE EMP_NAC < '01-ENE-1940';
UNION
SELECT *
FROM E2
WHERE EMP_NAC < '01-ENE-1940';
UNION
SELECT *
FROM E3
WHERE EMP_NAC < '01-ENE-1940';

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
CASO 3: LA BASE DE
DATOS SOPORTA
TRANSPARENCIA DE
UBICACIÓN LOCAL
SELECT *
FROM E1 NODE VERACRUZ
WHERE EMP_NAC < '01-ENE-1940';
UNION
SELECT *
FROM E2 NODE MONTERREY
WHERE EMP_NAC < '01-ENE-1940';
UNION
SELECT *
FROM E3 NODE DF
WHERE EMP_NAC < '01-ENE-1940';

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
La transparencia de distribución es soportada
Catálogo de datos distribuidos(DDC, Data
DistributedCatalogpor sus siglas en inglés).
El DDC contiene la descripción de toda la base de
datos tal como la ve su administrador. Está
replicado en los nodos de red, debe mantener
consistencia mediante la actualización en todos los
sitios.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de distribución.
❖Transparencia de transacción.
❖Transparencia de replicación.
❖Transparencia de falla.
❖Transparencia de desempeño.
❖Transparencia de heterogeneidad.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
Latransparencia de transacciónpermite que una
transacción actualice datos en varios sitios de la
red. La transparencia de transacción garantiza que
la transacción se realizará o completada en su
totalidad o abortada, con lo cual se mantiene la
integridad de la base de datos.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
Formato de una transacción:
BEGIN WORK
Selectblablabla
Updateblablabla
Deleteblablabla
COMMIT WORK
Inicio de la transacción
Solicitudes
Fin de la transacción

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖Transacción No Distribuida
❖Transacción Distribuida. Actualiza y solicita
datos de varios sitios remotos en una red.
❖Transacción Remota. Está compuesta de varias
solicitudes remotas y puede acceder datos en
sólo un sitio.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖Solicitud remota:
❖Permite acceder datos que serán
procesados por un sólo procesador de base
de datos remoto.
❖La sentencia o solicitud SQL puede hacer
referencia a datos en un solo sitio remoto.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖Solicitud remota:

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖Transacción remota:
La transacción actualiza las
tablas CLIENTE y FACTURA.
Ambas tablas están en el
sitio B.
La transacción puede hacer
referencia solamente a un
procesador de datos
remoto.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖Transacción remota:
Cada sentencia o solicitud
SQL puede hacer referencia
solamente a un procesador
de datos remoto (el
mismo) a la vez, y toda la
transacción puede hacer
referencia a y ser ejecutada
sólo en un procesador de
datos remoto.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖Transacción distribuidapermite que una transacción
haga referencia a varios sitios de procesamiento de
datos diferentes (locales y remotos).
❖Cada solicitud puede hacer referencia a sólo un sitio
de procesamiento de datos remotos.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖La transacción distribuidacomo un todo puede hacer
referencia a varios sitios de procesamiento de datos,
porque cada solicitud puede hacer referencia a un sitio
diferente.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
¿Qué pasa si la tabla
PRODUCTOestá dividida en
dos fragmentos, PROD1y
PROD2, localizados en los
sitios By C, respectivamente?

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
❖Una solicitud distribuidapermite hacer referencia a
datos de varios sitios de procesamiento de datos
remotos.
❖Proporciona capacidades de procesamiento de base
de datos totalmente distribuida:
❖Dividir una tabla en varios fragmentos.
❖Hacer referencia a uno o más de esos fragmentos solamente con
una solicitud. Se tiene transparencia de fragmentación.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
Solicitud
distribuida

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
¿Y si la tabla CLIENTE está
dividida en dos fragmentos,
C1 y C2, localizados en los
sitios B y C?
¿Si queremos los clientes cuyos
saldos sean de más de $250?

Facultadde Estadísticae Informática
Bases de Datos Distribuidas.
Niveles de transparencia de una base de datos
distribuida
Solicitud
distribuida

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de replicación.
La transparencia de replicación de datos se refiere a que, si
existen copiasde objetos de la base de datos, su existencia
debe ser controlada por el sistema no por el usuario.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de falla.
La transparencia de falla permite que el sistema continúe
operando en el caso de una falla de nodo. Las funciones que
se perdieron a causa de la falla serán recobradas por otro
nodo de la red.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia
de falla y
replicación.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de distribución.
❖Transparencia de transacción.
❖Transparencia de replicación.
❖Transparencia de falla.
❖Transparencia de desempeño.
❖Transparencia de heterogeneidad.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de desempeño.
La transparencia de desempeño permite que cuando los objetos de la base de
datos están fragmentados, el sistema maneja la conversiónde consultas de
usuario definidas sobre relaciones globales a consultas definidas sobre
fragmentos. Así también, mezcla las respuestas a consultas fragmentadas para
obtener una sola respuesta a una consulta global.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
Reducir al mínimo el costo total asociado
con la ejecución de una solicitud.

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
¿Qué costo se desea reducir?

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
Los costos asociados con una solicitud son una función (Rob, 2004):
▪Del costo del tiempo de acceso (E/S) implicado al acceder los datos
físicos guardados en disco.
▪Del costo de comunicaciónasociado con la transmisión de datos
entre nodos en sistemas de base de datos distribuidos.
▪Del costo de tiempo de CPU asociado con la sobrecarga de
procesamientode manejar transacciones distribuidas.

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
La mayoría de los algoritmospropuestos para una
optimización de consultas se basan en dos principios:
▪La selección del orden de ejecución óptimo.
▪La selección de los sitios a ser accedidos para reducir al
mínimo los costos de comunicación.

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
¿Cómo se evalúan los algoritmos de
optimización?

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
Un algoritmo de optimización de consulta puede
ser evaluado con base en su modo de operacióno
en la temporización de su optimización

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
Los modos de operación se clasifican como manuales
o automáticos.
▪Optimización de consulta automática: el DDBMS
localiza la ruta de acceso más barata sin la
intervención del usuario.
▪Optimización de consulta manual: requiere que la
optimización sea seleccionada y programada por el
usuario o programador.

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
Los algoritmos de optimización de consultas
también se clasifican de acuerdo con el momento
en el que se realiza la optimización:
◦Estáticos
◦Dinámicos

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
▪En la optimización de consulta estática, la mejor estrategia de
optimización se selecciona cuando la consulta es compilada por
el DBMS.
▪Cuando el programa se somete para su compilación, crea el
plan necesario para acceder a la base de datos. Cuando se
ejecuta el programa, el DBMS utiliza ese plan para acceder a la
base de datos.

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
▪La optimización de consulta dinámica ocurre en tiempo de
ejecución.
▪La estrategia de acceso a la base de datos se define cuando
se ejecuta el programa.
▪Es eficiente, su costo se mide por sobrecarga de
procesamiento en tiempo de ejecución.

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
¿Cómo se optimizan las
consultas?

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
▪Las técnicas de optimización de consultas se clasifican
de acuerdo con el tipo de información emitida para
optimizar la consulta
▪Basado en estadísticas
▪Basado en reglas

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
▪Basado en estadísticas.
Las estadísticas proporcionan información sobre características de la
base de datos tales como tamaño, número de registros, tiempo de
acceso promedio, número de solicitudes atendidas, número de
usuarios con derechos de acceso, etc.
Posteriormente estas estadísticas son utilizadas por el DBMS para
determinar la mejor estrategia de acceso.

Facultadde Estadísticae Informática
Bases de Datos DistribuidasNivelesde
transparencia de una base de datos
distribuida. Transparencia de desempeño.
❖Optimización de consultas
▪Basado en reglas.
Se basa en un conjunto de reglas definidas por el usuario para
determinar la mejor estrategia de acceso a la consulta.
Las reglas son ingresadas por el usuario o el administrador de la
base de datos, y casi siempre son de naturaleza muy general.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de distribución.
❖Transparencia de transacción.
❖Transparencia de replicación.
❖Transparencia de falla.
❖Transparencia de desempeño.
❖Transparencia de heterogeneidad.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de transparencia de una base de datos
distribuida
❖Transparencia de heterogeneidad.
Latransparencia de heterogeneidadpermite la integración de
varios sistemas de administración de bases de datos locales
diferentes (relacional, de red, jerárquicos, multimedia, etc.)
conforme un esquema global común.

Facultadde Estadísticae Informática
Bases de Datos Distribuidas
Niveles de
transparencia de
una base de datos
distribuida
❖Transparencia de
heterogeneidad.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura de los sistemas de
administración de base de datos
distribuida

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
▪Arquitectura de los sistemas de administración de
base de datos distribuida
▪Arquitectura de los Sistemas Manejadores de Bases
de Datos ANSI-SPARC divide a un sistema en tres
niveles: interno, conceptual y externo.
▪Surgió en 1975, el comité ANSI-SPARC(American
NationalStandard Institute-StandardsPlanningand
RequirementsCommittee) propuso una arquitectura
de tres niveles para los sistemas de bases de datos.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
▪Arquitectura ANSI-
SPARCde los sistemas
de administración de
base de datos (SMBD)

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura ANSI-SPARC de los sistemas de
administración de base de datos
▪En el nivel interno: Describe la estructura física de la base
de datos mediante un esquema interno.
▪Nivel conceptual: Se concentra en describir entidades,
atributos, relaciones, operaciones de los usuarios y
restricciones.
▪Nivel externo: Describe varios esquemas externos o
vistas de usuario.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura ANSI-SPARC de los sistemas de
administración de base de datos
▪Los únicos datos que existen realmente están a nivel
físico, almacenados en un dispositivo como puede ser
un disco.

Facultadde Estadísticae Informática
SISTEMA MANEJADOR DE
BASE DE DATOS
Clase 8. Tema 2. Bases de Datos Distribuidas
(BDD). Arquitectura ANSI-SPARC de los
sistemas de administración de base de datos
Solicitud
Esquema
Externo
(VISTAS)
Esquema
Interno
(FISICO)
Esquema
Conceptual
(RELACIONES)
Base de
datos
correspondencia o transformación

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura ANSI/SPARC de un sistema distribuido
▪Basado en datos. Se identifican los diferentes tipos
de descripción de datos.
▪Define las unidades funcionales que realizarán y/o
usarán los datos de acuerdo con las diferentes vistas.
Este es el enfoque seguido por el modelo
ANSI/SPARC.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura ANSI/SPARC de un sistema distribuido
▪Sistemas de administración de bases de datos distribuidas
homogéneos.
▪Tiene múltiples colecciones de datos.
▪Integra múltiples recursos de datos
▪Se parecen a un sistema centralizado. Datos en varios sitios
comunicados por la red.
▪No existen usuarios locales y todos ellos acceden la base de datos a
través de una interfaz global.
▪El esquema global es la unión de toda las descripciones de datos locales.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura ANSI/SPARC de un sistema distribuido
▪Para manejar los aspectos de la distribución, se deben agregar
dos niveles a la arquitectura estándar ANSI-SPARC:
▪El esquema de fragmentación describe la forma en que las relaciones
globales se dividen entre las bases de datos locales
▪El esquema de asignamientoespecifica el lugar en el cual cada
fragmento es almacenado.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos
Distribuidas (BDD).
Arquitectura ANSI/SPARC de un
sistema distribuido
▪Sistemas de administración de
bases de datos distribuidas
homogéneos.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura ANSI/SPARC de un sistema distribuido
▪Sistemas de administración de bases de datos distribuidas
heterogéneos.
▪Según David Bell (Bell, 1992), se caracterizan por manejar diferentes
sistemas de administración de base de datos (DBMS) en los nodos
locales.
▪Una subclase son los sistemas de administración de multi-bases de
datos.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Arquitectura ANSI/SPARC de un sistema distribuido
▪Sistemas de administración de bases de datos distribuidas
heterogéneos.
▪Un sistema multi-bases de datos (Smulti-BD) tiene múltiples sistemas
manejadores de base de datos, que pueden ser de tipos diferentes y
múltiples bases de datos existentes. La integración de todos ellos se
realiza mediante subsistemas de software.
▪Existen usuarios locales y globales. Los usuarios locales acceden sus
bases de datos locales sin verse afectados por la presencia del sistema
administrador de multi-base de datos.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos
Distribuidas (BDD).
Arquitectura ANSI/SPARC de
un sistema distribuido
▪Sistemas de administración
de bases de datos distribuidas
heterogéneos.

Facultadde Estadísticae Informática
SMBDD homogéneo SMBDD heterogéneo

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
▪Se basa en los principios del diseño de una base de datos
centralizada y contempla los tres puntos siguientes (Marqués,
2001):
i.Diseño conceptual de la base de datos.
ii.Diseño lógico de la base de datos.
iii.Diseño físico de la base de datos
* La ubicación de datos y programas a través de los diferentes sitios de una red
de computadoras.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
i.Diseño físico de la base de datos.
•En el caso de las bases de datos distribuidas se tienen que
considerar adicionalmente los tres problemas siguientes (Rob, 2004):
I.Cómo dividir la base de datos en fragmentos.
II.Qué fragmentos replicar.
III.Dónde localizar estos fragmentos y réplicas.
•La fragmentación y replicación de los datos se ocupa de los dos
primeros problemas, mientras que la colocación de los datos con el
tercero.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
¿Cuáles son los objetivos
del diseño de la
distribución de los datos?

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Objetivos del diseño de la distribución de los datos(Bell, 1992):
✓Procesamiento local.
✓Distribución de la carga de trabajo.
✓Costo de almacenamiento y disponibilidad.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Objetivos del diseño de la distribución de los datos(Bell, 1992):
✓Procesamiento local.
Para maximizar el procesamiento local, colocar los datos tan cerca
como sea posible de las aplicaciones que los utilizan.
En el diseño de la distribución de los datos se puede agregar el
número de referencias locales y remotas que le corresponden a
cada fragmentación candidata y la localización del fragmento, y
de esta forma se seleccione la mejor solución de ellas.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Objetivos del diseño de la distribución de los datos(Bell, 1992):
✓Distribución de la carga de trabajo.
Se realiza para tomar ventaja de las diferentes características
(potenciales) o utilizaciones de las computadoras de cada sitio, y
maximizar el grado de ejecución de paralelismo de las
aplicaciones.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Objetivos del diseño de la distribución de los datos(Bell, 1992):
✓Costo de almacenamiento
Es posible tener sitios especializados en la red para el
almacenamiento de datos.
El costo de almacenamiento de datos no es tan relevante si éste
se compara con el del CPU, I/O y costos de transmisión de las
aplicaciones y disponibilidad.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
El problema de la
fragmentación

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
El problema de la fragmentación.
Se refiere al particionamientode la información para distribuir cada parte en los
diferentes sitios de la red.
El diseño de una base de datos distribuida, cualquiera que sea el enfoque que se
siga, debe responder satisfactoriamente las siguientes preguntas:
a.¿Por qué hacer una fragmentación de datos?
b.¿Cómo realizar la fragmentación?
c.¿Qué tanto se debe fragmentar?
d.¿Cómo probar la validez de una fragmentación?
e.¿Cómo realizar el asignamientode fragmentos?
f.¿Cómo considerar los requerimientos de la información?

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
El problema de la
fragmentación.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
Peter Rob(Rob, 2004), afirma que la fragmentación de los datos
permite dividir un objeto en dos o más segmentos o fragmentos.
Objeto:
▪Base de datos de usuario
▪Base de datos de sistema
▪Una tabla.
Cada fragmento puede guardarse en cualquier sitio en una red de
computadoras.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
La información de la fragmentación de los datos se guarda en un
Catálogo de Datos Distribuidos (DDC, DistributedData Catalog
por sus siglas en inglés), desde donde es accedida por el
procesador de transacciones para procesar las solicitudes de los
usuarios.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
▪Las estrategias de fragmentación de los datos a estudiar, están
basadas a nivel de tabla.
▪La tabla se divide en fragmentos lógicos.
oFragmentación horizontal
oFragmentación vertical
oFragmentación mezclada
Una tabla fragmentada siempre puede recrearse con sus partes
fragmentadas mediante una combinación de uniones y
articulaciones.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
La fragmentación horizontalse refiere a la división de una
relación en subconjunto (fragmentos) de tuplas(filas).
Cada fragmento se guarda en un nodo diferente, y cada uno de
ellos tiene filas únicas.
Todas las filas únicas tienen los mismos atributos (columnas). En
suma, cada fragmento equivale a una sentencia SELECT, con la
cláusula WHERE en un solo atributo.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
La fragmentación verticalse refiere a la división de una
relación en subconjuntos de atributos (columna).
Cada subconjunto (fragmento) se guarda en un nodo diferente, y
cada fragmento tiene columnas únicas, con la excepción de la
columna clave, la cuál es común a todos los fragmentos.
Esto es el equivalente de la sentencia SELECT columna1,
columna2 INTO Nueva_TablaFROM Tabla.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
La fragmentación mezcladase refiere a una combinación
de estrategias horizontales y verticales.
En otras palabras, una tabla puede dividirse en varios
subconjuntos horizontales (filas), y cada una tiene un
subconjunto de los atributos (columnas).

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de
una base de datos
distribuida.
Tabla a fragmentar

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación horizontal de una base de datos distribuida.
Tabla CLIENTE de la compañiaXYZ, ilustrada en la figura. La tabla
contiene los atributos CLI_NUM, CLI_NOM, CLI_DIR, CLI_EST,
CLI_LIM, CLI_BAL, CLI_NIVEL, CLI_DEUDA.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
La fragmentación horizontalse refiere a la división de una
relación en subconjunto (fragmentos) de tuplas(filas).
Cada fragmento se guarda en un nodo diferente, y cada uno de
ellos tiene filas únicas.
Todas las filas únicas tienen los mismos atributos (columnas). En
suma, cada fragmento equivale a una sentencia SELECT, con la
cláusula WHERE en un solo atributo.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación horizontal de una base de datos distribuida.
La CompañiaXYZrequiere información sobre sus clientes en los
tres estados, pero las ubicacionesde la compañía en cada estado
(DF, VE y MY) solamente requieren datos con respecto a clientes
locales.
Con base en esos requerimientos, se decide distribuir los datos
por estado. Por consiguiente, se definen los fragmentos
horizontales de acuerdo con la estructura mostrada en la tabla 1.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación horizontal de una base de datos distribuida.
NOMBRE DEL
FRAGMENTO
UBICACIÓN CONDICIÓN
NOMBRE DEL
NODO
NÚMEROS DE
CLIENTE
NÚMERO DE
REGISTROS
CLI_H1
Distrito
Federal
CLI_EST =
'DF'
DF 1, 3 2
CLI_H2 Nuevo León
CLI_EST =
'NL'
MY 6 1
CLI_H2 Veracruz
CLI_EST =
'VE'
XAL 2, 4, 5 3
Cada fragmento horizontal puede tener un número diferente de filas, pero cada uno de ellos DEBE
tener los mismos atributos. Los fragmentos resultantes producen las tres tablas siguientes.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación horizontal de una base de datos distribuida.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación vertical de una base de datos distribuida.
Tabla CLIENTE de la compañiaXYZ, ilustrada en la figura 1. La
tabla contiene los atributos CLI_NUM, CLI_NOM, CLI_DIR,
CLI_EST, CLI_LIM, CLI_BAL, CLI_NIVEL, CLI_DEUDA.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
La fragmentación verticalse refiere a la división de una
relación en subconjuntos de atributos (columna).
Cada subconjunto (fragmento) se guarda en un nodo diferente, y
cada fragmento tiene columnas únicas, con la excepción de la
columna clave, la cuál es común a todos los fragmentos.
Esto es el equivalente de la sentencia SELECT columna1,
columna2 INTO Nueva_TablaFROM Tabla.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación vertical de una base de datos distribuida.
Supongamos que la compañía está dividida en dos fragmentos, el
de servicioy el de colecciones.
Cada departamento está ubicado en un edificio distinto, y cada
uno tiene interés solamente en unos cuantos de los atributosde
la tabla CLIENTE.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación vertical de una base de datos distribuida.
Cada fragmento vertical debe tener el mismo número de filas,
pero la inclusión de los diferentes atributos depende de la
columna clave.
NOMBRE DEL
FRAGMENTO
UBICACIÓN
NOMBRE
DEL
NODO
NOMBRES DE ATRIBUTO
CLI_V1 Edif. de servicioES
CLI_NUM, CLI_NOM,
CLI_DIR, CLI_EST
CLI_V2 Edif. de colecciónEC
CLI_NUM, CLI_LIM,
CLI_BAL, CLI_NIVEL,
CLI_DEUDA

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación vertical de una base de datos distribuida.
Observemos que el atributo clave (CLI_NUM) es común en
ambos fragmentos CLI_V1 y CLI_V2.
NOMBRE DEL
FRAGMENTO
UBICACIÓN
NOMBRE DEL
NODO
NOMBRES DE ATRIBUTO
CLI_V1 Edif. de servicio ES
CLI_NUM, CLI_NOM,
CLI_DIR, CLI_EST
CLI_V2
Edif. de
colección
EC
CLI_NUM, CLI_LIM,
CLI_BAL, CLI_NIVEL,
CLI_DEUDA

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación
vertical de una
base de datos
distribuida.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación mezclada de una base de datos distribuida.
Tabla CLIENTE de la compañiaXYZ, ilustrada en la figura. La tabla
contiene los atributos CLI_NUM, CLI_NOM, CLI_DIR, CLI_EST,
CLI_LIM, CLI_BAL, CLI_NIVEL, CLI_DEUDA.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación de una base de datos distribuida.
La fragmentación mezcladase refiere a una combinación
de estrategias horizontales y verticales.
En otras palabras, una tabla puede dividirse en varios
subconjuntos horizontales (filas), y cada una tiene un
subconjunto de los atributos (columnas).

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación mezcladade una base de datos distribuida.
La compañía XYZ requiere que los datos CLIENTE se fragmenten
horizontalmentepara acomodar las diferentes ubicaciones de la
compañía; dentro de las ubicaciones, los datos deben ser
fragmentados verticalmentepara acomodar los diferentes
departamentos (servicio y colección).
En suma, la tabla CLIENTE requiere una fragmentación mezclada.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación mezcladade una base de datos distribuida.
La fragmentación mezclada requiere un procedimiento de dos
pasos.
Primero, se introduce la fragmentación horizontal por cada sitio,
con base en la ubicación dentro de un estado (CLI_EST).
La fragmentación horizontal produce los subconjuntos de tuplas
cliente (fragmentos horizontales) localizados en cada sitio.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación mezcladade una base de datos distribuida.
Como los departamentos están localizados en edificios
diferentes; se utiliza una fragmentación vertical dentro de cada
fragmento horizontal para dividir los atributos, con lo cual se
satisfacen las necesidades de información de cada departamento
en cada sub sitio.

Facultadde Estadísticae Informática
Clase 8
Tema 2. Bases de Datos Distribuidas (BDD).
Diseñode una base de datos distribuidas
Fragmentación mezcladade una base de datos distribuida.
NOMBRE DEL
FRAGMENTO
UBICACIÓN
CRITERIOS
HORIZONTALES
NOMBRE DEL
NODO
FILAS
RESULTANTE
S EN EL SITIO
NOMBRES DE ATRIBUTO
CLI_M1 DF-ServicioCLI_EST = 'DF' DF-S 1, 3
CLI_NUM, CLI_NOM, CLI_DIR,
CLI_EST
CLI_M2 DF-ColecciónCLI_EST = 'DF' DF-C 1, 3
CLI_NUM, CLI_LIM, CLI_BAL,
CLI_NIVEL, CLI_DEUDA
CLI_M3 NL-Servicio CLI_EST = 'NL' MY-S 6
CLI_NUM, CLI_NOM, CLI_DIR,
CLI_EST
CLI_M4 NL-ColecciónCLI_EST = 'NL' MY-C 6
CLI_NUM, CLI_LIM, CLI_BAL,
CLI_NIVEL, CLI_DEUDA
CLI_M5 'VE'-ServicioCLI_EST = 'VE' XAL-S 2, 4, 5
CLI_NUM, CLI_NOM, CLI_DIR,
CLI_EST
CLI_M6 'VE'-ColecciónCLI_EST = 'VE' XAL-C 2, 4, 5
CLI_NUM, CLI_LIM, CLI_BAL,
CLI_NIVEL, CLI_DEUDA
Cada fragmento mostrado contiene datos de clientes por estado y, dentro de cada estado, por ubicación de
departamento, para adaptarse a los requerimientos de datos de cada departamento

Facultadde Estadísticae Informática
Fragmentación
mezcladade una
base de datos
distribuida.

¿Cómo surgen las Bases de Datos Distribuidas?
Inician debido a la evolución y crecimiento de las compañías y las necesidades de sus
negocios, aprovechando el desarrollo de la red (Internet), se impulsó la creación del
almacenamiento distribuido de datos.
CONCEPTO.

Es una colección de múltiples bases de datos (es un conjunto de datos relacionados entre
sí), que están conectados entre sí almacenados en varios servidores sobre una red. Estas
bases de datos están lógicamente interrelacionadas. Ejemplos donde se implementan
bases de datos distribuidas aerolíneas, hospitales, bancos, hoteles, entre otros.

Cada uno de los procesadores que integran dicho sistema se conoce con el nombre de
localidad o nodo, y por lo tanto la información va a estar distribuida en las distintas
localidades y no en una sola localidad, que es lo que ocurre con las bases de datos
centralizadas.

Cada localidad tiene una base de datos local aunque la información que se necesite puede
provenir tanto de la base de datos local como de otras localidades, lo que se conoce como
transacciones locales o transacciones globales respectivamente.

Los usuarios acceden a la base de datos distribuida a través de una serie de transacciones:
•Transacciones locales: aquellas que no requieren datos de otras localidades o nodos.
•Transacciones globales: aquellas que si requieren datos de esas otras localidades.

EJEMPLO DE BASES DE DATOS DISTRIBUIDAS

Bases de Datos Centralizadas
Una Base de Datos Centralizada es una base de datos que está físicamente situada en un
único lugar, controlado por una sola computadora.
Esquema De Un Sistema Informático Centralizado:

Desventajas
- Dependencia de los usuarios al departamento central de procesamiento de datos.
- Atrasos en las entregas de los resultados.
- Diferentes prioridades con afectación a usuarios.
- Cuellos de botella.

Datos de
Salida
Datos de
Entrada
Datos de
Entrada
Datos de
Entrada
Datos de
Salida
Datos de
Salida
Departamento 1 Departamento 2 Departamento
N
Base de
Datos
Centro de
Cálculo

Comparación. Bases de Datos Distribuidas vs Bases de Datos Centralizadas.

Bases de Datos Distribuidas Homogéneas.
Son aquellas en la cual todos los sitios tienen idéntico software de sistemas gestores de
bases de datos, son conscientes de la existencia de los demás sitios y acuerdan cooperar
en el procesamiento de las solicitudes de los usuarios. En estos sistemas los sitios locales
renuncian a una parte de su autonomía en cuanto a su derecho a modificar los esquemas
o el software del sistema gestor de bases de datos. Ese software también debe de
cooperar con los demás sitios en el intercambio de la información sobre las transacciones
para hacer posible el procesamiento de las transacciones entre varios sitios.
Bases de Datos Distribuidas Heterogéneas.
Sitios diferentes puede que utilicen esquemas diferentes y diferente software de gestión
de sistemas de bases de datos. Puede que unos sitios no sean conscientes de la existencia
de los demás y puede que solo proporcionen facilidades limitadas para la cooperación en

el procesamiento de las transacciones. Las diferencias en el esquema suelen constituir un
problema importante para el procesamiento de consultas, mientras que la divergencia del
software supone un inconveniente para el procesamiento de las transacciones que tengan
acceso a varios sitios.
¿Cuáles son las ventajas y desventajas de implementar
Bases de Datos Distribuidas?
VENTAJAS
 Compartimiento de datos. Los usuarios de un nodo son capaces de acceder
a los datos de otro nodo. Por ejemplo, desde el Rectorado, se puede
consultar los datos de los alumnos de Informática.
 Autonomía. Cada nodo tiene cierto grado de control sobre sus datos, en un
sistema centralizado, hay un administrador del sistema responsable de los datos
a nivel global. Cada administrador local puede tener un nivel de autonomía
local diferente.
 Disponibilidad. Si en un sistema distribuido falla un nodo, los nodos
restantes pueden seguir funcionando. Si se duplican los datos en varios
nodos, la transacción que necesite un determinado dato puede encontrarlo en
cualquiera de los diferentes nodos.
 Debido a que la información está distribuida en localidades, los resultados a las
consultas se pueden obtener de manera rápida, ágil y fiable.

DESVENTAJAS
 Coste de desarrollo del software. La complejidad añadida que es necesaria para
mantener la coordinación entre nodos hace que el desarrollo de software sea más
costoso.

 Mayor probabilidad de errores. Como los nodos que constituyen el sistema
funcionan en paralelo, es más difícil asegurar el correcto funcionamiento de los
algoritmos, los fallos de parte del sistema, así como la recuperación. Son probables
errores extremadamente sutiles.

 Mayor sobrecarga de procesamiento. El intercambio de mensajes y ejecución de
algoritmos para el mantenimiento de la coordinación entre nodos supone una
sobrecarga que no se da en los sistemas centralizados.

SISTEMA GESTOR DE BASES DE DATOS DISTRIBUIDO

Este sistema está formado por las transacciones y los administradores de la base de
datos distribuidos.
Un SGBDD implica un conjunto de programas que operan en diversas computadoras, estos
programas pueden ser subsistemas de un único SGBDD de un fabricante o podría consistir de una
colección de programas de diferentes fuentes.
El sistema software que permite gestionar la base de datos distribuida y hace que dicha
distribución sea transparente para los usuarios.
Un sistema gestor de bases de datos distribuidas (SGBDD) está compuesto por una única
base de datos lógica dividida en una serie de fragmentos.

Cada fragmento se almacena en una o más computadoras bajo el control de un SGBD
independiente, estando dichas computadoras conectadas mediante una red de
comunicaciones.

TIPOS DE SGBD:

- CLASIFICACION SEGÚN EL MODELO DE DATOS:
 Relacional.
 En red
 Jerárquico
 Orientado a objetos.

- CLASIFICACION SEGÚN EL NUMERO DE USUARIOS:
 Monousuarios.
 Multiusuarios.

- CLASIFICACION SEGÚN EL NUMERO DE SITIOS:
 Centralizado.
 Distribuido.

--CENTRALIZADAS: Las primeras bases de datos centralizadas (década de los 70,80)
toda la base de datos está en un solo computador.
--DISTRIBUIDAS: Los SGBDD surgen a principio de los años 80 como mesclas de las
tecnologías de BD con las redes de comunicaciones y como respuesta y como respuesta a
la necesidad de las grandes empresas de descentralizar los datos (multinacionales con
grandes centros)

Un SGBD Distribuido debe tener, al menos, las siguientes características:
 Una colección de datos compartidos lógicamente relacionados.
 Los datos están divididos en una serie de fragmentos.
 Los fragmentos pueden ser replicados. Y cada fragmento se asigna a distintas
instalaciones.
 Las distintas instalaciones están enlazadas mediante una red de comunicaciones.
 Los datos de cada instalación están bajo el control de un SGBD.
 El SGBD de cada instalación puede gestionar las aplicaciones locales de manera
autónoma.
 Cada SGBD participa en al menos una aplicación global.

EJEMPLO DE SISTEMAS GESTORES DE BASES DE DATOS DISTRIBUIDAS

 MICROSOFT SQL SERVER.
 ORACLE.
 APACHE CASSANDRA.

TRANSPARENCIA DEL SGBD.
 Un SGBDD debe hacer que la distribución sea transparente para el usuario.
 La transparencia oculta al usuario los detalles de implementación.
Hay cuatro tipos principales de transparencia en un SGBDD:
1. Transparencia de distribución: Permite al usuario percibir la base de datos
como una única entidad lógica.
2. Transparencia De Transacciones: Garantiza que todas las transacciones
distribuidas mantengan la integridad y coherencia de la base de datos
distribuida.
3. Transparencia de rendimiento: Requiere que el SGBDD tenga unas prestaciones
equivalentes al caso de que se tratara de un SGBD centralizado. En un entorno
distribuido, el sistema no debe sufrir una degradación de rendimiento debido a
la arquitectura distribuida.
4. Transparencia de SGBD: Oculta el hecho de que los SGBD locales puedan ser
diferentes, por lo que este tipo de transparencia solo es aplicable a los SGBDD
heterogéneos.

ALMACENAMIENTO DISTRIBUIDO DE DATOS.

Considérese una relación r que hay que almacenar en la base de datos. Hay dos enfoques
del almacenamiento de esta relación en la base de datos distribuida:

Réplica. El sistema conserva replicas (copias) idénticas de la relación y guarda cada replica
en un nodo diferente. La alternativa a las replicas es almacenar solo una copia de la
relación r.

Fragmentación. El sistema divide la relación en varios fragmentos y guarda cada
fragmento en un nodo diferente.

La fragmentación y la replica pueden combinarse: las relaciones pueden dividirse en varios
fragmentos y puede haber varias réplicas de cada fragmento.

REPLICACION.
Replicación Completa:
 Mantener una copia completa de la base de datos en cada nodo.
 Localidad de referencia, fiabilidad, disponibilidad y prestaciones se maximizan.
 Costes de almacenamiento y de comunicaciones máximos.
 Uso de instantáneas. Una instantánea es una copia de los datos en un instante
concreto y se actualizan periódicamente.
Replicación Selectiva:
 Combinación de fragmentación, replicación y centralización.
 Algunos elementos de datos se fragmentan para conseguir una alta localidad de
referencia. Otros, que se utilizan en muchos nodos y no se actualizan
frecuentemente, se replican; todos los demás elementos de datos se centralizan.
 El objetivo de esta estrategia es conseguir todas las ventajas de las otras técnicas,
pero sin ninguna de las desventajas.
 Es la estrategia más utilizada, debido a su flexibilidad.

Ventajas y Desventajas de las Réplicas.

 Disponibilidad: si alguno de los sitios que contiene la relación r falla, la relación
puede hallarse en otro nodo distinto. Por tanto, el sistema puede seguir
procesando las consultas que impliquen a r, pese al fallo del nodo.

 Paralelismo Incrementado: en caso de que la mayoría de los accesos a la relación r
solo resulten en la lectura de la relación, varios nodos pueden procesar en paralelo
las lecturas que implique a r. Cuantas mas replicas de r haya, mayor será la
posibilidad de que los datos necesarios se hallen en el sitio en que se ejecuta la
transacción. Por tanto la replica de los datos minimiza el movimiento de los datos
entre los nodos.

 Sobrecarga incrementada durante la actualización: el sistema debe de asegurar
que todas las replicas de la relación r sean consistentes; en caso contrario pueden
producirse cómputos erróneos. Por eso, siempre que se actualiza r, hay que
propagar la actualización a todos los nodos que contienen réplicas. El resultado es
una sobrecarga incrementada. Por ejemplo, en un sistema bancario, en el que se
replica en varios nodos la información de las cuentas, es necesario asegurarse de
que el saldo de cada cuenta concuerde en todos los sitios.

FRAGMENTACION.
El sistema divide la relación en varios fragmentos y guarda cada fragmento en un nodo
diferente.

Reglas para Fragmentar:

1- Completitud. Si una instancia R de una relación se descompone en fragmentos R1,
R2,…, Rn, cada elemento de datos que aparezca en R debe aparecer al menos en un
fragmento. Esta regla es necesaria para garantizar que no haya pérdida de datos
durante la fragmentación.

2- Reconstrucción. Debe ser posible definir una operación relacional que permita
reconstruir la relación R a partir de los fragmentos. Esta regla garantiza que se
preserven las dependencias funcionales.

3- Disyunción. Si un elemento de datos di aparece en el fragmento Ri, no debe aparecer
en ningún otro fragmento. La fragmentación vertical es la excepción a esta regla, ya
que los atributos de clave principal deberán estar repetidos para permitir la
reconstrucción de la relación. Esta regla garantiza una redundancia mínima de datos.

El elemento de datos es: la tupla para la fragmentación horizontal y atributos para la
fragmentación vertical.

TIPOS DE FRAGMENTACION

Fragmentación Horizontal:
 Agrupa las tuplas de una relación que son utilizadas de manera colectiva por las
transacciones de mayor importancia.
 Los fragmentos horizontales se generan especificando un predicado que imponga
una restricción a las tuplas de la relación.

 Dicho predicado se define utilizando la operación de selección del algebra
relacional. La operación de selección agrupa tuplas que tengan alguna propiedad
común.
 Dada una relación R, un fragmento horizontal se define como:
σ p(R) Donde p es un predicado basado en uno o más atributos de la relación.

Ejemplo de fragmentación horizontal:

Tabla inicial de Alumnos.

Fragmentación Horizontal de la Tabla Alumnos.

Fragmentación Vertical:

 Agrupa los atributos de una relación que son utilizados de manera conjunta por las
transacciones de mayor importancia.
 Un fragmento vertical se define utilizando la operación de proyección del algebra
relacional.
 Dada una relación R, un fragmento vertical se define como:
a1….an(R), donde a1,…., an(R) son atributos de la relación R.

Ejemplo de fragmentación vertical:

Fragmentación Mixta:

 Un fragmento mixto está compuesto por un fragmento horizontal que se
fragmenta a continuación verticalmente, o por un fragmento vertical que se
fragmenta a continuación horizontalmente.

 Este tipo de fragmento mixto se define utilizando las operaciones de selección y
proyección del algebra relacional.

Ejemplo fragmentación mixta:

TRANSPARENCIA DE LOS DATOS

Transparencia de la fragmentación. No se exige a los usuarios que conozcan el modo en
que se ha fragmentado la relación.

Transparencia de la réplica. Los usuarios ven cada objeto de datos como lógicamente
único. Puede que el sistema distribuido replique los objetos para incrementar el
rendimiento del sistema o la disponibilidad de los datos. Los usuarios no deben
preocuparse por los objetos que se hayan replicado ni por la ubicación de esas replicas.

Transparencia de la ubicación. No se exige a los usuarios que conozcan la ubicación física
de los datos. El sistema distribuido de bases de datos debe poder hallar los datos siempre
que la transacción del usuario facilite el identificador de los datos.

transacciones Base de datos con SQL SERVER

About This Presentation

Slide Content

Tags

Categories

Download

Quick Actions

Statistics

Related Slideshows

transacciones Base de datos con SQL SERVER

About This Presentation

Slide Content

Slide 1

Slide 2

Slide 3

Slide 4

Slide 5

Slide 6

Slide 7

Slide 8

Slide 9

Slide 10

Slide 11

Slide 12

Slide 13

Slide 14

Slide 15

Slide 16

Slide 17

Slide 18

Slide 19

Slide 20

Slide 21

Slide 22

Slide 23

Slide 24

Slide 25

Slide 26

Slide 27

Slide 28

Slide 29

Slide 30

Slide 31

Slide 32

Slide 33

Slide 34

Slide 35

Slide 36

Slide 37

Slide 38

Slide 39

Slide 40

Slide 41

Slide 42

Slide 43

Slide 44

Slide 45

Slide 46

Slide 47

Slide 48

Slide 49

Slide 50

Slide 51

Slide 52

Slide 53

Slide 54

Slide 55

Slide 56

Slide 57

Slide 58

Slide 59

Slide 60

Slide 61

Slide 62

Slide 63

Slide 64

Slide 65

Slide 66

Slide 67

Slide 68

Slide 69

Slide 70

Slide 71

Slide 72

Slide 73

Slide 74

Slide 75

Slide 76

Slide 77