Una base de datos temporal almacena datos relacionados con instancias temporales. Ofrece tipos de datos temporales y almacena información relacionada con el pasado, el presente y el futuro. Las bases de datos temporales pueden ser unitemporales, bitemporales o tritemporales.
Más específicamente, los aspectos temporales suelen incluir el tiempo de validez , el tiempo de transacción y/o el tiempo de decisión .
Una base de datos unitemporal tiene un eje de tiempo, ya sea el rango de validez o el rango de tiempo del sistema.
Una base de datos bitemporal tiene dos ejes de tiempo:
Una base de datos tritemporal tiene tres ejes de tiempo:
Este enfoque introduce complejidades adicionales.
Las bases de datos temporales contrastan con las bases de datos actuales (que no deben confundirse con las bases de datos actualmente disponibles), que almacenan únicamente hechos que se consideran verdaderos en el momento actual.
Las bases de datos temporales permiten gestionar y acceder a datos temporales proporcionando una o más de las siguientes características: [1] [2]
Con el desarrollo de SQL y su uso en aplicaciones de la vida real, los usuarios de bases de datos se dieron cuenta de que, cuando añadían columnas de fecha a campos clave, surgían algunos problemas. Por ejemplo, si una tabla tiene una clave principal y algunos atributos, añadir una fecha a la clave principal para realizar un seguimiento de los cambios históricos puede dar lugar a la creación de más filas de las previstas. Las eliminaciones también deben gestionarse de forma diferente cuando se realiza un seguimiento de las filas de esta forma. En 1992, se reconoció este problema, pero la teoría estándar de bases de datos aún no estaba preparada para resolverlo, y tampoco lo estaba el entonces recién formalizado estándar SQL-92 .
En 1992, Richard Snodgrass propuso que la comunidad de bases de datos temporales desarrollara extensiones temporales de SQL. En respuesta a esta propuesta, se formó un comité para diseñar extensiones de la edición de 1992 del estándar SQL (ANSI X3.135.-1992 e ISO/IEC 9075:1992); dichas extensiones, conocidas como TSQL2, fueron desarrolladas durante 1993 por este comité. [3] A fines de 1993, Snodgrass presentó este trabajo al grupo responsable del Estándar Nacional Estadounidense para el Lenguaje de Bases de Datos SQL, el Comité Técnico ANSI X3H2 (ahora conocido como NCITS H2). La especificación preliminar del lenguaje apareció en el Registro SIGMOD de ACM de marzo de 1994. En función de las respuestas a esa especificación, se realizaron cambios al lenguaje y la versión definitiva de la Especificación del Lenguaje TSQL2 se publicó en septiembre de 1994 [4].
Se intentó incorporar partes de TSQL2 en el nuevo estándar SQL SQL:1999 , llamado SQL3. Partes de TSQL2 se incluyeron en un nuevo subestándar de SQL3, ISO/IEC 9075-7, llamado SQL/Temporal. [3] El enfoque de TSQL2 fue duramente criticado por Chris Date y Hugh Darwen . [5] El proyecto ISO responsable del soporte temporal fue cancelado cerca de fines de 2001.
A partir de diciembre de 2011, la norma ISO/IEC 9075, Lenguaje de base de datos SQL:2011 Parte 2: SQL/Foundation incluyó cláusulas en las definiciones de tabla para definir "tablas de período de tiempo de aplicación" ( tablas de tiempo válido ), "tablas con versiones del sistema" ( tablas de tiempo de transacción ) y "tablas de período de tiempo de aplicación con versiones del sistema" ( tablas bitemporales ). Una diferencia sustancial entre la propuesta de TSQL2 y lo que se adoptó en SQL:2011 es que no hay columnas ocultas en el tratamiento de SQL:2011, ni tiene un nuevo tipo de datos para intervalos; en cambio, dos columnas con marcas de fecha (DS) o marcas de fecha y hora (DTS) se pueden unir mediante una PERIOD FORdeclaración. Otra diferencia es el reemplazo de los controvertidos modificadores de declaración (prefijo) de TSQL2 con un conjunto de predicados temporales. [1]
Otras características del estándar SQL:2011 relacionadas con las bases de datos temporales son la división automática de períodos de tiempo, claves primarias temporales, integridad referencial temporal, predicados temporales con álgebra de intervalos de Allen y consultas secuenciadas y con cortes de tiempo.
A modo de ilustración, consideremos la siguiente biografía breve de un hombre ficticio, John Doe:
Para almacenar la vida de John Doe en una base de datos actual (no temporal) utilizamos una tabla person (name, address). (Para simplificar, namese define como la clave principal de person.)
El padre de John informó oficialmente de su nacimiento el 4 de abril de 1975. En esa fecha, un funcionario de Smallville insertó la siguiente entrada en la base de datos: Person(John Doe, Smallville). Tenga en cuenta que la fecha en sí no se almacena en la base de datos.
Después de graduarse, John se muda, pero se olvida de registrar su nueva dirección. La entrada de John en la base de datos no cambia hasta el 27 de diciembre de 1994, cuando finalmente la informa. Un funcionario de Bigtown actualiza su dirección en la base de datos. La persontabla ahora contiene Person(John Doe, Bigtown). Tenga en cuenta que la información de que John vive en Smallville se ha sobrescrito, por lo que ya no es posible recuperar esa información de la base de datos. A un funcionario que acceda a la base de datos el 28 de diciembre de 1994, se le informará que John vive en Bigtown. Más técnicamente: si un administrador de la base de datos ejecutó la consulta el 26 de diciembre de 1994, el resultado sería . Ejecutar la misma consulta 2 días después daría como resultado .SELECT ADDRESS FROM PERSON WHERE NAME='John Doe'SmallvilleBigtown
Hasta su muerte, la base de datos indicaría que vivía en Bigtown. El 1 de abril de 2001, el forense eliminó la entrada de John Doe de la base de datos. Después de esto, la ejecución de la consulta anterior no arrojaría ningún resultado.
El tiempo válido es el tiempo durante el cual un hecho es verdadero en el mundo real. Un período de tiempo válido puede ser del pasado, abarcar el tiempo actual o ocurrir en el futuro.
En el ejemplo anterior, para registrar una hora válida, personse han añadido dos campos a la tabla, valid_fromy valid_to. Estos campos especifican el período en el que la dirección de una persona es válida en el mundo real. El 4 de abril de 1975, el padre de John registró el nacimiento de su hijo. A continuación, un funcionario inserta una nueva entrada en la base de datos que indica que John vive en Smallville desde el 3 de abril. Observe que, aunque los datos se insertaron el día 4, la base de datos indica que la información es válida desde el día 3. El funcionario aún no sabe si John se mudará a otro lugar ni cuándo, por lo que el valid_tocampo se establece en infinito (∞). La entrada en la base de datos es:
El 27 de diciembre de 1994, John informa de su nueva dirección en Bigtown, donde ha estado viviendo desde el 26 de agosto de 1994. Se realiza una nueva entrada en la base de datos para registrar este hecho:
La entrada original Person (John Doe, Smallville, 1975-04-03, ∞)no se ha eliminado, pero se ha valid_toactualizado el atributo para reflejar que ahora se sabe que John dejó de vivir en Smallville el 26 de agosto de 1994. La base de datos ahora contiene dos entradas para John Doe:
Cuando John muere, su entrada actual en la base de datos se actualiza indicando que John ya no vive en Bigtown. La base de datos ahora luce así:
El tiempo de transacción registra el período de tiempo durante el cual una entrada de la base de datos se acepta como correcta. Esto permite realizar consultas que muestran el estado de la base de datos en un momento determinado. Los períodos de tiempo de transacción solo pueden ocurrir en el pasado o hasta el momento actual. En una tabla de tiempo de transacción, los registros nunca se eliminan. Solo se pueden insertar registros nuevos y actualizar los existentes configurando su hora de finalización de transacción para mostrar que ya no son actuales.
Para habilitar el tiempo de transacción en el ejemplo anterior, se agregan dos campos más a la tabla Persona: transaction_fromy transaction_to. Aquí, transaction_fromes el momento en que se realizó una transacción y transaction_toes el momento en que se reemplazó la transacción (que puede ser infinito si aún no se reemplazó). Esto convierte la tabla en una tabla bitemporal.
¿Qué sucede si la dirección de la persona almacenada en la base de datos es incorrecta? ¿Supongamos que un funcionario ingresó accidentalmente una dirección o fecha incorrecta? O supongamos que la persona mintió sobre su dirección por algún motivo. Al descubrir el error, los funcionarios actualizan la base de datos para corregir la información registrada.
Por ejemplo, desde el 1 de junio de 1995 hasta el 3 de septiembre de 2000, John Doe se mudó a Beachy. Pero para evitar pagar el exorbitante impuesto de residencia de Beachy, nunca lo informó a las autoridades. Más tarde, durante una investigación fiscal, se descubre que el 2 de febrero de 2001, de hecho, estuvo en Beachy durante esas fechas. Para registrar este hecho, la entrada existente sobre John viviendo en Bigtown debe dividirse en dos registros separados e insertar un nuevo registro que registre su residencia en Beachy. La base de datos aparecería entonces de la siguiente manera:
Sin embargo, esto no deja ningún registro de que la base de datos haya afirmado alguna vez que vivió en Bigtown entre el 1 de junio de 1995 y el 3 de septiembre de 2000. Esto podría ser importante para fines de auditoría o para utilizarlo como prueba en la investigación fiscal del funcionario. El tiempo de transacción permite capturar este conocimiento cambiante en la base de datos, ya que las entradas nunca se modifican ni se eliminan directamente. En cambio, cada entrada registra cuándo se ingresó y cuándo se reemplazó (o se eliminó lógicamente). El contenido de la base de datos se ve así:
La base de datos registra no sólo lo que sucedió en el mundo real, sino también lo que se registró oficialmente en diferentes momentos.
El tiempo de decisión es una alternativa al período de tiempo de transacción para registrar el momento en el que una entrada de la base de datos puede aceptarse como correcta. Esto permite realizar consultas que muestran los hechos oficialmente reconocidos en un momento determinado, incluso si hubo un retraso en la confirmación de esos hechos en la base de datos. La compatibilidad con el tiempo de decisión conserva todo el historial y evita la pérdida de información durante las actualizaciones. [6]
Los períodos de tiempo de decisión solo pueden ocurrir en el pasado o hasta el momento de la transacción. Al igual que en una tabla de tiempo de transacción, los registros nunca se eliminan. Solo se pueden insertar registros nuevos y actualizar los existentes configurando su hora de finalización de decisión para mostrar que ya no son actuales.
Para habilitar el tiempo de decisión, se agregan dos campos más a una tabla de base de datos: decision_fromy decision_to. Aquí, decision_fromes el momento en que se tomó una decisión y es el momento en que se reemplazó la decisión (que puede ser infinito si aún no se reemplazó). Cuando se combina con el tiempo de transacción, esto convierte la tabla en una tabla tritemporal. La siguiente es una lista de eventos reales que ocurrieron entre las elecciones presidenciales de los Estados Unidosdecision_to de 1964 y 1976 :
En este ejemplo, se supone que hay un retraso constante de siete días entre el momento de la decisión y el momento de la transacción cuando los datos se incorporan a la base de datos. Dadas esas condiciones, la base de datos habría contenido la siguiente información después de las elecciones de 1976:
Teniendo en cuenta la tabla anterior con un retraso de siete días, la pregunta "quién era presidente y vicepresidente durante el período válido de 1977-01-01" (que, dado el retraso de siete días, podría proporcionar datos para 1976-12-25) sería:
Un modelo bitemporal contiene tanto el tiempo válido como el de la transacción. Esto proporciona información histórica y de reversión . La información histórica (por ejemplo: "¿Dónde vivía John en 1992?") se proporciona mediante el tiempo válido. La reversión (por ejemplo: "¿En 1992, dónde creía la base de datos que vivía John?") se proporciona mediante el tiempo de la transacción. Las respuestas a estas preguntas de ejemplo pueden no ser las mismas: la base de datos puede haber sido modificada desde 1992, lo que hace que las consultas produzcan resultados diferentes.
La hora válida y la hora de la transacción no tienen por qué ser las mismas para un mismo hecho. Por ejemplo, supongamos que se trata de una base de datos temporal que almacena datos sobre el siglo XVIII. La hora válida de estos hechos se encuentra entre 1701 y 1800. La hora de la transacción indicaría cuándo se insertaron los hechos en la base de datos (por ejemplo, 1998-01-21).
Un problema complejo es el soporte de consultas temporales en una base de datos de tiempo de transacción bajo un esquema en evolución . Para lograr una calidad de archivo perfecta, es de importancia clave almacenar los datos bajo la versión del esquema bajo la que aparecieron por primera vez. Sin embargo, incluso la consulta temporal más simple que reescribiera el historial de un valor de atributo tendría que reescribirse manualmente bajo cada una de las versiones del esquema, potencialmente cientos como en el caso de MediaWiki . [7] Este proceso sería particularmente exigente para los usuarios. Una solución propuesta es proporcionar reescritura automática de consultas, [8] [9] aunque esto no es parte de SQL o estándares similares.
Los enfoques para minimizar las complejidades de la evolución del esquema son:
Las siguientes implementaciones proporcionan características temporales en un sistema de gestión de bases de datos relacionales (RDBMS).
Sistemas de gestión de bases de datos NoSQL no relacionales que proporcionan funciones temporales, incluidas las siguientes:
Las bases de datos temporales fueron una de las primeras formas de control de versiones de datos e influyeron en el desarrollo de los sistemas de versiones de datos modernos. [19]
Las dimensiones que cambian lentamente se pueden utilizar para modelar relaciones temporales.
