Databases Reference
In-Depth Information
worldview of its stakeholders. Relational databases—with their rigid schemas and com‐
plex modeling characteristics—are not an especially good tool for supporting rapid
change. What we need is a model that is closely aligned with the domain, but which
doesn't sacrifice performance, and which supports evolution while maintaining the in‐
tegrity of the data as it undergoes rapid change and growth. That model is the graph
model. How, then, does this process differ when realized with a graph data model?
In the early stages of analysis, the work required of us is similar to the relational ap‐
proach: using lo-fi methods such as whiteboard sketches, we describe and agree upon
the domain. After that, however, the methodologies diverge. Instead of transforming a
domain model's graph-like representation into tables, we enrich it, with the aim of pro‐
ducing an accurate representation of the salient aspects of the domain relevant to what
we are trying to achieve in that domain. That is, for each entity in our domain, we ensure
that we've captured both the properties and the connections to neighboring entities
necessary to support our application goals.
Remember, the domain model is not a transparent, context-free win‐
dow onto reality: rather, it is a purposeful abstraction of those aspects
of our domain relevant to our application goals. There's always some
motivation for creating a model. By enriching our first-cut domain
graph with additional properties and relationships, we effectively pro‐
duce a graph model attuned to our application's data needs; that is, we
provide for answering the kinds of questions our application will ask of
its data.
Helpfully, domain modeling is completely isomorphic to graph modeling. By ensuring
the correctness of the domain model we're implicitly improving the graph model, be‐
cause in a graph database
what you sketch on the whiteboard is typically what you store
in the database
.
In graph terms what we're doing is ensuring each node has the appropriate properties
so that it can fulfil its specific data-centric domain responsibilities. But we're also en‐
suring that every node is in the correct semantic context; we do this by creating named
and directed (and often attributed) relationships between the nodes to capture the
structural aspects of the domain. For our data center scenario, the resulting graph model
looks like
Figure 3-5
.
