Целостность данных

Термин “целостность данных” относится к правильности и полноте информации, содержащейся в БД. Вероятно, корректнее говорить о непротиворечивости данных, поскольку невозможно предотвратить появление неверных данных. При изменении содержимого БД с помощью операторов INSERT, DELETE, UPDATE может произойти нарушение целостности данных. Например, могут возникнуть следующие ситуации:

· в базу внесены заведомо неправильные данные (отрицательная цена товара);

· данные оказались несогласованными (заказ билета на несуществующий рейс);

· внесенные изменения потеряны из-за системной ошибки или сбоя в электропитании;

· изменения внесены частично (учтена выручка от продажи товара, но количество товара на складе не уменьшено; изменена нумерация домов на улице, но остались старые адреса жильцов).

Одной из важнейших задач реляционной СУБД является поддержка целостности данных.

Для обеспечения непротиворечивости данных в реляционных СУБД определяются условия целостности данных. Опишем основные типы условий целостности.

1. Обязательность данных. Некоторые столбцы должны содержать значения в каждой строке, то есть не иметь NULL-значений и не оставаться незаполненными. Например, для каждой поставки должен быть указан поставщик. Условие обязательности данных задается в операторе создания таблицы CREATE TABLE.

2. Проверка на правильность. Можно, например, указать СУБД, что значения поля должны находиться в определенном диапазоне. Это условие также задается в операторе CREATE TABLE.

3. Целостность таблицы. Первичный ключ таблицы должен в каждой строке иметь уникальное значение. Свойство уникальности может быть задано и для других полей. Условие задается в операторе CREATE TABLE.

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

5. Деловые правила. Изменение информации может быть ограничено деловыми правилами, учитывающими специфику БД. Например, компания может установить правило, запрещающее принимать заказ на товар, если его недостаточно на складе. Деловые правила могут быть реализованы с помощью триггеров, которые будут описаны ниже.

6. Непротиворечивость. Многие операции в БД вызывают несколько изменений одновременно. Если эти изменения выполнены не в полном объеме, целостность данных нарушается. Условия непротиворечивости данных обеспечивает механизм транзакций.

Рассмотрим некоторые проблемы, связанные со ссылочной целостностью данных. Существует четыре типа изменений БД, которые могут нарушить ссылочную целостность отношений предок-потомок.

1. Добавление новой строки-потомка. Значение внешнего ключа строки-потомка должно быть одним из значений первичного ключа в таблице- предке.

2. Обновление внешнего ключа в строке-потомке. Новое значение внешнего ключа строки-потомка должно быть одним из значений первичного ключа в таблице-предке.

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

4. Обновление первичного ключа в строке-предке - все аналогично предыдущему случаю.

Первые две ситуации приводят к сообщению об ошибке. Для двух последних ситуаций в операторе CREATE TABLE можно задать одно из четырех возможных правил

1. RESTRICT – запрещает удаление строки из таблицы-предка или корректировку первичного ключа, если строка имеет потомков.

2. CASCADE – при удалении строки-предка все строки-потомки также удаляются из таблицы-потомка. При обновлении первичного ключа в строке-предке значение внешнего ключа обновляется во всех строках-потомках.

3. SET NULL – при удалении или корректировке первичного ключа строки-предка внешним ключам во всех строках-потомках присваивается NULL-значение.

4. SET DEFAULT - при удалении или корректировке первичного ключа строки-предка внешним ключам во всех строках-потомках присваивается значение по умолчании.

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

Каскадные удаления и обновления могут приводить к непредвиденным последствиям. Рассмотрим, например три таблицы A - животные, B – девочки и C – мальчики с одинаковыми полями Name и Likes (любит). Будем считать, что животные любят мальчиков, мальчики – девочек, а девочки – животных. Таким образом, каждая из таблиц является как родительской, так и дочерней. Таблица A является родительской для B и дочерней для C, а B – родительской для C и дочерней для A.

Пусть таблицы имеют следующее содержание.

Таблица 17

Записи таблицы A

Name	Likes
Джек	Леша
Мурка	Петя
Хрюша	Толя

Таблица 18

Записи таблицы B

Name	Likes
Таня	Джек
Галя	Хрюша
Лена	Мурка

Таблица 19

Записи таблицы C

Name	Likes
Петя	Галя
Леша	Лена
Толя	Таня
Стас	Галя

Предположим, что все правила удаления CASCADE. Удалим запись с данными о Пете из таблицы C. Тогда из таблицы A каскадно удалится запись с информацией о Мурке, потом не останется Лены в таблице B и т. д. Легко проследить, что в итоге произойдет полное удаление содержимого всех таблиц.

Часть внешнего ключа может иметь значения NULL. По стандарту SQL92 в операторе CREATE TABLE можно указать один из двух режимов

· MATCH FULL (полное совпадение) – ни одна часть внешнего ключа не может иметь значение NULL;

· MATCH PARTIAL (частичное совпадение) – часть внешнего ключа может принимать значение NULL.

Дата добавления: 2014-01-07