Базы Данных - Сибилев, 2007

251

Однако это только гипотеза. А что делать с остальными тремя элементами?

Игнорировать? Но пользователь наверняка имел в виду совсем не такие

«обновления». Возможно, он хотел поместить в отчёт дополнительную строку.

Пользователь, не зная, что имеет дело с представлением, а не с базо-

вой таблицей, может попытаться удалить все строки:

DELETE FROM REPORT;

Этот оператор имеет вполне логичную интерпретацию в терминах базовых таблиц:

DELETE FROM SPJ;

DELETE FROM P;

«Таблица» REPORT будет очищена, но последствия такой «чистки»,

скорее всего, окажутся катастрофическими для других пользователей.

Существуют и такие типы представлений, при обновлении которых не возникает запутанных или неразрешимых проблем. Примером может служить представление S_LOWER (п. 7.4.1, пример 1). В самом деле, лю-

бой оператор обновления этого представления имеет единственную интер-

претацию в терминах операций обновления таблицы S. Например,

UPDATE S_LOWER

SET Sname = ‘Игорь’, St = 40, Ci = ‘Яя’

WHERE Snum = ‘S8’;

однозначно интерпретируется как

UPDATE S

SET Sname = ‘Игорь’, St = 40, Ci = ‘Яя’

WHERE Snum = ‘S8’;

Аналогичные интерпретации существуют и для операций встав-

ки/удаления строк представления.

Рассмотренные примеры показывают, что существует два типа пред-

ставлений: обновляемые и необновляемые или только для чтения. На об-

новляемые представления можно ссылаться в операторах обновления как

252

на приёмники данных. Исполняющая система преобразует оператор, со-

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

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

Приведённые примеры являются крайними. Представление

S_LOWER может использоваться для обновления так же, как базовая таб-

лица, а REPORT вообще не пригодно для обновления данных. Между эти-

ми двумя крайностями существует много обновляемых представлений, бо-

лее сложных, чем S_LOWER и необновляемых, устроенных значительно проще, чем REPORT. Кроме того, представления могут быть обновляемы-

ми без ограничений, как S_LOWER, или частично обновляемыми. К этим последним применимы не все операции обновления. Проблема обновляе-

мости представлений – это сложнейшая и интереснейшая проблема теории баз данных. Многие важные с практической точки зрения результаты тео-

рии обновляемости представлений можно найти в [Ошибка! Источник ссылки не найден., гл. 17]. К сожалению, современный SQL не использу-

ет эти результаты. Приведём определение обновляемого представления,

соответствующее стандарту SQL2.

Представление является обновляемым, если определяющий его за-

прос удовлетворяет всем перечисленным ниже требованиям.

■ Предложение FROM запроса ссылается на одну и только одну ба-

зовую таблицу или представление.

■ Если ссылка ведёт на представление, то оно является обновляе-

мым и не ссылается прямо или косвенно на определяемое представление.

■ В предложении SELECT запроса используются только ссылки на столбцы источника данных. Выражения и агрегатные функции не допус-

каются. Ни на один столбец нельзя ссылаться более одного раза.

■ Предложение SELECT запроса не содержит спецификации

253

DISTINCT.

■ Подзапрос в предикате предложения WHERE запроса не содер-

жит прямых или косвенных ссылок на определяемое представление.32

■Запрос не содержит предложения GROUP BY или HAVING.

■Запрос не использует операторы UNION, EXCEPT, INTERSECT.

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

можно использовать как приёмник данных в операторах обновления.

Это очень жёсткие ограничения. Очень многие теоретически обнов-

ляемые представления им не удовлетворяют. Поэтому разработчики про-

мышленных СУБД часто обходят эти требования, расширяя стандартное множество обновляемых представлений. Узнать правила обновления пред-

ставлений, действующие в конкретной СУБД, можно только из техниче-

ской документации.

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

Пример 1. Определим представление S_LOWER (п. 7.4.1, пример 1)

так:

CREATE VIEW S_LOWER

AS SELECT *

FROM S

WHERE St < 50;

Согласно стандарту оно обновляемо. Добавим в него две строки:

INSERT INTO S_LOWER

VALUES (‘S10’, ‘Алексей’, 30, ‘Шегарка’),

(‘S11’, ‘Кузьма’, 400, ‘Бакчар’);

Этот оператор будет исполнен как

INSERT INTO S

VALUES (‘S10’, ‘Алексей’, 30, ‘Шегарка’),

255

Для того чтобы уберечь пользователя хотя бы от некоторых неожи-

данностей, настоятельно рекомендуется использовать параметр WITH CHECK OPTION в определениях обновляемых представлений, хотя стан-

дарт этого и не требует.

Пример 2. Рассмотрим представление, отображающее только сведения о поставщиках из Томска:

CREATE VIEW S_TOMSK

AS SELECT Snum, Snam, St

FROM S

WHERE Ci = ‘Томск’

WITH CHECK OPTION;

Это обновляемое представление, поэтому параметр WITH CHECK OPTION использован правомерно. Однако, если пользователь попытается добавить в него новую строку:

INSERT INTO S_TOMSK

VALUES (‘S10’, ‘Алексей’, 30);

система преобразует этот оператор так:

INSERT INTO S

VALUES (‘S10’, ‘Алексей’, 30);

