stringtranslate.com

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

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

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

Типы

Одновременный

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

Битемпоральный

Битемпоральная база данных имеет две оси времени:

Трёхвисочный

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

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

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

Функции

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

Пример

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

Джон Доу родился 03.04.1975 в Детской больнице округа Медисин, сын Джека Доу и Джейн Доу, которые жили в Смолвилле. Джек Доу с гордостью зарегистрировал рождение своего первенца 4 апреля 1975 года в здании мэрии Смолвилля. Джон рос жизнерадостным мальчиком, оказался блестящим студентом и окончил школу с отличием в 1993 году. После окончания школы он отправился жить самостоятельно в Бигтаун. Хотя он переехал 26.08.1994, он забыл официально зарегистрировать смену адреса. Только на стыке сезонов мать напомнила ему, что он должен зарегистрироваться, что он и сделал несколько дней спустя, 27.12.1994. Хотя у Джона было многообещающее будущее, его история заканчивается трагически. Джона Доу случайно сбил грузовик 01.04.2001. Коронер сообщил дату его смерти в тот же день.

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

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

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

Пример модели медленно меняющегося измерения (SCD)

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

Дальнейшее чтение

Смотрите также

Ссылки

  1. ^ abc Кулкарни, Кришна и Ян-Эйке Михелс. «Временные признаки в SQL: 2011». ACM SIGMOD Record 41.3 (2012): 34-43.
  2. ^ ab Saracco, Cynthia M.; Nicola, Matthias; Gandhi, Lenisha (3 апреля 2012 г.). "Вопрос времени: управление временными данными в DB2 10". IBM . Архивировано из оригинала 2012-10-25 . Получено 2020-10-27 .
  3. ^ ab Snodgrass, 1999, стр. 9
  4. ^ Ричард Т. Снодграсс . "TSQL2 Temporal Query Language". www.cs.arizona.edu . Computer Science Department of the University of Arizona . Получено 14 июля 2009 г.
  5. ^ Хью Дарвен, CJ Date, «Обзор и анализ предложений, основанных на подходе TSQL2», в книге «Date on Database: Writings 2000-2006» , CJ Date, Apress, 2006, стр. 481-514
  6. ^ Марио А. Насименто, Маргарет Х. Эйх, «Время принятия решений во временных базах данных», в трудах Второго международного семинара по временному представлению и рассуждениям , 1995, стр. 157-162
  7. ^ Тест эволюции схемы - Эволюция схемы
  8. ^ Хён Дж. Мун; Карло А. Курино; Алин Дойч; К.-Й. Хоу и Карло Заниоло (2008). Управление и запросы к базам данных транзакционного времени в рамках эволюции схемы. Очень большая база данных VLDB.
  9. ^ Хён Дж. Мун; Карло А. Курино и Карло Заниоло (2010). Масштабируемая архитектура и оптимизация запросов для транзакционных БД с развивающимися схемами. SIGMOD.
  10. ^ Энтони Б. Коутс (2015). Почему банки заботятся о битемпоральности. MarkLogic World 2015.
  11. ^ «Системно-версионные таблицы».
  12. ^ Пакье, Майкл (1 ноября 2012 г.). "Postgres 9.2 highlight: range types". Майкл Пакье - разработчик открытого исходного кода из Японии . Архивировано из оригинала 2016-04-23.
  13. ^ Кац, Джонатан С. «Типы диапазонов: ваша жизнь никогда не будет прежней» (PDF) . Получено 14 июля 2014 г.
  14. ^ Аль-Катеб, Мохаммед и др. «Временная обработка запросов в Teradata». EDBT/ICDT '13 18–22 марта 2013 г., Генуя, Италия
  15. ^ Временной в SQL Server 2016 , получено 2019-07-19
  16. ^ "terminusdb/terminusdb-server". GitHub . Получено 2020-09-04 .
  17. ^ Бриджуотер, Адриан (24 ноября 2014 г.). «Данные — это хорошо, а «двунаправленные битемпоральные» данные — лучше». Forbes .
  18. ^ «Модель атомарных данных: модель времени». 29 апреля 2024 г.
  19. ^ Бхардвадж, Анант; Бхаттачерджи, Сувик; Чаван, Амит; Дешпанде, Амол; Элмор, Аарон Дж.; Мэдден, Сэмюэл; Парамешваран, Адитья Г. (2 сентября 2014 г.). «DataHub: совместная обработка данных и управление версиями наборов данных в масштабе». arXiv : 1409.0798 [cs.DB].

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