## 3 The Mediator-Wrapper Architecture
### On Schema Hierarchies in the Mediator-Wrapper Architecture  
One of the advantages of using a MW architecture is the ability to modularly translate schemas by using the architecture's components themselves. To better understand these specifics, a generic example of a schema-type hierarchy is displayed in Figure 3, which shows all the possible schema types and their possible relationships. This is, in multiple forms, explained by [28].  
Figure 3: A schema hierarchy [28].  
Starting bottom-up in Figure 3, the first type of schema is a local internal schema (LIS). The LIS is the schema found in the connected data source itself, defined in the data source's native form. For the data source integration system to be able to work on the connected data source, it must translate the LIS to a more generic and adaptable form that is used system wide--this is the local conceptual schema (LCS). The LCS can then be translated into a local exported schema (LES). The LES is, for all intents and purposes, a partial or transformed schematic view of the LCS. As the data source integration system does not use the LES for its internal functioning, the LES can be described in an entirely different form and presented to the user. The global conceptual schema (GCS) is created by integrating the local conceptual schemas. In turn, the GCS can also be exported to the user in multiple forms, just like the LES. Such an exported schema is called a global exported schema (GES).  
In a multidatabase integration system, these schemas are all found in the same integration component in the form of metadata and are generated by modules. On the other hand, in a MW architecture data source integration system, these schemas are worked on gradually. This is done through the system's wrapper and mediator layers, each layer creating a more encompassing global schema or creating new forms of exported schemas.  
As an example, a certain system-wide schema hierarchy is presented in Figure 4 with the schemas' relationships in accordance with the former explanation. The schema relationships (mergers or extractions) are presented by connecting lines, while the arrows on top of the schemas demonstrate which of them can be accessed by a user.  
To set a concrete example, this paper displays how schemas should be assigned to MW components. Setting this example for the continuation of this paper, the schemas from the exemplified hierarchy (Figure 4) can now be assigned to MW architecture components. In Figures 5 and 6, the components are displayed with their assigned schemas (illustrated by a white rectangle) adjacent to them.  
The first possible assignment of schemas is to a system with a single mediator layer, as displayed in Figure 5. The LISs are positioned in the connected data sources. The wrappers then form their individual LCSs based on their connected data source's LIS. The wrappers' LCSs are then used by the mediators to create their GCSs. In this example, an aforementioned case of a mediator connected to a single wrapper is also displayed. This mediator generates a LES, and thus this mediator is only used for translation. The other mediators, along with their GCSs, generate GESs. A mediator can be used to create GESs  
Figure 4: An example of a system-wide schema hierarchy.  
to remove the need for another architectural layer of the mediators above. Of course, this might decrease system latency, but will increase the complexity of mediator components, as they now must manage multiple user role access.  
Another example of a schemas' assignment is displayed in Figure 6. In this example, there is another mediator layer on top of the architectural hierarchy. These mediators are used exclusively for exporting schemas, similar to the translating mediator. In this alternative, each mediator exports just one form of GES, thus reducing their task base and reducing the required complexity for multiple user role management. In other words, each mediator could have just one form of a data-accessing user.