¿Por qué necesitamos una base de datos temporal?

Considere su cita/diario - va desde el 1 de enero hasta el 31 de diciembre. Ahora podemos consultar el diario para citas/entradas del diario en cualquier día. Este orden se llama tiempo válido. Sin embargo, las citas/entradas generalmente no se insertan en orden.

Supongamos que me gustaría saber qué citas/entradas estaban en mi diario el 4 de abril. Es decir, todos los registros que existían en mi diario el 4 de abril. Este es el tiempo de transacción.

Dado que las citas / entradas se pueden crear y eliminar, etc. Un registro típico tiene un tiempo válido de inicio y fin que cubre el período de la entrada y un tiempo de transacción de inicio y fin que indica el período durante el cual la entrada apareció en el diario.

Esta disposición es necesaria cuando el diario puede someterse a revisión histórica. Supongamos que el 5 de abril me doy cuenta de que la cita que tuve el 14 de Febrero realmente ocurrió el 12 de febrero, es decir, descubro un error en mi diario: puede corregir el error para que se corrija la imagen de tiempo válida, pero ahora, mi consulta de lo que estaba en el diario el 4 de abril estaría mal, A menos que también se almacenen los tiempos de transacción para citas/entradas. En ese caso, si consulta mi diario a partir del 4 de abril se mostrará una cita existió el 14 de febrero, pero si la consulta a partir del 6 de abril se mostrará una cita el 12 de febrero.

Esta característica de viaje en el tiempo de una base de datos temporal permite registrar información sobre cómo se corrigen los errores en una base de datos. Esto es necesario para obtener una verdadera imagen de auditoría de los datos que registra cuándo se realizaron las revisiones y permite realizar consultas relacionadas con la forma en que se revisaron los datos tiempo.

La mayor parte de la información comercial debe almacenarse en este esquema bitemporal para proporcionar un verdadero registro de auditoría y maximizar la inteligencia comercial, de ahí la necesidad de soporte en una base de datos relacional. Observe que cada elemento de datos ocupa un cuadrado (posiblemente ilimitado) en los dos modelo de tiempo dimensional por lo que la gente a menudo utiliza un índice GIST para implementar la indexación bitemporal. El problema aquí es que un índice GIST está realmente diseñado para datos geográficos y los requisitos para los datos temporales son algo diferentes.

Las restricciones de exclusión de PostgreSQL 9.0 deben proporcionar nuevas formas de organizar los datos temporales, por ejemplo, las transacciones y los períodos de tiempo válidos no deben superponerse para la misma tupla.

Según lo entiendo (y simplificando enormemente), una base de datos temporal registra datos sobre cuándo los datos eran válidos, así como los datos en sí, y le permite consultar los aspectos temporales. Terminas lidiando con tablas de' tiempo válido 'y' tiempo de transacción', o' tablas bitemporales 'que involucran aspectos de' tiempo válido 'y' tiempo de transacción'. Usted debe considerar la lectura de cualquiera de estos dos libros:

• Darwen, Date and Lorentzos " Datos Temporales y Relacionales Modelo" (agotado),
• and (at a radically different extreme)" Developing Time-Oriented Database Applications in SQL", Richard T. Snodgrass, Morgan Kaufmann Publishers, Inc., San Francisco, July, 1999, 504 + xxiii pages, ISBN 1-55860-436-7. Eso está fuera de impresión, pero disponible como PDF en su sitio web en cs.arizona.edu (por lo que una búsqueda en Google hace que sea bastante fácil de encontrar).

Las bases de datos temporales se utilizan a menudo en la industria de servicios financieros. Una razón es que rara vez (si es que alguna vez) se le permite eliminar cualquier dato, por lo que los campos de tipo ValidFrom - ValidTo en los registros se utilizan para proporcionar una indicación de cuándo un registro era correcto.

Aparte de leer el artículo de Wikipedia? Una base de datos que mantenga un "registro de auditoría" o un registro de transacciones similar tendrá algunas propiedades de ser "temporal". Si necesitas respuestas a preguntas sobre quién hizo qué a quién y cuándo entonces tienes un buen candidato para una base de datos temporal.

Puede imaginar una base de datos temporal simple que solo registra su ubicación GPS cada pocos segundos. Las oportunidades para comprimir estos datos son excelentes, una base de datos normal que necesitaría almacenar una marca de tiempo para cada fila. Si se requiere una gran cantidad de rendimiento, saber que los datos son temporales y que las actualizaciones y eliminaciones a una fila nunca serán necesarias permite que el programa elimine gran parte de la complejidad heredada en un RDBMS típico.

A pesar de esto, los datos temporales suelen ser sólo se almacena en un RDBMS normal. PostgreSQL, por ejemplo, tiene algunas extensiones temporales, lo que hace esto un poco más fácil.

Dos razones vienen a la mente:

1. Algunos están optimizados para insertar y solo lectura y pueden ofrecer mejoras dramáticas de perf
2. Algunos tienen una mejor comprensión del tiempo que el SQL tradicional, lo que permite agrupar operaciones por segundo, minuto, hora, etc

Solo una actualización, Base de datos temporal está llegando a SQL Server 2016.

