Обновление представлений в коммерческих СУБД

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

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

Контроль над обновлением представлений (предложение WITH CHECK OPTION)

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

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

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

В СУБД имеются механизмы обнаружения таких инструкций и предотвращения их выполнение. SQL позволяет организовать этот вид контроля целостности представления путем создания представлений с режимом контроля. Данный режим задается в инструкции create view с помощью предложения with CHECK OPTION:

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

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

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