Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
1-120.docx
Скачиваний:
46
Добавлен:
13.09.2019
Размер:
827.39 Кб
Скачать

105. Организация процессов обработки данных в бд. Ограничения целостности.

Ограничения целостности при работе с реляционной БД.

ЦЕЛОСТНОСТЬ ДАННЫХ. Состоит в обеспечение правильности данных и их сохранности в любой момент времени. При этом имеется в виду как физическая сохранность данных в таблицах, так и возможность доступа к ним средствами СУБД. Ограничения целостности - утверждения о допустимых значений отдельных информационных единиц и связей между ними. Для реляционных баз данных формулируются два правила целостности данных: целостность сущностей и целостность согласования.

ЦЕЛОСТНОСТЬ СУЩНОСТЕЙ. Никакой ключевой атрибут строки не может быть пустым. Ключ реляционной таблицы однозначно определяет каждую строку. Таким образом, если пользователь хочет извлечь конкретную строку таблицы или выполнить с ней манипуляции, он должен знать значения ключа этой строки. Поэтому запись не должна записываться в БД пока значения ее ключевых атрибутов не будут определены.

ЦЕЛОСТНОСТЬ СОГЛАСОВАНИЯ. Значение непустого внешнего ключа должно быть равно одному из текущих значений первичного ключа другой таблицы. Все связи между отношениями должны быть реальными. Каждый вторичный ключ должен ссылаться на существующий первичный ключ другого отношения.

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

Потеря связей между записями может произойти в нескольких случаях:

  • Если будет изменено значение поля связи в родительской таблице без изменения значений в полях дочерней таблицы.

  • Если будет изменено значение поля (полей) связи в дочерней таблице без изменения соответствующего значения в родительской таблице.

Нарушение ссылочной целостности может возникнуть в нескольких случаях:

  • удаление записи из главной таблицы, без удаления связанных записей в дочерней таблице;

  • изменение значения поля связи главной таблицы, без изменения ключа дочерней;

  • изменение ключа дочерней таблицы без изменения поля связи главной.

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

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

  • При удалении записи в родительской таблице обязательно следует удалить все связанные записи.

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

Подобные возможности существуют во всех СУБД. Кроме того, в серверных СУБД, таких как ORACLE и SQL Server, имеются утилиты, периодически запуская которые, можно гарантировать, что в базу данных не проникнут нарушения ссылочной целостности, обусловленные частично завершенными транзакциями, импортированными данными и другим. Запуск этих утилит обычно входит в план обслуживания базы данных.

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