Операторы реляционного сравнения, например SUBSET, SUBSETEQ и т.д. (Примеры операторов взяты из рассматриваемого продукта. В этом продукте оператор SUBSET на самом деле означает собственное подмножество , а SUBSETEQ - подмножество .)

Операторы для отслеживания иерархии классов.

Замечание. Здесь также требуется осторожность. Вполне возможно, что результат выполнения запроса данных из отношения PERSON вместе с соответствующими данными из отношения ЕМР не будет отношением. Фактически это означает нарушение фундаментального реляционного свойства замкнутости со всеми вытекающими отсюда плачевными последствиями. (В связи с этим в [25.31] - где такой результат называют обкусанным возвратом - беспечно замечают, что программа клиента должна быть готова справиться со всеми сложностями обработки обкусанного возврата !)

Возможность вызывать методы в предложениях SELECT и WHERE в терминах языка SQL.

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

Для краткого обзора практической реализации уравнения переменная-отношение = класс этого, пожалуй, будет достаточно. Теперь разберемся, что же тут плохого.

Прежде всего отметим, что, как уже указывалось, переменная-отношение - это переменная, а класс - это тип. Так как же они могут быть одним и тем же? Одного этого достаточно, чтобы идею уравнения переменная-отношение = класс отбросить без дальнейшего обсуждения. Однако не будем торопиться, поскольку в связи с этим возникают и дополнительные вопросы, рассмотреть которые было бы весьма полезно.

Из уравнения переменная-отношение класс следуют уравнения кортеж = объект и атрибут = (открытая) переменная экземпляра . Таким образом, хотя (как было показано в главе 24) настоящий объектный класс - по крайней мере скаляр или инкапсулированный объектный класс - имеет методы и не имеет открытых переменных экземпляра, объектный класс переменной-отношения имеет открытые переменные экземпляра и лишь необязательно имеет методы (разумеется, он не инкапсулирован ). И снова возникает вопрос, как могут эти два понятия быть одним и тем же?

Между определениями атрибутов, например SAL NUMERIC и WORKS FOR COMPANY, имеется значительное отличие. Тип NUMERIC- это настоящий тип данных (равносильный настоящему, хотя и примитивному, домену). Он накладывает независимое от времени Офаничение на значения, которые может законно принимать атрибут SAL. Тип COMPANY, напротив, не является истинным типом данных. Офаничение, которое он накладывает на значения афибута WORKS FOR, зависит от времени (оно, очевидно, зависит от текущего значения переменной-отношения COMPANY). Фактически здесь стерты все различия между переменными-отношениями и доменами или согласно объектной терминологии между коллекциями и классами.

Как мы уже видели, одни объекты кортежей могут содержать другие такие же объекты . Например, объекты ЕМР воспринимаются как содержащие объекты COMPANY. Однако в действительности они содержат не их, а указатели на эти

содержащиеся в них объекты , и это нужно четко себе представлять. Предположим, что пользователь каким-то образом обновляет один из кортежей отношения COMPANY (см. рис. 25.1). Тогда это изменение немедленно распространяется на все кортежи ЕМР, которые содержат данный кортеж COMPANY.

Замечание. Указанные здесь последствия обновления не должны восприниматься как нежелательные - они были приведены лишь для объяснения эффекта такого обновления. Однако модель на рис. 25.1, которая использовалась нами в обсуждении, показана неверно: кортежи ЕМР содержат не кортежи COMPANY, а лишь указатели на них.

Этот аспект требует некоторых дополнительных пояснений.

а) Можно ли вставить кортеж ЕМР и задать значение для содержащегося в нем кортежа COMPANY, которого в данный момент еще не существует в переменной-отношении COMPANY? Если ответ будет положительны.м, то задание типа COMPANY для атрибута WORKS FOR не будет значить практически ничего, поскольку при этом на операцию вставки INSERT не накладывается никаких ограничений. А если ответ будет отриг{ательньш, то операция вставки INSERT становится очень сложной, так как пользователь должен указать не только допустимый внешний ключ COMPANY.NAME (как следовало бы поступить в аналогичной ситуации в реляционной системе), но и весь допустимый кортеж COMPANY. Более того, в лучшем случае при указании всего кортежа COMPANY системе будет повторно передана информация, которая ей уже известна, а в худшем - в случае ошибки пользователя при определении кортежа COMPANY в целом корректная операция INSERT выполнена не будет.

б) Предположим, что для переменной-отношения COMPANY необходимо реализовать правило ограничения удаления ON DELETE RESTRICT (т.е. запретить удаление объекта компании, если в этой компании работают какие-либо сотрудники). Допустим, что это правило может быть реализовано процедурным способом, скажем, с помощью метода М. (Обратите внимание, что переменная-отношение ЕМР не имеет внешнего ключа, к которому можно было бы подключить декларативную версию этого правила.) Более того, обычные операции DELETE языка SQL для переменной-отношения ЕМР не должны теперь выполняться иначе, чем посредством вызова метода М. Как обеспечить соблюдение этого требования? Аналогичные замечания и вопросы относятся, конечно, и к другим правилам внешних ключей, например к правилам ON DELETE CASCADE.

в) Также отметим, что при выполнении операции DELETE для кортежа ЕМР каскадное удаление соответствующего кортежа COMPANY, скорее всего, выполняться не будет, несмотря на видимость того, что он содержится внутри кортежа ЕМР.

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

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

Предположим, что определено представление V, которое является проекцией переменной-отношения ЕМР лишь по одному атрибуту HOBBIES. Представление V, конечно, также является переменной-отношением, но не базовой, а производной. Тогда, если уравнение переменная-отношение = класс верно, значит, представление V - также класс. А что такое класс? Классы имеют методы. Какие методы есть у представления V?

В рассматриваемом случае класс ЕМР имеет только один метод, а именно - RETIREMENT BENEFITS, который, очевидно, не применяется к классу V. Практически вряд ли было бы разумно, чтобы любые методы, которые применяются к классу ЕМР, применялись также к классу V. Тем более это касается всех остальных методов. Таким образом, получается, что никакие методы не могут применяться для результата выполнения операции проекции, т.е. каким бы ни был результат, он на самом деле не является классом. (Его можно так назвать, однако от этого он не станет классом, поскольку может иметь переменные экземпляра, но не может содержать методов, тогда как ранее отмечалось, что истинный инкапсулированный класс обладает методами, но не имеет открытых переменных экземпляра.)

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

И наконец чем же поддерживаются домены? Похоже, что защитникам уравнения переменная-отношение = класс нечего сказать о доменах, по-видимому, потому, что они не могут представить, как домены могут вписаться в их схему. Тем не менее, как неоднократно указывалось, домены - это фундаментальное понятие (см., например, главу 3).

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

Термин концептуальная целостность получил распространение благодаря Фреду Бруксу (Fred Brooks), который в [25.1] сказач следующее: [Концептуальная] целостность- это наиболее ба.жный вопрос в системном проектировании. Лучше не включить в систему определенные несо-в-иестимые боз.можности [и] отразить единый ряд проектных идей, че.м иметь систему, которая поддер.живает много полезных, но несвязанных и несогласованных идей . Спустя 20 лет он добавил: Цельный первоклассный програтшый продукт должен представлять... логически последовательную мысленную модель... [Концептуальная] целостность- наиболее ба,жный фактор для удобства в использовании... И сейчас я в этом убежден больше, чем когда бы то ни было. Концептуальная целостность - это основа для получения качественного продукта .