The Three-Level ANSI-SPARC

Architecture

BY MR. D SINYANGWE

Zambia ICT College

• The American National Standards Institute
(ANSI) Standards Planning and Requirements
Committee (SPARC).
• 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.
• Although the ANSI-SPARC model did not
become a standard, it still provides a basis for
understanding some of the functionality of a
DBMS.
• There are 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
 objectives of the three-level
architecture
There are several reasons why this separation is desirable:
 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.
 Users should not have to deal directly with physical
database storage details, such as indexing or hashing. In
other words, a user’s interaction with the database
should be independent of storage considerations.
 The Database Administrator (DBA) should be
able to change the database storage structures
without affecting the users’ views.
 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.
 The DBA should be able to change the
conceptual structure of the database without
affecting all users.
 External Level
• The users’ view of the database. This level
describes that part of the database that is
relevant to each user.
• The external level consists of a number of
different external views of the database. Each
user has a view of the ‘real world’ represented
in a form that is familiar for that user. The
external view includes only those entities,
attributes, and relationships in the ‘real world’
that the user is interested in.
 What is a view
• A view is a virtual relation that does not
necessarily exist in the database but can be
produced upon request by a particular user, at
the time of request. The contents of a view
are defined as a query on one or more base
relations. Views are dynamic, meaning that
changes made to the base relations that affect
the view are immediately reflected in the
view.
 Purpose of Views
• It provides a powerful and flexible security mechanism
by hiding parts of the database from certain users.
Users are not aware of the existence of any attributes
or tuples that are missing from the view.
• It permits users to access data in a way that is
customized to their needs, so that the same data can
be seen by different users in different ways, at the
same time.
• It can simplify complex operations on the base
relations. For example, if a view is defined as a
combination (join) of two relations users may now
perform more simple operations on the view, which
will be translated by the DBMS into equivalent
operations on the join.
 Conceptual Level

• The community view of the database. This

level describes what data is stored in the
database and the relationships among the data.
• This level contains the logical structure of the
entire database as seen by the DBA. It is a
complete view of the data requirements of the
organization that is independent of any storage
considerations. The conceptual level
represents:
  all entities, their attributes, and their relationships;
 the constraints on the data;
 semantic information about the data;
 security and integrity information.
• The conceptual level supports each external view,
in that any data available to a user must be
contained in, or derivable from, the conceptual
level.
• However, this level must not contain any storage-
dependent details.
 Internal Level

• The physical representation of the database

on the computer. This level describes how the
data is stored in the database.
• The internal level covers the physical
implementation of the database to achieve
optimal runtime performance and storage
space utilization. It covers the data structures
and file organizations used to store data on
storage devices.
The internal level is concerned with such things
as:
• storage space allocation for data and indexes;
• record descriptions for storage (with stored sizes
for data items);
• record placement;
• data compression and data encryption techniques.
• Below the internal level there is a physical
level that may be managed by the operating
system under the direction of the DBMS.
However, the functions of the DBMS and the
operating system at the physical level are not
clear-cut and vary from system to system.
Some DBMSs take advantage of many of the
operating system access methods, while
others use only the most basic ones and
create their own file organizations.
Schemas, Mappings, and Instances
• The overall description of the database is called the
database schema.
• There are three different types of schema in the database
and these are defined according to the levels of abstraction
of the three-level architecture. At the highest level, we have
multiple external schemas (also called subschemas) that
correspond to different views of the data.
• At the conceptual level, we have the conceptual schema,
which describes all the entities, attributes, and relationships
together with integrity constraints.
• At the lowest level of abstraction we have the internal
schema, which is a complete description of the internal
model, containing the definitions of stored records, the
methods of representation, the data fields, and the indexes
and storage structures used. There is only one conceptual
schema and one internal schema per database.
• The conceptual schema is related to the internal
schema through a conceptual/internal mapping.
This enables the DBMS to find the actual record
or combination of records in physical storage that
constitute a logical record in the conceptual
schema, together with any constraints to be
enforced on the operations for that logical record.
It also allows any differences in entity names,
attribute names, attribute order, data types, and so
on, to be resolved.
• Each external schema is related to the
conceptual schema by the external/conceptual
mapping. This enables the DBMS to map names
in the user’s view on to the relevant part of the
conceptual schema.
• There are two kinds of data independence:
logical and physical.
• Logical data independence refers to the
immunity of the external schemas to changes
in the conceptual schema.
• Physical data independence refers to the
immunity of the conceptual schema to
changes in the internal schema.
 Conceptual Modeling
• Conceptual modeling, or conceptual database
design, is the process of constructing a model
of the information use in an enterprise that is
independent of implementation details, such as
the target DBMS, application programs,
programming languages, or any other physical
considerations. The conceptual schema is the
‘heart’ of the database. It supports all the
external views and is, in turn, supported by the
internal schema.
• The conceptual schema should be a complete
and accurate representation of the data
requirements of the enterprise. If this is not
the case, some information about the
enterprise will be missing or incorrectly
represented and we will have difficulty fully
implementing one or more of the external
views.
• The conceptual model is independent of all
implementation details, whereas the logical
model assumes knowledge of the underlying
data model of the target DBMS.
Branch (branchNo, street, city,
postcode)
Staff (staffNo, fName, lName, position,
sex, DOB, salary, branchNo)
PropertyForRent (propertyNo, street, city,
postcode, type, rooms, rent, ownerNo,
staffNo, branchNo)
• The common convention for representing a
relation schema is to give the name of the
relation followed by the attribute names in
parentheses. Normally, the primary key is
underlined. The conceptual model, or conceptual
schema, is the set of all such schemas for the
database.