Hispanopedia Wiki
Articulo de referencia

Base de datos temporal

Una base de datos temporal almacena información relativa a instantes de tiempo. Ofrece tipos de datos temporales y almacena información sobre el pasado, el presente y el futuro....

Hispanopedia WikiContenido en espanolLectura gratuita

Una base de datos temporal almacena información relativa a instantes de tiempo. Ofrece tipos de datos temporales y almacena información sobre el pasado, el presente y el futuro. Las bases de datos temporales pueden ser unitemporales, bitemporales o tritemporales.

Más concretamente, los aspectos temporales suelen incluir el tiempo de validez , el tiempo de transacción y/o el tiempo de decisión .

  • El tiempo válido es el período de tiempo o el momento del evento durante el cual un hecho es verdadero en el mundo real.
  • El tiempo de transacción es el momento en que un hecho se registró en la base de datos.
  • El momento de la decisión es aquel en el que se tomó la decisión sobre el hecho. Se utiliza para mantener un registro de las decisiones sobre los momentos válidos.

Tipos

Unitemporal

Una base de datos unitemporal tiene un único eje temporal, ya sea el intervalo de validez o el intervalo de tiempo del sistema.

Bitemporal

Una base de datos bitemporal tiene dos ejes de tiempo:

  • Hora válida
  • Tiempo de transacción o tiempo de decisión

Tritemporal

Una base de datos tritemporal tiene tres ejes de tiempo:

  • Hora válida
  • Tiempo de transacción
  • Momento de decisión

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), las cuales almacenan únicamente hechos que se consideran verdaderos en el momento presente.

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: [ 1 ] [ 2 ]

  • Un tipo de dato de período de tiempo, que incluye la capacidad de representar períodos de tiempo sin fin (infinito o para siempre).
  • La capacidad de definir atributos de período de tiempo válidos y de transacción y relaciones bitemporales
  • Tiempo de transacción mantenido por el sistema
  • Claves primarias temporales , incluidas las restricciones de período no superpuesto.
  • Restricciones temporales, incluyendo la unicidad no superpuesta y la integridad referencial.
  • Actualización y eliminación de registros temporales con división y fusión automáticas de períodos de tiempo.
  • Consultas temporales en el momento actual, en momentos del pasado o del futuro, o durante periodos de tiempo.
  • Predicados para consultar períodos de tiempo, a menudo basados ​​en las relaciones de intervalo de Allen.

Historia

Con el desarrollo de SQL y su posterior uso en aplicaciones reales, los usuarios de bases de datos se percataron de que al añadir columnas de fecha a los campos clave surgían algunos problemas. Por ejemplo, si una tabla tiene una clave primaria y algunos atributos, añadir una fecha a la clave primaria para registrar cambios históricos puede generar más filas de las previstas. Las eliminaciones también deben gestionarse de forma diferente cuando las filas se registran de esta manera. En 1992, se reconoció este problema, pero la teoría estándar de bases de datos aún no lo había resuelto, ni tampoco el estándar SQL-92, recientemente formalizado .

En 1992, Richard Snodgrass propuso que la comunidad de bases de datos temporales desarrollara extensiones temporales para 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); dichas 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 Bases de Datos SQL, el Comité Técnico ANSI X3H2 (ahora conocido como NCITS H2). La especificación preliminar del lenguaje apareció en el ACM SIGMOD Record de marzo de 1994. Con base en las respuestas a dicha 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 al nuevo estándar SQL SQL:1999 , denominado SQL3. Partes de TSQL2 se incluyeron en un nuevo subestándar de SQL3, ISO/IEC 9075-7, denominado SQL/Temporal. [ 3 ] El enfoque de TSQL2 fue duramente criticado por Chris Date y Hugh Darwen . [ 5 ] El proyecto ISO responsable del soporte temporal se canceló a finales de 2001.

A partir de diciembre de 2011, la norma ISO/IEC 9075, Lenguaje de bases de datos SQL:2011 Parte 2: SQL/Foundation, incluyó cláusulas en las definiciones de tablas para definir "tablas de período de tiempo de aplicación" ( tablas de tiempo válidas ), "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 la adoptada en SQL:2011 es que no hay columnas ocultas en el tratamiento de SQL:2011, ni tampoco un nuevo tipo de datos para intervalos; en su lugar, dos columnas con marcas de tiempo (DS) o marcas de tiempo (DTS) pueden vincularse mediante una PERIOD FORdeclaración. Otra diferencia es la sustitución de los modificadores de sentencia (prefijo) controvertidos 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, las claves primarias temporales, la integridad referencial temporal, los predicados temporales con el álgebra de intervalos de Allen y las consultas segmentadas y secuenciadas en el tiempo.

