Database Reference
In-Depth Information
Granulate nodes
The typical graph modeling pattern that we will discuss in this section will be called
the granulate pattern. This means that in graph database modeling, we will tend to
havemuchmoreine-graineddatamodelswithahigherlevelof"granularity"than
we would be used to having in a relational model.
In a relational model, we use a process called database normalization to come up
withthegranularityofourmodel.Wikipediadeinesthisprocessas:
"…the process of organizing the ields and tables of a relational database to
minimize redundancy and dependency. Normalization usually involves dividing
large tables into smaller (and less redundant) tables and deining relationships
between them. The objective is to isolate data so that additions, deletions, and
modiications of a ield can be made in just one table and then propagated through
the rest of the database using the deined relationships."
The reality of this process is that we will create smaller and smaller table structures
until we reach the third normal form. This is a convention that the IT industry seems
to have agreed on—a database is considered to have been normalized as soon as it
achieves the third normal form. Visit
http://en.wikipedia.org/wiki/Database_
normalization#Normal_forms
for more details.
As we discussed before, this model can be quite expensive, as it effectively
introduces the need for join tables and join operations at query time. Database
administrators tend to denormalize the data for this very reason, which introduces
data-duplication—another very tricky problem to manage.
In graph database modeling, however, normalization is much cheaper for the simple
reason that these infamous join operations are much easier to perform. This is why
we see a clear tendency in graph models to create "thin" nodes and relationships,
that is, nodes and relationships with few properties on them. These nodes and
relationships are very granular and have been "granulated".
Related to this pattern is a typical question that we get asked and ask ourselves
in every modeling session: should I keep this as a property or should the property
becomeitsownnode?Forexample,shouldwemodelthealcoholpercentageofa
beerasapropertyonabeerbrand?Thefollowingdiagramshowsthemodelwith
the alcohol percentage as a property:
