1

CHAPTER II

DATABASE SYSTEM ARCHITECTURE

THE THREE LEVEL OF THE ARCHITECTURE

 The ANSI/SPARC architecture is divided into three levels, known as the internal,
conceptual, and external level.
 The internal Level (also known as the physical level) is the one closest to physical
storage-i.e, it is the one concerned with the way the data is physical stored;

External level
(individual views)

Conceptual level
(community user view)

Internal level
(Storage view)

FIG. 2.1 The three levels of the architecture.

 The external level (also known as the user logical level) is the one closest to the users-
i.e., it is the one concerned with the way the data is seen by individual users; and
 The conceptual LEVEL (also known as the community logical level, or sometimes just
the logical level, unqualified) is a level of indirection between the other two.
 2

AN EXAMPLE OF THE THREE LEVELS

External(PL/I) External(PL/I)
DCL 1. EMPP, 01 EMPC.
2. EMP# CHAR (6), 02 EMPNO PIC X(6).
3. SAL FIXED BIN (31); 02 DEPTNO PIC X(4).

Conceptual
EMPLOYEE
EMPLOYEE_NUMBER CHARACTER (6)
DEPARTMENT_NUMBER CHARCTER (4)
SALARY NUMERIC (5)
Internal
STORED_EMP BYTES = 20
PREFIX TYPE = BYTE (6) , OFFSET = 0
EMP# TYPE = BYTE (6) , OFFSET = 6 , INDEX = EMPX
DEPT# TYPE = BYTE (4) , OFFSET = 12
PAY TYPE = FULLWORD , OFFSET = 16

FIG. 2.2 An example of the three levels.

 At the conceptual level, the database contains information concerning an entity type
called EMPLOYEE.
 At the internal level, employees are represented by a stored record type called STORED-
EMP, twenty bytes long.
 The PL/I user has an external view of the database in which each employee is represented
by a PL/I record containing two fields. The record type is defined by an ordinary OPL/I
structure declaration I n accordance with the normal PL/I rules.
 Similarly, the COBOL user has an external view in which each employee is represented
by a COBOL record containing, again, two fields. The record type is defined by an
ordinary COBOL record description in accordance with the normal COBOL rules.
 Notice that corresponding data items can have different names at different points.
 For example, the employee number is called EMP# in the PL/I external view, EMPNO in
the COBOL external view, EMPLOYEE_ NUMBER in the conceptual view, and EMP#
again in the internal view.
 The system must be aware of the correspondences.
 3

 For example, it must be told that the COBOL field EMPNO is derived from the
conceptual field EMPLOYEE_ NUMBER, which in turn is derived from the
stored field EMP# at the internal level.

Detailed System Architecture

User A1 User A2 User B1 User B2 User B3

Host language Host language Host language Host language Host language
+DSL +DSL +DSL +DSL +DSL

*External External view A *External External view B

schema A schema B

External/conceptual External/conceptual
mapping A mapping B
Schemas and
Database
mapping built and management
maintained by the Conceptual Conceptual view system (DBMS)
schema
database
administrator
(DBA)
Conceptual/ Internal
mapping

Storage structure
definition Stored database (internal view)
(Internal schema)

*User Interface

FIG. 2.3 Detailed system architecture.

 4

THE EXTERNAL LEVEL

 The external level is the individual user level.
 Each user has a language at his or her disposal:
1) For the application programmer, that language will be either conventional
programming language(e.g., PL/I, C++, Java) or else a proprietary
language(fourth generation languages(4GLS).
2) For the end user, the language will be either a query language or some
special- purpose language, perhaps forms-or menu- driven, tailored to that
user’s requirements and supported by some online application program.
 An individual user will generally be interested only in some portion of the total
database.
 The ANSI/SPARC term for an individual user’s view is an external view.
 An external view is thus the content of the database as seen by some particular
user.
 In general, then an external view consists of many occurrences of each of many
types of external records.
 Each external view is defined by means of an external schema, which consists
basically of definitions of each of the various external record types in that external
view.
 The external schema is written using the DDL portion of the user’s data
sublanguage.
 For example , he employee external record type might be defined as a
six – character employee number field plus a five – digit (decimal)
salary field, and soon.
 In addition, there must be a definition of the mapping between the external
schema and the underlying conceptual schema.
 5

THE CONCEPTUAL LEVEL

 The external level is the individual user level.
 The conceptual view is intended to be a view of the data “as it really is”, rather
than as users are forced to see it by the limitations of (for example) the particular
language or hardware they might be using.
 The conceptual view consists of many occurrences of each of many types of
conceptual record.
 A conceptual record is not necessarily the same as either an external record on the
hand, or a stored record on the other.
 The conceptual view is defined by means of the conceptual schema, which
includes definitions of each of the various conceptual record types.
 The conceptual schema is written using another data definition language, the
conceptual DDL.
 The conceptual view, then, is a view of the total database content, and the
conceptual schema is a definition of that view.
 The definitions in the conceptual schema are intended to include a grate many
additional features, such as the security and integrity constraints.

THE INTERNAL LEVEL

 The internal view is a low-level representation of the entire database; it consists of
