Временная база данных хранит данные, относящиеся к моментам времени. Она предлагает временные типы данных и хранит информацию, относящуюся к прошлому, настоящему и будущему времени. Временные базы данных могут быть одновременными, двухвременными или трехвременными.
Более конкретно, временные аспекты обычно включают в себя действительное время , время транзакции и/или время принятия решения .
Одновременная база данных имеет одну ось времени: либо диапазон действия, либо диапазон системного времени.
Битемпоральная база данных имеет две оси времени:
Трехвременная база данных имеет три оси времени:
Такой подход вносит дополнительные сложности.
Временные базы данных отличаются от текущих баз данных (не путать с имеющимися в настоящее время базами данных), которые хранят только факты, которые считаются истинными в текущий момент времени.
Временные базы данных поддерживают управление и доступ к временным данным, предоставляя одну или несколько из следующих функций: [1] [2]
С развитием SQL и его сопутствующим использованием в реальных приложениях пользователи баз данных поняли, что при добавлении столбцов даты к ключевым полям возникают некоторые проблемы. Например, если таблица имеет первичный ключ и некоторые атрибуты, добавление даты к первичному ключу для отслеживания исторических изменений может привести к созданию большего количества строк, чем предполагалось. Удаления также должны обрабатываться по-другому, когда строки отслеживаются таким образом. В 1992 году эта проблема была признана, но стандартная теория баз данных еще не была готова к ее решению, как и недавно формализованный стандарт SQL-92 .
Ричард Снодграсс в 1992 году предложил, чтобы темпоральные расширения SQL разрабатывались сообществом темпоральных баз данных. В ответ на это предложение был сформирован комитет для разработки расширений к изданию стандарта SQL 1992 года (ANSI X3.135.-1992 и ISO/IEC 9075:1992); эти расширения, известные как TSQL2, были разработаны этим комитетом в 1993 году. [3] В конце 1993 года Снодграсс представил эту работу группе, ответственной за Американский национальный стандарт языка баз данных SQL, Техническому комитету ANSI X3H2 (теперь известному как NCITS H2). Предварительная спецификация языка появилась в отчете ACM SIGMOD за март 1994 года. На основе ответов на эту спецификацию в язык были внесены изменения, и окончательная версия спецификации языка TSQL2 была опубликована в сентябре 1994 года [4]
Была сделана попытка включить части TSQL2 в новый стандарт SQL SQL:1999 , названный SQL3. Части TSQL2 были включены в новый подстандарт SQL3, ISO/IEC 9075-7, названный SQL/Temporal. [3] Подход TSQL2 подвергся резкой критике со стороны Криса Дейта и Хью Дарвена . [5] Проект ISO, отвечающий за поддержку темпоральных баз данных, был отменен ближе к концу 2001 года.
По состоянию на декабрь 2011 года ISO/IEC 9075, язык баз данных SQL:2011 Часть 2: SQL/Foundation включали положения в определения таблиц для определения «таблиц периода времени приложения» ( допустимых таблиц времени), «системно-версионных таблиц» ( таблиц времени транзакций ) и «системно-версионных таблиц периода времени приложения» ( битемпоральных таблиц). Существенное различие между предложением TSQL2 и тем, что было принято в SQL:2011, заключается в том, что в обработке SQL:2011 нет скрытых столбцов, а также в ней нет нового типа данных для интервалов; вместо этого два столбца с метками даты (DS) или метками даты и времени (DTS) могут быть связаны вместе с помощью PERIOD FORобъявления. Другое отличие заключается в замене спорных (префиксных) модификаторов операторов из TSQL2 набором временных предикатов. [1]
Другие функции стандарта SQL:2011 , связанные с временными базами данных, включают автоматическое разделение временных периодов, временные первичные ключи, временную ссылочную целостность, временные предикаты с алгеброй интервалов Аллена , а также запросы с временными срезами и последовательностями.
Для иллюстрации рассмотрим следующую краткую биографию вымышленного человека, Джона Доу:
Для хранения жизни Джона Доу в текущей (не временной) базе данных мы используем таблицу person (name, address). (Для упрощения nameопределяется как первичный ключperson .)
Отец Джона официально сообщил о его рождении 1975-04-04. В этот день должностное лицо Смолвиля внесло следующую запись в базу данных: Person(John Doe, Smallville). Обратите внимание, что сама дата не хранится в базе данных.
После окончания школы Джон съезжает, но забывает зарегистрировать свой новый адрес. Запись Джона в базе данных не меняется до 1994-12-27, когда он наконец сообщает об этом. Чиновник Bigtown обновляет его адрес в базе данных. personТеперь таблица содержит Person(John Doe, Bigtown). Обратите внимание, что информация о Джоне, проживающем в Смолвиле, была перезаписана, поэтому извлечь эту информацию из базы данных больше невозможно. Чиновник, обращающийся к базе данных 1994-12-28, получит сообщение о том, что Джон проживает в Bigtown. Более технически: если администратор базы данных выполнит запрос 1994-12-26, результатом будет . Выполнение того же запроса через 2 дня приведет к .SELECT ADDRESS FROM PERSON WHERE NAME='John Doe'SmallvilleBigtown
До его смерти в базе данных указывалось, что он жил в Бигтауне. 2001-04-01 коронер удаляет запись о Джоне Доу из базы данных. После этого выполнение вышеуказанного запроса не вернуло бы вообще никакого результата.
Действительное время — это время, для которого факт является истинным в реальном мире. Действительный период времени может быть в прошлом, охватывать текущее время или происходить в будущем.
Для приведенного выше примера для записи действительного времени personв таблицу добавлены два поля valid_fromи valid_to. Они определяют период, когда адрес человека действителен в реальном мире. 1975-04-04 отец Джона зарегистрировал рождение своего сына. Затем должностное лицо вставляет новую запись в базу данных, в которой говорится, что Джон живет в Смолвиле с 3 апреля. Обратите внимание, что хотя данные были добавлены четвертого числа, база данных утверждает, что информация действительна с третьего. Должностное лицо еще не знает, переедет ли Джон в другое место и когда это произойдет, поэтому valid_toполе установлено на бесконечность (∞). Запись в базе данных следующая:
1994-12-27 Джон сообщает свой новый адрес в Бигтауне, где он живет с 1994-08-26. В базу данных вносится новая запись для фиксации этого факта:
Первоначальная запись Person (John Doe, Smallville, 1975-04-03, ∞)не удалена, но атрибут valid_toобновлен, чтобы отразить, что теперь известно, что Джон перестал жить в Смолвиле 1994-08-26. База данных теперь содержит две записи для Джона Доу:
Когда Джон умирает, его текущая запись в базе данных обновляется, указывая, что Джон больше не живет в Бигтауне. База данных теперь выглядит так:
Время транзакции регистрирует период времени, в течение которого запись базы данных принимается как правильная. Это позволяет выполнять запросы, которые показывают состояние базы данных в заданное время. Периоды времени транзакции могут иметь место только в прошлом или до текущего времени. В таблице времени транзакции записи никогда не удаляются. Могут быть вставлены только новые записи, а существующие обновлены путем установки времени окончания транзакции, чтобы показать, что они больше не являются актуальными.
Чтобы включить время транзакции в примере выше, в таблицу Person добавляются еще два поля: transaction_fromи transaction_to. Здесь — transaction_fromвремя совершения транзакции, а transaction_to— время, когда транзакция была заменена (которое может быть бесконечностью, если она еще не была заменена). Это превращает таблицу в битемпоральную таблицу.
Что произойдет, если адрес человека, сохраненный в базе данных, неверен? Предположим, что чиновник случайно ввел неправильный адрес или дату? Или, предположим, что человек по какой-то причине солгал о своем адресе. После обнаружения ошибки чиновники обновляют базу данных, чтобы исправить записанную информацию.
Например, с 1995-06-01 по 2000-09-03 Джон Доу переехал в Бичи. Но чтобы не платить непомерный налог на проживание в Бичи, он никогда не сообщал об этом властям. Позже, во время налогового расследования, 2 февраля 2001 года выясняется, что он на самом деле был в Бичи в эти даты. Чтобы зафиксировать этот факт, существующую запись о проживании Джона в Бигтауне необходимо разделить на две отдельные записи, а также вставить новую запись, фиксирующую его место жительства в Бичи. Тогда база данных будет выглядеть следующим образом:
Однако это не оставляет никаких записей о том, что база данных когда-либо утверждала, что он жил в Бигтауне в период с 1995-06-01 по 2000-09-03. Это может быть важно знать для целей аудита или для использования в качестве доказательства в налоговом расследовании чиновника. Время транзакции позволяет фиксировать эти изменяющиеся знания в базе данных, поскольку записи никогда напрямую не изменяются и не удаляются. Вместо этого каждая запись записывает, когда она была введена и когда она была заменена (или логически удалена). Содержимое базы данных тогда выглядит следующим образом:
В базе данных фиксируется не только то, что произошло в реальном мире, но и то, что было официально зафиксировано в разное время.
Время принятия решения является альтернативой периоду времени транзакции для записи времени, в которое запись в базе данных может быть принята как верная. Это позволяет выполнять запросы, которые показывают официально признанные факты в определенное время, даже если была задержка в фиксации этих фактов в базе данных. Поддержка времени принятия решения сохраняет всю историю и предотвращает потерю информации во время обновлений. [6]
Периоды времени принятия решения могут иметь место только в прошлом или до времени транзакции. Как и в таблице времени транзакции, записи никогда не удаляются. Можно вставлять только новые записи, а существующие обновлять, устанавливая время окончания решения, чтобы показать, что они больше не актуальны.
Чтобы включить время принятия решения, в таблицу базы данных добавляются еще два поля: decision_fromи decision_to. Здесь — decision_fromвремя принятия решения, а decision_to— время, когда решение было заменено (которое может быть бесконечностью, если оно еще не было заменено). В сочетании со временем транзакции это превращает таблицу в трехвременную таблицу. Ниже приведен список реальных событий, которые произошли между президентскими выборами в США 1964 и 1976 годов :
В этом примере предполагается постоянная 7-дневная задержка между временем принятия решения и временем транзакции, когда данные фиксируются в базе данных. При таких условиях база данных содержала бы следующую информацию после выборов 1976 года:
Учитывая приведенную выше таблицу с задержкой в 7 дней, вопрос «кто был президентом и вице-президентом в допустимое время 1 января 1977 года» (который с учетом задержки в 7 дней мог бы предоставить данные за 25 декабря 1976 года) будет выглядеть следующим образом:
Битемпоральная модель содержит как действительное, так и транзакционное время. Это обеспечивает как историческую, так и откатную информацию. Историческая информация (например, «Где жил Джон в 1992 году?») предоставляется действительным временем. Откат (например, «Где, по мнению базы данных, жил Джон в 1992 году?») предоставляется транзакционным временем. Ответы на эти примеры вопросов могут быть разными — база данных могла быть изменена с 1992 года, в результате чего запросы выдавали разные результаты.
Действительное время и время транзакции не обязательно должны совпадать для одного факта. Например, рассмотрим временную базу данных, хранящую данные о 18 веке. Действительное время этих фактов находится где-то между 1701 и 1800 годами. Время транзакции будет показывать, когда факты были вставлены в базу данных (например, 1998-01-21).
Сложной проблемой является поддержка временных запросов в базе данных транзакционного времени в рамках развивающейся схемы . Для достижения идеального качества архивирования крайне важно хранить данные в той версии схемы, в которой они впервые появились. Однако даже самый простой временной запрос, перезаписывающий историю значения атрибута, потребуется вручную переписать в каждой из версий схемы, потенциально сотен, как в случае MediaWiki . [7] Этот процесс будет особенно обременительным для пользователей. Предлагаемое решение — обеспечить автоматическую перезапись запросов, [8] [9] хотя это не является частью SQL или аналогичных стандартов.
Подходы к минимизации сложностей эволюции схемы заключаются в следующем:
Следующие реализации предоставляют временные функции в системе управления реляционными базами данных (СУРБД).
Нереляционные системы управления базами данных NoSQL, которые предоставляют временные функции, включая следующие:
Временные базы данных были одной из самых ранних форм контроля версий данных и оказали влияние на развитие современных систем управления версиями данных. [19]
Медленно меняющиеся измерения можно использовать для моделирования временных отношений.
