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

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

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

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

Типы

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

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

Двувременный

Основная статья: Битемпоральное моделирование

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

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

трехвременный

Дополнительная информация: Время принятия решения.

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

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

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

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

Функции

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

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

История

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

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

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

Пример

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

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

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

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

Отец Джона официально сообщил о его рождении 4 апреля 1975 года. В этот день чиновник Смоллвилля внес в базу данных следующую запись: 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 г. коронер удаляет запись о Джоне Доу из базы данных. После этого выполнение вышеуказанного запроса вообще не вернет никакого результата.

Дата	Реальное событие в мире	Действие базы данных	Что показывает база данных
1975-04-03	Джон родился	Ничего	Нет человека по имени Джон Доу
1975-04-04	Отец Джона официально сообщает о рождении Джона	Вставлено:Человек (Джон Доу, Смоллвиль)	Джон Доу живет в Смоллвилле.
1994-08-26	После окончания школы Джон переезжает в Бигтаун, но забывает зарегистрировать свой новый адрес.	Ничего	Джон Доу живет в Смоллвилле.
1994-12-26	Ничего	Ничего	Джон Доу живет в Смоллвилле.
1994-12-27	Джон регистрирует свой новый адрес	Обновлено: Человек (Джон Доу, Бигтаун)	Джон Доу живет в Бигтауне.
2001-04-01	Джон умирает	Удален:Человек (Джон Доу)	Нет человека по имени Джон Доу

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

Основная статья: Время действия

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

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

Имя	Город	Действительно с	Действительно до
Джон Доу	Смоллвиль	1975-04-03	∞

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

Имя	Город	Действительно с	Действительно до
Джон Доу	Бигтаун	1994-08-26	∞

Оригинальная запись Person (John Doe, Smallville, 1975-04-03, ∞) не удаляется, но имеет valid_to атрибут обновлен, чтобы отразить, что теперь известно, что Джон перестал жить в Смоллвилле 26 августа 1994 г. База данных теперь содержит две записи для Джона Доу:

Имя	Город	Действительно с	Действительно до
Джон Доу	Смоллвиль	1975-04-03	1994-08-26
Джон Доу	Бигтаун	1994-08-26	∞

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

Имя	Город	Действительно с	Действительно до
Джон Доу	Смоллвиль	1975-04-03	1994-08-26
Джон Доу	Бигтаун	1994-08-26	2001-04-01

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

Основная статья: Время транзакции

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

Чтобы включить время транзакции в приведенном выше примере, в таблицу Person добавляются еще два поля: transaction_from и transaction_to. Здесь, transaction_from время совершения транзакции, и transaction_to — это время замены транзакции (которое может быть бесконечным, если она еще не была заменена). Это превращает таблицу в битемпоральную таблицу .

Что произойдет, если адрес человека, хранящийся в базе данных, неверен? Предположим, чиновник случайно ввел неправильный адрес или дату? Или предположим, что человек по какой-то причине солгал о своем адресе. При обнаружении ошибки должностные лица обновляют базу данных, чтобы исправить записанную информацию.

Например, с 1 июня 1995 г. по 3 сентября 2000 г. Джон Доу переехал в Бичи. Но чтобы избежать уплаты непомерного налога на проживание Бичи, он никогда не сообщал об этом властям. Позже, 2 февраля 2001 года, в ходе налогового расследования выяснилось, что в те дни он действительно находился в Бичи. Чтобы зафиксировать этот факт, существующую запись о Джоне, живущем в Бигтауне, необходимо разделить на две отдельные записи и добавить новую запись, в которой записано его место жительства в Бичи. Тогда база данных будет выглядеть следующим образом:

Имя	Город	Действительно с	Действительно до
Джон Доу	Смоллвиль	1975-04-03	1994-08-26
Джон Доу	Бигтаун	1994-08-26	1995-06-01
Джон Доу	Бичи	1995-06-01	2000-09-03
Джон Доу	Бигтаун	2000-09-03	2001-04-01

