DATABASE

ENVIRONMENT
CHAPTER 2

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 American National Standards
Institute (ANSI) Standards Planning
and Requirements Committee
(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.

 The objective of the three-level architecture is to separate each users

view of the database from the way the database is physically
represented. 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 (see Appendix C). In other words, a users
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.
In addition, different views may have different
representations of the same data.

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.

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.

Schemas, Mappings, and

Instances

Data Independence
A major objective for the three-level architecture is to provide data
independence, which means that upper levels are unaffected by
changes to lower levels. There are two kinds of data independence:
logical and physical.

 Logical data independence: Logical data independence refers to

the immunity of the external schemas to changes in the conceptual
schema.
Changes to the conceptual schema, such as the addition or removal of new
entities, attributes, or relationships, should be possible without having to
change existing external schemas or having to rewrite application programs.

Physical data independence: Physical data independence refers to

the immunity of the conceptual schema to changes in the internal
schema.
Changes to the internal schema, such as using different file organizations or
storage structures, using different storage devices, modifying indexes, or
hashing algorithms, should be possible without having to change the
conceptual or external schemas.

DATABASE LANGUAGES
A data sublanguage consists of two parts: a Data
Definition Language (DDL) and a Data
Manipulation Language (DML).
The DDL is used to specify the database schema and
the DML is used to both read and update the database.

The Data Definition Language

(DDL)
DDL: A language that allows the DBA or user to
describe and name the entities, attributes, and
relationships required for the application, together with
any associated integrity and security constraints.
The DDL is used to define a schema or to modify an
existing one. It cannot be used to manipulate data.
The result of the compilation of the DDL statements is a
set of tables stored in special files collectively called the
system catalog.

The Data Manipulation

Language (DML)
DML: A language that provides a set of operations to support the basic
data manipulation operations on the data held in the database.
Data manipulation operations usually include the following:

insertion of new data into the database;

modification of data stored in the database;
retrieval of data contained in the database;
deletion of data from the database.

The part of a DML that involves data retrieval is called a query language.
DML: procedural and non-procedural. The prime difference between
these two data manipulation languages is that procedural languages
specify how the output of a DML statement is to be obtained, while nonprocedural DMLs describe only what output is to be obtained.

Procedural DMLs & Non-procedural

DMLs
Procedural DML: A language that allows the user to tell the
system what data is needed and exactly how to retrieve the
data.
Typically, such a procedural DML retrieves a record, processes it and,
based on the results obtained by this processing, retrieves another
record that would be processes similarly, and so on.

Non-procedural DML: A language that allows the user to

state what data is needed rather than how it is to be retrieved.
Relational DBMSs usually include some form of non-procedural
language for data manipulation, typically SQL (Structured Query
Language) or QBE (Query-By- Example). Non-procedural DMLs are
normally easier to learn and use than procedural DMLs

DATA MODELS AND

CONCEPTUAL MODELING
Data model: An integrated collection of concepts for describing
and manipulating data, relationships between data, and
constraints on the data in an organization.
A data model can be thought of as comprising three components:
a structural part, consisting of a set of rules according to which
databases can be constructed;
a manipulative part, defining the types of operation that are allowed
on the data (this includes the operations that are used for updating or
retrieving data from the database and for changing the structure of the
database);
possibly a set of integrity constraints, which ensures that the data is
accurate.

Object-Based Data Models

Object-based data models use concepts such as
entities, attributes, and relationships. An entity is a
distinct object (a person, place, thing, concept, event) in
the organization that is to be represented in the
database. An attribute is a property that describes
some aspect of the object that we wish to record, and a
relationship is an association between entities.

Record-Based Data Models

In a record-based model, the database consists of a
number of fixed-format records possibly of differing
types. Each record type defines a fixed number of fields,
each typically of a fixed length.
There are three principal types of record-based logical
data model: the relational data model, the network
data model, and the hierarchical data model.

Relational data model

The relational data
model is based on the
concept of
mathematical
relations. In the
relational model, data
and relationships are
represented as tables,
each of which has a
number of columns
with a unique name.

Network data model

In the network model, data is represented as collections
of records, and relationships are represented by sets.

Hierarchical data model

The hierarchical model is a restricted type of network model. Again, data
is represented as collections of records and relationships are represented
by sets. However, the hierarchical model allows a node to have only one
parent.

FUNCTIONS OF A DBMS