Может ли отношение много к одному быть представлено в логической диаграмме ER?

Question

У меня есть конкретная проблема из моего задания, которая выглядит следующим образом:

"Каждый продукт, составляющий набор, поставляется одним поставщиком и получает уникальный идентификатор. Продукты всегда продаются как часть набор, а не сам по себе. "

Итак, на основании этого предполагается, что многие продукты создают один пакет (он же набор), но я не знаю, прав ли я, если да, то как я могу показать визуально Отношение «многие к одному» как диаграмма ER.

Я построил свою собственную Концептуальную и Логическую диаграмму ER, мне просто нужно знать, прав я или нет, чтобы я мог продолжить с остальными.

Answer 1

Вот разбивка задания и что я от него получаю:

Каждый продукт, составляющий набор, поставляется одним поставщиком и получает уникальный идентификатор, , Товары всегда продаются как часть набора, а не как таковые.

Из этого я получаю, что у нас есть следующие объекты:

1. Товар
2. Поставщик
3. Пакет (комплект)

Вы должны знать, что каждому субъекту необходим свой первичный ключ. Профессионалы либо назовут этот идентификатор, либо product_id. Есть ORM, которые, как правило, работают лучше всего из коробки, если вы называете pk для каждой таблицы 'id', особенно когда это простой порядковый номер.

Также лучше не делать то, что вы делаете с именами атрибутов. В sql люди придерживаются либо прописных, либо строчных имен, а не верблюжьих. Также я бы посоветовал не называть атрибут цены pPrice только потому, что он находится в таблице Package. Просто назовите его price, потому что он может называться Package.price, если вам нужно отличить его от другой таблицы, которая также содержит столбец цен.

Важно понимать, что отношения между Пакетом и Продуктом Многие ко многим

1. Один продукт может быть частью многих пакетов.
2. Один пакет может содержать много продуктов

Чтобы создать сущности для отношения «многие ко многим», вам нужна таблица, которая находится между двумя таблицами и будет содержать внешние ключи для обеих таблиц. , Обычно люди выбирают все, что они считают доминирующей стороной - я бы, вероятно, использовал Package и назвал таблицу «PackageProduct», чтобы подкрепить идею, что эта таблица позволяет мне собирать продукты вместе и продавать или распространять их.

PackageProduct
--------------
id (pk)
package_id (foreign key to Package table)
product_id (foreign key to Product table)

Вам также нужна таблица поставщиков, но вы были проинформированы о том, что отношения между Пакетом и поставщиком таковы, что у Пакета может быть один и только один Поставщик.

Это код для: создания отношения один ко многим между Поставщик и упаковка. При этом Package будет иметь внешний ключ, в котором хранится файл Supplier.id (или supplier_id)

. Итак, чтобы сделать вывод, у вас должны быть следующие сущности (таблицы):

1. Package
2. Продукт
3. Поставщик
4. PackageProduct

ERD

Вот ERD, отображаемый с помощью "Relational" "формат, который я нахожу немного более описательным, поскольку многие стороны соединений используют ворону, поэтому это очень очевидно.

Answer 2

Согласно вашему описанию ваша схема будет иметь отношение один ко многим, то есть ваш пакет включает в себя множество продуктов.

Вы также можете узнать свою диаграмму ERD