Tecnológico De Estudios Superiores

Ingeniería en informática
Materia:
Tópicos de base de datos
Actividad:
“Apuntes”

Grupo: 702

Semestre Sep. 2021 – Feb. 2022

1
 Índice

Paginas
1.1 Concepto de base de datos distribuida 3
1.2 Diseño de base de datos distribuidas 5
1.3 Procesamiento de operaciones de actualización distribuidas 10
1.4 Procesamiento de consultas distribuidas 12
1.5 Manejo de transacciones 15

2
1.1 Concepto de base de datos distribuida
Una BDD (Base de Datos Distribuida) es un conjunto de Bases de Datos
relacionadas lógicamente, pero que se encuentran físicamente localizadas en
varios “sitios” de la red.
El soporte completo para las BDD implica que una sola aplicación debe ser capaz

de operar de manera transparente sobre los datos que están dispersos en bases
de datos diferentes, administradas por distintos DBMS, ejecutadas en máquinas
diferentes, manejadas por sistemas operativos diferentes y conectadas a una
variedad de redes de comunicación, donde el término transparente significa que
la aplicación opera desde un punto de vista lógico como sin todos los datos
fueran manejados por un solo DBMS y ejecutados en una sola máquina.

CARACTERÍSTICAS
1. Cuenta con autonomía local: Los sitios distribuidos deben ser
autónomos, es decir que todas las operaciones en un sitio dado se
controlan en ese sitio, pues cuenta con su propio SGBD.
2. Réplicas: Se realizan copias de los datos las cuales se almacenan en
los sitios que las requieren. De esta forma el usuario efectúa
operaciones sobre la réplica.
3. Fragmentación:. Es deseable por razones de desempeño, los datos
pueden almacenarse en la localidad donde se utilizan con mayor
frecuencia de manera que la mayor parte de las operaciones sean solo
locales y se reduzca el tráfico en la red.
4. No dependencia de un sitio central: No debe haber dependencia de
un sitio central para obtener un servicio.

3
5. Transparencia de localización de datos: No debe ser necesario que
los usuarios sepan dónde están almacenados físicamente los datos,
sino que el usuario debe verlo como si solo existiera un sitio local.
6. Manejo distribuido de transacciones: Tiene dos aspectos
principales, el control de recuperación y el control de concurrencia.
7. Independencia con respecto a la red: Se puede leer o escribir datos
localizados en diferentes nodos de la red.
8. Independencia del sistema operativo, hardware y DBMS: Para el
usuario final no importa que los datos estén almacenados en sitios en
los que no se maneje el mismo sistema operativo de su nodo local, el
mismo hardware o DBMS.
9. Dos tipos de transacciones: Locales, cuando se accede a los datos
del único sitio donde se inició la transacción. Globales, cuando se
accede a datos de sitios distintos al sitio donde se inició la transacción

4
 1.2 Diseño de base de datos distribuidas

El problema de diseño de bases de datos distribuidos se refiere, en general, a

hacer decisiones acerca de la ubicación de datos y programas a través de los
diferentes sitios de una red de computadoras. La decisión de donde colocar a las
aplicaciones tiene que ver tanto con el software del SMBDD como con las
aplicaciones que se van a ejecutar sobre la base de datos.
Los pasos a seguir para diseñar una base de datos distribuida:

1. Diseño del “esquema conceptual” el cual describe la base de datos

integrada (esto es, todos los datos que son utilizados por las
aplicaciones que tienen acceso a las bases de datos).
2. Diseño “físico de la base de datos”, esto es, mapear el esquema
conceptual a las áreas de almacenamiento y determinar los métodos
de acceso a las bases de datos.
3. Diseño de la fragmentación, este se determina por la forma en que las
relaciones globales se subdividen en fragmentos horizontales,
verticales o mixtos.
4. Diseño de la asignación de los fragmentos, esto se determina en la
forma en que los fragmentos se mapean a las imágenes físicas, en
esta forma, también se determina la solicitud de fragmentos.

