FROM SALESREPS WHERE REP OFFICE IN (11, 12, 13)

Это представление является обновляемым как по стандарту ANSI/ISO, так и в большинстве коммерческих СУБД. В него можно добавить информацию о новом служащем посредством инструкции insert:

INSERT INTO E?STRE?S (EMPL NUM, NAME, REP OFFICE, AGE, SALES) VALUES (113, Jake Kimball, 11, 43, 0.00)

СУБД добавит новую строку в исходную таблицу salesreps; она будет видна также в представлении eastreps. Но давайте посмотрим, что получится, если добавить строку для нового служащего с помощью следующей инструкции insert:

INSERT INTO EASTREPS (EMPL NUM, NAME, REP OFFICE, AGE, SALES) VALUES (114, Fred Roberts, 21, 47, 0.00)

Это полностью допустимая инструкция SQL, и СУБД произведет требуемое добавление в таблицу salesreps. Однако новая строка не удовлетворяет условию отбора для данного представления. Значение 21 в столбце rep office этой строки означает офис в Лос-Анджелесе, относящийся к западному региону. В результате, если сразу после инструкции insert выполнить запрос

SELECT EMPL NOM, NAME, REP OFFICE FROM EASTREPS

EMPL NUM NAME REP OFFICE

10.5 Bill Adams 13

109 Mary Jones 11

106 Sam Clark 11

104 Bob Smith 12

101 Dan Roberts 12

103 Paul Cruz 12

TO новая строка в нем будет отсутствовать. То же самое произойдет, если изменить идентификатор офиса у одного из служащих, включенных в представление. Данная инструкция update:

UPDATE EASTREPS

SET REP OFFICE = 21 WHERE EMPL NOM = 104

обновляет один из столбцов в строке Боба Смита (Bob Smith), что приводит к ее Немедленному исчезновению из представления. Конечно, обе исчезнувшие строки будут видны в запросе к исходной таблице:

SELECT EMPL NUM, NAME, REP OFFICE FROM SALESREPS

EMPL NOM NAME REP OFFICE

105 Bill Adams 13 109 Mary Jones 11 102 Sue Smith 21

106 Sam Clark 11

Tot факт, что в результате выполнения инструкции insert или update из представления исчезают строки, в лучшем случае вызывает замешательство. Вам, вероятно, захочется, чтобы СУБД обнаруживала такие инструкции и предотвращала их выполнение. SQL позволяет организовать этот вид контроля целостности представления путем создания представлений с режимом контроля. Данный режим задается в инструкции create view с помощью предложения with check option:

create view eastreps as select *

from salesreps where rep office in (11, 12, 13) with check option

Когда для представления установлен режим контроля, СУБД автоматически проверяет каждую операцию insert или update, выполняемую над представлением, чтобы удостовериться: полученные в результате строки удовлетворяют условиям отбора в определении представления. Если добавляемая или обновляемая строка не удовлетворяет этим условиям, то выполнение инструкции insert или update завершается ошибкой; другими словами, операция не выполняется.

Стандарт SQL2 позволяет также указывать параметр контроля: cascade или local. Этот параметр применим только к тем представлениям, в основе которых лежит не таблица базы данных, а другое представление. В основе этого, исходного, представления может лежать другое представление и т.д. Для каждого из представлений в такой цепочке может быть задан (или не задан) режим контроля. Если представление верхнего уровня создано с предложением with cascade check option, то любая попытка обновить такое представление вынудит СУБД просмотреть всю цепочку представлений нижнего уровня и проверить те из них, для которых задан режим контроля. Если же представление верхнего уровня создано с предложением with local check option, to СУБД офаничится проверкой только этого представления. Считается, что парамеф cascade установлен по умолчанию; его можно не указывать.

Из вышесказанного должно быть понятно, что введение режима конфоля приводит к значительным зафатам на выполнение инсфукций insert и update по отношению к многоуровневым представлениям. Тем не менее, он ифает важную роль в обеспечении целостности базы данных. Если обновляемое представление создается с целью повысить безопасность базы данных, то следует всегда задавать режим контроля. Тогда пользователь не сможет путем модификации представления воздействовать на данные, доступ к которым ему запрещен.

Удаление представления (инструкция DROP VIEW)

Вспомним, что в стандарте SQL1 язык определения данных (DDL) рассматривается как средство статического задания структуры базы данных, включающей таблицы и представления. По этой причине в стандарте SQL1 не предусмотрена возможность удаления представления, когда в нем больше нет необходимости. Однако во всех основных СУБД такая возможность существует. Поскольку представления подобны таблицам и не могут иметь совпадающие с ними имена, во многих СУБД для удаления представлений используется инструкция drop table. В других СУБД этой же цели служит отдельная инструкция drop view.

В стандарте SQL2 было формально закреплено использование инструкции drop view для удаления представлений. В нем также детализированы правила удаления представлений, на основе которых были созданы другие представления. Предположим, например, что были созданы два представления таблицы salesreps с помощью следующих инструкций create view:

CREATE VIEW EACTREPS AS SELECT *

FROM SALESREPS WHERE REP OFFICE IN (11, 12, 13)

CREATE VIEW NYREPS AS SELECT *

FROM EASTREPS WHERE REP OFFICE = 11

Для целей настоящего примера представление nyreps создано на основе представления eastreps, хотя его с таким же успехом можно было бы создать на основе исходной таблицы. Согласно стандарту SQL2, следующая инструкция drop view удалит из базы данных оба представления:

ЭРОР VIEW EASTREPS CASCADE

Параметр cascade означает, что СУБД должна удалить не только указанное в инструкции представление, но и все представления, созданные на его основе. В противоположность этому, следующая инструкция drop view:

DROP VIEW EASTREPS RESTRICT

выполнится с ошибкой, так как параметр restrict означает, что СУБД должна удалить представление только в том случае, если нет других представлений, созданных На его основе. Это служит дополнительной зашитой от случайных побочных эффектов при применении инструкции drop view. Стандарт SQL2 требует, чтобы в инструкции Drop view обязательно присутствовал или параметр restrict, или cascade, но в большинстве коммерческих СУБД используется инструкция drop view без каких-либо явно заданных параметров. Это сделано для поддержания обратной совместимости с теми продуктами, которые были выпущены до публикации стандарта SQL2. Работа инструкции drop view в таком случае зависит от СУБД.