Databases Reference
In-Depth Information
that different local DBs may be managed by different types of DBMSs for
example, different products or different versions of one product. Thus, the
local conceptual schemas may be defined in different data models (e.g., net-
work, hierarchical, relational, object-oriented), the DDL/DML supported by
local DBs may be different (e.g., network or hierarchical, different versions
of SQL, OQL), the query processors may use different algorithms and cost
models, the transaction managers may support different concurrency control
and recovery mechanisms, and so forth. Semantic heterogeneity means that
different local DBs may model the same information using different schema
constructs or may use the same schema construct to model different infor-
mation. For example, peoples names may be stored using different string
lengths, or a relation named student in one DB may contain only under-
graduate students while a relation named student in another DB contains
both undergraduate and postgraduate students. If there is semantic hetero-
geneity in a multi-DBMS, it is necessary to perform semantic integration of
the export schemas. That requires the export schemas to be transformed so
as to eliminate any inconsistencies between them. Section 9.3 examines this
topic further in the discussion of DDB design.
We finally note that, in reference to multi-DBMSs, the terms unfeder-
ated and homogeneous are usually treated as almost synonymous, as are the
terms federated and heterogeneous.
Of the various architectures in Figure 9.1, a heterogeneous multi-
DBMS is the most challenging to implement. Thus, this section first con-
siders a five-level model for a heterogeneous multi-DBMS architecture. We
then simplify that model to a four-level model for homogeneous multi-
DBMS and finally to a three-level model for single-DBMS. Section 9.2.4
continues with a discussion of physical DB connectivity, that is, mechanisms
by which information can be exchanged by DBMSs in DDB systems.
Ideally, the manner in which data are physically stored in a DDB sys-
tem should not alter the way that global queries and transactions are written.
For example, it should be possible to change the location of a particular data
item, perhaps to improve the performance of the DDB, without having to
alter any application code that requires access to that data item. This prop-
erty of DDBs, known as distributed data independence, is discussed further
in Section 9.2.5.
We conclude the section on architectures with, in Section 9.2.6, a brief
comparison of DDBs with two other decentralized DB architectures, client/
server DBs and parallel DBs.
