Databases Reference
In-Depth Information
be used to derive the changed view mapping v
0
by composing the inverse of the
evolution mapping with the view mapping v.
-
Automatic instance migration
: Instances of a changed schema or ontology should
automatically be migrated to comply with the specified changes. This may be
achieved by executing an instance-level mapping (e.g., in SQL or XQuery)
derived from the evolution mapping. Database schema evolution also requires
the adaptation of affected index structures and storage options (e.g., clustering
or partitioning), which should be performed without reducing the availability of
the database (online reorganization). There are different options to perform such
instance and storage structure updates: either in place or on a copy of the orig-
inal data. The copy approach is conceptually simpler and keeping the original
data simplifies undoing an erroneous evolution. On the other hand, copying is
inherently slow for a large amount of data most of which are likely unaffected
by the schema change. Furthermore, data migration can be performed eagerly
(expensive, but fast availability of changes) or lazily. Instance migration should
be undoable if anything goes wrong, which can be achieved by running it under
transactional control.
-
Propagation of schema changes to related mappings and schemas
: Schemas are
frequently related to other schemas (by mappings) so that schema changes may
have to be propagated to these related schemas. This should be performed in
a largely automatic manner supporting a maximum of backward compatibil-
ity. Important use cases of this general requirement include the maintenance of
views, integrated (global) schemas, and conceptual schemas. As discussed view
schemas may be kept stable for information-preserving changes by adapting the
view mapping according to a schema change; deleted or added schema compo-
nents on the other hand may also require the adaptation of views. Data integration
architectures typically rely on mappings between source schemas and a global
target (mediator or warehouse) schema and possibly between source schemas and
a shared ontology. Again, some schema changes (e.g., renames) may be covered
by only adapting the mappings, while other changes such as the provision of new
information in a source schema may have to be propagated to the global schema.
Finally, interrelating database schemas with their conceptual abstractions, e.g., in
UML or the entity/relationship (ER) model, require evolution support. Changes
in the UML or ER model should thus be consistently propagated to the database
schema and vice versa (reverse engineering).
-
Versioning support
: Supporting different explicit versions for schemas and onto-
logies and possibly for their associated instances supports evolution transparency.
This is because schema changes are reflected in new versions leaving former
versions that are in use in a stable state. Different versioning approaches are fea-
sible, e.g., whether only a sequence of versions is supported or whether one can
derive different versions in parallel and merge them later on. For full evolution
transparency, it is desirable to not only support backward compatibility (appli-
cations/queries of the old schema version S can also use S
0
)butalso
forward
compatibility
between schema versions S and S
0
, i.e., applications of S
0
can also
use S.
