В данном случае требуется создать ассоциирующую таблицу, которая будет содержать первичные ключи двух исходных таблиц в качестве внешних. Создадим таблицу «job» с первичным ключом jobID и полем employeeID (рис.1.27).

Рис.1.27 – Таблица job

Теперь сделаем из поля employeeID внешний ключ. Для этого перейдем на вкладку «Внешние ключи» и добавим новый внешний ключ (рис.1.28).

Рис.1.28 – Внешний ключ

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

Рис.1.29 – Формирование внешнго ключа

Здесь мы указываем поле таблицы «job», которое будет внешним ключом (employeeID), потом указываем на какую таблицу оно ссылается («employees») и, наконец, на какое конкретно поле таблицы «employees» оно ссылается (employeeID). Внешний ключ сформирован.

1. Добавьте в таблицу «job» еще один внешний ключ – projectID, который ссылается на projectID в таблице «projects».

2. Добавьте еще два поля.

dateBegin – дата начала работы в проекте с типом DATE;

dateEnd – дата окончания работы в проекте с типом DATE.

Для обоих полей допускается значение NULL.

3. Добавьте поле payment – оплата за участие в проекте. Тип данных – MEDIUMINT, NULL не допускается, значение по умолчанию -0 (рис.1.30).

Рис.1.30 – Окончательная структура таблицы «job»

Заполним базу данных в соответствии с рис. 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». Данное сообщение просто предупреждает нас о том, что удаление выполнить невозможно. Мы можем принять одно из двух решений: