Графическое моделирование логического значения - свойство отношения или свойство узла или его вообще нет? - PullRequest
Новая
       57

Графическое моделирование логического значения - свойство отношения или свойство узла или его вообще нет?

0 голосов
/ 19 апреля 2020

Контекст

У бизнеса много партнеров. Каждый партнер может предложить несколько услуг своим клиентам. Некоторые партнеры предлагают все услуги, некоторые предлагают несколько. Бизнес всегда может продать Продукт этому Партнеру, и какой Продукт может быть продан, зависит от того, предлагает ли Партнер конкретную Услугу или нет. Таким образом, бизнес может продать Продукт A Партнеру A, предлагающему Услугу A. Они могут предложить Продукт B Партнеру A, если они не предлагают Услугу B.

Вопрос - если Партнеры, Продукты, Услуги это узлы, где мне следует смоделировать вопрос «Эта Служба предлагается этим Партнером?» Другой бизнес-вопрос был бы «Каков мой рынок для Продукта А?», который должен вернуть всех Партнеров, которые не предлагают Услугу, построенную на Продукте. A. Должен ли я сделать:

  1. Partner_OFFERS_Service_BUILT_WITH_Product (иметь только отношения Partner_Service, где предлагается = да). В этом случае, как я могу вернуть партнерам, которым может быть продан продукт за услугу, которую они не предоставляют? t еще предлагают?
  2. Partner_COULD-OFFER_Service_BUILT_WITH_Product и имеют Offered = yes / no в качестве свойства в отношении COULD_OFFER
  3. Partner_COULD-OFFER_Service_BUILT_WITH_Product, и имеют Offered = yes / no как свойство на узле Service. РЕДАКТИРОВАТЬ: Это не сработает, поскольку я не могу иметь это свойство для каждого партнера.
  4. Имеют 2 различных типа отношений - OFFERS и DOESNT_OFFER для связи с каждым партнером. каждому порок, но затем есть механизм для переключения отношений при изменении принятия.

Это будет бэкэнд для приложения Spring Java. Я понимаю, что это можно сделать несколькими способами, и я пытаюсь понять простейший способ сделать это с точки зрения запросов и кодирования.

EDIT Обсудив с пользователями, требование только усложнилось. То, что они на самом деле делают, это что-то вроде таблицы в реляционном мире со следующими столбцами (ее денормализовано с большим количеством повторяющихся данных:

PartnerName | Service | Offered? |CurrentlyUsing | WeCouldSellThese |

XX | Baking | Yes |Competitor A, B | Product A | XX | Baking | Yes |Competitor A, B | Product C | XX | Baking | Yes |Competitor A, B | Product D | XX | OnlyDough| Yes |Product A | Product C | XX | Packing | No | | Product E |

В основном, им нужно хранить информацию о том, что используется в настоящее время, и независимо от того, предлагается ли она в настоящее время партнером или нет, они все еще пытаются продать им продукты (предложенные «да» или «нет», все равно приведут к рынку). отношения между услугой и продуктом ... а это означает, что существует отношение "3-узел" - потенциальный партнер определен как конкретный партнер для конкретного продукта для конкретной услуги, я пробовал следующую модель, но не уверен, как запросите Could_Buy и To_Build вместе, когда будет несколько таких отношений для одного продукта. graph model

1 Ответ

0 голосов
/ 19 апреля 2020

Самый простой c дизайн, который должен работать для вас, - это создание следующих отношений:

  1. Узел (Партнер) - [ПРЕДЛОЖЕНИЯ] -> Узел (Сервис)

  2. Узел (Сервис) - [BUILT_WITH] -> Узел (Сервис)

    Пример: PartnerA - ПРЕДЛОЖЕНИЯ - ServiceA, ПродуктA - BUILT_WITH - СервисA, ПродуктB - BUILT_WITH - СервисB

Теперь, как ответить на ваши деловые вопросы:

  1. Is this Service offered by this Partner?: Это довольно просто. Вам просто нужно проверить, существуют ли отношения «ПРЕДЛОЖЕНИЯ» между Сервисом и Партнером.
  2. What's my market for Product A?: Вы можете получить все Услуги «BUILT_WITH» Продукт A. (который является ServiceA). Затем выберите все узлы-партнеры, для которых не существует отношения «ПРЕДЛОЖЕНИЯ» с ServiceA. Я уверен, что один запрос может помочь достичь этого результата в Neo4j.
...