Schemas Integration - Information Systems Reengineering, Integration and Normalization - page 278

Begin
For each existing database do
Begin
If its conceptual schema does not exist
then reconstruct its conceptual schema by reverse engineering;
For each pair of existing database schema A and schema B do

begin

resolve semantic conflicts between schema A and schema B;
/*step1*/
Merge classes/entities and relationship relations between schema
A and B;
/*step2a*/
Capture and resolve the semantic constraints arising from
integration using Frame Model metadata
/*step2b*/
end
end

end

The input schemas must analyze in pairs and resolve semantic conflicts in different
areas. Conflicts are resolved using well-defined semantic rules with user supervi-
sions. Classes are merged by union or abstractions like subtype, generalization, ag-
gregation, and others. To demonstrate this step, UML diagrams are used to represent
the conceptual schema of relational and OO, respectively. The constraints arising
from the integration are then captured and enforced in the frame model metadata.
The details of each of the above steps are demonstrated as follows.
Step 1. Identify and resolve the semantics integrity conflicts among input sche-
mas.
Input: Schemas A and B with classes and attributes in conflicts to each other on
semantics.
Output: Integrated schema Y after data transformation.
In dealing with definition-related conflicts like inconsistency in keys or syn-
onyms/homonyms in names, user supervision is essential. For instance, two entities
may have some candidate keys overlapping with each other but using different keys
as the primary key. The user has to clarify in this kind of situation.
On the other hand, for conflicts arising from structural differences, the goal is to
capture as much information from the input schemas as possible. The most conser-
vative approach is to capture the superset from the schemas. For example, in deal-
ing with cardinality, the cardinality of the same relationship relation in schema A is
1:1 while the other one in schema B is 1:n. Since a 1:n relationship is the superset
of a 1:1 relationship, the 1:n cardinality is used for the integrated relation. Another
example is the participation constraint. If the same relationship relation in differ-
ent schemas have different levels of participation constraints, partial participation