ICOM
A Tool for Intelligent Conceptual Modelling


   

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:

ICOM screenshot

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:

ICOM screenshot

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:

ICOM screenshot


   
Enrico Franconi - ()