Databases Reference
In-Depth Information
-
Powerful schema evolution infrastructure
: The comprehensive support for sch-
ema evolution discussed before requires a set of powerful and easily usable tools,
in particular to determine the impact of intended changes, to specify incremen-
tal changes, to determine Diff evolution mappings, and to perform the specified
changes on the schemas, instances, mappings, and related schemas.
3
Relational Schema Evolution Approaches
By far, the most predominantly used model for storing data is the relational model.
One foundation of relations is a coupling between instances and schema, where
all instances follow a strict regular pattern; the homogeneous nature of relational
instances is a foundational premise of nearly every advantage that relational systems
provide, including query optimization and efficient physical design. As a conse-
quence, whenever the logical scheme for a table changes, all instances must follow
suit. Similarly, whenever the set of constraints on a database changes, the set of
instances must be validated against the new set of constraints, and if any violations
are found, either the validations must be resolved in some way or, more commonly,
the schema change is rejected.
An additional complication is the usually tight coupling between applications and
relational databases or at least between the data access tier and the database. Because
the SQL query language is statically typed, application queries and business logic
applied to query results are tightly coupled to the database schema. Consequently,
after a database schema is upgraded to a new version, multiple applications may
still attempt access to that database concurrently. The primary built-in support pro-
vided by SQL for such schema changes is
external schemas
, known more commonly
as views. When a new version of an application has different data requirements,
one has several options. First, one can create views to support the new applica-
tion version leaving existing structures intact for older versions. Or, one can adapt
the existing schema for the new application and maintain existing views to pro-
vide backward compatibility for existing applications. In both cases, the views may
be virtual, in which case they are subject to the stringent rules governing updatable
views, or they may be materialized, in which case the application versions are essen-
tially communicating with different database versions. However, the different views
have no semantic relationship and no intrinsic notion of schema version, and thus
no clean interoperability.
For the rest of this section, we first consider the current state of the art in
relational database systems regarding their support for schema evolution. We exam-
ine their language, tool, and scenario support. We then consider recent research
revelations in support for relational schema evolution. Finally, we use Table
6.1
to summarize the schema evolution support of the considered approaches w.r.t.
requirements introduced in Sect.
2
.
