Принципы построения графовой базы данных, общие принципы и проблема детализации

Question

В проектировании реляционных баз данных существуют нормальные формы для руководства процессом проектирования. Существуют ли похожие принципы, которые применяются к проектированию графовых баз данных, например, neo4j?

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

Эти проблемы схожи с моими вопросами для начинающих, когда я начинал проектировать SQL, и многие из них можно было решить только с помощью опыта. Тем не менее, вы можете порекомендовать хорошую практическую книгу по самым основам этой темы или указать мне, где найти некоторые общие принципы?

Answer 1

Я не видел ничего такого, что воспринималось бы как истина, совсем как нормализация в реляционных базах данных.Тем не менее, я бы отстаивал две вещи:

1) Моделируйте ваши сущности (узлы), как обычно.Атрибуты этих сущностей - это вещи, которые принадлежат именно этим сущностям и существуют вне отношений (связей).

2) Моделируйте ваши отношения (ребра), как обычно.Эти атрибуты не должны существовать, за исключением случаев, когда два объекта (узла) связаны (связаны).