Дизайн базы данных на основе списка

Question

Может ли кто-нибудь помочь мне спроектировать базу данных / таблицу на основе следующих критериев?

Требуется веб-сайт электронной коммерции, который позволит посетителям просматривать, искать и покупать фильмы. Применяется следующая бизнес-логика:

1. Каждый фильм может быть доступен в формате DVD или Blu-ray с разными кодами акций и ценами. Дополнительные форматы могут быть добавлены в будущем администратором сайта.
2. Фильмы должны иметь название, описание, год выпуска и «звездный рейтинг» из десяти, сохраненных против них.
3. Фильмы связаны ни с одним или несколькими актерами, а актеры могут быть связаны с одним или несколькими фильмами, поскольку некоторые фильмы могут быть документальными (без актеров).
4. Фильмы могут быть связаны с одним или несколькими жанрами (например, экшн, приключения, фантастика и т. Д.).
5. Количество жанров и актеров может измениться, поэтому администратор сайта должен иметь возможность добавлять / редактировать столько жанров и актеров, сколько они захотят со временем.
6. Посетители сайта должны иметь возможность находить фильмы, просматривая их по актерам или жанрам. Когда они это сделают, они смогут увидеть список всех фильмов, которые связаны с выбранным актером / жанром.
7. Чтобы совершить покупку на сайте, посетители должны зарегистрировать свои данные, чтобы стать пользователем.
8. У пользователей будет один или несколько адресов, связанных с их учетной записью. Когда они войдут в систему в будущем, все их ранее введенные адреса должны быть доступны для их выбора для их последнего заказа. Они также должны иметь возможность добавить новый адрес в свою учетную запись в любое время.
9. При заказе пользователь выберет один или несколько предметов из доступных фильмов (в определенном формате). Им нужно будет выбрать платежный адрес и адрес доставки из тех, которые они ввели ранее, и оплатить заказ кредитной картой.
10. Поскольку цены на товары могут изменяться с течением времени, система должна записывать, какая цена каждого из товаров в их заказе была на момент их приобретения, а также общую стоимость всего заказа.
11. Отслеживание уровней запасов не требуется - можно предположить, что все товары постоянно есть в наличии.

Answer 1

Если это домашняя работа или проект класса, тогда вам действительно нужно начать изучать нормализацию.Взгляните на статью wikipedia или это введение на сайте MySQL

Если это профессиональный проект, то вам нужна профессиональная помощь для проектирования / разработки вашегосайт электронной коммерции.

Answer 2

Вот кое-что, что я мог бы придумать, надеюсь, оно должно соответствовать всем критериям, указанным в ваших требованиях. Я был спроектирован в SQL Server, поскольку у меня нет MySQL на этом компьютере.

Этапы проектирования базы данных (моделирование отношений сущностей)

1. Укажите сущности из требования. Объекты - это объекты, которые содержат информацию (обычно обозначают объекты реального мира, такие как человек, автомобиль, банк, сотрудник и т. Д.). В вашем случае идентифицируемыми объектами являются: Фильм, Актер, Пользователь, Заказ
2. Как только вы определили сущности в своих требованиях, перейдите к , определяющему атрибуты (или свойства) сущностей. Атрибуты - это то, с чем вы связываете сущность. Например, можно идентифицировать автомобиль по его производителю, модели, цвету, мощности двигателя и т. Д. В вашем случае атрибутами для объекта фильма будут Имя, Жанр, ActorInFilm (s), Формат (ы), Цена
3. Определите отношения между сущностями. В вашем случае фильм имеет отношения с актером. Отношения таковы: в одном фильме может быть ноль или более актеров. И один актер может сниматься в одном или нескольких фильмах. Таким образом, фильм и актер связаны между собой.
4. Определите количество связей . Количество элементов можно объяснить простыми словами: , сколько экземпляров сущности участвуют в отношениях. Например, работодатель может иметь 1 или более сотрудников. И работник может быть нанят только одним работодателем. В этом случае существует 2 объекта: Работодатель и Сотрудник. Они разделяют отношения , используют . По вашему требованию, Фильм и Актер - это лица, имеющие отношения Действует в (Актер (ы) Действует в Фильм). Таким образом, количество элементов в этом случае будет один ко многим (фильм для актеров) (один актер может действовать во многих фильмах) и ноль ко многим (актеры для фильмов).
5. Как только эта часть будет завершена, у вас будет нулевая диаграмма отношений нормальных сущностей. Затем наступает нормализация . Вы можете прочитать об этом в другом посте здесь .
6. После того, как вы нормализовали отношения сущностей (обычно достаточно до 3-й нормальной формы), вы можете реализовать проект базы данных в программном обеспечении проектирования SQL (MySQL и т. Д.)

Лучший способ выполнить описанные выше шаги - взять лист бумаги и написать сущности и атрибуты в табличном формате, а затем связать их с другими сущностями (для обозначения отношений).

Вы можете сослаться на любую хорошую книгу о понятиях базы данных (включая нормализацию) или просто искать в Google (ключевые слова: база данных , нормализация , база данных дизайн , моделирование отношений сущностей и т. д.). То, что я объяснил выше, очень краткое , вам нужно будет самостоятельно разобраться с остальными понятиями базы данных.

Диаграмма отношений сущностей часто сокращается как диаграмма ER.