Databases Reference
In-Depth Information
and virtual machine instances migrate. Given these needs and constraints, let's see how
the relational and graph models compare.
Relational Modeling in a Systems Management Domain
The initial stage of modeling in the relational world is similar to the first stage of many
other data modeling techniques: that is, we seek to understand and agree on the entities
in the domain, how they interrelate, and the rules that govern their state transitions.
Most of this tends to be done informally, often through whiteboard sketches and dis‐
cussions between subject matter experts and systems and data architects. To express our
common understanding and agreement, we typically create a diagram such as the one
in
Figure 3-2
, which is a graph.
The next stage captures this agreement in a more rigorous form such as an entity-
relationship (E-R) diagram—another graph. This transformation of the conceptual
model into a logical model using a more strict notation provides us with a second chance
to refine our domain vocabulary so that it can be shared with relational database spe‐
cialists. (Such approaches aren't always necessary: adept relational users often move
directly to table design and normalization without first describing an intermediate E-
R diagram.) In our example, we've captured the domain in the E-R diagram shown in
Figure 3-3
.
Despite being graphs, E-R diagrams immediately demonstrate the
shortcomings of the relational model for capturing a rich domain. Al‐
though they allow relationships to be named (something that graph
databases fully embrace, but which relational stores do not), E-R dia‐
grams allow only
single, undirected
, named relationships between en‐
tities. In this respect, the relational model is a poor fit for real-world
domains where relationships between entities are both numerous and
semantically rich and diverse.
Having arrived at a suitable logical model, we map it into tables and relations, which
are normalized to eliminate data redundancy. In many cases this step can be as simple
as transcribing the E-R diagram into a tabular form and then loading those tables via
SQL commands into the database. But even the simplest case serves to highlight the
idiosyncrasies of the relational model. For example, in
Figure 3-4
we see that a great
deal of accidental complexity has crept into the model in the form of foreign key con‐
straints (everything annotated
[FK]
), which support one-to-many relationships, and
join tables (e.g.,
AppDatabase
), which support many-to-many relationships—and all
this before we've added a single row of real user data. These constraints are model-level
metadata that exist simply so that we can make concrete the relations between tables at