El proceso de diseño

El proceso de diseño consta de los pasos siguientes:

• Determinar la finalidad de la base de datos

Es conveniente plasmar en papel el propósito de la base de datos: cómo piensa

utilizarla y quién va a utilizarla. Para una pequeña base de datos de un negocio
particular, por ejemplo, podría escribir algo tan simple como "La base de datos
de clientes contiene una lista de información de los clientes para el envío masivo
de correo y la generación de informes". Si la base de datos es más compleja o
la utilizan muchas personas, como ocurre normalmente en un entorno
corporativo, la finalidad podría definirse fácilmente en uno o varios párrafos y
debería incluir cuándo y cómo va a utilizar cada persona la base de datos. La
5
 idea es desarrollar una declaración de intenciones bien definida que sirva de
referencia durante todo el proceso de diseño. Esta declaración de intenciones le
permitirá centrarse en los objetivos a la hora de tomar decisiones.

• Buscar y organizar la información necesaria

Para buscar y organizar la información necesaria, empiece con la información

existente. Por ejemplo, si registra los pedidos de compra en un libro contable o
guarda la información de los clientes en formularios en papel en un archivador,
puede reunir esos documentos y enumerar cada tipo de información que
contienen (por ejemplo, cada casilla de un formulario). Si no dispone de
formularios, imagine que tiene que diseñar uno para registrar la información de
los clientes. ¿Qué información incluiría en el formulario? ¿Qué casillas crearía?
Identifique cada uno de estos elementos y cree un listado. Suponga, por ejemplo,
que guarda la lista de clientes en fichas. Cada ficha podría contener un nombre
de cliente, su dirección, ciudad, provincia, código postal y número de teléfono.
Cada uno de estos elementos representa una columna posible de una tabla.

Cuando prepare esta lista, no se preocupe si no es perfecta al principio.

Simplemente, enumere cada elemento que se le ocurra. Si alguien más va a
utilizar la base de datos, pídale también su opinión. Más tarde podrá ajustar la
lista.

• Dividir la información en tablas

Para dividir la información en tablas, elija las entidades o los temas principales.
Por ejemplo, después de buscar y organizar la información de una base de datos
de ventas de productos, la lista preliminar podría ser similar a la siguiente

Las entidades principales mostradas aquí son los productos, los proveedores,
los clientes y los pedidos. Por tanto, parece lógico empezar con estas cuatro
tablas: una para los datos sobre los productos, otra para los datos sobre los
proveedores, otra para los datos sobre los clientes y otra para los datos sobre
los pedidos. Aunque esto no complete la lista, es un buen punto de partida.
Puede seguir ajustando la lista hasta obtener un diseño correcto.

Cuando examine por primera vez la lista preliminar de elementos, podría estar
tentado a incluirlos todos ellos en una sola tabla en lugar de en las cuatro tablas
mostradas en la ilustración anterior. A continuación le explicaremos por qué eso

6
 no es una buena idea. Considere por un momento la tabla que se muestra a
continuación

• Convertir los elementos de información en columnas

Para determinar las columnas de una tabla, decida qué información necesita
registrar sobre el tema representado por la tabla. Por ejemplo, para la tabla
Clientes, una buena lista de columnas iniciales sería Nombre, Dirección, Ciudad-
Provincia-Código postal, Enviar correo electrónico, Saludo y Correo electrónico.
Cada registro de la tabla contiene el mismo número de columnas, por lo que
puede almacenar información sobre el nombre, dirección, ciudad-provincia-
código postal, envío de correo electrónico, saludo y dirección de correo
electrónico para cada registro. Por ejemplo, la columna de dirección podría
contener las direcciones de los clientes. Cada registro contendrá datos sobre un
cliente y el campo de dirección, la dirección de ese cliente.

