Я ближе к цели ? =)

Безусловно. Элементы заказа обычно называют  OrderLines или OrderDetails. Ну и производителя лучше выделить в отдельную сущность. И если предусмотрена возможность добавления новых видов упаковки, тоже в отдельную сущность.

И если захочется хранить историю цен (не только текущую цену, но и ту , которая была на товар 3,5 или 10 дней назад) то и ее тоже

Вот так у нас выпускают программистов с высшим образованием.

Уф. Хорошо , что не аналитиков с высшим образованием. Иначе бы это все грустно было бы. Для кодинга по спецификациям  эти все знания излишни:)

От многой мудрости много скорби, и умножающий знание умножает печаль. Копирайт Царь Соломон

Но как надоест кодить по спекам и захочется заняться проектированием, то лучше разобраться с реляционной алгеброй, нормальными формами, ER, а еще лучше с семантическими сетями и т.д.

Безусловно. Элементы заказа обычно называют  OrderLines или OrderDetails. Ну и производителя лучше выделить в отдельную сущность. И если предусмотрена возможность добавления новых видов упаковки, тоже в отдельную сущность.

И если захочется хранить историю цен (не только текущую цену, но и ту , которая была на товар 3,5 или 10 дней назад) то и ее тоже

Таблицы упаковка, производитель и размеры у меня в БД есть отдельно. Я думал в концептуальной модели они не важны.
Получается все таблицы надо сюда из БД.

Таблицы упаковка, производитель и размеры у меня в БД есть отдельно. Я думал в концептуальной модели они не важны.
Получается все таблицы надо сюда из БД.

Я никак не пойму критерия, по которым вы определяете что важно, а что нет.

Концептуальная модель должна обладать полнотой, то есть в ней должны найтись все бизнес-сущности и их атрибуты , которые у вас встречаются в проекте. Скажем если вы храните в БД настройки экранов, то это не бизнес-обьект и он в КМ не попадает.


У вас есть сомненья, что производитель - это бизнес-обьект?

Как-то так получается.
Я в модель еще сущность "категория" добавил, вот по нему у меня правда есть сомнения что это бизнес-объект.
Еще вопросы:
1) правильно ли я связи указываю? Потому что начитался про связи и уже запутался, каких только не бывает.
2) Для сущности Вид доставки, мне теперь как и с продуктом нужно добавить сущность ведь так? Иначе опять с ценой косяк будет.

Как-то так получается.
Я в модель еще сущность "категория" добавил, вот по нему у меня правда есть сомнения что это бизнес-объект.
Еще вопросы:
1) правильно ли я связи указываю? Потому что начитался про связи и уже запутался, каких только не бывает.
2) Для сущности Вид доставки, мне теперь как и с продуктом нужно добавить сущность ведь так? Иначе опять с ценой косяк будет.

Ну вот тут главное не переборщить

https://ru.wikipedia.org/wiki/%D0%91%D1%80%D0%B8%D1%82%D0%B2%D0%B0_%D0%9E%D0%BA%D0%BA%D0%B0%D0%BC%D0%B0

1. Если под категорией понимается товарная группа, то это безусловно бизнес-обьект
2. Экзотики у вас тут нет, все связи один ко многим. Надо проверить по каждой связи кого много, а кто один. И обязательность связи - скажем пользователь без заказа вполне может быть, а вот деталь заказа без ссылки на товар не может быт (из концептуальной модели это все поторм перейдет в constrain)
3. Стоимость доставки лучше копировать в заказ

Категорию оставляю, так как это одновременно ткань из которой делается товар.
Стоимость в заказ добавляю.

Ну, спустя страниц, думаю эту тему можно закрыть =))

Спасибо всем за помощь большое.

Как-то так получается.

У производителя есть код производителя, но у пользователя -- вместо кода пользователя код администратора. Плох тот пользователь, что не хочет быть администратором?
Заказ с видом доставки связывает помимо линии вид доставки. Что связывает элемент заказа с заказом помимо линии? А с товаром?
Во всех "прямоугольничках" есть что-то красненькое. Хотя, не во всех. В одном нет. Почему?
На примере от преподавателя нет "куриных лапок". А у Вас есть.  Примет ли преподаватель диаграмму с "лапками"?

1) Код пользователя изменил, спасибо за бдительность.
2) В физической модели будет указано как связана таблица Элемент заказа с товаром и заказом, это будет ключ, который и первичный и внешний. Я видимо не правильно решил, что в этой модели нет необходимости указывать вторичные ключи?
Иначе во всех таблицах нужно будет указать их.
3) Красненькое это первичный ключ я обозначил так (помимо PK) чтобы выделялся )) А в таблице Элемент заказа, уже выше написал что не указал, потому как он еще и вторичный.
4) А там где я делал эту модель, только куриные лапки, мне кажется главное чтобы я указал где какая связь, а уж как она будет нарисована нет разницы я думаю.

4) А там где я делал эту модель, только куриные лапки, мне кажется главное чтобы я указал где какая связь, а уж как она будет нарисована нет разницы я думаю.

Согласен. Можно приложить таблички типа этой

Диаграмма

А у меня связь один ко многим отличается, от того что у вас приведено в таблице.

И если захочется хранить историю цен (не только текущую цену, но и ту , которая была на товар 3,5 или 10 дней назад) то и ее тоже

В данной ситуации вполне достаточно иметь цену Элемента заказа. По дате заказа можно определить (и хранить) цену товара .
Сам товар хранит текущую цену. Как вариант.

В данной ситуации вполне достаточно иметь цену Элемента заказа. По дате заказа можно определить (и хранить) цену товара .
Сам товар хранит текущую цену. Как вариант.

Если нужна история цен как таковая, то вариант не годится. Цену могли задрать так , что продажи встали. Соответственно ни заказов, ни элементов на этот товар нет - статистику по цене не получим, менеджера-идиота не определим, будет просто малопонятная дыра в продажах

Диаграмма

А что это у вас за сущность Размер какая-то немного забавная?