Читать книгу SQL с нуля и быстро - Елена Литвак - Страница 12

Заполним базу данных в соответствии с рис. 1.31.

Рис.1.31 – Заполненные таблицы

Говоря простым языком, целостность данных, это, когда проекту с определенным кодом в таблице «job» находится соответствие в таблице «projects», а сотруднику в таблице «job» находится соответствие в таблице «employees».

Если бы в таблице «job» значился сотрудник с кодом 5, которого нет в таблице «employees», то это было бы нарушением целостности данных.

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

При попытке вставить в поле projectID таблицы «job» несуществующий код проекта, СУБД покажет диагностическое сообщение об ошибке (рис.1.32).

Рис.1.32 – Диагностическое сообщение о нарушении целостности данных

Вообще все диагностические сообщения обязательно нужно читать, переводить и понимать, а не закрывать и пытаться угадать, в чем проблема. Данное сообщение говорит нам, что «запись невозможно добавить или отредактировать, так как нарушается ограничение внешнего ключа». Конечно, именно такую ошибку мы тут допустили умышленно: попытались вставить проект с кодом 2022, хотя существуют только проекты с кодами 1, 2, 3, 4.

Также возможна обратная ситуация. Сотрудника с кодом 1 (Иванова Ивана) решили по каким-то причинам удалить из системы. Но сотрудник уже записан как участник проекта с кодом 1. Как поступить с записью в таблице «job», которая связана с этим сотрудником? Для ответа на этот вопрос есть свойство «ПриDELETE» в настройке внешнего ключа (рис.1.33).

Рис.1.33 – Ограничения при удалении записи

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

RESTRICT – ОГРАНИЧИТЬ. В этом случае при попытке удаления сотрудника из таблицы employees появится вот такое диагностическое сообщение:

Рис.1.34 – Ограничение RESTRICT

Сообщение говорит нам, что «невозможно удалить или изменить родительскую запись, так как нарушаются ограничения внешнего ключа». Запись с кодом 1 из таблицы «employees» является родительской по отношению к записи в таблице «job». Данное сообщение просто предупреждает нас о том, что удаление выполнить невозможно. Мы можем принять одно из двух решений:

– Сначала удалить связанную дочернюю запись в таблице «job», а уже потом выполнить удаление в таблице «employee». Тогда удаление выполнится.

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

CASCADE – Каскадное удаление. В этом случае при удалении сотрудника с кодом 1 удалятся автоматически все связанные записи из таблицы «job». В некоторых случаях это удобно. Но метод довольно опасный, так как данные «посыплются», как тетрис, и вернуть их вряд ли удастся, если окажется, что удаление было ошибочным.

SET NULL Установить значение NULL. NULL – это «пустое множество», отсутствие какого-либо значения. В этом случае при удалении сотрудника из таблицы «employee», запись в таблице «job» примет следующий вид (рис.1.35):

Рис.1.35 – Настройка SET NULL

NO ACTION – Никаких действий. В это случае после удаления записи из таблицы «employees», в таблице «job» ничего не произойдет. Поле employeeID так и будет содержать код 1, который уже не существует в родительской таблице.

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

Такие же настройки могут быть применены при попытке изменить значение первичного ключа родительской записи. Если мы в таблице «employees» захотим изменить значение кода для сотрудника Иванова с 1 на 5, то точно также для связанных записей есть четыре варианта: можно защитить их ограничением RESTRICT, каскадно изменить, установить NULL или ничего не изменять (рис.1.36).

Рис.1.36 – Ограничения целостности данных по внешнему ключу при изменении