Cuando haya determinado el conjunto inicial de columnas para cada tabla, puede
ajustar con mayor precisión las columnas. Por ejemplo, tiene sentido almacenar
los nombres de los clientes en dos columnas distintas (el nombre y el apellido)
para poder ordenar, buscar e indizar por esas columnas. De igual forma, la
dirección consta en realidad de cinco componentes distintos: dirección, ciudad,
provincia, código postal y país o región, y parece lógico también almacenarlos
en columnas distintas. Si desea realizar, por ejemplo, una búsqueda o una
operación de ordenación o filtrado por provincia, necesita que la información de
provincia esté almacenada en una columna distinta.

7
• Especificar claves principales

Cada tabla debe incluir una columna o conjunto de columnas que identifiquen
inequívocamente cada fila almacenada en la tabla. Ésta suele ser un número de
identificación exclusivo, como un número de identificador de empleado o un
número de serie. En la terminología de bases de datos, esta información recibe
el nombre de clave principal de la tabla. Access utiliza los campos de clave
principal para asociar rápidamente datos de varias tablas y reunir
automáticamente esos datos.

• Definir relaciones entre las tablas

Examine cada tabla y decida cómo se relacionan los datos de una tabla con las
demás tablas. Agregue campos a las tablas o cree nuevas tablas para clarificar
las relaciones según sea necesario.

• Ajustar el diseño

Analice el diseño para detectar errores. Cree las tablas y agregue algunos
registros con datos de ejemplo. Compruebe si puede obtener los resultados
previstos de las tablas. Realice los ajustes necesarios en el diseño.

• Aplicar las reglas de normalización

Aplique reglas de normalización de los datos para comprobar si las tablas están
estructuradas correctamente. Realice los ajustes necesarios en las tablas.

Consideraciones de diseño de bases de datos distribuidas

En el diseño de las BDD, una cuestión clave es la distribución de los datos. El

encargado de esta tarea es el DBA, el cual establece en tiempo de diseño el
modelo de distribución de los datos. Esta definición es progresiva, de acuerdo a
la evolución de la BD y al modo en que el SGBD resuelve:

• La distribución de las funciones

8
 • La sincronización de las operaciones
• La descomposición de las consultas

Alternativas de diseño

En todo proceso de diseño hay dos aproximaciones básicas [2]:

• La ascendente o Top-Down.
• La descendente o Bottom-Up.

El diseño ascendente se utiliza, cuando se crea un BDD a partir de varias BBDD

locales existentes. Se parte de varios esquemas lógicos locales (ELL) con
ubicaciones diferentes que se integran en un único esquema lógico global
(ELG).

El diseño descendente parte de un ELG y construye varios ELL definidos a

partir de esquemas de fragmentación, asignación y replicación que determinan
la distribución de los datos en los distintos nodos de la red.

1.3 Procesamiento de operaciones de actualización distribuidas

Los sistemas cliente/servidor involucran varias computadoras conectadas a una
red. Las computadoras que procesan programas de aplicaciones se conocen
como clientes y las que procesan bases de datos se conocen como servidor.
ARQUITECTURA CLIENTE SERVIDOR
Un sistema cliente servidor puede tener varios servidores de procesamiento de
bases de datos, cuando esto ocurre cada servidor debe procesar una base de
datos distinta. Cuando dos o más servidores procesan una misma base de datos,
el sistema no es considerado cliente servidor, más bien, es conocido como
sistema de base de datos distribuido.
Funciones del cliente:
• Administrar la interfaz de usuario.
• Aceptar datos del usuario.
• Procesar la lógica de la aplicación.
• Generar las solicitudes para la base de datos.
• Trasmitir las solicitudes de la base de datos al servidor.
• Recibir los resultados del servidor.
• Dar formatos a los resultados.
Funciones del servidor:
9
 • Aceptar las solicitudes de la base de datos de los clientes.
