Databases Reference
In-Depth Information
Figure 3-5. Example graph for the data center deployment scenario
And logically, that's
all
we need to do. No tables, no normalization, no denormalization.
Once we have an accurate representation of our domain model, moving it into the
database is, as we shall see shortly, trivial.
Testing the Model
Once we've refined our domain model, the next step is to test how suitable it is for
answering realistic queries. Although graphs are great for supporting a continuously
evolving structure (and therefore for correcting any erroneous earlier design decisions),
there are a number of design decisions which, once they are baked into our application,
can hamper us further down the line. By reviewing the domain model and the resulting
graph model at this early stage, we can avoid these pitfalls. Subsequent changes to the
graph structure will then be driven solely by changes in the business, rather than by the
need to mitigate poor design decisions.
In practice there are two techniques that we can apply here. The first, and simplest, is
just to check that the graph reads well. We pick a start node, and then follow relationships
to other nodes, reading each node's role and each relationship's name as we go. Doing
