Una base de datos temporal almacena datos relacionados con instancias de tiempo. Ofrece tipos de datos temporales y almacena información relacionada con el tiempo pasado, presente y futuro. Las bases de datos temporales pueden ser unitemporales, bitemporales o tritemporales.
Más específicamente, los aspectos temporales suelen incluir el tiempo válido , 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 disponibles actualmente), que almacenan sólo hechos que se creen ciertos en el momento actual.
Las bases de datos temporales admiten la gestión y el acceso 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 agregaban columnas de fecha a campos clave, surgían algunos problemas. Por ejemplo, si una tabla tiene una clave principal y algunos atributos, agregar una fecha a la clave principal para realizar un seguimiento de los cambios históricos puede generar más filas de las previstas. Las eliminaciones también deben manejarse de manera diferente cuando se realiza un seguimiento de las filas de esta manera. 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 .
Richard Snodgrass propuso en 1992 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 a la edición de 1992 del estándar SQL (ANSI X3.135.-1992 e ISO/IEC 9075:1992); esas extensiones, conocidas como TSQL2, fueron desarrolladas durante 1993 por este comité. [3] A finales de 1993, Snodgrass presentó este trabajo al grupo responsable del Estándar Nacional Estadounidense para el Lenguaje de Base de Datos SQL, Comité Técnico ANSI X3H2 (ahora conocido como NCITS H2). La especificación preliminar del lenguaje apareció en el registro ACM SIGMOD de marzo de 1994. Con base en las respuestas a esa especificación, se realizaron cambios en el 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 TSQL2 fue fuertemente criticado por Chris Date y Hugh Darwen . [5] El proyecto ISO responsable del apoyo temporal fue cancelado a finales de 2001.
A partir de diciembre de 2011, ISO/IEC 9075, Lenguaje de base de datos SQL:2011 Parte 2: SQL/Foundation incluyó cláusulas en las definiciones de tablas para definir "tablas de períodos de tiempo de aplicación" ( tablas de tiempos válidas ), "tablas versionadas por el sistema" ( tiempos de transacción ). tablas) y "tablas de períodos de tiempo de aplicación versionadas por el sistema" ( tablas bitemporales ). Una diferencia sustancial entre la propuesta TSQL2 y lo adoptado en SQL:2011 es que no hay columnas ocultas en el tratamiento SQL:2011, ni tiene un nuevo tipo de datos para intervalos; en su lugar , se pueden unir dos columnas con marcas de fecha (DS) o marcas de fecha y horaPERIOD FOR (DTS) mediante una declaración. Otra diferencia es la sustitución de los controvertidos modificadores de sentencias (prefijo) de TSQL2 por 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 divididas en el tiempo.
A modo de ilustración, considere la siguiente breve biografía 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 su nacimiento el 4 de abril de 1975. En esta 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 olvida 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 lo 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 John que 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 accediera a la base de datos el 28 de diciembre de 1994 se le diría que John vive en Bigtown. Más técnicamente: si un administrador de base de datos ejecutara 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 elimina la entrada de John Doe de la base de datos. Después de esto, ejecutar 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 en el pasado, abarcar el tiempo actual o ocurrir en el futuro.
Para el ejemplo anterior, para registrar el tiempo válido, la persontabla tiene dos campos agregados valid_fromy valid_to. Estos 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. Luego, un funcionario inserta una nueva entrada en la base de datos que indica que John vive en Smallville desde el 3 de abril. Tenga en cuenta que aunque los datos se insertaron el día cuatro, la base de datos indica que la información es válida desde el tercero. El funcionario aún no sabe si John se mudará a otro lugar o 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 su nueva dirección en Bigtown, donde vive 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 elimina, pero tiene el valid_toatributo actualizado 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 se ve 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 un cronograma de transacciones, los registros nunca se eliminan. Solo se pueden insertar registros nuevos y actualizar los existentes estableciendo la hora de finalización de la transacción para mostrar que ya no están actualizados.
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 la hora en que se realizó una transacción y transaction_tola hora en que se reemplazó la transacción (que puede ser infinita si aún no ha sido reemplazada). Esto convierte la mesa en una mesa bitemporal.
¿Qué sucede si la dirección de la persona almacenada en la base de datos es incorrecta? ¿Supongamos que un funcionario accidentalmente ingresó la 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, del 1 de junio de 1995 al 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 el 2 de febrero de 2001 que, 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 y se debe insertar un nuevo registro que registre su residencia en Beachy. La base de datos entonces aparecería 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. Podría ser importante saberlo por motivos 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 eliminan directamente. En cambio, cada entrada registra cuándo se ingresó y cuándo fue reemplazada (o eliminada lógicamente). El contenido de la base de datos entonces 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 la transacción para registrar el momento en el que una entrada de la base de datos puede aceptarse como correcta. Esto permite consultas que muestran los hechos oficialmente reconocidos en un momento dado, incluso si hubo un retraso en la confirmación de esos hechos en la base de datos. El soporte para el tiempo de decisión preserva todo el historial y evita la pérdida de información durante las actualizaciones. [6]
Los períodos de decisión solo pueden ocurrir en el pasado o hasta el momento de la transacción. Al igual que en un cronograma de transacciones, los registros nunca se eliminan. Solo se pueden insertar registros nuevos y actualizar los existentes estableciendo la hora de finalización de su decisión para mostrar que ya no están vigentes.
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 decision_toel momento en que la decisión fue reemplazada (que puede ser infinita si aún no ha sido reemplazada). Cuando se combina con el tiempo de transacción, esto convierte la tabla en una tabla tritemporal. La siguiente es una lista de hechos reales ocurridos entre las elecciones presidenciales de Estados Unidos de 1964 y 1976 :
En este ejemplo, se supone un retraso constante de 7 días entre el momento de la decisión y el momento de la transacción cuando los datos se confirman en 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:
Dada la tabla anterior con un retraso de 7 días, la pregunta "quién fue presidente y vicepresidente durante el período válido del 1 de enero de 1977" (que, dado el retraso de 7 días, podría proporcionar datos para el 25 de diciembre de 1976) sería:
Un modelo bitemporal contiene tanto el tiempo válido como el de 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 según la época válida. La reversión (por ejemplo: "En 1992, ¿dónde creía la base de datos que vivía John?") la proporciona el tiempo de transacción. Las respuestas a estas preguntas de ejemplo pueden no ser las mismas: es posible que la base de datos haya sido alterada desde 1992, lo que provocó que las consultas produzcan resultados diferentes.
El tiempo de validez y el tiempo de transacción no tienen por qué ser iguales para un solo hecho. Por ejemplo, consideremos una base de datos temporal que almacena datos sobre el siglo XVIII. La hora válida de estos hechos es entre 1701 y 1800. La hora de la transacción mostraría cuándo se insertaron los hechos en la base de datos (por ejemplo, 1998-01-21).
Un tema desafiante 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 vital importancia almacenar los datos en la versión del esquema con la que aparecieron por primera vez. Sin embargo, incluso la consulta temporal más simple que reescriba el historial de un valor de atributo tendría que reescribirse manualmente en cada una de las versiones del esquema, potencialmente cientos como en el caso de MediaWiki . [7] Este proceso sería particularmente gravoso para los usuarios. Una solución propuesta es proporcionar reescritura automática de consultas, [8] [9] aunque esto no forma parte de SQL ni de 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 administración de bases de datos NoSQL no relacionales que brindan características temporales que incluyen lo siguiente:
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 modernos de control de versiones de datos. [19]
Se pueden utilizar dimensiones que cambian lentamente para modelar relaciones temporales.
