2

I am modeling our existing database in transition to a graph database.

Currently here is how I can interpret the database a graph relationships

group -have-> groups group -have-> participants participant -is-> user user -has-> profile user -has-> user-accounts user-account -composed of-> social-logins user-account -composed of-> username-password

Does these seem like valid relationships? Examples of relationships I have read includes the following which seems better but I can't think of thing else that can fit better for the existing relationships.

actor - acted-in -> movie director - directed -> movie supplier - supplies -> product

UPDATE: Here is an articles I've already read. From what I can tell, https://neo4j.com/developer/relational-to-graph-modeling/#_modeling_from_relational_to_graph suggestions could be

 belongs-to is-part-of
Improve this question

1 Answer 1

Reset to default
1

If you have an existing relational database design you have the first iteration of your graph design. The table rows will become nodes and foreign keys will become the relationships.

In graphs, as in ERD design, avoid wishy-washy relationship names. "Has", "is" and their ilk say nothing positive about the business domain. Worse, they can cause confusion as each person reads into these weak names whatever their understanding is. Take "group -have-> groups" as an example. Is that saying the left-hand group is a super-set of the right-hand groups, or a sub-set of, or is administered by, or must exclude, or ... You see my point?

Instead use words the business domain uses. The relationship should document the role the association plays within the application and the domain. It should be specific and it should be single. If there are multiple reasons to link node A with node B then created a separate well-named relationship for each reason.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.