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

Замечание. Некоторые определения представлений задают не отображение уровня внешний-концептуальный , а отображение уровня внешний-внешний . Представление HEAVY REDPART из предыдушего раздела относится именно к такой категории представлений.

Синтаксис оператора удаления представления имеет следующий вид.

DROP VAR <имя переменной-отношении ;

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

Замечание. Стандартная версия языка SQL не поддерживает подобной опции в операторе определения представления, однако она включена в оператор DROP. Также не оговорено, какое значение опции будет использоваться по умолчанию; требуется явно указывать одно из значений опции (см. раздел 9.6).

9.2. Для чего нужны представления

Поддержка представлений желательна по многим причинам. Укажем некоторые из них.

Обеспечивается автоматическая защита скрытых данных

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

Пользователям предоставляются средства сокращенной записи или .макросы

Рассмотрим запрос Определить все города, в которых хранятся детали, поставляемые некоторым поставщиком из Лондона . Требуемый запрос можно легко сформулировать с помощью представления CITY PAIR (пары городов), определенного в предыдущем разделе.

( CITY PAIR WHERE SCITY = London ) { PCITY } Глава 9. Представления 353

Сформулировать данный запрос, не пользуясь этим представлением, будет сложнее.

( ( ( S RENAME CITY AS SCITY ) JOIN SP

JOIN ( P RENAME CITY AS PCITY ) )

WHERE SCITY = London ) { PCITY }

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

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

Представления позволяют разным пользователям различным образом видеть одни и те же данные в одно и то же время

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

Представления способны обеспечивать логическую независимость данных

Это одна из важнейших потенциальных возможностей представлений, поэтому мы рассмотрим ее отдельно в следующем разделе.

Логическая независимость данных

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

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

Замечание. Аспект роста здесь обсуждается только для полноты изложения. Он достаточно важен, но его связь с представлениями весьма относительна.

Рост базы данных

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

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

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

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

Реструктуризация базы данных

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

VAR SNC BASE RELATION { S# S#, SNAME SNAME, CITY CHAR } PRIMARY KEY { S# } ;

VAR ST BASE RELATION { S# S#, STATUS INTEGER } PRIMARY KEY { S# } ;

Здесь существенно то, что прежняя переменная-отношение S является соединением двух новых переменных-отношений SNC и ST (а переменные-отношения SNC и ST являются проекциями старой переменной-отношения S). Следовательно, можно создать представление, которое будет предусматривать выполнение указанного соединения, и присвоить ему имя S.

VAR S VIEW

SNC JOIN ST ;

Любая прикладная программа или интерактивная операция, в которой использовалась прежняя переменная-отношение S, теперь будет ссылаться на представление S. Следовательно, если предположить, что система корректно поддержива-