Как удалить темпоральную таблицу mssql

Данные в базах данных почти всегда неразрывно связаны со временем. Это верно и для транзакционных баз данных (дата и время авиарейсов, поступления запасов на склады, начала обработки заказов в Интернет-магазинах и т.д.), и тем более для аналитических баз данных (в частности, время является важнейшим измерением OLAP-кубов).

До начала 1990-х гг. представление в базах данных даты-времени и обработка соответствующей информации возлагались на приложения, что было нехорошо во многих отношениях и, в частности, привело к возникновению печально известной проблемы 2000-го года [1], которая, хотя и была преувеличена, вызвала во всем мире немало хлопот.

Серьезный шаг вперед был сделан в 1992 г. в стандарте SQL/92 (SQL:1992) [2], в котором были определены специальные «темпоральные» типы данных (DATE, TIME, TIMESTAMP и INTERVAL). Эти типы данных не только обеспечивают стандартное представление дат, значений времени и временных интервалов, но и набор полезных операций над темпоральными значениями, в том числе, логическую операцию OVERLAP, вырабатывающую истинное значение, если два заданных временных диапазона имеют непустое пересечение.

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

В истинно темпоральных базах данных для каждого объекта базы данных автоматически поддерживаются все его состояния от момента создания до момента уничтожения. Системы управления базами данных (СУБД), поддерживающие темпоральные базы данных, и сами называются темпоральными СУБД. Начиная с 1980-х вокруг темпоральных баз данных велась активная исследовательская работа, связанная как с теоретическими аспектами поддержки времени в базах данных, так и с проблемами реализации темпоральных СУБД [3].

В 1995 г. была завершена работа специально созданного комитета под руководством Ричарда Снодграсса по выработке спецификаций языка SQL, поддерживающего темпоральные базы данных (TSQL2) [4]. В том же году в комитете по стандартизации SQL Международной организации по стандартизации (ISO) был начат проект по разработке расширений стандарта SQL (SQL:1992) на основе идей TSQL2. Однако анализ экспертов показал наличие в TSQL2 неустранимых противоречий [5]. Кроме того, для реализации TSQL2 требовалась очень значительная переделка существующих SQL-ориентированных СУБД, а основные производители коммерческих СУБД соответствующего желания не испытывали. В результате в 2001 г. проект был закрыт.

Несколькими годами позже в комитет по стандартизации SQL поступили новые предложения расширений SQL, которые были одобрены комитетом. Это привело к принятию в конце 2011 г. нового стандарта SQL:2011, во второй части которого (Foundation) содержатся спецификации темпоральных расширений [6]. Бесплатно доступен предельно близкий к официальному стандарту SQL:2011 драфт [7]. Темпоральные средства SQL подробно обсуждаются в книге [8], но, как свойственно Дейту, это обсуждение ведется в виде критического сравнения с собственной темпоральной моделью авторов, которой посвящена основная и весьма объемная часть книги. Это несколько затрудняет понимание сути темпоральных расширений в SQL:2011. Неформально и понятно темпоральные возможности SQL описаны в [9].

В стандарте SQL:2011 используется так называемая битемпоральная модель. Это означает, что в SQL-ориентированных базах данных могут поддерживаться два вида времени: транзакционное (transactional time, автоматически обеспечиваемое системой) и истинное (valid time, задаваемое приложениями базы данных). В стандарте SQL транзакционное время называется системным (system time), а истинное время — прикладным (application time). Подробнее об этом говорится в основной части статьи.

К середине 2017 г. полнее всего темпоральная часть SQL:2011 поддерживается в IBM DB2 [10]. Оба вида времени поддерживаются и в Oracle, но, как отмечается в [11], реализацию темпоральных средств пока нельзя считать полной (кроме того, похоже, что синтаксис темпоральных конструкций в Oracle SQL отличен от стандартного). Полная поддержка времени еще с 2010 г. имеется в Teradata [12], но реализациия опирается на TSQL2, а не на стандарт SQL. В ряде СУБД (в том числе, в Microsoft SQL Server [13] и PostgreSQL [14]) имеется частичная поддержка времени с некоторой опорой на SQL:2011.

В этой статье приводится обзор темпоральных расширений, введенных в SQL:2011. [1] Обзор опирается на материалы [6-9]. Изложение следует плану доклада на семинаре Московской секции ACM SIGMOD [15]. Во втором разделе рассматриваются основные понятия SQL:2011, связанные с темпоральными средствами. Третий раздел посвящен обсуждению средств поддержки прикладного времени, четвертый — средств поддержки системного времени. В пятом разделе описываются возможности определения битемпоральных таблиц. Шестой раздел заключает статью.

2. Основные понятия

В основе битемпоральной модели SQL лежит понятие периода времени (time period) — полуинтервала оси времени, начинающегося в точке начального времени (start time) и заканчивающегося в точке конечного времени (end time). Почти во всех случаях применяется замкнуто-открытая (closed-open) семантика периодов времени: период включает точку начального времени и не включает точку конечного времени. [2] Периоды времени можно определять и связывать со строками таблиц.

В отличие от других подходов (в частности, TSQL2 [4]), в модели SQL для периодов времени не вводится специальный тип данных. В [9] отказ от введения нового типа данных обосновывается следующими соображениями. Во-первых, добавление нового типа данных в стандарт SQL потребовало бы не только серьезных переделок в SQL-ориентированных СУБД, но и оснащения соответствующими средствами всех языков серверного программирования, расширения всех API для клиентского программирования (ODBC, JDBC, .NET и т.д.), соответствующих переделок средств ETL и т.д. Все это (в лучшем случае) значительно задержало бы реализацию темпоральных расширений.

Во-вторых, поскольку темпоральные возможности реально требуются во многих приложениях, при отсутствии соответствующей поддержки со стороны СУБД многие разработчики приложений реализовывали нужные им темпоральные возможности внутри приложений. Для этого обычно в таблицы баз данных добавлялись два столбца — начальное время и конечное время периода. Подобные приложения проще адаптировать к системной поддержке времени, если периоду времени по-прежнему будут соответствовать два столбца каждой темпоральной таблицы.

Рис. 1. Определение периода времени в определении таблицы

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

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

Для любой строки ее период транзакционного времени может произвольным образом отличаться от периода истинного времени. Например, если 26 мая 2017 г. в таблицу USA_Presidents вставляется строка с данными Барака Обамы, то в соответствии с реальностью она корректна в периоде истинного времени с 20 января 2009 года по 20 января 2017 года. В периоде же транзакционного времени данная строка действительна с 26 мая 2017 г. до ближайшей операции изменения.

В SQL:2011 транзакционное время поддерживается на основе механизма системно-версионных таблиц (system-versioned table), в определение которых входит определение периода системного времени (system-time period), а истинное время — на основе таблиц, в определение которых входит определение периода прикладного времени (application-time period). Имя периода системного времени в стандарте предопределено (SYSTEM_TIME), а имя периода прикладного времени задается пользователями. Для каждой таблицы можно определить не более одного периода системного времени и не более одного периода прикладного времени.

3. Таблицы с периодом прикладного времени

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

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

CREATE TABLE EMP (
EMP_NO EMP_NO,
EMP_DEPT_NO DEPT_NO,
EMPStart DATE NOT NULL,
EMPEnd DATE NOT NULL,
PERIOD FOR EMPPeriod (EMPStart, EMPEnd));

Рис. 2. Определение таблицы с периодом прикладного времени

На рис. 2 приведено определение таблицы служащих с периодом прикладного времени. Здесь типом данных столбцов начала и конца периода является DATE, но можно использовать и тип TIMESTAMP, лишь бы у обоих столбцов типы данных были одинаковыми. В обоих столбцах запрещаются неопределенные значения.

Начальные значения начальной и конечной точек периода прикладного времени для данной строки устанавливаются при вставке этой строки в таблицу с помощью обычного оператора INSERT. На рис. 3 показан оператор INSERT, вставляющий одну строку в таблицу EMP (данные о служащем с номером 22217, который работал в третьем отделе в период с 1 января 2010 г. до 12 ноября 2011 г.), и состояние этой таблицы после выполнения операции вставки (предполагается, что до этого таблица была пустой) [3],[4] . Для изменения (включая столбцы начальной и конечной точек периода) и удаления строк таблиц с периодом прикладного времени можно использовать обычные операторы UPDATE и DELETE соответственно.

INSERT INTO EMP VALUES (22217,
DATE ‘01.01.2010’,
DATE ‘12.11.2011’, 3)

Рис. 3. Вставка строки в таблицу EMP

3.1 Операции UPDATE и DELETE с разделом FOR PORTION OF

Для таблиц с периодом прикладного времени в SQL:2011 обеспечивается возможность изменений, которые действуют в течение заданного периода времени. Для этого в операторах UPDATE и DELETE нужно использовать новый раздел FOR PORTION OF. Расширенный синтаксис операторов UPDATE и DELETE показан на рис. 4.

Рис. 4. Синтаксис «поисковых» операторов UPDATE и DELETE в SQL:2011

Предположим, что про служащего с номером 22217 стало известно, что в период с 3 февраля 2011 г. по 10 сентября 2011 г. он числился в отделе номер 4. Тогда над таблицей EMP можно выполнить операцию UPDATE, текст которой и вид результирующей таблицы показаны на рис. 5 (предполагается, что изменение применяется к таблице EMP с рис. 3).

UPDATE EMP
FOR PORTION OF EMPPeriod
FROM DATE ‘03.02.2011’
TO DATE ‘09.10.2011’
SET EMP_DEPT_NO = 4
WHERE EMP_NO = 22217

Рис. 5. Оператор UPDATE с разделом FOR PORTION OF

При выполнении этого оператора СУБД должна найти в таблице EMP все строки, у которых период прикладного времени имеет общую часть с периодом P c 3 февраля по 10 сентября 2011 г. (в соответствии с принятой замкнуто-открытой семантикой 3 февраля входит в P, а 10 сентября не входит). Для тех строк, для которых период прикладного времени входит в P, выполняется оставшаяся часть оператора (т.е. в строках, удовлетворяющих условию, меняется значение EMP_DEPT_NO).

Если у периода прикладного времени строки, у которой период имеет общую часть с периодом P, есть также и часть, строго предшествующая P или строго следующая за P, то строка расщепляется на две или три последовательные (во времени) строки в зависимости от вида перекрытия, и у той строки, у которой период прикладного времени содержится в P, изменяется столбец EMP_DEPT_NO. Конечно, во всех строках соответствующим образом изменяются столбцы EMPStart и/или EMPEnd. На рис. 5 мы имеем дело с расщеплением исходной строки на три. Первая и третья строки считаются заново вставленными (и для них могут сработать триггеры по INSERT), а вторая — обновленной (и для нее могут сработать триггеры по UPDATE).

Аналогично работает оператор DELETE с разделом FOR PORTION OF. Предположим, про служащего с номером 22217 стало известно, что в период с 3 февраля 2011 г. по 10 сентября 2011 г. он не работал. Тогда над таблицей EMP можно выполнить оператор DELETE, текст которого и вид результирующей таблицы показаны на рис. 6 (предполагается, что изменение применяется к таблице EMP с рис. 3).

DELETE EMP
FOR PORTION OF EMPPeriod
FROM DATE ‘03.02.2011’
TO DATE ‘09.10.2011’
WHERE EMP_NO = 22217

Рис. 6. Оператор DELETE с разделом FOR PORTION OF

Для тех строк, для которых период прикладного времени входит в P, выполняется оставшаяся часть оператора (т.е. строки, удовлетворяющие условию, удаляются). Если у периода прикладного времени строки, у которой период имеет общую часть с периодом P, есть также часть, строго предшествующая P или строго следующая за P, то строка расщепляется на две или три последовательные (во времени) строки в зависимости от вида перекрытия, и та строка, у которой период прикладного времени содержится в P, удаляется. Конечно, в остающихся строках соответствующим образом изменяются столбцы EMPStart или EMPEnd.

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

3.2 Первичный ключ и ссылочные ограничения целостности

Как показывают примеры предыдущего подраздела, если таблица EMP является таблицей с периодом прикладного времени, то в отличие от привычных таблиц служащих столбец EMP_NO не является первичным ключом. Похоже, что в этом случае первичным ключом должна являться комбинация столбцов (точнее, комбинация столбца EMP_NO и периода EMPPeriod, потому что у служащего должен иметься один отдел в каждой точке каждого периода прикладного времени). Однако этого не всегда достаточно.

Рис. 7. Строки с перекрывающимися периодами прикладного времени

Если объявить первичным ключом таблицы EMP составной столбец , то наполнение EMP с рис. 7 (a) недопустимо, поскольку нарушает ограничение первичного ключа. Однако таблица EMP вполне может содержать строки с рис. 7 (b). Содержательно это означает, что служащий 22217 не мог работать сразу в двух отделах в периоде с 1 января 2010 г. до 3 февраля 2011 г., но ему было позволено это с 10 сентября 2010 г.

Это ограничение странно само по себе, трудно объяснить его смысл. Но главное, что недопустимость таблицы с рис. 7 (a) согласуется с тем, что в таблице EMP без периода прикладного времени столбец EMP_NO являлся бы первичным ключом. В частности, это означает, что ни один служащий ни в какой момент времени не может работать сразу в двух отделах, а допустимость EMP с рис. 7 (b) смыслу EMP_NO противоречит.

Поэтому ситуации, подобные той, которая показана на рис. 7 (b), в стандарте SQL следовало бы запретить, уточнив семантику первичного ключа, включающего период прикладного времени. Однако разработчики стандарта на это не пошли, обеспечив вместо этого спецификацию WITHOUT OVERLAPS в определении первичного ключа. Для нашей таблицы EMP первичный ключ следовало бы определить следующим образом:

PRIMARY KEY (ENo, EMPPeriod, WITHOUT OVERLAPS).

Спецификация первичного (и возможного) ключа WITHOUT OVERLAPS в SQL:2011 является опциональной, так что по умолчанию перекрытия периодов прикладного времени у строк, соответствующих одной и той же сущности предметной области, допускаются. Как мы видели выше, это приводит к потенциальной возможности возникновения ситуаций, противоречащих здравому смыслу. Так что, как минимум, стоило бы запретить такие перекрытия по умолчанию (если не запретить вовсе).

(a)
CREATE TABLE DEPT (
DEPT_NO DEPT_NO,
DEPT_NAME VARCHAR(30),
DEPTStart DATE NOT NULL,
DEPTEnd DATE NOT NULL,
PERIOD FOR DEPTPeriod (DEPTStart, DEPTEnd),
PRIMARY KEY (DEPT_NO, DEPTPeriod WITHOUT OVERLAPS))

Рис. 8. Недопустимые и допустимые значения внешнего ключа

На рис. 8 показано определение таблицы DEPT с периодом прикладного времени (a) и три теоретически возможных наполнения таблиц EMP и DEPT ((b), (c) и (d)). В соответствии со здравым смыслом и традиционной семантикой базы данных EMP-DEPT столбец EMP_DEPT_NO таблицы EMP должен содержать «ссылки» на строки таблицы DEPT, и каждому отличного от NULL значению столбца EMP_DEPT_NO должна соответствовать в точности одна строка таблицы DEPT (отдел, в котором работает каждый служащий, должен существовать и быть единственным). Другими словами, в традиционном случае столбец EMP_DEPT_NO является внешним ключом, которому соответствует первичный ключ DEPT_NO таблицы DEPT.

В таблице DEPT с периодом прикладного времени DEPT_NO не является первичным ключом. Тем не менее, для таблиц EMP и DEPT с рис. 8 (b) и 8 (c) ограничение внешнего ключа, на первый взгляд, выполняется: служащий 22217 в разные периоды времени работал в отделах 3 и 4, и в таблице DEPT содержатся две строки, соответствующие обоим этим отделам.

