Databases Reference
In-Depth Information
The general desiderata are hard to meet and imply support for a series of more
specific, interrelated features:
-
Rich set of simple and complex changes
: Simple changes refer to the addi-
tion, modification, or deletion of individual schema constructs (e.g., tables and
attributes of relational databases), while complex changes refer to multiple such
constructs (e.g., merging or partitioning tables) and may be equivalent to multi-
ple simple changes. There are two main ways to specify such changes and both
should ideally be supported. The straightforward approach is to explicitly specify
schema modification statements to incrementally update a schema. Alternatively,
one can provide the evolved schema, thereby providing an implicit specification
of the changes compared to the old schema. This approach is attractive since it
is easy to use and since the updated schema version may contain several changes
to apply together.
-
Backward compatibility
: For transparency reasons, schema changes should min-
imally impact schema consumers and applications. We therefore require support
for
backward compatibility
meaning that applications/queries of schema S should
continue to work with the changed schema S
0
. This requires that schema changes
do not result in an information loss but preserve or extent the so-called informa-
tion capacity of schemas (
Miller et al. 1994
). Changes that are potentially lossy
(e.g., deletes) should therefore be either avoided or limited to safe cases, i.e., to
schema elements that have not yet been used. As we see, the view concept and
schema versioning in combination with schema mappings are main approaches
to support backward compatibility.
-
Mapping support
: To automatically propagate schema changes to instances and
dependent or related schemas, it is necessary to describe the evolution itself as
well as schema dependencies (such as view mappings) by high-level, declara-
tive schema mappings. In the simplest case, the
evolution mapping
between the
original schema S and the evolved schema S
0
consists of the set of incremental
changes specified by the schema developer. In case the changes are specified by
providing the evolved schema S
0
, the evolution mapping between S and S
0
still
needs to be determined. Ideally, this mapping is (semi-)automatically determined
by a so-called
Diff(erence) computation
that can be based on schema matching
(
Rahm and Bernstein 2001
;
Rahm 2011
) but also has to take into account the
(added/deleted) schema elements that exist in only one of the two schemas.
There are different possibilities to represent evolution mappings and other schema
mappings. A high flexibility and expressive power is achieved by using different
kinds of logical and algebraic mapping expressions that have been the focus of a
substantial amount of theoretical research (
Cate and Kolaitis 2010
). The mapping
representation should at least be expressive enough to enable the semi-automatic
generation of corresponding instance (data migration) mappings. Further mapping
desiderata include the ability to support high-level operations such as composition
and inversion of mappings (
Bernstein 2003
) that support the evolution
(adaptation)
of mappings
after schema changes. In the example of Fig.
6.1
, such operations can
