Интернет-магазин по продаже электронных книг

1.

Кафедра ЦТ
Институт информационных технологий
РТУ МИРЭА
Дисциплина
«Проектирование баз данных»
Интернет-магазин по продаже электронных книг
Кандидат технических наук,
доцент кафедры
цифровой трансформации
Дзгоев Алан Эдуардович

2.

Цель:
спроектировать и разработать базу данных;
научиться выводить её содержимое на экран.
.

3.

1. Описание предметной области
Магазин продает электронные книги (e-books). У каждой книги есть автор, название, жанр и цена.
Покупатели регистрируются в магазине, указывая имя и e-mail.
Покупатели формируют заказы, в которые могут входить несколько книг. У заказа есть статус
(например, 'обработан', 'доставлен') и дата создания.
У одного автора может быть несколько книг. Книга может иметь только одного автора (для
упрощения).
Книга может принадлежать к нескольким жанрам, и в одном жанре может быть множество
книг (связь многие-ко-многим).
Цель — найти ключевые сущности.
Сущность — это объект или явление из реального мира, информацию о котором мы хотим хранить в базе
данных. У каждой сущности есть собственный идентификатор и набор характеристик

4.

1. Описание предметной области
Шаг 1: Выделяем «Главных действующих лиц» (Явные объекты)
Давайте зададим себе первый вопрос: С кем или с чем система имеет дело напрямую? Прочитаем
описание еще раз.
•«Покупатели регистрируются в магазине...» → Сразу очевидный кандидат: Покупатель. Это «главное
действующее лицо».
•«Магазин продает электронные книги (e-books).» → Второй очевидный кандидат: Книга. Это наш товар.
Товар находится в Магазине - это тоже сущность (для упрощения модели не будет учтена).
•«У каждой книги есть автор...» → Автор — это отдельная характеристика? Или отдельная сущность?
Смотрим дальше: "У одного автора может быть несколько книг". Если у одного автора много книг, то
данные об авторе (имя) будут повторяться для каждой книги. Это нарушает нормализацию. Значит, автор —
это не просто атрибут, а самостоятельная сущность Автор.
Промежуточный итог: У нас уже есть три сущности: Покупатель, Книга, Автор.

5.

1. Описание предметной области
Шаг 2: Ищем «События» и «Документы»
«Теперь спросим: Какие ключевые события или процессы происходят в системе? Часто они
превращаются в отдельные сущности.»
•«Покупатели формируют заказы...» → Заказ — это не просто свойство покупателя, это центральное
событие в магазине. У заказа есть свой статус, своя дата, свой состав. Это 100% сущность: Заказ.
Промежуточный итог: Добавляем Заказ. Теперь у нас четыре сущности.
Сущности: Покупатель, Книга, Автор,
Заказ

6.

1. Описание предметной области
Шаг 3: Ищем «Справочники» и «Классификаторы»
«Следующий вопрос: Есть ли в системе объекты, которые служат для категоризации или описания
других объектов? Часто это статические списки.»
•"У каждой книги есть... жанр" → Сначала кажется, что жанр — это просто атрибут книги, как название. Но
читаем дальше: "Книга может принадлежать к нескольким жанрам, и в одном жанре может быть
множество книг". Это связь "многие-ко-многим"! Если бы жанр был просто текстовым полем в
таблице Книга, то для книги в трех жанрах нам пришлось бы либо создать три отдельные записи (это плохо!),
либо хранить список через запятую в одной ячейке (очень плохо, нарушение атомарности). Правильное
решение — вынести жанры в отдельную сущность-справочник: Жанр.
Промежуточный итог: Добавляем Жанр. Пять основных сущностей найдены.
Сущности: Покупатель, Книга, Автор, Заказ,
Жанр.

7.

1. Описание предметной области
Давайте резюмируем, как мы
пришли к нашим сущностям:
1. Покупатель, Книга — основные
объекты системы.
2. Автор — вынесен из Книги из-за
связи "один-ко-многим"
(повторяющиеся данные).
3. Заказ — ключевое
событие/документ.
4. Жанр — вынесен из Книги из-за
связи "многие-ко-многим"
(неатомарные данные).
Сущности: Покупатель, Книга, Автор, Заказ,
Жанр.

8.

1. Описание предметной области
Давайте резюмируем, как мы
пришли к нашим сущностям:
1. Покупатель, Книга —
основные объекты системы.
2. Автор — вынесен из Книги изза связи "один-ко-многим"
(повторяющиеся данные).
3. Заказ — ключевое
событие/документ.
4. Жанр — вынесен из Книги изза связи "многие-ко-многим"
(неатомарные данные).
Сущности: Покупатель, Книга, Автор, Заказ,
Жанр.
Простой чек-лист для проверки:
•У каждой сущности есть что хранить? (атрибуты:
имя, email, название, цена и т.д.)
•Можно ли однозначно идентифицировать каждый
экземпляр сущности? (например, у заказа есть
уникальный номер, у книги —ISBN, для упрощения
book_id).
•Сущность не является просто свойством другой
сущности? (Автор — не свойство книги, а
самостоятельная сущность, потому что у него много
книг).
Теперь, с четким пониманием почему мы выбрали

9.

2. Среда для создания моделей ChartDB
Сайт для выполнения практики - https://chartdb.mirea.dev/ (введите свой номер
студенческого билета, чтобы не потерять диаграмму