Однако DEPT, как и EMP, является таблицей с периодом прикладного времени! Каждая строка каждой из этих таблиц связана с периодом ее корректности. Содержимое таблицы EMP с рис. 8 (b) показывает, что служащий 22217 работал в 3-м отделе с 1 февраля 2010 г. по 3 февраля 2011 г., а с 3 февраля 2011 г. по 12 ноября 2011 г. работал в 4-м отделе. Из содержимого же таблицы DEPT следует, что отдел номер 3 существовал с 1 января 2009 г. по 31 декабря 2011 г., а 4-й отдел — с 1 июня по 31 декабря 2011 г. Следовательно, служащий 22217 мог работать в отделе 3 с 1 февраля 2010 г. по 3 февраля 2011 г., но не мог работать в отделе 4 с 3 февраля 2011 г. по 12 ноября 2011 г., и в действительности ограничение внешнего ключа для таблиц EMP и DEPT с рис. 8 (b) не выполняется.

С другой стороны, содержимое таблицы DEPT на рис. 8 (c) показывает, что отдел 4 существовал с 1 февраля по 31 декабря 2011 г. Поэтому служащий 22217 в период 3 февраля 2011 г. по 12 ноября 2011 г. мог работать в этом отделе, и ограничение внешнего ключа для таблиц EMP и DEPT с рис. 8 (c) выполняется.

Более того, по смыслу ссылочное ограничение выполняется и для таблиц EMP и DEPT с рис. 8 (d), где в DEPT присутствуют две строки с DEPT_NO, равным 4. Действительно, в этом варианте DEPT отдел 4 существовал с 1 февраля по 31 мая 2011 г. по названием QA и с 1 июня по 31 декабря 2011 г. под названием Cross-Check. Поэтому служащий 22217 в период 3 февраля 2011 г. по 12 ноября 2011 г. мог работать в отделе номер 4.

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

Рис. 9. Синтаксис определения внешнего ключа для таблиц с периодом прикладного времени

Как показывают синтаксические правила, внешний ключ таблицы с периодом прикладного времени должен включать этот период и может ссылаться только на таблицы с периодом прикладного времени. Для таблицы EMP с рис. 8 (a) определение внешнего ключа могло бы выглядеть следующим образом:

FOREIGN KEY (EMP_DEPT_NO, Period EMPPeriod)
REFERENCES DEPT (DEPT_NO, Period DEPTPeriod).

Ссылочное ограничение таблицы с периодом прикладного времени удовлетворяется в том и только в том случае, когда для каждой ее строки либо значения всех ссылающихся столбцов (referencing column на рис. 9) являются неопределенными, либо значения всех ссылающихся столбцов отличны от NULL и в таблице, на которую ведет ссылка, имеется непустой набор строк, значения соответствующих столбцов которых совпадают со значениями ссылающихся столбцов данной строки и объединение значений периодов прикладного времени которых включает значение периода прикладного времени данной строки. [5]

3.3 Предикаты с периодом прикладного времени

В стандарте SQL:2011 специфицированы новые предикаты, позволяющие формулировать условия выборки, включающие периоды прикладного времени: OVERLAPS, EQUALS, CONTAINS, PRECEDES, SUCCEEDS, IMMEDIATELY PRECEDES и IMMEDIATELY SUCCEEDS. Неформальный фрагмент синтаксических правил приведен на рис. 10.

Рис. 10. Неформальный синтаксис предикатов с периодом прикладного времени

Предикат OVERLAPS принимает значение true в том и только в том случае, когда два заданных периода прикладного времени перекрываются, то есть у них имеется хотя бы одна общая точка временной оси.
Предикат EQUALS принимает значение true в том и только в том случае, когда у двух заданных периодов прикладного времени совпадают начальные и конечные точки.
Предикат CONTAINS принимает значение true в том и только в том случае, когда первый период включает второй период или заданную точку временной оси.
Предикат PRECEDES принимает значение true в том и только в том случае, когда первый период предшествует второму, то есть все значения времени первого периода меньше начальной точки второго периода.
Предикат SUCCEEDS принимает значение true в том и только в том случае, когда первый период следует за вторым периодом, то есть все временные значения, входящие в первый период, больше или равны конечному значению второго периода.
Предикат IMMEDIATELY PRECEDES принимает значение true в том и только в том случае, когда первый период непосредственно предшествует второму периоду, то есть конечная точка первого периода совпадает с начальной точкой второго периода.
Наконец, предикат IMMEDIATELY SUCCEEDS принимает значение true в том и только в том случае, когда первый период непосредственно следует за первым периодом, то есть начальная точка первого периода совпадает с конечной точкой второго периода.
Если какое-либо выражение даты-времени, вычисляемое во время оценки предиката с периодом прикладного времени, приводит к неопределенному значению, то значением предиката является unknown.

Смысл предикатов достаточно очевиден. Для порядка приведем две формулировки запросов над таблицами EMP и DEPT с периодами прикладного времени.

Запрос 3.3.1. Найти номера служащих, начавших работать в отделе номер 3 во время существования отдела номер 4.

SELECT EMP_NO
FROM EMP, DEPT
WHERE EMP_DEPT_NO = 3 AND DEPT_NO = 4 AND
DEPTPeriod CONTAINS EMPStart

Запрос 3.3.2. Найти номера служащих, которые завершили работу в отделе номер 3 до образования отдела номер 4.

SELECT EMP_NO
FROM EMP, DEPT
WHERE EMP_DEPT_NO = 3 AND DEPT_NO = 4 AND
EMPPeriod PRECEDES DEPTPeriod

4. Системно-версионные таблицы

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

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

CREATE TABLE EMP (
EMP_NO EMP_NO,
EMP_NAME VARCHAR(30),
EMP_Sys_start TIMESTAMP(12)
GENERATED ALWAYS AS ROW START,
EMP_Sys_end TIMESTAMP(12)
GENERATED ALWAYS AS ROW END,
PERIOD FOR SYSTEM_TIME
(EMP_Sys_start, EMP_Sys_end)
) WITH SYSTEM VERSIONING

Рис. 11. Определение системно-версионной таблицы

На рис. 11 приведено возможное определение системно-версионного варианта таблицы EMP. В определении системно-версионной таблицы должна содержаться спецификация периода с именем SYSTEM_TINE и ключевые слова WITH SYSTEM VERSIONING. Как и для таблиц с периодами прикладного времени, в системно-версионной таблице должны быть определены два столбца с произвольными именами, сохраняющие начальное и конечное время периодов системного времени (на рис. 11 это столбцы EMP_Sys_start и EMP_Sys_end). Стандарт допускает использование для этих столбцов типов данных DATE и TIMESTAMP, однако в реализациях следует ожидать использования только типа TIMESTAMP с максимально допустимой точностью в долях секунды.

Как и для периодов прикладного времени, для периодов системного времени используется замкнуто-открытая модель. В любой момент времени строка системно-версионной таблицы считается текущей системной строкой (current system row), если ее период системного времени включает текущее время. Строка системно-версионной таблицы, не являющаяся текущей, считается исторической системной строкой (historical system row).

4.1 Отличия системно-версионных таблиц от таблиц с периодами прикладного времени

В отличие от таблиц с периодами прикладного времени, пользователи не могут заносить значения в столбцы начала и конца периода системного времени (или изменять значения этих столбцов). Эти столбцы устанавливаются и изменяются системой автоматически. Поэтому определения таких столбцов должны включать ключевые слова GENERATED ALWAYS.
При вставке строки в системно-версионную таблицу в столбец начала периода системного времени этой строки заносится временная метка транзакции (transaction timestamp) — специальное значение, ассоциированное с каждой транзакцией [6] , а в столбец конца периода — наибольшее значение типа данных этого столбца. На рис. 12 показан пример вставки строки в пустую системно-версионную таблицу EMP (считается, что значением временной метки соответствующей транзакции является 01.01.2012 09:00:00).

INSERT INTO EMP (EMP_NO, EMP_NAME)
VALUES (22217, ‘Joe’);

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

4.2 Операции UPDATE и DELETE над системно-версионными таблицами

Операция UPDATE над строкой системно-версионной таблицы сначала заносит в таблицу копию обновляемой строки, к которой в столбец конечной точки периода системного времени устанавливается значение временной метки транзакции, в которой выполняется UPDATE (строка перестала быть текущей во время выполнения этой транзакции). Затем строка соответствующим образом обновляется, причем значением ее столбца начальной точки периода системного времени становится временная метка транзакции. На рис. 13 показан пример операции UPDATE над таблицей EMP с рис. 12 (считается, что значением временной метки соответствующей транзакции является 03.02.2012 10:00:00).

UPDATE Emp
SET EName = ‘Tom’
WHERE ENo = 22217

Рис. 13. Обновление строки в системно-версионной таблице

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

Замечание 4.3.1. Если в одной транзакции некоторая строка таблицы с периодом системного времени обновляется более одного раза, то историческая системная строка заносится в таблицу только один раз при выполнении первой операции обновления. Как указано в стандарте SQL:2011, если значение столбца начала периода системного времени обновляемой строки совпадает со значением временной метки транзакции, то эта строка обновляется без вставки соответствующей исторической системной строки.

Замечание 4.3.2. Если при выполнении операции обновления транзакции некоторой строки таблицы с периодом системного времени оказывается, что значение столбца начала периода системного времени обновляемой строки меньше значения временной метки транзакции, то операция не выполняется, и возникает исключительная ситуация «invalid row version». Другими словами, по естественным причинам не допускается обновление строки таблицы с периодом системного времени, которая до этого обновлялась в транзакции, более «молодой», чем та, в которой выполняется текущая операция обновления (не удается сформировать допустимый период системного времени в новой исторической системной строке). Понятно, что в возникновении такой ситуации никак не повинно приложение, от имени которого выполняется пострадавшая транзакция, и поэтому возможность возникновения исключительной ситуации «invalid row version» можно считать серьезным недостатком подхода к работе с системным временем, предлагаемого в стандарте. Если ничего не менять, то единственным выходом из положения (по крайней мере, на мой взгляд; в стандарте и у его комментаторов на этот счет ничего не говорится) является полный откат пострадавшей транзакции и повторное ее выполнение с новой временной меткой. При повторном выполнении неприятная ситуация, скорее всего, не повторится.

Операция DELETE над системно-версионной таблицей изменяет значение столбцов конца периода системного времени «удаляемых» текущих системных строк, делая их тем самым историческими системными строками. На рис. 14 показан пример операции DELETE над системно-версионной таблицей EMP с рис. 12 (предполагается, что значением временной метки соответствующей транзакции является 01.06.2012 00:00:00).

DELETE FROM EMP
WHERE EMP_NO = 22217;

Рис. 14. Удаление строки из системно-версионной таблицы EMP

При таком «удалении» строк возбуждаются триггеры по удалению. Как и операция обновления, операция удаления строки из системно-версионной таблицы может не удасться (см. замечание 4.3.2).

4.3 Первичный ключ и ссылочное ограничение целостности

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

Поэтому для системно-версионных таблиц не требуется включать в состав первичного или внешнего ключа период системного времени. В частности, для системно-версионной таблицы EMP первичным ключом может быть объявлен столбец EMP_NO, а внешним ключом, ссылающимся на таблицу DEPT — столбец EMP_DEPT_NO.

Замечание 4.4.1. Приведенные выше утверждения заведомо справедливы, если все таблицы базы данных являются системно-версионными. Тогда можно утверждать, что для любой временной метки в прошлом все исторические и текущие строки всех таблиц, период системного времени которых включает данную временную метку, образуют целостную базу данных в соответствии с набором ограничений целостности, существовавшим в соответствующий момент времени. В противном случае целостность версий обеспечивается не обязательно. Действительно, предположим, что таблица EMP является системно-версионной, а таблица DEPT — нет. Пусть некоторая строка emp_row таблицы EMP стала исторической (в результате обновления) в момент времени t₀. Пусть эта строка ссылается на некоторую строку dept_row таблицы DEPT. В момент t₀ ссылочная целостность поддерживается. Затем в момент t₁ (t₁ > t₀) строка dept_row из таблицы DEPT удаляется. После этого ссылка на dept_row из emp_row становится ложной (в базе данных вообще нет строки, на которую ссылается emp_row). Это замечание относится не только к ограничениям ссылочной целостности, но и ко всем ограничениям, затрагивающим более чем одну таблицу.

4.4 Запросы в системно-версионных таблицах

Имя системно-версионной таблицы можно просто указывать в разделе FROM запроса, и тогда в расчет принимаются только текущие системные строки этой таблицы. Чтобы можно было выбрать исторические системные строки, в стандарте SQL:2011 предлагаются синтаксические расширения конструкции table reference. Фрагмент набора синтаксических правил приведен на рис. 15.

Рис. 15. Синтаксис ссылки на системно-версионную таблицу в разделе FROM запроса

(a)
SELECT ENo, EName, EMP_Sys_start, EMP_Sys_end
FROM EMP FOR SYSTEM_TIME AS OF
TIMESTAMP ‘02.01.2011 00:00:00’

(b)
SELECT ENo, EName, EMP_Sys_start, EMP_Sys_end
FROM EMP FOR SYSTEM_TIME FROM
TIMESTAMP ‘02.01.2011 00:00:00’ TO
TIMESTAMP ‘31.12.2011 00:00:00’

(c)
SELECT ENo, EName, EMP_Sys_start, EMP_Sys_end
FROM EMP FOR SYSTEM_TIME BETWEEN
TIMESTAMP ‘02.01.2011 00:00:00’ AND
TIMESTAMP ‘31.12.2011 00:00:00’

(d)
SELECT ENo, EName, EMP_Sys_start, EMP_Sys_end
FROM EMP FOR SYSTEM_TIME FROM
TIMESTAMP ‘0001-01-01 00:00:00’ TO
TIMESTAMP ‘9999-12-31 23:59:59’

Рис. 16. Примеры запросов к системно-версионной таблице

Как показывает синтаксис на рис. 15, имеются три основные возможности указания временных характеристик исторических системных строк при указании ссылки на системно-версионную таблицу в разделе FROM запроса. Спецификация FOR SYSTEM TIME AS OF инструктирует систему о потребности выбрать все строки таблицы, период системного времени которых включает заданную временную метку (ее значение должно быть не меньше значения начального столбца и меньше значения конечного столбца периода системного времени строк-кандидатов на выборку). Пример операции выборки со спецификацией FOR SYSTEM TIME AS OF показан на рис. 16 (a).

Спецификация FOR SYSTEM_TIME FROM … TO … означает, что кандидатами на выборку должны являться все строки указанной системно-версионной таблицы, у которых значение столбца начала периода системного времени меньше значения второй заданной временной метки, а значение столбца конца периода больше значения первой временной метки. Другими словами, кандидатами на выборку являются все строки, которые являлись текущими системными строками в период системного времени, указанный в запросе. Пример операции выборки со спецификацией FOR SYSTEM_TIME FROM … TO … показан на рис. 16 (b).

Наконец, спецификация FROM EMP FOR SYSTEM_TIME BETWEEN … AND … говорит о том, что кандидатами на выборку должны являться все строки указанной системно-версионной таблицы, у которых значение столбца начала периода системного времени не больше значения второй заданной временной метки, а значение столбца конца периода больше значения первой временной метки. При этом допускается, чтобы у обоих заданных в запросе временных меток было одно и то же значение. По сути, запрос с BETWEEN отличается от запроса с FROM тем, что в число строк-кандидатов попадают те, для которых значение столбца конца периода системного времени совпадает со значением первой временной метки (концом заданного в запросе периода). Пример операции выборки со спецификацией FROM EMP FOR SYSTEM_TIME BETWEEN … AND … показан на рис. 16 (c).

Как видно из синтаксиса на рис. 15, спецификация с BETWEEN может включать ключевые слова SYMMETRIC или ASYMMETRIC (по умолчанию полагается задание ASYMMETRIC). При использовании варианта ASYMMETRIC требуется, чтобы значение второй временной метки было не меньше значения первой временной метки. Если же задано ASYMMETRIC, и значение второй временной метки оказывается меньше значения первой временной метки (в общем случае эти значения вычисляются на стадии выполнения запроса), то эти временные метки меняются местами — вторая метка становится первой, а первая — второй.

Наконец, как показывает рис. 16 (d), из системно-версионной таблицы можно выбрать все строки, и исторические, и текущие.

