Программирование >>  Хронологические базы данных 

1 ... 104 105 106 [ 107 ] 108 109 110 ... 348


Глава

Представления

9.1. Введение

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

VAR GOOD SUPPLIER VIEW

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

Когда данный оператор выполняется, выражение реляционной алгебры (т.е. выражение определения представления) не вычисляется, а просто запоминается системой посредством его записи в каталог базы данных под указанным именем GOOD SUPPLIER. Тем не менее со стороны пользователя это выглядит так, как будто в базе данных существует реальная переменная-отношение GOOD SUPPLIER с собственными кортежами и атрибутами, показанными в незатененной части рис. 9.1 (имеется в виду, конечно, наш обычно используемый пример значений данных). Другими словами, имя GOOD SUPPLIERS обозначает производную (и виртуальную) переменную-отношение. Ее значение в любой момент представляет собой отношение, которое было бы получено в качестве результата в случае, если бы определяющее представление выражение было действительно вычислено в данный момент.

GOOD SUPPLIERS

SNAME

STATUS

CITY

Smith

London

Jones

Paris

Blake

Paris

Clark

London

Adams

Athens

Puc. 9.1. Представление GOOD SUPPLIER как заданный фрагмент базовой переменной-отношения S (незатененные части таблицы)

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



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

GOOD SUPPLIER WHERE CITY Ф London ;

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

STATUS

CITY

S3 S5

30 30

Paris Athens

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

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

WHERE CITY Ф London ;

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

( S WHERE STATUS > 15 AND CITY Ф London )

{ SI, STATUS, CITY } ;

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

В этой связи необходимо отметить, что процесс подстановки (т.е. процесс замены имени представления определяющим его выражением) выполняется корректно вследствие реляционного свойства замкнутости. Свойство замкнутости (кроме всего прочего) означает, что в любом месте выражения, где разрешено использовать имя переменной-отношения R, вместо него можно применять некоторое выражение X (естественно, предполагается, что в результате вычисления выражения X мы получим отношение того же типа, что и 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 присутствуют атрибуты P#, PNAME, WT и CITY. В него помешаются только те кортежи, которые описывают красные детали.

2. VAR PQ VIEW

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

В отличие от представлений GOOD SUPPLIER и REDPARTS, представление PQ не является простым подмножеством данных, получаемым посредством операции выборки или проекции некоторой базовой переменной-отношения. Это представление можно рассматривать как статистический итог или результат обобщения данных исходной переменной-отношения.

3. VAR CITY PAIR VIEW

( ( S RENAME CITY AS SCITY ) JOIN SP JOIN

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

Пара имен городов (x, у) появляется в представлении CITY PAIR тогда и только тогда, когда поставщик, находяшийся в городе х, поставляет детали, которые хранятся в городе у. Например, поставшик с номером S1 поставляет детали с номером Р1. При этом данный поставшик находится в Лондоне и поставляемые им детали хранятся также в Лондоне. В результате в представлении CITY PAIR будет присутствовать пара названий городов ( London, London).

4. VAR HEAVY REDPART VIEW

REDPART WHERE WT > WEIGHT ( 12.0 ) ;

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

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

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

VAR <иия переменной-отношениЯ> VIEW <реляционное выражение>

<список определения потенциальных ключей>;

В приведенном выражении параметр <список определения потенциальных ключей> может быть пустым, поскольку система должна уметь определять потенциальные ключи представления самостоятельно [10.6]. Например, в случае представления GOOD SUPPLIER системе должно быть известно, что единственным потенциальным ключом, о котором может идти речь, является ключ {S#}, унаследованный от исходной базовой переменной-отношения S.



1 ... 104 105 106 [ 107 ] 108 109 110 ... 348

© 2006 - 2024 pmbk.ru. Генерация страницы: 0
При копировании материалов приветствуются ссылки.
Яндекс.Метрика