Base de datos temporal

A base de datos temporales almacena datos relacionados con casos de tiempo. Ofrece tipos de datos temporales y almacena información relativa al 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 o el tiempo de decisión.

• Hora válida es el período de tiempo o tiempo de evento en el que un hecho es verdadero en el mundo real.
• Tiempo de transacción es el momento en que se registró un hecho en la base de datos.
• Tiempo de decisión es el momento en que se tomó la decisión sobre el hecho.

Tipos

Unitemporal

Una base de datos unitemporal tiene un eje de tiempo, ya sea el rango de validez o el rango de tiempo del sistema.

Bitemporal

Una base de datos bitemporal tiene dos ejes de tiempo:

• tiempo válido
• tiempo de transacción o tiempo de decisión

Tri-temporal

Una base de datos tritemporal tiene tres ejes de tiempo:

• tiempo válido
• tiempo de transacción
• tiempo de decisión

Este enfoque introduce complejidades adicionales.

Las bases de datos temporales contrastan con las bases de datos actuales (no deben confundirse con las bases de datos actualmente disponibles), que almacenan sólo hechos que se creen ciertos en el momento actual.

Características

Las bases de datos temporales admiten la gestión y el acceso a datos temporales al proporcionar una o más de las siguientes características:

• Un tipo de datos del período de tiempo, incluyendo la capacidad de representar períodos de tiempo sin fin (infinito o para siempre)
• La capacidad de definir los atributos válidos y del período de transacción y las relaciones mordemosporales
• Tiempo de transacción mantenido por el sistema
• Llaves primarias temporales, incluidas las restricciones de períodos no superpuestos
• Limitaciones temporales, incluida la singularidad no superpuesta y la integridad referencial
• Actualización y eliminación de registros temporales con división automática y coalesificación de períodos de tiempo
• Consultas temporales en el momento actual, puntos de tiempo en el pasado o en el futuro, o con duración
• Predicados para periodos de tiempo de consulta, a menudo basados en las relaciones de intervalo de Allen

Historia

Con el desarrollo de SQL y su uso adjunto en aplicaciones de la vida real, los usuarios de bases de datos se dieron cuenta de que cuando agregaron columnas de fecha a campos clave, surgieron algunos problemas. Por ejemplo, si una tabla tiene una clave primaria y algunos atributos, la adición de una fecha a la clave principal para rastrear los cambios históricos puede conducir a la creación de más filas de lo previsto. Los borradores también deben manejarse de manera diferente cuando las filas se rastrean de esta manera. En 1992 se reconoció esta cuestión, pero la teoría de bases de datos estándar aún no estaba en condiciones de resolver este problema, y tampoco era la norma formalizada.

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é. 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.

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. El enfoque TSQL2 fue fuertemente criticado por Chris Date y Hugh Darwen. El proyecto ISO responsable del apoyo temporal fue cancelado a finales de 2001.

En diciembre de 2011, ISO/IEC 9075, Database Language SQL:2011 Parte 2: SQL/Foundation incluyó cláusulas en las definiciones de tablas para definir "tablas de tiempo de aplicación" (tablas de tiempo válidas), "tablas de conversión del sistema" (tablas de tiempo de transacción) y "tablas de período de aplicación modificadas por el sistema" (tablas temporales). Una diferencia sustantiva entre la propuesta TSQL2 y lo que fue 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 lugar de dos columnas fecha o timetamp pueden estar unidas usando un tipo de datos nuevo para intervalos. PERIOD FOR declaración. Otra diferencia es la sustitución de los controvertidos (prefijos) modificadores de declaración de TSQL2 con un conjunto de predicados temporales.

Otras características de SQL:2011 estándar relacionados con bases de datos temporales son intervalos de tiempo automáticos, claves primarias temporales, integridad temporal de referencia, predicaciones temporales con el álgebra de intervalo de Allen y consultas cortadas y secuenciadas.

Ejemplo

Para ilustrar, considere la siguiente biografía corta de un hombre ficticio, John Doe:

John Doe nació el 3 de abril de 1975 en el Hospital de Niños del Condado de Medicina, como hijo de Jack Doe y Jane Doe que vivían en Smallville. Jack Doe registró con orgullo el nacimiento de su primogénito el 4 de abril de 1975 en el Ayuntamiento de Smallville. John creció como un chico alegre, resultó ser un estudiante brillante y se graduó con honores en 1993. Después de la graduación, fue a vivir por su cuenta en Bigtown. Aunque se mudó el 26 de agosto de 1994, se olvidó de registrar oficialmente el cambio de dirección. Sólo a la vuelta de las estaciones, su madre le recordó que tenía que registrarse, lo que hizo unos días después el 27 de diciembre de 1994. Aunque John tenía un futuro prometedor, su historia termina trágicamente. John. Doe fue golpeado accidentalmente por un camión el 1 de abril de 2001. El forense informó su fecha de muerte el mismo día.

Utilizar una base de datos no temporal

Para almacenar la vida de John Doe en una base de datos actual (no temporal) usamos una tabla Person (Name, Address). (Para simplificar Nombre se define como la clave principal Persona)

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: Persona(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 lo informa. Un funcionario de Bigtown actualiza su dirección en la base de datos. La tabla Persona ahora contiene Persona(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 ejecutó la consulta SELECCIONAR DIRECCIÓN DE PERSON DÓNDE NOMBRE='John Doe' el 26 de diciembre de 1994, el resultado sería Smallville. Ejecutar la misma consulta 2 días después daría como resultado Bigtown.

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.

Usando un solo eje: tiempo válido o tiempo de transacción

El tiempo de validez 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 tabla Persona tiene dos campos agregados, Válido-Desde y Válido-Hasta. 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 campo Válido para se establece en infinito (∞). La entrada en la base de datos es:

Person(John Doe, Smallville, 3-Apr-1975, ∞).

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:

Person(John Doe, Bigtown, 26-Aug-1994, ∞).

La entrada original Persona (John Doe, Smallville, 3 de abril de 1975, ∞) no se elimina, pero tiene el atributo Válido para actualizado para reflejar eso. 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.

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, ∞).

Cuando John muere su entrada actual en la base de datos se actualiza indicando que John no vive en Bigtown más tiempo. La base de datos ahora parece así.

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Apr-2001).

Usando dos ejes: tiempo válido y tiempo de transacción

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: Transacción-De y Transacción-A. Transaction-From es la hora en que se realizó una transacción y Transaction-To es la 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:

Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Jun-1995).
Person(John Doe, Beachy, 1-Jun-1995, 3-Sep-2000).
Person(John Doe, Bigtown, 3-Sep-2000, 1-Apr-2001).

Sin embargo, esto no deja 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 saber esto 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 se ve así:

Nombre, Ciudad, Valide From, Valid Till, Entered, Superseded

Person(John Doe, Smallville, 3-Apr-1975, ∞, 4-Apr-1975, 27-Dec-1994).
Person(John Doe, Smallville, 3-Apr-1975, 26-Aug-1994, 27-Dec-1994, ∞).
Person(John Doe, Bigtown, 26-Aug-1994, ∞, 27-Dec-1994, 2-Feb-2001).
Person(John Doe, Bigtown, 26-Aug-1994, 1-Jun-1995, 2-Feb-2001, ∞).
Person(John Doe, Beachy, 1-Jun-1995, 3-Sep-2000, 2-Feb-2001, ∞).
Person(John Doe, Bigtown, 3-Sep-2000, ∞, 2-Feb-2001, 1-Apr-2001).
Person(John Doe, Bigtown, 3-Sep-2000, 1-Apr-2001, 1-Apr-2001, ∞).

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.