Замечание 4.5.1. Описанные выше конструкции, безусловно, работают в запросах над одной системно-версионной таблицей. Однако спецификация требуемого от выбираемых строк периода системного времени при указании ссылки на таблицу может привести к получению бессмысленных результатов, если в разделе FROM запроса указывается несколько ссылок на таблицы и хотя бы в одной из этих ссылок содержатся обсуждавшиеся выше спецификации. Например, может ли быть осмысленным результат естественного соединения исторических записей из EMP и DEPT, если для этих системно-версионных таблиц в разделе FROM заданы разные периоды? Еще интереснее (и бессмысленнее) соединять исторические строки с текущими. Мне кажется, что здесь видна явная существенная недоработка стандарта SQL:2011. Интересно, что аналогичные проблемы имеются и в реализациях. Например, в Microsoft SQL Server 2016 реализована близкая к стандарту поддержка системно-версионных таблиц, и для обхода (хотя бы частичного) отмеченных проблем рекомендуется накрывать используемые в запросах системно-версионные таблицы представлениями, чтобы в запросе использовалась только одна ссылка на таблицу [17]. Понятно, что в целом это проблему не решает.

5. Битемпоральные таблицы

Понятно, что понятия прикладного и системного времени являются ортогональными, и никто не мешает определить таблицу, которая одновременно являлась бы и таблицей с периодом прикладного времени, и таблицей с периодом системного времени. Такие таблицы уместно называть битемпоральными, хотя в стандарте SQL:2011 этот термин не используется (как и термин темпоральный вообще). На рис. 17 показано возможное определение битемпоральной таблицы EMP.

CREATE TABLE EMP (
EMP_NO EMP_NO,
EMP_DEPT_NO DEPT_NO,
EMP_NAME VARCHAR(30),
EMPStart DATE NOT NULL,
EMPEnd DATE NOT NULL,
PERIOD FOR EMPPeriod (EMPStart, EMPEnd),
EMP_Sys_start TIMESTAMP(12)
GENERATED ALWAYS AS ROW START,
EMP_Sys_end TIMESTAMP(12)
GENERATED ALWAYS AS ROW END,
PERIOD FOR SYSTEM_TIME
(ENP_Sys_start, EMP_Sys_end),
PRIMARY KEY (EMP_NO, EMPPeriod
WITHOUT OVERLAPS),
FOREIGN KEY (EMP_DEPT_NO, PERIOD EMPPeriod)
REFERENCES (DEPT_NO, PERIOD DEPTPeriod)
) WITH SYSTEM VERSIONING

Рис. 17. Битемпоральная таблица EMP

Битемпоральные таблицы полезны в тех случаях, когда требуется знать системное время изменений состояния базы данных, отражающие изменения состояния моделируемых в ней объектов в прикладном времени. Например, служащая с фамилией Smith может изменить свою фамилию на Brown 25 мая 2017 г. (например, выйти замуж). 25.05.2017 это официально фиксируется в паспорте, но соответствующее изменение строки таблицы EMP происходит только через месяц — 26 июня 2017 г. (по окончанию медового месяца) Тогда период прикладного времени для новой строки будет начинаться с 25.05.2017, а период системного времени, в котором эта строка является текущей, — с 26.06.2017. Эта информация, например, позволяет исправить внешние документы, в которых служащая именовалась девичей фамилией и которые были произведены с 25 мая по 25 июня 2017 г.

Как и в случае таблиц с периодом прикладного времени, над битемпоральными таблицами можно выполнять как традиционные операции UPDATE и DELETE, так и операции обновления и удаления с ключевыми словами FOR PORTION OF. Как и в случае таблиц с периодом системного времени, обновлять и удалять можно только текущие системные строки, и в результате выполнения этих операций в таблицу вставляются соответствующие исторические системные строки.

Запросы над битемпоральными таблицами могут включать и предикаты прикладного времени, и спецификации периодов системного времени. Пример запроса показан на рис. 18 (найти номера служащих, у которых строка имени равнялась ‘Brown’ 25 мая 2017 г. прикладного времени и являлась текущей системной строкой 25 июня 2017 г.).

SELECT EMP_NO
FROM EMP FOR SYSTEM_TIME AS OF
TIMESTAMP ‘25.06.2017 23:59:59’
WHERE EMP_NAME = ‘Brown’ AND
EMPPeriod CONTAINS DATE ‘25.05.2017’

Рис. 18. Пример запроса к битемпоральной таблице

6. Заключение

14 лет тому назад в Москву приезжал бессменный редактор стандартов SQL Джим Мелтон [18]. Один из моих вопросов, не вошедших в опубликованное интервью, касался темпоральных расширений SQL. Меня удивляло, что при наличии хорошо разработанных предложений по расширению SQL темпоральными средствами [4] комитет по стандартизации SQL затягивает принятие соответствующего стандарта. Тогда Джим ничего не сказал насчет того, что TSQL2 не удовлетворил стандартизаторов, а лишь заметил, что комитет руководствуется пожеланиями основных вендоров SQL-ориентированных СУБД, а те, в свою очередь, стараются удовлетворять пожелания своих пользователей.

разумное использование базовой инфраструктуры SQL;
простота и понятность;
понятная и сравнительно простая возможная реализация в СУБД, поддерживающих предыдущие стандарты SQL.

Наверное, Дейт, Дарвен и Лоренцос в [8] правильно указывают на неполноту и ограниченность решения, внедренного в стандарт SQL, но на мой взгляд даже одно достоинство простоты перевешивает концептуальные недостатки этого решения. Такой простотой не отличается собственное решение проблемы темпоральных баз данных, предлагаемое Дейтом и др. в [8], а сложность отпугивает потенциальных пользователей.

А вот добиться того, чтобы с использованием новых конструкций SQL пользователи и разработчики приложений не могли получать бессмысленные результаты, упомянутые в данной статье, просто необходимо. Иначе пользователи не будут доверять темпоральным средствам. Пока это стандартизаторами SQL не сделано, хотя вышла уже следующая версия стандарта [19]. Придется еще подождать…

Список литературы

Константин Пьянзин. Проблема Y2K. Журнал сетевых решений/LAN, 1998, № 05
С.Д. Кузнецов. Основы баз данных. 2-е изд. Бином. Лаборатория знаний, Интернет-университет информационных технологий, Москва, 2007, 488 стр.; лекции 11 и 14
С.Д. Кузнецов, Б.Б.Костенко. История и актуальные проблемы темпоральных баз данных. Труды Института системного программирования, т. 13, часть 2, М., ИСП РАН, 2007, стр. 77-114
Richard T. Snodgrass, editor. The TSQL2 Temporal Query Language. Kluwer Academic Publishers, 1995, 674+xxiv p. Спецификация языка доступна online на ftp://ftp.cs.arizona.edu/tsql/tsql2/bookspec.pdf
Hugh Darwen, C.J. Date. An overview and Analysis of Proposals Based on the TSQL2 Approach. In Date on Database: Writings 2000-2006, C.J. Date, Apress, 2006. Драфт статьи доступен online на http://www.dcs.warwick.ac.uk/~hugh/TTM/OnTSQL2.pdf
ISO/IEC 9075-2:2011, Information technology—Database languages—SQL—Part 2: Foundation (SQL/Foundation), 2011
SQL:20nn Working Draft Documents. http://www.wiscorp.com/sql20nn.zip., 2011‑12‑21
C. J. Date, Hugh Darwen, Nikos A. Lorentzos. Time and Relational Theory. Temporal Databases in the Relational Model and SQL. Morgan Kaufmann; 2 edition, July 30, 2014
Krishna Kulkarni, Jan-Eike Michels. Temporal features in SQL:2011. ACM SIGMOD Record, Volume 41, Issue 3, September 2012, pp. 34-43
Cynthia Saracco, Matthias Nicola, and Lenisha Gandhi. A matter of time: Temporal data management in DB2 10. IBM developerWorks, https://www.ibm.com/developerworks/data/library/techarticle/dm-1204db2temporaldata/
Philipp Salvisberg. Multi-temporal Features in Oracle 12c. https://www.salvis.com/blog/2014/01/04/multi-temporal-database-features-in-oracle-12c/
Teradata. Temporal Table Support. http://www.info.teradata.com/HTMLPubs/DB_TTU_13_10/index.html#page/SQL_Reference/B035_1182_109A/title.01.2.html
Koen Verbeeck. Introduction to SQL Server 2016 Temporal Tables. https://www.mssqltips.com/sqlservertip/3680/introduction-to-sql-server-2016-temporal-tables/
Clark Dave. Historical records with PostgreSQL, temporal tables and SQL:2011. http://clarkdave.net/2015/02/historical-records-with-postgresql-and-temporal-tables-and-sql-2011/
С. Д. Кузнецов. Стандарт SQL во втором десятилетии XXI века. 181 заседание семинара Московской секции ACM SIGMOD. 21 января 2016 г. http://synthesis.ipi.ac.ru/sigmod/seminar/s20161229
Резниченко В.А. Темпоральный SQL:2011. Iнженерiя програмного забезпечення, № 3 – 4 (15 – 16), 2013, стр. 48-65
Carl Rabeler, Craig Guyer. Querying Data in a System-Versioned Temporal Table. https://docs.microsoft.com/en-us/sql/relational-databases/tables/querying-data-in-a-system-versioned-temporal-table
Леонид Черняк. Джим Мелтон о судьбе стандарта SQL. Открытые системы. СУБД, № 6, 2003. https://www.osp.ru/os/2003/06/183149/
New Edition of Database Language SQL Standard Published. https://share.ansi.org/Shared%20Documents/News%20and%20Publications/Links%20Within%20Stories/SQL%20standard%20published_POST.pdf

На русском языке темпоральные расширения SQL описаны в [16], однако в этой статье всего лишь честно пересказывается соответствующий материал стандарта SQL:2011 и не предпринимаются попытки его критического анализа. ↑

Не следует путать периоды времени со значениями типов INTERVAL, которые задают лишь продолжительность какого-либо события, не привязанную к точкам оси времени. ↑

В статье используются примеры из [9]. ↑

Во всех примерах используется европейский формат представления литералов типа DATE. ↑

Приводится определение для спецификации соответствия FULL. Для случаев SIMPLE и PARTIAL определение изменяется очевидным образом. ↑

Темпоральные таблицы SQL Server: практические рекомендации

Таблицы, которые возвращают значение данных в таблице в определенный момент времени, были у нас с момента появления первой реляционной базы данных, но всегда требовали специальных запросов и ограничений и могут быть непростыми для получения правильной информации. Системно управляемые версии темпоральных таблиц, впервые появившиеся в SQL Server 2016, заставляют такие таблицы вести себя как любые другие. Как создать или изменить существующую таблицу? Как получить таблицу OLTP, оптимизированную для памяти, как темпоральную?

Темпоральные таблицы или таблицы с системным управлением версиями были введены как функция базы данных в SQL Server 2016. Это дает нам тип таблицы, которая может предоставлять информацию о данных, которые хранились в любое указанное время, а не только текущие данные. ANSI SQL 2011 сначала определил темпоральную таблицу как функцию базы данных, и теперь она поддерживается в SQL Server.

Наиболее распространенные бизнес-применения для темпоральных таблиц:

Медленно меняющиеся измерения. Темпоральные таблицы предоставляют более простой способ запрашивать данные, которые являются текущими в течение определенного периода времени, такие как данные с разделением по времени, что является хорошо известной проблемой в базах данных хранилищ данных.
Аудит данных. Темпоральные таблицы предоставляют контрольный журнал для определения того, когда данные были изменены в «родительской» таблице. Это помогает удовлетворить требования нормативного соответствия и проводить экспертизу данных, когда это необходимо, путем отслеживания и аудита изменений данных с течением времени.
Исправление или восстановление повреждений на уровне записи. Создание способа «отмены» изменения данных в строке таблицы без простоя в случае случайного удаления или обновления записи. Таким образом, предыдущая версия данных может быть извлечена из таблицы истории и вставлена обратно в «родительскую» таблицу. — Это помогает, когда кто-то (или из-за некоторых ошибок приложения) случайно удаляет данные, и вы хотите вернуться к ним или восстановить их.
Воспроизведение финансовых отчетов, счетов и выписок с правильными данными на дату выдачи документа. Темпоральные таблицы позволяют запрашивать данные, как это было в конкретный момент времени, чтобы проверить состояние данных, как это было тогда.
Анализ тенденций путем понимания того, как данные изменяются с течением времени в ходе текущей бизнес-деятельности, и для расчета тенденций изменения данных с течением времени.

В давние времена до появления SQL Server 2016 механизм регистрации данных должен был быть явно установлен в триггере. Чтобы привести простой пример, нам нужно автоматизировать ведение истории для таблицы Department со следующей структурой, начиная с самой таблицы Department:

CREATE TABLE dbo.Department

DeptID INT NOT NULL,

DeptName VARCHAR(50) NOT NULL,

ManagerID INT NULL,

ParentDeptID INT NULL,

Created DATETIME NOT NULL

CONSTRAINT DF_Department_Created DEFAULT GETDATE(),

CONSTRAINT PK_Department_DeptID PRIMARY KEY CLUSTERED(DeptID ASC) ON [PRIMARY]

Следующим шагом является создание таблицы Department_Log с двумя дополнительными столбцами, которые предоставляют историю изменений

CREATE TABLE dbo.Department_Log

DeptID INT NOT NULL,

DeptName VARCHAR(50) NOT NULL,

ManagerID INT NULL,

ParentDeptID INT NULL,

Created DATETIME NOT NULL,

LogDate DATETIME NOT NULL,

LogAction VARCHAR(10) NOT NULL

Когда таблица «истории» будет готова, мы можем создать триггер для регистрации изменений действий UPDATE и DELETE:

CREATE TRIGGER dbo.tr_Department_Log

FOR UPDATE, DELETE

ON Inserted.DeptID = Deleted.DeptID

(DeptID, DeptName, ManagerID, ParentDeptID, Created, LogDate, LogAction)

SELECT Deleted.DeptID, Deleted.DeptName, Deleted.ManagerID,

Deleted.ParentDeptID, Deleted.Created, GETDATE(), ‘UPDATED’

(DeptID, DeptName, ManagerID, ParentDeptID, Created, LogDate, LogAction)

SELECT Deleted.DeptID, Deleted.DeptName, Deleted.ManagerID,

Deleted.ParentDeptID, Deleted.Created, GETDATE(), ‘DELETED’

SET NOCOUNT OFF;

Чтобы продемонстрировать, как таблица Department_Log работает с триггером, мы трижды обновляли строку, в которой DeptID = 1, затем удаляли эту строку и, наконец, при последнем обновлении для столбца DeptName устанавливалось первоначальное значение.

where DeptID = 1

SET DeptName = ‘Engineering IT’

where DeptID = 1

SET DeptName = ‘Engineering WEB’

where DeptID = 1

DELETE dbo.Department where DeptID = 1

INSERT dbo.Department(DeptID, DeptName)

FROM Department_Log WHERE DeptID = 1 and LogAction = ‘DELETED’

SET DeptName = ‘Engineering’

where DeptID = 1

select DeptID, DeptName,Created,LogDate,LogAction from Department_Log

Результат из таблицы Department_Log показан на следующем рисунке:

Функция темпоральных таблиц в SQL Server 2016 может значительно упростить механизм ведения журналов. В этой статье приводятся пошаговые инструкции по созданию таблиц с системной версией.

Чтобы перенести таблицу в темпоральную таблицу, для существующей таблицы можно установить параметр темпоральной таблицы. Чтобы создать новую темпоральную таблицу, вам просто нужно установить для параметра темпоральной таблицы значение ON (например, SYSTEM_VERSIONING = ON). Когда опция темпоральной таблицы включена, SQL Server 2016 автоматически генерирует «историческую» таблицу и поддерживает как родительские, так и исторические таблицы, одну для хранения фактических данных, а другую для исторических данных. Столбцы периода темпоральной таблицы SYSTEM_TIME (например, SysStartTime и SysEndTime) позволяют механизму запрашивать данные для другого временного интервала более эффективно. Обновленные или удаленные данные перемещаются в «историческую» таблицу, в то время как «родительская» таблица содержит последнюю версию строки для обновленных записей.

В чем подвох?

Наиболее важные соображения, условия и ограничения темпоральных таблиц:

