Главная » SQL, Базы данных » Представления

0

Как отмечалось в главе 3, представление в реляционной модели, по  сути, является именованным выражением реляционной алгебры (либо конструкцией, эквивалентной выражению реляционной алгебры). Ниже  приведен пример на языке Tutorial D.

VAR GOOD_SUPPLIER VIEW

( S WHERE STATUS > 15 ) { S#, STATUS, CITY } ;

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

Рис. 10.1. Представление GOOD_SUPPLIER как заданный фрагмент базовой переменной отношения S (незатененные части таблицы)

В главе 3 было также показано, что любое представление, такое как GOOD_SUPPLIER, в некотором смысле можно считать просто окном для просмотра данных. Любые изменения, вносимые в исходную базовую таблицу, будут автоматически и мгновенно отображаться в представлении (как в окне), конечно, если они попадут в область, охваченную данным представлением. И наоборот, все  изменения, вносимые в представление, будут автоматически переноситься в данные исходной базовой таблицы, в результате чего станут видимыми1 и в самом представлении.

В  реальной  ситуации  многие  пользователи  могут  даже  не  предполагать,   что GOOD_SUPPLIER — это представление. Одни пользователи могут знать об этом, а также о том, что существует реальная переменная отношения S, тогда как другие будут искренне верить, что GOOD_SUPPLIERS — настоящая переменная отношения. Но, в любом случае, важнее всего то, что с представлением можно работать так, как будто оно действительно является настоящей переменной отношения. Приведем пример запроса к представлению

GOOD_SUPPLIER.

GOOD_SUPPLIER WHERE  CITY  ≠   ‘London’    ;

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

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

( ( S WHERE STATUS > 15 ) { "S#, STATUS, CITY } ) WHERE CITY Ф ‘London’ ;

1 Фактически могут возникать ситуации, при которых эти изменения окажутся невидимыми в SQL!

Эта тема рассматривается при обсуждении конструкции WITH CHECK OPTION в разделе 10.6.

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

( S WHERE STATUS > 15 AND CITY ‘London’ )

{ S#, STATUS, CITY } ;

Результат вычисления последнего выражения совпадает с приведенным выше результатом запроса к представлению.

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

подтверждающий фундаментальное значение реляционного свойства замкнутости.

Операции  обновления  на  представлениях  выполняются  аналогичным   образом.

Например, рассмотрим следующую операцию.

UPDATE GOOD_SUPPLIER WHERE CITY = ‘Paris’ { STATUS := STATUS + 10

} ;

При обработке она будет приведена к следующему виду.

UPDATE S WHERE STATUS > 15 AND CITY = ‘Paris’ { STATUS := STATUS +10 }

;

При использовании операций INSERT и DELETE применяется тот же подход..

Дополнительные примеры

Ниже приведены некоторые дополнительные примеры, на основании которых можно сделать важные выводы.

1.    .  VAR  REDPART VIEW

( Р WHERE COLOR = COLOR (‘Red’) ) { ALL BUT COLOR } RENAME WEIGHT AS WT ;

Представление REDPART — это проекция сокращения (в которой предусмотрено также  переименование  атрибутов),  применяемая  к  переменной  отношения  с данными о деталях. В нем присутствуют атрибуты Р#, PNAME, WT и CITY, и помещаются только те кортежи, которые описывают детали красного цвета.

2.    VAR  PQ  VIEW

SUMMARIZE SP PER P { P# } ADD SUM ( QTY ) AS TOTQTY ;

Представление PQ можно рассматривать как статистический итог или результат

обобщения данных исходной переменной отношения.

3.    VAR  CITY_PAIR VIEW

( ( S RENAME CITY AS SCITY ) JOIN SP JOIN

( P RENAME CITY AS PCITY ) ) { SCITY, PCITY } ;

В представлении CITY_PAIR выполняется соединение таблиц с данными  о  поставщиках, деталях и поставках по номерам поставщиков и номерам деталей, а затем проекция результатов по столбцам SNAME и PNAME.  Говоря неформально, в представлении CITY_PAIR пара имен городов (х,у) появляется в результате тогда и только тогда, когда поставщик, находящийся в городе х, поставляет детали, которые хранятся в городе у. Например, предположим, что поставщик si поставляет детали Р1; поставщик S1 находится в Лондоне и детали Р1 хранятся в Лондоне; в этом случае в представлении появляется пара (London,   London).

4.      VAR HEAVY_REDPART VIEW

REDPART WHERE WT > WEIGHT ( 12.0 ) ;

В этом примере показано, как одно представление определяется через другое.

Определение и удаление представлений

Синтаксис оператора определения представления на языке Tutorial D выглядит следующим образом.

VAR <relvar name> VIEW <relation exp> <candidate key def list> ;

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

<candidate key def list> может быть пустым (это равносильно тому, что  может быть опущена соответствующая спецификация), поскольку система  должна обладать

способностью определить потенциальные ключи представления самостоятельно  [3.3].

Например, в случае представления GOOD_SUPPLIER системе должно быть известно, что единственным потенциальным ключом, о котором может идти речь, является ключ {S#}, унаследованный от исходной базовой переменной отношения S.

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

Примечание. Некоторые определения представлений задают не отображение  уровня "внешний—концептуальный", а отображение уровня "внешний—внешний".  Представление HEAVY_REDPART из предыдущего раздела относится именно к такой категории представлений.

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

DROP VAR <relvar name>   ;

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

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

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

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

По теме:

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