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

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

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

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

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

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

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

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

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

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

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

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

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

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

CREATE VIEW JOINEX AS

( ( EMP JOIN DEPT ) WHERE BUDGET > 7M ) [ EMPi, DEPTi ] ;

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

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

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

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

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

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

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

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

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

3.8. Транзакции

Замечание. Тему этого раздела нельзя отнести исключительно к теме реляционных систем. Тем не менее она здесь уместна, поскольку понимание основной идеи необходимо для усвоения некоторых аспектов материала и логичного перехода к части II. Однако здесь данная тема описывается лишь поверхностно.

В главе 1 указывалось, что транзакция - это логическая единица работы, обычно включающая несколько операций над базой данных. Также отмечалось, что пользователь должен иметь возможность указать системе, что отдельные операции являются частью одной транзакции. Для этого используются операции BEGIN TRANSACTION, COMMIT и ROLLBACK. Как правило, транзакция начинается при выполнении операции BEGIN TRANSACTION и прекращается при выполнении операции COMMIT или ROLLBACK, как в следующем примере, написанном на псевдокоде.

Следующая цитата из одной недавно вышедшей книги демонстрирует некоторые недоразумения, обсуждаемые здесь, а также недоразумения, которые обсуждались в разделе 3.3. Важно различать хранимые отношения, которые являются таблицами, и виртуальные отношения, которые являются представлениями... [Мы] будем использовать термин отношение только в тех случаях, когда вместо него можно использовать термин таблица или представление . Если необходимо будет подчеркнуть, что данное отношение является хранимым отношением, а не представлением, то в этом случае мы будем использовать термин базовое отношение или базовая таблица Подобные цитаты, к сожалению, - не редкость