many occurrences of each of many types of internal record.
 Internal record is the ANSI/SPARC term for the construct that have been calling a
stored record.
 The internal view is described by means of the internal schema, which not only
defines the various stored record types but also specifies what indexes exist, how
stored records are in and so on.
 The internal schema is written using yet another ata definition language the
internal DDL.
 6

MAPPINGS
 The detailed system architecture involves certain mappings – one conceptual/
internal mapping and several external/ conceptual mappings.
 The conceptual/ internal mapping defines the correspondence between the
conceptual view and the stored database. If the structure of the stored database is
changed, then the conceptual/internal mapping must be changed according by, so
that the conceptual schema can remain invariant.
 An external / conceptual mapping defines the correspondence between a
particular external view and conceptual view. Any number of external views can
exist at the same tim; any number of users can share a given external view;
different external views can overlap.
 The conceptual/internal mapping is the key to physical data independence.
 The external/conceptual mappings are the key to logical data independence.

THE DATABASE ADMINSTRATOR

 The data administrator(DA) is the person who makes the strategic and policy
decisions regarding the data of the enterprise;
 The database administrator(DBA) is the person who provides the necessary
technical support for implementing those decisions. Thus, the DBA is responsible
for the overall control of the system at a technical level.
 Some of the tasks for the DBA are:
 Defining the conceptual schema
 Defining the internal schema
 Liaising with users
 Defining security and integrity constrains
 Defining dump and reload policies
 Monitoring performance and responding to changing requirements.
 7

THE DATABASE MANAGEMENT SYSTEM

 The database management system (DBMS) is the software that handles all access
to the database.
 Conceptually what happens is the following:
1. A user issues an access request, using some particular data
sublanguage(typically SQL).
2. The DBMS intercepts that request and analyzes it.
3. The DBMS inspects, in turn(the object versions of) the external
schema for that user, the corresponding external/ conceptual mapping,
the conceptual schema , the conceptual/internal mapping, and the
storage structure definition.
4. DBMS executes the necessary operations on the stored database.

FUNCTIONS OF THE DBMS

 Data definition
 Data manipulation
 In general, DML requests can be “planned” or “unplanned”.
 Optimization and execution
 Data security and integrity
 Data recovery and concurrency
 Data dictionary
 Performance
 8

Source schemas Planned DML Unplanned (ad

and mapping requests hoc) DML
request

Query
DDL DML Language
Processors Processors Processors

Compiled
requests

enforce security
Source and object and integrity
schemas and constraints
Optimizer
mapping

Optimized
requests

Run Time metadata

Manager

database

data

Metadata (data dictionary)

FIG.2.4 Major Functions and Components.

Contrasting database management systems with file management systems.
 File managers are not aware of the internal structure to stored records and hence cannot
handle requests that rely on a knowledge of that structure.
 They typically provide little or no support for security and integrity constraints.
 They typically provide little or no support for recovery and concurrency controls.
 There is no true data dictionary concept at the file manager level.
 They provide much less data independence than the DBMS does.
 File s are typically not “integrated” or “shared” in the same sense that the database is
usually private to some particular user or application.
 9

THE DATA COMMUNICATIONS MANAGER

 Database requests from an end user are actually transmitted from the user’s workstation.
 Responses back from the DBMS and online application to the user’s workstation are also
transmitted in the form of communication messages.
 All such message transmissions take place under the control of another software
component, the data communications manager(DC manager).
 The DC manager is not part of the DBMS but is an autonomous system in its own right.
 However, since it is clearly required to work in harmony with the DBMS the two are
sometimes regarded as equal partners in a higher-level cooperative venture called the
database /data communications system(DB/DC system)

CLIENT/SERVER ARCHITECTURE
 A Database system can be regarded as having a very simple two-part structure, consisting
of a server (also called the backend) and a set of clients (also called fronted)

End user

Applications Clients

Applications Server

Database

FIG. 2.4 Client/Server Architecture

 10

 The server is just the DBMS itself. It supports all of the basic DBMS functions. Thus,
“server” in this context is just another name for the DBMS.
 The clients are the various applications that run on top of the DBMS- both user –written
applications and built-in applications i.e., applications provided by the DBMS vendor or
by some third party.

VENDOR- PROVIDED TOOLS

a. Query language processor;
b. Report writers;
c. Business graphics subsystem;
d. Spreadsheets;
e. Natural language processors;
f. Statistical packages;
g. Copy management or” data extract” tools;
h. Application generators( including 4 GL processor);
i. Other application development tools, including computer- aided software engineering
(CASE) products; and many others.

UTILITIES
 Utilities are programs designed to help the DBA with various administration tasks.
 Some examples of the kind of utilities are:
 Load routines to create the initial version of the database from one or more
operating system files;
 Unload/ reload routines, to unload the database, or portions thereof, to backup
storage an to reload data from such backup copies;
 Reorganization routines, to rearrange the data in the stored database for various
reasons;
 Statistical routines, to compute various performance statistics such as file sizes or
value distributions or I/O counts , etc;
 Analysis routines , to analyze the statistics just mentioned; and so on.
11