Ejemplo

A modo de ejemplo, consideremos la siguiente breve biografía de un hombre ficticio, John Doe:

John Doe nació el 3 de abril de 1975 en el Hospital Infantil del Condado de Medicina, hijo de Jack Doe y Jane Doe, quienes 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 niño alegre, se convirtió en un estudiante brillante y se graduó con honores en 1993. Después de graduarse, se fue a vivir solo a Bigtown. Aunque se mudó el 26 de agosto de 1994, olvidó registrar oficialmente el cambio de domicilio. Fue solo con el cambio de estación que su madre le recordó que debía registrarse, lo cual hizo unos días después, el 27 de diciembre de 1994. Aunque John tenía un futuro prometedor, su historia terminó trágicamente. John Doe fue atropellado accidentalmente por un camión el 1 de abril de 2001. El forense informó su fecha de muerte ese mismo día.

Utilizando una base de datos no temporal

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 primaria de person.)

El padre de John informó oficialmente 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). Cabe señalar 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 se modifica 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 ha sido sobrescrita, por lo que ya no es posible recuperar esa información de la base de datos. 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 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 .SELECTADDRESSFROMPERSONWHERENAME='John Doe'SmallvilleBigtown

Hasta su fallecimiento, la base de datos indicaba que residía en Bigtown. El 1 de abril de 2001, el forense eliminó la entrada de John Doe de la base de datos. A partir de entonces, al ejecutar la consulta anterior no se obtendría ningún resultado.

Utilizando un único eje: tiempo válido o tiempo de transacción.

El tiempo válido es el período durante el cual un hecho es verdadero en el mundo real. Un período de tiempo válido puede ser pasado, abarcar el presente o ocurrir en el futuro.

Para el ejemplo anterior, para registrar la validez temporal, personse agregaron dos campos a la tabla: valid_fromy valid_to. Estos especifican el período durante el cual 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. Un funcionario insertó una nueva entrada en la base de datos indicando que John vive en Smallville desde el 3 de abril. Cabe destacar que, si bien los datos se insertaron el día cuatro, la base de datos indica que la información es válida desde el día tres. El funcionario aún desconoce si John se mudará a otro lugar ni cuándo lo hará, 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 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 elimina, pero se valid_toactualiza 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 fallece, 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í:

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

El registro de tiempo de transacción indica el período durante el cual una entrada en la base de datos se considera correcta. Esto permite realizar consultas que muestran el estado de la base de datos en un momento dado. Los períodos de tiempo de transacción solo pueden abarcar el pasado o el momento actual. En una tabla de tiempo de transacción, los registros nunca se eliminan. Solo se pueden insertar nuevos registros y actualizar los existentes estableciendo su hora de finalización de transacción para indicar que ya no están vigentes.

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 tiempo en que se realizó una transacción, y transaction_toes el tiempo en que la transacción fue reemplazada (que puede ser infinito si aún no ha sido reemplazada). Esto convierte la tabla en una tabla bitemporal .

¿Qué sucede si la dirección de la persona registrada en la base de datos es incorrecta? ¿Qué ocurre si un funcionario ingresa por error una dirección o fecha errónea? ¿O si 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. Sin embargo, para evitar pagar el exorbitante impuesto de residencia de Beachy, nunca lo declaró a las autoridades. Posteriormente, durante una investigación fiscal, el 2 de febrero de 2001 se descubrió que, de hecho, se encontraba 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 indique su residencia en Beachy. La base de datos quedaría entonces de la siguiente manera:

Sin embargo, esto no deja constancia de que la base de datos indicara que residió 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 como prueba en la investigación fiscal del funcionario. El registro de tiempo de transacción permite capturar este cambio de información en la base de datos, ya que las entradas nunca se modifican ni se eliminan directamente. En cambio, cada entrada registra cuándo se introdujo y cuándo se sustituyó (o se eliminó lógicamente). El contenido de la base de datos quedaría así:

La base de datos registra no solo lo que sucedió en el mundo real, sino también lo que se registró oficialmente en diferentes momentos.

