Databases Reference
In-Depth Information
notion, but in many cases it doesn't match reality, because systems change not only
during development, but also during their production lifetimes.
The amortized view of data model change, in which costly changes during development
are eclipsed by the long-term benefits of a stable model in production, assumes that
systems spend the majority of their time in production environments, and that these
production environments are stable. Though it may be the case that most systems spend
most of their time in production environments, these environments are rarely stable.
As business requirements change or regulatory requirements evolve, so must our sys‐
tems and the data structures on which they are built.
Data models invariably undergo substantial revision during the design and development
phases of a project, and in almost every case, these revisions are intended to accom‐
modate the model to the needs of the applications that will consume it once it is in
production. These initial design influences are so powerful that it becomes nearly im‐
possible to modify the application and the model once they're in production to accom‐
modate things they were not originally designed to do.
The technical mechanism by which we introduce structural change into a database is
called
migration
, as popularized by application development frameworks such as
refactorings
to a database so that it can be responsibly evolved to meet the changing
needs of the applications that use it. Unlike code refactorings, however, which we typ‐
ically accomplish in a matter of seconds or minutes, database refactorings can take weeks
or months to complete, with downtime for schema changes. Database refactoring is
slow, risky, and expensive.
The problem, then, with the denormalized model is its resistance to the kind of rapid
evolution the business demands of its systems. As we've seen with the data center ex‐
ample, the changes imposed on the whiteboard model over the course of implementing
a relational solution create a gulf between the conceptual world and the way the data is
physically laid out; this conceptual-relational dissonance all but prevents business
stakeholders from actively collaborating in the further evolution of a system. Stake‐
holder participation stops at the threshold of the relational edifice. On the development
side, the difficulties in translating changed business requirements into the underlying
and entrenched relational structure cause the evolution of the system to lag behind the
evolution of the business. Without expert assistance and rigorous planning, migrating
a denormalized database poses several risks. If the migrations fail to maintain storage-
affinity, performance can suffer. Just as serious, if deliberately duplicated data is left
orphaned after a migration, we risk compromising the integrity of the data as a whole.
Graph Modeling in a Systems Management Domain
We've seen how relational modeling and its attendant implementation activities take us
down a path that divorces an application's underlying storage model from the conceptual
