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


1 Answer 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.