Databases Reference
In-Depth Information
derived
schema (view)
V
view mapping v
v
′
Evolution
mapping
Schema
S
S
¢
Instance
mapping
Instances
D
D
¢
D
¢
Fig. 6.1
Schema evolution scenario
Similarly, instance changes/migration can be specified by an instance mapping, e.g.,
a sequence of SQL operations. A main requirement for database schema evolu-
tion is thus to propagate the schema changes to the instances, i.e., to derive and
execute an instance mapping correctly and efficiently implementing the changes
specified in the evolution mapping. Changes to schema S can also affect all other
usages of S, in particular the applications using S or other schemas and views related
to S. Schema changes may thus have to be propagated to dependent schemas and
mappings. To avoid the costly adaptation of applications they should be isolated
from schema changes as much as possible, e.g., by the provision of stable schema
versions or views. For example, applications using view V remain unaffected by
the change from S to S
0
if the view schema V can be preserved, e.g., by adapt-
ing view mapping v to v
0
(Fig.
6.1
). There are similar evolution requirements for
XML schemas and ontologies, although they are less tightly connected to instance
data and have different usage forms than database schemas as we will see (e.g.,
XML schemas describing web service interfaces; ontologies may only provide a
controlled vocabulary).
In the following sections, we discuss in detail general and more specific desider-
ata and requirements for effective schema and ontology evolution. These require-
ments are then used in the subsequent sections to review and compare existing and
proposed evolution approaches.
We see the following general desiderata for a powerful schema evolution support:
-
Completeness
: There should be support for a rich set of schema changes and their
correct and efficient propagation to instance data and dependent schemas.
-
Minimal user intervention
: To the degree possible, ensure that the schema evolu-
tion description is the only input to the system and that other artifacts co-evolve
automatically.
-
Transparency
: Schema evolution should result into minimal or no degradation
of availability or performance of the changed system. Furthermore, applications
and other schema consumers should largely be isolated from the changes, e.g.,
by support for backward compatibility, versioning, or views.
