Преобразование реляционной БД в сущности и связи
На основе разработанной модели 3НФ создайте ER-диаграмму с первичными и внешними ключами и кардинальностями.
Один проект — три этапа
Все практические выполняются последовательно в одном файле diagrams.net. На каждой практической добавляются новые страницы, а прежние остаются для проверки хода проектирования. Все задания выполняются на схеме; отдельные текстовые ответы и автоматическое тестирование здесь не нужны.
Две части занятия: сначала изучите объяснения и примеры, затем перейдите к самостоятельным заданиям по магазину «ТехноКорзина».
От реляционных таблиц к ER-диаграмме
ER-диаграмма (Entity–Relationship Diagram) — схема сущностей, их атрибутов и связей. Она помогает увидеть, какие данные есть в системе и как записи одной таблицы соотносятся с записями другой. Для этой работы используем логическую ER-диаграмму: прямоугольник сущности с полями, PK/FK и связями между таблицами.
Предмет, событие или понятие, о котором система хранит сведения: автор, книга, заказ.
Свойство сущности: имя, дата, цена, код. В логической ER-модели соответствует полю таблицы.
Правило, показывающее, как одни записи относятся к другим: отдел содержит сотрудников.
Сколько экземпляров одной сущности может быть связано с одним экземпляром другой.
PK, FK и ссылочная целостность
PK однозначно определяет строку самой таблицы. FK содержит значение, которое должно ссылаться на существующую запись другой таблицы (или той же таблицы). Например, одна книга хранит автор_id, чтобы указать автора, не копируя все его данные в каждую книгу.
Если удалить автора, на которого ссылаются книги, база должна выполнить определённое правило: запретить удаление, удалить зависимые записи или изменить ссылки. Конкретное действие определяется требованием системы и ограничениями СУБД. На учебной схеме можно подписать желаемое правило.
На диаграмме ключи обычно показывают прямо в списке полей: PK у первичного, FK у внешнего. Одно поле может быть одновременно PK и FK — это типично для промежуточных таблиц.
Типы связей и «воронья лапка»
Один к одному (1:1) — одному объекту соответствует не более одного другого. Один ко многим (1:N) — одна запись может иметь несколько связанных записей. Многие ко многим (M:N) — у каждой стороны может быть много связей с другой.
В нотации Crow's Foot («воронья лапка») вертикальная черта означает «один», кружок — «ноль», развилка — «много». Комбинация возле каждого конца линии задаёт допустимое количество записей на этом конце.
| Тип | Пример | Как читать |
|---|---|---|
| 1:1 | Пользователь — настройка профиля | Каждому пользователю соответствует не более одной настройки |
| 1:N | Автор — книги (упрощённая модель) | У автора может быть много книг; у книги один автор |
| M:N | Студенты — учебные курсы | Каждый студент может посещать много курсов, каждый курс — иметь много студентов |
Как изображать многие ко многим
В реляционной модели связь M:N обычно реализуют через отдельную ассоциативную таблицу (таблицу-связку). Представим систему записи на курсы: студент посещает несколько курсов, а каждый курс посещают несколько студентов.
В промежуточной таблице обычно находятся FK на обе стороны и факты самого взаимодействия — например, дата записи или итоговая оценка. Если по условию одна и та же пара не должна повторяться, два FK могут образовывать составной PK.
Практические приёмы в diagrams.net
В библиотеке Entity Relation есть табличные фигуры и соединители с разными обозначениями кардинальности. Включите её через More Shapes → Software → Entity Relation → Apply. Поля можно добавлять как строки таблицы, а окончания линий выбирать в настройках стиля соединителя.
- Сначала расставьте сущности с полями и ключами, чтобы подписи не перекрывались.
- Проводите соединители между конкретными таблицами; не заменяйте связь неформальной стрелкой без кардинальности.
- Подпишите бизнес-правила там, где краткая нотация недостаточна (например, должна ли у заказа быть хотя бы одна позиция).
- Избегайте пересекающихся линий, используйте изгибы под прямым углом и выравнивание.
- Проверьте, что все указанные FK действительно ведут к ключам соответствующих таблиц.
Практические задания: ER-модель «ТехноКорзины»
Работайте в том же файле, где есть страницы 01 · Черновик, 02 · 1НФ, 03 · 2НФ и 04 · 3НФ. Применяйте информацию о 4 заказах, 3 клиентах, 4 товарах и 2 категориях из предыдущих работ.
Задание 1. Постройте страницу «05 · ER-диаграмма»
- Создайте новую вкладку
05 · ER-диаграмма. - Перенесите из 3НФ на этот лист все логические таблицы как ER-сущности. Не удаляйте прежние версии схемы.
- В каждой сущности отобразите название, поля, первичный ключ и внешние ключи.
- Если поле входит в составной PK и одновременно является FK, обозначьте обе роли.
- Добавьте легенду обозначений PK, FK и используемой нотации.
Задание 2. Свяжите сущности
- Определите и отобразите связи между покупателями и заказами, заказами и позициями, товарами и позициями, категориями и товарами.
- Поставьте кардинальность возле обоих концов каждой связи.
- Проверьте, каким образом связь «один заказ содержит несколько товаров» реализуется через позиции заказа, а не непосредственным FK от заказа к единственному товару.
- Отметьте обязательность: можно ли хранить клиента без заказов; должна ли позиция иметь существующий заказ и товар; может ли категория временно не содержать товаров.
Задание 3. Проверьте схему на исходных данных
- Оформите на полях листа блок «Контрольные сценарии».
- Разберите заказ
201: укажите, какие сущности и записи понадобятся, чтобы найти покупателя и две товарные позиции. - Разберите клиента
К01: на каких связях основан поиск всех его заказов? - Разберите товар
Т02: как получить заказы, в которые он входил? - Объясните на схеме, что произойдёт при попытке создать позицию с кодом несуществующего товара.
Задание 4. Финальная проверка качества
- Сведите пересечения линий к минимуму, выровняйте сущности и выдержите единый визуальный стиль.
- Добавьте заголовок и небольшое описание проекта с указанием автора и группы.
- Проверьте полную согласованность: поля FK присутствуют в нужных таблицах, связи не противоречат бизнес-правилам.
- Убедитесь, что в исходном проекте пять страниц, включая все предыдущие этапы.
- Сохраните рабочий файл
.drawioи экспортируйте все страницы в итоговый XML.
Дополнительное задание повышенной сложности (необязательное)
В реальном магазине текущая цена в каталоге может измениться после оформления заказа. Продумайте, где нужно хранить цену на момент покупки, чтобы старые чеки не пересчитывались при изменении цены товара. Объясните решение на схеме отдельной выноской. Не изменяйте демонстрационные значения и не удаляйте текущую цену каталога.
📤 Сохранение и сдача
Ответом является один редактируемый XML-файл из diagrams.net. Скриншоты, PNG, PDF, Word и ссылки не заменяют XML. Страница материала не загружает работу автоматически — отправить файл нужно самостоятельно через сервис.
- Сохраните рабочий проект через File → Save или File → Save As в формате
.drawio. Этот файл оставьте себе для продолжения. - Выберите File → Export as → XML. Включите All Pages, чтобы в файл вошли все страницы проекта. Не включайте Selection Only. Параметр Compressed можно отключить для удобства проверки XML.
- Скачайте XML и назовите файл
tehnokorzina_Фамилия_ПР03.xml(вместо слова «Фамилия» укажите свою фамилию латиницей или кириллицей). - Для проверки откройте экспортированный XML через File → Open From → Device в diagrams.net и убедитесь, что он редактируется и содержит нужные страницы.
- Перейдите на homework.probochka-corp.ru, откройте соответствующую практическую работу №3, прикрепите полученный
.xmlи завершите отправку в интерфейсе сервиса.
Этот XML содержит историю всех этапов проектирования — от первого черновика до итоговой ER-диаграммы.