Затем она вычислит на вводимой строке значение предиката, и операция не будет выполнена, если (совершенно случайно) в определении таблицы S

для столбца Ci значение ‘Томск’не задано по умолчанию.

Таким образом, параметр WITH CHECK OPTION фактически за-

прещает вставку строк в это представление. Однако, если его убрать из оп-

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

ность складывать мусор в базу данных. Если мы хотим запретить пользо-

вателю представления S_TOMSK добавлять строки в базовую таблицу, то приведённое выше определение и есть реализация запрета.

256

Пример 3. Пусть некоторому пользователю запрещён доступ к ко-

дам поставщиков, а прочие сведения о них он может использовать. Для не-

го создано следующее представление:

CREATE VIEW SUPPL AS SELECT Snam, St, Ci FROM S;

Оно обновляемо по определению, но операция вставки строк в него фактически запрещена, т.к. первичный ключ базовой таблицы не включён в список столбцов.

Примеры подобных нюансов обновления представлений можно множить и множить, однако уже приведённых достаточно, чтобы сделать два вывода. Во-первых, обновляемые представления – это хорошее средст-

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

дует конструировать очень внимательно, анализируя все возможные вари-

анты обновлений.

7.5 Операторы управления доступом

7.5.1 Основные принципы

Стандарты SQL поддерживают избирательный подход к управлению доступом (см. п. Ошибка! Источник ссылки не найден.). Согласно

SQL2, объектами защиты являются базовые таблицы, представления, до-

мены, определённые пользователями наборы символов, трансляции и сравнения (см. п. 7.1.12).

Пользователь с идентификатором _SYSTEM (Администратор базы данных) автоматически получает все системные и объектные привилегии.

Ему принадлежат права регистрации пользователей, создания объектов и наделения других ID любыми объектными и некоторыми системными привилегиями. В частности, пользователь _SYSTEM может предоставить любому ID право создания схемы.

Пользователь, создавший схему, является её владельцем и имеет все объектные привилегии внутри схемы. Другие пользователи не имеют ни-

258

привилегия ::= SELECT | DELETE

| { INSERT [ (имя_столбца.,..) ] }

| { UPDATE [ (имя_столбца.,..) ] }

| { REFERENCES [ (имя_столбца.,..) ] }

| USAGE

имя_объекта ::= [ TABLE ] имя_таблицы

| DOMAIN имя_домена

| COLLATION имя_сравнения

| CHARACTER SET имя_набора_символов

| TRANSLATION имя_трансляции

Оператор создаёт дескрипторы привилегий. Его исполнение гаран-

тирует, что все указанные ID получат право выполнять все указанные опе-

рации с указанным объектом. Предоставитель должен не только сам обла-

дать предоставляемыми привилегиями, но и иметь право на их предостав-

ление. Владелец схемы получает его автоматически и может предоставить другому пользователю, указав параметр WITH GRANT OPTION в опера-

торе GRANT.

Привилегия USAGE (использование) предоставляется для всех типов объектов, кроме таблиц. Остальные привилегии нужны только для работы с таблицами.

Привилегии SELECT, DELETE, INSERT, UPDATE предоставляют права на выполнение одноимённых операций с таблицей. Привилегия

REFERENCES означает право использования таблицы для ссылок в определениях ограничений. Привилегии INSERT, UPDATE, REFERENCES могут быть предоставлены на отдельные столбцы таблицы. По умолчанию они предоставляются на все столбцы таблицы, на которые предоставитель имеет право давать привилегии.

Привилегия USAGE предоставляет право использования объекта для определения других объектов, например, домена в определении таблицы.

260

Привилегии могут быть отменены только предоставителем. Если указан параметр GRANT OPTION FOR, то отменяется только право пере-

дачи привилегий. В противном случае привилегии безусловно теряются.

Параметры CASCADE и RESTRICT указывают порядок отмены на-

следуемых привилегий. Если определены параметры CASCADE и GRANT OPTION FOR, то привилегии сохраняются за указанным ID, но становятся непредоставляемыми. Отменяются все прямо зависящие от них привилегии и удаляются все объекты, существование которых связано с отменяемыми привилегиями. Например, если в определении столбца таб-

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

USAGE, то таблица будет удалена.

Если определён параметр RESTRICT, то каскадные отмены приви-

легий и удаление объектов не выполняются.

Пример.

REVOKE GRANT OPTION FOR UPDATE (St) ON S FROM Lump

CASCADE;

Пользователь Lump сохранит привилегию обновления столбца St

таблицы S, но потеряет право передачи этой привилегии другим ID. Все полученные от Lump привилегии обновления этого столбца будут отмене-

ны.

Следует отметить, что возможность распространения права передачи привилегий может приводить к довольно запутанным ситуациям. Так,

пусть ID1 – владелец объекта A – предоставил одну и ту же привилегию на объект пользователю ID2 – с правом передачи, а ID3 – без такого права

(рис. 5.5). ID2 также передал эту привилегию ID3, но уже с правом переда-

чи, которым ID3 и воспользовался, передав привилегию ID4. Что произой-

дёт, если теперь ID1 лишит ID3 предоставленной им привилегии? Сохра-

нится ли за ID3 привилегия, которую предоставил ID2? Сохранится ли за

ID4 привилегия, которую ему предоставил “лишенец”?