Временная база данных

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

Более конкретно, временные аспекты обычно включают действительное время , время транзакции или время принятия решения .

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

Uni-Temporal [ править ]

Одновременная база данных имеет одну ось времени: либо диапазон действия, либо диапазон системного времени.

Би-темпоральный [ править ]

Двувременная база данных имеет две оси времени:

• действительное время
• время транзакции или время принятия решения

Tri-Temporal [ править ]

Трехвременная база данных имеет три оси времени:

• действительное время
• время транзакции
• время принятия решения

Такой подход привносит дополнительные сложности.

Темпоральные базы данных отличаются от текущих баз данных (не путать с доступными в настоящее время базами данных), в которых хранятся только факты, которые считаются верными в настоящее время.

Особенности [ править ]

Темпоральные базы данных поддерживают управление и доступ к временным данным, предоставляя одну или несколько из следующих функций: ^{[1] [2]}

• Тип данных периода времени, включая возможность представления периодов времени без конца (бесконечность или вечность).
• Возможность определять действительные атрибуты периода времени и периода транзакции, а также битемпоральные отношения
• Время транзакции, поддерживаемое системой
• Временные первичные ключи , включая ограничения неперекрывающихся периодов
• Временные ограничения, включая неперекрывающуюся уникальность и ссылочную целостность
• Обновление и удаление временных записей с автоматическим разделением и объединением периодов времени
• Временные запросы в текущее время, временные точки в прошлом или будущем, или по длительности
• Предикаты для запроса периодов времени, часто основанные на интервальных отношениях Аллена.

История [ править ]

С развитием SQL и его сопутствующим использованием в реальных приложениях пользователи баз данных осознали, что при добавлении столбцов даты в ключевые поля возникают некоторые проблемы. Например, если таблица имеет первичный ключ и некоторые атрибуты, добавление даты к первичному ключу для отслеживания исторических изменений может привести к созданию большего количества строк, чем предполагалось. Когда строки отслеживаются таким образом, удаления также должны обрабатываться по-другому. В 1992 году эта проблема была признана, но стандартная теория баз данных еще не решила эту проблему, как и новый тогда формализованный стандарт.

Ричард Снодграсс в 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 нет скрытых столбцов и нет нового типа данных для интервалов; вместо этого два столбца даты или времени можно связать вместе с помощью PERIOD FORобъявления. Еще одно отличие заключается в замене спорных (префиксных) модификаторов операторов из TSQL2 на набор временных предикатов.^[1]

Другие особенности стандарта SQL: 2011, связанные с временными базами данных, включают автоматическое разделение периодов времени, временные первичные ключи, временную ссылочную целостность, временные предикаты с алгеброй интервалов Аллена, а также запросы с квантованием времени и последовательность запросов.

Пример [ править ]

В качестве иллюстрации рассмотрим следующую краткую биографию вымышленного человека Джона Доу:

Джон Доу родился 3 апреля 1975 года в Детской больнице Медицинского округа, в семье Джека Доу и Джейн Доу, которые жили в Смоллвилле. Джек Доу с гордостью зарегистрировал рождение своего первенца 4 апреля 1975 года в мэрии Смоллвилля. Джон рос веселым мальчиком, оказался отличным учеником и окончил его с отличием в 1993 году. После окончания уехал жить один в Бигтаун. Хотя он выехал 26 августа 1994 г., он забыл официально зарегистрировать изменение адреса. Только на рубеже сезонов его мать напомнила ему, что он должен зарегистрироваться, что он и сделал несколько дней спустя, 27 декабря 1994 года. Хотя у Джона было многообещающее будущее, его история заканчивается трагически. 1 апреля 2001 года Джон Доу был случайно сбит грузовиком. Коронер сообщил дату своей смерти в тот же день.

Использование вневременной базы данных [ править ]

Чтобы сохранить жизнь Джона Доу в текущей (невременной) базе данных, мы используем таблицу Person (Name, Address) . (Для упрощения Имени определяются как первичный ключ от лица .)

Отец Джона официально сообщили о его рождении 4 апреля 1975 г. В этот день официальный Smallville вставленной следующую запись в базе данных: Person(John Doe, Smallville). Обратите внимание, что сама дата не хранится в базе данных.

После окончания школы Джон уезжает, но забывает зарегистрировать свой новый адрес. Запись Джона в базе данных не менялась до 27 декабря 1994 года, когда он наконец сообщил об этом. Чиновник из Бигтауна обновляет свой адрес в базе данных. Таблица Person теперь содержит Person(John Doe, Bigtown). Обратите внимание, что информация о Джоне, живущем в Смоллвилле, была перезаписана, поэтому получить эту информацию из базы данных больше невозможно. Официальный представитель, обращающийся к базе данных 28 декабря 1994 года, узнает, что Джон живет в Бигтауне. Более технически: если бы администратор базы данных выполнил запрос SELECT ADDRESS FROM PERSON WHERE NAME='John Doe'26 декабря 1994 г., результат был бы Smallville. Выполнение того же запроса через 2 дня приведет к Bigtown.

