скачать книгу бесплатно
Удалить выбранную строку можно кнопкой (рис.1.24).
Рис.1.24 – Удаление строки
Самостоятельная работа №1
– Создайте в базе данных project_manager таблицу employee (сотрудники) со следующими характеристиками (рис.1.25):
Рис.1.25 – Поля таблицы employees
– Заполните созданную таблицу данными (рис.1.26)
Рис.1.26 – Данные таблицы
Внешние ключи
Теперь у нас есть таблица «projects», которая содержит список проектов, и таблица «employees», которая содержит список сотрудников. Требуется распределить сотрудников по проектам с условием, что один сотрудник может работать в нескольких проектах.
Это означает, что между сущностями «проекты» и «сотрудники» имеется связь типа «много-ко-многим». (Если не очень понятно о чем идет речь, то более подробно об определении вида связи и о построении связей можно прочитать в книге «Как научиться проектировать базы данных и остаться в живых». )
В данном случае требуется создать ассоциирующую таблицу, которая будет содержать первичные ключи двух исходных таблиц в качестве внешних. Создадим таблицу «job» с первичным ключом jobID и полем employeeID (рис.1.27).
Рис.1.27 – Таблица job
Теперь сделаем из поля employeeID внешний ключ. Для этого перейдем на вкладку «Внешние ключи» и добавим новый внешний ключ (рис.1.28).
Рис.1.28 – Внешний ключ
Далее нужно показать на какую таблицу внешний ключ ссылается. Для этого нужно заполнить три свойства внешнего ключа (рис.1.29).
Рис.1.29 – Формирование внешнго ключа
Здесь мы указываем поле таблицы «job», которое будет внешним ключом (employeeID), потом указываем на какую таблицу оно ссылается («employees») и, наконец, на какое конкретно поле таблицы «employees» оно ссылается (employeeID). Внешний ключ сформирован.
Самостоятельная работа №2
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». Данное сообщение просто предупреждает нас о том, что удаление выполнить невозможно. Мы можем принять одно из двух решений:
– Сначала удалить связанную дочернюю запись в таблице «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 – Ограничения целостности данных по внешнему ключу при изменении
Создание резервной копии (дампа базы данных).
Резервная копия (дамп) базы данных создается для повышения надежности хранения данных, а также для переноса базы на другой сервер. Резервная копия представляет собой файл с расширением *.sql, который содержит код создания таблиц и код добавления данных в таблицы. Этот код можно выполнить на другом сервере, тогда по нему будет воссоздана база и данные в ней.
Для создания резервной копии нужно нажать кнопку «Дамп объектов базы данных в файл SQL» (рис.1.37).
Рис.1.37 – Создание резервной копии базы данных
В открывшемся окне указать нужную базу данных (рис.1.38).
Рис.1.38 – Выбор базы данных
Далее требуется настроить нужные опции. Чаще всего нужно сохранить в резервную копию код создания самой базы, код создания таблиц и код добавления данных. Для этого нужно проконтролировать чтобы были выбраны опции, которые отмечены на рис.1.39.
Рис.1.39 – Выбор опций
Бывают ситуации, когда нужна только структура базы с пустыми таблицами. В этом случае настройки будут такими, как на рис.1.40.
Рис.1.40 – Настройки для пустой структуры базы
Возможны и другие варианты, которые выбираются из выпадающего списка. Например, можно не выгружать инструкции создания базы и таблиц, но выгрузить инструкции удаления старых данных и добавления новых (рис.1.41).
Рис.1.41 – Удаление старых данных и добавление новых через резервную копию.
Мы сохраним вариант, который показан на рис.1.39, укажем имя файла и нажмем «Экспорт» (рис.1.42).
Рис.1.42 – Экспорт
В результате на диске сохранится файл project_management. sql, который можно просматривать в любом редакторе кода (рис.1.43).
