График, моделирующий «переходные» отношения

Question

Это продолжение более раннего вопроса , который я опубликовал и принял ответ. У меня есть еще один вопрос после получения обратной связи, и я пытаюсь опубликовать как новый вопрос, чтобы надеяться получить ответ.

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

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-узел" - конкретный партнер для конкретного продукта для конкретной услуги, вот два варианта, о которых я думаю. Проблема с вариантом 1 заключается в том, что Продукт А будет иметь много исходящих отношений To_Build, поэтому у меня нет способа выяснить, для какого партнера.

Вот варианты после того, как я создать новую сущность для разделения отношений:

Answer 1

Вы можете использовать дополнительный узел (скажем, помеченный как «Build»), чтобы «переопределить» «отношение с 3 узлами». Например:

Кстати, вы также должны учитывать, является ли отношение Could_Offer избыточным. Например, вы можете добавить свойство isOffered в отношение Could_Build и исключить отношение Could_Offer.