До его смерти в базе данных говорилось, что он жил в Бигтауне. 1 апреля 2001 г. коронер удаляет запись о Джоне Доу из базы данных. После этого выполнение вышеуказанного запроса вообще не вернет результата.

Использование одной оси: допустимое время или время транзакции [ править ]

Действительное время - это время, в течение которого факт является истинным в реальном мире. Допустимый период времени может быть в прошлом, охватывать текущее время или наступать в будущем.

В приведенном выше примере для записи действительного времени в таблицу Person добавлены два поля: Valid-From и Valid-To . Они определяют период, когда адрес человека действителен в реальном мире. 4 апреля 1975 года отец Джона зарегистрировал рождение сына. Затем чиновник вводит новую запись в базу данных, в которой говорится, что Джон живет в Смоллвилле с 3 апреля. Обратите внимание, что, хотя данные были вставлены 4 апреля, в базе данных указано, что информация действительна с 3 апреля. Официальный представитель пока не знает, переедет ли Джон в другое место и когда, поэтому в поле Valid-To установлено значение бесконечности (∞). Запись в базе данных:

Человек (Джон Доу, Смоллвиль, 3 апреля 1975 г., ∞).

27 декабря 1994 года Джон сообщает свой новый адрес в Бигтауне, где он живет с 26 августа 1994 года. Для записи этого факта сделана новая запись в базе данных:

Человек (Джон Доу, Бигтаун, 26 августа 1994 г., ∞).

Исходная запись Person (John Doe, Smallville, 3-Apr-1975, ∞)не удаляется, но ее атрибут Valid-To обновлен, чтобы отразить, что теперь известно, что Джон перестал жить в Смоллвилле 26 августа 1994 года. База данных теперь содержит две записи для Джона Доу.

Человек (Джон Доу, Смоллвиль, 3 апреля 1975 г., 26 августа 1994 г.).Человек (Джон Доу, Бигтаун, 26 августа 1994 г., ∞).

Когда Джон умирает, его текущая запись в базе данных обновляется о том, что Джон больше не живет в Бигтауне. База данных теперь выглядит так

Человек (Джон Доу, Смоллвиль, 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 г., ∞).

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

Использование трех осей: допустимое время, время принятия решения и время транзакции [ править ]

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

Периоды времени принятия решения могут иметь место только в прошлом или до времени транзакции. Как и в таблице времени транзакции, записи никогда не удаляются. Можно вставлять только новые записи, а существующие обновлять, задав для них время окончания принятия решения, чтобы показать, что они больше не актуальны.

Чтобы включить время принятия решения, в таблицу базы данных добавляются еще два поля: Decision From и Decision To . Decision From - это время, когда было принято решение, а Decision-To - время, когда решение было отменено (которое может быть бесконечным, если оно еще не было отменено). В сочетании со временем транзакции это превращает таблицу в банальную .

Ниже приводится список реальных событий, произошедших между президентскими выборами в США 1964 и 1976 годов:

