3.7. Базовые переменные-отношения и представления

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

, Замечание. В [3.3] базовые переменные-отношения называются реальными перемен- ными-отношениями.

Реляционные системы, очевидно, должны предоставлять средства для создания, в первую очередь, базовых переменных-отношений. В языке SQL, например, эта функция обеспечивается оператором CREATE TABLE (здесь слово TABLE используется в узком смысле, как базовая переменная-отношение). Базовые переменные-отношения, конечно же^ должны быть именованными, как, например, показано ниже.

CREATE TABLE ЕМР

Однако реляционные системы обычно поддерживают еще один вид именованных пе- ременных-отношений, называемых представлениями, В любой конкретный момент их значение является производным отношением (и поэтому упрощенно можно считать, что представление— это производная переменная-отношение). Значение данного пред- ставления в данное время является результатом вычисления определенного реляционно- го выражения в данный момент, а упомянутое реляционное выражение определяется в момент создания этого представления. Например, для определения представления ТОРЕМР можно использовать следующий оператор.

CREATE VIEW ТОРЕМР AS

{ ЕМР WHERE SALARY > ЗЗК ) { EMPt, ENAME, SALARY } ;

Замечание, Поскольку в данный момент это несущественно, в примере используется смешанная нотация языков SQL и Tutorial D.

Когда этот оператор выполняется, выражение, следующее за ключевым словом AS и фактически определяющее представление, не вычисляется, а просто запоминается системой (обычно посредством сохранения в каталоге под указанным именем ТОРЕМР). Однако, с точки зрения пользователя, все выглядит так, как будто в базе данных появи- лась вполне реальная переменная-отношение с именем ТОРЕМР, имеющая текущее значе- ние, которое показано на рис. 3.7 только в незатененных участках. И пользователь дол- жен иметь возможность оперировать этим представлением точно так, как если бы оно являлось обычной базовой переменной-отношением.

Замечание. Если, как мы уже отмечали, такие переменные-отношения, как DEPT и ЕМР, можно считать реальными, то переменную-отношение ТОРЕМР следует понимать как виртуальную переменную-отношение. Иначе говоря, как переменную-отношение, которая внешне существует как таковая, но на самом деле ее нет (значение этой пере- менной-отношения в любой данный момент зависит от значений некоторых других переменных-отношений).

ТОРЕМР

ЕМР#	ENAME	DEPT#	SALARY
Е1	Lopez	Dl	40K
Е2	Cheng	Dl	42K
ЕЗ	Finzi	D2	30K
Е4	Saito	D2	35K

Рис. 3.7. Виртуальная переменная-отношение ТОРЕМР (затененные участки) как пред- ставление базовой переменной-отношения ЕМР

Однако будьте внимательны: отмечая, что значение переменной-отношения ТОРЕМР является отношением, которое было бы результатом, если бы определяющее данное представление выражение было на самом деле вычислено, мы вовсе не хотим сказать, что существует отдельная копия этих данных. Иначе говоря, мы вовсе не имеем в виду, что определяющее представление выражение на самом деле вычисля- ется. Наоборот, представление — это, по сути, просто окно, через которое можно видеть часть значения базовой переменной-отношения ЕМР. Отсюда следует, что лю- бые изменения в базовой переменной-отношении будут автоматически и немедленно

видны в подобном окне (конечно, если эти изменения относятся к незатененной час- ти реальной переменной-отношения). Аналогично изменения, внесенные в пере- менную-отношение ТОРЕМР, будут автоматически и немедленно применены к реаль- ной переменной-отношению ЕМР и, следовательно, станут видны через это окно (примеры будут приведены позднее).

Ниже показан пример запроса, использующего представление ТОРЕМР.

