Considere su cita/agenda diaria: va desde el 1 de enero hasta el 31 de diciembre. Ahora podemos consultar el diario para citas/entradas de diario en cualquier día. Este pedido 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 había en mi agenda el 4 de abril. Es decir, todos los registros que existieron en mi diario el 4 de abril. Este es el tiempo de transacción .
Dado que las citas/entradas se pueden crear y borrar etc. Un registro típico tiene un tiempo válido de inicio y final que cubre el período de la entrada y un tiempo de transacción de inicio y final que indica el período durante el cual el diario.
Esta disposición es necesaria cuando el diario puede someterse a la revisión histórica . Supongamos que el 5 de abril me doy cuenta de que la cita que tuve el 14 de febrero ocurrió en realidad el 12 de febrero, es decir, descubrí un error en mi diario. Puedo corregir el error para corregir la imagen temporal válida, pero ahora mi consulta de lo que era en el diario del 4 de abril sería incorrecto, A MENOS QUE los tiempos de transacción para las citas/entradas también estén almacenados. En ese caso, si consulto mi agenda a partir del 4 de abril, se mostrará una cita el 14 de febrero, pero si realizo una consulta a partir del 6 de abril, aparecerá una cita el 12 de febrero.
Esta función de desplazamiento 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 una verdadera imagen de auditoría de los datos que registra cuándo se realizaron las revisiones y permite consultas relacionadas con cómo se han revisado los datos durante el 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 de negocios, de ahí la necesidad de soporte en una base de datos relacional. Observe que cada elemento de datos ocupa un cuadrado (posiblemente ilimitado) en el modelo de tiempo bidimensional, por lo que las personas a menudo usan 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 deberían proporcionar nuevas formas de organizar los datos temporales, p. Los PERIODOS de transacción y tiempo válido no deben superponerse para la misma tupla.
Pi utiliza un algoritmo de compuerta oscilante, y debe considerarse una base de datos de compresión, no una base de datos temporal. Las bases de datos temporales conservan la capacidad de ver los datos tal como se veían en el pasado, a la vez que permiten la capacidad de actualizar incluso el pasado en el futuro. Esta disociación de tiempo válido y hora actual no existe en Pi. Pi muestra un valor pasado que no es estadísticamente diferente del valor real, una base de datos temporal le mostrará el valor real en ese momento, como se vio en ese momento, y el valor real en ese momento, como se conoce ahora (2 consultas diferentes)) –
@EdwinBuck - esto suena autoritario, pero no cita ninguna fuente. – codekaizen
Era integrador/herrero de herramientas para el sistema RARA SCADA, que tenía varios nombres, y fue vendido por Ferranti Systems, Elsag, Elsag/Bailey, Bailey Network Management, ABB Network Management y ahora solo ABB. Actualmente se vende bajo el nombre "Network Manager" a menos que lo hayan cambiado nuevamente. Escribí los ayudantes de instalación de Pi para esa plataforma, y di entrenamiento en el uso de Pi Historian, e instalé Pi (y un montón de otro software) en numerosas salas eléctricas de control SCADA. En el breve lapso de personajes, es difícil entrar en detalles. –