Добавил в таблицу "заказ" количество товаров. В БД у меня в этой таблице есть поле товары, в котором хранится массив с выбранными товарами (id товара и количество).

Если поле является массивом, элементы которого в свою очередь имеют поля, значит, его нужно моделировать по-другому. Посмотрите как это сделано на диаграмме с сайта uml-diagrams.

Цена товара может меняться в панели администратора. И странно, но при этом меняется цена в уже сформированных заказах...

Понятно, что моделируемый в рамках учебного примера интернет-магазин может отличаться от реального, но, наверное, не так сильно.

Чтобы выявить другие ошибки в своём решении, попробуйте для себя обосновать, чем Ваше решение лучше, а чем хуже решений из Сети. Например, в таком духе: В решении с сайта uml-diagrams больше классов и связей, поэтому оно хуже моего. Но эти дополнительные классы и связи позволяют то-то и то-то, чего не может моё решение.

Добавил в таблицу "заказ" количество товаров. В БД у меня в этой таблице есть поле товары, в котором хранится массив с выбранными товарами (id товара и количество).
Цена товара может меняться в панели администратора. И странно, но при этом меняется цена в уже сформированных заказах...

Ну вот на словах Вы вроде правильно сказали, но на диаграмме Количество товара в качестве массива я не увидел. Ну и с точки зрения физической структуры - какой БД вы пользуетесь? Поддерживает ли она массивы полей? Кстати, какую размерность этого массива Вы определили?

Если поле является массивом, элементы которого в свою очередь имеют поля, значит, его нужно моделировать по-другому. Посмотрите как это сделано на диаграмме с сайта uml-diagrams.
Понятно, что моделируемый в рамках учебного примера интернет-магазин может отличаться от реального, но, наверное, не так сильно.

Чтобы выявить другие ошибки в своём решении, попробуйте для себя обосновать, чем Ваше решение лучше, а чем хуже решений из Сети. Например, в таком духе: В решении с сайта uml-diagrams больше классов и связей, поэтому оно хуже моего. Но эти дополнительные классы и связи позволяют то-то и то-то, чего не может моё решение.

Я бы с радостью смотрел на сайте uml-diagrams, но к сожалению я не знаю английский.

Ну вот на словах Вы вроде правильно сказали, но на диаграмме Количество товара в качестве массива я не увидел. Ну и с точки зрения физической структуры - какой БД вы пользуетесь? Поддерживает ли она массивы полей? Кстати, какую размерность этого массива Вы определили?

СУБД MySQL. Поле Products в БД определено как тип "text".
Я прошу прощения, ввел в заблуждение вас. В массиве у меня заказанные продукты хранятся в процессе заказа, в переменной, при сохранении заказа массив преобразуется в строку с помощью функции "json_encode"
Так выглядит строка в таблице {"47":1,"48":1,"49":1,"51":1}, где 47 это id товара, а 1 - количество товаров.

Я бы с радостью смотрел на сайте uml-diagrams, но к сожалению я не знаю английский.

В translate.google.соm , translate.yandex.ru, translate.ru тоже забанили?

СУБД MySQL. Поле Products в БД определено как тип "text".
Я прошу прощения, ввел в заблуждение вас. В массиве у меня заказанные продукты хранятся в процессе заказа, в переменной, при сохранении заказа массив преобразуется в строку с помощью функции "json_encode"
Так выглядит строка в таблице {"47":1,"48":1,"49":1,"51":1}, где 47 это id товара, а 1 - количество товаров.

Отличное решение:) Главное концептуальное и хорошо отражающее структуру предметной области:)

Отличное решение:) Главное концептуальное и хорошо отражающее структуру предметной области:)

Это был сарказм ? ))

В translate.google.соm , translate.yandex.ru, translate.ru тоже забанили?

Боюсь таким методом я там надолго застряну...а сроки горят как обычно(
Поэтому обратился за помощью сюда на русскоязычный форум.

Это был сарказм ? ))

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

Кстати именно поэтому я считаю крайне вредным учить начинающих строить диаграмму классов - они так и норовят всю грязь  запихать в методы. Классическая ER на это не провоцирует.

В вашем случае я бы рекомендовал построить именно ER , получить из нее диаграмму классов можно формально

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

Кстати именно поэтому я считаю крайне вредным учить начинающих строить диаграмму классов - они так и норовят всю грязь  запихать в методы. Классическая ER на это не провоцирует.

В вашем случае я бы рекомендовал построить именно ER , получить из нее диаграмму классов можно формально

ER это пример которой я вначале темы кидал правильно? По мне она более адекватная и понятная, но я боюсь на дипломе забракуют.

Да, ER точно не получится.
Список диаграмм:
Раздел должен содержать описание проектных решений по следующим вопросам:
1.   Анализ проблемы, цель разработки.
2.   Основные бизнес-процессы (IDEF0) и бизнес-правила.
3.   Границы системы (DFD).
4.   Варианты использования системы (Use Case).
5.   Спецификация требований.
6.   Концептуальная модель предметной области (диаграмма классов уровня анализа UML).

Кстати именно поэтому я считаю крайне вредным учить начинающих строить диаграмму классов - они так и норовят всю грязь  запихать в методы. Классическая ER на это не провоцирует.

В вашем случае я бы рекомендовал построить именно ER , получить из нее диаграмму классов можно формально

Диаграмма предметной области, она же диаграмма бизнес-объектов, всегда строится без методов. Упор на понятия и отношения между понятиями.

Соглашусь, что лучше делать ER диаграмму, более того при построении инфологической модели (концептуальной) типично проходят три этапа:
1 построение модели сущность- связь - сосредотачиваемся на понятиях и связях между ними, чем строить не имеет значение.
2 построение модели, основанной на ключах - добавляем идентификаторы экземпляров сущностей, определяем независимые и идентификационно-зависимые
3 построение полно атрибутивной модели - добавляем неключевые атрибуты

http://dit.isuct.ru/ivt/books/CASE/case10/idef1x/index.htm

В последней моей модели ведь есть и сущности и связи и идентификаторы сущностей, атрибуты, операции.
Единственное не уверен в связи "зависимость" между сущностями Товар и Заказ.

Да, ER точно не получится.
.....
6.   Концептуальная модель предметной области (диаграмма классов уровня анализа UML).

Если диаграмма классов содержит только прикладные обьекты она практически совпадает с  ER. На вашей ER используется нотация Чена. На нотациях Чена и Мартина атрибуты выносятся в отдельные графические элементы (это бывает удобно, когда при проектировании велика вероятность выделения атрибута в отдельную сущность) . Нотации crow foot notation и IDEF1X позволяют описывать атрибуты внутри элементов сущностей.

Сделаете ER -без труда сможете преобразовать в диаграмму классов. По крайней мере мере это преобразование несопоставимо по своей трудоемкости с разработкой качественной ER

Единственное не уверен в связи "зависимость" между сущностями Товар и Заказ.

Совершенно верно не уверены, никаких зависимостей здесь не должно быть.