The Three-Level ANSI-SPARC Architecture
An early proposal for a standard terminology and general architecture for database systems
was produced in 1971 by the DBTG (Data Base Task Group) appointed by the
Conference on Data Systems and Languages (CODASYL, 1971). The DBTG recognized
the need for a two-level approach with a system view called the schema and user
views called subschemas. The American National Standards Institute (ANSI) Standards
Planning and Requirements Committee (SPARC), ANSI/X3/SPARC, produced a similar
terminology and architecture in 1975 (ANSI, 1975). ANSI-SPARC recognized the need
for a three-level approach with a system catalog. These proposals reflected those published
by the IBM user organizations Guide and Share some years previously, and concentrated
on the need for an implementation-independent layer to isolate programs from underlying
representational issues (Guide/Share, 1970). Although the ANSI-SPARC model did not
become a standard, it still provides a basis for understanding some of the functionality of
a DBMS.
For our purposes, the fundamental point of these and later reports is the identification
of three levels of abstraction, that is, three distinct levels at which data items can be
described. The levels form a three-level architecture comprising an external, a conceptual,
and an internal level, as depicted in Figure 2.1. The way users perceive the data is
called the external level. The way the DBMS and the operating system perceive the data
is the internal level, where the data is actually stored using the data structures and file
organizations described in Appendix C. The conceptual level provides both the mapping
and the desired independence between the external and internal levels.
The objective of the three-level architecture is to separate each user’s view of the
database from the way the database is physically represented. There are several reasons
why this separation is desirable:
n Each user should be able to access the same data, but have a different customized view
of the data. Each user should be able to change the way he or she views the data, and
this change should not affect other users.
n Users should not have to deal directly with physical database storage details, such as
indexing or hashing (see Appendix C). In other words, a user’s interaction with the
database should be independent of storage considerations.
n The Database Administrator (DBA) should be able to change the database storage structures
without affecting the users’ views.
n The internal structure of the database should be unaffected by changes to the physical
aspects of storage, such as the changeover to a new storage device.
n The DBA should be able to change the conceptual structure of the database without
affecting all users.
An early proposal for a standard terminology and general architecture for database systems
was produced in 1971 by the DBTG (Data Base Task Group) appointed by the
Conference on Data Systems and Languages (CODASYL, 1971). The DBTG recognized
the need for a two-level approach with a system view called the schema and user
views called subschemas. The American National Standards Institute (ANSI) Standards
Planning and Requirements Committee (SPARC), ANSI/X3/SPARC, produced a similar
terminology and architecture in 1975 (ANSI, 1975). ANSI-SPARC recognized the need
for a three-level approach with a system catalog. These proposals reflected those published
by the IBM user organizations Guide and Share some years previously, and concentrated
on the need for an implementation-independent layer to isolate programs from underlying
representational issues (Guide/Share, 1970). Although the ANSI-SPARC model did not
become a standard, it still provides a basis for understanding some of the functionality of
a DBMS.
For our purposes, the fundamental point of these and later reports is the identification
of three levels of abstraction, that is, three distinct levels at which data items can be
described. The levels form a three-level architecture comprising an external, a conceptual,
and an internal level, as depicted in Figure 2.1. The way users perceive the data is
called the external level. The way the DBMS and the operating system perceive the data
is the internal level, where the data is actually stored using the data structures and file
organizations described in Appendix C. The conceptual level provides both the mapping
and the desired independence between the external and internal levels.
The objective of the three-level architecture is to separate each user’s view of the
database from the way the database is physically represented. There are several reasons
why this separation is desirable:
n Each user should be able to access the same data, but have a different customized view
of the data. Each user should be able to change the way he or she views the data, and
this change should not affect other users.
n Users should not have to deal directly with physical database storage details, such as
indexing or hashing (see Appendix C). In other words, a user’s interaction with the
database should be independent of storage considerations.
n The Database Administrator (DBA) should be able to change the database storage structures
without affecting the users’ views.
n The internal structure of the database should be unaffected by changes to the physical
aspects of storage, such as the changeover to a new storage device.
n The DBA should be able to change the conceptual structure of the database without
affecting all users.
No comments: