что база данных не должна содержать никаких
Базы данных: конспект лекций.
4. Ограничения ссылочной целостности.
Итак, ограничение уровня баз данных включает ограничение ссылочной целостности внешних ключей (fоrеign кеу). Коротко мы уже упоминали об этом, когда говорили об ограничениях ссылочной целостности при создании базового отношения и внешних ключах. Теперь настало время поговорить об этом понятии более подробно.
Как мы уже говорили раньше, внешний ключ объявляемого базового отношения ссылается на первичный или кандидатный ключ какого-то другого (чаще всего) базового отношения. Напомним, что при этом отношение, на которое ссылается внешний ключ, называется ссылочным или родительским, потому что оно как бы «порождает» один атрибут или несколько атрибутов в ссылающемся базовом отношении. А, в свою очередь, отношение, содержащее внешний ключ, называется дочерним, тоже по вполне понятным причинам.
В чем же заключается ограничение ссылочной целостности? А заключается оно в том, что каждому значению внешнего ключа дочернего отношения обязательно должно соответствовать значение какого-либо ключа отношения родительского, если только значение внешнего ключа не содержит Null-значений в каких-либо атрибутах.
Кортежи дочернего отношения, нарушающие это условие, называются висящими.
Действительно, если внешний ключ дочернего отношения ссылается на атрибут, которого на самом деле в родительском отношении нет, то он не ссылается ни на что. Именно таких ситуаций и требуется всячески избегать, это и означает поддерживать ссылочную целостность.
Но, зная, что ни одна база данных никогда не допустит создания висящего кортежа, разработчики следят за тем, чтобы изначально висящих кортежей в базе данных не было и все имеющиеся ключи ссылались на вполне реальный атрибут отношения родительского. Но тем не менее бывают ситуации, когда висящие кортежи образуются уже в процессе функционирования базы данных. Что это за ситуации? Известно, что при удалении кортежей из родительского отношения или при обновлении значения ключа кортежа родительского отношения ссылочная целостность может нарушиться, т. е. могут возникнуть висящие кортежи.
Для исключения возможности их появления при объявлении значения внешнего ключа задается одно из трех имеющихся правил поддержания ссылочной целостности, применяемых соответственно при обновлении значения ключа в родительском отношении (т. е., как мы уже упоминали раньше, оn uрdаtе) или при удалении кортежа из родительского отношения (оn dеlеtе). Необходимо отметить, что добавление нового кортежа в родительское отношение не может нарушить ссылочную целостность по вполне понятным причинам. Ведь, если этот кортеж только что добавили в базовое отношение, раньше на него не мог ссылаться ни один атрибут по причине его отсутствия!
Итак, что же это за три правила, применяющиеся для поддержания в базах данных ссылочной целостности? Перечислим их.
1. Rеstriсt, или правило ограничения. Если мы при задании нашего базового отношения, при объявлении внешних ключей в ограничении ссылочной целостности применили это правило ее поддержания, то обновление ключа в родительском отношении или удаление кортежа из родительского отношения просто не может быть выполнено в том случае, если на этот кортеж ссылается хотя бы один кортеж дочернего отношения, т. е. операция Rеstriсt банально запрещает производить какие-либо действия, могущие привести к появлению висящих кортежей.
Проиллюстрируем применение этого правила следующим примером.
Пусть даны два отношения:
Мы видим, что кортежи дочернего отношения (2, …) и (2, …) ссылаются на кортеж (…, 2) родительского отношения, а кортеж (3, …) дочернего отношения ссылается на кортеж (…, 3) родительского отношения. Кортеж (100, …) дочернего отношения является висящим, он недопустим.
Здесь только кортежи родительского отношения (…, 1) и (…, 4) допускают обновление значений ключа и удаление кортежей, потому что на них не ссылается ни один из внешних ключей дочернего отношения.
Составим оператор создания базового отношения, включающего в себя объявление всех вышеназванных ключей:
Сrеаtе tаblе Родительское отношение.
рrimаrу кеу (Рrimаrу_кеу).
Сrеаtе tаblе Дочернее отношение.
fоrеign кеу (Fоrеign_кеу) rеfеrеnсеs Родительское отношение (Рrimаrу_кеу).
оn uрdаtе Rеstriсt.
оn dеlеtе Rеstriсt.
2. Саsсаdе, или правило каскадной модификации. Если при объявлении внешних ключей в нашем базовом отношении мы использовали правило поддержания ссылочной целостности Саsсаdе, то обновление ключа в родительском отношении или удаление кортежа из родительского отношения вызывает автоматическое обновление или удаление соответствующих ключей и кортежей дочернего отношения.
Рассмотрим пример, чтобы лучше понять механизм работы правила каскадной модификации. Пусть даны уже знакомые нам базовые отношения из предыдущего примера:
Допустим, мы в таблице, задающей отношение «Родительское отношение» обновим некоторые кортежи, а именно заменим кортеж (…, 2) на кортеж (…, 20), т. е. получим новое отношение:
И пусть при этом в операторе создания нашего базового отношения «Дочернее отношение» при объявлении внешних ключей мы использовали правило поддержания ссылочной целостности Саsсаdе, т. е. оператор создания наших базовых отношений выглядит следующим образом:
Сrеаtе tаblе Родительское отношение.
рrimаrу кеу (Рrimаrу_кеу).
Сrеаtе tаblе Дочернее отношение.
fоrеign кеу (Fоrеign_кеу) rеfеrеnсеs Родительское отношение (Рrimаrу_кеу).
оn uрdаtе Саsсаdе.
оn dеlеtе Саsсаdе.
Тогда что же произойдет с отношением дочерним при обновлении родительского отношения указанным выше образом? Оно примет следующий вид:
Таким образом, действительно, правило Саsсаdе обеспечивает каскадное обновление всех кортежей дочернего отношения в ответ на обновления отношения родительского.
3. Sеt Null, или правило присвоения Null-значений. Если же мы в операторе создания нашего базового отношения при объявлении внешних ключей применяем правило поддержания ссылочной целостности Sеt Null, то обновление ключа родительского отношения или удаление кортежа из родительского отношения влечет за собой автоматическое присвоение Null-значений тем атрибутам внешнего ключа дочернего отношения, который Null-значения допускают. Следовательно, правило применимо, если такие атрибуты имеются.
Рассмотрим пример, который мы уже использовали ранее. Пусть нам даны два базовых отношения:
Как можно заметить, атрибуты дочернего отношения допускают Null-значения, следовательно, правило Sеt Null в данном конкретном случае применимо.
Допустим теперь, что из родительского отношения был удален кортеж (…, 1), а кортеж (…, 2) обновлен, как и в предыдущем примере. Таким образом, родительское отношение принимает следующий вид:
Тогда с учетом того, что при объявлении внешних ключей дочернего отношения нами применялось правило поддержания ссылочной целостности Sеt Null, дочернее отношение примет следующий вид:
На кортеж (…, 1) не ссылался ни один ключ дочернего отношения, поэтому его удаление не влечет за собой никаких последствий.
Сам оператор создания базового отношения с использованием правила Sеt Null при объявлении внешних ключей отношения выглядит следующим образом:
Сrеаtе tаblе Родительское отношение.
рrimаrу кеу (Рrimаrу_кеу).
Сrеаtе tаblе Дочернее отношение.
fоrеign кеу (Fоrеign_кеу) rеfеrеnсеs Родительское отношение (Рrimаrу_кеу).
оn uрdаtе Sеt Null.
оn dеlеtе Sеt Null.
Итак, мы видим, что наличие трех различных правил поддержания ссылочной целостности обеспечивают то, что во фразах оn uрdаtе и оn dеlеtе функции могут быть разными.
Необходимо помнить и понимать, что вставка кортежей в дочернее отношение или обновление значений ключа дочерних отношений не будут выполнены, если это будет приводить к нарушению ссылочной целостности, т. е. к появлению так называемых висящих кортежей. Удаление же кортежей из дочернего отношения ни при каких условиях не может привести к нарушению ссылочной целостности.
Интересно, что дочернее отношение одновременно может выступать и родительским со своими правилами поддержания ссылочной целостности, если внешние ключи других базовых отношений ссылаются на какие-то его атрибуты, как на первичные ключи.
Если у программистов возникает желание обеспечить выполнение ссылочной целостности какими-то отличными от приведенных стандартных правил, то процедурная поддержка таких нестандартных правил поддержания ссылочной целостности обеспечивается с помощью так называемых триггеров. К сожалению, подробное рассмотрение этого понятия не сходит в наш курс лекций.
4. Ограничения ссылочной целостности
4. Ограничения ссылочной целостности
Итак, ограничение уровня баз данных включает ограничение ссылочной целостности внешних ключей (foreign key). Коротко мы уже упоминали об этом, когда говорили об ограничениях ссылочной целостности при создании базового отношения и внешних ключах. Теперь настало время поговорить об этом понятии более подробно.
Как мы уже говорили раньше, внешний ключ объявляемого базового отношения ссылается на первичный или кандидатный ключ какого-то другого (чаще всего) базового отношения. Напомним, что при этом отношение, на которое ссылается внешний ключ, называется ссылочным или родительским, потому что оно как бы «порождает» один атрибут или несколько атрибутов в ссылающемся базовом отношении. А, в свою очередь, отношение, содержащее внешний ключ, называется дочерним, тоже по вполне понятным причинам.
В чем же заключается ограничение ссылочной целостности? А заключается оно в том, что каждому значению внешнего ключа дочернего отношения обязательно должно соответствовать значение какого-либо ключа отношения родительского, если только значение внешнего ключа не содержит Null-значений в каких-либо атрибутах.
Кортежи дочернего отношения, нарушающие это условие, называются висящими.
Действительно, если внешний ключ дочернего отношения ссылается на атрибут, которого на самом деле в родительском отношении нет, то он не ссылается ни на что. Именно таких ситуаций и требуется всячески избегать, это и означает поддерживать ссылочную целостность.
Но, зная, что ни одна база данных никогда не допустит создания висящего кортежа, разработчики следят за тем, чтобы изначально висящих кортежей в базе данных не было и все имеющиеся ключи ссылались на вполне реальный атрибут отношения родительского. Но тем не менее бывают ситуации, когда висящие кортежи образуются уже в процессе функционирования базы данных. Что это за ситуации? Известно, что при удалении кортежей из родительского отношения или при обновлении значения ключа кортежа родительского отношения ссылочная целостность может нарушиться, т. е. могут возникнуть висящие кортежи.
Для исключения возможности их появления при объявлении значения внешнего ключа задается одно из трех имеющихся правил поддержания ссылочной целостности, применяемых соответственно при обновлении значения ключа в родительском отношении (т. е., как мы уже упоминали раньше, on update) или при удалении кортежа из родительского отношения (on delete). Необходимо отметить, что добавление нового кортежа в родительское отношение не может нарушить ссылочную целостность по вполне понятным причинам. Ведь, если этот кортеж только что добавили в базовое отношение, раньше на него не мог ссылаться ни один атрибут по причине его отсутствия!
Итак, что же это за три правила, применяющиеся для поддержания в базах данных ссылочной целостности? Перечислим их.
1. Restrict, или правило ограничения. Если мы при задании нашего базового отношения, при объявлении внешних ключей в ограничении ссылочной целостности применили это правило ее поддержания, то обновление ключа в родительском отношении или удаление кортежа из родительского отношения просто не может быть выполнено в том случае, если на этот кортеж ссылается хотя бы один кортеж дочернего отношения, т. е. операция Restrict банально запрещает производить какие-либо действия, могущие привести к появлению висящих кортежей.
Проиллюстрируем применение этого правила следующим примером.
Пусть даны два отношения:
Мы видим, что кортежи дочернего отношения (2, …) и (2, …) ссылаются на кортеж (…, 2) родительского отношения, а кортеж (3, …) дочернего отношения ссылается на кортеж (…, 3) родительского отношения. Кортеж (100, …) дочернего отношения является висящим, он недопустим.
Здесь только кортежи родительского отношения (…, 1) и (…, 4) допускают обновление значений ключа и удаление кортежей, потому что на них не ссылается ни один из внешних ключей дочернего отношения.
Составим оператор создания базового отношения, включающего в себя объявление всех вышеназванных ключей:
Create table Родительское отношение
primary key (Primary_key)
Create table Дочернее отношение
foreign key (Foreign_key) references Родительское отношение (Primary_key)
on update Restrict
on delete Restrict
2. Cascade, или правило каскадной модификации. Если при объявлении внешних ключей в нашем базовом отношении мы использовали правило поддержания ссылочной целостности Cascade, то обновление ключа в родительском отношении или удаление кортежа из родительского отношения вызывает автоматическое обновление или удаление соответствующих ключей и кортежей дочернего отношения.
Рассмотрим пример, чтобы лучше понять механизм работы правила каскадной модификации. Пусть даны уже знакомые нам базовые отношения из предыдущего примера:
Допустим, мы в таблице, задающей отношение «Родительское отношение» обновим некоторые кортежи, а именно заменим кортеж (…, 2) на кортеж (…, 20), т. е. получим новое отношение:
И пусть при этом в операторе создания нашего базового отношения «Дочернее отношение» при объявлении внешних ключей мы использовали правило поддержания ссылочной целостности Cascade, т. е. оператор создания наших базовых отношений выглядит следующим образом:
Create table Родительское отношение
primary key (Primary_key)
Create table Дочернее отношение
foreign key (Foreign_key) references Родительское отношение (Primary_key)
on update Cascade
on delete Cascade
Тогда что же произойдет с отношением дочерним при обновлении родительского отношения указанным выше образом? Оно примет следующий вид:
Таким образом, действительно, правило Cascade обеспечивает каскадное обновление всех кортежей дочернего отношения в ответ на обновления отношения родительского.
3. Set Null, или правило присвоения Null-значений. Если же мы в операторе создания нашего базового отношения при объявлении внешних ключей применяем правило поддержания ссылочной целостности Set Null, то обновление ключа родительского отношения или удаление кортежа из родительского отношения влечет за собой автоматическое присвоение Null-значений тем атрибутам внешнего ключа дочернего отношения, который Null-значения допускают. Следовательно, правило применимо, если такие атрибуты имеются.
Рассмотрим пример, который мы уже использовали ранее. Пусть нам даны два базовых отношения:
Как можно заметить, атрибуты дочернего отношения допускают Null-значения, следовательно, правило Set Null в данном конкретном случае применимо.
Допустим теперь, что из родительского отношения был удален кортеж (…, 1), а кортеж (…, 2) обновлен, как и в предыдущем примере. Таким образом, родительское отношение принимает следующий вид:
Тогда с учетом того, что при объявлении внешних ключей дочернего отношения нами применялось правило поддержания ссылочной целостности Set Null, дочернее отношение примет следующий вид:
На кортеж (…, 1) не ссылался ни один ключ дочернего отношения, поэтому его удаление не влечет за собой никаких последствий.
Сам оператор создания базового отношения с использованием правила Set Null при объявлении внешних ключей отношения выглядит следующим образом:
Create table Родительское отношение
primary key (Primary_key)
Create table Дочернее отношение
foreign key (Foreign_key) references Родительское отношение (Primary_key)
on update Set Null
on delete Set Null
Итак, мы видим, что наличие трех различных правил поддержания ссылочной целостности обеспечивают то, что во фразах on update и on delete функции могут быть разными.
Необходимо помнить и понимать, что вставка кортежей в дочернее отношение или обновление значений ключа дочерних отношений не будут выполнены, если это будет приводить к нарушению ссылочной целостности, т. е. к появлению так называемых висящих кортежей. Удаление же кортежей из дочернего отношения ни при каких условиях не может привести к нарушению ссылочной целостности.
Интересно, что дочернее отношение одновременно может выступать и родительским со своими правилами поддержания ссылочной целостности, если внешние ключи других базовых отношений ссылаются на какие-то его атрибуты, как на первичные ключи.
Если у программистов возникает желание обеспечить выполнение ссылочной целостности какими-то отличными от приведенных стандартных правил, то процедурная поддержка таких нестандартных правил поддержания ссылочной целостности обеспечивается с помощью так называемых триггеров. К сожалению, подробное рассмотрение этого понятия не сходит в наш курс лекций.
Данный текст является ознакомительным фрагментом.
Продолжение на ЛитРес
Читайте также
Приобретение ссылочной массы
Приобретение ссылочной массы Покупка ссылок с целью «подкачки» траста требует бдительности, так как доноры должны быть исключительно трастовыми площадками и передавать большой вес.В SeoPul реализована такая функция, как закупка сугубо трастовых ссылок. Система
Наращивание ссылочной массы и ожидания от поискового продвижения
Наращивание ссылочной массы и ожидания от поискового продвижения Количество внешних ссылок, ведущих на страницы разных тематических кластеров, относится к числу простых метрик, улучшение которых почти наверняка улучшит позиции портала в поисковой выдаче. Ранее я уже
Обеспечение ссылочной целостности с помощью индексов
Расширенные возможности поддержки ссылочной целостности с помощью внешнего ключа
Расширенные возможности поддержки ссылочной целостности с помощью внешнего ключа Обычно вполне достаточно декларативного варианта ограничения внешнего ключа, при котором сервер только следит за тем, чтобы в таблицу с внешним ключом нельзя было вставить некорректные
Глава 19. ПОДДЕРЖКА ЦЕЛОСТНОСТИ ВАШИХ ДАННЫХ
Глава 19. ПОДДЕРЖКА ЦЕЛОСТНОСТИ ВАШИХ ДАННЫХ РАНЕЕ В ЭТОЙ КНИГЕ, МЫ УКАЗЫВАЛИ НА ОПРЕДЕЛЕННЫЕ связи которые существуют между некоторыми полями наших типовых таблиц. Поле snum таблицы Заказчиков, например, соответствует полю snum в таблице Продавцов и таблице Порядков. Поле cnum
3.5. Контроль целостности с Xintegrity
3.5. Контроль целостности с Xintegrity Xintegrity – удобная утилита, которая обнаруживает любое, даже самое незначительное изменение файла практически неограниченного размера. Принцип ее работы прост: первоначально создается список файлов и каталогов, целостность которых
Использование ссылочной целостности для поддержания непротиворечивости данных
Использование ссылочной целостности для поддержания непротиворечивости данных Когда таблицы связаны между собой посредством отношений, данные в каждой из связанных таблиц должны оставаться согласованными друг с другом. Ссылочная целостность справляется с этой
3. Ограничение целостности по состоянию
3. Ограничение целостности по состоянию Ограничение целостности реляционного объекта данных по состоянию – это так называемый инвариант данных.При этом целостность следует уверенно отличать от безопасности, которая, в свою очередь, подразумевает защиту данных от
Ограничения целостности
Ограничения целостности
Ограничения целостности Ограничение NOT NULL Firebird не поддерживает атрибут указания допустимости пустого значения, как это делают некоторые нестандартные СУБД. В соответствии со стандартами все столбцы в Firebird могут содержать пустое значение, если не будет явно указано
Действия триггеров по изменению правил целостности
Действия триггеров по изменению правил целостности Очевидно, что правила целостности применяются, когда происходят изменения данных, влияющих на отношение. При этом правила по умолчанию не всегда подходят для всех требований. Мы можем захотеть перекрыть правило,
Предложения действия ссылочной целостности
Предложения действия ссылочной целостности Триггеры ссылочной целостности являются модулями компилированного кода, создаваемыми ядром сервера, когда вы объявляете ограничение ссылочной целостности для ваших таблиц. Включив предложения действия ON UPDATE и ON DELETE В
Содержание важнее целостности
Содержание важнее целостности То, что имеет смысл «здесь», может потерять его «там»Должны ли действия задаваться кнопками или ссылками? Это зависит от действия. Должны ли даты выбираться из списка или из сетки календаря? Это зависит от того, где будут показаны даты и
Ограничения целостности баз данных
Ограничения целостности баз данных — это специальные средства в базах данных, главное назначение которых — не допустить попадания в базу ошибочных данных, например — тридцатый день в феврале или восьмой день недели.
Содержание
[править] Категории ограничений
Все ограничения целостности можно разделить на три категории:
[править] Ограничение на значение столбцов
[править] Первичный ключ (primary key)
Используется для обеспечения уникальности данных в столбцах и, в основном, для обеспечения ссылок на другие таблицы посредством связывания их внешними ключами.
[править] Внешний ключ (foreign key)
Применяется вместе с определённым раннее первичным ключом или же ограничением уникальности (unique) в связанной таблице. Условие на значение внешнего ключа одной таблицы ставит в соответствие один или несколько столбцов другой таблицы.
[править] Ограничение уникальности (unique)
Назначается чтобы запретить повторение значений в столбце таблицы. Для столбца, на котором определено ограничение первичного ключа, не может быть определено ограничение уникальности, так как уникальный индекс данного столбца уже создан.
[править] Проверочное ограничение (check)
Устанавливает, какие значения может хранить столбец. Это ограничение, например, можно использовать для столбца, хранящего номера квартир в многоквартирном доме.
[править] Ссылочная целостность
Ссылочная целостность обеспечивается системой первичных и внешних ключей. Этими средствами можно гарантировать, что у нас не будет ссылок на несуществующие объекты таблицы.
[править] Доменная целостность
Отвечает за то, чтобы в соответствующих полях базы данных были соответствующие значения. Например, номер телефона, как правило, обозначается цифрами, а имя или фамилия — буквами. В базах данных такая целостность зачастую обеспечивается запретом пустых значений (NOT NULL), триггерами, ключами а так же хранимыми процедурами.
[править] Целостность сущностей
Заключается в том, что любое отношение должно обладать первичным ключом или проверкой уникальности. Иными словами, главная задача целостности сущностей — сделать так, чтобы данные об одном объекте (сущности) не попали в базу данных дважды, так как при несоблюдении данного ограничения в базе данных может храниться противоречивая информация об одном объекте. Поддержание целостности сущностей осуществляется системой управления базой данных (СУБД).