[Назад] [Оглавление] [Вперед]

2.1 Первый манифест

В Первом манифесте [1] была предпринята попытка дать определение системам объектно-ориентированных баз данных. Авторы стремились привести описание основных свойств и характеристик, которыми должна обладать система, претендующая на то, чтобы быть квалифицированной как система объектно-ориентированных баз данных. Насколько это удалось, судить вам.

Эти характеристики были разделены на три группы:

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

Манифест рассматривался как отправная точка для дальнейшей дискуссии.

Введение в Первый манифест

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

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

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

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

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

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

Обязательные свойства: золотые правила

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

Сложные объекты

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

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

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

Идентифицируемость объектов

Для баз данных концепция идентифицируемости объектов (object identity ) сравнительно нова ³. Идея состоит в том, что в модели с идентифицируемостью объектов объект существует независимо от его значения. Таким образом, имеется два понятия эквивалентности объектов: два объекта могут быть идентичны (они представляют собой один и тот же объект) или они могут быть равны (они имеют одно и тоже значение). Это влечет две следствия: первое – разделяемые объекты, а второе – изменения объектов.

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

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

Конечно, можно моделировать идентифицируемость объектов в системе, основанной на идентификации посредством значений, путем введения явных идентификаторов объектов. Однако такой подход перекладывает на пользователя бремя обеспечения уникальности идентификаторов объектов и поддержки ссылочной целостности (и это бремя может быть весьма значительным для таких операций, как “сборка мусора”).

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

Инкапсуляция

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

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

Идея инкапсуляции в языках программирования происходит от абстрактных типов данных. С этой точки зрения объект делится на интерфейсную и реализационную части. Интерфейсная часть является спецификацией набора допустимых над объектом операций. Только эта часть объекта видима (для пользователя объекта). Реализационная часть состоит из части данных и процедурной части. Часть данных – это представление (representation ), или состояние объекта, а в процедурной части на некотором языке программирования описывается реализация каждой операции.

Адаптация этого принципа применительно к базам данных состоит в том, что объект инкапсулирует и программу, и данные. В мире баз данных не вполне ясно, является или нет структурная часть типа частью интерфейса (это зависит от системы), в то время как в мире языков программирования структура данных явно является частью реализации, а не интерфейса.

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

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

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

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

Типы и классы

Имеются две основные категории объектно-ориентированных систем, в одной из которых поддерживают классы, а в другой – типы. К первой категории относятся системы, опирающиеся на языки Smalltalk и Lisp . К представителям второй категории относятся, например, C ++ и Simula .

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

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

Понятие класса отличается от понятия типа. Его спецификация совпадает со спецификацией типа, но является более динамическим понятием. Класс характеризуется двумя аспектами: фабрика объектов и склад объектов. Фабрика объектов может быть использована для создания новых объектов посредством выполнения операции new данного класса операции или клонирования некоторого объекта-прототипа, являющегося представителем данного класса. Склад объектов означает, что к классу присоединяется его расширение, т.е. набор объектов, которые являются экземплярами класса. Пользователь может манипулировать складом, применяя операции ко всем экземплярам класса. Классы используются не для проверки правильности программы, а скорее для создания и манипулирования объектами. В большинстве систем, в которых используется механизм классов, классы обладают таким же статусом, как переменные и значения, ими можно манипулировать во время выполнения программы, т. е. изменять их и передавать как параметры. В большинстве случаев это делает невозможным проверку типов во время компиляции, но придает системе большую гибкость и однородность. Здесь речь идет о так называемых “полнотиповых” языках программирования (баз данных), в которых действительно создается иллюзия, что с типами можно оперировать во время выполнения программы. Насколько известно автору, при реализации, тем не менее, обычно пытаются ограничить операции над типами таким образом, чтобы можно было выполнить эти операции во время компиляции.

Конечно, между классами и типами имеется значительное сходство, оба термина использовались в каждом из значений, а в некоторых системах отличие между ними и вовсе едва заметно. Авторы Первого манифеста не чувствовали себя вправе отдать предпочтение одному из двух подходов и оставляли право выбора за проектировщиком системы. ⁵ Однако требовалось, чтобы система предоставляла некоторый механизм структурирования данных, будь это классы или типы. Таким образом, классическое понятие схемы базы данных заменяется на понятие множества классов или множества типов.

Авторы не видели необходимости в том, чтобы система автоматически поддерживала экстент типа (т. е. набор объектов данного типа в базе данных) или, если экстент типа поддерживается, чтобы система предоставляла пользователю доступ к нему. Рассмотрим, например, тип “прямоугольник”, который может использоваться в различных базах данных многими пользователями. Не имеет смысла говорить о множестве всех прямоугольников, поддерживаемых системой, или производить операции над ними. Мы думаем, что более оправдано отдать на откуп пользователю поддержку его множества прямоугольников и манипулирование ими. С другой стороны, в случае такого типа как “служащий” весьма удобно, чтобы система автоматически сопровождала экстент этого типа.

Иерархии классов или типов

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