Чтобы связать записи между темпоральной таблицей и таблицей истории, у вас должен быть первичный ключ в темпоральной таблице. Однако таблица истории не может иметь первичный ключ.
Тип данных datetime2 должен быть установлен для столбцов периода SYSTEM_TIME (например, SysStartTime и SysEndTime).
Когда вы создаете таблицу истории, вы всегда должны указывать и схему, и имя таблицы темпоральной таблицы в таблице истории.
Сжатие PAGE является настройкой по умолчанию для таблицы истории.
Темпоральные таблицы поддерживают типы данных BLOB-объектов (nvarchar (макс.), Varchar (макс.), Varbinary (макс.), Ntext, текст и изображение), которые могут влиять на стоимость хранения и иметь проблемы с производительностью.
Темпоральные и хронологические таблицы должны быть созданы в одной базе данных. Вы не можете использовать связанный сервер для предоставления темпоральных таблиц.
Вы не можете использовать ограничения, первичный ключ, внешние ключи или ограничения столбцов для таблиц истории.
Вы не можете ссылаться на временные таблицы в индексированных представлениях, в которых есть запросы, использующие предложение FOR SYSTEM_TIME
На столбцы периода SYSTEM_TIME нельзя напрямую ссылаться в инструкциях INSERT и UPDATE.
Вы не можете использовать TRUNCATE TABLE, когда SYSTEM_VERSIONING включен.
Вы не можете напрямую изменять данные в таблице истории.

Создание темпоральной таблицы

Мы показали, как создавать темпоральные и хронологические таблицы в одном сценарии DDL в листинге 1. Как мы упоминали ранее, столбцы SysStartTime и SysEndTime с типом данных datetime2 для обоих столбцов требуются для временной таблицы. Столбец SysStartTime должен быть GENERATED ALWAYS AS ROW START NOT NULL, а SysEndTime должен быть GENERATED ALWAYS AS ROW END NOT NULL. Вы не обязаны указывать значения по умолчанию для этих столбцов, но мы бы порекомендовали это. И столбцы SysStartTime, и SysEndTime должны быть указаны в столбце PERIOD FOR SYSTEM_TIME (как MSDN определил PERIOD, в других публикациях условие вызовов PERIOD).

Примечание. Системные версии столбцов не обязательно должны называться как SysStartTime и SysEndTime, но имена столбцов следует выбирать так, чтобы они отражали функцию захвата времени. Параметры GENERATED ALWAYS AS ROW START/END и PERIOD FOR SYSTEM_TIME (nameFrom, nameTo), включают функцию темпоральной таблицы.

CREATE TABLE Department

DeptID INT NOT NULL PRIMARY KEY CLUSTERED,

DeptName VARCHAR(50) NOT NULL,

ManagerID INT NULL,

ParentDeptID INT NULL,

SysStartTime DATETIME2 GENERATED ALWAYS AS ROW START

CONSTRAINT DF_Department_SysStartTime DEFAULT SYSUTCDATETIME() NOT NULL,

SysEndTime DATETIME2 GENERATED ALWAYS AS ROW END

DEFAULT CONVERT( DATETIME2, ‘9999-12-31 23:59:59’ ) NOT NULL,

PERIOD FOR SYSTEM_TIME(SysStartTime, SysEndTime)

WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.DepartmentHistory));

Листинг 1: Создание темпоральных и исторических таблиц

После создания темпоральной таблицы подчеркнутая таблица истории создается автоматически (рисунок 1), а для истории будет создан CLUSTERED INDEX с обоими столбцами SysStartTime и SysEndTime (или именем, выбранным для определения версии системы). таблица, листинг 2.

CREATE CLUSTERED INDEX ix_DepartmentHistory

Листинг 2: Создание кластерного индекса

Если новый столбец должен быть добавлен в темпоральную таблицу, то необходимо разрешить ALTER TABLE… ADD столбец DDL, и новый столбец будет автоматически отражен в таблице истории.

Рисунок 1: Отображение вновь созданных временных и исторических таблиц в Object Explorer.

Однако невозможно использовать DROP TABLE DDL для темпоральной таблицы. Во-первых, SYSTEM_VERSIONING должен быть выключен.

ALTER TABLE Department SET (SYSTEM_VERSIONING = OFF);

Листинг 3: Отключение SYSTEM_VERSIONING для таблицы Department.

Когда для SYSTEM_VERSIONING установлено значение OFF, временные и хронологические таблицы становятся обычными таблицами. Команда DROP TABLE может затем использоваться для этих таблиц.

CREATE TABLE Department_Exist (

DeptID int NOT NULL PRIMARY KEY CLUSTERED

, DeptName varchar(50) NOT NULL

, ManagerID INT NULL

, ParentDeptID int NULL )

Листинг 4: Создание таблицы Department_Exist.

ALTER TABLE dbo.Department_Exist

ADD SysStartTime datetime2 GENERATED ALWAYS AS ROW START

CONSTRAINT DF_Department_Exist_SysStartTime DEFAULT SYSUTCDATETIME() NOT NULL,

SysEndTime datetime2 GENERATED ALWAYS AS ROW END

CONSTRAINT DF_Department_Exist_SysEndTime DEFAULT CONVERT (DATETIME2, ‘9999-12-31 23:59:59’) NOT NULL,

PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)

ALTER TABLE dbo.Department_Exist

SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.Department_ExistHistory))

Листинг 5: Добавление системных версий столбцов и включение системных версий в таблице Department_Exist.

Существующая таблица Преобразованная в темпоральную таблица

Рисунок 2: Сравнение параллельного Department_Exist после преобразования я в темпоральную таблицу

Проверьте метаданные темпоральных таблиц:

— List temporal tables, temporal_type = 2

SELECT tables.object_id, temporal_type, temporal_type_desc, history_table_id,

WHERE temporal_type = 2 — SYSTEM_VERSIONED_TEMPORAL_TABLE

— List temporal tables and history tables

SELECT h.name temporal_name, h.temporal_type_desc, h.temporal_type,

t.name AS history_table_name, t.temporal_type, t.temporal_type_desc

FROM sys.tables t

JOIN sys.tables h

ON t.object_id = h.history_table_id

Преобразование оптимизированной в памяти таблицы OLTP в таблицу с системным управлением версиями

Хотя процесс преобразования оптимизированной в памяти таблицы OLTP в таблицу с системным управлением версиями аналогичен, есть некоторые различия, которые мы должны рассмотреть и продемонстрировать в этом разделе.

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

Оптимизированные в памяти таблицы должны быть долговечными (DURABILITY = SCHEMA_AND_DATA).
Оптимизированная таблица истории в памяти создается на основе дисков.
Запросы, которые влияют только на родительскую таблицу, могут использоваться в компиляционных модулях T-SQL. Вы не можете использовать временные запросы, используя предложение FOR SYSTEM TIME в изначально скомпилированных модулях, но можно использовать предложение FOR SYSTEM TIME с оптимизированными в памяти таблицами в специальных запросах и не собственных модулях.
Внутренняя оптимизированная промежуточная таблица в памяти создается автоматически, чтобы принимать самые последние изменения (INSERT, DELETE) при изменениях в оптимизированной родительской таблице в памяти, когда SYSTEM_VERSIONING = ON.
Данные из внутренней промежуточной таблицы, оптимизированной для памяти, регулярно перемещаются в таблицу хронологии на основе диска с помощью задачи асинхронной очистки данных. Этот механизм очистки данных имеет целью сохранить на внутренних буферах памяти менее 10% потребления памяти их родительскими объектами. DMV sys.dm_db_xtp_memory_consumers поможет отследить общее потребление памяти.
Сброс данных может быть вызван путем вызова хранимой процедуры sys.sp_xtp_flush_temporal_history @schema_name, @object_name.
Когда SYSTEM_VERSIONING = OFF или когда схема таблицы версии системы изменяется путем добавления, удаления или изменения столбцов, все содержимое внутреннего промежуточного буфера перемещается в таблицу истории на основе диска.
Запрос исторических данных фактически выполняется на уровне изоляции SNAPSHOT и всегда возвращает объединение между промежуточным буфером в памяти и таблицей на диске без дубликатов.
Операции ALTER TABLE, которые изменяют схему таблицы внутри, должны выполнять сброс данных, что может замедлить операцию.

Создание нового оптимизированного в памяти OLTP с включенной опцией System-Versioned Table

DDL для создания новой оптимизированной в памяти таблицы с параметрами темпоральной таблицы очень близок по своему синтаксису к традиционной дисковой таблице. Синтаксис оптимизированной таблицы в памяти имеет блок WITH для первоначальной установки свойств MEMORY_OPTIMIZED и DURABILITY. Поэтому необходимо добавить свойство SYSTEM_VERSIONING через запятую, как показано в листинге 7.

CREATE TABLE dbo.InMemory

UniqueName varchar(50) NOT NULL

PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 131072),

City varchar(32) NULL,

State_Province varchar(32) NULL,

LastModified datetime NOT NULL

, SysStartTime datetime2 GENERATED ALWAYS AS ROW START

CONSTRAINT DF_InMemory_SysStartTime DEFAULT GETDATE() NOT NULL

, SysEndTime datetime2 GENERATED ALWAYS AS ROW END

DEFAULT CONVERT (DATETIME2, ‘9999-12-31 23:59:59’) NOT NULL

, PERIOD FOR SYSTEM_TIME (SysStartTime,SysEndTime)

MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA,

SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.InMemory_History)

Листинг 7: Создание нового оптимизированного в памяти OLTP с включенной опцией System-Versioned Table

Добавление опции System-Versioned Table в существующую оптимизированную в памяти таблицу OLTP.

Как показано в листинге 8, сложнее преобразовать существующую оптимизированную в памяти OLTP-таблицу в таблицу с системным управлением версиями.

Чтобы продемонстрировать этот механизм, давайте создадим таблицу:

CREATE TABLE dbo.InMemoryExist

UniqueName varchar(50) NOT NULL

PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT = 131072),

City varchar(32) NULL,

State_Province varchar(32) NULL

MEMORY_OPTIMIZED = ON , DURABILITY = SCHEMA_AND_DATA

Листинг 8: Создание новой оптимизированной в памяти таблицы OLTP

Когда таблица создана, нам нужно добавить параметры темпоральной таблицы, прежде чем какие-либо данные будут добавлены в таблицу, как показано в листинге 9:

ALTER TABLE dbo.InMemoryExist

ADD SysStartTime datetime2 GENERATED ALWAYS AS ROW START

CONSTRAINT DF_InMemoryExist_SysStartTime DEFAULT SYSUTCDATETIME() NOT NULL,

SysEndTime datetime2 GENERATED ALWAYS AS ROW END

CONSTRAINT DF_InMemoryExist_SysEndTime DEFAULT CONVERT (DATETIME2, ‘9999-12-31 23:59:59’) NOT NULL,

PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)

ALTER TABLE dbo.InMemoryExist

SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.InMemoryExist_History))

Листинг 9: Добавление параметров темпоральной таблицы

Если таблица уже содержит данные, то процесс преобразования таблицы в таблицу с системным управлением версиями является более сложным.

Если InMemoryExist был создан с опцией системного управления версиями, нам нужно удалить таблицы InMemoryExist и InMemoryExist_History:

ALTER TABLE InMemoryExist set (SYSTEM_VERSIONING = OFF)

DROP TABLE InMemoryExist

DROP TABLE InMemoryExist_History

Мы воссоздаем таблицу (используйте пример кода, приведенный в листинге 8, приведенном выше в этом разделе). Затем мы вставляем данные в таблицу InMemoryExist:

select NEWID(),name, type_desc from sys.objects where is_ms_shipped = 0

При запуске кода, чтобы добавить временные параметры таблицы, листинг 9, будут отброшены следующие ошибки:

Msg 13575, Level 16, State 0, Line 21

ADD PERIOD FOR SYSTEM_TIME failed because table ‘database.dbo.InMemoryExist’ contains records where end of period is not equal to MAX datetime.

Msg 13510, Level 16, State 1, Line 29

Невозможно установить для SYSTEM_VERSIONING значение ON, если период SYSTEM_TIME не определен.

Чтобы избежать этих ошибок, нам нужно добавить опции контроля версий системы в более подробных шагах:

—Step 1. Adding nullable the columns

ALTER TABLE dbo.InMemoryExist ADD SysStartTime datetime2 NULL

ALTER TABLE dbo.InMemoryExist ADD SysEndTime datetime2 NULL

—Step 2 Adding the default constraints

ALTER TABLE InMemoryExist ADD CONSTRAINT DF_InMemoryExist_SysStartTime DEFAULT GETDATE() FOR SysStartTime;

ALTER TABLE InMemoryExist ADD CONSTRAINT DF_InMemoryExist_SysEndTime DEFAULT CAST(‘9999-12-31 23:59:59.9999999’ AS DATETIME2) FOR SysEndTime;

—Step 3 Updating the column

SET SysStartTime = ‘19000101 00:00:00.0000000’

,SysEndTime = ‘99991231 23:59:59.9999999’

—Step 4 Setting NOT NULL to the columns

ALTER TABLE dbo.InMemoryExist ALTER COLUMN SysStartTime datetime2 NOT NULL

ALTER TABLE dbo.InMemoryExist ALTER COLUMN SysEndTime datetime2 NOT NULL

—Step 5 Adding PERIOD FOR SYSTEM_TIME option

ALTER TABLE InMemoryExist ADD PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime)

—Step 6 Setting SYSTEM_VERSIONING property

ALTER TABLE InMemoryExist

SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.InMemoryExist_History))

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

Указание свойства DATA_CONSISTENCY_CHECK

Вы должны установить SYSTEM_VERSIONING с DATA_CONSISTENCY_CHECK = ON, чтобы обеспечить проверку целостности данных для существующих данных. Однако свойство DATA_CONSISTENCY_CHECK в настоящее время имеет профиль утечки памяти при использовании. Если вы решили включить DATA_CONSISTENCY_CHECK для временных таблиц, убедитесь, что в вашем экземпляре установлено накопительное обновление 1 для SQL Server 2016.

Вот пример включения свойства DATA_CONSISTENCY_CHECK в существующих таблицах:

ALTER TABLE InMemoryExist

SET (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.TableName_History, DATA_CONSISTENCY_CHECK = ON))

For a new table, DATA_CONSISTENCY_CHECK property enables after HISTORY_TABLE property separated by a comma.

WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE = dbo.DepartmentHistory, DATA_CONSISTENCY_CHECK = ON));

Заключение

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

История и актуальные проблемы темпоральных баз данных Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Костенко Б. Б., Кузнецов С. Д.

Целью данной статьи является обеспечение знакомства с темпоральными базами данных, текущим состоянием разработок, а также актуальными задачами и дальнейшими путями развития данного направления. Хочется подчеркнуть важность исследований в данной области, поскольку почти все данные, так или иначе, связаны с различными событиями, интервалами времени. Однако лишь незначительная часть разработчиков осознает, что это отдельная и вполне самостоятельная область исследований. Зачастую многие темпоральные системы создаются лишь на основе общих методов проектирования и разработки приложений баз данных, без использования накопленных знаний в области создания систем управления темпоральными базами данных. Подобное «изобретение велосипеда» не только повышает стоимость разработки, но и может самым негативным образом сказаться на эффективности работы приложений и наличии в них ошибок.

i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «История и актуальные проблемы темпоральных баз данных»

История и актуальные проблемы темпоральных баз данных

Б.Б. Костенко, С.Д. Кузнецов

Целью данной статьи является обеспечение знакомства с темпоральными1 базами данных, текущим состоянием разработок, а также актуальными задачами и дальнейшими путями развития данного направления2. Хочется подчеркнуть важность исследований в данной области, поскольку почти все данные, так или иначе, связаны с различными событиями, интервалами времени. Однако лишь незначительная часть разработчиков осознает, что это отдельная и вполне самостоятельная область исследований. Зачастую многие темпоральные системы создаются лишь на основе общих методов проектирования и разработки приложений баз данных, без использования накопленных знаний в области создания систем управления темпоральными базами данных. Подобное «изобретение велосипеда» не только повышает стоимость разработки, но и может самым негативным образом сказаться на эффективности работы приложений и наличии в них ошибок.

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

1 В русскоязычной литературе вместо термина «темпоральные базы данных» иногда применяется термин «временные базы данных». Но поскольку, во-первых, в этой области отсутствует устоявшаяся русскоязычная терминология и, во-вторых, при использовании первого термина, являющегося калькой английского термина temporal database, не требуется дополнительное уточнение ударения, в этой статье будет использоваться именно этот термин.

