1.

Sistema manejador de base de datos (SMBD)

Es un conjunto de programas que se encargan de manejar la creación y todos los accesos a las bases
de datos. Su función es servir de interfaz entre la base de datos, el usuario y las distintas
aplicaciones utilizadas. El objetivo es el de manejar un conjunto de datos para convertirlos en
información relevante para la organización, ya sea a nivel operativo o estratégico.

Manejo de memoria
Una de las principales tareas de un SMBD es minimizar las operaciones de lectura y escritura del
disco ya que esto consume muchos recursos, por esta razón cada SMBD posee una arquitectura de
memoria definida, donde su funcionamiento permite la administración de memoria utilizando
diversas opciones y herramientas.

Manejo de memoria principal

La memoria principal constituye el medio de almacenamiento para el proceso de los datos
disponibles para las operaciones requeridas por el usuario. Se compone de un conjunto de celdas
básicas dotadas de una determinada organización. Cada celda soporta un bit de información. Los
bits se agrupan en unidades direccionales denominadas palabras. La longitud de palabra la
determina el número de bits que la componen y constituye la resolución de la memoria. La longitud
de palabra suele oscilar desde 8 bits hasta 64 bits.

Manejo de memoria secundaria

A diferencia de la memoria principal, la memoria secundaria no es tan veloz pero tiene gran
capacidad para almacenar información en dispositivos tales como discos, cintas magnéticas, discos
ópticos. Frecuentemente los datos y programas se graban en la memoria secundaria, de esta forma,
cuando se ejecutan varias veces un programa o se utilicen repetidamente unos datos, no es necesario
darlos de nuevo a través del dispositivo de entrada. Un sistema de almacenamiento secundario es
necesario ya que la memoria principal es volátil y además muy pequeña para almacenar todos los
programas y datos.

2. Organización de Archivos
Se refiere a la estructura física de un archivo sobre el disco. Los tres métodos de organización de
archivos disponibles son: secuencial, directo e indexado.

Archivos secuenciales
Es la forma básica de organizar un conjunto de registros, que forman un archivo, utilizando una
organización secuencial. En un archivo organizado secuencialmente, los registros quedan grabados
consecutivamente cuando el archivo se utiliza como entrada. En la mayoría de los casos, los
registros de un archivo secuencial quedan ordenados de acuerdo con el valor de algún campo de
cada registro.

Archivo secuencial indexado

 Los registros se organizan en una secuencia basada en un campo clave presentando dos
características, un índice del archivo para soportar los accesos aleatorios y un archivo del
desbordamiento. El índice proporciona una capacidad de búsqueda para llegar rápidamente al
registro deseado y el archivo de desbordamiento es similar al archivo de registros usado en un
archivo secuencial, pero está integrado de forma que los archivos de desbordamiento se ubiquen
siguiendo un puntero desde su registro predecesor.

Archivo de acceso directo

Un archivo directo consiste en una colección de registros de longitud fija almacenados uno al lado
del otro en un dispositivo de almacenamiento de acceso directo. El almacenamiento de este tipo de
archivos se hace generalmente en orden aleatorio. Cada registro en un archivo de organización
directa hace referencia por un número entero de dirección, el cual indica su distancia o
desplazamiento desde el origen del archivo. Al primer registro en un archivo relativo se le asigna el
valor 1, 2 al siguiente y así sucesivamente. De este modo, la dirección relativa de un valor entero
que refleja su posición respecto al primer registro del archivo.

Otras Organizaciones
Método Hashing
Son similares a las de direccionamiento por clave en que la fórmula es aplicada a un campo del
registro (usualmente la clave primaria) teniendo como resultado un valor usado como la dirección
en disco para almacenar ese registro. La diferencia es que las técnicas hashing no garantizan una
dirección de almacenamiento única. La fórmula puede producir dos o más registros con el mismo
valor resultante.
Organización aleatoria indexada
En este tipo de organización los registros en el archivo de datos están almacenados de manera
aleatoria y en el archivo índice existe una entrada porcada registro lógico existente en el archivo de
datos (este tipo de archivo índice se conoce como archivo denso) almacenados según el orden de la
clave primaria.
Organización indexada secuencial
En este tipo de organización los registros en el archivo de datos están almacenados según la
secuencia de la clave primaria. Siendo así a nivel del archivo índice sólo se necesita una entrada o
un registro por cada página del archivo de datos (índice no denso) correspondiente al registro que
tenga el mayor o el menor valor de clave primaria en la página del archivo de datos.
Ejemplos de modelos internos de diferentes SMBD comerciales
 SMBD de código abierto MySQL: Es un sistema gestor de bases de datos que se puede encuadrar