• Procesar las solicitudes de los clientes.
• Dar formato a los resultados y trasmitirlos al cliente.
• Llevar a cabo la verificación de integridad.
• Mantener los datos generales de la base de datos.
• Proporcionar control de acceso concurrente.
• Llevar a cabo la recuperación.
• Optimizar el procesamiento de consulta/actualización
Una transacción es una unidad lógica de trabajo, la cual no necesariamente
consta de una sola operación en la base de datos; más bien, es en general una
secuencia de varias de esas operaciones mediante la cual un estado consistente
de la base de datos se transforma en otro estado consistente, sin conservar por
fuerza la consistencia en todos los puntos intermedios. El punto importante aquí
es asegurar que la base de datos regresa a un estado consistente al fin de la
ejecución de una transacción. Una transacción es también la invocación a un
procedimiento remoto (RPC) que ejecuta un conjunto de operaciones sobre una
base de datos bajo el principio de todo o nada.
El concepto fundamental aquí es la noción de “ejecución consistente” o
“procesamiento confiable” asociada con el concepto de una consulta. El
concepto transacción es usado dentro del dominio de la base de datos como una
unidad básica de cómputo consistente y confiable.
Mecanismos de recuperación
A fin de soportar una respuesta favorable para la ejecución de transacciones, el
DBMS (Sistema Manejador de Bases de Datos) deberá de manejar el
procesamiento de transacciones. Esto es, deberá de garantizar que si la
transacción ejecuta algunas modificaciones y después se presenta una falla (por
cualquier razón), antes de que llegue al término normal de la transacción, se
anularán esas modificaciones. Así, o bien se lleva a cabo la transacción en su
totalidad, o se cancela en su totalidad. De esta manera puede lograrse que una
secuencia de operaciones, la cual en esencia no es atómica, aparente serlo
desde un punto de vista externo. El componente del sistema encargado de lograr
esta apariencia de atomicidad se conoce como Manejador de transacciones, y
las operaciones de COMMIT (comprometer) y ROLLBACK (retroceder) son la
clave de su funcionamiento.
La operación COMMIT señala el término exitoso de la transacción: le dice al
manejador de transacciones que se ha finalizado con éxito una unidad lógica de
trabajo, que la base de datos esta (o debería estar) de nuevo en un estado
consistente, y que se pueden hacer permanentes todas las modificaciones
efectuadas por esa unidad de trabajo.

10
1.4 Procesamiento de consultas distribuidas

Las consultas distribuidas detienen acceso a datos de varios orígenes de datos

heterogéneos. Estos orígenes de datos pueden estar almacenados en el mismo
equipo o en equipos diferentes.

El procesamiento de consultas tiene varias etapas a seguir para resolver una

consulta SQL, las características del modelo relacional permiten
quecada motor de base de datos elija
su propia representación que,comúnmente, resulta ser el álgebra relacional
.Existen varios medios para calcular la respuesta a una consulta. En el caso
del sistema centralizado, el criterio principal para determinar el costo de una
estrategia específica es el número de acceso al disco. En un sistema distribuido
es preciso tener en cuenta otros factores como son:

• El costo de transmisión de datos en la red.

• Repetición y fragmentación.
• Procesamiento de intersección simple.

ARBOLES DE CONSULTAS

Pasos:

• Parsing y traducción de la consulta

• Optimización
• Generación de código
• Ejecución de la consulta

TRANSFORMACIONES EQUIVALENTES

Cuando una base de datos se encuentra en múltiples servidores ydistribuye a

un número determinado de nodos tenemos:
11
 1. El servidor recibe una petición de un nodo.
2. El servidor es atacado por el acceso concurrente a la base de datos
cargada localmente.
3. El servidor muestra un resultado y le da un hilo a cada una de
las maquinas nodo de la red local.

Cuando una base de datos es acezada de esta manera la técnica que se utiliza
es la de fragmentación de datos que puede ser hibrida, horizontal y vertical.

En esta fragmentación lo que no se quiere es perder la consistencia delos datos,

por lo tanto se respetan las formas normales de la base de datos.

Bueno para realizar una transformación en la consulta primero desfragmentam

os siguiendo los estándares marcados por las reglas formales y posteriormente
realizamos el envió y la maquina que recibe es la que muestra el resultado
pertinente para el usuario, de esta se puede producir una copia que será

la equivalente a la original.

Existen diferentes algoritmos que pueden obtener transformacioneseficientes en

el procesamiento de consultas.

Join en bucles (ciclos) anidados

Si z = r s, r recibirá el nombre de relación externa y s se llamará relación interna,

el algoritmo de bucles anidados se puede presentar como sigue:

Para cada tupla tr en s si (tr,ts) si satisface la condición, entonces añadir tr * ts al

resultado Donde tr * ts será la concatenación de las tuplas tr y ts. Como para
cada registro de r se tiene que realizar una exploración completa de ts, y
suponiendo el peor caso, en el cual la memoria intermedia sólo puede
concatenar un bloque de cada relación, entonces el número de bloques a
acceder es de sr bn b. Por otro lado, en el mejor de los casos si se pueden
12
contener ambas relaciones en la memoria intermedia entonces sólo se
necesitarían accesos a bloques.

Join en bucles anidados por bloques

Una variante del algoritmo anterior puede lograr un ahorro en el acceso a

bloques, si se procesan las relaciones por bloques en vez de por tuplas. Para
cada bloque Br dar a igual para cada bloque Bs de s, para cada tupla tr en Br.

La diferencia principal en costos de este algoritmo con el anterior es que en el

peor de los casos cada bloque de la relación interna s se lee una vez por cada
bloque de dr y no por cada tupla de la relación externa.

Join por mezcla

Este algoritmo se puede utilizar para calcular si un Join natural es óptimo en la

búsqueda o consulta. Para tales efectos, ambas relaciones deben estar
ordenadas para los atributos en común es decir se asocia un puntero a cada
relación, al principio estos punteros apuntan al inicio de cada una de las
relaciones. Según avance el algoritmo el puntero se mueve a través de la
relación. De este modo se leen en memoria un grupo de tuplas de una relación
con el mismo valor en los atributos de las relaciones.

¿Qué se debe de tomar en cuenta en este algoritmo?

• Se tiene que ordenar primero, para después utilizar este método.

• Se tiene que considerar el costo de ordenarlo / las relaciones.
• Es más fácil utilizar pequeñas tuplas.

Join por asociación.

Al igual que el algoritmo de join por mezcla, el algoritmo de join por asociación
se puede utilizar para un Join natural o un equi-join. Este algoritmo utiliza una
función de asociación h para dividir las tuplas de ambas relaciones. La idea
fundamental es dividir las tuplas de cada relación en conjuntos con el mismo
valor de la función de asociación en los atributos de join.

El número de bloques ocupados por las particiones podría ser ligeramente mayor
que.

Debido a que los bloques no están completamente llenos. El acceso a estos

bloques puede añadir un gasto adicional de 2·max a lo sumo, ya que cada una
de las particiones podría tener un bloque parcialmente ocupado que se tiene que
leer y escribir de nuevo.

Join por asociación híbrida

El algoritmo de join por asociación híbrida realiza otra optimización; es útil

cuando el tamaño de la memoria es relativamente grande paro aún así, no cabe

13
toda la relación s en memoria. Dado que el algoritmo de join por asociación
necesita max +1 bloques de memoria para dividir ambas relaciones se puede
utilizar el resto de la memoria (M – max – 1 bloques)para guardar en la memoria
intermedia la primera partición de la relación s, esto es, así no es necesaria leerla
ni escribirla nuevamente y se puede construir un índice asociativo.

Cuando r se divide, las tuplas de tampoco se escriben en disco; en su lugar,

según se van generando, el sistema las utiliza para examinar el índice asociativo
en y así generar las tuplas de salida del join. Después de utilizarlas, estas tuplas
se descartan, así que la partición no ocupa espacio en memoria. De este modo
se ahorra un acceso de lectura y uno de escritura para cada bloque de y.

Join Complejos

Los join en bucle anidado y en bucle anidado por bloques son útiles siempre, sin
embargo, las otras técnicas de join son más eficientes que estas, pero sólo se
pueden utilizar en condiciones particulares tales como join natural o equi-join. Se
pueden implementar join con condiciones más complejas tales como conjunción
o disyunción Dado un join de las forma se pueden aplicar una o más de las
técnicas de join descritas anteriormente en cada condición individual, el
resultado total consiste en las tuplas del resultado intermedio que satisfacen el
resto de las condiciones. Estas condiciones se pueden ir comprobado según se
generen las tuplas. La implementación de la disyunción es homóloga a la
conjunción.

Outer Join (Join externos)

Un outer join es una extensión del operador join que se utiliza a menudo para
trabajar con la información que falta.

Por ejemplo:

Suponiendo que se desea generar una lista con todos los choferes y los autos
que manejan (si manejan alguno) entonces se debe cruzar la relación Chofer con
la relación Móvil. Si se efectúa un join corriente se perderán todas aquellas tuplas
que pertenecen a los choferes, en cambio con un outer join se pueden desplegar
las tuplas resultado incluyendo a aquellos choferes que no tengan a cargo un
auto.

El outer join tiene tres formas distintas: por la izquierda, por la derecha y
completo. El join por la izquierda ( ) toma todas las tuplas de la relación de la
izquierda que no coincidan con ninguna tupla de la relación de la derecha, las
rellena con valores nulos en los demás atributos de la relación de la derecha y
las añade al resultado del join natural.

Un outer join por la derecha ( ) es análogo al procedimiento anterior y el outer

join completo es aquel que efectúa ambas operaciones.

14
 Para el caso de un outer join completo se puede calcular mediante extensiones
de los algoritmos de join por mezcla y join por asociación.

1.5 Manejo de transacciones

Se considera el manejo de transacciones cuando un dispositivo móvil inicia una
transacción hacia la base de datos o hacia un servidor fijo. La transacción puede
ejecutarse en el servidor o en el dispositivo móvil.
Se debe tomar en cuenta: Desconexiones, movilidad, errores, fallas en el
dispositivo móvil.
Se debe mantener la autonomía y la consistencia local del SMBD.
Los algoritmos dependen de:
Si el dispositivo está ejecutando la transacción (no, solo lectura, lectura y
escritura)
Si se almacenaron los datos en disco.
Si el dispositivo móvil necesita datos que se encuentran en otros dispositivos
móviles.
Hasta este momento, las primitivas básicas de acceso que se han considerado
son las consultas (queries). Sin embargo, no se ha discutido qué pasa cuando,
por ejemplo, dos consultas tratan de actualizar el mismo elemento de datos, o si
ocurre una falla del sistema durante la ejecución de una consulta. Dada la
naturaleza de una consulta, de lectura o actualización, a veces no se puede
simplemente reactivar la ejecución de una consulta, puesto que algunos datos
pueden haber sido modificados antes la falla. El no tomar en cuenta esos
factores puede conducir a que la información en la base de datos contenga datos
incorrectos.
El concepto fundamental aquí es la noción de “ejecución consistente” o
“procesamiento confiable” asociada con el concepto de una consulta. El
concepto de una transacción es usado dentro del dominio de la base de datos
como una unidad básica de cómputo consistente y confiable.
DEFINICIÓN DE UNA TRANSACCIÓN
Una transacción es una colección de acciones que hacen transformaciones
consistentes de los estados de un sistema preservando la consistencia del
sistema. Una base de datos está en un estado consistente si obedece todas las
restricciones de integridad definidas sobre ella. Los cambios de estado ocurren
debido a actualizaciones, inserciones, y supresiones de información. Por
supuesto, se quiere asegurar que la base de datos nunca entra en un estado de
inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de
datos puede estar temporalmente en un estado inconsistente. El punto

