Architecture: The architecture of a system defines its structure:
– the components of the system are identified;
– the function of each component is specified;
– the interrelationships and interactions among the components are defined.


Motivation for standardization of DDBMS architecture:

a. Homogeneous DDBMS

b. Heterogeneous DDBMS


Reference Model: A conceptual framework whose purpose is to divide standardization
work into manageable pieces and to show at a general level how these pieces are
related to each other.

A reference model can be described according to 3 different approaches:
– component-based
– function-based
– data-based

• Components-based
– Components of the system are defined together with the interrelationships between
the components. Example: Computer Corporation of America (CCA 1980, 1982) prepared proposals

  • Function-based
    – Classes of users are identified together with the functionality that the system will
    provide for each class
    – Typically a hierarchical system with clearly defined interfaces between different layers
    – The objectives of the system are clearly identified.
    – Not clear how to achieve the objectives
    – Example: ISO/OSI architecture of computer networks
  • Data-based
    – Identify the different types of the data and specify the functional units that will realize
    and/or use data according to these views
    – Gives central importance to data (which is also the central resource of any DBMS)
    → Claimed to be the preferable choice for standardization of DBMS
    – The full architecture of the system is not clear without the description of functional
    – Example: ANSI/SPARC architecture of DBMS

ANSI/SPARC architecture is based on data
• 3 views of data: external view, conceptual view, internal view
• Defines a total of 43 interfaces between these views


Conceptual schema: Provides enterprise view of entire database

Internal schema: Describes the storage details of the relations.
– Relation EMP is stored on an indexed file
– Index is defined on the key attribute ENO and is called EMINX
– A HEADER field is used that might contain flags (delete, update, etc.)

External view: Specifies the view of different users/applications



Architectural Models for DDBMSs (or more generally for multiple DBMSs) can be
classified along three dimensions:
– Autonomy
– Distribution
– Heterogeneity

Autonomy: Refers to the distribution of control (not of data) and indicates the degree to
which individual DBMSs can operate independently.
– Tight integration: a single-image of the entire database is available to any user who
wants to share the information (which may reside in multiple DBs); realized such that
one data manager is in control of the processing of each user request.
– Semiautonomous systems: individual DBMSs can operate independently, but have
decided to participate in a federation to make some of their local data sharable.
– Total isolation: the individual systems are stand-alone DBMSs, which know neither of
the existence of other DBMSs nor how to comunicate with them; there is no global
• Autonomy has different dimensions
– Design autonomy : each individual DBMS is free to use the data models and
transaction management techniques that it prefers.
– Communication autonomy : each individual DBMS is free to decide what information
to provide to the other DBMSs
– Execution autonomy : each individual DBMS can execture the transactions that are
submitted to it in any way that it wants to.


Distribution: Refers to the physical distribution of data over multiple sites.
– No distribution: No distribution of data at all
– Client/Server distribution:
∗ Data are concentrated on the server, while clients provide application
environment/user interface
∗ First attempt to distribution
– Peer-to-peer distribution (also called full distribution):
∗ No distinction between client and server machine
∗ Each machine has full DBMS functionality

Heterogeneity: Refers to heterogeneity of the components at various levels
– hardware
– communications
– operating system
– DB components (e.g., data model, query language, transaction management