dentro de la categoría de los programas open-source. Aparte de las características que definen
MySQL como programa open-source, existen aspectos que lo diferencian de otros productos como,
por citar uno conocido, Access. Los atributos a los que hacemos referencia son: Posibilidad de crear
y configurar usuarios, asignando a cada uno de ellos permisos diferentes. Facilidad de exportación e
 importación de datos, incluso de la base de datos completa. Posibilidad de ejecutar conjuntos de
instrucciones guardadas en ficheros externos a la base de datos.
 SQLITE: A diferencia del sistema de gestión de bases de datos cliente- servidor, el motor de
SQLite no es un proceso independiente con el que el programa principal se comunica. En lugar de
eso, la biblioteca SQLite se enlaza con el programa pasando a ser parte integral del mismo. El
programa utiliza la funcionalidad de SQLite a través de llamadas simples a subrutinas y funciones.
Esto reduce la latencia en el acceso a la base de datos, debido a que las llamadas a funciones son
más eficientes que la comunicación entre procesos. El conjunto de la base de datos (definiciones,
tablas, índices, y los propios datos), son guardados como un sólo fichero estándar en la máquina
host.

3. Restauración
Transacción como unidad de trabajo y recuperación
Una transacción es una secuencia de operaciones que llevan la base de datos desde un estado de
consistencia1 a otro estado de consistencia, por esto suele decirse también que la transacción es una
unidad lógica de integridad.
Cuando múltiples transacciones son introducidas en el sistema por varios usuarios, es necesario
evitar que interfieran entre ellas de forma tal que provoquen que la BD quede en un estado no
consistente; desde este punto de vista, podemos ver una transacción como una unidad lógica de
concurrencia.
Cuando ocurre un fallo que provoca la caída del sistema, en el momento en el que había varias
transacciones en curso de ejecución, muy probablemente dejará erróneos los datos en la BD (estado
inconsistente); en estas circunstancias, se debe garantizar que la BD pueda ser recuperada a un
estado en el cual su contenido sea consistente, por esto una transacción es considerada también una
unidad lógica de recuperación.
La idea clave es que una transacción debe ser atómica, es decir, las operaciones que la componen
deben ser ejecutadas en su totalidad o no ser ejecutadas en absoluto.
El Subsistema de Recuperación del SGBD es el encargado de conseguir el cumplimiento de las
propiedades de atomicidad y durabilidad de las transacciones. Para hacer posible el control de la
concurrencia de las transacciones, así como la recuperación del sistema tras fallos o caídas del
mismo, es necesario almacenar cuándo se inicia, termina, se confirma o se aborta cada transacción,
y además qué modificaciones de qué elementos de BD realiza cada una.
Cuando la transacción finaliza, pasa al estado PARCIALMENTE CONFIRMADA. En este punto,
el Subsistema de Control de Concurrencia puede efectuar verificaciones para asegurar que la
transacción no interfiera con otras transacciones en ejecución. Además, el Subsistema de
Recuperación puede anotar qué operaciones (qué cambios) ha realizado que la transacción en un
fichero del sistema (bitácora3), con el objetivo de garantizar que los cambios realizados por la
transacción terminada queden permanentes, a pesar de fallos del sistema.
Las transacciones fallidas (abortadas) pueden ser reiniciadas posteriormente, ya sea de forma
automática por parte del sistema, o bien sea el usuario el que las reintroduzca como si fueran nuevas
transacciones.

Operaciones para controlar y manejar transacciones

Una transacción, para cumplir con su propósito y protegernos de todos los problemas que hemos
visto, debe presentar las siguientes características:
 Atomicidad: las operaciones que componen una transacción deben considerarse como una
sola.
 Consistencia: una operación nunca deberá dejar datos inconsistentes.
 Aislamiento: los datos "sucios" deben estar aislados, y evitar que los usuarios utilicen
información que aún no está confirmada o validada. (por ejemplo: ¿sigue siendo válido el
saldo mientras realizo la operación?)
 Durabilidad: una vez completada la transacción los datos actualizados ya serán permanentes
y confirmados.
A estas propiedades se las suele conocer como propiedades ACID (de sus siglas en inglés:
Atomicity, Consistency, Isolation y Durability).
Por regla general en los gestores de datos relacionales modernos disponemos de tres tipos de
transacciones según la forma de iniciarlas:
 De confirmación automática: el gestor de datos inicia una transacción automáticamente por
cada operación que actualice datos. De este modo mantiene siempre la consistencia de la
base de datos, aunque puede generar bloqueos.
 Implícitas: cuando el gestor de datos comienza una transacción automáticamente cada vez
que se produce una actualización de datos, pero el que dicha transacción se confirme o se
deshaga, lo debe indicar el programador.
 Explícitas: son las que iniciamos nosotros "a mano" mediante instrucciones SQ. somos
nosotros, los programadores, los que indicamos qué operacio0nes va a abarcar.
Una transacción explícita se define de manera general con una instrucción que marca su inicio, y
dos posibles instrucciones que marcan su final en función de si debe tener éxito o debe fracasar en
bloque.
Cada sistema gestor de bases de datos tiene sus pequeñas particularidades, pero podemos escribir
con un pseudo-código, la sintaxis de una transacción genérica:

BEGIN TRAN
Operación 1...
Si fallo: ROLLBACK TRAN
Operación 2....
Si fallo: ROLLBACK TRAN...
Operación N.... Si fallo: ROLLBACK TRAN
COMMIT TRAN
Es decir, se define el comienzo de una transacción, se comprueban posibles errores en cada paso,
echando atrás todo el proceso (se le suele llamar "hacer un Rollback"), o confirmando el conjunto
de operaciones completas al final del todo si no ha habido problemas (en la jerga habitual se suele
hablar de "hacer un Commit").
De hecho no suele ser necesario comprobar los errores por el camino ya que por regla general el
gestor de datos si detecta un error en cualquiera de los pasos dentro de una transacción, realizará un
rollback automático de toda la operación.
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.
Tipos de fallas y caídas
El sistema debe estar preparado para recuperarse no sólo de fallas puramente locales, como la
aparición de una condición de desborde dentro de una transacción, sino también de fallas globales,
como podría ser la interrupción del suministro eléctrico al CPU Las fallas locales son las que
afectan sólo a la transacción en donde ocurrió. Por el contrario las fallas globales, afectan a varias y
casi siempre a todas las transacciones que se estaban efectuando en el momento de la falla, por lo
cual tienen implicaciones importantes en el sistema.
Estas fallas pueden ser:
1. Fallas del sistema:
Afectan a todas las transacciones que se estaban ejecutando pero no afectan a la base de datos, se
conocen también como caídas suaves (crash). El problema aquí es que se pierda el contenido de
memoria principal, en particular, las áreas de almacenamiento temporal o buffers.
Si esto ocurre, no se conocerá el estado preciso de la transacción que se estaba ejecutando en el
momento de la falla, esta transacción jamás se podrá completar con éxito por lo que será preciso
anularla cuando se reinicie el sistema.
Además, puede ocurrir que sea necesario volver a ejecutar algunas transacciones que sí se
realizaron con éxito antes de la falla pero cuyas modificaciones no lograron efectuarse sobre la base
de datos porque no lograron ser transferidas de los buffers de la base de datos a la base de Datos
física (en disco).
2. Fallas en los medios de almacenamiento
Una falla de los medios de almacenamiento es un percance en el cual se destruye físicamente alguna
porción de la DB. La recuperación de una falla semejante implica en esencia cargar de nuevo la DB
a partir de una copia de respaldo y utilizar después la bitácora para realizar de nuevo todas las
transacciones terminadas desde que se hizo esa copia de respaldo. No hay necesidad de anular las
transacciones inconclusas en el momento de la falla, porque por definición todas las modificaciones
de esas transacciones ya se anularon de todas maneras.
La parte de restauración de la utilería servirá entonces para recrear la DB después de una falla de los
medios de almacenamiento a partir de una copia de respaldo especificada. Las fallas de los medios
de almacenamiento se llaman caídas duras.
La Recuperación de una falla semejante implica, en esencia, cargar de nuevo la base de datos a
partir de una copia de respaldo (database backup) y después utilizar la bitácora, o system log, para
realizar de nuevo todas las transacciones terminadas desde que se hizo esa copia para respaldo.
3. Fallas por catástrofes
Por terremotos, incendios, inundaciones, etc. Su tratamiento es similar al de fallas de los medios. La
principal técnica para manejar este tipo de fallas es la del database backus. Este es un respaldo
periódico que se hace de la DB. Después de una caída de esta índole el sistema se restaura
recargando la DB con la copia del último respaldo y recreando la DB mediante la bitácora o system
log.
Fallas a nivel de transacción
Si una transacción falla, por alguna razón, después de la actualización de la base de datos es
necesario "anularla" (RollBack o UNDO). Cualquier valor del data ítem que haya sido cambiado
por la transacción debe volver a su valor previo.
Si una transacción R ha leído un valor de un data ítem Y que ha sido modificado por S, entonces R
también se debe anular y así sucesivamente. Este fenómeno se conoce como rollback en cascada,
puede ser muy costoso y es por ello que los mecanismos de recovery han catalogado a este
fenómeno como indeseable o nunca requerido.
La recuperación de las fallas de transacciones significa que la DB se debe restaurar desde algún
estado considerado correcto del pasado lo más cercano posible al momento de la falla. El sistema
debe mantener la información de todo lo que afecta a la DB, a esto se le llama Bitácora o system
log.
Fallas a nivel de sistema
Cualquier sistema está sujeto a fallos, un fallo eventualmente puede ocasionar pérdidas e
inconsistencia de información. La ocurrencia de un fallo se puede presentar en cualquier etapa de la
vida de las distintas transacciones que gestiona el SMBD.
Como realizar operaciones que causen un overflow de un entero o la división por cero, así mismo
puede ocurrir que se pasen valores erróneos a algún parámetro o que se detecte un error en la lógica
de un programa, o que sencillamente no se encuentren los datos del programa. Además, en algunos
ambientes de desarrollo el usuario puede explícitamente interrumpir una transacción durante su
ejecución Aplicación del control de concurrencia Que ocurre por ejemplo cuando una transacción
viola las reglas de serialización o cae en abrazo mortal o interbloqueo.
Tambien puede existir una “caída del sistema (crash)”, que son fallos de hardware o software que
causan la falla general y caída del sistema. Estos se caracterizan por:
 Causan pérdida de información en memoria volátil (memoria principal y cache).
 El contenido de la información en la memoria no volátil (disco) permanece intacto.
 El DBMS posee numerosos chequeos de consistencia para prevenir la corrupción de los
