Файл: Базы данных - уч. пособие.pdf

7.3 СУБД третьего поколения и объектно-ориентированные СУБД

141

7.3 СУБД третьего поколения
и объектно-ориентированные СУБД

7.3.1 Манифесты СУБД третьего поколения
и объектно-ориентированных СУБД

Реляционные СУБД давно подвергаются критике за то, что могут работать

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

Еще в 1990 году Комитетом по развитию функциональных возможностей СУБД

был опубликован доклад, представленный на конференции в Виндермере (Англия)
и получивший название «Манифест СУБД третьего поколения». Полный текст до-
кумента изложен в [21], в данном пособии рассмотрим лишь общие положения
Манифеста.

Авторы документа отмечают, что на момент опубликования доклада сформи-

ровались два поколения таких систем:

• первое поколение — иерархические и сетевые системы, которые были пер-

выми системами, позволившими объединить средства языков определения
данных и манипулирования данными для совокупностей записей;

• второе поколение — реляционные СУБД, явившиеся важным шагом в эво-

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

Авторы манифеста сформулировали три принципа и тринадцать предложений,

имеющих отношение к СУБД третьего поколения.

Принципы:

1) СУБД третьего поколения будут обеспечивать сервисы в трех областях:

• управления данными;

• управления объектами;

• управления знаниями;

2) СУБД третьего поколения должны сохранить функции непроцедурного до-

ступа и независимости данных, присущие СУБД второго поколения;

3) СУБД третьего поколения должны быть открытыми для других подсистем.

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

Предложения были условно разделены на три группы.

Первая группа содержит предложения, связанные с ОО-свойствами, которые

необходимы для систем третьего поколения:

142

Глава 7. Системы управления базами данных

1) наличие объектно-ориентированных возможностей, но не как элементов

полностью нового архитектурного рассмотрения СУБД, а как расширение
существующих моделей;

2) поддержание механизма наследования;

3) поддержание функций (методов, процедур) и инкапсуляции;

4) факультативное назначение уникальных идентификаторов для записей;

5) правила (триггеры) должны стать важной возможностью будущих систем,

но их не следует ассоциировать с какими-либо определенными функциями
или коллекциями.

Вторая группа содержит предложения, касающиеся усиления функций СУБД:

1) навигация для доступа к требуемым данным должна использоваться только

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

2) должно быть не менее двух вариантов реализации коллекций, один из кото-

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

3) должна существовать возможность обновления представлений;

4) кластеризация, индексы уникальных идентификаторов, буферы в пользова-

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

Третья группа предложений касается идеологии открытых систем:

1) СУБД третьего поколения должны быть многоязычными;

2) необходимо близкое соответствие между типами данных СУБД третьего

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

3) SQL должен быть сохранен в системах третьего поколения, несмотря на

многочисленные недостатки;

4) SQL-запросы и ответы на них должны быть самыми нижними уровнями

коммуникаций между клиентом и сервером.

После опубликования «Манифеста СУБД третьего поколения» эти принципы

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

За год до опубликования «Манифеста СУБД третьего поколения» другая груп-

па ученых в области БД опубликовала документ под названием «Манифест объ-
ектно-ориентированных систем баз данных», и если в «Манифесте СУБД третьего
поколения» сформулированы перспективные направления в разработке так называ-
емой гибридной модели (т. е. смеси реляционной и объектно-ориентированной), то
в Манифесте ОО-систем сделано то же самое для сугубо объектно-ориентирован-
ных БД (ООБД). Этот документ содержит тринадцать «заповедей» относительно
обязательных свойств ООБД [22].

7.3 СУБД третьего поколения и объектно-ориентированные СУБД

143

1. Поддержка сложных объектов.
Сложные объекты следует поддерживать. Сложные объекты строятся из бо-

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

2. Идентифицируемость объектов.
Идея состоит в следующем: в модели с идентифицируемостью объектов объект

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

3. Инкапсуляция объектов.
Идея инкапсуляции происходит из потребности отчетливо различать специфи-

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

4. Поддержка типов и классов.
Система должна предоставлять некоторый механизм структурирования дан-

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

5. Обеспечение иерархии классов или типов.
Для классов или типов следует поддерживать наследование. Наследование об-

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

6. Перекрытие, перегрузка и позднее связывание.
Не следует производить преждевременное связывание. Для обеспечения пере-

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

7. Обеспечение вычислительной полноты.
Вычислительную полноту следует поддерживать. С точки зрения языка про-

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

144

Глава 7. Системы управления базами данных

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

8. Расширяемость.
Система БД поставляется с набором предопределенных типов. Эти типы могут

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

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

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

10. Управление вторичной памятью.
Управление вторичной памятью является классической чертой систем управ-

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

11. Параллелизм.
Следует поддерживать параллельную работу нескольких пользователей. Что

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

12. Восстановление.
Следует обеспечивать восстановление после аппаратных и программных сбо-

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

7.3 СУБД третьего поколения и объектно-ориентированные СУБД

145

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

териям:

1) быть средством высокого уровня, т. е. пользователь должен иметь возмож-

ность кратко выразить нетривиальные запросы (в нескольких словах или
несколькими нажатиями клавиш мыши). Это означает, что средство форму-
лирования должно быть достаточно декларативным, т. е. упор должен быть
сделан на «что», а не на «как»;

2) быть эффективным, т. е. формулировка запросов должна допускать возмож-

ность оптимизации запросов;

3) не должно зависеть от приложения, т. е. оно должно работать с любой воз-

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

Помимо обязательных «заповедей» в Манифесте ООСУБД содержались также

дополнительные положения, характерные для объектно-ориентированных СУБД:

• множественное наследование;

• проверка и вывод типов;

• распределенность;

• проектные транзакции;

• версии;

• парадигма программирования;

• система представления;

• система типов;

• однородность.

Имеется ряд коммерческих объектно-ориентированных систем баз данных. В их

числе GemStone (от Servio Corporation), ONTOS (ONTOS), Object Store (Object
Design, Inc.), Objectivity/DB (Objectivity,Inc.), Versant (Versant Object Technology,
Inc.), Object Database (Object Database, Inc.), Itasca (Itasca Systems, Inc.), 02 (02
Technology). Все эти продукты поддерживают объектно-ориентированную модель
данных. Они позволяют пользователю создавать новый класс с атрибутами и ме-
тодами, определять наследование атрибутов и методов у суперклассов, создавать
экземпляры поодиночке или группами, загружать и выполнять методы.

Рассмотрим два похода к новым типам СУБД, предложенные в манифестах.
Оба документа предполагают поддержку сложных объектов, инкапсуляции,

структуры классов, наследования и расширяемости [21, 22]. Однако использовать-
ся эти механизмы должны по-разному. Наиболее значительные расхождения обна-
руживаются в области использования таких механизмов, как уникальные иденти-
фикаторы объектов, поддержка полиморфизма и языковые средства. Здесь позиции
авторов манифестов полностью расходятся.

Сторонниками объектно-ориентированного подхода предлагается введение уни-

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