Нам не всегда желательна инкапсуляция
Еще одна причина, которая заставляет автора считать инкапсуляцию не настолько важным понятием, как это полагается в литературе, состоит в следующем. Некоторые типы являются совсем не инкапсулированными, и это никому не мешает! В частности, это относится к "генерируемым" типам, которые определяются с использованием генераторов типов, такие как ARRAY, LIST, TUPLE и RELATION. Рассмотрим для определенности RELATION. Предположим, что теперь мы имеем дело с relvar (relation variable) POINT:
VAR POINT ... RELATION { X ..., Y ... } ... ; /* для простоты типы атрибутов X и Y опущены */
Замечание: Определение сформулировано на языке Tutorial D, который определен в Third Manifesto для иллюстративных целей. Многоточия в определении поставлено вместо конструкций, не являющихся существенными для этого обсуждения.
В этом определении для указании (генерируемого) типа relvar используется генератор типов RELATION; это конкретный тип отношения, а именно:
RELATION { X ..., Y ... } /* снова для простоты типы атрибутов X и Y опущены */
И этот тип определенно не является инкапсулированным: у него имеются видимые пользователям компоненты - атрибуты X и Y. И именно наличие этих видимых пользователям компонентов позволяет выполнять над relvar POINT непредвиденные запросы; например, можно выполнить проецирование на атрибут Y, ограничение по условию "значение Y меньше пяти".
Заметим мимоходом, что похожие наблюдение содержатся в книге Mike Stonebraker про объектно-реляционные СУБД: "Базовые типы полностью инкапсулированы. Единственный способ манипулировать [экземпляром] базового типа состоит в том, чтобы выбрать его и выполнить функцию, принимающую [экземпляр этого типа] в качестве аргумента. В противоположность этому, составные типы полностью прозрачны. Можно видеть все поля, и они легко доступны в языке запросов. Конечно, промежуточная позиция заключается в том, чтобы допустить в составном объекте наличие публичных (видимых) полей и приватных (инкапсулированных). Этот подход используется в Си++". Однако следует добавить, что остается неясным, проводит ли Стоунбрейкер четкое различие между реальными и возможными представлениями, как это делается в The Third Manifesto.
Вернемся к основному аргументу. Тот факт, что типы отношений не искапсулированы, не означает потерю независимости данных! Например, в случае relvar POINT нет абсолютно никаких причин, по которым нельзя было бы физически представить эту relvar полярными координатами R и U, а не декартовыми координатами X и Y. (Вероятно, это невозможно сделать в сегодняшних продуктах SQL, но это недостаток продуктов. Сегодняшние продукты SQL вообще обеспечивают меньшую независимость данных, чем теоретически в состоянии обеспечить реляционная технология.) Другими словами, даже при использовании не инкапсулированных типов требуется четко различать типы и представления, и "отказ от инкапсуляции" не обязательно ведет к разрушению независимости данных.
