РУКОВОДСТВО ПО РЕЛЯЦИОННОЙ СУБД DB2

              

ПРЕДСТАВЛЕНИЯ И БЕЗОПАСНОСТЬ - часть 3


SELECT) рейтингов, т. е. значений состояния, для всех поставщиков, а обновлять их (операция UPDATE) разрешается только для поставщиков из Парижа. Тогда потребуется два следующих представления:

CREATE

VIEW

ВСЕ_РЕЙТИНГИ

CREATE

VIEW

ПАРИЖСКИЕ_

РЕЙТИНГИ

AS

SELECT

НОМЕР_

ПОСТАВЩИКА, СОСТОЯНИЕ

AS

SELECT

НОМЕР_

ПОСТАВЩИКА, СОСТОЯНИЕ

FROM

S;

FROM

S

WHERE

ГОРОД=' ПАРИЖ';

При этом операции

SELECT могут быть адресованы представлению ВСЕ_РЕЙТИНГИ, а операции обновления — только представлению ПАРИЖСКИЕ_РЕЙТИНГИ. В связи с этим программирование становится довольно невразумительным. В этом можно, например, убедиться, рассматривая структуру программы, которая просматривает и печатает рейтинги всех поставщиков, а также обновляет некоторые из них (рейтинги поставщиков из Парижа), когда это требуется.

Другой недостаток связан с тем, что при вставке (операция INSERT) или обновлении (операция UPDATE) записей при помощи представления система DB2 не требует, чтобы новая или обновленная запись удовлетворяла предикату, определяющему это представление. Такое требование можно ввести с помощью спецификации CHECK, но эта возможность, как пояснялось в главе 8, не всегда может быть использована и во всяком случае это факультативная возможность — пользователь не обязан

ее специфицировать. Таким образом, приведенное выше представление ПАРИЖСКИЕ_ПОСТАВЩИКИ, например, может не дать пользователю возможности видеть поставщиков, которые находятся не в Париже, но при отсутствии спецификации CHECK оно не может помешать пользователю создать такого поставщика или переместить какого-либо существующего парижского поставщика в некоторый другой город. Такая операция, конечно, приведет к тому, что новая или обновленная запись немедленно исчезнет из этого представления, но она однако же появится в соответствующей базовой таблице.




Содержание  Назад  Вперед