Предположим, существует постоянная 7-дневная задержка между временем принятия решения и временем транзакции, зафиксированной в базе данных. Тогда, после выборов 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 г.)Администрация (Ричард Никсон, Джеральд Форд, ∞, 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 г., ∞)Администрация (Ричард Никсон, Джеральд Форд, 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 г., 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 года:

• Никсон / Агнью при использовании времени принятия решения и времени транзакции от 14 ноября 1972 г.
• Nixon / (Vacant) при использовании времени принятия решения и времени транзакции 17 октября 1973 г.
• Никсон / Форд при использовании времени принятия решения и времени транзакции от 8 августа 1974 г.
• Ford / (Vacant) при использовании времени принятия решения 8 августа 1974 г. и текущего времени транзакции
• Форда / Рокфеллера при использовании времени принятия решения и времени транзакции текущего

Битемпоральное моделирование [ править ]

Битемпоральная модель содержит как действительное и транзакции времени. Это предоставляет как историческую информацию, так и информацию об откате . Историческая информация (например: «Где жил Джон в 1992 году?») Предоставляется по действительному времени. Откат (например: «Где, по мнению базы данных, жил Джон в 1992 году?») Обеспечивается временем транзакции. Ответы на эти примерные вопросы могут быть разными - база данных могла быть изменена с 1992 года, в результате чего запросы давали разные результаты.

Действительное время и время транзакции не обязательно должны совпадать для одного факта. Например, рассмотрим временную базу данных, в которой хранятся данные о 18 веке. Действительное время этих фактов находится где-то между 1701 и 1800. Время транзакции покажет, когда факты были вставлены в базу данных (например, 21 января 1998 г.).

Эволюция схемы [ править ]

Сложной проблемой является поддержка временных запросов в базе данных времени транзакции при развивающейся схеме . Для достижения идеального качества архивирования крайне важно хранить данные в той версии схемы, в которой они впервые появились. Однако даже самый простой темпоральный запрос, перезаписывающий историю значения атрибута, потребовался бы переписывать вручную под каждой из версий схемы, потенциально сотни, как в случае MediaWiki [1] . Этот процесс будет особенно обременительным для пользователей. Предлагаемое решение - обеспечить автоматическую перезапись запросов ^{[7] [8],} хотя это не является частью SQL или аналогичных стандартов.

Подходы к минимизации сложности эволюции схемы :

• использовать полуструктурированную базу данных / базу данных NoSQL, которая упрощает моделирование данных атрибутов, но не предоставляет функций для обработки нескольких осей времени. ^[9]
• использовать базу данных, способную хранить как полуструктурированные данные для атрибутов, так и структурированные данные для осей времени (например, SnowflakeDB , PostgreSQL)

Реализации в известных продуктах [ править ]

Следующие реализации предоставляют временные функции в системе управления реляционными базами данных (RDBMS).

• В MariaDB версии 10.3.4 добавлена ​​поддержка стандарта SQL: 2011 как «Таблицы с системной версией». ^[10]
• Oracle Database  - Oracle Workspace Manager - это функция Oracle Database, которая позволяет разработчикам приложений и администраторам баз данных управлять текущими, предлагаемыми и историческими версиями данных в одной базе данных.
• PostgreSQL версии 9.2 добавил собственные ранжированные типы данных, которые способны реализовать все функции временного расширения pgFoundry. ^{[11] [12]} Типы диапазонов PostgreSQL поддерживаются множеством собственных операторов и функций.
• Teradata предлагает два продукта. Teradata версии 13.10 и Teradata версии 14 имеют временные функции, основанные на TSQL2 ^[13], встроенном в базу данных.
• В IBM DB2 версии 10 добавлена ​​функция, называемая «запрос путешествия во времени» ^[2], которая основана на временных возможностях стандарта SQL: 2011 . ^[1]
• Microsoft SQL Server представил временные таблицы как функцию для SQL Server 2016. Эта функция описана в видео на веб-сайте Microsoft Channel 9. ^[14]

Нереляционные системы управления базами данных NoSQL, которые предоставляют временные функции, включая следующие:

• TerminusDB - это полнофункциональная графическая база данных с открытым исходным кодом, которая изначально поддерживает управление версиями, запросы перемещения во времени и функции сравнения. Он имеет неизменяемую архитектуру слоев, основанную на дельта-кодировании и сжатых структурах данных . ^[15]
• MarkLogic представил поддержку битемпоральных данных в версии 8.0. Отметки времени для действительного и системного времени хранятся в документах JSON или XML. ^[16]
• SirixDB очень эффективно хранит моментальные снимки (в настоящее время) XML- и JSON-документов в двоичном формате благодаря новому алгоритму управления версиями, называемому скользящим моментальным снимком, который уравновешивает производительность чтения / записи и никогда не создает пиков записи. Запросы о путешествиях во времени поддерживаются изначально, а также функции сравнения.
• Crux обеспечивает одновременные битемпоральные запросы к журналу данных по транзакциям и документам, полученным из полу неизменяемых журналов Kafka. Документы автоматически индексируются для создания индексов модели «сущность – атрибут – значение» без необходимости определять схему. Операции транзакции указывают действующее время действия. Время транзакции назначается Kafka и обеспечивает горизонтальную масштабируемость за счет согласованного чтения.
• RecallGraph - это единая (время транзакции) графовая база данных на определенный момент времени, построенная на основе ArangoDB . Он работает на подсистеме микросервисов Foxx от ArangoDB . Он имеет семантику, подобную VCS, во многих частях своего интерфейса и поддерживается трекером транзакционных событий. Битемпоральность указана как один из пунктов в ее дорожной карте развития .

Альтернативы [ править ]

Медленно изменяющиеся размеры можно использовать для моделирования временных отношений.

Дальнейшее чтение [ править ]

См. Также [ править ]

• Якорное моделирование
• Теория баз данных
• Магазин событий
• Пространственно-временная база данных
• База данных временных рядов

Ссылки [ править ]

Внешние ссылки [ править ]

Викискладе есть медиафайлы, связанные с временными базами данных .

• TimeCenter
• Временные отношения в RDF
• Временной объем для RDF троек
• IBM DB2 10 для z / OS
• Снова и снова цикл статей Рэнди Вайса и Тома Джонстона
• Темпоральные паттерны Мартина Фаулера