datos.
La caída del sistema afecta a todas las transacciones activas al momento del error potencialmente
también a transacciones recientemente cometidas.
Fallas a través de almacenamiento secundario
Se refieren a las fallas que se pueden presentar en los dispositivos de almacenamiento secundario
que almacenan las bases de datos. Esas fallas se pueden presentar por errores del sistema operativo,
por errores del controlador del disco, o del disco mismo.
Bitácora o Log
Una bitácora (log) es una herramienta (archivos o registros) que permite registrar, analizar, detectar
y notificar eventos que sucedan en cualquier sistema de información utilizado en las organizaciones.
La estructura más ampliamente usada para grabar las acciones que se llevan en la base de datos.
Nos ayuda a recuperar la información ante algunos incidentes de seguridad, detección de
comportamiento inusual, información para resolver problemas, evidencia legal, es de gran ayuda en
las tareas de computo forense.
Permite guardar las transacciones realizadas sobre una base de datos en específico, de tal manera
que estas transacciones puedan ser auditadas y analizadas posteriormente.
 Recuperación (Rollback)
 En tecnologías de base de datos, un rollback es una operación que devuelve a la base de datos a
algún estado previo. Los Rollbacks son importantes para la integridad de la base de datos, a causa
de que significan que la base de datos puede ser restaurada a una copia limpia incluso después de
que se han realizado operaciones erróneas. Son cruciales para la recuperación de crashes de un
servidor de base de datos; realizando rollback (devuelto) cualquier transacción que estuviera activa
en el tiempo del crash, la base de datos es restaurada a un estado consistente.
En SQL, ROLLBACK es un comando que causa que todos los cambios de datos desde la última
sentencia BEGIN WORK, o START TRANSACTION sean descartados por el sistema de gestión
de base de datos relacional (RDBMS), para que el estado de los datos sea "rolled back"(devuelto) a
la forma en que estaba antes de que aquellos cambios tuvieran lugar.
 Permanencia (Commit)