2 За исключением специально оговоренных случаев в этой статье речь будет идти о реляционной модели данных (и ее темпоральных расширениях). Кроме того, здесь не проводится различия между реляционной моделью данных в классическом смысле и моделью данных языка SQL, и используются термины, принятые в мире SQL-ориентированных баз данных.

зависимость от времени, так как когда-то нам (или системе) стало известно, что такая аксиома существует. Кроме того, есть вероятность, что в будущем аксиома будет опровергнута, или на условия ее применимости будут наложены определенные ограничения; поэтому нельзя уже будет рассматривать ее как некоторую абсолютную истину, верную во всех ситуациях и в любой момент времени3.

Темпоральные базы данных — это базы данных, хранящие темпоральные данные. Однако эти базы данных и содержащиеся в них данные могут рассматриваться как темпоральные только в том случае, если известно правило интерпретации временных меток и интервалов для конкретной системы управления базами данных (СУБД). Чтобы определить, является ли рассматриваемая СУБД темпоральной в полном смысле этого слова, необходимо понять, можно ли отдельно выделить и специальным образом интерпретировать данные атрибута «время». В категорию темпоральных СУБД не будут попадать обычные реляционные СУБД, в которых поддерживаются связанные со временем типы данных, но интерпретацией и связью данных (или событий) между собой с учетом времени приходится заниматься разработчику. В «настоящей» темпоральной СУБД учитываются специфическая природа времени и изменчивость данных с течением времени.

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

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