15
importante aquí es asegurar que la base de datos regresa a un estado
consistente al fin de la ejecución de una transacción.
Lo que se persigue con el manejo de transacciones es por un lado tener una
transparencia adecuada de las acciones concurrentes a una base de datos y por
otro lado tener una transparencia adecuada en el manejo de las fallas que se
pueden presentar en una base de datos.
Condiciones de terminación de una transacción
Una transacción siempre termina, aun en la presencia de fallas. Si una
transacción termina de manera exitosa se dice que la transacción hace un
commit (se usará el término en inglés cuando no exista un término en español
que refleje con brevedad el sentido del término en inglés). Si la transacción se
detiene sin terminar su tarea, se dice que la transacción aborta. Cuando la
transacción es abortada, su ejecución es detenida y todas sus acciones
ejecutadas hasta el momento son deshechas (undone) regresando a la base de
datos al estado antes de su ejecución. A esta operación también se le conoce
como rollback.
CARACTERIZACIÓN DE TRANSACCIONES
Observe que en el ejemplo anterior las transacciones leen y escriben datos.
Estas acciones se utilizan como base para caracterizar a las transacciones. Los
elementos de datos que lee una transacción se dice que constituyen el conjunto
de lectura (RS). Similarmente, los elementos de datos que una transacción
escribe se les denomina el conjunto de escritura (WS). Note que los conjuntos
de lectura y escritura no tienen que ser necesariamente disjuntos. La unión de
ambos conjuntos se le conoce como el conjunto base de la transacción (BS =
RS U WS).
Los conjuntos de lectura y escritura de la transacción del Ejemplo 3 son:
RS[Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP }

WS[Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME,

FC.SPECIAL }
PROPIEDADES DE LAS TRANSACCIONES
La discusión en la sección previa clarifica el concepto de transacción. Sin
embargo, aun no se ha dado ninguna justificación para afirmar que las
transacciones son unidades de procesamiento consistentes y confiables. Las
propiedades de una transacción son las siguientes:
Atomicidad. Se refiere al hecho de que una transacción se trata como una unidad
de operación. Por lo tanto, o todas las acciones de la transacción se realizan o
ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transacción

