Разделите участника, предмет и событие
Читатель существует независимо от конкретной выдачи. Экземпляр книги может многократно переходить от одного читателя к другому. Выдача связывает их в определённое время. Поэтому для учебной задачи удобно отдельно представить читателей, экземпляры и события выдачи. Важно различать название книги и физический экземпляр. Два одинаковых издания могут одновременно находиться у разных людей. Если идентифицировать их только названием, история станет неоднозначной. Отдельная запись выдачи содержит ссылки на читателя и экземпляр, дату начала и сведения о возврате. Когда книгу берут снова, появляется новое событие. Перезаписывать предыдущего читателя в карточке экземпляра недостаточно, если система должна сохранять историю.
Идентификатор помогает связать записи без повторения всего описания
У каждой сущности нужен способ однозначно различать записи. Имя человека для этого обычно неудобно: имена могут совпадать и меняться. В учебной модели можно использовать условный постоянный номер читателя и отдельный номер экземпляра. Событие выдачи хранит эти номера, а не полную копию сведений о человеке в каждой строке. Это уменьшает риск противоречий при обновлении данных. Если телефон изменился, не требуется искать множество независимых копий, которые должны обозначать один текущий контакт. При этом исторические сведения рассматривают осознанно. Если задаче действительно нужно сохранить значение на момент события, это отдельное требование. Нельзя удалять полезную историю только ради механического правила никогда ничего не повторять.
Связи и правила проверяют на неудобных случаях
Первичный ключ позволяет однозначно определить запись. Внешний ключ помогает обеспечить, чтобы ссылка указывала на существующую связанную запись. Но наличие внешних ключей не описывает все правила предметной области. Например, запрет двух одновременных незавершённых выдач одного экземпляра требует отдельного решения. Ссылки на существующих читателей сами по себе не исключают такого конфликта. Аналогично, нужно определить, что происходит при попытке удалить читателя, у которого сохранились связанные события. Перед реализацией полезно проверить модель на повторной выдаче, совпадающих именах, отсутствующем экземпляре и возврате. Сначала формулируют желаемое поведение, затем выбирают ограничения и обработку в приложении. Хорошая структура помогает сохранять смысл данных, а не просто помещать их в таблицы.
Попробуйте на практике
Смоделируйте выдачи двух экземпляров книги двум вымышленным читателям на бумаге.
- Создайте отдельные списки читателей и экземпляров с условными идентификаторами. Дайте читателям одинаковое имя, чтобы проверить, различаются ли они без него.
- Запишите две выдачи разных экземпляров. Для каждой укажите идентификаторы участников и предмета, а также условную дату.
- Отметьте возврат одного экземпляра и новую выдачу другому читателю. Сохраните оба события вместо перезаписи истории.
- Добавьте ошибочную попытку сослаться на несуществующий экземпляр и конфликт двух активных выдач одного экземпляра. Объясните, почему это разные проверки.
Как проверить результат. Совпадение имён не создаёт неоднозначности, повторная выдача сохраняет историю. Несуществующая ссылка и конфликт активных событий различены. Для каждого правила понятно, какое нарушение оно должно предотвращать.
Частые вопросы
Внешний ключ автоматически проверяет все бизнес-правила?
Нет. Он решает задачу ссылочной целостности. Ограничения времени, состояния и допустимых сочетаний событий могут требовать дополнительных механизмов.
Чем больше таблиц, тем лучше спроектирована база?
Количество само по себе не является критерием. Важно, чтобы сущности, связи и зависимости соответствовали задаче, а необходимые запросы и изменения выполнялись без потери смысла.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.