Форум Сообщества Аналитиков
Общий раздел => Для всех => Тема начата: Даниил от 18 Июня 2016, 08:17:18
-
Добрый день.
Прошу помочь сделать концептуальную модель предметной области или по-крайней мере объяснить как она делается.
Разобраться не могу толком так как у меня есть пример преподавателя и есть пример из интернета, и они скажем так отличаются очень. В итоге как правильно делать я так и не понял. А в Visio вообще не нашел шаблона концептуальной модели предметной области.
Делаю я интернет магазин по продаже постельного белья. Соответственно покупатель заходит ищет нужный товар, далее происходит оформление товара, а администратор магазина может просматривать заказы и проставлять статусы (новый заказ, в обработке и т.д.)
Ниже примеры от преподавателя и из интернета.
-
Концептуальная модель предметной области отражает структуру понятий данной предметной области.
Чаще всего для нее используют диаграммы сущность-связь в разных нотациях и диаграмма классов в UML (на примере предподавателя именно сущность связь)
Есть еще целое направление анализа - концептуальный анализ (Никаноров, Никитина, Кучкаров, Солнцев), в нем для модели используются специального вида графы, но как правило предметом рассмотрения концептуалтистов являются более обширные предметные области, и аппарат там хоть и очень выразительный, но требующий очень хорошей подготовки
Так же в ИИ под концептуальной моделью понимается онтология, описанная специальным языком
https://ru.wikipedia.org/wiki/%D0%9E%D0%BD%D1%82%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_(%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0) (https://ru.wikipedia.org/wiki/%D0%9E%D0%BD%D1%82%D0%BE%D0%BB%D0%BE%D0%B3%D0%B8%D1%8F_(%D0%B8%D0%BD%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%82%D0%B8%D0%BA%D0%B0))
В вашем случае скорее всего предподаватель хочет получить именно модель Сущность-Связь.
https://ru.wikipedia.org/wiki/ER-%D0%BC%D0%BE%D0%B4%D0%B5%D0%BB%D1%8C_%D0%B4%D0%B0%D0%BD%D0%BD%D1%8B%D1%85
-
Добрый день.
Прошу помочь сделать концептуальную модель предметной области или по-крайней мере объяснить как она делается.
Найденный Вами пример в интернете (UML-диаграмма) неудачен, т. к. относится к иной предметной области. Модель от преподавателя (ER-диаграмма) является хорошей заготовкой ответа (из которой, быть может, следует убрать лишнее, заменить "журнал(?) покупок" на "часть покупки", исправить мощности: покупка -1-включает-n- часть покупки, часть покупки -n-связана с-1- товар) Моделирование интернет-магазинов часто используемое учебное упражнение. Для него есть множество ответов с сети. Например, такая диаграмма классов: http://www.uml-diagrams.org/examples/class-example-online-shopping-domain.png (http://www.uml-diagrams.org/examples/class-example-online-shopping-domain.png) может быть найдена в гугль-картинках запросом вроде class diagram uml shop. Если исправить запрос на entity relationship diagram shop, также найдётся масса вариантов. Например, такой: http://creately.com/jupiter/diagram/image/gyhd76iq2 (http://creately.com/jupiter/diagram/image/gyhd76iq2)
Учебный пример с интернет-магазином подробно рассматривается в книгах по UML:
Мацяшек "Анализ и проектирование информационных систем с помощью UML 2.0"
Розенберг, Скотт "Применение объектного моделирования с использованием UML и анализ прецедентов на примере разработки книжного internet-магазина"
Коналлен "Разработка веб-приложений с использованием UML"
Магазины в книгах разные (книжные, видеокассетные, ...) но это не принципиально.
На этом форуме также есть несколько заходов на модели интернет-магазинов. [Воспользуйтесь поиском по форуму.]
Думаю, что и по ER-моделям можно найти книги.
[В сторону] Для студенческих задач на форуме есть свой раздел.
-
Спасибо за ответы и советы.
Однако если модель преподавателя более-менее верная, то чем она отличается в итоге от логической и физической модели БД. По сути только поля обозначены русским языком и все.
-
Правильно ли я понимаю, что в данной модели нет необходимости указывать какие-либо справочники? важны основные классы?
-
Еще подскажите пожалуйста на чем можно сделать данную диаграмму? На Visio не нашел ее, PowerDesigner у меня триал версия кончилась.
-
Найденный Вами пример в интернете (UML-диаграмма) неудачен, т. к. относится к иной предметной области. Модель от преподавателя (ER-диаграмма) является хорошей заготовкой ответа (из которой, быть может, следует убрать лишнее, заменить "журнал(?) покупок" на "часть покупки", исправить мощности: покупка -1-включает-n- часть покупки, часть покупки -n-связана с-1- товар)
Не совсем понял мысль. В модели преподавателя нет журнала покупок, он как раз в модели из интернета.
-
Не совсем понял мысль. В модели преподавателя нет журнала покупок, он как раз в модели из интернета.
Я не обратил внимания на названия изображений, приложенных к Вашему сообщению. Из-за чего ошибся, так как предположил, что ER-диаграмму Вам дал преподаватель в качестве примера, а в Сети Вы нашли диаграмму классов. Раз преподаватель Вам выдал диаграмму классов, то воспользуйтесь соответствующей ссылкой, примером запроса, библиографией. А про ER-диаграмму забудьте.
Дополнения для Visio, чтобы рисовать UML-диаграммы находятся тут: http://www.softwarestencils.com/uml/ (http://www.softwarestencils.com/uml/)
-
Сделал вот такую диаграмму.
В нее не включены такие таблицы-справочники как размер товара, вид доставки, производитель, категория, упаковка.
Сделал только 3 основных таблицы: пользователь, товар, и заказ.
Единственное, что у меня пользователь это и клиент и администратор магазина, только у администратора соответственно есть роль admin и соответствующие ему права.
Я не понимаю как подписывать связи, почитал нужно вроде глаголом, но что тут поставить я так и не понял.
И связь продукт и пользователь у меня получается многие ко многим. Не знаю верно ли так делать.
-
Сделал вот такую диаграмму.
Если Вы воспользуйтесь поиском по форуму, библиографией и т. д., то сможете обнаружить ошибки в своём решении.
-
Почитал, получилось как-то так.
-
Почитал, получилось как-то так.
Как в вашей модели вы отразите то, что товар может браться в количестве >1?
Может ли меняться цена товара? Меняется ли при этом цена в уже сформированных заказах?
-
Еще дополню:
Вы описываете предметную область интернет-магазина постельного белья. Не могу сказать, что я большой специалист в предметной области, но там присутствуют КОМПЛЕКТЫ постельного белья. То есть связанные между собой товары. Каким образом будет осуществляться их продажа?
-
Добавил в таблицу "заказ" количество товаров. В БД у меня в этой таблице есть поле товары, в котором хранится массив с выбранными товарами (id товара и количество).
Цена товара может меняться в панели администратора. И странно, но при этом меняется цена в уже сформированных заказах...
-
Еще дополню:
Вы описываете предметную область интернет-магазина постельного белья. Не могу сказать, что я большой специалист в предметной области, но там присутствуют КОМПЛЕКТЫ постельного белья. То есть связанные между собой товары. Каким образом будет осуществляться их продажа?
Комплект постельного белья это один товар, одна позиция. Комплект означает подушка, простыня, пододеяльник. Отдельно они не продаются.
-
Добавил в таблицу "заказ" количество товаров. В БД у меня в этой таблице есть поле товары, в котором хранится массив с выбранными товарами (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
-
Единственное не уверен в связи "зависимость" между сущностями Товар и Заказ.
Совершенно верно не уверены, никаких зависимостей здесь не должно быть.
-
Если диаграмма классов содержит только прикладные обьекты она практически совпадает с ER. На вашей ER используется нотация Чена. На нотациях Чена и Мартина атрибуты выносятся в отдельные графические элементы (это бывает удобно, когда при проектировании велика вероятность выделения атрибута в отдельную сущность) . Нотации crow foot notation и IDEF1X позволяют описывать атрибуты внутри элементов сущностей.
Сделаете ER -без труда сможете преобразовать в диаграмму классов. По крайней мере мере это преобразование несопоставимо по своей трудоемкости с разработкой качественной ER
IDEF1X это не физическая модель БД ?
-
В последней моей модели ведь есть и сущности и связи и идентификаторы сущностей, атрибуты, операции.
Единственное не уверен в связи "зависимость" между сущностями Товар и Заказ.
Учитывая Ваши ограничения по срокам могу дать наводку - поищите про реализацию связи многие ко многим в реляционных БД
-
Учитывая Ваши ограничения по срокам могу дать наводку - поищите про реализацию связи многие ко многим в реляционных БД
Примерно так:
Группа и Сотрудник - многие ко многим.
Тренинг и Сотрудник - многие ко многим
-
IDEF1X это не физическая модель БД ?
Нет. В любой нотации можно разрабатывать ER модель разного уровня абстракции
-
IDEF1X это не физическая модель БД ?
По ранее представленной ссылке Вы можете найти ответ. IDEF1X - этот система моделирования максимально адаптирована для создания реляционных моделей данных. Реляционная модель данных - это не физическая модель БД.
-
По ранее представленной ссылке Вы можете найти ответ. IDEF1X - этот система моделирования максимально адаптирована для создания реляционных моделей данных. Реляционная модель данных - это не физическая модель БД.
Спасибо за ссылку, уже начал читать статью.
Я просто уже запутался в этих моделях, мне нужно сделать и концептуальную модель и физическую модель и логическую.
Во всех примерах, что у меня есть от других студентов эти модели крайне похожи, ровно те же таблицы, те же атрибуты, те же связи.
Единственное различие - в концептуальной атрибуты написаны русским текстом, а в физической английским.
Еще один вопрос: должны ли в концептуальной модели быть все таблицы как в БД? Или все же я в чем то прав и в ней используются основные сущности?
Т.е. в ней не надо указывать, например, сущность "производитель товара".
-
Нет. В любой нотации можно разрабатывать ER модель разного уровня абстракции
Спасибо, а то я путаюсь уже (
-
Спасибо за ссылку, уже начал читать статью.
Я просто уже запутался в этих моделях, мне нужно сделать и концептуальную модель и физическую модель и логическую.
Во всех примерах, что у меня есть от других студентов эти модели крайне похожи, ровно те же таблицы, те же атрибуты, те же связи.
Единственное различие - в концептуальной атрибуты написаны русским текстом, а в физической английским.
Это издержки учебных примеров. В реальных системах отличия видны сразу.
Еще один вопрос: должны ли в концептуальной модели быть все таблицы как в БД? Или все же я в чем то прав и в ней используются основные сущности?
Т.е. в ней не надо указывать, например, сущность "производитель товара".
Концептуальная модель должна отвечать требованиям постановки - в ней должны присутствовать все необходимые сущности, отражены их отношения, присутвовать атрибуты, упоминаемые в постановке. Концептуальная модель - ЭТО НЕ ЧЕРНОВИК, не модель сделанная спустя рукава.
Концептуальная модель подвергается т.н. интерпретации - она должна отражать все понятия, встречающиеся в постановке
Вы не сможете сослаться в use case или любой другой диаграмме на сущность или атрибут, отсутсвующий в концептуальной модели. Физическая модель как правило дополняется большим количеством технических таблиц, которые не связаны с бизнес-обьектами. Но бизнес-обьекты в концептуальной модели должны быть все
-
Концептуальная модель должна отвечать требованиям постановки - в ней должны присутствовать все необходимые сущности, отражены их отношения, присутвовать атрибуты, упоминаемые в постановке. Концептуальная модель - ЭТО НЕ ЧЕРНОВИК, не модель сделанная спустя рукава.
Концептуальная модель подвергается т.н. интерпретации - она должна отражать все понятия, встречающиеся в постановке
Вы не сможете сослаться в use case или любой другой диаграмме на сущность или атрибут, отсутсвующий в концептуальной модели. Физическая модель как правило дополняется большим количеством технических таблиц, которые не связаны с бизнес-обьектами. Но бизнес-обьекты в концептуальной модели должны быть все
Получается, что достаточно трех сущностей, которые я уже пробовал использовать.
Т.к. остальные таблицы в БД это лишь справочники.
-
Получается, что достаточно трех сущностей, которые я уже пробовал использовать.
Возьмите исходную постановку и все ваши другие диаграммы и проверьте , достаточно или нет. И разберитесь с хранением количества и цены в заказе
Т.к. остальные таблицы в БД это лишь справочники.
В ER нет такого понятия - справочник. Есть сущности и отношения между ними.
На этом я самоустраняюсь. Информации Вам предоставлено более чем достаточно
-
Возьмите исходную постановку и все ваши другие диаграммы и проверьте , достаточно или нет. И разберитесь с хранением количества и цены в заказе
В ER нет такого понятия - справочник. Есть сущности и отношения между ними.
На этом я самоустраняюсь. Информации Вам предоставлено более чем достаточно
Большое Вам спасибо за разъяснения и потраченное на меня время.
-
IDEF1X это не физическая модель БД ?
И еще пара слов про различие.
Логические модели (или концептуальные, или какие угодно "бумажные") отражают информационные сущности (объекты) и связи между ними, которыми оперирует информационная система.
Физическая модель - это то, как информационные сущности были интерпретированы и реализованы в конкретной БД.
Разница может быть очень существенной.
Например, есть у вас 3 очень разных логических сущности: мимопроходимец, покупатель и администратор. Например, характеризуются они следующими атрибутами:
Мимопроходимец:
1. IP последнего посещения
2. Время последнего посещения
3. Количество посещенных страниц
Покупатель:
1. IP последнего посещения
2. Время последнего посещения
3. ФИО
4. Контактные данные
5. Заказы
6. История покупок
Администратор:
1. IP последнего посещения
2. Время последнего посещения
3. ФИО
4. Контактные данные
5. Полномочия
Так вот администратору БД ничего не стоит закатать их всех в одну таблицу БД со следующими полями:
1. IP последнего посещения
2. Время последнего посещения
3. Количество посещенных страниц
4. ФИО
5. Контактные данные
6. Заказы
7. История покупок
8. Полномочия
И в зависимости от того, какую из трех сущностей нужно сохранить, будет заполняться тот или иной набор полей в таблице.
В результате в логической модели будет три сущности и какие-то связи между ними (и другими сущностями), а в физической - только одна.
(приведенный пример ни в коем случае не является руководством к действию)
-
И еще пара слов про различие.
Логические модели (или концептуальные, или какие угодно "бумажные") отражают информационные сущности (объекты) и связи между ними, которыми оперирует информационная система.
Физическая модель - это то, как информационные сущности были интерпретированы и реализованы в конкретной БД.
Разница может быть очень существенной.
Небольшая ремарка - в ER предполагается третья нормальная форма, а разработчики для обеспечения гибкости, настраиваемости и т.д. идут на довольно грубую денормализацию
-
Небольшая ремарка - в ER предполагается третья нормальная форма,
Ну... Никогда не заморачивался, на самом деле. Вот то, под реляционную ли базу рисуется ER, или наоборот (под xml-свалку, например) - это да, это на модели сказывается. Хотя это уже, конечно, не ортодоксальная ER-каллиграфия.
а разработчики для обеспечения гибкости, настраиваемости и т.д. идут на довольно грубую денормализацию
Медом не корми - дай испортить идеальную модель своими грубыми лапами.
-
Медом не корми - дай испортить идеальную модель своими грубыми лапами.
Медом не медом, а жизнь себе хотят упростить созданием сущностей типа "всякая хрень, о которой мне лениво думать, пока проблема себя не обозначила". Всякие там "универсальные справочники", "универсальные классификаторы" - топикстартер норовит в эту помойку аж поставщиков засунуть.
А когда начинаются проблемы с ссылочной целостностью, интерпретационными свойствами, производительностью поиска оказываются почему -то виноваты аналитики
-
Медом не медом, а жизнь себе хотят упростить созданием сущностей типа "всякая хрень, о которой мне лениво думать, пока проблема себя не обозначила". Всякие там "универсальные справочники", "универсальные классификаторы" - топикстартер норовит в эту помойку аж поставщиков засунуть.
А когда начинаются проблемы с ссылочной целостностью, интерпретационными свойствами, производительностью поиска оказываются почему -то виноваты аналитики
У меня нет универсального справочника типа поставщиков...для поставщика, а точнее производителя у меня отдельный справочник 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 делали эти диаграммы, и оба раза нам толком не объясняли и на зачет или экзамен принимали кривые диаграммы (непонятно что).
Ни кто толком не объяснил зачем, для чего и почему сначала диаграмму, а потом проект. Что так логичней, что так проще потом будет сам проект делать.
В итоге у меня и всех моих одногруппников сложилось мнение, что главное сделать программу (или сайт), а уж диаграммы то нарисуем как-нибудь.
Но тут выпускная квалификационная работа. Как обычно делаю сначала сайт, а потом остальное. И тут на тебе, оказывается, что на защите мой сайт даже смотреть ни кто не будет, даже не проверит работает ли он. Главное это презентация, в которой будут диаграммы и пара скринов с сайта.
А в пояснительной записке главное не содержание (за исключением диаграмм конечно), главное чтобы по ГОСТу все было, чтобы таблицы правильно названы были, чтобы интервал полуторный и т.д. и т.п.
Вот так у нас выпускают программистов с высшим образованием.
-
Я ближе к цели ? =)
Безусловно. Элементы заказа обычно называют 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) А там где я делал эту модель, только куриные лапки, мне кажется главное чтобы я указал где какая связь, а уж как она будет нарисована нет разницы я думаю.
Согласен. Можно приложить таблички типа этой
(http://www.data-e-education.com/ERM/images/ERM_21_E_R_Model_Crows_Foot_Notation_02.png)
-
Диаграмма
-
А у меня связь один ко многим отличается, от того что у вас приведено в таблице.
-
И если захочется хранить историю цен (не только текущую цену, но и ту , которая была на товар 3,5 или 10 дней назад) то и ее тоже
В данной ситуации вполне достаточно иметь цену Элемента заказа. По дате заказа можно определить (и хранить) цену товара .
Сам товар хранит текущую цену. Как вариант.
-
В данной ситуации вполне достаточно иметь цену Элемента заказа. По дате заказа можно определить (и хранить) цену товара .
Сам товар хранит текущую цену. Как вариант.
Если нужна история цен как таковая, то вариант не годится. Цену могли задрать так , что продажи встали. Соответственно ни заказов, ни элементов на этот товар нет - статистику по цене не получим, менеджера-идиота не определим, будет просто малопонятная дыра в продажах
-
Диаграмма
А что это у вас за сущность Размер какая-то немного забавная?
-
А что это у вас за сущность Размер какая-то немного забавная?
Да, название наверно не очень)
У постельного белья есть размеры: полуторный, двуспальный, семейный, евро и т.д. - это название в таблице
А дальше идет размер наволочки, простыни и пододеяльника (70х70 и т.д.)
Это по большей части для отображения информации о товаре. Больше ни где не фигурирует.
-
В последнем варианте диаграммы верно я указал ключи в таблице Элемент заказа? Или там просто указать поле Товар и Заказ ?
-
Да, название наверно не очень)
У постельного белья есть размеры: полуторный, двуспальный, семейный, евро и т.д. - это название в таблице
А дальше идет размер наволочки, простыни и пододеяльника (70х70 и т.д.)
Это по большей части для отображения информации о товаре. Больше ни где не фигурирует.
Тогда и впрямь не очень. А чего их не разделить?
Размер - полуторный, двуспальный, семейный, евро
А собственно размеры пусть в товаре живут. Причем в одном атрибуте
-
Тогда и впрямь не очень. А чего их не разделить?
Размер - полуторный, двуспальный, семейный, евро
А собственно размеры пусть в товаре живут. Причем в одном атрибуте
Так у полуторного постельного белья свои размеры наволочки, пододеяльника и простыни, у евро другие. Зачем их в товар.
-
Так у полуторного постельного белья свои размеры наволочки, пододеяльника и простыни, у евро другие. Зачем их в товар.
Ну и что у полуторного всегда одеяло 180*200 всегда? А не может быть 182*198 например?
То есть по группе размеров примерные габариты есть, но в конкретном артикуле могут отличаться. Или фактические размеры никому не интересны?
-
Всегда 180х200, есть определенные стандарты размеров. Скажем так основная информация в этой таблице это название (полуторный и т.д.) а далее это уточняющие размеры, чтобы клиент наверняка не ошибся в выборе.
-
Да, название наверно не очень)
У постельного белья есть размеры: полуторный, двуспальный, семейный, евро и т.д. - это название в таблице
А дальше идет размер наволочки, простыни и пододеяльника (70х70 и т.д.)
Это по большей части для отображения информации о товаре. Больше ни где не фигурирует.
Постельное белье, постельному белью рознь.
Есть понятие комплект постельного белья, размер его в этом случае можно определить прямо в названии. Но можно и иначе конечно.
С другой стороны вполне можно покупать отдельные наволочки и т.п., хотя возможно этого не происходит в вашей предметной области.
-
Постельное белье, постельному белью рознь.
Есть понятие комплект постельного белья, размер его в этом случае можно определить прямо в названии. Но можно и иначе конечно.
С другой стороны вполне можно покупать отдельные наволочки и т.п., хотя возможно этого не происходит в вашей предметной области.
Все верно, у меня продажа именно КПБ - комплект постельного белья.
То есть здесь размеры скорее как описание товара что ли. Но в то же время функциональную роль они естественно играют, ведь не каждый человек знает, что такое полуторный или евро размер.
-
Всегда 180х200, есть определенные стандарты размеров. Скажем так основная информация в этой таблице это название (полуторный и т.д.) а далее это уточняющие размеры, чтобы клиент наверняка не ошибся в выборе.
Тогда все правильно. Могу только предложить название поменять. Не размер, а Стандарт размеров или Типоразмер
-
Стандарт размеров было бы не плохо, но я пожалуй оставлю, потому что как мы помним БД у меня уже есть и код тоже, очень много менять кода придется в запросах.
Что ж раз с этой моделью все более менее ясно, за что всем спасибо большое, то просьба посмотреть на физическую модель.
Скажу сразу, не совсем понимаю, почему именно такие связи установлены между элементом заказа и таблицами Товар и Заказ.
PowerDesigner их так сам поставил.
Мне кажется, наоборот другие связи должны быть не идентифицирующие, а эти две идентифицирующая.
-
Стандарт размеров было бы не плохо, но я пожалуй оставлю, потому что как мы помним БД у меня уже есть и код тоже, очень много менять кода придется в запросах.
Это конечно важные соображения, но крайне не рекомендуется принимать их во внимание на реальных проектах. Разработка и поддержка КМ требует максимального перфекционизма, на который способен аналитик. В реальных проектах участвует множество людей, и любая такая непонимашка, типа той, которой высказали я и Galogen, легко оборачиваясь в человеко- месяцы работы, а то и в продукт с конструктивными недостатками.
Так же не очень понял про запросы - в КМ русские наименования, в физической БД английские. В чем переделка?
-
мне кажется главное чтобы я указал где какая связь, а уж как она будет нарисована нет разницы я думаю.
Вам виднее, каковы требования по оформлению Вашей дипломной работы.
-
Это конечно важные соображения, но крайне не рекомендуется принимать их во внимание на реальных проектах. Разработка и поддержка КМ требует максимального перфекционизма, на который способен аналитик. В реальных проектах участвует множество людей, и любая такая непонимашка, типа той, которой высказали я и Galogen, легко оборачиваясь в человеко- месяцы работы, а то и в продукт с конструктивными недостатками.
Так же не очень понял про запросы - в КМ русские наименования, в физической БД английские. В чем переделка?
Да по сути только в этом и есть.
Ну еще связь почему то от элемента заказа к товару и заказу, не ставится 1 ко многим как у других таблиц.
А чем она может еще отличаться? Физическая модель это же по сути тоже что у меня в БД находится, так?
-
Если тема посвящена не концептуальным моделям предметных областей вообще, а модели конкретной предметки — предлагаю её так и назвать.