Почему нам нужна временная база данных?

Мое понимание временных баз данных заключается в том, что они ориентированы на хранение определенных типов временной информации. Вы можете смоделировать это с помощью стандартной СУБД, но, используя базу данных, которая ее поддерживает, у вас есть встроенные идиомы для многих концепций, и язык запросов может быть оптимизирован для такого рода запросов.

Для меня это немного похоже на работу с базой данных ГИС, а не с СУБД. В то время как вы могли бы перемещать координаты в обычной СУБД, наличие соответствующих представлений (например, через файлы сетки) может быть быстрее, а наличие примитивов SQL для таких вещей, как топология, полезно.

Существуют академические базы данных и некоторые коммерческие. Timecenter имеет несколько ссылок.

Насколько я понимаю (и чрезмерно упрощенно), временная база данных записывает факты о том, когда данные были действительны, а также сами данные, и позволяет вам запрашивать временные аспекты. , В итоге вы работаете с таблицами «действительное время» и «время транзакции» или «битемпоральными таблицами», включающими аспекты «действительное время» и «время транзакции». Вы должны рассмотреть вопрос о чтении любой из этих двух книг:

• Дарвен, Дата и Лоренцо " Временные данные и реляционная модель " (из печати),
• и (в радикально отличном крайнем случае) " Разработка ориентированных на время приложений баз данных в SQL ", Ричард Т. Снодграсс, Morgan Kaufmann Publishers, Inc., Сан-Франциско, июль 1999 г., 504 + xxiii pages, ISBN 1-55860-436-7. Это распечатано, но доступно в формате PDF на его веб-сайте по адресу cs.arizona.edu (поэтому поиск в Google позволяет довольно легко его найти).

Кроме чтения статьи из Википедии ? База данных, которая поддерживает «журнал аудита» или аналогичный журнал транзакций, будет иметь некоторые свойства «временного». Если вам нужны ответы на вопросы о , кто что сделал, с кем и когда , то у вас есть хороший кандидат для временной базы данных.

Вы можете представить простую временную базу данных, которая регистрирует ваше местоположение GPS каждые несколько секунд. Возможности для сжатия этих данных велики, обычная база данных, вам нужно будет хранить временную метку для каждой строки. Если вам требуется большая пропускная способность, знание того, что данные являются временными, и что обновления и удаление строки никогда не потребуются, позволяет программе отбрасывать большую часть сложности, унаследованной в типичной СУБД.

Несмотря на это, временная Данные обычно просто хранятся в обычной РСУБД. PostgreSQL, например, имеет некоторые временные расширения , что делает это немного проще.

На ум приходят две причины:

1. Некоторые из них оптимизированы для вставки и только для чтения и могут предложить значительные улучшения производительности
2. Некоторые из них лучше понимают время, чем традиционный SQL - с учетом группировки операций по секундам, минутам, часам и т. д.

Другой пример, где временная база данных полезна, это когда данные меняются со временем. Я провел несколько лет, работая в розничной сети, где мы сохраняли показания счетчиков в течение 30 минут. Эти показания счетчиков могут быть пересмотрены в любой момент, но нам все еще нужно было иметь возможность просмотреть историю изменений показаний.

Поэтому мы получили последнее показание (наше «текущее понимание» потребления за 30 минут). ) но мог бы оглянуться назад на наше историческое понимание потребления. Когда у вас есть данные, которые можно настроить таким образом, чтобы временные базы данных работали хорошо.

(Сказав это, мы вырезали их вручную в SQL, но это было довольно давно. Не принял бы это решение в эти дни.)

Подумайте о своем дневнике назначения/дневника - он идет с 1 января по 31 декабря. Теперь мы можем запрашивать в дневнике записи о встречах/ записях в журнале в любой день. Это упорядочение называется допустимым временем. Однако назначения/записи обычно не вставляются по порядку.

Предположим, я хотел бы знать, какие встречи / записи были в моем дневнике 4 апреля. То есть все записи, которые существовали в моем дневнике на 4 апреля. Это время транзакции.

Учитывая, что встречи/записи могут быть созданы и удалены и т.д.Типичная запись имеет время начала и окончания, которое охватывает период записи, и время начала и окончания транзакции, которое указывает на период, в течение которого запись появилась в дневнике.

Такая договоренность необходима, когда дневник может подвергаться историческому пересмотру. Предположим, 5 апреля я понимаю, что встреча, которая у меня была 14 февраля, на самом деле произошла 12 февраля, т.е. я обнаруживаю ошибку в своем дневнике - я могу исправить ошибку, чтобы исправить достоверную картину времени, но теперь мой запрос о том, что было в дневнике 4 апреля, был бы неправильным, ЕСЛИ только время транзакций для встреч/записей также сохраняется. В том случае, если я запрошу свой дневник по состоянию на 4 апреля, он покажет, что встреча существовала 14 февраля, но если я запрошу по состоянию на 6 апреля, она покажет встречу 12 февраля.

Эта функция путешествия во времени временной базы данных позволяет записывать информацию о том, как исправляются ошибки в базе данных.Это необходимо для получения достоверной картины аудита данных, которая фиксирует, когда были внесены изменения, и позволяет запрашивать вопросы, касающиеся того, как данные были пересмотрены. Время.

Большая часть бизнес-информации должна храниться в этой схеме bitemporal, чтобы обеспечить истинную аудиторскую запись и максимизировать бизнес-аналитику - отсюда и необходимость поддержки в реляционной базе данных. Обратите внимание, что каждый элемент данных занимает (возможно, неограниченный) квадрат в двухмерной модели времени, поэтому люди часто используют индекс GIST для реализации индексации bitemporal. Проблема здесь в том, что индекс GIST действительно предназначен для географических данных, а требования к временным данным несколько отличаются.

Ограничения исключения PostgreSQL 9.0 должны предусматривать новые способы организации временных данных, например, транзакции и допустимые временные PERIOD не должны перекрываться для одного и того же кортежа.