Utilizando 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 transacción para registrar el momento en que una entrada de la base de datos puede aceptarse como correcta. Esto permite realizar consultas que muestran los hechos reconocidos oficialmente en un momento dado, 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 periodos de decisión solo pueden ser anteriores 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 nuevos registros y actualizar los existentes estableciendo su hora de finalización de decisión para indicar 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_toes el momento en que la decisión fue reemplazada (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 reales que ocurrieron entre las elecciones presidenciales de Estados Unidos de 1964 y 1976 :

En este ejemplo, se asume 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 guardan en la base de datos. Dadas estas 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 era 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:

  • Nixon/Agnew utilizando una fecha de decisión y una fecha de transacción del 14 de noviembre de 1972.
  • Nixon/(Vacante) al usar un tiempo de decisión y un tiempo de transacción del 17 de octubre de 1973
  • Nixon/Ford al usar un tiempo de decisión y un tiempo de transacción del 8 de agosto de 1974
  • Ford/(Vacante) al usar un tiempo de decisión del 8 de agosto de 1974 y un tiempo de transacción actual
  • Ford/Rockefeller al utilizar un tiempo de decisión y un tiempo de transacción de la actualidad

Modelado bitemporal

Un modelo bitemporal contiene tanto el tiempo de validez como el tiempo 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?") la proporciona el tiempo de validez. La información de reversión (por ejemplo: "¿En 1992, la base de datos creía que vivía John?") la proporciona el tiempo de transacción. Las respuestas a estas preguntas de ejemplo pueden no ser las mismas , ya que la base de datos podría haber sido modificada desde 1992, lo que provocaría que las consultas produjeran resultados diferentes. 

La fecha de validez y la fecha de transacción no tienen por qué coincidir para un mismo dato. Por ejemplo, consideremos una base de datos temporal que almacena información sobre el siglo XVIII. La fecha de validez de estos datos se sitúa entre 1701 y 1800. La fecha de transacción indicaría cuándo se insertaron los datos en la base de datos (por ejemplo, el 21 de enero de 1998).

Evolución del esquema

Un problema complejo es la compatibilidad con consultas temporales en una base de datos de tiempo de transacción bajo un esquema evolutivo . Para lograr una calidad de archivo perfecta, es fundamental almacenar los datos bajo la versión del esquema en la que aparecieron por primera vez. Sin embargo, incluso la consulta temporal más simple, que reescribe el historial de un valor de atributo, requeriría ser reescrita manualmente bajo cada una de las versiones del esquema, potencialmente cientos, como en el caso de MediaWiki . [ 7 ] Este proceso sería particularmente tedioso 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 la complejidad de la evolución de los esquemas son:

Implementaciones en productos destacados

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

  • MariaDB versión 10.3.4 agregó soporte para el estándar SQL:2011 como "Tablas con versiones del sistema". [ 11 ]
  • Oracle Database – Oracle Workspace Manager es una función de Oracle Database que permite a los desarrolladores de aplicaciones y a los administradores de bases de datos gestionar las versiones actuales, propuestas e históricas de los datos en la misma base de datos. 
  • La versión 9.2 de PostgreSQL agregó tipos de datos de rango nativos que pueden implementar todas las características de la extensión temporal aportada por pgFoundry. [ 12 ] [ 13 ] Los tipos de rango de PostgreSQL son compatibles con numerosos operadores y funciones nativas.
  • Teradata ofrece dos productos. Teradata versión 13.10 y Teradata versión 14 tienen características temporales basadas en TSQL2 [ 14 ] integradas en la base de datos.
  • IBM Db2 versión 10 agregó una característica llamada "consulta de viaje en el tiempo" [ 2 ] que se basa en las capacidades temporales del estándar SQL:2011 . [ 1 ]
  • Microsoft SQL Server introdujo las tablas temporales como una característica para SQL Server 2016. Esta característica se describe en un vídeo del sitio web "Channel 9" de Microsoft. [ 15 ]

Sistemas de gestión de bases de datos no relacionales, NoSQL, que proporcionan características temporales, entre las que se incluyen 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 modernos de control de versiones de datos. [ 18 ]

Alternativas

Ejemplo de modelo de dimensión de cambio lento (SCD, por sus siglas en inglés)

Las dimensiones que cambian lentamente pueden utilizarse para modelar relaciones temporales.

Lecturas adicionales

  • CJ Date , Hugh Darwen , Nikos Lorentzos (2002). Datos temporales y el modelo relacional, primera edición (Serie Morgan Kaufmann en sistemas de gestión de datos); Morgan Kaufmann; 1.ª edición; 422 páginas. ISBN 1-55860-855-9.
  • Joe Celko (2014). SQL para expertos de Joe Celko: Programación SQL avanzada (Serie Morgan Kaufmann de gestión de datos); Morgan Kaufmann; 5.ª edición. ISBN 978-0-12-800761-7—Los capítulos 12 y 35, en particular, abordan cuestiones temporales.
  • Snodgrass, Richard T. (1999). " Desarrollo de aplicaciones de bases de datos orientadas al tiempo en SQL " (PDF) . (4,77 MiB )  (Serie Morgan Kaufmann en Sistemas de Gestión de Datos); Morgan Kaufmann; 504 páginas; ISBN 1-55860-436-7

Véase también

Referencias

  1. 1 2 3 Kulkarni, Krishna y Jan-Eike Michels. " Características temporales en SQL: 2011 ". ACM SIGMOD Record 41.3 (2012): 34-43.
  2. 1 2 Saracco, Cynthia M.; Nicola, Matthias; Gandhi, Lenisha (3 de abril de 2012). "Una cuestión de tiempo: Gestión de datos temporales en DB2 10" . IBM . Archivado del original el 25 de octubre de 2012. Recuperado el 27 de octubre de 2020 .
  3. 1 2 Snodgrass, 1999, pág. 9
  4. ↑ Richard T. Snodgrass . "TSQL2 Lenguaje de consulta temporal" . www.cs.arizona.edu . Departamento de Ciencias de la Computación de la Universidad de Arizona . Consultado el 14 de julio de 2009 .
  5. ↑ Hugh Darwen, CJ Date, “ Una visión general y análisis de las propuestas basadas en el enfoque TSQL2 ”, en Date on Database: Writings 2000-2006 , CJ Date, Apress, 2006, pp. 481-514
  6. ↑ Mario A. Nascimento, Margaret H. Eich, “ Tiempo de decisión en bases de datos temporales ”, En Actas del Segundo Taller Internacional sobre Representación y Razonamiento Temporal , 1995, págs. 157-162
  7. ↑ Prueba comparativa de evolución de esquemas - Evolución de esquemas
  8. ↑ Hyun J. Moon; Carlo A. Curino; Alin Deutsch; C.-Y. Hou y Carlo Zaniolo (2008). Gestión y consulta de bases de datos en tiempo de transacción bajo evolución de esquema . Very Large Data Base VLDB. Archivado del original el 27-03-2024 . Recuperado el 11-06-2008 .
  9. ↑ Hyun J. Moon; Carlo A. Curino y Carlo Zaniolo (2010). Arquitectura escalable y optimización de consultas para bases de datos en tiempo de transacción con esquemas evolutivos . SIGMOD. Archivado del original el 27 de marzo de 2024. Recuperado el 6 de febrero de 2010 .
  10. ↑ Anthony B. Coates (2015). Por qué a los bancos les importa la bitemporalidad . MarkLogic World 2015.
  11. ↑ "Tablas con versiones del sistema" . Archivado del original el 24/01/2018 . Consultado el 24/01/2018 .
  12. ↑ Paquier, Michael (1 de noviembre de 2012). "Postgres 9.2 highlight: range types" . Michael Paquier - Desarrollador de código abierto radicado en Japón . Archivado del original el 23 de abril de 2016.
  13. ↑ Katz, Jonathan S. "Tipos de rango: Tu vida nunca será la misma" (PDF) . Consultado el 14 de julio de 2014 .
  14. ↑ Al-Kateb, Mohammed et al. " Procesamiento de consultas temporales en Teradata ". EDBT/ICDT '13, 18-22 de marzo de 2013, Génova, Italia.
  15. ↑ Temporal en SQL Server 2016 , archivado del original el 07/05/2021 , recuperado el 19/07/2019.
  16. ↑ "terminusdb/terminusdb-server" . GitHub . Consultado el 4 de septiembre de 2020 .
  17. ↑ Bridgwater, Adrian (24 de noviembre de 2014). "Los datos son buenos, los datos 'bidireccionales bitemporales' son mejores" . Forbes .
  18. ^ Bhardwaj, Anant; Bhattacherjee, Souvik; Chavan, Amit; Deshpande, Amol; Elmore, Aaron J.; Enloquecer, Samuel; Parameswaran, Aditya G. (2 de septiembre de 2014). "DataHub: ciencia de datos colaborativa y gestión de versiones de conjuntos de datos a escala". arXiv : 1409.0798 [ cs.DB ].
  • "Página principal de TimeCenter" . TimeCenter . Departamento de Informática de la Universidad de Arizona. Archivado del original el 24 de febrero de 2020.
  • Relaciones temporales en RDF
  • Alcance temporal para triples RDF
  • IBM DB2 10 para z/OS
  • Serie de artículos " Una y otra vez" de Randy Weis y Tom Johnston.
  • Patrones temporales por Martin Fowler