Chapter 3. Revisiting Modeling Decisions
Graph modeling is an intuitive process that requires a clear understanding of the use cases in your business. It’s different from relational schema design, and the flexibility and lack of fixed rules can be bewildering at first, but as you get used to the process, you’ll find that it is a rewarding exercise.
You’ll use the graph you created in Chapter 1 to try some of the queries that follow.
It Depends
Let’s say you’ve been given a dataset that contains tracks, albums, artists, and their genres, and you want to design a schema for a relational database management system (RDBMS). You’d probably apply the familiar set of normalization rules1 and end up with a similar structural model—table and column names might vary—as in Figure 3-1.
Figure 3-1. Schema for an RDBMS
How do you model this as a graph? Your answer, as a seasoned graph modeler, should be, “It depends!” Really? Yes, really. Figures 3-2 to 3-4 show three graph models, all of which are valid.
Figure 3-2. Model A models genres as a property of the artist.
Figure 3-3. Genres are nodes and the album is a property in Model B.
Figure 3-4. Model C with a TRACK_VERSION node and genres ...
Become an O’Reilly member and get unlimited access to this title plus top books and audiobooks from O’Reilly and nearly 200 top publishers, thousands of courses curated by job role, 150+ live events each month,
and much more.
Read now
Unlock full access