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

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

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

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

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

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

( CITY PAIR WHERE SCITY = 'London' ) { PCITY }

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

( ( { 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 { St St, SNAME SNAME, CITY CHAR } PRIMARY KEY { Si } ;

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

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

VAR S VIEW

SNC JOIN ST ;

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

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

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

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

Два важных принципа

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

• Пользователь, который реально определяет некоторое представление V, безуслов­но, знаком с соответствующим выражением X, определяющим это представление. Он может использовать имя V везде, где применимо выражение X, причем, в сущ­ности, как мы уже убедились, это просто сокращенная запись данного выражения.

• Пользователь, которому просто известно, что представление V существует и его можно применять, чаще всего не знаком с выражением X, определяющим это представление. Для него представление V должно выглядеть и вести себя точно так, как базовая переменная-отношение.

' Это в принципе! К сожалению, современные продукты (и сам стандарт языка SQL) в целом некорректно поддерживают операции обработки данных представлений и, следовательно, эти программные продукты не обеспечивают в должной мере логической независимости от показан­ных в примере изменений. Говоря конкретнее, большинство программных продуктов (но не все) в настоящее время корректно поддерживает только операции выборки данных через представле­ния и, насколько известно автору, ни один из продуктов не поддерживает операций обновления данных в представлениях корректно на все 100%. Поэтому такие продукты обеспечивают логи­ческую независимость от структуры базы данных для операций выборки данных, но не для опе­раций обновления данных.

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

обсуждении вопросов "реструктуризации" в предыдущем разделе. Очевидно, что можно либо определить S как базовую переменную-отношение, a SNC и ST — как представления проекции этой базовой переменной-отношения, либо определить SNC и ST как базовые переменные-отношения, a S — как представление соединения этих двух базовых пере­менных-отношений². Отсюда следует, что не должно быть никаких предпочтений и никаких ненужных различий между базовыми и производными переменными-отношениями. Мы называем это утверждение принципом взаимозаменяемости базовых и производных переменных-отношений. Заметим в частности, что из этого принципа следует, что должна существовать возможность обновления представлений. Иначе говоря, возможности обновления базы данных не должны зависеть от произволь­ного по существу решения, каким переменным-отношениям быть базовыми, а каким — производными. Обсуждение этого вопроса будет продолжено в разделе 9.4.

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