Обновление данных в представлениях

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

В стандарте ISO указано, что представления могут быть обновляемыми только в тех системах, которые отвечают некоторым четко определенным требованиям. Согласно стандарту ISO представление может быть обновляемым только в том случае, если:

• в его определении не используется ключевое слово DISTINCT, т.е. из результатов определяющего запроса не исключаются повторяющиеся строки;

• каждый элемент в списке конструкции SELECT определяющего запроса представляет собой имя столбца (а не константу, выражение или агрегирующую функцию), причем имя каждого из столбцов упоминается в этом списке не более одного раза;

• в конструкции FROM указана только одна таблица, т.е. представление должно быть создано на базе единственной таблицы, по отношению к которой пользователь должен обладать необходимыми правами доступа. Если исходная таблица сама является представлением, то это представление также должно отвечать указанным условиям. Данное требование исключает возможность обновления любых представлений, построенных на базе соединения, объединения (UNION), пересечения (INTERSECT) или разности (EXCEPT) таблиц;

• в конструкцию WHERE не входят какие-либо вложенные запросы типа SELECT, которые ссылаются на таблицу, указанную в конструкции FROM;

• определяющий запрос не должен содержать конструкций GROUP BY и HAVING.

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

Обновляемое представление. Для того чтобы представление было обновляемым, СУБД должна иметь возможность однозначно отобразить любую его строку или столбец на соответствующую строку или столбец его исходной таблицы.

Использование конструкции with check option

В представление помещаются только те строки, которые удовлетворяют условию WHERE в определяющем запросе. Если строка в представлении будет изменена таким образом, что перестанет удовлетворять этому условию, то эта строка должна исчезнуть из данного представления. Аналогичным образом, в представлении будут появляться новые строки всякий раз, когда вставка или обновление данных в представлении приведет к тому, что новые строки будут удовлетворять условию WHERE.

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

В общем случае для предотвращения миграции строк представления используется конструкция WITH CHECK OPTION оператора CREATE VIEW. Необязательные ключевые слова LOCAL/CASCADED применимы в случае существования иерархии представлений, т.е. когда представление создается на базе другого представления. Если указана конструкция WITH LOCAL CHECK OPTION, то такие действия, как вставка или обновление данных в некотором представлении, на базе которого прямо или косвенно определены другие представления, не могут вызвать исчезновение строки из данного представления, за исключением случаев, когда данная строка исчезает также из представлений или таблиц других уровней иерархии. При указании конструкции WITH CASCADED CHECK OPTION (это значение принимается по умолчанию) в случае вставки или обновления строки в данном представлении или в любом другом представлении, прямо или косвенно определенном на базе данного, исчезновение этой строки из данного представления не допускается.

Такая функция может оказаться настолько полезной, что работать с представлениями окажется удобнее, чем с таблицами базы данных. В том случае, когда оператор INSERT или UPDATE нарушает условия, указанные в конструкции WHERE определяющего запроса, выполнение затребованной операции отменяется. В результате появляется возможность реализовать в базе данных дополнительные ограничения, направленные на сохранение целостности данных. Следует отметить, что конструкцию WITH CHECK OPTION можно указывать только для обновляемых представлений.

Пример 7.2.7. Использование опции WITH CHECK OPTION

Еще раз обратимся к представлению, созданному в примере 7.2.3:

CREATE VIEW БаллСтудент

AS SELECT *

FROM Студент

WHERE СРБАЛЛ = '3,8';

WITH CHECK OPTION;

Содержимое этого представления приведено в табл. 7.2.3. Теперь попытаемся изменить значение среднего балла студента в любой из строк с '3,8' на '4' , например, с помощью следующего чего оператора:

UPDATE БаллСтудент

SET СРБАЛЛ = '4'

WHERE НС = '12';

Поскольку в определении представления была указана конструкция WITH CHECK OPTION, выполнение этого оператора будет заблокировано, так как в противном случае произойдет миграция строки из данного горизонтального представления. Таким образом, не будет иметь успеха и попытка выполнения следующего оператора:

INSERT INTO БаллСтудент

VALUES(13, 'ТЗ-31', 'Сушко А.', 1986, ' о.Сицилия ', 4 ) ;

Поскольку в определении представления указана конструкция WITH CHECK OPTION, ввод указанной строки в данное представление будет заблокирован, так как сразу после помещения ее в исходную таблицу Студент она должна будет немедленно исчезнуть из данного представления.

А теперь рассмотрим ситуацию, когда представление БаллСтудент создается не на базе самой таблицы Студент, а на базе другого представления, созданного для этой таблицы.

CREATE VIEW МладшийСт CREATE VIEW СтаршийСт

AS SELECT * AS SELECT *

FROM Студент FROM МладшийСт

WHERE ГОДР > 1983; WHERE ГОДР > 1985

WITH LOCAL CHECK OPTION;,

CREATE VIEW БаллСтудент

AS SELECT *

FROM СтаршийСт

WHERE СРБАЛЛ = '3,8' ;

Теперь попытаемся выполнить в представлении БаллСтудент следующий оператор:

UPDATE Managers Staff

SET ГОДР = 1984

WHERE НС = '12';

Однако это нам не удастся. Дело в том, что после выполнения данного оператора измененная строка исчезнет только из представления СтаршийСт, но сохранится в представлении МладшийСт, на базе которого сформировано представление СтаршийСт. Если же при обновлении установить новое значение года рождения, равным 1986, то эта операция будет успешной, поскольку измененная строка должна будет исчезнуть и из представления МладшийСт. Если же при определении представления СтаршийСт указать конструкцию WITH CASCADED CHECK OPTION, то при указании любого из упомянутых значений года рождения (как 1984, так и 1986) выполнение данного обновления будет заблокировано, поскольку измененная строка должна будет исчезнуть из представления СтаршийСт. Следовательно, для того чтобы получить гарантию, что подобные аномалии обновления никогда не будут иметь места, каждое из создаваемых представлений должно содержать конструкцию WITH CASCADED CHECK OPTION.