Рассмотрите вашу запись в дневнике - с 1 января по 31 декабря. Теперь мы можем запросить дневник для встреч / записей в журнале в любой день. Этот порядок называется действительное время . Тем не менее, встречи / записи обычно не вставляются в порядке.
Предположим, я хотел бы знать, какие встречи / записи были в моем дневнике 4 апреля. То есть все записи, которые существовали в моем дневнике 4 апреля. Это время транзакции .
Учитывая, что встречи / записи могут создаваться и удаляться и т. Д. Типичная запись имеет начальное и конечное действительное время, которое охватывает период записи, а также время начала и окончания транзакции, которое указывает период, в течение которого запись появилась в дневник.
Эта договоренность необходима, когда дневник может подвергнуться историческому пересмотру . Предположим, 5 апреля я понимаю, что встреча, которая была у меня 14 февраля, действительно произошла 12 февраля, то есть я обнаружил ошибку в своем дневнике - я могу исправить ошибку так, чтобы исправить действительное время, но теперь мой запрос о том, что было в дневнике за 4 апреля было бы неправильно, ЕСЛИ МЕНЬШЕ, время транзакций для встреч / записей также сохраняется. В этом случае, если я сделаю запрос на свой дневник по состоянию на 4 апреля, он покажет, что встреча существовала 14 февраля, но если я сделаю запрос по состоянию на 6 апреля, это будет означать встречу 12 февраля.
Эта функция перемещения во времени временной базы данных позволяет записывать информацию о том, как ошибки исправляются в базе данных. Это необходимо для достоверной картины аудита данных, которые записывают, когда были внесены изменения, и позволяет выполнять запросы, касающиеся того, как данные были пересмотрены в течение
время.
Большая часть бизнес-информации должна храниться в этой битемпоральной схеме, чтобы обеспечить достоверную запись аудита и максимизировать бизнес-аналитику - отсюда необходимость поддержки в реляционной базе данных. Обратите внимание, что каждый элемент данных занимает (возможно, неограниченный) квадрат в двумерной временной модели, поэтому люди часто используют индекс GIST для реализации битемпоральной индексации. Проблема здесь в том, что индекс GIST действительно предназначен для географических данных, а требования к временным данным несколько иные.
Ограничительные ограничения PostgreSQL 9.0 должны обеспечивать новые способы организации временных данных, например. Периоды транзакций и действительного времени не должны перекрываться для одного и того же кортежа.