Ошибки целостности ссылок

Материал из Seo Wiki — Поисковая Оптимизация и Программирование

Перейти к: навигация, поиск

Ссы́лочная це́лостность (англ. 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 (SQL). Если хотя бы для одной из ссылающихся записей это невозможно (например, если поле внешнего ключа описано так, что его нельзя обнулять), то удаление запрещается.

Ссылки

cs:Referenční integrita
de:Referentielle Integrität
en:Referential integrity
es:Integridad referencial
fr:Intégrité référentielle
ja:参照整合性
nl:Referentiële integriteit
no:Referanseintegritet
pt:Integridade referencial

→

First of all, it’s almost impossible to make it really work correctly. To have any chance of working right, you need to wrap a lot of the cascading modifications as transactions, so you don’t have things out of sync while you’ve changed one part of the database, but are still updating others that depend on the first. This means code that should be simple and aware only of business logic suddenly needs to know about all sorts of concurrency issues.

Second, keeping it working is almost impossible to hope for — every time anybody touches the business logic, they need to deal with those concurrency issues again.

Third, this makes the referential integrity difficult to understand — in the future, when somebody wants to learn about your database structure, they’ll have to reverse engineer it out of your business logic. With it in the database, it’s separate, so what you have to look at only deals with referential integrity, not all sorts of unrelated issues. You have (for example) direct chains of logic showing what a modification to a particular field will trigger. At least for quite a few databases, that logic can be automatically extracted and turned into fairly useful documentation (e.g., tree diagrams showing dependencies). Extracting the same kind of information from the BLL is more likely to be a fairly serious project.

There are certainly some points in the other direction, and reasons to craft all of this by hand — scalability and performance being the most obvious. When/if you go that route, however, you should be aware of what you’re giving up to get that performance. In some cases, it’s a worthwhile tradeoff — but in other cases it’s not, and you need information to make a reasoned decision.

разрешено вставлять только эти значения в атрибут ссылки, которые уже присутствуют в значении ссылочного атрибута. Вставка значения в атрибут ссылки, которого нет в значении атрибута ссылки, нарушает ограничение ссылочной целостности.

Что такое нарушение ограничения на целостность ссылки?

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

Что нарушает референциальную целостность?

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

Должен ли я обеспечить референциальную целостность?

Когда вы создаете взаимосвязь между двумя таблицами , обычно это хорошая идея для обеспечения референциальной целостности. Референциальная целостность сохраняет данные и гарантирует, что вы не случайно не изменяете или не удаляете связанные данные в одной таблице, но не в другой.

Что такое ссылка целостность с примером?

Референциальная целостность требует, чтобы внешний ключ имел соответствующий первичный ключ или он должен быть нулевым. … Примеры ограничения ссылки на целостность в базе данных клиента/заказов Компании: Клиент (CUSTID, CUSTNAME) Заказ (OrderID, CUSTID, ORDEDATE)

Как вы справляетесь с референциальной целостностью?

Существует ряд способов, которыми может быть обработано нарушение референциальной целостности. Три общих метода – это отклонение, аннулирование или каскад заявление об стрельбе .

Каковы правила ссылочной целостности?

Правило ссылочной целостности – это правило, определенное на ключе (столбец или набор столбцов) в одной таблице, которое гарантирует, что значения в этом ключе соответствуют значениям в ключе в соответствующей таблице (ссылочное значение).

Что такое нарушение ограничения?

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

Когда нарушаются ограничения иностранного ключа?

это вызывает нарушение только в том случае, если кортеж в отношении 1 удален , на который ссылается внешний ключ из других кортежей таблицы 2 в базе данных, если такая удаление происходит, то значения в кортеже Иностранный ключ в таблице 2 станет пустым, что в конечном итоге нарушит ограничение целостности ссылки.

Каковы ограничения целостности?

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

Что из следующего является ограничением ссылки на целостность?

Ограничение ссылочной целостности определяется как часть ассоциации между двумя типами сущностей. Определение ограничения ссылки на целостность указывает следующую информацию: Основной конец ограничения . (Тип сущности, ключ объекта которого ссылается зависимым концом.)

Как проверить на предмет целостности ссылки в SQL?

Если это так, то вы можете использовать “DBCC CheckConstraints” для проверки целостности указанного ограничения или всех ограничений в указанной таблице в текущей базе данных. Вы можете использовать SYS. Взгляд каталога Foreign_keys, чтобы проверить, ограничено ли ограничение, а также «изменить таблицу», чтобы включить его.

Что из следующего не является ограничением целостности?

Что из следующего не является ограничением целостности? Объяснение: Идентичный – это не разрешенное ограничение целостности в SQL. Not NULL предотвращает нулевые значения и уникальные только позволяют вводить уникальные значения. … Объяснение: Не нулевое ограничение гарантирует, что данные введены в базу данных.

Что из следующего является ограничением внешнего ключа?

Иностранный ключ – это столбец (или комбинация столбцов) в таблице, значения которых должны соответствовать значениям столбца в какой -то другой таблице . Ограничения иностранного ключа обеспечивают целостность ссылки, которая по существу говорит, что если значение столбца A относится к значению столбца B, то значение B столбца B должно существовать.

Каковы три типа правил для референциальной целостности?

Правила об ограничении ссылок

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

Какова цель референциальной целостности?

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

Что значит обеспечить целостность референции?

ссылочная целостность – это свойство данных, в котором говорится, что все его ссылки действительны . … Некоторые системы управления реляционными базами данных (RDBMS) могут обеспечить целостность ссылки, обычно либо путем удаления строк иностранных ключей, так и для поддержания целостности, либо путем возврата ошибки и не выполняя удаление.

Как избегать референциальной целостности?

Используйте каскадные делеции с осторожностью

Вы можете устранить наиболее референциальные проблемы целостности, тщательно контролируя процесс обновления. В некоторых случаях вам приходится каскады делеции от родительской таблицы до своих детей.

Как вы проверяете референциальную целостность?

Проверка целостности ссылки

1. Настройка относительно того, с каким объектом (таблица основных данных или объект данных) следует проверять, выполняется в самом InfoObject. …
2. Выбором в структуре связи эта проверка может быть определена для конкретной характеристики или для всей характеристики.

Как добавлять ограничения на целостность референтной целостности?

изменять таблицу dept_tab добавить первичный ключ (deptno); Затем создайте конференциальную целостную ограничение на столбце DEPTNO таблицы EMP_TAB, который ссылается на первичный ключ таблицы DEPT_TAB. Например: ALTER TABLE EMP_TAB Добавить внешний ключ (DEPTNO) Ссылки DEPT_TAB (DEPTNO);

может ли иностранный ключ быть нулевым?

Иностраненному ключу может быть назначено имя ограничения. … внешний ключ, содержащий нулевые значения, не может соответствовать значениям родительского ключа, поскольку родительский ключ по определению не может иметь нулевых значений. Тем не менее, нулевое значение иностранного ключа всегда действителен, независимо от значения какой-либо из ее не нулевых частей.

Что такое ограничение ссылочной целостности иностранного ключа?

Ограничения иностранного ключа (также известные как референциальные ограничения или ограничения ссылочной целостности) позволяют определить необходимые отношения между таблицами и внутри таблиц . … ссылочная целостность – это состояние базы данных, в которой все значения всех иностранных ключей действительны.

Почему я не могу применять референциальную целостность?

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

Ссылочная целостность—это состояние реляционной базы данных в которой записи не могут ссылаться на несуществующие записи в этой базе данных.

FOREIGN KEY—особый вид ограничения(constraint) MySQL, которое позволяет предотвратить нарушение ссылочной целостности при удалении/изменении информации в таблицах предках. Поддержка FOREIGN KEY поддерживается только для таблиц типа InnoDB

Пример нарушения ссылочной целостности

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

mysql> SELECT * FROM catalogs;                                                                           
+------------+-------------------------------------+                                                      
| id_catalog | name                                |
+------------+-------------------------------------+                                                      
|          1 | Процессоры                          |                                                      
|          2 | Материнские платы                   |
|          3 | Видеоадаптеры                       |
|          4 | Жёсткие диски                       |
|          5 | Оперативная память                  |
+------------+-------------------------------------+

mysql> SELECT * FROM products;                                                                           
+------------+-------------------------------+------------+
| id_product | name                          | id_catalog |
+------------+-------------------------------+------------+
|          1 | Celeron 1.8                   |          1 |
|          2 | Celeron 2.0GHz                |          1 |
|          3 | Celeron 2.4GHz                |          1 |
|          4 | Celeron D 320 2.4GHz          |          1 |
|          5 | Celeron D 325 2.53GHz         |          1 |
|          6 | Celeron D 315 2.26GHz         |          1 |
|          7 | Intel Pentium 4 3.2GHz        |          1 |
|          8 | Intel Pentium 4 3.0GHz        |          1 |
|          9 | Intel Pentium 4 3.0GHz        |          1 |
|         10 | Gigabyte GA-8I848P-RS         |          2 |
|         11 | Gigabyte GA-8IG1000           |          2 |
|         12 | Gigabyte GA-8IPE1000G         |          2 |
|         13 | Asustek P4C800-E Delux        |          2 |
|         14 | Asustek P4P800-VM\L i865G     |          2 |
|         15 | Epox EP-4PDA3I                |          2 |
|         16 | ASUSTEK A9600XT/TD            |          3 |
|         17 | ASUSTEK V9520X                |          3 |
|         18 | SAPPHIRE 256MB RADEON 9550    |          3 |
|         19 | GIGABYTE AGP GV-N59X128D      |          3 |
|         20 | Maxtor 6Y120P0                |          4 |
|         21 | Maxtor 6B200P0                |          4 |
|         22 | Samsung SP0812C               |          4 |
|         23 | Seagate Barracuda ST3160023A  |          4 |
|         24 | Seagate ST3120026A            |          4 |
|         25 | DDR-400 256MB Kingston        |          5 |
|         26 | DDR-400 256MB Hynix Original  |          5 |
|         27 | DDR-400 256MB PQI             |          5 |
|         28 | DDR-400 512MB Kingston        |          5 |
|         29 | DDR-400 512MB PQI             |          5 |
|         30 | DDR-400 512MB Hynix           |          5 |
+------------+-------------------------------+------------+

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

mysql> DELETE FROM catalogs WHERE name = 'Процессоры';

mysql> SELECT * FROM catalogs;
+------------+-------------------------------------+
| id_catalog | name                                |
+------------+-------------------------------------+
|          2 | Материнские платы                   |
|          3 | Видеоадаптеры                       |
|          4 | Жёсткие диски                       |
|          5 | Оперативная память                  |
+------------+-------------------------------------+

mysql> SELECT * FROM products WHERE id_catalog = 1;
+------------+------------------------+------------+
| id_product | name                   | id_catalog |
+------------+------------------------+------------+
|          1 | Celeron 1.8            |          1 |
|          2 | Celeron 2.0GHz         |          1 |
|          3 | Celeron 2.4GHz         |          1 |
|          4 | Celeron D 320 2.4GHz   |          1 |
|          5 | Celeron D 325 2.53GHz  |          1 |
|          6 | Celeron D 315 2.26GHz  |          1 |
|          7 | Intel Pentium 4 3.2GHz |          1 |
|          8 | Intel Pentium 4 3.0GHz |          1 |
|          9 | Intel Pentium 4 3.0GHz |          1 |
+------------+------------------------+------------+

Это явление называется нарушением ссылочной целостности

На ссылочную целостность базы данных как правило оказывают четыре типа изменений:

• Добавление новой записи в таблице-потомке. Например добавление новой товарной позиции в таблицу products. Важно заметить что важную роль играет изменение именно таблицы-потомка, т.к изменение таблицы-предка (catalogs) не приведет к нарушению ссылочной целостности, т.к наличие пустой категории товаров допустимо
• Обновление внешнего ключа в таблице-потомке. Эта ситуация похожа на первую и может произойти при изменении у товара ссылки на несуществующий раздел каталога, например товар с id_catalog равным 50
• Удаление записи из таблицы-предка. Эта ситуация рассмотрена выше.
• Изменение записи в таблице-предке. Эта ситуация отличается от рассмотренной выше тем что категория каталога не удаляется а принимает новый id

Обработка изменений при помощи FOREIGN KEY

Для того что бы контролировать ссылочную целостность в базе данных необходимо что бы таблицы были связаны при помощи конструкции FOREIGN KEY, которая имеет вид:

FOREIGN KEY [index_name] (index_col_name, …)
REFERENCES tbl_name (index_col_name,…)
[ON DELETE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]
[ON UPDATE {RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT}]

FOREIGN KEY — используется при создании/изменении таблиц-потомков таблицах. В рамках данной статьи FOREIGN KEY, следует использовать в таблице products. Данная конструкция позволяет задать в таблице-потомке внешний ключ с именем index_name на столбцах таблицы которые перечисляется в круглых скобках. Можно использовать один или несколько столбцов.

Ключевое слово REFERENCES задаёт таблицу-предка tbl_name на которую будет ссылаться внешний ключ. Поля таблицы-предка задаются в круглых скобках, один или несколько.

Необязательные конструкции ON DELETE и ON UPDATE, определяют поведение MySQL при удалении/обновлении записей из таблицы-предка.

Допустимые параметры для ключевых слов ON DELETE и ON UPDATE:

• RESTRICT — Если в таблице-потомке существуют записи ссылающиеся на первичный ключ таблицы-предка то при удалении или обновлении записей с этим первичным ключом в таблице предке, будет возвращена ошибка. Ошибка будет возвращаться до тех пор пока не останется ни одной ссылки в таблице потомке. В MySQL данный параметр означает то же самое что и NO ACTION
• CASCADE — При удалении/обновлении записей в таблице-предке, будут так же обновлены/удалены записи из таблицы-потомка с существующим первичным ключом
• SET NULL — При удалении/обновлении записей в таблице-предке, записи из таблицы-потомка с существующим первичным ключом будут обновлены на NULL
• NO ACTION — При удалении/обновлении записей в таблице-предке, записи из таблицы-потомка с существующим первичным ключом изменены не будут. В MySQL данный параметр означает то же самое что и RESTRICT
• SET DEFAULT — Это действие зарезервировано но не обрабатывается в InnoDB

Добавление для таблицы products из примера статьи конструкции:

ALTER TABLE products ADD CONSTRAINT fk_catalog
FOREIGN KEY (id_catalog) REFERENCES catalogs (id_catalog)
    ON DELETE CASCADE
    ON UPDATE CASCADE

приведет к тому что изменения таблицы catalogs приведет к автоматическому изменению таблицы products.

Проверку ограничения внешнего ключа можно отключить присвоив системной переменной FOREIGN_KEY_CHECKS значение 0

mysql> FOREIGN_KEY_CHECKS = 0;

Источник