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

Как возникла первая грубейшая ошибка

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

Тем не менее совершенно очевидно, что, по крайней мере в области объектных языков программирования, термин объект означает то, что традиционно называлось значением или переменной (или тем и другим). Однако, к сожалению, этот термин используется и в других областях, в частности в области семантического моделирования как части множества различных методов и методологий объектного анализа и проектирования или объектного моделирования (см., например, [13.3]). А в этой области, похоже, он не соответствует понятию значение или переменная . Скорее, он означает то, что среди специалистов по базам данных называют сущностью (откуда следует, между прочим, что в отличие от объектов языков программирования такие объекты, разумеется, не инкапсулированы). Иначе говоря, объектное моделирование - это на самом деле просто моделирование отношений сущность/связь , с чем автор публикации [13.3] в какой-то мере также соглашается. Поэтому то, что в подобных методологиях идентифицировалось как объекты , затем корректно отображалось в кортежи переменных-отношений, а не в значения доменов. Вот и весь фокус!

25.3. Вторая грубейшая ошибка

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

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

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

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

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

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

Литерачы кортежей и отношений. Это важные понятия, но их необходимо обобщить в понятия выборок кортежей и отношений [3.3].

Реляционные операторы сравнения. Также существенное понятие (хотя требуется правильная его реализация).

Операторы для обхода иерархии класса. Если иерархия класса действительно означает иерархию переменных-отношений , то, как отмечалось в предыдущем разделе, мы категорически возражаем, поскольку возможны нарушения свойства реляционной замкнутости (см. также [25.31]). Если же иерархия класса означает иерархию типов в смысле главы 19, никаких возражений нет (но в действительности это не так).

Вызов методов внутри предложений, например, SELECT и WHERE. Конечно, за.

Доступ к отдельным компонентам внутри значений атрибута, которые являются кортежами или отношениями. Конечно, за.

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

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

В [24.21] и [25.11] можно найти дополнительные аргументы в поддержку этой позиции. А в [25.8]-[25.10] и [25.13] обсуждается важное связанное понятие существенности (конструкций данных в модели данных).

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

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

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

Как возникла вторая грубейшая ошибка

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

Поэтому мы можем только предположить, что главная причина широкого распространения идеи смешивания указателей и отношений, в первую очередь, состоит в том, что слишком мало пользователей понимают, почему указатели были исключены из отношений. Как говорил Сантаяна, те, кто не помнят прошлого, обречены повторить его. Мы совершенно согласны с точкой зрения Мориса Вилкеса, который писал следующее [25.35].