Привилегии уровня таблицы находятся в таблице systabauth, в которой используется составной первичный ключ, включающий номер таблицы, идентификатор пользователя, предоставившего привилегии на таблицу и идентификатор пользователя, получившего их. В столбце tabauth привилегии закодированы в виде шестибуквенного списка следующим образом (дефис обозначает не предоставленную привилегию):
s – SELECT
u – UPDATE
- – * привилегия на столбцы
i – INSERT
d – DELETE
x – INDEX
a – ALTER
r – REFERENCES (обращение к заданной таблице в ограничениях целостности)
Таким образом, полный комплект привилегий выглядит какsu-idxar.
Например, набор -u------ говорит, что пользователь обладает только привилегией UPDATE.
Если в третьей позиции присутствует звездочка, то это означает, что для данной таблицы и пользователя существуют еще какие-то привилегии уровня столбца. Конкретные привилегии регистрируются в таблице syscolauth. Ее первичный ключ составлен из номера таблицы, идентификатора пользователя, предоставившего привилегии, получившего привилегии, и номера столбца. Единственный атрибут – двухбуквенный список, показывающий тип привилегии: s-, -u или su.
Привилегии и представления
При создании представления ядро БД проверяет привилегии пользователя на соответствующие таблицы и представления. При использовании же представлений проверяются только привилегии на само представление.
Привилегии при создании представления
При создании представления ядро БД проверяет наличие у пользователя всех привилегий, необходимых для выполнения оператора SELECT в определении представления. Если таких привилегий нет, представление не создается. Эта проверка не позволяет пользователю получить несанкционированный доступ к таблице путем создания представления для нее и обращения к представлению. После создания представления ядро БД предоставляет его создателю и владельцу, как минимум, привилегию SELECT для этого представления. Оно не становится автоматически общедоступным, как это происходит с таблицей. Ядро БД определяет определение представления и выясняет, является ли оно обновляемым. Если да, то создатель представления получает привилегии INSERT, DELETE и UPDATE для этого представления при наличии этих привилегий на порождающей таблице или представлении. Иными словами, если создаваемое представление является обновляемым, то ядро БД копирует привилегии INSERT, DELETE и UPDATE создателя представления и предоставляет их ему на новом представлении. Если для порождающей таблицы создатель представления располагает только привилегией INSERT, то он получит на представление только эту привилегию и т.д. Эта проверка не позволяет пользователям получить какие-либо привилегии кроме тех, которые у него уже есть.
Поскольку для представления нельзя выполнять операторы ALTER TABLE и CREATE INDEX, привилегии ALTER и INDEX никогда не распространяются на представления.
Привилегии при использовании представления
При попытке использовать представление, ядро БД проверяет лишь те привилегии, которые относятся лишь к самому представлению. Оно не проверяет права на доступ к определяющим его таблицам. Привилегии создателя представления уже отмечались ранее. Для других пользователей привилегии определяются создателем или тем, у кого есть привилегия WITH GRANT OPTION. Это означает, что можно создать таблицу и отменить ее общедоступность. Затем можно предоставить ограниченные привилегии на доступ к таблице через представления.
Ниже приводится синтаксис оператора GRANT:
GRANT список_привилегий_через_запятую ON объект
TO список_пользователей_через_запятую [WITH GRANT OPTION]
Директива WITH GRANT OPTION наделяет указанных пользователей особыми полномочиями – правом предоставления полномочий другим пользователям. Это означает, что для работы с данным объектом они могут наделять полномочиями других пользователей.
Работу с представлениями можно продемонстрировать на примерах с таблицей emp_data:
CREATE TABLE emp_data
(
emp_num integer,
emp_name char(20),
hired date,
id-code char (10),
salary decimal(4,2)
)
Пусть после создания таблицы был выполнен следующий оператор:
REVOKE ALL ON emp_data FROM PUBLIC
Теперь создадим несколько представлений для разных категорий пользователей. Для тех, кто может иметь доступ по чтению из неконфиденциальных столбцов, создадим такое представление:
CREATE VIEW emp_data AS
SELECT emp_num, emp_name FROM emp_data
Пользователи, получившие привилегию SELECT для данного представления, могут видеть некоторые данные без возможности обновления. Для работников отдела кадров создадим следующее представление:
CREATE VIEW enter_data AS
SELECT emp_num,emp_name,id-code,salary FROM emp_data
Этим пользователям необходимо предоставить привилегии INSERT и UPDATE для этого представления. Так как создатель таблицы и представления имеет привилегии на вставку как для таблицы так и для представления, можно предоставить привилегии INSERT и UPDATE на представление даже тем пользователям, у которых нет такой привилегии:
GRANT SELECT, INSERT, UPDATE ON enter_data TO olga_s, helena_m
Для некоторых пользователей, которые могут вводить или изменять некоторые данные о сотрудниках, создадим еще одно представление:
CREATE VIEW enter_upd AS
SELECT emp_num,emp_name,id-code FROM emp_data
Это представление отличается от предыдущего тем, что в последнем не показываются данные о зарплате сотрудников. Наконец, пусть менеджерам необходим доступ по чтению и редактированию всех данных о работниках фирмы:
CREATE VIEW all_data AS
SELECT * FROM emp_data
Теперь можно дать менеджерам все привилегии:
GRANT SELECT, UPDATE, INSERT, DELETE ON emp_data TO alex_v
Администрирование сервера INFORMIX-OnLine
Внедрение в информационную систему сервера INFORMIX-OnLine Dynamic Server требует решения множества вопросов, которые влияют на производительность системы в целом. Необходимо решить вопросы, где будут храниться данные, как к ним будет осуществляться доступ, как защитить данные. OnLine Server позволяет настроить систему на оптимальную производительность. Для этого необходимо понимать архитектуру сервера и требований, возникающих во время эксплуатации сервера.
Организация хранения данных
Сервер INFORMIX-OnLine может хранить данные на диске двумя способами. Первый способ – это хранение данных в файловой системе ОС. Второй способ – хранение данных на “сыром” дисковом пространстве. В последнем случае сервер INFORMIX-OnLine сам управляет вводом-выводом данных.
Единицы хранения данных
Сервер INFORMIX-OnLine использует следующие физические единицы хранения информации: chunk, page, blobpage, extent.
Логические единицы хранения данных связаны с управлением БД. К логическим единицам относятся: dbspace, blobspace, database, table, tblspace.
В дополнение к этому существуют следующие единицы хранения информации о физической и логической целостности данных:logical log, physical log, reserved pages.
Фрагмент диска chunk – это максимальная физическая единица хранения информации сервером INFORMIX-OnLine. Фрагмент может быть файлом операционной системы или специальным символьным устройством системы. В первом случае данные размещаются в обычном файле и записью на диск управляет ОС. В этом случае INFORMIX-OnLine не гарантирует, что записанные данные реально попадут на диск, так как данные могут быть помещены в дисковую кэш-память ОС. Во втором случае сервер гарантирует, что те данные, которые должны попасть на диск, будут записаны. Кроме этого, заметно выше производительность системы ввода-вывода. Однако не каждая операционная система позволяет организовать chunk на “сыром” диске. INFORMIX-OnLine поддерживает размер chunk до 2 GB. Максимальное количество chunk’ов – 2048.
Страница page – это единица информации, которой сервер INFORMIX-OnLine обменивается с устройством хранения данных для доступа к БД. Размер страницы варьируется. Обычно это 2 или 4 КБ. Фрагмент диска содержит определенное количество страниц. Страница не может выходить за пределы chunk’а.
Blobpage – единица дискового пространства, которой INFORMIX-OnLine манипулирует для хранения данных типа BYTE и TEXT. Размер blobpage задается администратором и может варьироваться.
Когда создается таблица, INFORMIX-OnLine выделяет фиксированное число страниц для хранения данных. Когда выделенное пространство исчерпывается, сервер выделяет дополнительное место. Физическая единица данных, которая используется для этих целей, называется extent. При создании таблицы задаются initial extent size и next extent size. Первый – первоначальный объем под таблицу (в килобайтах). Второй – величина прироста объема таблицы в килобайтах.
Extent всегда хранится в пределах одного chunk’а и не может перекрывать его границы. В случае, когда INFORMIX-OnLine не может выделить достаточно пространства в текущем фрагменте, он ищет его в другом фрагменте.
Базовой логической единицей хранения информации сервером INFORMIX-OnLine является пространство БД (dbspace). Пространство БД отображает физическое пространство на логическое пространство хранения данных. Обычно одному dbspace соответствует один chunk, хотя одному dbspace может соответствовать несколько фрагментов.
Зеркалирование
Зеркалирование позволяет резервировать фрагмент диска точно такого же размера фрагментом. Запись в первичный chunk порождает запись в резервный chunk. В случае сбоя первичного фрагмента сервер INFORMIX-OnLine переключается на резервный автоматически, при этом работа пользователя не прерывается.
Технология резервирования позволяет администратору восстанавливать данные в первичном фрагменте параллельно с работой пользователя с вторичным фрагментом.
За возможность зеркалирования придется платить дополнительным дисковым пространством.
В случае, когда незеркалированный chunk выходит из строя, INFORMIX-OnLine не может добраться к данным из него и будет возвращать ошибку при обращении к этому фрагменту. Если из строя вышел незеркалированный фрагмент, который хранит logical log, physical log или root dbspace, сервер немедленно переходит в режим off-line, т.е. прекращает работу.
Сервер делает запись в оба фрагмента параллельно и читает из обоих разные части (split read) для минимизации времени ввода-вывода.