What is a CDM database

12 Federal database systems

12.1 Schema architecture

The schema architecture of a centralized DBS according to ANSI / SPARC (Section 2.1.2) and the schema architecture of distributed DBS (Section 4.2) do not support a sufficiently high level of autonomy and heterogeneity of the LDBS, as required for federative DBS. A more suitable schema architecture, which can be used for different types of FDBS, is shown in Fig. 12-2. As with centralized and distributed DBS, there is an internal and a conceptual schema (LIS or LKS) at each node. Likewise, users generally access to the databases via external schemes. Three types of schema have been added: component, export and federative schemas.

Component schemes are required if the LDBS use different data models; they are therefore used to deal with heterogeneity (in the data models). The component schemes are based on a common data model (Common Data Model, CDM). Each local conceptual schema of another data model is represented by a Schema translation transformed into an equivalent conceptual schema of the CDM (the component schema). In practice, the relational data model is to be seen as a suitable candidate for the CDM, since a large part of the databases is already relationally structured (and the schema translation is thus not necessary) and also for non-relational databases (hierarchical and network-like databases) mostly a transformation into the relation model is possible [HK89]. Semantic data models (e.g. entity relationship models) or object-oriented models are often seen as a sensible alternative, as they support a high level of modeling power, which can be used in the transformation process (as well as for schema integration) [SL90]. From a practical point of view, however, there is the problem that a large number of such models exist and none of these models has achieved significant market significance. In addition, there are usually deficits with regard to the support of powerful set-oriented DB operations.

Export Schemes are defined at each node on the component schema of the local database. They determine which objects in the local database are to be made accessible to external users within the framework of a federation (one export schema per federation). Furthermore, the permissible operations can be restricted by appropriate access restrictions. The export schemes thus serve to support the LDBS autonomy, in particular the cooperation autonomy.

A federal scheme includes the schema specifications of several export schemas from the LDBS participating in the federation. The federative schema also contains information on data distribution in order to be able to map operations on the federative schema to the individual LDBS (this information could also be kept in a separate distribution schema, analogous to distributed DBS). In general, different federations can be formed to meet the needs of different user groups. With external schemes a further restriction of the visible data and the permissible operations for individual users can be achieved. Users who only access a local database continue to do so via external schemes (not shown in Fig. 12-2), which are mapped directly to the relevant LKS.

The role of the federal schemes (as well as the external schemes) depends on whether a closely or loosely coupled FDBS is to be implemented. In the case of a close coupling, an attempt is made to undo the distinction between several databases by means of a schema integration. In this case, the federal scheme is like a global conceptual scheme, with which an extensive distribution transparency - similar to distributed DBS - is to be achieved. The schema integration is transparent to the user and is carried out by global database administrators (GDBA) performed. The global schema not only consists of the unification of the individual export schemas, but above all a treatment of the semantic heterogeneity is carried out.
In the case of the loosely coupled FDBS, there is no schema integration, but the distinction between several databases remains visible to the user. Each user creates a federative schema from the required export schema, which is now also available as a Import scheme referred to as. This is typically done through operations of a special multi-DB query language, with which relationships between objects of different export schemes can also be defined (see below). Additional external schemes are generally required with loose coupling. not necessary, as the import scheme can already be tailored to the specific needs of a user.

In the following we first discuss which types of semantic heterogeneity can exist in FDBS. Then we outline the process of the schema integration in tightly coupled FDBS as well as the use of a multi-DB query language in loosely coupled FDBS. Finally, we will go into the transaction management in FDBS.