En el contexto de la Ciencia de la computación y la gestión de datos, commit (acción de
comprometer) se refiere a la idea de consignar un conjunto de cambios "tentativos, o no
permanentes". Un uso popular es al final de una transacción de base de datos.
Una sentencia COMMIT en SQL finaliza una transacción de base de datos dentro de un sistema
gestor de base de datos relacional (RDBMS) y pone visibles todos los cambios a otros usuarios. El
formato general es emitir una sentencia BEGIN WORK, una o más sentencias SQL, y entonces la
sentencia COMMIT.
Técnicas de restauración utilizando bitácoras o log y sin utilizar log (esquema de doble
paginación)
El sistema mantiene una bitácora o system log en cinta, por lo general, o en disco en donde se
detallan todas las operaciones de actualización y los valores iniciales y finales de cada objeto. Por lo
tanto, si resulta necesario anular alguna modificación específica, el sistema puede utilizar la entrada
correspondiente de la bitácora para restaurar el valor original del objeto modificado.
Para recuperarse de las fallas de las transacciones, el sistema mantiene un log (llamado journal o
periódico) que mantiene el curso de todas las transacciones que afectan los datos ítems de la base de
datos. Al conjunto de log se le conoce como system log.
Esta información es mantenida en disco (memoria secundaria) de manera que sólo puede estar
afectada, eventualmente, por fallas en medios de almacenamiento. Periódicamente, los log son
respaldados en cintas para protegerlos contra fallas por catástrofes.

4. Control de Concurrencia
Problemas que pueden surgir cuando hay varias transacciones simultáneas:
 Actualización perdida:
a. El primer tipo de actualización se pierde, cobertura de reversión: cuando se deshace una
transacción, La operación de escritura en la transacción debe revertirse, Sobrescribe los datos
escritos por otras transacciones comprometidas.
b. El segundo tipo de actualización se pierde y se envía para cobertura: cuando se envía una
transacción, La operación de escritura depende de los datos leídos en la transacción. La lectura
ocurre antes de que se confirmen otras transacciones y la escritura ocurre después de que se
confirman otras transacciones., Sobrescribe los datos escritos por otras transacciones
comprometidas. Este es un caso especial de lectura no repetible.
 Lectura sucia: una transacción lee otra no comprometido datos escritos por la transacción.
 Lectura no repetible: leer dos veces en una transacción misma línea datos, pero los datos
leídos estos dos tiempos son diferentes.
 Lectura fantasma: dos consultas en una transacción, pero la segunda consulta es mejor que
la primera consulta más o menos filas o columnas datos.

Correctitud
Un programa es funcionalmente correcto si se comporta de acuerdo a la especificación de las
funciones (especificación de requerimientos funcionales) que debería proveer. Esta definición de
correctitud asume que existe una especificación de requerimientos funcionales del sistema y que es
posible determinar en forma no ambigua si las cumple o no. Se presentan diversas dificultades
cuando no existe dicha especificación, o si existe pero está escrita informalmente utilizando, por
ejemplo, lenguaje natural por lo que es posible que contenga ambigüedades.
La correctitud es una propiedad matemática que establece la equivalencia entre el software y su
especificación, por lo que cuanto más riguroso se haya sido en la especificación, más precisa y
sistemática podrá ser su evaluación. Posteriormente se verá que la correctitud puede ser evaluada
mediante diversos métodos, algunos de enfoque experimental como las pruebas, otros de enfoque
analítico como verificación formal de la correctitud.

Seriabilidad
Un conjunto entrelazado de transacciones es correcto si es serializable, es decir si produce el mismo
resultado mediante la ejecución en serie de las mismas transacciones. Dado un conjunto de
transacciones entrelazadas, cualquier ejecución de esas transacciones se dice que es una
calendarización (“scheduling”).
Las Formas de planificar la seriabilidad son por conflicto y por visión:
 Seriabilidad por conflicto:
Eliminar conflictos entre dos o más transacciones
Operaciones sobre los mismos datos en más de una transacción
Tipos de operaciones
 Seriabilidad por visión
Se basa en definir una regla de equivalencia menos estricta que la de conflicto.
Pero basándose solo en las operaciones de lectura y escritura.
Se puede considerar como un refinamiento de la equivalencia por conflicto

Técnicas y métodos de control de concurrencia implementados por diferentes SMBD

Entre las técnicas de concurrencia existen dos grandes grupos: Control de simultaneidad pesimista y
Control de simultaneidad optimista. En cada grupo se incluyen diferentes técnicas que permiten
manejar esa simultaneidad de manera eficiente:
a) Control de simultaneidad pesimista:
 Técnicas basadas en bloqueos.
 Técnicas Multi-Granulares.
 Técnicas basadas en marcas temporales.

b) Control de simultaneidad optimista.

 Técnicas basadas en Validación.
 Técnica original de control de concurrencia optimista.