Исследования
и построения прототипов темпоральных
СУБД обычно выполняются на
основе некоторой реляционной СУБД.
Как и в случае дедуктивных БД темпоральная
СУБД - это надстройка над реляционной
системой. Конечно, это не лучший способ
реализации с точки зрения эффективности,
но он прост и позволяет производить достаточно
глубокие исследования.
Примером
кардинального (но может быть, преждевременного)
решения проблемы темпоральных БД может
служить СУБД Postgres. Эта система была разработана
М.Стоунбрекера для исследований и обучения
студентов в университете г.Беркли, и он
смело шел в ней на самые смелые эксперименты.
Главными
особенностями системы управления
памятью в Postgres является, во-первых,
то, что в ней не ведется
обычная журнализация изменений
базы данных и мгновенно обеспечивается
корректное состояние базы данных
после перевызова системы с
утратой состояния оперативной памяти.
Во-вторых, система управления памятью
поддерживает исторические данные. Запросы
могут содержать временные характеристики
интересующих объектов. Реализационно
эти два аспекта связаны.
Основное
решение состоит в том, что
при модификациях кортежа изменения
производятся не на месте его хранения,
а заводится новая запись, куда помещаются
измененные поля. Эта запись содержит,
кроме того, данные, характеризующие транзакцию,
производившую изменения (в том числе
и время ее завершения), и подшивается
в список к изменявшемуся кортежу. В системе
поддерживается уникальная идентификация
транзакций и имеется специальная таблица
транзакций, хранящаяся в стабильной памяти.
Таким образом, после сбоев просто не следует
обращать внимание на хвостовые записи
списков, относящиеся к незакончившемся
транзакциям. Синхронизация поддерживается
на основе обычного двухфазного протокола
захватов.
Отдельный
компонент системы осуществляет
архивизацию объектов базы данных.
Он производит сборку разросшихся
списков изменявшихся кортежей и записывает
их в область архивного хранения. К этой
области тоже могут адресоваться запросы,
но уже только на чтение.
Система была
ориентирована на использование
оптических дисков с разовой
записью и стабильной оперативной
памяти (хотя бы небольшого объема). При
наличии таких технических средств она
выигрывает по эффективности даже при
работе в традиционном режиме по сравнению
со схемой с журнализацией. Однако, возможна
работа и на традиционной аппаратуре,
тогда эффективность системы слегка уступает
традиционным схемам.
Соответствующие
возможности работы с историческими
данными заложены в язык Postquel
(и в этом его главное отличие
от последних вариантов Quel). Возможна
выборка информации, хранившейся
в базе данных в указанное
время, в указанном временном интервале
и т.д. Кроме того, имеется возможность
создавать версии отношений, и допускается
их последующая модификация с учетом изменений
основных вариантов.
2.5. Интегрированные
или федеративные системы и
мультибазы данных
Направление
интегрированных или федеративных систем
неоднородных БД и мульти-БД появилось
в связи с необходимостью комплексирования
систем БД, основанных на разных моделях
данных и управляемых разными СУБД.
Основной
задачей интеграции неоднородных
БД является предоставление пользователям
интегрированной системы глобальной схемы
БД, представленной в некоторой модели
данных, и автоматическое преобразование
операторов манипулирования БД глобального
уровня в операторы, понятные соответствующим
локальным СУБД. В теоретическом плане
проблемы преобразования решены, имеются
реализации.
При строгой
интеграции неоднородных БД локальные
системы БД утрачивают свою
автономность. После включения локальной
БД в федеративную систему
все дальнейшие действия с
ней, включая администрирование,
должны вестись на глобальном уровне.
Поскольку пользователи часто не соглашаются
утрачивать локальную автономность, желая
тем не менее иметь возможность работать
со всеми локальными СУБД на одном языке
и формулировать запросы с одновременным
указанием разных локальных БД, развивается
направление мульти-БД. В системах мульти-БД
не поддерживается глобальная схема интегрированной
БД и применяются специальные способы
именования для доступа к объектам локальных
БД. Как правило, в таких системах на глобальном
уровне допускается только выборка данных.
Это позволяет сохранить автономность
локальных БД.
Как правило,
интегрировать приходится неоднородные
БД, распределенные в вычислительной
сети. Это в значительной степени
усложняет реализацию. Дополнительно
к собственным проблемам интеграции приходится
решать все проблемы, присущие распределенным
СУБД: управление глобальными транзакциями,
сетевую оптимизацию запросов и т.д. Очень
трудно добиться эффективности.
Как правило,
для внешнего представления интегрированных
и мульти-БД используется (иногда расширенная)
реляционная модель данных. В последнее
время все чаще предлагается использовать
объектно-ориентированные модели, но на
практике пока основой является реляционная
модель. Поэтому, в частности, включение
в интегрированную систему локальной
реляционной СУБД существенно проще и
эффективнее, чем включение СУБД, основанной
на другой модели данных.
2.6. СУБД следующего
поколения
Термин "системы
следующего (или третьего) поколения"
вошел в жизнь после опубликования
группой известных специалистов в области
БД "Манифеста систем баз данных третьего
поколения". Сторонники этого направления
придерживаются принципа эволюционного
развития возможностей СУБД без коренной
ломки предыдущих подходов и с сохранением
преемственности с системами предыдущего
поколения.
Частично
требования к системам следующего
поколения означают просто необходимость
реализации давно известных свойств,
отсутствующих в большинстве
текущих реляционных СУБД (ограничения
целостности, триггеры, модификация
БД через представления и т.д.). В число
новых требований входит полнота системы
типов, поддерживаемых в СУБД; поддержка
иерархии и наследования типов; возможность
управления сложными объектами и т.д.
Одной из
наиболее известных СУБД третьего
поколения является система Postgres, а создатель
этой системы М.Стоунбрекер, по всей видимости,
является вдохновителем всего направления.
В Postgres реализованы многие интересные
средства: поддерживается темпоральная
модель хранения и доступа к данным и в
связи с этим абсолютно пересмотрен механизм
журнализации изменений, откатов транзакций
и восстановления БД после сбоев; обеспечивается
мощный механизм ограничений целостности;
поддерживаются ненормализованные отношения
(работа в этом направлении началась еще
в среде Ingres), хотя и довольно странным
способом: в поле отношения может храниться
динамически выполняемый запрос к БД.
Одно свойство
системы Postgres сближает ее с
объектно-ориентированными СУБД. В
Postgres допускается хранение в полях
отношений данных абстрактных, определяемых
пользователями типов. Это обеспечивает
возможность внедрения поведенческого
аспекта в БД, т.е. решает ту же задачу,
что и ООБД, хотя, конечно, семантические
возможности модели данных Postgres существенно
слабее, чем у объектно-ориентированных
моделей данных.
Хотя отнесение
СУБД к тому или иному классу
в настоящее время может быть
выполнено только условно (например,
иногда объектно-ориентированную
СУБД O2 относят к системам следующего
поколения), можно отметить три
направления в области СУБД следующего
поколения. Чтобы не изобретать названий,
будем обозначать их именами наиболее
характерных СУБД.
Направление Postgres.
Основная характеристика: максимальное
следование (насколько это возможно
с учетом новых требований) известным
принципам организации СУБД (если не считать
упоминавшейся коренной переделки системы
управления внешней памятью).
Направление Exodus/Genesis.
Основная характеристика: создание собственно
не системы, а генератора систем, наиболее
полно соответствующих потребностям
приложений. Решение достигается путем
создания наборов модулей со стандартизованными
интерфейсами, причем идея распространяется
вплоть до самых базисных слоев системы.
Направление Starburst.
Основная характеристика: достижение
расширяемости системы и ее приспосабливаемости
к нуждам конкретных приложений путем
использования стандартного механизма
управления правилами. По сути дела, система
представляет собой некоторый интерпретатор
системы правил и набор модулей-действий,
вызываемых в соответствии с этими правилами.
Можно изменять наборы правил (существует
специальный язык задания правил) или
изменять действия, подставляя другие
модули с тем же интерфейсом. В целом можно
сказать, что СУБД следующего поколения
- это прямые наследники реляционных систем.
2.7. Объектно-ориентированные
базы данных
Направление
объектно-ориентированных баз данных
(ООБД) возникло сравнительно давно.
Публикации появлялись уже в
середине 1980-х гг. Однако наиболее
активно это направление развивается
в последние годы. С каждым
годом увеличивается число публикаций
и реализованных коммерческих и экспериментальных
систем.
Возникновение
направления ООБД определяется
прежде всего потребностями практики:
необходимостью разработки сложных
информационных прикладных систем,
для которых технология предшествующих
систем БД не была вполне удовлетворительной.
Конечно,
ООБД возникли не на пустом
месте. Соответствующий базис
обеспечивают как предыдущие
работы в области БД, так и
давно развивающиеся направления
языков программирования с абстрактными
типами данных и объектно-ориентированных
языков программирования.
Что касается
связи с предыдущими работами
в области БД, то наиболее сильное
влияние на работы в области
ООБД оказывают проработки реляционных
СУБД и следующее хронологически
за ними семейство БД, в которых поддерживается
управление сложными объектами. Кроме
того, исключительное влияние на идеи
и концепции ООБД и, как кажется, всего
объектно- ориентированного подхода оказал
подход к семантическому моделированию
данных (общее число публикаций по семантическому
моделированию поистине безгранично).
Достаточное влияние оказывают также
развивающиеся параллельно с ООБД направления
дедуктивных и активных БД.
Среди языков
и систем программирования наибольшее
первичное влияние на ООБД
оказал Smalltalk. Этот язык сам по себе не
является полностью пионерским, хотя в
нем была введена новая терминология,
являющаяся теперь наиболее распространенной
в объектно-ориентированном программировании.
На самом деле, Smalltalk основан на ряде ранее
выдвинутых концепций.
Большое число
работ не означает, что все
проблемы ООБД полностью решены.
Как отмечается в Манифесте
группы ведущих ученых, занимающихся
ООБД, современная ситуация с
ООБД напоминает ситуацию с
реляционными системами середины
1970-х гг. При наличии большого количества
экспериментальных проектов (и даже коммерческих
систем) отсутствует общепринятая объектно-ориентированная
модель данных, и не потому, что нет ни
одной разработанной полной модели, а
по причине отсутствия общего согласия
о принятии какой-либо модели. На самом
деле, имеются и более конкретные проблемы,
связанные с разработкой декларативных
языков запросов, выполнением и оптимизацией
запросов, формулированием и поддержанием
ограничений целостности, синхронизацией
доступа и управлением транзакциями и
т.д.
Мы уже
говорили, что основная практическая
надобность в ООБД связана
с потребностью в некоторой
интегрированной среде построения
сложных информационных систем.
В этой среде должны отсутствовать
противоречия между структурной
и поведенческой частями проекта и
должно поддерживаться эффективное управление
сложными структурами данных во внешней
памяти. С этой точки зрения языковая среда
ООБД - это объектно-ориентированная система
программирования, естественно включающая
средства работы с долговременными объектами.
"Естественность" включения средств
работы с БД в язык программирования означает,
что работа с долговременными (хранимыми
во внешней БД) объектами должна происходить
на основе тех же синтаксических конструкций
(и с той же семантикой), что и работа со
временными, существующими только во время
работы программы объектами.
Эта сторона
ООБД наиболее близка родственному
направлению языков программирования
БД. Языки программирования ООБД
и БД во многих своих чертах
различаются только терминологически;
существенным отличием является лишь
поддержание в языках первого класса подхода
к наследованию классов. Кроме того, языки
второго класса, как правило, более развиты
как в отношении системы типов, так и в
отношении управляющих конструкций.
Что же
касается связи ООСУБД с реляционными
системами, то, как обычно, реляционные
СУБД являются основным инструментом
при проведении исследовательских работ
и прототипировании объектно-ориентированных
СУБД.