Имеется по крайней мере четыре типа наследования: наследование через подстановку, наследование путем включения, наследование через ограничение и наследование через специализацию.

Наследование через подстановку подразумевает, что тип T наследует от типа T ’ , если над объектами типа T можно выполнить больше операций, чем над объектами типа T ’ . Таким образом, вместо объекта типаT ’ всегда можно подставить объект типа T . Этот тип наследования базируется на поведении, а не на значениях.

Наследование путем включения соответствует понятию классификации. В этом случае утверждается, что тип T является подтипом T ’ , если каждый объект типа T является также объектом типа T ’ . Этот тип наследования базируется на структуре, а не на операциях. Примером является тип “квадрат” с методами “получить”, “установить размер” и “раскрашенный квадрат” с методами “получить”, “установить размер” и “раскрасить”.

Наследование через ограничение является частным случаем наследования путем включения. Тип T является подтипом типа T ’ , если к нему относятся все объекты типа T ’ , которые удовлетворяют данному ограничению. Примером такого наследования является класс “подросток” как подкласс класса “человек”: объекты класса “подросток” не имеют дополнительных полей или операций по сравнению с объектами класса “человек”, но они удовлетворяют более специфичным ограничениям (возраст подростков ограничен снизу 13, а сверху 19 годами). ⁷

При наследовании через специализацию тип T является подтипом T ’ , если объекты типа T являются объектами типа T ’ , но при этом содержат более конкретные данные. Примером являются типы “люди” и “служащие”, где данные о служащих включают все данные о соответствующих  людях, но включают некоторые дополнительные поля.

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

Перекрытие, перегрузка и позднее связывание

Имеются случаи, когда желательно иметь одно и то же имя для различных операций. Рассмотрим, например, операцию визуализации: она принимает на входе объект и отображает его на экране. В зависимости от типа объекта используются разные механизмы отображения. Если объект является изображением, то желательно, чтобы оно действительно появилось на экране. Если объект является человеком, то желательно, чтобы в том или ином виде был отображен описывающий человека кортеж. Наконец, если объект является графом, то желательно получить графическое представление. Рассмотрим теперь задачу отображения множества объектов, типы элементов которого не известны во время компиляции.

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

В объектно-ориентированной системе операция отображения определяется на уровне типа “объект” (наиболее общий тип в системе). Таким образом, операция отображения имеет единственное имя и может быть одинаковым образом применена к графам, людям и изображениям. Однако реализация операции переопределяется для каждого типа в соответствии с его особенностями (такое переопределение называется перекрытием – overlapping ). В результате три разные программы имеют одно имя “отобразить” (это называется перегрузкой – overloading ). Для отображения множества элементов мы просто применяем операцию отображения к каждому элементу, оставляя за системой выбор соответствующей реализации во время выполнения.

Здесь реализатор типов по-прежнему должен написать то же количество программ. Но прикладному программисту уже не нужно заботиться о трех различных программах. Кроме того, код проще, так как оператор case над типами отсутствует. Наконец, код становится более сопровождаемым, поскольку и при введении нового типа, и при добавлении нового экземпляра существующего типа программа отображения будет работать без изменения (при условии, что для этого нового типа будет обеспечено перекрытие метода отображения).

Чтобы обеспечить эти новые функциональные возможности, система не может связывать имена операций с программами во время компиляции⁸. Поэтому имена операций должны разрешаться (транслироваться в адреса программ) во время выполнения. Эта отложенная трансляция называется поздним связыванием ( late binding ). Позднее связывание затрудняет проверку типов (а в некоторых случаях делает ее невозможной), но оно не отменяет ее полностью.

Вычислительная полнота

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

Авторы Первого манифеста не призывали проектировщиков объектно-ориентированных систем баз данных к созданию новых языков программирования. Вычислительную полноту можно получить, разумным образом опираясь на существующие языки программирования. Вычислительная полнота – это не то же самое, что “ресурсная полнота”, т.е. возможность доступа ко всем ресурсам системы с использованием внутренних средств языка. Система, даже будучи вычислительно полной, может быть не способна к полной поддержке приложения. Тем не менее, такая система является более мощной, чем система баз данных, которая обеспечивает только хранение и извлечение данных и выполняет простые вычисления с атомарными значениями. Легко заметить, что здесь опять под “плохой” системой понимается SQL -ориентированная СУБД. И последнее утверждение является не вполне справедливым, поскольку уже в SQL /89 обеспечивалась возможность встраивания операторов SQL в вычислительно полные императивные языки, т.е. на основе SQL и некоторого традиционного языка программирования можно было написать законченное приложение.

Расширяемость

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

Стабильность

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

Управление вторичной памятью

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

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

Параллелизм

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

Восстановление

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

Средства обеспечения незапланированных запросов

