Главная » SQL, Базы данных » ОБЛАСТЬ ПРИМЕНЕНИЯ ПРЕДСТАВЛЕНИЙ

0

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

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

Рассмотрим запрос "Определить все города, в которых хранятся детали, поставляемые некоторым поставщиком, находящимся в Лондоне". Требуемый запрос можно легко сформулировать с помощью представления 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

}

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

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

некоторые дополнительные затраты имеют место только на этапе развертывания представлений (как и в случае макросов).

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

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

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

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

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

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

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

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

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

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

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

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

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

Ни одна из указанных разновидностей роста не должна оказывать  какого-либо влияния на работу существующих пользователей или пользовательских программ, по крайней мере, в принципе (однако см. в этой связи пункт 6 упражнения 8.6.1, приведенного в главе 8, в котором рассматривается одна из проблем, возникающих при использовании конструкции "SELECT *" в языке SQL).

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

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

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

ill.

VAR ST BASE RELATION { S# S#, STATUS INTEGER

} KEY { S# } ;

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

VAR  S   VIEW

SNC   JOIN   ST   ;

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

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

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

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

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

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

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

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

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

■     определить S как базовую переменную отношения, a SNC и ST — как представле ния, являющиеся проекциями этой базовой переменной отношения; или

■     определить SNC и ST как базовые переменные отношения, a S —  как представле ние, являющееся соединением этих двух базовых переменных отношения3.

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

3 См. обсуждение декомпозиции без потерь в разделе 12.2 главы 12.

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

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

Источник: Дейт К. Дж., Введение в системы баз данных, 8-е издание.: Пер. с англ. — М.: Издательский дом «Вильямс», 2005. — 1328 с.: ил. — Парал. тит. англ.

По теме:

  • Комментарии