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

Методы. Это, конечно, важное понятие, хотя мы предпочли бы более привычный термин операторы. Но объединение методов с операторами не является обязательным и приводит к некоторым проблемам [3.3]. Раздельное определение классов (типов) и методов (операторов), как было показано в главе 5, позволяет обойтись без использования понятия объекта-получателя.

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

Замечание. Однако мы бы отказались от функций-конструкторов. Конструкторы создают переменные. А поскольку для нас единственными необходимыми переменными в базе данных являются переменные-отношения, единственный конструктор , который нам нужен, - это оператор создания переменной-отношения, т.е. CREATE TABLE или CREATE VIEW (по терминологии языка SQL). Операторы выборки, наоборот, выбирают значения. Конечно, дополнительное отличие в том, что конструкторы возвращают указатели на созданные переменные, в то время как операторы выборки возвращают сами выбранные значения.

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

Иерархия классов. С иерархией классов связаны такие понятия, как наследование, полиморфизм, перегрузка, переопределение и т.д. Считаем, что понятие нужное, но производное. Мы рассматриваем поддержку иерархии классов как составляющую поддержки самих классов.

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

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

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

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

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

Представления. Обычно не поддерживаются (в основном по тем же причинам, что и обработка произвольных запросов).

Замечание. В некоторых объектных системах поддерживаются производные или виртуальные переменные экземпляра (обязательно открытые). Например, переменная экземпляра AGE (возраст) может наследоваться с помощью вычитания значения переменной экземпляра BIRTH-DATE (дата рождения) от текущей даты. Однако такая возможность еще очень далека от возможностей, которые предоставляются с помощью механизма представлений; и кроме того, мы уже отказались от понятия открытой переменной экземпляра.

Декларативные ограничения целостности. Обычно не поддерживаются (в основном, по тем же причинам, что и представления и обработка незапланированных запросов ). Более того, они обычно не поддерживаются даже теми системами, которые поддерживают незапланированные запросы.

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

Замыкание. Сложно найти объектный аналог реляционному свойству замкнутости.

Каталог. Где же каталог в объектной системе? Как он выглядит? Есть ли какие-либо стандарты?

Замечание. Конечно, это вопросы риторические. Каков будет реальный результат, если такой каталог будет создан специалистом-профессионалом, которому будет поручено выполнить подгонку объектной СУБД, устанавливаемой для какого-либо приложения, как обсуждалось в разделе 24.5. (Такой каталог будет специфическим для данного приложения, как, впрочем, и вся настроенная СУБД.)

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

Поняггие

Предпочтительный термин

Замечания

Класс объекта

Неизменяемый объект Изменяемый объект Метод

Сообщение

Значение

Переменная

Оператор

Вызов оператора

Скаляр и нескаляр; может определяться пользователем Скаляр и нескаляр Скаляр и нескаляр Включает операторы выборки, операторы ТНЕ , := , = и оператор проверки типа Никаких целевых операндов

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

Упражнения

24.1. Дайте определения следующим терминам.

закрытая переменная экземпляра

защищенная переменная экземпляра

идентификатор объекта

иерархия вложения

иерархия классов

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

класс

метод

обратная переменная

открытая переменная экземпляра

объект

объект, определяющий класс сообщение

функция конструктора

24.2. В чем заключаются недостатки и преимущества использования идентификаторов объектов? Каким образом можно реализовать идентификаторы?

24.3. В разделе 24.2 были представлены две формулировки SQL-запроса Найти все прямоугольники, которые покрывают какую-нибудь область квадрата (О, О, 1, 1) . Докажите, что эти формулировки эквивалентны.

24.4. Исследуйте любую доступную вам объектную СУБД. Какой язык программирования поддерживается в этой системе? Поддерживается ли в ней язык запросов? Если поддерживается, то какой? Является ли он, по вашему мнению, более мощным, чем язык SQL? Как организован каталог системы? Как пользователь опрашивает каталог? Предусмотрена ли в этой системе поддержка представлений? Если предусмотрена, то в какой степени (например, поддерживается ли в ней обновление представлений)? Как обрабатывается отсутствующая информация ?

24.5. Составьте макет объектной версии используемой в этой книге базы данных поставщиков и деталей.

Замечание. Этот макет будет использоваться как основа для приведенных ниже упр. 24.6-24.8.

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