Однако это не оставляет никаких записей о том, что в базе данных когда-либо утверждалось, что он жил в Бигтауне с 1 июня 1995 г. по 3 сентября 2000 г. Это может быть важно знать для целей аудита или использовать в качестве доказательства в налоговом расследовании чиновника. Время транзакции позволяет фиксировать эти изменяющиеся знания в базе данных, поскольку записи никогда не изменяются и не удаляются напрямую. Вместо этого каждая запись записывает, когда она была введена и когда она была заменена (или логически удалена). Содержимое базы данных будет выглядеть следующим образом:

Имя	Город	Действительно с	Действительно до	Вошел	Заменено
Джон Доу	Смоллвиль	1975-04-03	∞	1975-04-04	1994-12-27
Джон Доу	Смоллвиль	1975-04-03	1994-08-26	1994-12-27	∞
Джон Доу	Бигтаун	1994-08-26	∞	1994-12-27	2001-02-02
Джон Доу	Бигтаун	1994-08-26	1995-06-01	2001-02-02	∞
Джон Доу	Бичи	1995-06-01	2000-09-03	2001-02-02	∞
Джон Доу	Бигтаун	2000-09-03	∞	2001-02-02	2001-04-01
Джон Доу	Бигтаун	2000-09-03	2001-04-01	2001-04-01	∞

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

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

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

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

Чтобы включить время принятия решения, в таблицу базы данных добавляются еще два поля: decision_from и decision_to. Здесь, decision_from время принятия решения и decision_to время, когда решение было отменено (которое может быть бесконечным, если оно еще не было отменено). В сочетании со временем транзакции это превращает таблицу в трехвременную таблицу . Ниже приводится список реальных событий, произошедших между президентскими выборами в США 1964 и 1976 годов :

Дата	Лицо, принимающее решения	Реальное событие в мире
1964-11-03	Коллегия выборщиков	Выборы 1964 г.
1968-11-05	Коллегия выборщиков	Выборы 1968 г.
1972-11-07	Коллегия выборщиков	Выборы 1972 г.
1973-10-10	Спиро Агнью	Агнью уходит в отставку
1973-10-12	Ричард Никсон	Никсон выдвигает кандидатуру Форда
1973-12-06	Конгресс	Конгресс утверждает Форда
1974-08-09	Ричард Никсон	Никсон уходит в отставку
1974-08-20	Джеральд Форд	Форд выдвигает кандидатуру Рокфеллера
1974-12-19	Конгресс	Конгресс подтверждает Рокфеллера
1976-11-02	Коллегия выборщиков	Выборы 1976 г.

В этом примере предполагается постоянная 7-дневная задержка между временем принятия решения и временем транзакции, когда данные фиксируются в базе данных. Учитывая эти условия, после выборов 1976 года база данных содержала бы следующую информацию:

		Действительный		Решение		Сделка
Президент	Порок	От	К	От	К	От	К
Джонсон	Хамфри	1965-01-20	1969-01-20	1964-11-03	∞	1964-11-10	∞
Никсон	Агнью	1969-01-20	1973-01-20	1968-11-05	∞	1968-11-12	∞
Никсон	Агнью	1973-01-20	1977-01-20	1972-11-07	∞	1972-11-14	1973-10-17
Никсон	Агнью	1973-01-20	1977-01-20	1972-11-07	1973-10-10	1973-10-17	∞
Никсон	Агнью	1973-01-20	1973-10-10	1973-10-10	∞	1973-10-17	∞
Никсон	(свободно)	1973-10-10	1977-01-20	1973-10-10	∞	1973-10-17	1973-12-13
Никсон	Форд	∞	1977-01-20	1973-10-12	∞	1973-10-19	1973-12-13
Никсон	(свободно)	1973-10-10	1977-01-20	1973-10-10	1973-12-06	1973-12-13	∞
Никсон	(свободно)	1973-10-10	1973-12-06	1973-12-06	∞	1973-12-13	∞
Никсон	Форд	∞	1977-01-20	1973-10-12	1973-12-06	1973-12-13	∞
Никсон	Форд	1973-12-06	1977-01-20	1973-12-06	∞	1973-12-13	1974-08-15
Никсон	Форд	1973-12-06	1977-01-20	1973-12-06	1974-08-08	1974-08-15	∞
Никсон	Форд	1973-12-06	1974-08-09	1974-10-08	∞	1974-08-15	∞
Форд	(свободно)	1974-08-09	1977-01-20	1974-10-08	∞	1974-08-15	1974-12-26
Форд	Рокфеллер	∞	1977-01-20	1974-10-20	∞	1974-08-27	1974-12-26
Форд	(свободно)	1974-08-09	1977-01-20	1974-10-08	1974-12-19	1974-12-26	∞
Форд	(свободно)	1974-08-09	1974-12-19	1974-12-19	∞	1974-12-26	∞
Форд	Рокфеллер	∞	1977-01-20	1974-08-20	1974-12-19	1974-12-26	∞
Форд	Рокфеллер	1974-12-19	1977-01-20	1974-12-19	∞	1974-12-26	∞
Картер	Мондейл	1977-01-20	1981-01-20	1976-11-02	∞	1976-11-09	∞

