Ограничение ссылочной целостности в дочерней таблице

Первым действием, которое может контролироваться операциями ссылочной целостности, является попытка добавления новой записи в дочерней таблице. Предположим, что имеются данные в таблицах, ассоциированных с сущностями "Заказы" и "Клиент" (рис. 5.46).

"Заказы" "Клиент"
ИДФ заказа	Номер заказа	ИДФ клиента ИДФ клиента ФИО клиента
1	3-1/2012	1 1 Иванов П. С.
2	3-2/2012	1 2 Кравец Р. С.
5	3-4/2013	2 3 Роднина А. К.

Рис. 5.46. Исходные сведения для проверки ограничений
ссылочной целостности

Будем считать, что дочерней таблицей, в связи с наличием связывающего в ней внешнего ключа, будет рассматриваться таблица, ассоциированная с сущностью "Заказы", а соответственно родительской таблицей — "Клиент". Рассматриваемое первое действие предполагает добавление новой записи в таблицу "Заказы" (рис. 5.47), где внешний ключ не имеет значения или имеет значение, которое не представлено среди значений первичного ключа таблицы клиентов.

"Заказы"				"Клиент"
ИДФ заказа	Номер заказа	ИДФ клиента		ИДФ клиента ФИО клиента
1	3-1/2012	1		1 Иванов 11. С.
2	3-2/2012	1		2 Кравец Р. С.
5	3-4/2013	2		3 Роднина А. К.
10	3-152/2014	❖

Рис. 5.47. Добавление нового заказа для неизвестного клиента

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

Когда пользователь базы данных будет пытаться добавить запись с новым заказом и закрепленным за определенным клиентом, но который не содержится в таблице клиентов, то здесь необходимо указание ограничения ссылочной целостности на действие по добавлению данных в дочернюю таблицу. Если СУБД предоставляет возможность определить правило ограничения ссылочной целостности, то для таких действий необходимо устанавливать операцию "Restrict", которая запретит добавлять записи с некорректными значениями первичного ключа. Если этого не сделать, то будет добавлена запись, которая нарушит целостность данных. Например, данное нарушение может привести к следующим проблемам:

— попытка получить список заказов с указанием, какой клиент сделал каждый заказ, может привести к невозможности выполнить эту операцию, поскольку для одной из записей заказа не будет существовать указанный клиент;

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

— выборка списка заказов, сделанных имеющимися в базе данных клиентами, приведет к тому, что добавленный заказ нс будет выбран и обработан;

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

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

Второе действие заключается в изменении значения внешнего ключа в дочерней таблице либо его очищении (рис. 5.48). Когда значение изменяется на такое, которое существует в первичном ключе родительской таблицы, то операция должна выполниться успешно, кроме отдельных случаев, которые регулируются отдельными триггерными операциями, определяемыми разработчиком базы данных на основании условий предметной области.

"Заказы"
ИДФ заказа	Номер заказа	ИДФ клиента
1	3-1/2012	1
2	3-2/2012	1
5	3-4/2013	4

Рис. 5.48. Изменение значения внешнего ключа

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

Когда же значение внешнего ключа изменяется на другое, но среди значений первичного ключа родительской таблицы его не существует, то здесь должно быть ограничение ссылочной целостности, которое, как правило, обеспечивается стандартными механизмами СУБД. Однако установка варианта действия "No action" или "None" может привести, особенно при использовании инструментального средства СЛ ERWin Data Modeler, формирующего триггерные действия самостоятельно, к отказу в контроле соответствия значений внешнего и первичного ключей. Такая ситуация требует контроля и установки варианта действия "Restrict", запрещающего изменение, если в родительской таблице не существует связываемая запись.

Если вернуться к таблице описания правил ссылочной целостности (см. табл. 5.4), предполагая, как это ранее отмечалось, что выбранной СУБД является IBM DB2, то знание особенностей работы этой СУБД и применение инструментального средства IBM InfoSphere Data Architect позволяет использовать действие "No action", понимая, что в СУБД имеется автоматическая операция, которую нельзя настроить указанием стандартизированного действия, а можно только заменить триггерным действием, которое должно быть определено разработчиком, что не предполагается делать по условиям предметной области.

Третьим действием является удаление записи из дочерней таблицы (рис. 5.49). Это действие никаким образом не влияет па родительскую

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

"Заказы"
ИДФ заказа	Номер заказа	ИДФ клиента
1	3-1/2012	1
2	3-2/2012	1
§	3 1/2013	%

Рис. 5.49. Удаление записи в дочерней таблице

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