Главная Случайная страница


Полезное:

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


Категории:

АрхитектураАстрономияБиологияГеографияГеологияИнформатикаИскусствоИсторияКулинарияКультураМаркетингМатематикаМедицинаМенеджментОхрана трудаПравоПроизводствоПсихологияРелигияСоциологияСпортТехникаФизикаФилософияХимияЭкологияЭкономикаЭлектроника






Поддержание целостности данных в СУБД





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

С точки зрения пользователя СУБД, основными средствами поддержания целостности данных являются ограничения и правила.

Ограничения

Ограничения могут относиться к таблицам или отдельным столбцам. Ограничения на столбцы задаются при создании таблицы, в операторах CREATE TABLE Табличные ограничения относятся к группе столбцов и могут задаваться как при создании таблицы, так и позже, посредством оператора ALTER TABLE. Следующий пример содержит именованное ограничение, связывающее значения в двух столбцах:

CREATE TABLE dept (dname char(10), budget money, expenses money,

CONSTRAINT check_amount CHECK (budget > 0 and expenses <= budget));

{Бюджет должен быть положительным, а расходы не должны выходить за рамки бюджета}

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

CREATE TABLE emp (ename char(10), edept char(10) references dept (dname));

{Ни один работник не должен числиться в неизвестном отделе}

Ограничения всех видов накладываются владельцем таблицы и влияют на исход последующих операций с данными. Перед завершением выполнения SQL-оператора производится проверка имеющихся ограничений. При обнаружении нарушений СУБД сигнализирует о ненормальном завершении и аннулирует внесенные оператором изменения. Отметим, что для наложения ссылочного ограничения необходимо обладать привилегией REFERENCES по отношению к таблице, на которую делается ссылка (dept в примере выше). Ограничения можно не только накладывать, но и отменять. При этом между ограничениями могут существовать зависимости, и отмена одного из них может потребовать ликвидации других (ссылочных) ограничений, зависящих от первоначального.

Рассмотрим следующий пример:

CREATE TABLE dept (name char(10) NOT NULL, location char(20), CONSTRAINT dept_unique UNIQUE(name));

CREATE TABLE emp (name char(10), salary decimal(10,2), edept char(10) CONSTRAINT empref REFERENCES dept(name));

Если требуется удалить ограничение dept_unique, можно воспользоваться следующим оператором:

ALTER TABLE dept DROP CONSTRAINT dept_unique cascade;

Слово cascade означает, что следует удалить также все ограничения, прямо или косвенно зависящие от dept_unique. В данном случае будет изъято ограничение empref. Если вместо cascade указать restrict, то есть сделать попытку удалить только ограничение dept_unique, СУБД зафиксирует ошибку. Тем самым обеспечивается целостность системы ограничений. В СУБД INGRES делается попытка примирить контроль ограничений и эффективность функционирования. При массовом копировании данных контроль ограничений отключается. Это значит, что необходимо дополнять копирование запуском процедуры глобальной проверки целостности.

Правила

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

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

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

SET NORULES;

Оператор

SET RULES;

позволит затем восстановить работу механизма правил. По умолчанию этот механизм включен. Для удаления правил служит оператор

DROP RULE правило;

СУБД обеспечивает автоматическое удаление правил в тех случаях, когда удаляется соответствующая таблица. Тем самым поддерживается целостность системы таблиц и правил.

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

АУДИТ

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

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

Возможные протоколируемые события:

· Добавление записи

· Корректировка записи

· Выборка записи

· Удаление записи

· Добавление записи хранимой процедурой

· Корректировка записи хранимой процедурой

· Выборка записи хранимой процедурой

· Удаление записи хранимой процедурой

· Удаление записи по ссылке

· Корректировка записи по ссылке

· Создание индекса

· Удаление индекса

· Добавление/Удаление файла

Date: 2016-08-30; view: 670; Нарушение авторских прав; Помощь в написании работы --> СЮДА...



mydocx.ru - 2015-2024 year. (0.007 sec.) Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав - Пожаловаться на публикацию