Семантика баз данных

12.4 Темпоральные данные

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

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

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

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

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

Например, нашу таблицу emp (таблица 7.1) не стоит считать темпоральной только из-за того, что столбец hiredate в ней имеет тип DATE. Ведь СУБД не интерпретирует смысл этого столбца как даты, с которой вновь принятый сотрудник начинает работу. Кроме того, хорошо бы в emp иметь столбцы, фиксирующие даты увольнений (firedate) и переводов на другие должности (transferdate). Иначе создается нереалистическая картина организации, которая только принимает на работу, но не увольняет и не перемещает сотрудников. Вспоминая Стругацких, это список сотрудников, допущенных к получению зарплаты посмертно.

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

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

Различают еще модельное и транзакционное время. Модельное время — это время моделируемой предметной области. Например, в таблице emp в столбце hiredate фиксируется дата, в которую сотрудник приступил к работе. Транзакционное время определяется промежутком времени, в который некоторая запись была представлена в базе данных, то есть периодом между добавлением и удалением записи. При этом операция обновления понимается как последовательность из удаления старой записи и добавления новой. Транзакционное время может быть не доступно пользователю и используется администраторами для работы с журналом и историей изменений записей (аудитом).

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

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

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

12.4.2 Темпоральные данные интерпретируемые пользователем

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

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

Следует помнить, что базы данных табличного типа могут не оптимизировать запросы с темпоральными данными. Поэтому эффективность запросов может сильно зависеть от структуры данных.

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

Первичный ключ образуют столбцы price_code и start_date. Запрос, позволяющий узнать цену товара "А" действующую на указанную дату, требует использования подзапроса:

SELECT price FROM pricel WHERE price_code = 'A'
AND start_date = (SELECT MAX(start_date) FROM pricel WHERE price_code = 'A' AND start_date <= требуемая_дата)

Указание только начальной даты периода можно рекомендовать при интенсивной вставке записей и при отсутствии частых запросов по периодам времени, вроде приведенного выше.

Таблица price2 (таблица 12.4) определяет и начало и конец действия цены. Первичный ключ по-прежнему образуют столбцы price_code и start date.

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

SELECT price 
FROM price2 
WHERE price_code = 'A'
AND заданная_дата BETWEEN start_date AND end_date;

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

12.4.3 Модальные и темпоральные данные как смыслы

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

Что такое модальности в логике? В высказываниях часто используются модальные операторы, которые в русском языке выражаются словами "известно", "возможно", "разрешено", "верится" и т.д. Раздел логики, изучающий свойства высказываний и предикатов с модальными операторами называется модальной логикой.

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

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

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

Алетические модальности могут быть временными ("в будущем", "в прошлом", "всегда" и т. п.) и пространственными ("здесь", "где-нибудь", "близко" и т. д.)

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

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

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

Темпоральные логики это частный случай логик модальных. В них могут в качестве и , использоваться символы будущего и прошлого, обозначаемые [F] и [Р].

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

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

Возможны две шкалы времени:

• Прошлое — настоящее — будущее;
• Раньше — позже.

Интерпретацию темпоральных данных программой можно реализовать двумя основными способами:

• на основе различных темпоральных логик;
• с использованием специальных предикатов в рамках логики предикатов первого порядка.

Понятно, что второй вариант, скорее всего, будет иметь ограниченное применение.