3.7. Базовые таблицы и представления

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

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

Например, инструкцию

CREATE VIEW TOPEMPS AS ( EMP WHERE SALARY > 33K ) [ EMP#, ENAME, SALARY ] ;

можно использовать для определения представления TOPEMPS. Когда эта инструкция выполняется, выражение, следующее за ключевым словом as и фактически определяющее представление, не вычисляется, а просто "запоминается" системой (обычно путем сохра­нения в каталоге под указанным именем TOPEMPS). Однако для пользователя это теперь такая же реальная таблица базы данных с именем TOPEMPS, со строками и столбцами, как и показанная на рис. 3.5, но только в незатемненных участках. Иными словами, имя TOPEMPS обозначает виртуальную таблицу, т.е. таблицу, которая была бы результатом, если бы выражение, определяющее представление, было на самом деле вычислено.

TOPEMPS

EMP#	ENAME	DEPT#	SALARY
E1 E2 E3 E4	Lopez Cheng Finzi Saito	D1 D1 D2 D2	40K 42K 30K 35K

Рис. 3.5. TOPEMPS как представление базовой таблицы EMP (незатемненные участки)

Однако будьте внимательны: отмечая, что имя TOPEMPS обозначает "таблицу, которая была бы результатом, если бы выражение, определяющее представление, бы­ло на самом деле вычислено", мы вовсе не хотим сказать, что она ссылается на от­дельную копию данных, т.е. мы не имеем в виду, что выражение, определяющее представление, на самом деле вычисляется. Наоборот, представление — это просто "окно" в основной таблице EMP. Более того, естественно, что любые изменения в ос­новной таблице будут автоматически и немедленно видны через такое "окно" (конечно, если эти изменения относятся к незатемненной части таблицы EMP); ана­логично, изменения в TOPEMPS будут автоматически и немедленно применены к ре­альной таблице EMP и, следовательно, будут видны через "окно".

Ниже показан пример запроса, использующего представление TOPEMPS:

( TOPEMPS WHERE SALARY < 42K ) [ ЕМР#, SALARY ]

Результат будет выглядеть подобно следующему:

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

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

( TOPEMPS WHERE SALARY < 42K ) [ ЕМР#, SALARY ]

модифицируется системой к виду

(((EMP WHERE SALARY > 33K ) [ ЕМР#, ENAME, SALARY ] )

WHERE SALARY < 42K ) [ EMP#, SALARY ]

После определенного количества перегруппировок это выражение упрощается и при­нимает следующий вид:

( ЕМР WHERE SALARY > ЗЗК AND SALARY < 42К ) [ ЕМР#, SALARY ]

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

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

CREATE VIEW JOINEXl AS ( ( ЕМР JOIN DEPT ) WHERE BUDGET > 7M ) [ EMP#, DEPT# ] ;

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

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

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

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

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

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

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

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

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