Основной проблемой является обеспечение функциональности языка незапланированных (ad hoc ) запросов. Авторы Первого манифеста не призывают к тому, чтобы эта функциональность обязательно была реализована в виде языка запросов, а требуют только, чтобы была такая услуга существовала. Например, для обеспечения этой функциональной возможности вполне достаточно наличие графической программы просмотра. Услуга состоит в том, что пользователь может без затруднений сделать простой запрос к базе данных.¹¹ Очевидной мерой являются, конечно, реляционные системы. Поэтому проверка наличия средства незапланированных запросов состоит в том, чтобы взять на пробу несколько реляционных запросов и проверить, можно ли их сформулировать с теми же затратами труда. Заметим, что это средство могло бы поддерживаться языком манипулирования данными или его подмножеством.

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

• Оно должно быть средством высокого уровня, т. е., пользователь должен иметь возможность кратко выразить нетривиальные запросы. Для этого средство формулирования должно быть достаточно декларативным, т. е., упор должен быть сделан на “что”, а не на “как”.
• Оно должно быть эффективным. Для этого формулировка запросов должна допускать возможность оптимизации запросов.
• Средство запросов не должно зависеть от приложения, т. е. оно должно работать с любой возможной базой данных. Это последнее требование устраняет потребность в специфических средствах обеспечения запросов для конкретных приложений и необходимость написания дополнительных операций для каждого определенного пользователем типа.

Заключение к золотым правилам

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

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

Необязательные возможности: конфетки

Под этим заголовком собраны возможности, которые улучшают систему, но не являются обязательными для того, чтобы система была объектно-ориентированной системой баз данных. Некоторые из этих возможностей являются объектно-ориентированными по своей природе (например, множественное наследование¹²). Они отнесены к категории необязательных возможностей, потому что не входят в набор ключевых требований, хотя и делают систему более объектно-ориентированной.

Другие возможности являются просто возможностями систем баз данных (например, управление проектными транзакциями). Эти характеристики обычно улучшают функциональные возможности систем баз данных, но не относятся к ключевым требованиям, предъявляемым к таким системам, и они не связаны с аспектом объектной ориентированности. В действительности, многие из этих возможностей предназначены для обслуживания “новых” приложений (CAD /CAM , CASE , офисная автоматизация и т.д.) и являются более ориентированными на приложения, чем на технологии. Поскольку многие системы объектно-ориентированных баз данных нацелены на эти новые приложения, то существует некоторая путаница между этими возможностями и объектно-ориентированной природой системы.

Множественное наследование

Обеспечение или не обеспечение системой множественного наследования не является обязательным. Поскольку сообщество специалистов в области объектно-ориентированного подхода еще не достигло согласия относительно множественного наследования¹³, обеспечение такого наследования считается необязательным. В случае принятия решения о поддержке множественного наследования предстоит выбор из множества возможных решений проблемы разрешения конфликтов.

Проверка и вывод типов

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

Распределенность

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

Проектные транзакции

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

Версии

Большинство новых приложений (CAD /CAM и CASE ) включают проектную деятельность и требуют поддержки версий в том или ином виде. Поэтому во многих ООСБД поддерживаются версии. И в этом случае обеспечение механизма поддержки версий не является ключевым требованием к системе.

Открытые возможности

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

Парадигма программирования

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

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

Система представления определяется набором атомарных типов и набором конструкторов. Хотя в числе Золотых правил  указывается минимальный набор атомарных типов и конструкторов (элементарные типы языков программирования и конструкторы множеств, кортежей и списков), который должен быть доступен для описания представления объектов, этот набор может быть расширен множеством разнообразных способов.

Система типов

Остается свобода и в выборе способа формирования типов. Единственным средством формирования типов, наличия которого требуют авторы, является инкапсуляция. Возможны другие формирователи типов, такие как родовые типы, генераторы типов и т.д.

Однородность

Ведутся жаркие споры о степени однородности таких систем. Является ли тип объектом? Является ли метод объектом? Следует ли эти три понятия рассматривать отдельно? Эту проблему можно рассматривать на трех разных уровнях: уровне реализации, уровне языка программирования и уровне интерфейса.

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

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

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

Заключительные замечания

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

Первый манифест является замечательным историческим материалом. Скорее всего, это неизвестно нынешнему поколению, но в 80-е дух объектной ориентированности витал над миром. Казалось, что еще совсем немного, и оковы реляционных баз данных падут и т.д.¹⁵ К сожалению, о чем мы еще поговорим позже, это не произошло. Но остается фактом, что именно этот манифест (прямо или косвенно) привел к появлению, во-первых, стандарта ODMG объектно-ориентированных баз данных (см. следующий подраздел), а во-вторых, двух следующих манифестов – Манифеста баз данных следующего поколения, а через него и стандарта SQL :1999 (см. разд.3), и Третьего манифеста (развернутое название которого его авторы так и не смогли придумать) (см. разд. 4). Первый манифест отражает представления и взгляды авторов, существовавшие к концу 80-х. Эти представления и взгляды были местами наивными, но они позволяют понять суть стремления – создать полнотиповую среду программирования, включающую возможности определения схемы баз данных, постоянного хранения объектов и манипулирования схемой и данными.

[Назад] [Оглавление] [Вперед]