2.3.10. Ссылочная целостность
Ссылочная целостность (referential integrity) – необходимое качество реляционной базы данных, заключающееся в отсутствии в любом её отношении внешних ключей, ссылающихся на несуществующие кортежи.
Связи между данными, хранимыми в разных отношениях, в реляционной БД устанавливаются с помощью использования внешних ключей, как только что было рассмотрено.
Таким образом, всегда имеется возможность выполнить две операции:
определить, с каким кортежем в отношении B связан определённый кортеж отношения A;
найти все кортежи отношения A, имеющие связи с определённым кортежем отношения B.
Ссылочная целостность может быть проиллюстрирована следующим образом: Дана пара отношений «A» и «B», связанных внешним ключом.
Первичный ключ отношения «B» – атрибут «B.key». Внешний ключ отношения «A», ссылающийся на отношение «B» – атрибут «A.b».
Ссылочная целостность для пары отношений «A» и «B» имеет место тогда, когда выполняется условие: для каждого кортежа отношения «A2 существует соответствующий кортеж отношения «B», то есть кортеж, у которого (B.key = A.b).
База данных обладает свойством ссылочной целостности, когда для любой пары связанных внешним ключом отношений в ней условие ссылочной целостности выполняется.
Если вышеприведённое условие не выполняется, говорят, что в базе данных нарушена ссылочная целостность.
Такая БД не может нормально эксплуатироваться, так как в ней разорваны логические связи между зависимыми друг от друга фактами.
Непосредственным результатом нарушения ссылочной целостности становится то, что корректным запросом не всегда удаётся получить корректный результат.
Рассмотрим пример. Основная таблица «Адрес» содержит непосредственно номер дома и квартиры, а вместо имени улицы в поле «улица» имеет внешний ключ, ссылающийся на таблицу «Улицы» – справочник улиц.
Очевидно, что полноценный адрес должен быть представлен двумя связанными записями в обеих названных таблицах.
Рисунок 2.3.10.1 – Ссылочная целостность и её нарушение
Две записи таблицы «Адрес» (id = 887 и id = 994) имеют в поле «улица» так называемые «висящие ссылки» – значения, которым не соответствуют записи в таблице «Улицы» (эти ссылки показаны красным цветом).
Из-за этого результат SQL-запроса, выбирающего адреса (полные, по равенству полей) не будет содержать этих двух записей – для них условие запроса не выполнится.
И ещё одна запись не будет выбрана таким запросом (id = 85).
Это вариант намеренного (и, в некоторых случаях, легального) нарушения ссылочной целостности – в поле внешнего ключа записан NULL (показано синим цветом).
Правильно спроектированная и поддерживаемая база данных не допускает возможности нарушения ссылочной целостности. Тем не менее, такие нарушения могут появиться в ходе эксплуатации базы по целому ряду причин:
некорректная работа прикладного программного обеспечения (при ошибке в ПО, выполняющем модификацию БД, БД может быть модифицирована недопустимым образом); ПО может совершать ошибки следующих видов:
неполная запись объектов – данные объекта размещаются в записях нескольких таблиц, а программа не записывает какую-то из них;
некорректная правка ссылки – значение внешнего ключа изменяется на такое, которому не соответствует ни одна запись в связанной таблице;
правка первичного ключа без каскадного обновления – в таблице, на которую есть ссылки, правится первичный ключ, но при этом внешние ключи в связанных с ней таблицах остаются без изменения;
удаление записи без каскадного обновления – из таблицы удаляется запись, на которую имеются ссылки по внешним ключам других таблиц, при этом в связанных записях внешние ключи не меняются (в результате все ссылающиеся на неё записи других таблиц становятся некорректными).
сбои в работе системного программного обеспечения и оборудования; например, если при добавлении объекта в базу нужно добавить несколько связанных записей в несколько таблиц, очевидно, что ссылочная целостность будет нарушена в процессе добавления данных (когда часть связанных записей уже добавлена, а часть – ещё нет), и восстановится только после завершения операции; если во время выполнения операции она будет прервана (из-за переполнения диска, сбоя питания, или по каким-то другим причинам), часть записей будет добавлена в БД, часть – нет, т.о. часть добавленных записей останется с некорректными ссылками.
Пустые внешние ключи
Возможна ситуация, когда внешний ключ вместо ссылки на существующую запись в таблице БД содержит «отсутствующее значение» NULL.
Такое положение можно трактовать как отсутствие какой-то части объекта. Хотя с точки зрения чистой теории это недопустимо, на практике иногда бывает удобно разрешить использование пустых внешних ключей.
Чтобы корректно работать с группами связанных таблиц, допускающих пустые внешние ключи, используется специфическая операция языка SQL – открытое соединение (внешнее соединение, outer join).
Обязательным (хотя и не достаточным) условием сохранения ссылочной целостности базы данных является поддержка транзакций.
Если программное обеспечение выполняет группу связанных между собой операций, которые по отдельности могут приводить к нарушению целостности ссылок, СУБД должна предоставлять возможность выполнения всей этой группы в одной транзакции, то есть так, чтобы при любом сбое производилась автоматическая отмена всех операций группы, в том числе уже полностью завершённых.
Возможно поддержание ссылочной целостности БД с использованием механизма триггеров.
В этом случае для любой потенциально опасной операции над таблицей создаётся триггер, который производит необходимые проверки или даже изменяет данные в связанных таблицах, чтобы исключить потерю ссылок.
Так, для обеспечения каскадных изменений триггер может быть установлен на операцию изменения записи в таблице.
Если окажется, что при редактировании изменилось значение ключевого поля, триггер должен произвести согласованные изменения во всех таблицах, связанных с данной, поменяв старое значение внешних ключей на новое.
СУБД может иметь механизм автоматического поддержания ссылочной целостности, основанный на явном описании ссылок при создании БД.
При описании таблиц БД программист явно описывает, какие поля таблиц являются внешними ключами и на какие таблицы они ссылаются.
Любая операция, изменяющая данные в таблице, вызывает автоматическую проверку ссылочной целостности.
при операции добавления или редактирования записи автоматически проверяется, ссылаются ли внешние ключи в этой записи на существующие записи в заявленных при описании связанных таблицах; если выясняется, что операция приведёт к появлению некорректных ссылок, она не выполняется;
при операции редактирования записи проверяется, не изменяется ли её первичный ключ и нет ли на неё ссылок; если первичный ключ изменяется, и при этом на данную запись имеются ссылки, операция редактирования завершается с ошибкой;
при операции удаления записи проверяется, нет ли на неё ссылок; если ссылки имеются, то возможно три варианта дальнейших действий:
запрет – удаление блокируется и возвращается ошибка;
каскадное удаление – в одной транзакции производится удаление данной записи и всех записей, ссылающихся на данную;
обнуление внешних ключей – во все внешние ключи записей, ссылающихся на данную, записывается значение NULL.
ГЛАВА 17. Ссылочная целостность данных.
Термин ссылочная целостность относится к возможности базы данных защищать себя от получения входных данных, результатом которых может стать нарушение отношений. А именно ссылочная целостность базы данных существует в соответствии с ее способностью осуществлять и защищать отношение между двумя таблицами.
Реализация формальных ограничений целостности добавляет некоторую дополнительную работу разработчикам баз данных — так какова же окупаемость? Если вы новичок в этой концепции, то вы, безусловно, должны найти множество причин для оправдания дополнительного времени и внимания.
* Бомбоубежище: формальные ссылочные ограничения — особенно при разумном использовании других ограничений — станут надежным бомбоубежищем бизнес- правил вашей базы данных от ошибок приложений, независимо от их источника. Это будет в особенности важным, когда вы начнете устанавливать ваши системы на сайты, где неквалифицированный или частично квалифицированный персонал будет получать доступ к базе данных через утилиты сторонних организаций.
* Скорость запросов: индексы, автоматически созданные для ограничений ссылочной целостности, увеличат скорость операций соединения (join)[47].
* Качество управления: в процессе разработки и тестирования потенциальные ошибки имеют тенденцию проявляться раньше, потому что база данных отменяет операции, которые нарушают правила. Они эффективно уменьшают неприятности в разработке приложения при ошибочных предположениях о согласованности данных.
* Документированность: правила целостности, установленные в вашей базе данных, дают «свободную» документацию, которая уменьшает потребность в любой описательной документации, помимо скриптов схемы. Правила, корректно определенные в метаданных, становятся надежным справочником по модели данных для новых групп и будущей разработки.
Если реляционная СУБД позволяет объявлять отношение между двумя таблицами, иногда это называется декларативной ссылочной целостностью — туманный термин, который, похоже, распространялся писателями журнальных статей. Ссылочная целостность является целью проектирования, уровнем его качества. Автор предпочитает термин формальные ссылочные ограничения, когда обращается к механизмам реализации таких правил.
В системе управления реляционными базами данных (реляционные СУБД) отношение между двумя таблицами создается посредством ограничения внешнего ключа. Ограничение внешнего ключа реализует правила существования строк, защищая таблицу от попыток добавлять строки, несовместимые с моделью данных. Однако такое ограничение не работает в одиночестве. Другие ограничения целостности (подробно описанные в главе 16) могут работать в комбинации с ссылочными ограничениями для поддержания непротиворечивости отношений.
Читайте также
Целостность и восстановление данных
Целостность и восстановление данных Целостность данных, хранящихся в базе крайне важна. Между тем, при одновременном чтении и изменении данных многими пользователями существует вероятность их разрушения. База данных AS/400 предоставляет надежные средства обеспечения
Ссылочная целостность
Ссылочная целостность На практике данные одного физического файла часто зависят от данных другого. Если программа обновляет один файл независимо от другого, то целостность данных может быть нарушена. Часто ответственность за поддержку таких зависимостей ложится на
Целостность файловой системы
Целостность файловой системы Значительная часть файловой системы находится в оперативной памяти. А именно, в оперативной памяти расположены суперблок примонтированной системы, метаданные активных файлов (в виде системно-зависимых inode и соответствующих им vnode) даже
5.16.1 Целостность файловой системы
5.16.1 Целостность файловой системы Ядро посылает свои записи на диск для того, чтобы свести к минимуму опасность искажения файловой системы в случае системного сбоя. Например, когда ядро удаляет имя файла из родительского каталога, оно синхронно переписывает каталог на
Ссылочная политика
Ссылочная политика Метки: блоговедение, продвижение, ссылкиИнтернет – это гипертекст, он пронизан ссылками, как голова – мыслями. Даже эта бумажная книга содержит перекрестные ссылки-темы, хотя интерактивной назвать ее сложно.Если вы распространяете свои сообщения по
3.8.3 Целостность сообщения
3.8.3 Целостность сообщения MD5 и совместно используемые секретные ключи можно применять для определения изменений в данных при их пересылке по сети. Рассмотрим рис. 3.10:1. Вычисление MD5 выполняется над данными с помощью секретного ключа.2. Данные и полученное сообщение
Ссылочная масса
Ссылочная масса С тех пор как «Яндекс», а затем и Yahoo! (который, впрочем, все равно показывал далеко не все) закрыли доступ к просмотру ссылок, для оценки ссылочного веса приходится пользоваться платными сервисами. Для этой цели подходят системы Solomono.ru, Ahrefs.com, Majestic-SEO.com (рис.
Глава 13. Базы данных
Глава 13. Базы данных Модуль QtSql средств разработки Qt обеспечивает независимый от платформы и типа базы данных интерфейс для доступа с помощью языка SQL к базам данных. Этот интерфейс поддерживается набором классов, использующих архитектуру Qt модель/представление для
Глава 17. Программирование баз данных.
Глава 17. Программирование баз данных. В этой главе . ~ Знакомство с терминологией~ Написание кода баз данных с помощью объектов данных ActiveX~ Программирование с помощью DAO~ Ускорение с помощью SQLНесмотря на то, что Access — официальное приложение для работы с базами данных,
Глава 2 Ввод данных. Типы, или форматы, данных
Глава 2 Ввод данных. Типы, или форматы, данных Работа с документами Excel сопряжена с вводом и обработкой различных данных, то есть ин формации, которая может быть текстовой, числовой, финансовой, статистической и т. д. МУЛЬТИМЕДИЙНЫЙ КУРС Методы ввода и обработки данных
Ссылочная целостность
Ссылочная целостность Firebird имеет полную поддержку формальной, основанной на стандартах SQL, ссылочной целостности — иногда называемой декларативной ссылочной целостностью — включая необязательные каскадные изменения и
Глава 12 Базы данных
Глава 12 Базы данных 12.1. Понятие о базах данных Одной из важнейших областей применения компьютеров является переработка и хранение больших объемов информации в различных сферах деятельности человека: в экономике, банковском деле, торговле, транспорте, медицине, науке и
Глава 22 Дублирование данных
Глава 22 Дублирование данных Современные носители информации обладают высокой надежностью, однако нельзя быть полностью застрахованным от возможных сбоев оборудования. Проблемы с программами, даже операционными системами можно решить путем их переустановки, но если
Глава 19 Архивация данных
Глава 19 Архивация данных • Архивация средствами Windows• WinRAR• 7-ZipВзаимодействуя с компьютером, вы так или иначе работаете с файлами. Их приходится открывать, просматривать, изменять, копировать, перемещать, создавать и т. д. При этом часто требуется переносить файлы с
Целостность
Целостность Сервис целостности данных гарантирует то, что данные (передаваемые или хранимые) не были незаметно изменены. Очевидно, что такая гарантия существенна для любого вида электронного бизнеса, а также желательна во многих других средах. Целостность данных может
Ссылочная целостность
Информация должна быть проверяема, иначе она может быть поставлена под сомнение и удалена.
Вы можете отредактировать эту статью, добавив ссылки на авторитетные источники.
Эта отметка установлена 14 мая 2011.
Пожалуйста, улучшите статью в соответствии с правилами написания статей.
Ссы́лочная це́лостность (англ. referential integrity ) — необходимое качество реляционной базы данных, заключающееся в отсутствии в любом её отношении внешних ключей, ссылающихся на несуществующие кортежи.
Определение
Связи между данными, хранимыми в разных отношениях, в реляционной БД устанавливаются с помощью использования внешних ключей — для установления связи между кортежем из отношения A с определённым кортежем отношения B в предусмотренные для этого атрибуты кортежа отношения A записывается значение первичного ключа (а в общем случае значение потенциального ключа) целевого кортежа отношения B. Таким образом, всегда имеется возможность выполнить две операции:
- определить, с каким кортежем в отношении B связан определённый кортеж отношения A;
- найти все кортежи отношения A, имеющие связи с определённым кортежем отношения B.
Благодаря наличию связей в реляционной БД можно хранить факты без избыточного дублирования, то есть в нормализованном виде. Ссылочная целостность может быть проиллюстрирована следующим образом:
Дана пара отношений A и B, связанных внешним ключом. Первичный ключ отношения B — атрибут B.key. Внешний ключ отношения A, ссылающийся на B — атрибут A.b. Ссылочная целостность для пары отношений A и B имеет место тогда, когда выполняется условие: для каждого кортежа отношения A существует соответствующий кортеж отношения B, то есть кортеж, у которого (B.key = A.b).
База данных обладает свойством ссылочной целостности, когда для любой пары связанных внешним ключом отношений в ней условие ссылочной целостности выполняется.
Если вышеприведённое условие не выполняется, говорят, что в базе данных нарушена ссылочная целостность. Такая БД не может нормально эксплуатироваться, так как в ней разорваны логические связи между зависимыми друг от друга фактами. Непосредственным результатом нарушения ссылочной целостности становится то, что корректным запросом не всегда удаётся получить корректный результат.
Пример
Так, в примере реляционная БД, состоящая из таблиц Address и Street, обеспечивает хранение адресов. При этом основная таблица, — Address, — содержит непосредственно номер дома и квартиры, а вместо имени улицы в поле Street имеет внешний ключ, ссылающийся на таблицу Street — справочник улиц. Очевидно, что полноценный адрес должен быть представлен двумя связанными записями в обеих названных таблицах, что технически выражается в условии: для любой записи таблицы Address в таблице Street должна существовать соответствующая запись, то есть запись со (Street.Key = Address.Street). Чтобы получить список полных адресов из таблиц такой структуры, когда в них соблюдается ссылочная целостность, достаточно применить к данным таблицам SQL-запрос:
select * from Address, Street where Address.Street = Street.Key
В данном примере, однако, ссылочная целостность нарушена. Две записи таблицы Address (Key = 887 и Key = 994) имеют в поле Street так называемые «висящие» ссылки — значения, которым не соответствуют записи в таблице Street (эти ссылки показаны красным цветом). Из-за этого результат вышеприведённого запроса не будет содержать этих двух записей — для них условие запроса не выполнится. И ещё одна запись не будет выбрана вышеприведённым запросом — запись таблицы Address с (Key = 85). Это вариант намеренного (и, в некоторых случаях, легального) нарушения ссылочной целостности — в поле внешнего ключа записан NULL (показано голубым цветом). Чтобы получить список всех адресов, даже тех, у которых не указана улица, необходимо использовать открытое соединение, в одном из вариантов синтаксиса записываемое так:
select * from Address left outer join Street on (Address.Street = Street.Key)
Если же требуется получить список, не включающий записи с «висящими» ссылками, то придётся усложнить запрос:
select * from Address left outer join Street on ((Address.Street = Street.Key) or (Address.Street is null))
Поддержание ссылочной целостности в БД
Причины нарушений
Правильно спроектированная и поддерживаемая база данных не допускает возможности нарушения ссылочной целостности. Тем не менее, такие нарушения могут появиться в ходе эксплуатации базы по целому ряду причин. Некоторые из них:
- Некорректная работа прикладного программного обеспечения. Понятно, что при ошибке в программе, выполняющей модификацию базы данных, база может быть модифицирована недопустимым образом, в результате чего образуются «висящие» ссылки. Программа может совершать ошибки следующих видов:
- Неполная запись объектов. Данные объекта размещаются в записях нескольких таблиц, а программа не записывает какую-то из них.
- Некорректная правка ссылки. Значение внешнего ключа изменяется на такое, которому не соответствует ни одна запись в связанной таблице.
- Правка первичного ключа без каскадного обновления. В таблице, на которую есть ссылки, правится первичный ключ, но при этом внешние ключи в связанных с ней таблицах остаются без изменения.
- Удаление записи без каскадного обновления. Из таблицы удаляется запись, на которую имеются ссылки по внешним ключам других таблиц, при этом в связанных записях внешние ключи не меняются. В результате все ссылающиеся на неё записи других таблиц становятся некорректными.
Пустые внешние ключи
Возможна ситуация, когда внешний ключ вместо ссылки на существующую запись в таблице БД содержит «отсутствующее значение» NULL. Такое положение можно трактовать как отсутствие какой-то части объекта. Хотя с точки зрения чистой теории это недопустимо, на практике иногда бывает удобно разрешить использование пустых внешних ключей. Чтобы корректно работать с группами связанных таблиц, допускающих пустые внешние ключи, используется специфическая операция языка SQL — открытое соединение (другое название — «внешнее соединение», англ. outer join).
Ссылочная целостность на триггерах
Возможно поддержание ссылочной целостности БД с использованием механизма триггеров. В этом случае для любой потенциально опасной операции над таблицей создаётся триггер, который производит необходимые проверки или даже изменяет данные в связанных таблицах, чтобы исключить потерю ссылок.
Так, для обеспечения каскадных изменений триггер может быть установлен на операцию изменения записи в таблице. Если окажется, что при редактировании изменилось значение ключевого поля, триггер должен произвести согласованные изменения во всех таблицах, связанных с данной, поменяв старое значение внешних ключей на новое.
Для исключения потери ссылок от некорректного редактирования внешнего ключа триггер должен при каждом изменении соответствующего поля проверять, имеется ли в связанной таблице запись с таким первичным ключом.
Для защиты от удаления записи, на которую имеются ссылки, триггер на связанной таблице должен при удалении проверять наличие ссылок и, в зависимости от необходимости, либо запрещать удаление, либо обнулять внешние ключи тем или иным образом.
Ссылочная целостность на внешних ключах
СУБД может иметь механизм автоматического поддержания ссылочной целостности, основанный на явном описании ссылок при создании БД. При описании таблиц БД программист явно описывает, какие поля таблиц являются внешними ключами и на какие таблицы они ссылаются. Эта информация сохраняется в служебных областях памяти БД. Любая операция, изменяющая данные в таблице, вызывает автоматическую проверку ссылочной целостности. При этом:
- При операции добавления или редактирования записи автоматически проверяется, ссылаются ли внешние ключи в этой записи на существующие записи в заявленных при описании связанных таблицах. Если выясняется, что операция приведёт к появлению некорректных ссылок, она не выполняется — система возвращает ошибку.
- При операции редактирования записи проверяется:
- если изменяется её первичный ключ и на данную запись имеются ссылки, то операция редактирования завершается с ошибкой;
- если изменяется какой-то из внешних ключей, хранящихся в этой записи, и после изменения внешний ключ будет ссылаться на несуществующую запись, то операция редактирования завершается с ошибкой.
- Запрет — удаление блокируется и возвращается ошибка.
- Каскадное удаление — в одной транзакции производится удаление данной записи и всех записей, ссылающихся на данную. Если на удаляемые записи также есть ссылки и настройки также требуют удаления, то каскадное удаление продолжается дальше. Таким образом, после удаления данной записи в базе не остаётся ни одной записи, прямо или косвенно ссылающейся на неё. Если хотя бы одну из ссылающихся записей удалить не получается (либо для неё настроен запрет, либо происходит какая-либо ещё ошибка), то все удаления запрещаются.
- Обнуление внешних ключей — во все внешние ключи записей, ссылающихся на данную, записывается псевдозначение NULL. Если хотя бы для одной из ссылающихся записей это невозможно (например, если поле внешнего ключа описано так, что его нельзя обнулять), то удаление запрещается.
1.2.2 Ссылочная целостность данных
Ссылочная целостность в реляционной базе данных — это согласованность между связанными таблицами. Ссылочная целостность обычно поддерживается путем комбинирования первичного ключа и внешнего ключа. Для соблюдения ссылочной целостности требуется, чтобы любое поле в таблице, объявленное внешним ключом, могло содержать только значения из поля первичного ключа родительской таблицы.
Поддержание ссылочной целостности обеспечивает семантическую адекватность совокупности взаимосвязанных реляционных отношений соответствующему фрагменту предметной области при выполнении транзакций (удаление, редактирование, добавление кортежей) в отдельных реляционных отношениях.
В практике реализации ссылочной целостности наиболее широко используются две стратегии: стратегия ограничения (запрета) и стратегия каскадирования, значительно реже — стратегия установки значений по умолчанию, стратегия игнорирования и стратегия установки неопределенного значения (в NULL).
Суть стратегии ограничения заключается в том, что накладывается запрет на транзакции, выполнение которых может повлечь за собой нарушение ссылочной целостности. Следует заметить, что данная стратегия является достаточно простой с точки зрения ее реализации. В рамках ее выполнения предстоит лишь проверить наличие в дочернем отношении кортежей, связанных с активным кортежем в родительском отношении. Под активным картежом будем понимать такой картеж, над которым выполняется транзакция. При выполнении такой транзакции, как удаление кортежа в основном отношении, сохранится ссылочная целостность, если будет реализовано следующее ограничение целостности: “При попытке удаления кортежа в реляционном отношении “Мастер” реализовывать стратегию ограничения (запрета на удаление), при условии, что в порожденном отношении “Услуга” существуют кортежи, непосредственно связанные с удаляемым”. Таким образом, при реализации данной стратегии выполнение операции удаления кортежа из основного отношения будет возможным, если в порожденном отношении не найдется кортежа, непосредственно связанного с удаляемым (для данного случая — если отсутствуют данные об услугах данного мастера). Заметим, в данном случае недопустимо использование стратегии ограничения для операции удаления кортежа в порожденном отношении. Наиболее приемлемой здесь будет стратегия игнорирования либо стратегия каскадирования.
Суть стратегии каскадирования заключается в том, что допускается выполнение необходимой транзакции и при этом вносятся соответствующие изменения в тех отношениях, которые связаны с текущем (с тем, в который в данный момент производится транзакция). Изменения в отношениях, связанных с текущем реализуются с целью не допустить нарушения ссылочной целостности и сохранить при этом все имеющиеся связи. Чаще всего изменение начинается в родительском отношении и каскадно выполняется в порожденном отношении. Следует заметить, что последнее может в свою очередь выступать в качестве материнского для каких-либо других отношений. В связи с этим может возникнуть необходимость соответствующих изменениях (транзакциях) и в этих отношениях. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это самая сложная стратегия, но она хороша тем, что при этом не нарушается связь между кортежами родительского и дочернего отношений.
Стратегия установки неопределенного значения допускает выполнение требуемой операции, при этом все возникающие некорректные значения внешних ключей должны быть изменены на null-значения. Эта стратегия имеет два недостатка. Во-первых, для нее требуется допустить использование null-значений. Во-вторых, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя. На практике такая стратегия используется крайне редко.
Как было отмечено ранее, в некоторых случаях для поддержания ссылочной целостности используется стратегия установки по умолчанию. В рамках данной стратегии разрешается выполнение требуемой операции, но все возникающие некорректные значения внешних ключей при этом изменяются на некоторое значение, которое принятое по умолчанию. Достоинство этой стратегии по сравнению с предыдущей в том, что она позволяет не пользоваться null-значеними. Недостатки заключаются в следующем. Во-первых, в родительском отношении должен быть некий кортеж, потенциальный ключ которого принят как значение по умолчанию для внешних ключей. В качестве такого «кортежа по умолчанию» обычно принимают специальный кортеж, заполненный нулевыми значениями (не null-значениями!). Этот кортеж нельзя удалять из родительского отношения, и в этом кортеже нельзя изменять значение потенциального ключа. Таким образом, не все кортежи родительского отношения становятся равнозначными, поэтому приходится прилагать дополнительные усилия для отслеживания этой неравнозначности. Это плата за отказ от использования null-значений. Во-вторых, как и в предыдущем случае, кортежи дочернего отношения теряют всякую связь с кортежами родительского отношения. Установить, с каким кортежем родительского отношения были связаны измененные кортежи дочернего отношения, после выполнения операции уже нельзя.
И, наконец, стратегия игнорирования (IGNORE), суть которой заключается в том, что разрешено выполнять любые транзакции, не обращая при этом внимание на нарушения ссылочной целостности.
Фактически такую стратегию даже нельзя назвать стратегией сохранения ссылочной целостности: в этом случае в дочернем отношении могут появляться некорректные значения внешних ключей, и вся ответственность за целостность базы данных ложится на пользователя, его внимательность и корректность при выполнении различных транзакций.
Таким образом, на данный момент выделяется шесть видов ограничений семантической целостности и три стратегии ограничений ссылочной целостности. Необходимость поддержания семантической целостности данных обусловлена различными видами информации, содержащейся в базе, что и приводит к такому делению, как ограничение по интервалу, перечислимому значению и т.д. Ограничения же ссылочной целостности имеют значение в связи с логикой построения отношений между данными, содержащимися в базе.
Определив виды семантической и ссылочной целостности, перейдем к рассмотрению организации ограничений целостности средствами СУБД MySQL на примере фрагмента информационной системы «Салон».