Databases Reference
In-Depth Information
framework do not have the same expressive power as the full XML schema lan-
guage, and so the work focuses on the subset of XML Schema to which the UML
language maps cleanly. Changes to the UML diagrams within a tool then induce
changes to the underlying schema and instances in the form of deployable XSLT
documents.
The set of changes that the UML framework supports is thus heavily influ-
enced by the tooling support. For instance, the change that is described in depth
in
Domınguez et al.
(
2005
) is a refactoring operation that translates an attribute in a
UML class into its own class:
Employee:
- Name
- Address
Employee:
- Name
- Address
- Department
Attribute
to Class
*
1..1
Department:
- Department
In general, each class corresponds to a type in an XML schema with an element
and a key. Attributes correspond to nested elements, while associations map to key
references. The refactoring operation above therefore results in removing the nested
element from the Employee type, creating a new type and element with a key for
Department, and a key reference between the two types. An XSLT stylesheet is also
generated to migrate data to ensure Department data is not lost.
A similar and more recent approach is
CoDEX
(
Klettke 2007
), which uses a
conceptual model that is closely aligned with XML Schema rather than using UML.
Again, incremental changes made to the conceptual model result in changes to the
associated schema and valid documents. The work on CoDEX also describes an
algebra that does preprocessing on incremental changes. As the user edits the model,
a log of actions is recorded, which can subsequently be optimized using reduction
rules. For instance, adding a new element then renaming it is equivalent to simply
adding the element with the new name to begin with.
X-Evolution
(
Guerrini and Mesiti 2009
;
Mesiti et al. 2006
) is another framework
that defines incremental schema evolution in terms of a tool, in this case a graph rep-
resentation of the schema. Like CoDEX and the UML tools, X-Evolution supports a
set of evolution primitives; the list is too long to mention in-line, but covers change
classes except 7, 8, and 13 from our running list (and the algorithm in X-Evolution
could be altered in a fairly straightforward way to accommodate them). X-Evolution
is also able to handle a kind of change not listed in the change taxonomy at all -
specifically, changing a content particle's type, say, from ALL to SEQUENCE or
CHOICE. A subset of the list of incremental evolutions is classified as having no
effect on validation, such as the removal of a global type that has no current element
instances. With any such evolution, no document revalidation is necessary - this list
of validation-less changes tracks with the research done in
Moto et al.
(
2007
).
