Разработка модели данных и модели предметной области - PullRequest
Новая
       23

Разработка модели данных и модели предметной области

1 голос
/ 17 июня 2009

Я пытаюсь смоделировать продуктовый магазин. В магазине есть несколько «проходов». Каждый «проход» имеет группу «категорий» «предметов», которые он хранит. Каждая «категория» может принадлежать только одному «проходу». Каждый «предмет» может иметь только одну «категорию».

Модель данных мне кажется простой:

  • Таблица "проходов" с идентификатором и ОПИСАНИЕМ
  • Таблица «категории» с идентификатором, ИМЯ и AISLE_ID, которая ссылается на таблицу «прохода»
  • Таблица «item» с идентификатором, NAME, DESCRIPTION и CATEGORY_ID, которая ссылается на «category»

В объектной модели мне нужна помощь:

  1. Объект Aisle может иметь список объектов Category и Item.
  2. Объект Aisle может иметь список объектов Category. Объект Category может иметь список объектов Item внутри него.
  3. Проход может иметь список объектов Предмета. Объект Category может иметь список объектов Item.

В каждом случае Предмет логически будет иметь объект Категории внутри него. У меня есть DAO для каждого объекта домена, поэтому в зависимости от того, как это делается, sql немного меняется. Есть мысли?

Ответы [ 3 ]

1 голос
/ 17 июня 2009

Я бы выбрал вариант №2.

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

1 голос
/ 17 июня 2009

Номер 2 наиболее целесообразен, если это только ваши 3 варианта.

Я думаю, что если бы я создал эту модель, я бы использовал следующую модель (небольшая модификация, просто стараясь максимально приблизиться к вашим идеям):

Объект прохода может иметь список объектов категории, объект категории может содержать список объектов элемента внутри него, , и элемент связан с категорией И проходом.

Кажется, моя модификация больше касается данных.

Причина, по которой я бы это сделал, заключается в том, что кто-то говорит: "Эй, я ищу этот конкретный предмет, в каком проходе он находится?" - 1 поиск даст вам ответ. в то время как с вашей моделью данных вам потребуется 2 поиска.

По крайней мере, я так думаю об этом.

1 голос
/ 17 июня 2009

Я голосую за выбор № 2. Имеет больше смысла, чем № 1 или № 3.

Как вы думаете, отношения должны быть двунаправленными? Должен ли предмет иметь возможность выяснить, кто является его родительской категорией и проходом для прародителя?

...