3 Если пойти еще дальше, то можно даже сказать, что результаты любых вычислений, по сути, тоже являются темпоральными данными, так как связаны со временем. Например, представим, что определенное решение принимается на основе целочисленного округления значения некоторого вещественного выражения. Если система некоторое время округляет 0.5 до 0, а потом — до 1, то мы можем получить разные результаты на одних и тех же исходных данных, то есть Б(С) Ф Р(С), где С — константа. Для формально корректной записи подобного неравенства требуется введение дополнительного аргумента — момента вычисления, и тогда получится абсолютно корректное выражение Б(С, ^) Ф Б(С, (г). Данный пример может показаться несколько искусственным, но он демонстрирует, что время является неотъемлемым атрибутом любых данных, когда речь идет о практической работе с конкретной системой, а не лишь о теоретическом ее исследовании.

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

2. Краткая история

История систем реляционных баз данных насчитывает более трех десятилетий. Примерно на 10 лет позже появились идеи реализации систем управления темпоральными базами данных, до сих пор не воплощенные полностью ни в одной реализации крупных коммерческих СУБД4. Принято считать, что впервые идеи управления темпоральными данными появились в работе Якова Бен-Зви (Jacob Ben-Zvi) в 1982 г. [BZ82], но эта работа не получила широкой известности, хотя и предвосхитила многие последующие исследования в области темпоральных баз данных. Позже, в 80-е гг. начали появляться работы по темпоральной логике и использованию данных, зависимых от времени, их представлению внутри системы и визуализации для пользователя. С тех пор предлагались различные модели, создавались прототипы систем темпоральных баз данных ([Böh95]).

Одним из ключевых периодов в области исследований темпоральных баз данных, временем ее «официального» представления можно считать 1992-1993 гг. В это время сначала Ричард Снодграс (Richard Snodgrass) высказал идею о возможном темпоральном расширении стандарта языка запросов к реляционным базам данных SQL-92, а затем был проведен семинар «ARPA/NSF International Workshop on an Infrastructure for Temporal Databases», продемонстрировавший заинтересованность научного сообщества в создании и использовании темпорального расширения стандарта языка запросов к базе данных ([AJS95]). После этого семинара была образована комиссия по созданию спецификации подобного языка, в которую вошли Ричард Снодграс, Илсу Ан (Ilsoo Ahn), Гэд Ариав (Gad Ariav), Дон Бэтори (Don Batory), Джеймс Клиффорд (James Clifford), Картис Дайрсон (Curtis E. Dyreson), Кристиан Йенсен (Christian S. Jensen), Рамес Элмасри (Ramez Elmasri), Фабио Гранди (Fabio Grandi), Вольфганг Кафер (Wolfgang Kaefer), Ник Клайн (Nick Kline), Кришна Кулкарни (Krishna Kulkami), Тинг Клифф Леунг (Ting Y. Cliff Leung), Никое Лоренцос (Nikos Lorentzos), Джон Роддик (John F. Roddick), Эрай Серев (Arie Segev), Майкл Су (Michael D. Soo) и Суринараяна Срипада (Surynarayana

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

M. Sripada). После нескольких лет плодотворной работы в начале 1994 года появилась первая предварительная версия спецификации языка, а на основе полученных замечаний в сентябре того же года была выпущена окончательная спецификация языка запросов TSQL2 [SAAB95],

Одновременно со спецификацией языка запросов TSQL2 были распространены комментарии [SAAB95], в которых объяснялись решения, принятые в ходе подготовки языка запросов, а также предоставлялись примеры, и рассматривались возможные пути реализации данного языка на основе существующих СУБД. Позднее эти комментарии, которые, по сути, не являлись частью спецификации языка, стали использоваться для сравнения TSQL2 с другими предлагаемыми темпоральными моделями и языками запросов к ним.

2.1. Принятие стандарта и коммерческие реализации

Представленная спецификация языка TSQL2 позволяла делать оптимистичные прогнозы относительно возможности расширения спецификации языка SQL-92 новыми конструкциями и одновременной интеграции темпоральной модели в реляционную модель данных. Разные члены сообщества исследователей темпоральных баз данных работали над переносом конструкций и логики языка TSQL2 в язык SQL3 (позднее названный SQL: 1999). Первым шагом стало добавление в 1995 году проекта седьмой части спецификации языка SQL3, названной SQL/Temporal. В 1996 году два предложения [SBJ96a] и [SBJ96b] (а также их дополнения [Sno96] и [Sno97]), описывающие добавление действительного, или модельного (valid) и транзакционного (transaction)5 времен к стандарту SQL-92, были единодушно поддержаны в ANSI и переданы в ISO. В это же время Андреас Стейнер (Andreas Steiner) и Михаель Бехлен (Michael H. Böhlen) создали прототип TimeDB, поддерживающий возможность работать и с действительным, и с транзакционным временами ([Tim07]). Система являлась прослойкой6 между интерфейсом пользователя и одной из коммерческих СУБД, обеспечивая поддержку темпоральных конструкций путем их преобразования в обычные реляционные структуры и обратно. Позднее разработчики пытались позиционировать TimeDB как коммерческий проект, но, по-видимому, не достигли в этом успехов.

Многие исследователи были убеждены, что окончательное принятие стандарта и появление расширений для поддержки темпоральных баз данных в развитых коммерческих СУБД должны были произойти уже в самом начале XXI века. Однако седьмая часть стандарта так и осталась на бумаге. Более того, несколько лет назад работы над стандартом SQL/Temporal были вообще

5 Эти и другие термины будут более подробно рассмотрены и разъяснены в разд. 4.

6 Подробнее об этом см. разд. 7.

прекращены (или приостановлены на неопределенный срок) [Jcc07], Производители СУБД также не добавили в свои продукты полноценную темпоральную поддержку. Кристофер Дейт (С. J. Date) в [DDL02] считает целесообразным введение курса по работе с темпоральными данными в рамках программы подготовки специалистов (и сам читает подобный курс в одном из университетов), но соглашается, что для производителей сейчас более актуальными являются другие задачи, связанные, например, с расширением функциональности для поддержки электронного бизнеса и т.п. Однако стоит отметить, что некоторые производители коммерческих СУБД уже обращают внимание на проблему поддержки работы с темпоральными данными в своих системах, предоставляя определенные дополнительные возможности как для администраторов, так и для пользователей. Но из-за отсутствия стандарта нет ни единого подхода, ни одинаковой поддерживаемой функциональности. Более того, системы в явном виде не позиционируются как поддерживающие работу с темпоральными данными, поэтому невозможно говорить даже о наличии стандарта de facto.

Между тем, начиная уже с 2000 года, часть исследователей темпоральных баз данных обратила внимание на XML-данные, для которых стандарт языка запросов еще только вырабатывался. Необходимость разработки новых интерпретаторов запросов и гибкость структур языка давали некоторым разработчикам надежду на реализацию темпоральной XML-СУБД. Однако текущая ситуация напоминает ту, которая сложилась в области реляционных баз данных: предложено несколько моделей и созданы прототипы, но все это осталось пока лишь иллюстрацией или инструментом для решения конкретной проблемы и не может претендовать на то, что со временем будет стандартизовано7.

3. Появление области исследований темпоральных баз данных

В предыдущем разделе была представлена краткая история появления и развития области исследований темпоральных баз данных. Далее будут даны определения основных понятий, описаны наиболее важные проблемы, с которыми сталкивались и сталкиваются разработчики при создании темпоральных баз данных. Но вначале кратко ответим на один из основных вопросов, почему же возникла потребность в расширении стандарта языка SQL, и почему возникла подобная область исследований?

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

7 Здесь речь идет об общем стандарте, а не какой-нибудь специальной функциональности для определенной прикладной области.

понимают, что в языке запросов SQL отсутствует адекватная и эффективная поддержка работы с темпоральными базами данных. Традиционная реляционная база данных хранит информацию лишь о текущем состоянии, и СУБД не предоставляет возможности работать с данными, привязанными к определенным датам или интервалам времени (то есть темпоральными данными). Поэтому почти во всех базах данных поддержка работы с такими данными обеспечивается усилиями программистов и администраторов, которые используют для решения задач «неудобные» конструкции языка. При этом многие простые запросы, которые легко формулируются «вне времени», довольно тяжело переписать для «самодельной» темпоральной системы, и они получаются достаточно громоздкими, что чревато появлением ошибок.

4. Основные понятия

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

4.1. Линии времени

В повседневной жизни человек чаще всего не задумывается, что использует только одну линию времени. События могли уже произойти в прошлом или только планируются в будущем, но время всегда измеряется согласно одним часам. С другой стороны, в базе данных может сохраняться информация о событиях и интервалах времени, соответствующих различным представлениям и связям. Если обработкой подобных данных занимается сам пользователь, то используемый тип времени можно назвать временем, определяемым пользователем. Его отличительным признаком служит отсутствие интерпретации со стороны СУБД, так как обработка данных, связанных со временем, полностью возлагается на пользователя. Фактически, все современные СУБД обеспечивают поддержку подобной разновидности времени, например, с помощью введения специальных типов данных DATA или TIMESTAMP.

Если рассматривать данные, представленные в базе данных, как некоторое отражение текущего состояния действительности для моделируемого мира, то каждая запись может восприниматься как некоторый факт, который является истинным в определенный момент или интервал времени. При переходе к темпоральной базе данных для каждого факта можно указать тот промежуток времени8, когда этот факт являлся истинным в моделируемом мире, представленном в базе данных. Подобное представление времени, когда с

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

данными связывается промежуток времени их актуальности (с точки зрения моделируемого мира), называется модельным, или действительным (valid) временем. Его значения можно сравнить с показаниями часов моделируемого мира. Поскольку довольно часто в базе данных отражается именно реальный мир, могут быть заданы соотношения между значениями времени реального мира и представленной в базе данных моделью. Отметим, что значениями данного типа времени могут быть моменты времени как в прошлом, так и в будущем. Кроме того, эти значения могут изменяться, то есть истинность факта в определенные моменты времени может приниматься или отклоняться. Другим типом линии времени, который рассматривается исследователями темпоральных баз данных, является транзакционное время. В любой СУБД каждой записи базы данных можно сопоставить тот промежуток времени, когда данная запись была представлена в базе данных, т.е. промежуток времени между моментами добавления записи и ее удаления из базы данных. При этом отметим, что операция обновления, которая действительно вносит изменения в запись, понимается как составная операция удаления старой записи и добавления новой. Очевидно, что значения транзакционного времени не могут относиться к будущему. В подавляющем числе СУБД транзакционное время используется для работы с блокировками, журналом для восстановления системы. В некоторых системах администраторы даже могут использовать специальные расширения языка SQL, позволяющие получить доступ к транзакционному времени и истории изменений записей в базе данных.

Рис. 1. Таблица без темпоральных расширений

сотрудник з/плата действительное время

ALAN 500 с 1 января 2006

ВОВ 300 с 1 марта 2005 по 31 января 2006

ВОВ 400 с 1 февраля 2006

Рис. 2. Таблица с поддержкой действительного времени

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

(рис. 1). При наличии поддержки действительного времени мы могли бы в любой момент сказать, какая у сотрудника была зарплата за произвольный период времени (рис. 2). Таким образом, данные о зарплате могут быть представлены как последовательность изменяющихся значений. При наличии поддержки транзакционного времени мы могли бы сказать, в какой момент в таблицу были внесены изменения9 (рис. 3).

табельный номер з/плата транзакционное время

ALAN 500 с 20 декабря 2005

ВОВ 300 с 3 марта 2005 по 27 января 2006

ВОВ 500 с 28 января 2006 по 5 февраля 2006

ВОВ 400 с 6 февраля 2006

Рис. 3. Таблица с поддержкой транзакционного времени

табельный номер з/плата действительное время транзакционное время

ALAN 500 с 1 января 2006 с 20 декабря 2005

ВОВ 300 с 1 марта 2005 по 31 января 2006 с 3 марта 2005 по 27 января 2006

ВОВ 500 с 1 февраля 2006 с 28 января 2006 по 5 февраля 2006

ВОВ 400 с 1 февраля 2006 с 6 февраля 2006

Рис. 4. Таблица с поддержкой обеих линий времени

Теперь предположим, что для таблицы поддерживается как действительное, так и транзакционное время (рис. 4). Тогда в случае, если неправильно введенные данные были впоследствии исправлены, можно будет точно сказать, когда это было сделано. Кроме того, информация о подобных изменениях необходима, так как некорректные данные могли бы быть уже

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

использованы в каких-нибудь отчетах. Поэтому в данном случае требуется поддержка транзакционного времени. При обновлении значений в системе (даже в случае исправления ошибки в данных) интервал транзакционного времени также обновляется, поэтому можно просмотреть список изменений в базе данных.

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

01.03.2005 03.03.2005 28.01.2006 01.02.2006 06.02.2006

Рис. 5. Связь линий времени для сотрудника ALAN

Исследователи темпоральных баз данных обычно используют один из данных типов времени или оба одновременно. В некоторых работах предлагаются и другие линии времени1″, хранение значений которых может быть интересно пользователю, но все они могут быть сведены к одному из рассмотренных типов, возможно, через дополнительные отношения.

Говоря о линиях времени, необходимо ввести еще один термин -гранулярность, которая показывает, насколько близкие моменты на оси времени все еще будут отличимыми друг от друга. Например, возможно, что для данных о заработной плате сотрудника достаточно разбиения по дням, но для транзакционного времени может быть недостаточно даже разбиения по секундам, если в СУБД возможна более частая фиксация транзакций.

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

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

соответствия и преобразования между моментами времени для различных осей времени.

4.2. Интервальное и точечное представления

В предыдущем подразделе при обсуждении действительного времени, говорилось, что существует некоторый интервал, в котором определенный факт являлся истинным. Это так называемое интервальное представление. Однако можно рассматривать отдельный момент времени и все факты, которые были истинны в этот конкретный момент (рис. 6).

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

АЦШ ВОВ АЦШ ВОВ

01.01.2006 100 100

28.02.2005 100 100

01.03.2005 100 300 100

02.03.2005 100 300 100

03.03.2005 100 300 100 300

100 300 100 300

|15.09.2005 100 300 100 300 I

100 300 100 300

27.01.2006 100 300 100 300

28.01.2006 100 300 100 500

100 300 100 500

31.01.2006 100 300 100 500

01.02.2006 100 400 100 500

100 400 100 500

05.02.2006 100 400 100 500

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

06.02.2006 100 400 100 400

100 400 100 400

| сейчас 100 400 100 400 |

Рис. 6. Точечное представление и срезы на линии времени

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

состояния данных. В ряде работ проводится сравнение этих подходов [Тот96], исследуются возможности их совместного использования и объединения [BBJ98], [TS01], а также анализируются способы эффективной реализации менее распространенных точечных подходов [Тот98].

5. Расширение реляционной модели и СУБД

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

5.1. Создание темпоральной СУБД

Исследователи темпоральных баз данных рассматривали несколько способов создания темпоральной СУБД. Вначале рассматривалась возможность создания темпоральных СУБД «с нуля», то есть самостоятельная реализация некоторой темпоральной модели. Однако реляционные СУБД быстро прогрессировали, расширялась их функциональность, поэтому создание «урезанной» темпоральной СУБД было нецелесообразным, а ресурсов и возможности повторной реализации всех средств реляционной СУБД (при создании темпоральной СУБД) просто не было.

Рис. 7. Общий вид многоуровневой архитектуры темпоральной СУБД

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

Отсутствовала и соответствующая потребность со стороны пользователей. Поэтому вскоре разработчики стали рассматривать различные способы дополнения и расширения обычных реляционных СУБД поддержкой темпоральной модели данных12. Почти все такие способы сводились к созданию некоторого функционального блока, отвечающего за разбор темпоральных запросов, подмену их некоторыми реляционными вычислениями, а потом обратное преобразование в требуемое темпоральное представление для возвращения результатов пользователю. Основным отличием был уровень «вмешательства» в реляционную СУБД, а также степень интеллектуальности данного блока темпоральных преобразований (рис. 7). Сравнение различных вариантов реализации промежу точного слоя представлено, например, в [Т1898].

Рассмотрим три крайних случая: преобразование на уровне ядра реляционной СУБД, преобразование на уровне пользовательского приложения и использование независимого промежуточного ргоху-уровня. Первый способ предоставляет максимум возможностей по расширению синтаксиса языка баз данных, обеспечению различных проверок, а также оптимизации. Он также обеспечивает полную прозрачность для всех пользовательских приложений, а возможно, и для администратора БД. Однако он доступен только разработчикам СУБД.

В отличие от простого использования приложением реляционной СУБД для работы с темпоральными данными второй способ предполагает выделение некоторых модулей или библиотеки (в пользовательском приложении), отвечающих за преобразование именно темпоральных запросов. То есть основное приложение использует некоторую темпоральную абстракцию, а не реляционную БД в чистом виде, а потом интерпретирует результаты запросов. Подобная абстракция (пусть и на уровне приложения) позволяет сократить число ошибок и отделить бизнес-логику приложения от технической составляющей хранения данных13. В [8по99] подробно описано, как можно создавать темпоральные приложения в рамках реляционной СУБД.

Третий способ подразумевает создание между пользовательским приложением и СУБД некоторого промежуточного «черного ящика» (будем называть его ргоху-уровнем), который может быть реализован в виде драйвера, сервиса, внешней библиотеки и т.п. Для пользовательского приложения этот рюху-уровень должен работать как темпоральная СУБД. С другой стороны, для СУБД этот рюху-уровень является обычным реляционным приложением. Поэтому рюху-уровень оказывается прозрачным как для пользовательского приложения, так и для СУБД, а также не требует

12 Фактически, именно этот факт приводит к «реляционности» большинства темпоральных моделей.

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

внесения изменений в их исходный код. Исходя из того, что между ргоху-уровнем и СУБД интенсивность обмена данными может оказаться на порядок выше, чем между ргоху-уровнем и приложением (с учетом различных дополнительных оптимизаций), предпочтительно размещать его как можно ближе к СУБД.

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

5.2. Язык запросов к темпоральной базе данных

Для работы с темпоральными базами данных необходимо было разработать язык запросов к ним, который должен был бы стать расширением языка запросов SQL к реляционным базам данных. Рассмотрение языка запросов начнем с конструкций выборки, предложенных авторами языка TSQL2 (SQL/Temporal).

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

14 Данное определение не противоречит определениям, приведенным ранее, но вполне конкретизирует пару «темпоральная база данных и соответствующая СУБД».

других таблиц — нет15. Поэтому далее будем рассматривать отдельную таблицу, на время забывая о возможных ее связях с другими таблицами.

При построении модели языка запросов к темпоральной базе данных ставились следующие цели. Во-первых, при переходе к темпоральной модели желательно расширить все три компонента модели данных: структуру данных, операции и ограничения целостности. Во-вторых, любая корректная конструкция в исходном языке запросов должна остаться корректной в новом языке, и семантика этих конструкций должна остаться прежней; например, результат, возвращаемый запросом, должен быть таким же. То есть необходимо обеспечить восходящую совместимость языка запросов и базы данных. Кроме того, желательно обеспечить темпоральную восходящую совместимость: необходимо, чтобы после добавления в систему темпоральной поддержки все унаследованные конструкции продолжали работать так же, как и раньше. Из этого следует, что все существующие приложения не должны почувствовать переход от обычной реляционной СУБД к темпоральной СУБД (|ВЕи+97|). Более того, последующее добавление темпоральной поддержки в какую-нибудь конкретную таблицу не должно отразиться на корректности выполнения запросов. С другой стороны, подобное добавление должно позволить использовать темпоральные запросы в новых программах, заметно облегчая работу программистам и администраторам системы.

Рассмотрим таблицу, содержащую информацию о заработной плате сотрудников. До добавления темпоральной поддержки таблица содержала только актуальную информацию (на текущий момент времени)16. В таком случае у приложения имеется возможность узнать текущее значение любых элементов данных, но предыдущее значение будет потеряно после любого изменения. После удаления записи например вообще невозможно будет сказать, , сколько получал данный сотрудник перед увольнением. Такая ситуация существует при использовании традиционной реляционной модели (рис. 8). Предположим, что позже было принято решение о необходимости хранить историю значений заработной платы сотрудников. Решить это можно было бы несколькими путями. Во-первых, можно создать специальную таблицу с историей зарплаты, но это могло бы быть достаточно странным, так как уже есть таблица «заработных плат». Более того, пришлось бы модифицировать код приложения, чтобы при удалении и изменении значений происходило автоматическое обновление данных и во второй таблице.

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

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

Рис. 8. Работа с таблицей без темпоральной поддержки

Рис. 9. Работа реляционных приложений с темпоральной таблицей

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

новые темпоральные запросы, которые позволят узнать историю изменений (рис. 9).

Какие же запросы могут быть сформулированы к таблице с темпоральной поддержкой? Во-первых, это запрос значений на какой-нибудь момент времени в прошлом, то есть создание среза истинности фактов на произвольную дату. Например, для обычного реляционного запроса «какую зарплату сейчас получает каждый из сотрудников?» можно легко сформулировать его темпорального двойника «какую зарплату получал каждый из сотрудников в указанную дату?» В этом случае результат запроса останется в рамках реляционного представления. С другой стороны, вполне естественным оказывается запрос «когда и какую зарплату получал каждый из сотрудников?». Здесь уже в результатах запроса появляется линия времени. Один из традиционных способов представления подобных результатов опирается на интервальное действительное время, то есть к обычному реляционному представлению результатов добавляется еще один столбец, содержащий интервалы истинности фактов. Алгоритм формирования результатов подобных запросов можно упрощенно представить следующим образом: для каждого момента времени17 вычисляется реляционный подзапрос «какую зарплату получает каждый из сотрудников», после чего к общему результату добавляются результаты этих подзапросов с учетом интервалов истинности. Подобная семантика «последовательной» интерпретации реляционных запросов называется последовательной (sequenced valid semantics), см. рис. 10.

Однако на основе этой семантики невозможно сформировать запрос, который требует «сравнения» нескольких последовательных моментов времени. К таким запросам относится большинство запросов, включающих агрегационные функции «во времени», например, «вывести среднюю заработную плату сотрудника за все периоды времени» (отметим, что результат будет представлен обычной реляционной таблицей) или «вывести периоды, когда на оплату труда сотрудников уходила максимальная сумма». Предусмотреть все подобные типы запросов невозможно, и также нельзя ограничивать выразительные возможности языка, поэтому была предложена конструкция запросов произвольного доступа к темпоральным данным (Non-Sequenced Queries), которые предоставляют возможность самостоятельно сформулировать необходимый запрос, накладывая ограничения на системный темпоральный столбец18. См. рис. 11.

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

18 Фактически, система позволяет только формулировать ограничения и отношения меяеду интервалами и отдельными моментами времени, а все остальное отдается на откуп пользователю.

Рис. 10. Обработка «последовательных» запросов к темпоральной таблице

Рис. 11. Обработка «произвольных» запросов к темпоральной таблице

Таким образом, при наличии темпоральной поддержки в системе можно выделить четыре уровня использования запросов (для конкретной таблицы): 1

— темпоральная поддержка для таблицы отсутствует, 2 — использование реляционных запросов к таблице с темпоральной поддержкой, 3 -использование последовательных запросов и 4 — использование произвольных темпоральных запросов. Подобная классификация верна как для таблиц с поддержкой действительного времени, так и для тех, для которых поддерживается транзакционное время. Поскольку эти линии времени являются ортогональными и независимыми, в системе с темпоральной

поддержкой получается шестнадцать вариантов использования запросов на выборку.

На основе запросов на выборку можно формулировать темпоральные ограничения целостности, которые будут проверяться при операциях обновления базы данных. Для операций модификации и удаления записей можно накладывать аналогичные ограничения в их разделах WHERE. С другой стороны, обработка запросов на обновление для транзакционного и действительного времени будет принципиально отличаться. Например, в разделе SET невозможно задавать системные поля транзакционного времени. Поэтому полностью корректная реализация поддержки транзакционного времени возможна только при реализации темпоральных операций внутри ядра СУБД.

5.3. Представление результатов темпоральных запросов

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

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

19 Точечное представление может быть более удобно при ограниченности (и дискретности) возвращаемых моментов времени и их последующем использовании при программной обработке.

время промежуточных вычислений. Фактически, перед каждой операцией над темпоральными данными можно выполнять распаковку, а потом — упаковку.

5.4. Специальное значение «сейчас»

Слово «сейчас» означает «в настоящее время, в данный момент». В запросах на языке SQL довольно часто используются конструкции CURRENTTIMESTAMP, CURRENTDATE и CURRENT TIME, которые заменяются соответствующими константами в момент выполнения запросов, поэтому в самой базе данных хранятся лишь конкретные значения дат и времени. Так как язык запросов к темпоральной базе данных является расширением языка SQL, данные конструкции в нем также могут использоваться как синонимы «динамических» констант. Однако для работы с фактами, которые истинны в настоящий момент, но могут меняться с течением времени, необходимо использовать дополнительное специальное значение СЕЙЧАС. Оно используется при задании верхней границы интервала истинности факта, хранимого в таблице с темпоральной поддержкой ([CDI+97]).

Пусть в базе данных хранится информация о периоде работы сотрудника в компании. Тогда до 2 апреля для сотрудника, пришедшего на работу 1 апреля, промежутком времени его работы в компании является один день 1 апреля. На следующий день промежуток его работы в компании изменится на интервал с 1 по 2 апреля. Через день интервал примет вид 1-3 апреля и так далее. Одним из путей решения подобной проблемы могло бы быть ежедневное обновление базы данных, изменяющее верхнюю границу интервала на корректное значение, но это нереальный вариант. Поэтому при выполнении запросов можно использовать подобную динамическую подстановку20. Для этого можно хранить динамическую константу СЕЙЧАС, обозначающую зависимость факта от текущего времени. В приведенном примере это бы означало, что человек работает в компании с 1 апреля по СЕЙЧАС.

В качестве представления СЕЙЧАС можно использовать одно из значений домена TIMESTAMP или пустое значение NULL. При выборе значения для представления СЕЙЧАС необходимо гарантировать, чтобы это значение не использовалось с каким-либо иным смыслом. Фактически, требуется сделать выбор из значения NULL и максимального или минимального значения типа TIMESTAMP. При использовании СЕЙЧАС в запросах необходимо принимать во внимание, что его следует заменять текущим временем на этапе выполнения. При работе над системой TimeDB [TIM07] исследовалась производительность системы для различных вариантов представлений. Было продемонстрировано, что представление СЕЙЧАС с помощью минимального

20 Если подстановка для CURRENT_TIMESTAMP, СиМ1ЕОТ_ВАТЕ и СиР1ШЫТ_Т1МЕ выполняется для данных запроса, то здесь подстановка выполняется для информации, хранимой в базе данных.

значения типа TIMESTAMP всегда самое медленное. Представление в виде NULL было наиболее эффективным при большем проценте пересечений с текущим временем. Однако представление в виде NULL-значения всегда приводило к максимальному количеству чтений диска. На основе этого анализа был сделан выбор в пользу максимального значения типа TIMESTAMP.

Использование некоторого специального значения СЕЙЧАС не является единственно возможным решением. Например, можно разделить все факты на два класса, в одном из которых хранятся факты, для которых интервал уже точно известен, а в другом — те, у которых верхняя граница еще не известна. Если хранить эти факты в разных таблицах, то не потребуется вводить специальное значение СЕЙЧАС, однако несколько усложнится выборка, а таблицы с поддержкой и транзакционного, и действительного времени придется разбивать на четыре подтаблицы.

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

5.5. Разрежение таблиц с темпоральной поддержкой

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

Поэтому фундаментальным требованием является возможность контролирования физического удаления данных, что приводит к операции, которая называется разрежением (vacuuming) таблиц с темпоральной поддержкой. Для обеспечения корректности выполнения разрежения необходимо иметь возможность указывать в запросе данные, которые должны

быть удалены, и те, которые должны быть оставлены. Очевидно, что все «активные» строки должны остаться в таблице при любом ее разрежении. В простейшем случае отбрасываются все те кортежи, которые были удалены21 до определенного момента времени — происходит срез истории.

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

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

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

21 В терминах транзакционного времени.

5.6. Проектирование темпоральных баз данных

В настоящее время существуют проверенные методы и инструментарий, используемые при проектировании реляционных баз данных. При работе с темпоральными базами данных необходимо учитывать темпоральную специфику и использовать соответствующие средства. Рассмотрим простой вопрос: сколько в базе данных должно быть таблиц с темпоральной поддержкой? Если для действительного времени ответ на данный вопрос достаточно прост (количество таблиц определяется потребностью приложений), то при наличии транзакционного времени он становится нетривиальным, так как от ответа от него зависит объем накапливаемой истории. При этом не всегда требуется именно поддержка транзакционного времени, а вполне может подойти и простой журнал, реализованный вне базы данных. При проектировании таблиц с поддержкой действительного времени можно использовать обычные инструменты, дополняя таблицы интервалами (парой значений) времени, однако в этом случае количество связей между таблицами заметно увеличивается. Более того, невозможно корректно описать работу со специальным значением СЕЙЧАС. При проектировании темпоральной базы данных следует также помнить, что все «обычные» реляционные ключи таблиц будут неявно расширяться верхней границей интервала транзакционного и/или действительного времени. Ограничения целостности также должны формулироваться с учетом этих обстоятельств ШТ95]).

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

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

темпоральной поддержки. Принудительное добавление темпоральной

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

5.7. АСЮ-свойства темпоральных транзакций

Основными свойствами традиционных транзакций, поддерживаемыми в реляционных СУБД, являются АСГО (атомарность, целостность,

изолированность и продолжительность). При создании темпоральной СУБД чрезвычайно важно перенести подобные свойства и на темпоральные транзакции. АСШ-свойства темпоральных 8()Ь-транэакций могут быть

сохранены за счет отображения каждой темпоральной транзакции в одиночную реляционную 8С)Ь транзакцию. Альтернативные реализации темпоральных транзакций, при которых рюху-уровень отображает темпоральную 8 О Ь -т ра н ■ >, а к ц и ю в несколько обычных 8 () Ь-тр а н за к ц и й. могут привести к неразрешимым проблемам, если во время выполнения получится так, что одна из реляционных 8()Ь-транэакций будет зафиксирована, а вторая

— нет, что должно означать неудачу всей темпоральной 8 () Ь-тр а н за к ц и и. а не отдельной ее части. Выполнить же откат транзакции, зафиксированной в базе данных, может оказаться просто невозможно, так как изменения уже могут быть использованы параллельно работающими транзакциями. Поэтому для поддержки параллельно работающих темпоральных транзакций необходимо реализовывать их в виде одиночных 8 О Ь -т ра н ■ >, а к ц и й. иначе не удастся обеспечить поддержку АСШ-свойств22.

