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

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

У меня нет универсального справочника типа поставщиков...для поставщика, а точнее производителя у меня отдельный справочник brand, в котором есть только поля id и name.
Проблема у меня с полем products в таблице заказов, в нем сразу id товара и количество. Да, сейчас я понимаю, что это криво и возможно следовало бы сделать отдельную таблицу заказанных товаров, в которой указать товар, количество и стоимость.
Однако делал интернет-магазин по видео-урокам, и там был именно такой способ. Времени изменять что-либо к сожалению не осталось.
К слову я немного изменил концептуальную модель, правда думаю что все равно не верно...
Я разделил сущность пользователь, на две сущности: клиент и администратор.

Я разделил сущность пользователь, на две сущности: клиент и администратор.

Типичная ошибка студентов.
Вы строите концептуальную модель. КМ - это понятия предметной области и отношения  между ними. Отношения - это ограничения, зависимости, связанности одного понятия к другому.

Есть понятие - Клиент. Он делает Заказы Товаров. Заказ обрабатывается определенным Администратором, хотя странное понятие для такой предметной области, скорее уже Оператор заказа, Менеджер заказа, Исполнитель заказа.

Заказ сам по себе себя не определяет, он определяется через свою связь с Клиентом. Именно Клиент идентифицирует (определяет) Заказ.

Товар - тут посложнее. Товар - это абстрактное понятие. У вас по сути Товар - это экземпляр товар. Конкретная продаваемая единица. Это нормально работает со штучным товаром, хотя из каталога Вы выбираете не конкретный товар - а обобщенное описание этого товара.

При это Вы не первый, кто моделирует подобные предметные области, и даже не второй, ну может быть какой-нибудь 10миллионный.

http://www.databaseanswers.org/data_models/

У вас по сути Товар - это экземпляр товар. Конкретная продаваемая единица. Это нормально работает со штучным товаром, хотя из каталога Вы выбираете не конкретный товар - а обобщенное описание этого товара.

Не совсем точно по отношению к предметной области. Штучный товар в торговле - это тот , который продается штуками. В отличии от весового, который продается на вес, обьемного и т.д.

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

IMHO серийный учет при торговле постельным бельем вряд ли используется.

Типичная ошибка студентов.
Вы строите концептуальную модель. КМ - это понятия предметной области и отношения  между ними. Отношения - это ограничения, зависимости, связанности одного понятия к другому.

Есть понятие - Клиент. Он делает Заказы Товаров. Заказ обрабатывается определенным Администратором, хотя странное понятие для такой предметной области, скорее уже Оператор заказа, Менеджер заказа, Исполнитель заказа.

Заказ сам по себе себя не определяет, он определяется через свою связь с Клиентом. Именно Клиент идентифицирует (определяет) Заказ.

Товар - тут посложнее. Товар - это абстрактное понятие. У вас по сути Товар - это экземпляр товар. Конкретная продаваемая единица. Это нормально работает со штучным товаром, хотя из каталога Вы выбираете не конкретный товар - а обобщенное описание этого товара.

При это Вы не первый, кто моделирует подобные предметные области, и даже не второй, ну может быть какой-нибудь 10миллионный.

http://www.databaseanswers.org/data_models/

У меня же есть связь клиента с заказом. Один ко многим.
По поводу того что у меня Администратор обрабатывает заказ это да, необычно, и естественно в реальном интернет магазине такого не будет. Но в моем случае пуст будет один администратор он же менджер, который и товары добавляет и за заказами следит.

IMHO серийный учет при торговле постельным бельем вряд ли используется.

Речь всё же, полагаю о том, что один класс Товар не справится с тем, чтобы описывать и элементы каталога, и сведения о товарах в заказе.

Речь всё же, полагаю о том, что один класс Товар не справится с тем, чтобы описывать и элементы каталога, и сведения о товарах в заказе.

Я топикстартера уже четвертую страницу к этому подталкиваю Но похоже только чувство голода заставляет присматриваться к предметной области настоящих програмистов Менее активные раздражители не способны заставить их поступиться уже написанным кодом:)

Я топикстартера уже четвертую страницу к этому подталкиваю Но похоже только чувство голода заставляет присматриваться к предметной области настоящих програмистов Менее активные раздражители не способны заставить их поступиться уже написанным кодом:)

Да, при построении моделей я исхожу из уже существующей БД и кода.
Ели я в концептуальной модели выделю отдельный класс, мне же придется и дальше менять саму бд правильно ведь?

Да, при построении моделей я исхожу из уже существующей БД и кода.
Ели я в концептуальной модели выделю отдельный класс, мне же придется и дальше менять саму бд правильно ведь?

Именно так.

Но можно и оставить все как есть. Это же очень правильно для покупателя - заказать товар по одной цене, получить по другой. Это безусловно укрепит позиции заказчика на рынке и будет способствовать лояльности покупателей. Очень удобно считать выручку прошлых периодов - цены ведь будут пересчитываться даже в доставленных заказах. С большой вероятностью учет выручки при таком подходе надо будет вести в Excel паралельно - надо только предусмотреть в него выгрузку.

А уж как удобно вскрывать json строки из текста, чтобы посчитать суммарное количество проданного товара в разрезе артикулов!

Нет, надо оставить как есть

Не совсем точно по отношению к предметной области. Штучный товар в торговле - это тот , который продается штуками. В отличии от весового, который продается на вес, обьемного и т.д.

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

IMHO серийный учет при торговле постельным бельем вряд ли используется.

Ну, правильно. Спасибо за дополнение:)

Речь всё же, полагаю о том, что один класс Товар не справится с тем, чтобы описывать и элементы каталога, и сведения о товарах в заказе.

И Вы правы, уважаемый инопланетянин

Нет, надо оставить как есть

Humbert, пощадите пианиста, он играет как умеет:)

Humbert, пощадите пианиста, он играет как умеет:)

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

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

Причем пропуск разработки КМ это скорее норма, чем исключение.

Причем пропуск разработки КМ это скорее норма, чем исключение.

Но никак не могу понять, почему концептуальная модель появилась на финальной стадии ?

Успел.

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

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

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

Причем пропуск разработки КМ это скорее норма, чем исключение.

Почему пианист ? ) И с кем проводить интервью?

Объясняю почему сначала сайт, а потом диаграммы.
Потому что за время моего обучения в институте, мы раза 2 делали эти диаграммы, и оба раза нам толком не объясняли и на зачет или экзамен принимали кривые диаграммы (непонятно что).
Ни кто толком не объяснил зачем, для чего и почему сначала диаграмму, а потом проект. Что так логичней, что так проще потом будет сам проект делать.
В итоге у меня и всех моих одногруппников сложилось мнение, что главное сделать программу (или сайт), а уж диаграммы то нарисуем как-нибудь.
Но тут выпускная квалификационная работа. Как обычно делаю сначала сайт, а потом остальное. И тут на тебе, оказывается, что на защите мой сайт даже смотреть ни кто не будет, даже не проверит работает ли он. Главное это презентация, в которой будут диаграммы и пара скринов с сайта.
А в пояснительной записке главное не содержание (за исключением диаграмм конечно), главное чтобы по ГОСТу все было, чтобы таблицы правильно названы были, чтобы интервал полуторный и т.д. и т.п.
Вот так у нас выпускают программистов с высшим образованием.