Просмотр сообщений
В этом разделе можно просмотреть все сообщения, сделанные этим пользователем.
Речь всё же, полагаю о том, что один класс Товар не справится с тем, чтобы описывать и элементы каталога, и сведения о товарах в заказе.
Но похоже только чувство голода заставляет присматриваться к предметной области настоящих програмистов Менее активные раздражители не способны заставить их поступиться уже написанным кодом:)
У вас по сути Товар - это экземпляр товар. Конкретная продаваемая единица. Это нормально работает со штучным товаром, хотя из каталога Вы выбираете не конкретный товар - а обобщенное описание этого товара.
Если их не использовать, то тот же BPMN превратится в блок-схему. В том числе по унылости. То ли дело пляшущие человечки, утыкающиеся в сервера.
В долговременном? Они ж одноразовые по сути, в силу своего назначения. Отпрезентовались - и в помойку. В смысле, в архив.
В том то и смысл - передать идею в ситуации, когда "приемник" не располагает специальными знаниями. Любая, абсолютно любая серьезная нотация требует для понимания изложенного в ней определенной подготовки. Смысл может быть "уловлен" и без знания нюансов, однако применение последних либо останется незамеченным, либо будет непонятым, а в самом худшем случае - будет понято не так. И зачем это надо?
Медом не корми - дай испортить идеальную модель своими грубыми лапами.
Любой генерал знает, чем отличается закрашенный конвертик в кружочке от незакрашенного.
И еще пара слов про различие.
Логические модели (или концептуальные, или какие угодно "бумажные") отражают информационные сущности (объекты) и связи между ними, которыми оперирует информационная система.
Физическая модель - это то, как информационные сущности были интерпретированы и реализованы в конкретной БД.
Разница может быть очень существенной.
Получается, что достаточно трех сущностей, которые я уже пробовал использовать.Возьмите исходную постановку и все ваши другие диаграммы и проверьте , достаточно или нет. И разберитесь с хранением количества и цены в заказе
Т.к. остальные таблицы в БД это лишь справочники.
Спасибо за ссылку, уже начал читать статью.
Я просто уже запутался в этих моделях, мне нужно сделать и концептуальную модель и физическую модель и логическую.
Во всех примерах, что у меня есть от других студентов эти модели крайне похожи, ровно те же таблицы, те же атрибуты, те же связи.
Единственное различие - в концептуальной атрибуты написаны русским текстом, а в физической английским.
Еще один вопрос: должны ли в концептуальной модели быть все таблицы как в БД? Или все же я в чем то прав и в ней используются основные сущности?
Т.е. в ней не надо указывать, например, сущность "производитель товара".
IDEF1X это не физическая модель БД ?
В последней моей модели ведь есть и сущности и связи и идентификаторы сущностей, атрибуты, операции.
Единственное не уверен в связи "зависимость" между сущностями Товар и Заказ.
Да, ER точно не получится.
.....
6. Концептуальная модель предметной области (диаграмма классов уровня анализа UML).
Это был сарказм ? ))
СУБД MySQL. Поле Products в БД определено как тип "text".
Я прошу прощения, ввел в заблуждение вас. В массиве у меня заказанные продукты хранятся в процессе заказа, в переменной, при сохранении заказа массив преобразуется в строку с помощью функции "json_encode"
Так выглядит строка в таблице {"47":1,"48":1,"49":1,"51":1}, где 47 это id товара, а 1 - количество товаров.
Я бы с радостью смотрел на сайте uml-diagrams, но к сожалению я не знаю английский.
