Как одобрить модель данных для услуги, предоставляемой человеком, График Моделирование данных

Question

Привет, я новичок в моделировании баз данных графов и у меня есть некоторые сомнения по поводу выражения одобрения за услугу, предоставляемую Лицом.Вариант использования следующий.PersonA дает Одобрение Сервису, предоставленному PersonB.

Ключевым моментом является то, что если я получаю одобрение, я хотел бы знать, кто поддержал меня.Я придумал несколько сценариев того, как я могу это сделать, но из-за недостатка опыта у меня есть сомнения в том, что будет лучшим подходом.

Сценарий 1.

Индоссамент выражается непосредственно как отношение, а услуга переходит в собственность как индоссамент. Таким образом, это будет выглядеть так:

PersonA-------ENDORSE{service}--->PersonB 

Сценарий 2

Я моделирую сущность с именем Сервис.Проблема заключается в том, что, когда я выполняю отношение «ENDORSE» к сервису, я теряю информацию о том, кого я поддерживаю.Таким образом, я должен был бы сохранить собственность в отношениях с тем, кого я поддерживаю.Затем PersonB должен получить одобрение за СЕРВИС, но он не будет знать, кто на самом деле дает одобрение.Итак ..... это будет выглядеть так:

PERSONA----ENDORSE{personB}--->Service------ENDORSMENT{personA}--->PERSONB

Имеет ли это смысл?

Сценарий 3:

Я нормализую второе отношение "ENDORSMENT" и исключаю personA как свойство, но затем мне нужно запросить все Person, чтобы выяснить, кто имеетони одобрили.

Как бы вы смоделировали такие отношения?

Answer 1

Два важных принципа проверки модели данных для графической базы данных:

• , если объект или факт можно использовать более одного раза, он должен быть сохранен как узел

Так что @Raj указал правильный путь, и в этом случаеМодель может выглядеть так:

Рекомендую прочитать:

• https://neo4j.com/graph-databases-book/
• http://patterns.dataincubator.org/book/

Answer 2

Второй подход выглядит хорошо, вам не нужно добавлять эти свойства в отношения.

Можно получить человека A, который одобрил человека B, для службы S. Единственная проблема с этим - наличие нескольких узлов для любой службы S. Если это не приемлемо.

Вы можете заменить узел службы во втором подходе узлом подтверждения E и подключить это E к узлу обслуживания S. Таким образом, будет четыре типа узлов.

РЕДАКТИРОВАТЬ:

Добавление изображения для уточнения.Переименуйте REL1 и REL2, как вы хотите. @ Stdob предложил несколько хороших имен для этих отношений.