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

Поддержка представлений желательна по нескольким причинам, но, возможно, самая важная из них — обеспечение логической независимости данных. Это понятие не следует путать с понятием физической независимости данных, описанным ниже в этой главе. Система обеспечивает физическую независимость данных, если пользо­ватели и пользовательские программы не зависят от изменений в физической струк­туре базы данных. Система обеспечивает логическую независимость данных, если пользователи и пользовательские программы также не зависят и от изменений в логи­ческой структуре базы данных. С последним утверждением связаны два интересных аспекта — рост и реструктуризация базы данных.

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

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

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

• Расширение существующего базового отношения с целью включения нового ат­рибута. Новый атрибут соответствует внесению новой информации, относящей­ся к объектам определенного типа. Например, добавление атрибута DISCOUNT (скидка) в базовое отношение, которое содержит информацию о поставщиках. (Следует заметить, что здесь используется не совсем точная терминология. Как описано в главе 4, отношение нельзя расширить и включить в него новый атри­бут. Говоря о расширении отношения, здесь имеют в виду замену одного отно­шения другим с тем же именем и дополнительным атрибутом, который требова­лось вставить.)

• Создание нового базового отношения, соответствующее добавлению в базу дан­ных информации об объектах нового типа.

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

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

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

SNC ( S#, SNAМЕ, CITY )

PRIMARY KEY ( S# )

ST ( S#, STATUS )

PRIMARY KEY ( S# )

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

CREATE VIEW S AS SNC JOIN ST ;

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

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

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

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

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

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

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

•Представления обеспечивают пользователей механизмом сокращений, или "макросов".

Рассмотрим запрос "Получить все города, в которых хранятся детали, поставляе­мые поставщиком из Лондона". Ниже в этой главе приводится пример определе­ния представления CITY_PAIRS (пары городов) с атрибутами SCTY и PCITY та­ким образом, чтобы пары имен городов {SCITY:x, PCITY:y} появлялись в пред­ставлении тогда и только тогда, когда поставщик, находящийся в городе х, по­ставляет детали, которые хранятся в городе у. Представление CITY_PAIRS позво­ляет записать сформулированный выше запрос в следующем виде:

( CITY_PAIRS WHERE SCITY = 'London' ) [ PCITY ]

He используя представление, этот запрос определить значительно сложнее:

( ( ( S RENAME CITY AS SCITY )

JOIN SP

JOIN ( P RENAME CITY AS PCITY ) )

WHERE SCITY = 'London' ) [ PCITY ]

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

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

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

Под "скрытыми данными" здесь понимают данные, которые не видны в опреде­ленном представлении. Таким образом, пользователи вынуждены получать доступ к базе данных через представления; это простой и эффективный механизм контро­ля доступа и аутентификации. Эта тема уже обсуждалась в главе 15.