Usando tres ejes: tiempo válido, tiempo de decisión y tiempo de transacción

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.

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: Decisión desde y Decisión hasta. Decisión desde es el momento en que se tomó una decisión y Decisión hasta es el momento en que se reemplazó la decisión (que puede ser infinito 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 eventos del mundo real que ocurrieron entre las elecciones presidenciales de Estados Unidos de 1964 y 1976:

Supongamos que hay un retraso constante de 7 días entre el momento de la decisión y el momento de la transacción comprometida en la base de datos. Luego, tras las elecciones de 1976, el contenido de la base de datos sería:

 Presidente, Vicepresidente, Valide From, Valid Till, Decision From, Decision To, Transaction From, Transaction To
Respuesta
Administración(Lyndon Johnson, Hubert Humphrey, 20-Jan-1965, 20-Jan-1969, 3-Nov-1964, ∞, 10-Nov-1964, ∞)
Administración (Richard Nixon, Spiro Agnew, 20-Jan-1969, 20-Jan-1973, 5-Nov-1968, ∞, 12-Nov-1968, ∞)
Administración (Richard Nixon, Spiro Agnew, 20-Jan-1973, 20-Jan-1977, 7-Nov-1972, ∞, 14-Nov-1972, 17-Oct-1973)
Administración (Richard Nixon, Spiro Agnew, 20-Jan-1973, 20-Jan-1977, 7-Nov-1972, 10-Oct-1973, 17-Oct-1973, ∞)
Administración (Richard Nixon, Spiro Agnew, 20-Jan-1973, 10-Oct-1973, 10-Oct-1973, ∞, 17-Oct-1973, ∞)
Administración(Richard Nixon, (Vacant), 10-Oct-1973, 20-Jan-1977, 10-Oct-1973, ∞, 17-Oct-1973, 13-Dec-1973)
Administración (Richard Nixon, Gerald Ford, ∞, 20-Jan-1977, 12-Oct-1973, ∞, 19-Oct-1973, 13-Dec-1973)
Administración(Richard Nixon, (Vacant), 10-Oct-1973, 20-Jan-1977, 10-Oct-1973, 6-Dec-1973, 13-Dec-1973, ∞)
Administración(Richard Nixon, (Vacant), 10-Oct-1973, 6-Dec-1973, 6-Dec-1973, ∞, 13-Dec-1973, ∞)
Administración (Richard Nixon, Gerald Ford, ∞, 20-Jan-1977, 12-Oct-1973, 6-Dec-1973, 13-Dec-1973, ∞)
Administración (Richard Nixon, Gerald Ford, 6-Dec-1973, 20-Jan-1977, 6-Dec-1973, ∞, 13-Dec-1973, 15-Aug-1974)
Administración (Richard Nixon, Gerald Ford, 6-Dec-1973, 20-Jan-1977, 6-Dec-1973, 8-Aug-1974, 15-Aug-1974, ∞)
Administración (Richard Nixon, Gerald Ford, 6-Dec-1973, 9-Aug-1974, 8-Aug-1974, ∞, 15-Aug-1974, ∞)
Administración(Gerald Ford, (Vacant), 9-Aug-1974, 20-Jan-1977, 8-Aug-1974, ∞, 15-Aug-1974, 26-Dec-1974)
Administración(Gerald Ford, Nelson Rockefeller, ∞, 20-Jan-1977, 20-Aug-1974, ∞, 27-Aug-1974, 26-Dec-1974)
Administración(Gerald Ford, (Vacant), 9-Aug-1974, 20-Jan-1977, 8-Aug-1974, 19-Dec-1974, 26-Dec-1974, ∞)
Administración(Gerald Ford, (Vacant), 9-Aug-1974, 19-Dec-1974, 19-Dec-1974, ∞, 26-Dec-1974, ∞)
Administración(Gerald Ford, Nelson Rockefeller, ∞, 20-Jan-1977, 20-Aug-1974, 19-Dec-1974, 26-Dec-1974, ∞)
Administración(Gerald Ford, Nelson Rockefeller, 19-Dec-1974, 20-Jan-1977, 19-Dec-1974, ∞, 26-Dec-1974, ∞)
Administración(Jimmy Carter, Walter Mondale, 20-Jan-1977, 20-Jan-1981, 2-Nov-1976, ∞, 9-Nov-1976, ∞)

Considere la cuestión de quién sería presidente y vicepresidente por un tiempo válido de 1-Jan-1977:

• Nixon/Agnew when using a decision time and transactions time of 14-Nov-1972
• Nixon/(Vacant) al utilizar un tiempo de decisión y tiempo de transacción de 17-Oct-1973
• Nixon/Ford al utilizar un tiempo de decisión y tiempo de transacción de 8-Aug-1974
• Ford/(Vacant) al utilizar un tiempo de decisión de 8-Aug-1974 y tiempo de transacción actual
• Ford/Rockefeller al utilizar un tiempo de decisión y tiempo de transacción actual

Modelado bitemporal

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. Es posible que las respuestas a estas preguntas de ejemplo no sean las mismas: es posible que la base de datos haya sido modificada desde 1992, lo que ha provocado que las consultas produzcan resultados diferentes.

El tiempo de validez y el tiempo de transacción no tienen que 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, 21 de enero de 1998).

