4.2 Querying derived types
4.2.2 Proxy types and objects
When a type from another data source is used for the rst time as a supertype of a local DT, then it is either imported implicitly by the system (when an AMOSII data source is used), or explicitly by the IMPORT TYPE clause.
Locally, for each imported type (distinguished by the type and data source name) a proxy type is created. All proxy types are subtypes of the type Proxy. For example, there is a proxy type, P Person, de ned for the type Personfrom the sport database. Figure 4.3 shows the proxy type hierarchy for the de nition of the DT Sporty Emp type in Figure 4.1. The proxy type hierarchy is rst divided into di erent kinds of data sources. In the Figure, two kinds are shown: AMOSII data sources and ODBC data sources. This classi cation is not to be confused with the data source capability hierarchy described in chapter 6. Each data source is represented by a type placed under the type corresponding to the data source kind. There can be more than one data source of the same kind. Types imported from a data sources are placed in the type hierarchy under the type representing the source.
Non-46 Data Integration by Derived Types
OO data sources have at proxy hierarchies (each proxy type is a child of the type representing the data source kind). The proxy types of OO data sources that can provide the required meta-data information are organized in a type hierarchy that is a subset of the type hierarchy in the exporting mediator, and contain all the types imported from the source to date. Locally de ned DTs that are subtypes of types in other data sources are placed as subtypes of the corresponding proxy types.
AMOSII
locally or in sport_db other derived types which
SPORT_BONUS Sporty_Emp
other proxy types from sport_db
Sport_DB other types of sources
P_Person
EMPLOYEE_DB
Proxy
ODBC
other AMOSII sources
. . . . . .
. . .
. . . . . .
. . . . . .
. . .
inherit from person@sport_db
Figure 4.3: Placing the proxy types in the type hierarchy
4.2 Querying derived types 47
After de ning a proxy type, the system retrieves the signatures of the functions de ned over the type in the exporting AMOSII server. If the argu-ment and the result types of a remote function are known to the importing mediator (i.e. if they are system-de ned types or previously imported user-de ned types) a local corresponding proxy function is user-de ned. The proxy function has the same signature as the remote function, but an empty body. Although the proxy functions and the proxy type extent functions are treated as ordinary functions throughout the calculus oriented query processing steps, they are not executed as ordinary functions. The decom-position algorithm groups them, and schedules them for execution in other AMOSII servers. In the calculus-based query processing phases, they provide information for type checking and query transformation as described below.
For each proxy type, a system-de ned stored function is generated that maps instances of the proxy type into instances of type foreign oid. This system type is used to represent the stringi ed OIDs received from other AMOSII servers when parts of query plans are evaluated there. The OIDs are transmitted among the mediators and stored in their native format with-out origin or typing information added. The OIDs generated by an AMOSII server are unique only within that server. The system makes no e ort to generate \universal OIDs" unique in all AMOSII servers, like, for example, in the CORBA architecture [58]. In a CORBA environment, OIDs represent services and are designed to be transmitted alone. Therefore, every OID contains all the information needed to identify its origin. In a bulk data pro-cessing environment such as ours, the OIDs are passed in large collections having few di erent types and a common origin. Consequently, it is advan-tageous to condense the meta-information about the structure (types) and the origin of the transmitted OIDs with the transmission protocol. When an AMOSII server receives OIDs from another server, it stores them in their native format, while the meta-information is captured in the server's schema and the functions generated from the DT de nitions. As a result of this kind of architecture, imported OIDs are stored in the mediator server, but they cannot be interpreted there. The user does not have direct access to the imported OIDs, but only to their proxy type instances. The system uses the imported OIDs only in operations executed in the server where they originate from. The main bene ts from this approach are a simpler OID generation method, lower communication cost, and lower storage overhead due to smaller OIDs.
The name service in AMOSII provides means for a mediator to locate
48 Data Integration by Derived Types
other AMOSII servers that contain the types to be imported. AMOSII also provides an interface for providing information about the types to be im-ported by other mediators. This however, is not possible when types are imported from other types of data sources2. For this purpose, AMOSQL is expanded with constructs for data source declaration and explicit type importation:
IMPORT TYPE type_name@data_source [KEYS (key_list)]
[FUNCTIONS (function_list)];
The KEYS clause de nes a set of functions to be imported and used in the generation of OIDs for the instances of the proxy types representing data coming from non-OO sources. The FUNCTIONS clause can be used to import additional functions. The IMPORT TYPE clause can also be used to import types from AMOSII servers, when the user prefers to explicitly name the functions to be imported. If we assume that Sport DB is an
ODBC
data source, then the data source declaration and the importation of the typePerson
would be speci ed as following:DECLARE odbc DATA SOURCE Sport_DB;
IMPORT TYPE Person@Sport_DB KEYS (ssn integer)
FUNCTIONS (hobby string);
In a query retrieving instances of the type