Mapping-Based Merging of Schemas - Schema Matching and Mapping - page 237

8.5 Binary Merge vs. N-ary Merge

Many different situations, such as view integration, solve the problem of merging
more than two models at the same time. However, in almost every case this is broken
down into a series of two way merges. Break down of an n-ary merge follows either
a ladder strategy, wherein a new component schema is integrated with an existing
intermediate result at each step, or a balanced binary strategy wherein the models
are divided into pairs at the start and are integrated in a symmetric pattern [ Batini
et al. 1986 ]. Thus even in situations where n-ary merge would be appropriate, the
problem can be, and often is, broken down into a number of binary merges.

8.6 Can Merge be Fully Automatic?

One natural question is whether merge can be fully automatic. Based on these sys-
tems, it would appear that it cannot. Even with the limited problems that the above
systems address, most of them require user intervention or error handling even
though most do not consider either constraints or ordering.
However, with enough parameters set to allow the system to resolve any conflicts
that arise, it is possible to have a largely if not entirely automatic version of merge.
In addition to setting parameters to allow for the merge to be tailored to the above
semantic differences, some of the parameters that should be considered are:

Is there a preferred model and if so which one?

If there are two matched objects and one has a more restrictive type than the
other (e.g., an integer vs. a double), which would the user prefer? Both have
their utilities; if there is an application built on top of the databases, it may be an
advantage to require the more restrictive type. However, the less restrictive type
allows more expressiveness.

A fully automatic system would not allow the different semantics and user desires
to be fully taken into account. A system that required too many knobs would be
annoying and frustrating for the user. Thus, any merge system must strike a balance.
The most solution is to allow the setting of a number of parameters but to provide
default settings to make the common case perform correctly.

8.7 User Interaction Requirements

Both the Chimæra ontology merger [ McGuinness et al. 2000 ] and Munson and
Dewan's work in CSCW [ Munson and Dewan 1994 ] describe interactions that the
user should be able to have with the tool when performing a merge. Combined, they
list a great number of the goals that any merge operator for Model Management