|
Guided Tour: Conceptual Modelling of Integration Systems
Let us consider as an example the conceptual design of a data
warehouse in telecommunication business. In this warehouse, we want
to integrate data from a source that contains information concerning
specific telephone calls. Let us suppose that the source database
contains a table relating the phone calls done by the customers of the
company with the locations of the calls themselves. The schema is
ambiguous in the sense that it is not clear whether the location
associated to each call indicates the source or the destination of the
call. In the attempt to reuse this data in a centralised system, the
source schema is related to the global integrated schema introduced in
the previous part of the tutorial, where the origin and the destination
of the calls are differentiated.
We thus start with two distinct ER schemas to be integrated, the
Source and the (global) EnterpriseDemo schemas:
From the figure above, we can see how the schema integration has
been performed using ICOM. The Service
entity of the source schema is asserted to generalise the
Call entity in the global schema and the Location
entity of the source schema generalises the PhonePoint entity
in the global schema. The lack of information about the real meaning
of the ServiceLocation relationship in the source schema is
captured by the designer with the assertion that such a relation
generalises both the destination and the origin
relationships in the global schema. A closer took at the source
database, during a reverse engineering phase, reveals to the designer
an additional inter-schema constraint stating that the second argument
of ServiceLocation includes all and only Cell phone
points. Thus, the view CellServLoc is defined as a
ServiceLocation relationship restricted to consider
Cell phone points only.
Given this state of affairs, ICOM immediately informs us of the
unpleasant consequences of our modelling:
At this point, the following fact is logically implied by the
integrated schema: for every call, any origin cell point is also a
destination point and vice-versa. This fact is clearly a symptom that
something went wrong. Indeed, the designer can not accept this
conclusion. In this example, the reason for this can be found in the
wrong assumption that the original relationship was modelling both
sources and destinations. If we omit in the integrated schema that
the destination relationship specialises the ServiceLocation
relationship, then the above deduction does not hold anymore, and the
integrated schema is acceptable:
|