16
se interrumpe por una falla, sus resultados parciales deben ser deshechos. La
actividad referente a preservar la atomicidad de transacciones en presencia de
abortos debido a errores de entrada, sobrecarga del sistema o interbloqueos se
le llama recuperación de transacciones. La actividad de asegurar la atomicidad
en presencia de caídas del sistema se le llama recuperación de caídas.
Consistencia. La consistencia de una transacción es simplemente su correctitud.
En otras palabras, una transacción es un programa correcto que lleva la base de
datos de un estado consistente a otro con la misma característica. Debido a esto,
las transacciones no violan las restricciones de integridad de una base de datos.
Aislamiento. Una transacción en ejecución no puede revelar sus resultados a
otras transacciones concurrentes antes de su commit. Más aún, si varias
transacciones se ejecutan concurrentemente, los resultados deben ser los
mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad).
Durabilidad. Es la propiedad de las transacciones que asegura que una vez que
una transacción hace su commit, sus resultados son permanentes y no pueden
ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los
resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad
motiva el aspecto de recuperación de bases de datos, el cual trata sobre como
recuperar la base de datos a un estado consistente en donde todas las acciones
que han hecho un commit queden reflejadas.
Las transacciones proporcionan una ejecución atómica y confiable en presencia
de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y
un manejo correcto de réplicas (en el caso de que se soporten).
TIPOS DE TRANSACCIONES
Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas
fundamentales son los mismos para las diferentes clases, los algoritmos y
técnicas que se usan para tratarlas pueden ser considerablemente diferentes.
Las transacciones pueden ser agrupadas a lo largo de las siguientes
dimensiones:
Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar en
aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos
se les conoce como transacciones distribuidas. Por otro lado, dado que los
resultados de una transacción que realiza un commit son durables, la única forma
de deshacer los efectos de una transacción con commit es mediante otra
transacción. A este tipo de transacciones se les conoce como transacciones
compensatorias. Finalmente, en ambientes heterogéneos se presentan
transacciones heterogéneas sobre los datos.
Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se
inicia una transacción hasta que se realiza un commit o se aborta, las
transacciones pueden ser de tipo batch o en línea. Estas se pueden diferencias
también como transacciones de corta y larga vida. Las transacciones en línea se
17
caracterizan por tiempos de respuesta muy cortos y por accesar un porción
relativamente pequeña de la base de datos. Por otro lado, las transacciones de
tipo batch toman tiempos relativamente largos y accesan grandes porciones de
la base de datos.
Estructura. Considerando la estructura que puede tener una transacción se
examinan dos aspectos: si una transacción puede contener a su vez
subtransacciones o el orden de las acciones de lectura y escritura dentro de una
transacción.
ESTRUCTURA DE TRANSACCIONES
Las transacciones planas consisten de una secuencia de operaciones primitivas
encerradas entre las palabras clave begin y end.
En las transacciones anidadas las operaciones de una transacción pueden ser
así mismo transacciones.
Una transacción anidada dentro de otra transacción conserva las mismas
propiedades que la de sus padres, esto implica, que puede contener así mismo
transacciones dentro de ella. Existen restricciones obvias en una transacción
anidada: debe empezar después que su padre y debe terminar antes que él. Más
aún, el commit de una subtransacción es condicional al commit de su padre, en
otras palabras, si el padre de una o varias transacciones aborta, las
subtransacciones hijas también serán abortadas.
Las transacciones anidadas proporcionan un nivel más alto de concurrencia
entre transacciones. Ya que una transacción consiste de varios transacciones,
es posible tener más concurrencia dentro de una sola transacción. Así también,
es posible recuperarse de fallas de manera independiente de cada
subtransacción. Esto limita el daño a un parte más pequeña de la transacción,
haciendo que costo de la recuperación sea menor.
En el segundo punto de vista se considera el orden de las lecturas y escrituras.
Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna
restricción, entonces, a este tipo de transacciones se les conoce como
generales. En contraste, si se restringe o impone que un dato deber ser leído
antes de que pueda ser escrito entonces se tendrán transacciones restringidas.
Si las transacciones son restringidas a que todas las acciones de lectura se
realicen antes de las acciones de escritura entonces se les conoce como de dos
pasos. Finalmente, existe un modelo de acción para transacciones restringidas
en donde se aplica aún más la restricción de que cada par <read,write> tiene
que ser ejecutado de manera atómica.
ASPECTOS RELACIONADOS AL PROCESAMIENTO DE TRANSACCIONES
Los siguientes son los aspectos más importantes relacionados con el
procesamiento de transacciones:

18
Modelo de estructura de transacciones. Es importante considerar si las
transacciones son planas o pueden estar anidadas.
Consistencia de la base de datos interna. Los algoritmos de control de datos
semántico tienen que satisfacer siempre las restricciones de integridad cuando
una transacción pretende hacer un commit.
Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir
medios de comunicación entre los diferentes nodos de una red para garantizar
la atomicidad y durabilidad de las transacciones. Así también, se requieren
protocolos para la recuperación local y para efectuar los compromisos (commit)
globales.
Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia
deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de
correctitud. La consistencia entre transacciones se garantiza mediante el
aislamiento de las mismas.
Protocolos de control de réplicas. El control de réplicas se refiere a cómo
garantizar la consistencia mutua de datos replicados. Por ejemplo se puede
seguir la estrategia read-one-write-all (ROWA).

19