4 Субд третьего поколения. Примеры.

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

1 Введение

Сетевые и иерархические системы баз данных, широко распространенные в 70-е годы, получили подходящее название - системы баз данных первого поколения. Действительно, это были первые системы, предлагавшие развитую функциональность СУБД в рамках единой системы, с языками определения и манипулирования данными для наборов записей.²⁾ Типичными представителями первого поколения являются системы, основанные на предложениях CODASYL [CODA71] и IMS [DATE86].

В 80-е годы системы первого поколения были существенно потеснены современным семейством реляционных СУБД, называемых системами баз данных второго поколения. Их появление стало важным шагом вперед для многих приложений, так как в этих системах использовались непроцедурные языки манипулирования данными и предусматривалась значительная степень независимости данных. Типичные представители систем второго поколения - DB2, INGRES, NON-STOP SQL, ORACLE и Rdb/VMS.³⁾

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

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

Таким образом, почти всем требуется лучшая СУБД, и уже делалось несколько попыток сконструировать прототипы с продвинутыми функциями. Более того, большинство современных поставщиков СУБД работают над значительным расширением функций своих СУБД второго поколения. Удивительна степень единодушия в отношении желаемых возможностей систем следующего, третьего поколения. В настоящей работе мы представим три основных принципа, которыми следует руководствоваться при создании систем третьего поколения. Кроме этого, будут приведены 13 предложений, в которых требования к новым системам будут обсуждены более детально. Целесообразно сопоставить нашу работу с публикациями [ATKI89, KIM90, ZDON90], где предлагаются другие наборы принципов.