Учитывая приведенную выше таблицу с 7-дневной задержкой, вопрос «кто был президентом и вице-президентом в период действия 1 января 1977 г.» (который, учитывая 7-дневную задержку, мог бы предоставить данные за 25 декабря 1976 г.) будет следующим:

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

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

Основная статья: Битемпоральное моделирование

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

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

Эволюция схемы

Основная статья: Эволюция схемы

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

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

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

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

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

• В версии MariaDB 10.3.4 добавлена ​​поддержка стандарта SQL:2011 как «Таблицы с системными версиями».
• База данных Oracle – Oracle Workspace Manager – это функция базы данных Oracle, которая позволяет разработчикам приложений и администраторам баз данных управлять текущими, предлагаемыми и историческими версиями данных в одной базе данных.
• В 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-документов в двоичном формате благодаря новому алгоритму управления версиями, называемому скользящим снимком, который уравновешивает производительность чтения/записи и никогда не создает пиков записи. Запросы путешествий во времени поддерживаются изначально, а также функции сравнения.
• XTDB на определенный момент времени (ранее Crux) обеспечивает побитемпоральные запросы к журналу данных по транзакциям и документам, полученным из полунеизменяемых журналов Kafka. Документы автоматически индексируются для создания индексов модели «сущность-атрибут-значение» без необходимости определения схемы. Операции транзакции указывают эффективное время действия. Время транзакций назначается Kafka и обеспечивает горизонтальное масштабирование посредством последовательного чтения.
• RecallGraph — это графовая база данных на определенный момент времени (время транзакции), построенная на основе ArangoDB . ArangoDB микросервиса Foxx Он работает на подсистеме . Он имеет семантику, подобную VCS , во многих частях своего интерфейса и поддерживается трекером транзакционных событий. Битемпоральность указана как один из пунктов в дорожной карте развития .
• Datomic «представляет собой распределенную базу данных, которая обеспечивает транзакции ACID, гибкую схему, [...] запросы к журналу данных, полную историю данных и поддержку аналитики SQL». Для каждого изменения, внесенного в данные, он записывает ответственную транзакцию и момент времени, когда она произошла.

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

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

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

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

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

• Си Джей Дэйт , Хью Дарвен , Никос Лоренцос (2002). Временные данные и реляционная модель, первое издание (Серия Моргана Кауфмана по системам управления данными); Морган Кауфманн; 1-е издание; 422 страницы. ISBN   1-55860-855-9 .
• Джо Селко (2014). «SQL для умников» Джо Селко: расширенное программирование на SQL (серия Моргана Кауфмана по управлению данными); Морган Кауфманн; 5-е издание. ISBN   978-0-12-800761-7 . — В главах 12 и 35, в частности, обсуждаются временные проблемы.
• Снодграсс, Ричард Т. (1999). « Разработка ориентированных на время приложений баз данных на SQL » (PDF) .   (4,77 МБ ) (Серия Моргана Кауфмана по системам управления данными); Морган Кауфманн; 504 страницы; ISBN   1-55860-436-7

См. также

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

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

• «ТаймЦентр Домашний» . Центр времени . Компьютерные науки Университета Аризоны. Архивировано из оригинала 24 февраля 2020 г.
• Временные отношения в RDF
• Временная область видимости для троек RDF
• IBM DB2 10 для z/OS
• Время и снова время» Рэнди Вейса и Тома Джонстона Серия статей «
• Временные паттерны Мартина Фаулера