Моделирование темпоральных (временных) данных в хранилищах данных

Цель лекции

Изучив материал настоящей лекции, вы будете знать:

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

и научитесь:

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

Литература: [3], [37].

Темпоральные данные и базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И со временем фиксации факта, и со временем операции связывается домен "Время", который может быть как дискретным, так и непрерывным. Для представления времени в БД обычно применяется домен с конечными и дискретными значениями. Предполагается, что значения времени в домене упорядочены.