В эпоху работы информационных ресурсов компаний в Интернете (а не только в локальных сетях) особенно остро встаёт вопрос о контроле доступа к базе данных. Проблема состоит из трёх самостоятельных частей:

1. Сокрытие от просмотра некоторых записей и защита от изменений некоторых записей
2. Сокрытие от просмотра некоторых столбцов и защита от изменений некоторых столбцов
3. Журнализация изменений

Вторая задача уже решена индустрией¹, решение третьей предложено². Таким образом, открытым остаётся только первый вопрос.

Важно понимать, что пользователь вносит в базу не отдельные записи, а целые графы. Графы разных пользователей (разных ролей) слабо пересекаются, таким образом все записи базы данных (из всех таблиц) распадаются на слабо взаимодействующие классы. Будем называть такие классы департаментами. Можно только указывать (оператором CREATE DEPARTMENT), что новое имя департамента введено или изъято (оператором DROP DEPARTMENT)³.

CREATE DEPARTMENT dp;

Резонно предоставить пользователю (роли) одинаковые права на все записи одного департамента, а имя департамента указывать в самих записях в поле специального типа LEGAL⁴.

CREATE TABLE a (..., a5 LEGAL, ...);
CREATE TABLE b (..., b7 LEGAL, ...);
INSERT INTO a VALUES (..., dp, ...);
INSERT INTO b VALUES (..., dp, ...);
BESTOW select ON dp FOR usr;
BESTOW update ON dp FOR rolename;

Изымать права на департамент будем другим оператором

VANISH select ON dp FOR usr;
VANISH update ON dp FOR rolename;

Если на какую-либо операцию с записью у пользователя нет прав, то запись для данного пользователя не существует: например, отсутствие права SELECT означает невидимость записи, отсутствие права UPDATE - что запись "read only". Само это поле доступно для изменения только тем, у кого есть право PUBLISH на департамент, которому принадлежит запись.

BESTOW publish ON dp FOR rolename;
VANISH publish ON dp FOR rolename;

Если в записи нет поля типа LEGAL или оно равно NULL, то пользователь имеет все права на эту запись. Для удобства пользователя (да и администрирования базы данных) при создании пользователя укажем, каким департаментом по умолчанию он метит все создаваемые и обновляемые данные. Этот департамент по умолчанию будем указывать в параметре TRACE.

CREATE USER usr1
IDENTIFIED BY pwd1
TRACE dp1;

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

Дмитрий ТЮРИН,
главный специалист департамента ЦАБС "АСБ Беларусбанк"

1 Делегированием полномочий на колонку

2 В каждой записи хранится время начала и конца её существования: при внесении записи начало устанавливается равным моменту создания, а конец - бесконечности; при удалении конец становится равным моменту удаления; при обновлении запись копируется, новая копия обновляется, конец существования старой копии и начало существования новой копии устанавливается равным моменту копирования, конец существования новой копии устанавливается равным бесконечности. Для полного контроля остаётся только добавить и автоматически заполнять два скрытых поля - идентификатор пользователя, создавшего запись, и идентификатор пользователя, удалившего запись

3 Изменять департаменты невозможно (ALTER DEPARTMENT), т.к. они не имеют никаких параметров

4 В записи может существовать только одно поле типа данных LEGAL