A Временная база данных хранит данные, относящиеся к временным моментам. Он предлагает временные типы данных и хранит информацию, относящуюся к прошлому, настоящему и будущему времени. Темпоральные базы данных могут быть одновременными, двухвременными или трехвременными.
Более конкретно, временные аспекты обычно включают в себя действительное время, время транзакции или.
Одновременная база данных имеет одну ось времени, либо диапазон действия, либо диапазон системного времени.
Двувременная база данных имеет две оси времени:
Трехвременная база данных имеет три оси времени:
Этот подход привносит дополнительные сложности.
Темпоральные базы данных отличаются от текущих баз данных (не путать с доступными в настоящее время базами данных), в которых хранятся только факты, которые считаются верными в настоящее время.
Временные базы данных поддерживают управление и доступ к временным данным, предоставляя одну или несколько из следующих функций:
С развитием SQL и его сопутствующее использование в реальных приложениях, пользователи баз данных поняли, что когда t При добавлении столбцов даты в ключевые поля возникли некоторые проблемы. Например, если таблица имеет первичный ключ и некоторые атрибуты, добавление даты к первичному ключу для отслеживания исторических изменений может привести к созданию большего количества строк, чем предполагалось. Если строки отслеживаются таким образом, удаления также должны обрабатываться иначе. В 1992 году эта проблема была признана, но стандартная теория баз данных еще не решила эту проблему, как и недавно формализованный стандарт.
Ричард Снодграсс в 1992 году предложил, чтобы временные расширения SQL были разработаны сообществом временных баз данных. В ответ на это предложение был сформирован комитет для разработки расширений к версии стандарта SQL 1992 г. (ANSI X3.135.-1992 и ISO / IEC 9075: 1992); эти расширения, известные как TSQL2, были разработаны этим комитетом в 1993 году. В конце 1993 года Снодграсс представил эту работу группе, ответственной за Американский национальный стандарт языка баз данных SQL, Техническому комитету ANSI X3H2 (теперь известному как NCITS H2). Предварительная спецификация языка появилась в записи ACM SIGMOD за март 1994 года. На основе ответов на эту спецификацию в язык были внесены изменения, и окончательная версия спецификации языка TSQL2 была опубликована в сентябре 1994 г.
Была предпринята попытка включить части TSQL2 в новый стандарт SQL SQL: 1999, называется SQL3. Части TSQL2 были включены в новый нестандартный стандарт SQL3, ISO / IEC 9075-7, который называется SQL / Temporal. Подход TSQL2 подвергся резкой критике со стороны Криса Дейта и Хью Дарвена. Проект ISO, отвечающий за временную поддержку, был отменен ближе к концу 2001 года.
По состоянию на декабрь 2011 года, ISO / IEC 9075, Язык баз данных SQL: 2011 Часть 2: SQL / Foundation включены пункты в определениях таблиц для определения «таблиц периодов времени приложения» (допустимое время таблиц), «таблиц с системным управлением версиями» (таблицы времени транзакции ) и «периода времени приложения с системным управлением версиями. таблицы "(битемпоральные таблицы). Существенное различие между предложением TSQL2 и тем, что было принято в SQL: 2011, заключается в том, что в обработке SQL: 2011 нет скрытых столбцов и нет нового типа данных для интервалов; вместо этого два столбца даты или времени можно связать вместе с помощью объявления PERIOD FOR
. Другое отличие заключается в замене спорных (префиксных) модификаторов операторов из TSQL2 набором временных предикатов.
Другие особенности стандарта SQL: 2011, относящиеся к временным базам данных, - это автоматическое разделение периодов времени, временные первичные ключи, временная ссылочная целостность, временные предикаты с алгеброй интервалов Аллена и запросы с квантованием времени и последовательностью.
Для иллюстрации рассмотрим следующую краткую биографию вымышленного человека, Джона Доу:
Чтобы сохранить жизнь Джона Доу в в текущей (невременной) базе данных мы используем таблицу Person (Name, Address). (Для упрощения Имя определяется как первичный ключ Личности.)
Отец Джона официально сообщил о своем рождении 4 апреля 1975 года. В этот день чиновник Смоллвилля вставил следующую запись в базе данных: Человек (Джон Доу, Смоллвиль)
. Обратите внимание, что сама дата не хранится в базе данных.
После окончания школы Джон уезжает, но забывает зарегистрировать свой новый адрес. Запись Джона в базе данных не менялась до 27 декабря 1994 года, когда он наконец сообщил об этом. Официальный представитель Bigtown обновляет свой адрес в базе данных. Таблица Person теперь содержит Person (John Doe, Bigtown)
. Обратите внимание, что информация о Джоне, живущем в Смоллвилле, была перезаписана, поэтому получить эту информацию из базы данных больше невозможно. Официальный представитель, обращающийся к базе данных 28 декабря 1994 года, узнает, что Джон живет в Бигтауне. Более технически: если 26 декабря 1994 г. администратор базы данных выполнил запрос ВЫБРАТЬ АДРЕС ОТ ПЕРСОНА, ГДЕ ИМЯ = 'Джон Доу'
, результатом будет Смоллвиль
. Выполнение того же запроса через 2 дня приведет к Бигтаун
.
. До его смерти в базе данных будет указано, что он жил в Бигтауне. 1 апреля 2001 г. коронер удаляет запись о Джоне Доу из базы данных. После этого выполнение вышеуказанного запроса вообще не вернет результата.
Дата | Событие реального мира | Действие базы данных | Что показывает база данных |
---|---|---|---|
3 апреля 1975 г. | Родился Джон | Ничего | Нет человека по имени Джон Доу |
4 апреля 1975 г. | Отец Джона официально сообщает о рождении Джона | Вставлено: Человек (Джон Доу, Смоллвиль) | Джон Доу живет в Смоллвилле |
26 августа 1994 г. | После окончания школы Джон переезжает в Бигтаун, но забывает зарегистрировать свой новый адрес | Ничего | Джон Доу живет в Смоллвилле |
26 декабря 1994 г. | Ничего | Ничего | Джон Доу живет в Смоллвилле |
27 декабря 1994 г. | Джон регистрирует свой новый адрес | Обновлено: Человек (Джон Доу, Бигтаун) | Джон Доу живет в Бигтауне |
1 апреля 2001 г. | Джон умирает | Удалено: Человек (Джон Доу) | Нет человека по имени Джон Доу |
Допустимое время - время для что факт истинен в реальном мире. Действительный период времени может быть в прошлом, охватывать текущее время или наступать в будущем.
В приведенном выше примере для записи действительного времени в таблицу Person добавлены два поля: Valid-From и Valid-To. Они определяют период, когда адрес человека действителен в реальном мире. 4 апреля 1975 года отец Джона зарегистрировал рождение сына. Затем чиновник вводит новую запись в базу данных, в которой говорится, что Джон живет в Смоллвилле с 3 апреля. Обратите внимание, что, хотя данные были вставлены 4 апреля, в базе данных указано, что информация действительна с 3 апреля. Официальный представитель пока не знает, переедет ли Джон в другое место и когда, поэтому в поле Valid-To установлено значение infinity (∞). Запись в базе данных:
Человек (Джон Доу, Смоллвиль, 3 апреля 1975 г., ∞).
27 декабря 1994 г. Джон сообщает свой новый адрес в Бигтауне, где он проживает с 26 августа 1994 г. Для записи этого факта сделана новая запись в базе данных:
Человек (Джон Доу, Бигтаун, 26 августа 1994 г., ∞).
Исходная запись Person (John Doe, Smallville, 3 апреля 1975 г., ∞)
не удаляется, но для нее обновлен атрибут Valid-To, чтобы отразить, что теперь известно, что Джон перестал жить в Смоллвилле 26 августа 1994 года. База данных теперь содержит две записи для Джон Доу
Человек (Джон Доу, Смоллвиль, 3 апреля 1975 г., 26 августа 1994 г.). Человек (Джон Доу, Бигтаун, 26 августа 1994 г., ∞).
Когда Джон умирает, его текущая запись в базе данных обновляется о том, что Джон больше не живет в Бигтауне. База данных теперь выглядит так:
Человек (John Doe, Smallville, 3 апреля 1975 г., 26 августа 1994 г.). Человек (Джон Доу, Бигтаун, 26 августа 1994 г., 1 апреля 2001 г.).
Время транзакции регистрирует период времени, в течение которого запись в базе данных принимается как правильная. Это позволяет выполнять запросы, которые показывают состояние базы данных в данный момент времени. Периоды времени транзакции могут иметь место только в прошлом или до текущего времени. В таблице времени транзакции записи никогда не удаляются. Можно вставлять только новые записи, а существующие обновлять, задав время окончания транзакции, чтобы показать, что они больше не актуальны.
Чтобы включить время транзакции в приведенном выше примере, в таблицу Person добавлены еще два поля: Transaction-From и Transaction-To. Transaction-From - это время выполнения транзакции, а Transaction-To - время, когда транзакция была заменена (которая может быть бесконечной, если она еще не была заменена). Это превращает таблицу в битемпоральную таблицу.
Что произойдет, если адрес человека, хранящийся в базе данных, неверен? Предположим, чиновник случайно ввел неправильный адрес или дату? Или предположим, что человек по какой-то причине солгал о своем адресе. При обнаружении ошибки официальные лица обновляют базу данных, чтобы исправить записанную информацию.
Например, с 1 июня 1995 г. по 3 сентября 2000 г. Джон Доу переехал в Бичи. Но, чтобы избежать уплаты непомерного налога на проживание Бичи, он никогда не сообщал об этом властям. Позже, в ходе налогового расследования, 2 февраля 2001 года выяснилось, что он действительно находился в Бичи в те дни. Чтобы зафиксировать этот факт, существующая запись о Джоне, живущем в Бигтауне, должна быть разделена на две отдельные записи, а новая запись должна быть добавлена с записью его проживания в Бичи. В этом случае база данных будет выглядеть следующим образом:
Человек (Джон Доу, Смоллвиль, 3 апреля 1975 г., 26 августа 1994 г.). Человек (Джон Доу, Бигтаун, 26 августа 1994 г., 1 июня 1995 г.). Человек (Джон Доу, Бичи, 1 июня 1995 г., 3 сентября 2000 г.). Человек (Джон Доу, Бигтаун, 3 сентября 2000 г., 1 апреля 2001 г.).
Однако это не оставляет никаких записей о том, что в базе данных когда-либо утверждалось, что он жил в Бигтауне с 1 июня 1995 г. по 3 сентября 2000 г. Это может быть важно знать для целей аудита или использовать в качестве доказательства в налоговом расследовании должностного лица. Время транзакции позволяет фиксировать эти изменяющиеся знания в базе данных, поскольку записи никогда не изменяются или не удаляются напрямую. Вместо этого каждая запись записывает, когда она была введена и когда она была заменена (или логически удалена). Тогда содержимое базы данных будет выглядеть следующим образом:
Имя, Город, Действителен с, Действителен до, Введен, Заменен
Человек (Джон Доу, Смоллвиль, 3 апреля 1975 г., ∞, 4- Апр 1975 г., 27 декабря 1994 г.). Человек (Джон Доу, Смоллвиль, 3 апреля 1975 г., 26 августа 1994 г., 27 декабря 1994 г., ∞). Человек (Джон Доу, Бигтаун, 26 августа 1994 г., ∞, 27 декабря 1994 г., 2 февраля 2001 г.). Человек (Джон Доу, Бигтаун, 26 августа 1994 г., 1 июня 1995 г., 2 февраля 2001 г., ∞). Человек (Джон Доу, Бичи, 1 июня 1995 г., 3 сентября 2000 г., 2 февраля 2001 г., ∞). Человек (Джон Доу, Бигтаун, 3 сентября 2000 г., ∞, 2 февраля 2001 г., 1 апреля 2001 г.). Человек (Джон Доу, Бигтаун, 3 сентября 2000 г., 1 апреля 2001 г., 1 апреля 2001 г., ∞).
В базе данных записано не только то, что происходило в реальном мире, но и то, что было официально зарегистрировано в разное время.
является альтернативой периоду времени транзакции для записи времени, в которое запись в базе данных может быть принята как правильная. Это позволяет выполнять запросы, которые показывают официально признанные факты в определенный момент времени, даже если произошла задержка в передаче этих фактов в базу данных. Поддержка времени принятия решения сохраняет всю историю и предотвращает потерю информации во время обновлений.
Периоды времени принятия решения могут иметь место только в прошлом или до времени транзакции. Как и в таблице времени транзакции, записи никогда не удаляются. Можно вставлять только новые записи, а существующие обновлять, задав для них время окончания принятия решения, чтобы показать, что они больше не актуальны.
Чтобы включить время принятия решения, в таблицу базы данных добавляются еще два поля: Decision From и Decision To. Decision From - это время, когда было принято решение, а Decision-To - это время, когда решение было отменено (которое может быть бесконечным, если оно еще не было отменено). В сочетании с временем транзакции это превращает таблицу в шаблонную таблицу.
. Ниже приводится список реальных событий, которые произошли между президентскими выборами в США 1964 и 1976 годов:
Дата | Лицо, принимающее решения | Событие в реальном мире |
---|---|---|
3 ноября 1964 г. | Коллегия выборщиков | Выборы 1964 г. |
5 ноября 1968 г. | Коллегия выборщиков | Выборы 1968 года |
7 ноября 1972 года | Коллегия выборщиков | Выборы 1972 года |
10 октября 1973 года | Спиро Агнью | Агнью уходит в отставку |
12 октября 1973 г. | Ричард Никсон | Никсон номинирует Форда |
6 декабря 1973 г. | Конгресс | Конгресс подтверждает Форда |
9 августа 1974 г. | Ричард Никсон | Никсон уходит в отставку |
20 августа 1974 г. | Джеральд Форд | Форд выдвигает кандидатуру Рокфеллера |
19 декабря 1974 г. | Конгресс | Конгресс подтверждает Рокфеллера |
2 ноября 1976 г. | Коллегия выборщиков | Выборы 1976 года |
Предположим, что существует постоянная 7-дневная задержка между n время принятия решения и время транзакции, зафиксированные в базе данных. Затем, после выборов 1976 года, содержимое базы данных будет следующим:
Президент, Вице-президент, Действителен с, Действителен до, Решение от, Решение К, Транзакция от, Транзакция до ---------- -------------------------------------------------- -------------------------------------------------- -------------------- Администрация (Линдон Джонсон, Хьюберт Хамфри, 20 января 1965 г., 20 января 1969 г., 3 ноября 1964 г., ∞, 10- Ноябрь 1964, ∞) Администрация (Ричард Никсон, Спиро Агнью, 20 января 1969, 20 января 1973, 5 ноября 1968, ∞, 12 ноября 1968, ∞) Администрация (Ричард Никсон, Спиро Агнью, 20 января 1973 г., 20 января 1977 г., 7 ноября 1972 г., ∞, 14 ноября 1972 г., 17 октября 1973 г.) Администрация (Ричард Никсон, Спиро Агнью, 20 января 1973 г., 20 января- 1977, 7 ноября 1972, 10 октября 1973, 17 октября 1973, ∞) Администрация (Ричард Никсон, Спиро Агнью, 20 января 1973, 10 октября 1973, 10 октября 1973, ∞, 17 октября 1973 г., ∞) Администрация (Ричард Никсон, (Вакант), 10 октября 1973 г., 20 января 1977 г., 10 октября 1973 г., ∞, 17 октября 1973 г., 13 декабря 1973 г.) (Ричард Никсон, Джеральд Фо rd, ∞, 20 января 1977 г., 12 октября 1973 г., ∞, 19 октября 1973 г., 13 декабря 1973 г.) Администрация (Ричард Никсон, (вакантно), 10 октября 1973 г., 20 января 1977 г., 10 октября 1973 г., 6 декабря 1973 г., 13 декабря 1973 г., ∞) Администрация (Ричард Никсон, (Вакант), 10 октября 1973 г., 6 декабря 1973 г., 6 декабря 1973 г., ∞, 13 декабря 1973 г., ∞) Администрация (Ричард Никсон, Джеральд Форд, ∞, 20 января 1977 г., 12 октября 1973 г., 6 декабря 1973 г., 13 декабря 1973 г., ∞) Администрация (Ричард Никсон, Джеральд Ford, 6 декабря 1973 г., 20 января 1977 г., 6 декабря 1973 г., ∞, 13 декабря 1973 г., 15 августа 1974 г.) Администрация (Ричард Никсон, Джеральд Форд, 6 декабря 1973 г., 20- Январь 1977 г., 6 декабря 1973 г., 8 августа 1974 г., 15 августа 1974 г., ∞) Администрация (Ричард Никсон, Джеральд Форд, 6 декабря 1973 г., 9 августа 1974 г., 8 августа 1974 г., ∞, 15 августа 1974 г., ∞) Администрация (Джеральд Форд, (вакантно), 9 августа 1974 г., 20 января 1977 г., 8 августа 1974 г., ∞, 15 августа 1974 г., 26 декабря 1974 г.) Администрация (Джеральд Форд, Нельсон Рокфеллер, ∞, 20 января 1977 г., 20 августа 1974 г., ∞, 27 августа 1974 г., 26 декабря 1974 г.) Администрация (Джеральд Форд, (свободно), 9 августа 1974 г.) 1974, 20 января 1977, 8 августа 1974, 19 декабря 1974, 26 декабря 1974, ∞) Администрация (Джеральд Форд, (вакантно), 9 августа 1974 г., 19 декабря 1974 г., 19 декабря 1974 г., ∞, 26 декабря 1974 г., ∞) Администрация (Джеральд Форд, Нельсон Рокфеллер, ∞, 20 -Янв 1977, 20 августа 1974, 19 декабря 1974, 26 декабря 1974, ∞) Администрация (Джеральд Форд, Нельсон Рокфеллер, 19 декабря 1974, 20 января 1977, 19 декабря 1974, ∞, 26 декабря 1974 г., ∞) Администрация (Джимми Картер, Уолтер Мондейл, 20 января 1977 г., 20 января 1981 г., 2 ноября 1976 г., ∞, 9 ноября 1976 г., ∞)
Рассмотрим вопрос о том, кто будет президентом и вице-президентом в течение действительного времени 1 января 1977 года:
A битемпоральной модели содержит как действительное время, так и время транзакции. Это обеспечивает информацию как журнала, так и отката . Историческая информация (например: «Где жил Джон в 1992 году?») Предоставляется по действительному времени. Откат (например: «Где, по мнению базы данных, жил Джон в 1992 году?») Обеспечивается временем транзакции. Ответы на эти примеры вопросов могут быть разными - база данных могла быть изменена с 1992 года, в результате чего запросы давали разные результаты.
Действительное время и время транзакции не обязательно должны совпадать для одного факта. Например, рассмотрим временную базу данных, в которой хранятся данные о 18 веке. Действительное время этих фактов находится где-то между 1701 и 1800. Время транзакции покажет, когда факты были вставлены в базу данных (например, 21 января 1998 г.).
Сложной проблемой является поддержка временных запросов в базе данных времени транзакции в рамках развивающейся схемы. Для достижения идеального качества архивирования очень важно хранить данные в той версии схемы, в которой они впервые появились. Однако даже самый простой темпоральный запрос, перезаписывающий историю значения атрибута, потребовал бы перезаписи вручную под каждой из версий схемы, потенциально сотни, как в случае MediaWiki [1]. Этот процесс будет особенно обременительным для пользователей. Предлагаемое решение - обеспечить автоматическую перезапись запросов, хотя это не является частью SQL или аналогичных стандартов.
Подходы к минимизации сложностей эволюции схемы :
Следующие реализации предоставляют временные функции в системе управления реляционными базами данных (RDBMS).
Нереляционные системы управления базами данных NoSQL, которые обеспечивают временные функции, включая следующие:
Медленно меняющиеся размеры может использоваться для моделирования временных отношений.
Викискладе есть носители, относящиеся к темпоральным базам данных. |