Мы начали несколько сессий по моделированию графов в Лондоне, и в ходе первой сессии было отмечено, что описанный мной процесс очень похож на процесс моделирования реляционной базы данных.
Я подумал, что мне лучше почитать, как создаются реляционные модели, и я наткнулся на отличное видео Джо Магуайра под названием « У разработчиков моделей данных все еще есть рабочие места: настройка для среды NoSQL ».
Джо начинает с того, что показывает следующую «общую картину», которая описывает шаги, необходимые для создания реляционной модели :
Несколько слайдов позже он указывает, что мы часто стираем границы между различными этапами и заканчиваем проектированием модели, которая содержит много деталей реализации:
Если, с другой стороны, мы сравниваем концептуальную модель с графовой моделью, это не представляет особой проблемы, поскольку две модели отображаются достаточно близко:
- Объекты -> Узлы / Метки
- Атрибуты -> Свойства
- Отношения -> Отношения
- Идентификаторы -> Уникальные ограничения
Уникальные ограничения не совсем фиксируют все, что делают идентификаторы, поскольку можно создать узел определенной метки без указания свойства, которое однозначно ограничено. Кроме этого, хотя каждая концепция соответствует один за другим.
Мы часто говорим, что графики удобны для белой доски, поэтому мы подразумеваем, что модель, которую вы рисуете на белой доске, такая же, как и та, которая хранится в базе данных.
Например, рассмотрим следующий набросок людей и их взаимодействия с различными книгами:
Если бы мы перевели это в запрос на запись с использованием языка запросов Neo4j, он бы выглядел так:
CREATE (ian:Person {name: "Ian"})
CREATE (alan:Person {name: "Alan"})
CREATE (gg:Person:Author {name: "Graham Greene"})
CREATE (jlc:Person:Author {name: "John Le Carre"})
CREATE (omih:Book {name: "Our Man in Havana"})
CREATE (ttsp:Book {name: "Tinker Tailor, Soldier, Spy"})
CREATE (gg)-[:WROTE]->(omih)
CREATE (jlc)-[:WROTE]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "05-02-2011"}]->(ttsp)
CREATE (ian)-[:PURCHASED {date: "08-09-2011"}]->(omih)
CREATE (alan)-[:PURCHASED {date: "05-07-2014"}]->(ttsp)
Есть несколько дополнительных скобок и ключевое слово «CREATE», но мы не потеряли верности домена, и, по моему опыту, нетехнический / коммерческий человек мог бы понять запрос.
В отличие от этого, эта статья показывает шаги, которые мы могли бы предпринять от концептуальной модели, описывающей сотрудников, отделов и профсоюзов, до возможной реляционной модели.
Если у вас нет времени, чтобы прочитать это, мы начнем с этой первоначальной модели …
… И к тому времени, когда мы добрались до модели, которая может быть сохранена в нашей реляционной базе данных:
Вы заметите, что мы потеряли типы отношений, и они были заменены 4 внешними ключами, которые позволяют нам объединять различные таблицы / наборы вместе.
В графовой модели мы смогли бы быть намного ближе к концептуальной модели и, следовательно, ближе к языку бизнеса.
Я все еще изучаю мир моделирования данных, и теперь я должен прочитать книгу Джо « Mastering Data Modeling ». Мне также любопытно, как нормальные формы и избыточность данных применяются к графам, поэтому я также буду изучать это.
Мысли приветствуются, как обычно!