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

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

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

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

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

Содержание

  • 1 Одновременное
  • 2 Би-темпоральное
  • 3 Трехвременное
  • 4 Характеристики
  • 5 История
  • 6 Пример
    • 6.1 Использование невременной базы данных
    • 6.2 Использование одной оси: допустимое время или время транзакции
    • 6.3 Использование двух осей: допустимое время и время транзакции
    • 6.4 Использование трех осей: допустимое время, время принятия решения и время транзакции
  • 7 Битемпоральное моделирование
  • 8 Развитие схемы
  • 9 Реализации в известных продуктах
    • 9.1 Альтернативы
  • 10 Дополнительная литература
  • 11 См. также
  • 12 Ссылки
  • 13 Внешние ссылки

Uni-Temporal

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

Bi-Temporal

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

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

Tri-Temporal

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

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

Этот подход привносит дополнительные сложности.

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

Возможности

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

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

История

С развитием 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, относящиеся к временным базам данных, - это автоматическое разделение периодов времени, временные первичные ключи, временная ссылочная целостность, временные предикаты с алгеброй интервалов Аллена и запросы с квантованием времени и последовательностью.

Пример

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

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

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

Чтобы сохранить жизнь Джона Доу в в текущей (невременной) базе данных мы используем таблицу 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 года:

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

битемпорального моделирования

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

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

Развитие схемы

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

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

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

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

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

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

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

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

Альтернативы

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

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

Дополнительная литература

См. Также

Ссылки

Внешние ссылки

Викискладе есть носители, относящиеся к темпоральным базам данных.
Последняя правка сделана 2021-06-09 13:05:31
Содержание доступно по лицензии CC BY-SA 3.0 (если не указано иное).
Обратная связь: support@alphapedia.ru
Соглашение
О проекте