
- •2.3 Базы данных [5-7] тебеньков е.С.
- •1 .Проектирование базы данных с помощью нормализации
- •2. Операция «соединения» и ее свойства.
- •3. Разложение без потерь. Теорема. Примеры
- •4. Полностью соединимые отношения. Примеры
- •5. Операторы описания данных в sql
- •6. Операторы манипулирования данными в sql
- •7. Управление транзакциями
- •1. Запуск транзакции
- •2. Завершение транзакции
- •8. Технологии «клиент-сервер»
- •1 Вариант - файловый сервер.
- •2 Вариант – удаленный доступ.
- •3 Вариант – сервер Базы Данных.
- •4 Вариант – сервер приложений.
- •9. Оператор Select
- •10. Индексация. Достоинства и недостатки. Примеры
- •13. Архитектуры бд
- •1.1.2. Архитектуры бд
- •Локальная
- •Архитектура "файл-сервер"
- •Архитектура удаленных бд ("клиент-сервер")
- •1.1.3. Достоинства и недостатки различных архитектур приложений бд
- •14. Управление правами доступа в sql
- •15. Модель Чена
- •16. Примеры бинарных связей
- •17. Правила Джексона для перехода от модели Чена к реляционной модели
- •18. Реляционная модель данных. 12 правил Кодда.
- •12 Правил Кодда.
- •19. Ограничения целостности в реляционной модели данных и их поддержка в sql
- •20. Восстановление данных в бд
19. Ограничения целостности в реляционной модели данных и их поддержка в sql
Целостность (от англ. integrity – нетронутость, неприкосновенность, сохранность, целостность) – понимается как правильность данных в любой момент времени. Но эта цель может быть достигнута лишь в определенных пределах: СУБД не может контролировать правильность каждого отдельного значения, вводимого в базу данных (хотя каждое значение можно проверить на правдоподобность). Например, нельзя обнаружить, что вводимое значение 5 (представляющее номер дня недели) в действительности должно быть равно 3. С другой стороны, значение 9 явно будет ошибочным и СУБД должна его отвергнуть. Однако для этого ей следует сообщить, что номера дней недели должны принадлежать набору (1,2,3,4,5,6,7).
Целостность данных - это механизм поддержания соответствия базы данных предметной области.
Поддержание целостности базы данных может рассматриваться как защита данных от неверных изменений или разрушений (не путать с незаконными изменениями и разрушениями, являющимися проблемой безопасности). Современные СУБД имеют ряд средств для обеспечения поддержания целостности (так же, как и средств обеспечения поддержания безопасности).
В реляционной модели данных определены два базовых требования обеспечения целостности:
Целостность по сущностям.
Целостность по ссылкам.
Целостность, определяемая пользователем.
Целостность сущностей. Не допускается, чтобы какой-либо атрибут, участвующий в первичном ключе, принимал неопределенное значение. Вполне очевидно, что если данное требование не соблюдается то в базе данных может хранится противоречивая информация об одном и том же объекте. Поддержание целостности сущностей обеспечивается средствами системы управления базой данных (СУБД). Это осуществляется с помощью двух ограничений:
при добавлении записей в таблицу проверяется уникальность их первичных ключей
не позволяется изменение значений атрибутов, входящих в первичный ключ.
Целостность ссылок Значение внешнего ключа должно либо:
быть равным значению первичного ключа цели;
быть полностью неопределенным, т.е. каждое значение атрибута, участвующего во внешнем ключе должно быть неопределенным.
Пусть, например, даны отношения ОТДЕЛ (N_ОТДЕЛА, ИМЯ_ОТДЕЛА) и СОТРУДНИК (N_СОТРУДНИКА, N_ОТДЕЛА, ИМЯ_СОТРУДНИКА), в которых хранятся сведения о работниках предприятия и подразделениях, где они работают. Отношение ОТДЕЛ в данной паре является родительским, поэтому его первичный ключ "N_отдела" присутствует в дочернем отношении СОТРУДНИК. Требование целостности по ссылкам означает здесь, что в таблице СОТРУДНИК не может присутствовать кортеж со значением атрибута "N_отдела", которое не встречается в таблице ОТДЕЛ. Если такое значение в отношении ОТДЕЛ отсутствует, значение внешнего ключа в отношении СОТРУДНИК считается неопределенным.
Как правило, поддержание целостности ссылок также возлагается на систему управления базой данных. Например, она может не позволить пользователю добавить запись, содержащую внешний ключ с несуществующим (неопределенным) значением.
Целостность определяемая пользователем. Для любой конкретной базы данных существует ряд дополнительных специфических правил, которые относятся к ней одной и определяются разработчиком. Чаще всего контролируется: уникальность тех или иных атрибутов, диапазон значений экзаменационная оценка от 2 до 5),принадлежность набору значений (пол "М" или "Ж").
В общем случае целостность данных может нарушаться по следующим основным причинам:
1) ошибки в создании структуры локальных БД и их заполнении;
2) просчеты в построении структуры РБД (процедуры фрагментации и локализации);
3) системные ошибки в программном обеспечении взаимодействия локальных БД (одновременный доступ);
4) аварийная ситуация (неисправность технических средств) и восстановление РБД.
Логическая целостность
Логическая целостность – нарушается, если база некорректно обновлена.
Например, фамилию записали не буквами, а на псевдокодах. Тогда должен сработать сервер и выдать ошибку, что не тот формат записи.
Семантическая целостность
Семантическая целостность – соответствие данных в разных полях. Осуществляется проверка связи между данными, хранящимися в разных полях.
Например, дата окончания школы не может быть на 16 лет раньше рождения.
Механизмы поддержания семантической целостности:
Механизм триггеров - активная процедура, автоматически вызывается, когда это необходимо.
Существуют специальные процедуры, которые осуществляют контроль за внесенной информацией.
Триггеры - средство, обеспечивающее автоматическое выполнение некоторых действий при каждой модификации таблицы.
Триггер характеризуется следующими классификационными признаками, которые должны быть заданы при его создании:
условие активизации - действие над таблицей, которое вызывает запуск триггера - такими действиями являются операции INSERT, DELETE, UPDATE;
время активизации - выполнение триггера до или после выполнения операции над таблицей;
область действия - выполнение триггера либо один раз для каждого оператора модификации таблицы, либо для каждой строки, изменяемой / удаляемой / вставляемой в таблицу.
Таким образом, для каждой таблицы может быть создано до 12 типов триггеров. На самом деле, триггеров может быть и больше, так как может быть создано и несколько триггеров одного типа. В таком случае однотипные триггеры выполняются в порядке их создания.
При обеспечении в общем-то одинаковой функциональности, синтаксис и некоторые детали применения триггеров различаются в DB2 и Oracle, поэтому мы рассматриваем их раздельно.
Триггеры: Oracle
Триггер создается оператором языка SQL CREATE TRIGGER:
Отличия триггера Oracle от триггера DB2 (многие из них видны из самого синтаксиса оператора) состоят в следующем:
Оператор CREATE позволяет заменить триггер (в DB2 для этого нужно уничтожить триггер и создать его заново).
Триггер можно создавать и для представления (это связано прежде всего с более широкими возможностями изменения представлений в Oracle).
Введено новое условие активизации INSTEAD OF (триггер выполняется вместо оператора); оно применяется только для представлений и позволяет изменять базовые таблицы вместо неизменяемого представления.
Для триггера могут быть назначены несколько условий активизации (через операцию OR). В этом случае действие триггера может "узнать" по какому условию запущен триггер, проверяя значения предикатов INSERTING, DELETEING, UPDATING.
В условии фразы WHEN не допускаются запросы.
Собственно выполняемые действия триггера задаются в виде блока на языке PL/SQL.
Триггер, выполняемый после (AFTER) выполнения оператора, модифицирующего некоторую таблицу, не может содержать операторы выборки (SELECT) из этой таблицы.