21.5. Поддержка исторической
информации и темпоральных запросов
Обычные БД хранят мгновенный
снимок модели предметной области.
Любое изменение в момент времени t
некоторого объекта приводит к
недоступности состояния этого
объекта в предыдущий момент
времени. Самое интересное, что на
самом деле в большинстве развитых
СУБД предыдущее состояние объекта
сохраняется в журнале изменений, но
возможности доступа со стороны
пользователя нет.
Конечно, можно явно ввести в
хранимые отношения явный временной
атрибут и поддерживать его
значения на уровне приложений.
Более того, в большинстве случаев
так и поступают. Недаром в
стандарте SQL появились специальные
типы данных date и time. Но в таком
подходе имеются несколько
недостатков: СУБД не знает
семантики временного поля
отношения и не может
контролировать корректность его
значений; появляется
дополнительная избыточность
хранения (предыдущее состояние
объекта данных хранится и в
основной БД, и в журнале изменений);
языки запросов реляционных СУБД не
приспособлены для работы со
временем.
Существует отдельное направление
исследований и разработок в
области темпоральных БД. В этой
области исследуются вопросы
моделирования данных, языки
запросов, организация данных во
внешней памяти и т.д. Основной тезис
темпоральных систем состоит в том,
что для любого объекта данных,
созданного в момент времени t1 и
уничтоженного в момент времени t2, в
БД сохраняются (и доступны
пользователям) все его состояния во
временном интервале [t1,t2].
Исследования и построения
прототипов темпоральных СУБД
обычно выполняются на основе
некоторой реляционной СУБД. Как и в
случае дедуктивных БД темпоральная
СУБД - это надстройка над
реляционной системой. Конечно, это
не лучший способ реализации с точки
зрения эффективности, но он прост и
позволяет производить достаточно
глубокие исследования.
Примером кардинального (но, может
быть, преждевременного) решения
проблемы темпоральных БД может
служить СУБД Postgres. Эта система была
спроектирована и разработана
М.Стоунбрекером для исследований и
обучения студентов в университете
г.Беркли, и он безбоязненно шел в
ней на самые смелые эксперименты.
Главными особенностями системы
управления памятью в Postgres являются,
во-первых, то, что в ней не ведется
обычная журнализация изменений
базы данных и мгновенно
обеспечивается корректное
состояние базы данных после
перевызова системы с утратой
состояния оперативной памяти.
Во-вторых, система управления
памятью поддерживает исторические
данные. Запросы могут содержать
временные характеристики
интересующих объектов.
Реализационно эти два аспекта
связаны.
Основное решение состоит в том,
что при модификациях кортежа
изменения производятся не на месте
его хранения, а заводится новая
запись, куда помещаются измененные
поля. Эта запись содержит, кроме
того, данные, характеризующие
транзакцию, производившую
изменения (в том числе и время ее
завершения), и подшивается в список
к изменявшемуся кортежу. В системе
поддерживается уникальная
идентификация транзакций и имеется
специальная таблица транзакций,
хранящаяся в стабильной памяти.
Таким образом, после сбоев просто
не следует обращать внимание на
хвостовые записи списков,
относящиеся к незакончившемся
транзакциям. Синхронизация
поддерживается на основе обычного
двухфазного протокола захватов.
Отдельный компонент системы
осуществляет архивацию объектов
базы данных. Он производит сборку
разросшихся списков изменявшихся
кортежей и записывает их в область
архивного хранения. К этой области
тоже могут адресоваться запросы, но
уже только на чтение.
Система ориентирована на
использование оптических дисков с
разовой записью и стабильной
оперативной памяти (хотя бы
небольшого объема). При наличии
таких технических средств она
выигрывает по эффективности даже
при работе в традиционном режиме по
сравнению со схемой с
журнализацией. Однако возможна
работа и на традиционной
аппаратуре, тогда эффективность
системы слегка уступает
традиционным схемам.
Соответствующие возможности
работы с историческими данными
заложены в язык Postquel (и в этом его
главное отличие от последних
вариантов Quel). Возможна выборка
информации, хранившейся в базе
данных в указанное время, в
указанном временном интервале и
т.д. Кроме того, имеется возможность
создавать версии отношений и
допускается их последующая
модификация с учетом изменений
основных вариантов.
Предыдущая
глава || Оглавление
|| Следующая глава
|