( ТОРЕМР WHERE SALARY < 42К ) { EMPi, SALARY > Результат будет иметь следующий вид.

ЕМР#	SALARY
Е1 Е4	40К 35К

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

( ТОРЕМР WHERE SALARY < 42К ) { EMPi, SALARY }

модифицируется системой следующим образом.

{( ЕМР MERE SALARY > ЗЗК ) { EMPi, ENAME, SALARY } WHERE SALARY < 42K ) { EMPi, SALARY }

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

{ ЕМР WHERE SALARY > ЗЗК AND SALARY < 42К ) { EMPi, SALARY }

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

В качестве другого примера рассмотрим операцию удаления DELETE.

DELETE ТОРЕМР WHERE SALARY < 42К ;

На самом деле будет выполнена следующая операция. DELETE ЕМР WHERE SALARY > ЗЗК AND SALARY < 42К ;

Наше представление ТОРЕМР — очень простое представление, состоящее из под- множества строк и столбцов единственной базовой переменной-отношения. Однако, в принципе, определение представления может быть произвольной сложности. Напри- мер, вот представление, определение которого включает соединение двух базовых пе- ременных-отношений.

CREATE VIEW JOINEX AS

{ ( EMP JOIN DEPT ) WHERE BUDGET > 7M ) f EMPI, DEPTt ] ;

К вопросу определения и обработки представлений мы еще вернемся в главе 9.

Между прочим, сейчас уже можно объяснить приведенное в конце раздела 2.2 за- мечание относительно того, что термин представление (view) в реляционном контек- сте имеет особое специфическое значение, не совпадающее со значением, приписан- ным ему в архитектуре ANSI/SPARC. На внешнем уровне этой архитектуры база дан- ных воспринимается как "внешнее представление", определяемое внешней схемой (и разные пользователи могут иметь разные внешние представления). В реляционных системах, наоборот, представление, как пояснялось выше, является специально имено- ванной производной виртуальной переменной-отношением. Поэтому реляционным аналогом "внешнего представления" ANSI/SPARC обычно служит множество из не- скольких переменных-отношений, каждая из которых является представлением в ре- ляционном смысле. "Внешняя схема" состоит из определений таких представлений. (Отсюда следует, что представления в реляционном смысле являются способом обес- печения логической независимости данных, хотя еще раз следует отметить, что со- временные коммерческие продукты имеют серьезные недостатки в этом вопросе. (Подробности приводятся в главе 9.)

Архитектура ANSI/SPARC является достаточно общей и допускает произвольные из- менения между внешним и концептуальным уровнями. В принципе, даже типы структур данных, поддерживаемые на этих двух уровнях, могут быть различными: например, кон- цептуальный уровень может быть реляционным, тогда как конкретному пользователю может быть предоставлено внешнее представление иерархического типа. Однако на практике большинство систем использует одинаковые типы структур в качестве базовых на обоих уровнях. Реляционные продукты не являются исключением из этого общего правила — представление по-прежнему остается переменной-отношением, как и базовые переменные-отношения. А поскольку на обоих уровнях поддерживаются одинаковые ти- пы объектов, на этих уровнях применяется один и тот же подъязык данных (обычно это язык SQL). Действительно, тот факт, что представление— это тоже переменная- отношение, так же важен для реляционных систем, как для математики важно то, что подмножество также является множеством.

Замечание. Однако реальные SQL-продукты и сам стандарт языка SQL, похо- же, часто игнорируют этот момент (глава 4), поскольку нередко ссылаются на "таблицы и представления" (в том смысле, что представление не является табли- цей). Советуем не делать этой распространенной ошибки, используя термин "таб- лицы" (или "переменные-отношения") лишь для базовых таблиц (или "базовых пе- ременных-отношений").

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

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

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

Однако такая характеристика хотя и полезна в неформальном смысле, неточно отражает истинное положение дел. Действительно, пользователи могут представ- лять базовые переменные-отношения как физически хранимые, поскольку фактически главная цель создания реляционных систем состоит в том, чтобы позво- лить пользователю работать с базовыми переменными-отношениями как с физиче- ски существующими, не заботясь о том, как в действительности эти переменные- отношения физически представлены в памяти. Но (и это весьма существенное "но"!) подобное представление пользователей нельзя толковать так, что базовая перемен- ная-отношение — это непосредственно физически хранимая переменная-отношение (т.е. как единственный хранимый файл)⁴. Как пояснялось в разделе 2.2, базовые пе- ременные-отношения лучше всего представлять как абстракцию для некоторого на- бора хранимых данных — абстракцию, скрывающую все детали уровня хранения данных. В принципе, базовая переменная-отношение и ее хранимый эквивалент мо- гут отличаться в произвольной степени.

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