Para aclarar todas sus dudas sobre por qué uno necesita una Base de datos Temporal, en lugar de configurarla con métodos personalizados, y qué tan eficiente y sin problemas SQL Server la configura para usted, consulte el video en profundidad y la demostración en Channel9.msdn aquí: https://channel9.msdn.com/Shows/Data-Exposed/Temporal-in-SQL-Server-2016

Enlace MSDN: https://msdn.microsoft.com/en-us/library/dn935015 (v = sql.130).aspx

Actualmente con la versión CTP2 (beta 2) de SQL Server 2016 puedes jugar con ella.

Compruebe este video sobre cómo usar Tablas Temporales en SQL Server 2016.

Además de "qué cosas nuevas puedo hacer con él", podría ser útil considerar "¿qué cosas viejas unifica?". La base de datos temporal representa una generalización particular de la base de datos SQL "normal". Como tal, puede darle una solución unificada a problemas que anteriormente parecían no relacionados. Por ejemplo:

• Web Concurrency Cuando su base de datos tiene una interfaz de usuario web que permite a varios usuarios realizar modificaciones estándar de Creación / Actualización / Eliminación (CRUD), debe enfrentar problema de cambios web concurrentes . Básicamente, debe verificar que una modificación de datos entrantes no afecte a ningún registro que haya cambiado desde la última vez que el usuario vio esos registros. Pero si tiene una base de datos temporal, es muy posible que ya asocie algo como un "ID de revisión" con cada registro (debido a la dificultad de hacer que las marcas de tiempo sean únicas y monótonamente ascendentes). Si es así, entonces eso se convierte en el mecanismo natural, "ya incorporado" para prevenir el golpe de datos de otros usuarios durante las actualizaciones de la base de datos.
• Registros Legales/Fiscales El sistema legal (incluidos los impuestos) pone más énfasis en los datos históricos que la mayoría de los programadores. Por lo tanto, a menudo encontrará consejos sobre esquemas para facturas y tal que le advierte que tenga cuidado de eliminar registros o normalizar de una manera natural?lo que puede conducir a una incapacidad para responder a preguntas legales básicas como "Olvídese de su dirección actual, ¿a qué dirección envió esta factura en 2001?" Con una base de marco temporal, todas las maquinaciones para esos problemas (por lo general son pasos a medio camino para tener una base de datos temporal) desaparecen. Solo tiene que utilizar el esquema más natural, y eliminar cuando tiene sentido, sabiendo que siempre se puede volver atrás y responder a las preguntas históricas con precisión.

Por otro lado, el modelo temporal en sí está a mitad de camino para completar el control de revisiones, lo que podría inspirar nuevas aplicaciones. Por ejemplo, supongamos que usted pone en marcha su propia instalación temporal parte superior de SQL y permitir la ramificación, como en los sistemas de control de revisiones. Incluso la ramificación limitada podría hacer que sea fácil ofrecer "sandboxing" - la capacidad de jugar y modificar la base de datos con abandono sin causar ningún cambio visible a otros usuarios. Eso hace que sea fácil proporcionar capacitación de usuario altamente realista en una base de datos compleja.

La bifurcación simple con una facilidad de fusión simple también podría simplificar algunos problemas comunes de flujo de trabajo. Por ejemplo, una organización sin fines de lucro podría tener voluntarios o trabajadores ingresando datos. Dar a cada trabajador su propia rama podría hacer que sea fácil permitir que un supervisor revise su trabajo o lo mejore (por ejemplo, des-duplificación) antes de fusionarlo en la rama principal donde se haría visible para los usuarios "normales". Las ramas también podrían simplificar los permisos. Si a un usuario solo se le concede permiso para usar/ver su rama única, no tiene que preocuparse por evitar todas las posibles modificaciones no deseadas; solo fusionará los cambios que tengan sentido Por cierto.

Mi comprensión de las bases de datos temporales es que están orientadas a almacenar ciertos tipos de información temporal. Podría simular eso con un RDBMS estándar, pero al usar una base de datos que lo soporte, tiene expresiones integradas para muchos conceptos y el lenguaje de consulta podría optimizarse para este tipo de consultas.

Para mí esto es un poco como trabajar con una base de datos específica de SIG en lugar de un RDBMS. Mientras que usted podría empujar coordenadas en un RDBMS corriente-de-la-fábrica, teniendo el las representaciones apropiadas (por ejemplo, a través de archivos de cuadrícula) pueden ser más rápidas, y tener primitivas SQL para cosas como topología es útil.

Existen bases de datos académicas y algunas comerciales. Timecenter tiene algunos enlaces.

Otro ejemplo de donde una base de datos temporal es útil es donde los datos cambian con el tiempo. Pasé unos años trabajando para un minorista de electricidad donde almacenamos lecturas de medidores durante 30 minutos. Esas lecturas de los medidores podrían revisarse en cualquier momento, pero todavía necesitábamos poder mirar hacia atrás en la historia de los cambios para las lecturas.

Por lo tanto, tuvimos la última lectura (nuestra 'comprensión actual' del consumo de los 30 minutos), pero pudimos mirar hacia atrás en nuestro comprensión histórica del consumo. Cuando tienes datos que se pueden ajustar de tal manera las bases de datos temporales funcionan bien.

(Dicho esto, lo tallamos a mano en SQL, pero fue hace un buen rato. No tomaría esa decisión en estos días.)