Кроме этого, недостаточно требовать только то, чтобы каждая темпоральная 8С)Ь транзакция отображалась в одну 8()Ь-транэакцию. Для каждой транзакции необходимо обеспечить, чтобы в ее пределах транзакционное время было константно, но тогда встает вопрос, как его выбирать, ведь условия на специальное значение СЕЙЧАС должны проверяться с тем же значением константы. Здесь возможны два основных варианта: транзакционное время выбирается в самом начале или в самом конце выполнения транзакции. Первый вариант является некорректным, так как параллельная транзакция может внести изменения в таблицы, которые еще только понадобятся данной транзакции. Поэтому наиболее удачным выбором является момент времени непосредственно перед фиксацией транзакции, после того, как получены блокировки на все затрагиваемые объекты. Но и здесь возможны проблемы, если транзакция получит одно значение транзакционного времени, а будет зафиксирована чуть позже, так что между этими двумя моментами будет благополучно выполнена некорректная выборка. Подобная проблема может возникнуть и при параллельном выполнении двух различных транзакций.

Один из способов, который сможет гарантировать корректную поддержку АСШ-свойств темпоральных транзакций, состоит в реализации дополнительного механизма блокировок на рюху-уровне. Отметим, что восстановление базы данных, которое является важной частью работы СУБД, является прозрачным для конечного пользователя. При использовании многоуровневой архитектуры для конечного пользователя промежуточный слой ничем не отличается от СУБД, поэтому при проектировании прослойки можно полностью положиться на механизмы восстановления, реализованные в СУБД. Также нет причин, по которым они стали бы работать быстрее или медленнее.

22 Если, конечно, не реализовывать на рюху-уровне собственный механизм управления транзакциями над механизмом управления транзакциями базовой СУБД.

5.8. Эффективность при работе с темпоральной СУБД

Одним из наиболее важных вопросов при использовании баз данных является эффективность работы приложений с соответствующей СУБД. Для повышения скорости обработки запросов в реляционных СУБД традиционно применяются индексы для выборки данных из таблиц, а также статистики и различные эвристики при выборе алгоритма соединения данных из нескольких таблиц ([GJS+05]). При разработке темпоральных СУБД значительное внимание уделялось именно вопросам производительности, так как в общем случае небольшая доля «активных» данных из постоянно растущего объема информации в базе данных приводила к резкому спаду производительности при интенсивном использовании и/или недостаточном внимании при разработке приложения.

Наиболее очевидным, а также доступным способом оптимизации темпоральных приложений является использование индексов. Например, при добавлении дополнительных специальных столбцов для интервалов транзакционного времени необходимо включить верхний предел во все уникальные индексы. С другой стороны, необходимость постоянно разделять данные на «активные» и «устаревшие» требует их разделения на ранней стадии обработки, что также может быть обеспечено с помощью индексов. Аналогичная ситуация возникает при соединении темпоральных таблиц, так как оно часто проводится именно по специальным темпоральным столбцам.

Однако встает вопрос: должны ли темпоральные столбцы располагаться до или после остальных столбцов (обычного реляционного) индекса? Если они будут идти после всех обычных столбцов, то система получится почти «реляционной», так как большинство операций вначале будет выполняться именно на основе реляционных условий, а лишь затем будет применяться ограничение по времени, а значит, все проблемы с огромным объемом информации ложатся на традиционное реляционное ядро СУБД. Если же темпоральные столбцы будут располагаться перед обычными, то объем обрабатываемых данных будет напрямую зависеть лишь от наличия ограничений на темпоральные столбцы; например, при попытке получить историю отдельного кортежа при отсутствии темпоральых ограничений системе придется просмотреть историю всех кортежей (точнее, полностью весь индекс). Кроме того, подобный индекс будет довольно часто перестраиваться при изменениях данных темпоральных столбцов. С другой стороны, единственным изменением кортежа в таблице с темпоральной поддержкой транзакционного времени является установка вместо СЕЙЧАС точной верхней границы интервала (в момент удаления или изменения кортежа).

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

решения задачи эффективного соединения нескольких таблиц в традиционной реляционной СУБД. Частично они позволяют решить проблему производительности при соединении таблиц, но вся оптимизация возлагается на СУБД. Одновременно с этим следует помнить, что данные хранятся в интервальном представлении, поэтому соединение будет либо строиться на нестрогих неравенствах, либо алгоритм будет выполняться темпоральным ядром СУБД с учетом упаковки и распаковки темпоральных интервалов. Отсюда следует, что доступным путем является оптимизация преобразований различных темпоральных запросов в реляционные запросы и обратно с учетом построенных индексов. С другой стороны, в большинстве случаев разработчики приложений не смогут получить значительный выигрыш в эффективности, если будут сами формулировать реляционные запросы, а не пользоваться автоматическими преобразованиями, но первый путь сложнее и чреват появлением ошибок.

Таким образом, у создателей прототипов темпоральных СУБД не было широкого выбора методов оптимизации, а единственным действенным способом являлось расширение индексов или использование промежуточных алгоритмов, но за счет увеличения потока данных между ргоху-уровнем и реляционной СУБД. При этом исследователи предлагали различные расширения стандартных подходов к индексированию реляционных баз данных и хранению данных.

6. Смежные и дополнительные области исследований

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

6.1. Темпоральные базы XML-данных

В начале этого века формат XML, по сути, стал стандартом представления данных для обмена в сети. Разработчики реляционных СУБД начали включать поддержку XML в свои продукты. Одновременно с этим многие исследователи темпоральных баз данных обратили свое внимание на возможность работы с темпоральными базами XML-данных. Первоначально большие надежды возлагались на создание темпоральной XML-СУБД, так как стандарт языка темпоральных запросов еще не был окончательно принят, а для его реализации потребовалось бы создание новых алгоритмов, оптимизаторов и т.п.; поэтому внесение темпоральной поддержки в ядро

XML-СУБД было вполне вероятным. Однако многие производители реляционных СУБД минимальными усилиями добавили в свои продукты поддержку баз XML-данных, а не стали создавать новые системы.

Имеется несколько работ, в которых предлагается темпоральное расширение языка XQuery [GS03], а также описываются темпоральные системы, предназначенные для хранения XML документов [GS03+], В отличие от реляционной модели, в которой обычно используется плоское представление данных, в XML изначально применяется древовидное представление, поэтому появляется больше вариантов темпоральной поддержки. Например, метки времени могут являться наследуемыми атрибутами, что позволяет несколько упростить формулировку многих запросов и применить дополнительные способы оптимизации. С другой стороны, плоская структура является более «предсказуемой» при работе и позволяет гораздо проще можно получить многие оценки, необходимые оптимизатору. Темпоральные базы XML-данных используются в тех случаях, когда исходные данные являются плохо структурированными или уже представлены в формате XML.

6.2. Базы данных мультимедиа

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

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

6.3. Простанственно-временные базы данных

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

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

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

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

6.4. Механизм снимков состояний

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

Общий механизм снимков состояний может быть применен тремя различными способами. Во-первых, возможно ручное создание снимка состояния по специальной команде СУБД, например, generate-snapshot, которая создает снимок. Этот подход можно назвать созданием «ручного альбома». Второй подход состоит в автоматическом создании снимков через определенный пользователем промежуток времени; например, можно создавать снимок в конце каждого месяца и хранить его в течение года. Можно считать, что такой подход приводит к появлению «автоматического альбома». При третьем подходе снимки создаются последовательно по мере изменения базовой таблицы, то есть новый снимок создается каждый раз, когда обновляется состояние. Это уже можно назвать «съемкой фильма».

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

23 Здесь мы используем термин «пространственно-временные», а не «пространственно-темпоральные» базы данных, так как он подходит больше, а путаницы с ударением не возникает.

6.5. Ветвление линий времени и версии

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

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

7. Предложения от производителей коммерческих СУБД

Выше уже говорилось, что не существует коммерческой реализации полноценной темпоральной СУБД, но многие производители предлагают различные расширения и дополнения, которые позволяют работать с темпоральными данными (или некоторым специальным их типом). Ниже представлены краткие характеристики подобных разработок.

Прототип темпоральной СУБД TimeDB был создан в 1997 г. Андреасом Стейнером в ходе работы по подготовке его диссертации [Ste98], В прототипе поддерживалось как действительное, так и транзакционное время, но он был привязан к конкретной реляционной СУБД, так как в нем использовался интерфейс уровня вызовов компании Oracle. Позже была выпущена версия TimeDB 2.0, реализованная на языке Java. Для работы с реляционной СУБД использовался интерфейс JDBC, поэтому не было привязки к конкретному

производителю. Версию TimeDB 2.0 Beta 4 можно свободно скачать с сайта компании TimeConsult в исследовательских целях [Т1М07]. Неизвестны дальнейшие пути развития проекта или какие-либо изменения в системе, произошедшие после 1999 года.

7.2. Informix TimeSeries Datablade

Модуль TimeSeries компании Informix предназначен для обработки и анализа динамики процессов на основе временных рядов данных. Он содержит определение новых типов данных — временного ряда и календаря, а также предоставляет более сорока функций для обработки данных, содержащих временные метки. Данный модуль предоставляет большие возможности по анализу динамики отдельного процесса, а также эффективному хранению данных и доступа к ним. Если ряд является регулярным, то доступ константен для любого момента времени. Здесь присутствует оптимизация вполне конкретного пути доступа, поэтому нельзя назвать TimeSeries Datablade полноценным темпоральным решением для действительного времени.

7.3. Immortal DB (прототип от Microsoft)

Целью проекта Immortal DB, реализованного исследовательским подразделением Microsoft, было предоставление поддержки транзакционного времени, встроенной в SQL сервер, а не основанной на каком-либо ргоху-уровне ([LBM+05]). Была предпринята попытка продемонстрировать, что в СУБД, кроме поддержки снимков, может быть реализована полноценная поддержка транзакционного времени, причем с хорошей производительностью. При реализации поддержки был расширен стандартный механизм сномков состояния, позволяющий получить некоторый снимок базы данных на момент времени прошлого. Одна из проблем, стоявших перед разработчиками, состояла в обеспечении обновлений и модификации данных при минимальных дополнительных затратах, поэтому была введена поддержка разбиения файловых страниц базы данных при переполнении как по ключу, так и по временному атрибуту. Механизмы контроля параллельного доступа и восстановления были полностью интегрированы с соответствующими функциями MS SQL Server.

7.4. Технология Oracle Flashback — шаг к темпоральной СУБД

В Огас1е9/ появился механизм Flashback Query [0ra07a] — мощный, простой и полностью безопасный способ восстановления системы от ошибок пользователя. Он также позволяет пользователям без внесения каких-нибудь структурных изменений в базу данных просмотреть состояние базы данных на какой-либо момент в прошлом. Данная технология позволяет исправлять пользовательские ошибки. Операции Flashback Query могут выполняться без участия администратора, и это позволяет разработчикам добавлять в свои приложения функции восстановления данных. Для использования Flashback Query требуется включение автоматического управления восстановлением

(Automatic Undo Management) вместо использования сегментов отката (Rollback Segments). При этом в Flashback Query используются именно данные восстановления, поэтому его использование не сказывается на

В Ога1се9/ механизм Flashback Query позволял получить доступ только к некоторому статическому снимку данных. В Oracle 10g к данной технологии добавились еще несколько средств: Flashback Versions Query позволяет получить вместо статической картинки «фильм» изменений, Flashback Transaction Query дает возможность увидеть изменения, внесенные заданной транзакцией, а средства восстановления Flashback Database, Flashback Query и Flashback Drop позволяют вернуться к предыдущему состоянию за

константное время, не зависящее от объема базы данных.

Если подвести некоторый итог, то можно сказать, что СУБД Oracle стала уже почти темпоральной СУБД (с поддержкой транзакционного времени). Однако создание сколько-нибудь сложного запроса с использованием технологии Flashback опять полностью зависит от разработчика, так как никакой дополнительной поддержки множественных темпоральных операций не предусмотрено. Кроме того, даже для разрешенных темпоральных запросов существуют довольно жесткие ограничения.

7.5. Решение Oracle Workspace Manager — многовер-

сионность данных и поддержка снимков состояний

Кроме рассмотренной ранее технологии Oracle Flashback в Oracle 10g можно использовать механизм Oracle Workspace Manager — это одна из возможностей СУБД, позволяющая управлять текущими, предполагаемыми и историческими значениями данных в одной и той же базе данных [0ra07b]. Oracle Workspace Manager использует рабочие пространства в качестве виртуального окружения для изоляции совокупности изменений данных, хранения истории изменений данных и создания множественных сценариев развития для анализа возможного будущего. Создаваемые рабочие пространства могут наследоваться от других рабочих пространств или стандартного «актуального» рабочего пространства LIVE (по умолчанию). При этом фиксируется текущее состояние рабочего пространства-предка. В рамках конкретного рабочего пространства также можно использовать точки сохранения, которые позволяют откатывать изменения к определенному моменту прошлого. Также предусмотрены операции по слиянию рабочего пространства-потомка с рабочим пространством-предком. Отдельный интерес представляет опция полного отслеживания всех изменений данных, включая операции добавления, удаления и обновления. Фактически, это поддержка транзакционного времени. С точки зрения работы с темпоральным данными стоит отметить возможность зафиксировать запросы на указанный момент времени.

С технической точки зрения рабочие пространства представляют собой набор представлений базы данных с обработчиками триггеров INSTEAD OF. Когда

пользователь желает добавить для таблицы поддержку версионности, менеджер рабочих областей переименовывает таблицу в _ЬТ, добавляя к ней четыре служебных столбца, после чего создает представление с названием исходной таблицы , для которого обработчики триггеров INSTEAD OF производят необходимые действия по изменению данных в исходных таблицах. Если немного упрощать, то данное решение является решением промежуточного слоя, только реализованного непосредственно внутри конкретной СУБД.

СУБД Oracle еще не стала полностью темпоральной СУБД, несмотря на наличие средства Oracle Workspace Manager, в котором была реализована часть идей SQL/Temporal. Однако прослеживаемая тенденция позволяет утверждать, что работы над созданием полноценной реализации темпоральной СУБД со стороны производителей коммерческих систем ведутся. Более того, для конкретных классов задач создаются отдельные темпоральные расширения, которые проходят «боевую» проверку на реальных задачах.

8. Актуальные вопросы и задачи, перспективы исследований

При описании темпоральных систем уже подчеркивалось наличие отдельных проблем, которые должны быть решены прежде, чем будет создана полноценная темпоральная СУБД. С другой стороны, опыт технологии Oracle Flashback показывает, что для конкретной задачи можно реализовать специализированную темпоральную поддержку. Кроме того, существует множество проблем и задач, которые могут быть решены в рамках исследований в области темпоральных и пространственно-временных баз данных [RHE+04], В этом разделе перечисляются некоторые из подобных задач.

8.1. Эффективные пользовательские интерфейсы и представления

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

8.2. Извлечение данных и знаний из пространственно-временных систем

Важными областями исследований являются извлечение информации и обнаружение знаний. Большинство работ может быть разделено на три категории:

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

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

• Анализ временных последовательностей ст целью обнаружения часто встречающихся шаблонов в значениях атрибутов с течением времени.

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

8.3. Новый уровень мобильности

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

8.4. Пространственное разрежение

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

8.5. Нетрадиционные методы доступа

Для решения нетрадиционных проблем пространственно-временных баз данных требуются новые подходы. Например, во многих работах, посвященных движущимся объектам, для моделирования областей 108

пространства используются графы, а не евклидово представление пространства. Вместо евклидовых расстояний могут использоваться расстояния на дороге. Методы доступа к подобным данным должны соответствовать специфике проблемы. Исследования методов доступа к пространственно-временным данным, главным образом, фокусируются на двух аспектах: (1) хранение и поиск исторической информации и (2) предсказание будущего. Для решения первой задачи было предложено несколько индексных структур, минимизирующих объем хранимых данных и стоимость выполнения запроса. Подобные индексы обычно основываются на многоверсионных или трехмерных вариациях 11-деревьев. Методы для предсказания будущего основаны на том предположении, что в дополнение к текущей позиции объектов известны и скорости их движения. Целью является нахождение объектов, которые будут удовлетворять пространственным условиям в некоторый момент (или интервал времени) будущего на основе заданных текущих скоростей движения (например, «на основе текущей информации найти все машины, которые будут в центре города через 10 минут»). Индексы, практически пригодные для предсказания будущего, основываются на ТРЯ-деревьях и их вариациях (также являющих развитием идей 11-деревьев).