Evolución del esquema

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 [1]. Este proceso sería particularmente agotador para los usuarios. Una solución propuesta es proporcionar reescritura automática de consultas, 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:

• utilizar una base de datos semiestructurada/NoSQL que reduce las complejidades de los datos de atributos de modelado, pero no proporciona características para el manejo de ejes de tiempo múltiples.
• utilizar una base de datos capaz de almacenar datos semiestructurados para atributos y datos estructurados para ejes temporales (por ejemplo, SnowflakeDB, PostgreSQL)

Implementaciones en productos destacados

Las siguientes implementaciones proporcionan funciones temporales en un sistema de gestión de bases de datos relacionales (RDBMS).

• MariaDB versión 10.3.4 agregó soporte para SQL:2011 estándar como "System-Versioned Tables".
• Oracle Database – Oracle Workspace Manager es una característica de Oracle Database que permite a los desarrolladores de aplicaciones y DBAs gestionar versiones actuales, propuestas e históricas de datos en la misma base de datos.
• PostgreSQL versión 9.2 agregó tipos de datos nativos que son capaces de implementar todas las características de la extensión temporal pgFoundry. Los tipos de gama PostgreSQL son apoyados por numerosos operadores y funciones nativos.
• Teradata proporciona dos productos. Teradata versión 13.10 y Teradata versión 14 tienen características temporales basadas en TSQL2 incorporadas en la base de datos.
• IBM Db2 versión 10 agregó una característica llamada "query de viaje de tiempo" que se basa en las capacidades temporales del estándar SQL:2011.
• Microsoft SQL Servidor introdujo Tablas Temporales como una característica para SQL Server 2016. La característica se describe en un vídeo en el sitio web de Microsoft "Channel 9".

Sistemas de administración de bases de datos NoSQL no relacionales que brindan características temporales que incluyen lo siguiente:

• Terminus DB es una base de datos de gráficos de código abierto que admite nativamente el control de versiones, consultas de viajes de tiempo y funciones de difusión. Tiene una arquitectura de capa inmutable basada en la codificación delta y estructuras de datos sucintas.
• MarkLogic introdujo soporte de datos de mordedor en versión 8.0. Los sellos de tiempo para el tiempo Valid y System se almacenan en documentos JSON o XML.
• SirixDB almacena instantáneas de (actualmente) documentos XML- y JSON muy eficientemente en un formato binario debido a un algoritmo de versión novedosa llamado instantánea deslizante, que equilibra el rendimiento de lectura/escritura y nunca crea picos de escritura. Las consultas de viajes de tiempo son compatibles con funciones nativas y difusas.
• XTDB (antes Crux) proporciona consultas de bitmporal punto a tiempo sobre transacciones y documentos ingeridos de registros de Kafka semi-inmutables. Los documentos se indexan automáticamente para crear índices de modelos Entity–attribute–valor sin necesidad de definir un esquema. Operaciones de transacción especifican los tiempos válidos efectivos. Los tiempos de transacción son asignados por Kafka y permiten escalabilidad horizontal mediante lecturas consistentes.
• RecordallGraph es una base de datos gráfica de punto a tiempo, unitemporal (tiempo de transacción), construida en la parte superior de ArangoDB. Funciona en el subsistema Foxx Microservice de ArangoDB. Cuenta con semántica tipo VCS en muchas partes de su interfaz, y está respaldada por un rastreador de eventos transaccionales. La puntualidad figura como uno de los temas de su hoja de ruta para el desarrollo.

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.

Alternativas

Se pueden utilizar dimensiones que cambian lentamente para modelar relaciones temporales.