7.4.1. Разработка пользовательских представлений (видов).

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

Как правило, представления создаются с помощью операторов языка SQL. Например, создадим представление для получения подробных сведений о персонале отделения с кодом 'B3'. Оно не будет включать сведения о зарплате, поскольку эти сведения должны быть доступны только руководителю отделения и только в отношении персонала, работающего в его отделении. Соответствующий SQL-оператор имеет такой вид:

CREATE VIEW staff3

AS SELECT sno, fname, Lname, address, tel_no, position, sex

FROM staff

WHERE bno = 'B3';

В результате будет создано представление с именем Staff3 (Сотрудник3), имеющее те же самые атрибуты, что и таблица Staff (Сотрудник), за исключением атрибутов DOB (Дата_рождения), Salary (Зарплата), NIN (ИНН) и Bno (Код_сотрудника). Пример сведений, содержащихся в данном представлении, приведен в таблице.

Чтобы гарантировать, что просматривать значения атрибута Salary (Зарплата) будет только руководитель отделения, доступ в базе данных к таблице Staff (Сотрудник) остальным членам персонала предоставляться не должен. Вместо этого им нужно предоставить право доступа к представлению Staff3 (Сотрудник3). Подобная мера предотвратит возможность доступа рядового работника к закрытым данным.

Таблица 7.1.

Содержимое представления Staff3.

Sno	FName	LName	Address	Tel_no	Position	Sex
SG37	Ann	Beech	81 George St, Glasgow PA1 2 JR	0141-848-3345	Snr Asst	F
SG14	David	Ford	63 AshbySt.Patrick,Glasgow	0141-339-2177	Deputy	M
SG5	Susan	Brand	5 Gt Western Rd, Glasgow	0141-334-2001	Manager	F

7.4.2. Определение прав доступа.

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

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

Привилегиями (или правами доступа) называются действия, которые пользователю разрешено выполнять в отношении конкретной таблицы или представления. Например, привилегия SELECT разрешает пользователю выбирать информацию из соответствующей таблицы. Когда пользователь создает таблицу с помощью оператора CREATE TABLE, он автоматически назначается владельцем созданного объекта и получает полный набор прав доступа к нему. Все остальные пользователи не имеют никаких прав доступа к созданному им объекту. Для предоставления прочим пользователям возможности доступа к новой таблице, ее владелец должен явно предоставить им необходимые привилегии с помощью оператора GRANT. Если в операторе GRANT будет указана фраза WITH GRANT OPTION, то пользователю-получателю дополнительно будет предоставлено право передавать данный тип привилегии другим пользователям по его собственному усмотрению. Любая предоставленная ранее привилегия может быть отменена с помощью оператора REVOKE.

Когда пользователь создает представление с помощью оператора CREATE VIEW, он автоматически становится его владельцем, но это вовсе не означает, что он получает полный набор прав доступа к нему. Чтобы создать новое представление, пользователь должен иметь привилегию SELECT для всех таблиц, входящих в его состав. Однако любые другие типы привилегий для вновь созданного представления пользователь получит только в том случае, если он имеет их для всех таблиц, входящих в состав данного представления.

Например, чтобы предоставить пользователю MANAGER (УПРАВЛЯЮЩИЙ) право выбора данных из таблицы Staff (Сотрудник), а также привилегии вставки, обновления и удаления данных из этой таблицы, нужно использовать следующий SQL-оператор:

GRANT ALL PRIVILEGES

ON staff

TO manager WITH GRANT OPTION;

В этом случае пользователь MANAGER (УПРАВЛЯЮЩИЙ) дополнительно сможет ссылаться на эту таблицу и все атрибуты в любых таблицах, которые он создаст впоследствии. В приведенном выше операторе присутствует фраза WITH GRANT OPTION, поэтому пользователь MANAGER (УПРАВЛЯЮЩИЙ) получает право передавать назначенные ему привилегии другим пользователям по своему собственному усмотрению. В следующем примере пользователю с идентификатором ADMIN дается привилегия SELECT для таблицы Staff (Сотрудник);

GRANT SELECT

ON staff

TO admin;

В данном случае фраза WITH GRANT OPTION опущена, поэтому пользователь ADMIN не сможет передавать полученные им права другим пользователям.