Несмотря на огромное количество методов, которые явно фокусируются на выборку исторических данных или предсказание будущего, сейчас не существует ни одной индексной структуры, которая могла бы эффективно содействовать достижению обеих целей. Даже если бы существовала универсальная структура (например, многоверсионное ТРЯ-дерево, сохраняющее всю предыдущую историю каждого объекта), она была бы неприменимой для некоторых приложений с интенсивным обновлением. Например, обновление (удаление или повторная вставка) ТРЯ-дерева может привести к доступу более чем к 100 вершинам, и можно просто не успеть выполнить эту операцию до момента следующего обновления этого же объекта. Даже при небольшом числе движущихся объектов и небольшой скорости обновлений ТРЯ-дерево (или любой другой индекс) не может «следить» за быстрыми изменениями данных. Поэтому для приложений с интенсивным обновлением кажутся более подходящими структуры данных в основной памяти, и в этой области необходимы дальнейшие исследования.

8.6. Новые типы пространственно-временных запросов

Существует множество областей, где могут быть эффективно использованы пространственно-временные базы данных, но для решения задач оказываются недостаточными возможности формулировки запросов языка 8()Ь. К запросам нового типа относятся непрерывные запросы, где результат сильно зависит от темпорального контекста. Примером непрерывного запроса может служить следующий: «на основе текущего положения и скорости автомобиля найти две ближайшие АЗС в течение следующих пяти минут?» Результат в форме , [0,1)>, , [1,5)> означает, что АЗС А и В будут ближайшими в

интервале времени [ОД), а АЗС В и С — в интервале [1,5). Заметим, что соответствующий моментальный запрос («какие две АЗС являются сейчас ближайшими?») в высоко динамичном окружении обычно будет бессмысленным: если точка запроса или объект базы данных двигается, то результат может сразу стать недействительным.

В любом пространственном запросе имеется непрерывная составляющая, условие завершения которой зависит от потребностей пользователя или приложения. Рассмотрим, например, оконный запрос, где окно (и, возможно, объекты базы данных) двигается и/или изменяется с течением времени. Условием завершения может быть время (следующие пять минут), условие на результат (например, пока в окне запроса не останется только один объект, или пока результат не изменится три раза), условие на окно запроса (пока окно запроса не достигнет определенной точки в пространстве) и т.д.

Основным отличием от непрерывных запросов к традиционным базам данных является то, что в случае пространственно-временных баз данных для фиксации динамического поведения объекта не обязательно требуются обновления базы данных; поведение может сохраняться как функция от времени с использованием подходящих индексов. Кроме того, даже если объекты остаются статическими, результаты могут изменяться из-за динамической природы самого запроса (например, движущееся окно запроса), который также может быть представлен в виде функции от времени. Таким образом, пространственно-временной непрерывный запрос может быть вычислен немедленно (в текущий момент времени) с использованием параметризованной информации о динамическом поведении запроса или объектов базы данных, и будет выдано несколько результатов, каждый из которых относится к соответствующему интервалу времени в будущем.

8.7. Приближенные запросы

В некоторых пространственно-временных приложениях по причине большого объема данных и высокой скорости обновлений требуется приближенное вычисление запросов. Например, в системах управления движением трансорта исходные данные обычно представляются в виде потоков данных (например, через сенсоры, встроенные на дорожной сети), которые потенциально не ограничены в объеме. Поэтому нереальна материализация всех данных. Более того, даже если бы все данные были сохранены, точная обработка была бы слишком дорогой из-за больших размеров индекса, поскольку при использовании любого алгоритма выполнения запроса потребуется пройти в индексе полный путь от корня до листовой вершины. Наконец, для многих приложений требуется именно приближенная суммарная информация об объектах, удовлетворяющих определенному пространственно-временному предикату (например, «количество автомобилей в центре города в течение 10 минут»), а не точные данные об объектах (например, номера машин).

8.8. Неопределенности при обработке «неточных» данных

Неопределенность присуща большинству пространственно-временных приложений из-за ошибок в измерениях/оцифровке и отсутствия или неполноты информации. Допустим, например, что пользователь с карманным компьютером хочет узнать расстояние по шоссе до ближайшего ресторана. Хотя пользователь может находиться на некотором участке дороги, система может не суметь определить это из-за неточности GPS-приемника. В подобных ситуацих может задаваться допуск dT, такой что любая точка, удаленная от дороги на расстояние, не большее dT, считается находящейся на дороге. В качестве альтернативы можно привязать точку к ближайшей дороге, предполагая наличие неполноту информации (например, наличие незарегистрированного проезда улицу), или считать дорогу недоступной в зависимости от особенностей приложения. Похожие проблемы существуют для траекторий объектов, так как движение непрерывно, а измерения дискретны. При разработке приложений необходимо также учитывать возможность соединения нескольких таблиц, в каждой из которых данные могут быть неточны. В этом случае требуется разработка специальных индексов и оптимизация хранения информации, чтобы подобные запросы выполнялись эффективно, причем в результат может быть включен и показатель неопределенности.

9. Итоги и перспективы

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

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

но остается очень много неисследованных проблем в смежных исследовательских и прикладных областях.

Arie Segev, Christian S. Jensen, and Richard T. Snodgrass. Report on The 1995 International Workshop on Temporal Databases. ACM SIGMOD Record 24(4), December 1995, http://acm.org/sigmod/record/issues/9512/temporal.ps J. Bair, M. H. Böhlen, C. S. Jensen, and R. T. Snodgrass. Notions of Upward Compatibility of Temporal Query Languages. Wirtschaftsinformatik, 39(l):25-34, February 1997, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter24.pdf M. H. Böhlen, R. Busato, and C. S. Jensen. Point-Versus Interval-Based Temporal DataModels. In Proceedings of the Fourteenth International Conference on Data Engineering, pp. 192-200, Orlando, Florida, February 1998,

Michael H. Böhlen. Temporal Database System Implementations.

ACM SIGMOD Record 24(4), December 1995,

http ://www. sigmod. org/record/issues/9512/tdbms.ps

J. Ben-Zvi, “The Time Relational Model,” PhD thesis, Computer

Science Dept., UCLA, 1982

J. Clifford, C. E. Dyreson, T. Isakowitz, C. .S. Jensen, and R. T. Snodgrass. On the Semantics of ‘Now’ in Databases. ACM Transactions on Database Systems, 22(2), June 1997, http://www.cs.aau.dk/~csj/Thesis/pdf/chapter4.pdf

C.J. Date, Hugh Darwen, Nikos Lorentzos. Temporal Data & the Relational Model. Morgan Kaufmann; 1st edition, November 19, 2002

Dengfeng Gao, S. Jensen, T. Snodgrass, D. Soo. Join operations in temporal databases. The VLDB Journal, Volume 14 Issue 1, 2005, http://www.cs.aau.dk/~csj/Papers/Files/2004_gaoVLDBj.pdf Dengfeng Gao and Richard T. Snodgrass. Syntax, Semantics, and Query Evaluation of the xXQuery Temporal XML Query Language, TimeCenter TR-72, March 2003,

Dengfeng Gao and Richard T. Snodgrass. Temporal Slicing in the

Evaluation of XMLQueries. Proceedings of the 29th VLDB

Conference, Berlin, Germany, 2003,

JCC’s SQL Standards Page. http://jcc.com/SQL.htm JCC Consulting,

i Не можете найти то, что вам нужно? Попробуйте сервис подбора литературы.

Jan Chomicki and David Toman. Implementing Temporal Integrity Constraints Using an Active DBMS. IEEE Transactions on Knowledge and Data Engineering 7(4), August 1995, http://www.cs.uwaterloo.ca/~david/papers-ride94.ps Lomet, D., Barga, R., Mokbel, M., Shegalov, G., Wang, R., and Zhu, Y. Immortal DB: Transaction Time Support for Sql Server. SIGMOD Conference, Baltimore, MD, June 2005, http://www-users.cs.umn.edu/~mokbel/ImmortalDBDemo.pdf Технология Oracle Flashback,

http://www.oracle.com/technology/deploy/availability/htdocs/Flashba ck_Overview.htm, 2007.

Oracle Workspace Manager,

http://www.oracle.com/technology/products/database/workspace_man ager/, 2007.

Roddick, J. F., Hoel, E., Egenhofer, M. J., Papadias, D., and Salzberg, B. Spatial, temporal and spatio-temporal databases — hot issues and directions for phd research. SIGMOD Rec. 33(2), June 2004, http://acm.org/sigmod/record/issues/0406/RRl.SSTDpaper.pdf Richard T. Snodgrass, editor, Ilsoo Ahn, Gad Ariav, Don Batory, James Clifford, Curtis E. Dyreson, Ramez Elmasri, Fabio Grandi, Christian S. Jensen, Wolfgang Kaefer, Nick Kline, Krishna Kulkami, T. Y. Cliff Leung, Nikos Lorentzos, John F. Roddick, Arie Segev, Michael D. Soo and Suryanarayana M. Sripada, The TSQL2 Temporal Query Language, Kluwer Academic Publishers, 1995. Спецификация TSQL2 доступна по адресу

ftp://ftp.cs.arizona.edu/tsql/tsql2/bookspec.pdf, а комментарии — на ftp://ftp.cs.arizona.edu/tsql/tsql2/eval.pdf

Snodgrass, R. Т., М. H. Böhlen, С. S. Jensen and A. Steiner. Adding Valid Time to SQL/Temporal. ANSI X3H2-96-501r2, ISO/IEC JTC 1/SC 21/WG 3 DBL-MAD-146r2, November, 1996,

http ://www. cs. aau. dk/~csj/Thesis/pdf/chapter26 .pdf Snodgrass, R. Т., M. H. Böhlen, C. S. Jensen and A. Steiner. Adding Transaction Time to SQL/Temporal, ANSI X3H2-96-502r2, ISO/IEC JTC 1/SC 21/WG 3 DBL-MAD-147r2, November, 1996,

http ://www. cs. aau. dk/~csj/Thesis/pdf/chapter27 .pdf Snodgrass, R.T. Addendum to Valid- and Transaction-time Proposals. ANSI X3H2-96-582, БОЛЕС JTC1/SC21/WG3 DBL MAD-203, November 1996, ftp://ftp.cs.arizona.edu/tsql/tsql2/sql3/ansi-96-582.pdf

Snodgrass, R.T. A Second Addendum to Valid- and Transaction-time Proposals. ANSI X3H2-97-010, ISO/IEC JTC1/SC21/WG3 DBL MAD-220, January 1997,

http ://www. informatik.uni-trier. de/~ley/db/sy stems/sql3. html

Richard T. Snodgrass. Developing Time-Oriented Database Applications in SQL. Morgan Kaufmann Publishers, 1999.

Andreas Steiner. A Generalisation Approach to Temporal Data

Models and their Implementations. Doctoral Thesis, ETH No. 12434,

Department of Computer Science, ETH Zurich, Switzerland, 1998,

http ://www .timeconsult. com/Publications/diss .pdf

Официальный сайт проекта TimeDB,

http ://www .timeconsult. com/Software/Software.html

K. Torp, C. S. Jensen, and R. T. Snodgrass. Stratum Approaches to

Temporal DBMS Implementation. In Proceedings of the 1998

International Database Engineering and Applications Symposium,

Cardiff, Wales, UK, July 1998,

David Toman. Point vs. Interval-based Query Languages for

Temporal Databases. Proceedings of the fifteenth ACM SIGACT-

SIGMOD-SIGART symposium on Principles of database systems,

Montreal, Quebec, Canada, 1996,

http ://www.cs .uwaterloo .ca/~david/papers-pods96 .ps

D. Toman. Point-Based Temporal Extensions of SQL and Their

Efficient Implementation. Temporal Databases: Research and

Practice, Springer; 1st edition, July 1, 1998,

Как удалить темпоральную таблицу mssql

SQLRU.net
Разработка приложений баз данных

Начало » Использование СУБД » Microsoft SQL Server

Показать: Сегодняшние сообщения :: Сообщения без ответа :: Голосования :: Навигатор по сообщениям

От: Palvaleri4 — Thu, 26 October 2023

От: Шмодра — Thu, 26 October 2023

От: krioxi — Wed, 25 October 2023

От: rabanik — Wed, 18 October 2023

От: David — Fri, 06 October 2023

От: Stephov — Thu, 05 October 2023

От: ilya3310 — Tue, 10 October 2023

От: ValRi — Mon, 09 October 2023

От: BlackEric — Tue, 30 May 2023

От: Мария1212 — Fri, 29 September 2023

От: Богдан — Mon, 02 October 2023

От: arush23 — Thu, 25 May 2023

От: Testament — Fri, 25 August 2023

От: Sanek — Mon, 07 August 2023

От: sergey020487 — Sun, 23 July 2023

От: prospector — Tue, 18 July 2023

От: prospector — Wed, 19 July 2023

От: BlackEric — Sun, 16 July 2023

От: Андрей — Wed, 21 June 2023

От: Aspram — Tue, 13 June 2023

От: GrigoryFomin — Sun, 28 May 2023

От: GrigoryFomin — Sun, 21 May 2023

От: lupeykin — Wed, 24 May 2023

От: Виталий — Fri, 05 May 2023

От: Sanches3d — Thu, 18 May 2023

От: GrigoryFomin — Tue, 16 May 2023

От: shams — Mon, 01 May 2023

От: keepermode — Thu, 04 May 2023

От: ezus — Tue, 02 May 2023

От: akme24 — Mon, 24 April 2023

От: StillZero — Sat, 15 April 2023

От: Mansso — Thu, 06 April 2023

От: Sanych33 — Wed, 05 April 2023

От: Павел677 — Wed, 15 March 2023

От: BlackEric — Wed, 18 January 2023

От: boogeyman — Sun, 05 March 2023

От: egorka123 — Thu, 02 March 2023

От: Sebastian — Tue, 28 February 2023

От: komrad — Mon, 27 February 2023

От: some — Tue, 21 February 2023

Легенда: Новые сообщения Нет новых сообщений Тема закрыта (есть непрочитанные сообщения) Тема закрыта Тема перенесена в другой форум

Текущее время: Mon Oct 30 02:05:13 GMT+3 2023

Общее время, затраченное на создание страницы: 0.01450 секунд

. Обратная связь :: Начало .

Как удалить темпоральную таблицу mssql

Как удалить темпоральную таблицу mssql

2. Основные понятия

3. Таблицы с периодом прикладного времени

3.1 Операции UPDATE и DELETE с разделом FOR PORTION OF

3.2 Первичный ключ и ссылочные ограничения целостности

3.3 Предикаты с периодом прикладного времени

4. Системно-версионные таблицы

4.1 Отличия системно-версионных таблиц от таблиц с периодами прикладного времени

4.2 Операции UPDATE и DELETE над системно-версионными таблицами

4.3 Первичный ключ и ссылочное ограничение целостности

4.4 Запросы в системно-версионных таблицах

5. Битемпоральные таблицы

6. Заключение

Список литературы

Темпоральные таблицы SQL Server: практические рекомендации

В чем подвох?

Создание темпоральной таблицы

Преобразование оптимизированной в памяти таблицы OLTP в таблицу с системным управлением версиями

Создание нового оптимизированного в памяти OLTP с включенной опцией System-Versioned Table

Добавление опции System-Versioned Table в существующую оптимизированную в памяти таблицу OLTP.

Указание свойства DATA_CONSISTENCY_CHECK

Заключение

История и актуальные проблемы темпоральных баз данных Текст научной статьи по специальности «Компьютерные и информационные науки»

Аннотация научной статьи по компьютерным и информационным наукам, автор научной работы — Костенко Б. Б., Кузнецов С. Д.

Похожие темы научных работ по компьютерным и информационным наукам , автор научной работы — Костенко Б. Б., Кузнецов С. Д.

Текст научной работы на тему «История и актуальные проблемы темпоральных баз данных»

Как удалить темпоральную таблицу mssql

Добавить комментарий Отменить ответ