2.2.

1 The Three-Schema Architecture

The goal of the three-schema architecture, illustrated in Figure 2.2, is to separate
the user applications from the physical database. In this architecture, schemas can
be defined at the following three levels:
1. The internal level has an internal schema, which describes the physical
storage structure of the database. The internal schema uses a physical data
model and describes the complete details of data storage and access paths for
the database.

Figure 2.2
The three-schema End Users
.architecture.

External Level Etemal Etema

Vew VIew

External/Conceptual
Mapping
Conceptual Level ConceptalSciemaa
Conceptual/lInternal
Mapping
Internal Level nitena SCiema

Stored Database

This is also known as the ANSUSPARC (American National Standards Institute/ Standards Planning And
Requirements Committee) architecture, after the committee that proposed it (Isichritzis &Kug. 1978).
 2. The conceptual level has a conceptual schema, which describes the structure
of the whole databasc for a community of users. The conceptual schema hides
the details of physical storage structures and concentrates on describing enti
ies, data types, relationships, user operations, and constraints. Usually, a rep
resentational data nodel is used to describe the conceptual schema when a
database system is implemented. This implementation conceptual schema is
often based on a conceptual schema designin a high-level data model.
3. The external orview level includes a number of external schemas or user
views. Fach externalschema describes the part of the database that a partic
ular user group is interested in and hides the rest of the database from that
user group. As inthe previous level, eachexternal schema is typically imple
mented using a representational data model, possibly based on an external
schema design in a high-level conceptual data model.
Thethree-schema architecture is a convenient tool with which the user can visual
ize theschema levels in adatabase system. Most DEMSs do not separate the three
levels completely andexplicitly, but they support the three-schema architecture
some extent. Some older DBMSs may include physical-level details in the concep
tual schema.The three-level ANSI architecture has an important place in database
technology development because it clearly separates the users' external level, the
database's conceptual level, and the internal storage level for designing a database.
Itis very much applicable in the design of DBMSS, even today. In most DBMSs that
support user views, external schemas are specified in the same data model that
describes the conceptual-level information (for example, a relational DBMS like
Oracle or SQLServer uses SQL for this).
Notice that the three schemas are only desctiptions of data; the actual data is stored
at the physical level only. In the three-schema architecture, each user group refers
toits own external schema. Hence, the DBMS must transform a request specihied
and then into
on an external schema into a request against the conceptual schema,database. If the
arequest on the internal schema for processing over the stored
request is adatabase retrieval, the data extracted from the stored database must be
reformatted to match the user's external view. The processes of transtorming
requests and results between levels are called mappings. These mappings may be
time-consuming, so some DBMSs-especially those that are meant to support small
databases-do not support external views. Even in such systens, however, it is nec
essary to transform requests between the conceptual and internal levels.
 descriptions transactions.
information
storage programmers
The parametric
ing casual Lecatalog.
t the erably. to.effectread/write. disk The internal usersfigureFigure 2.4.1
ule .transactions. ware ware A2.4 Schema,ana

us DBMS dis k DBMS

changes is
database with
details
DDL consider
users A on controlled th
of is
e 2.3 DBMS components isThe
compiler higher-level
information read/write,Many
performance. modsles divided which
such of to users who database illustrates, complex
a
of the its
each as definition DBA whocreate work top
The who the and
of Component
in to
Database
the
primarily the
DBMSs that
schemas
thprocesses
e because the DBMS
filenames
, staff do with part thstored
atReducing DBMS environmentDBMS
two in
a constitute software
mapping programs
data of is have by parts.
simplified interacts.
(meta-data) and schema
usi n g works interactive data
Figure storedManagement their catalog System
entry the responsible
The Modules system.a
sizes the onusing manager disk operating and DBMS
intormation definitions, defining DDL work 2.3 on own are top form, ..
.. In
of in interfaces first. disk, read/write their
some buffer part and this
files, the
names DBMS othersupplying
and by
the host shows whether
It module of
buffer system
usually fo r
interfaces. of
storage
the Environment section
the
among specified tò management typical
the
database formulate improves stored types
and privileged
catalog. programminginterfaces of
it the storage (0S), of Thefigure
DBMS of
we
schemas, data parameters is
on dat a discuss
in and part
DBMS
performance whi c h lowerrefers computer
The the
types commands.tuning queries, for has disk.
of module ancomponents.
d the
and catalog DDL, languages, the a
controls schedulesAccessprocessing part to
of to the considerable the system types
constraints. data and predefined itapplication DBA database to shows
includes by consid various of
items, stores access sched to sot soft
mak and staff, or
disk the
of the The
 Environment 43
D4 The Database System

Users: DBA Staf Casual Users Parametric Users

Application

-i-if-+ DDL
Statements
Prvleged
Commands
Interactive
Ouery
Programmera

Application
Programs

DDL Host
Query
Compiler Comptle Precompiler Language
Compiler

Query DML Compiled

Optimizer Compler Transactions
|

DBA Commands,
Queries, and Transactions

Runtime Stored
System Database Data
Catalog/ Processor Manager
Concurrerncy ControV
Data
Dictionary Backup/Recovery
Subsystems

Stored Dalabase Inpu/Qutput

Query and Transaçtion Irom Database
Execution:

Figure 2.3
Conponent nodues of a DBMS and their Interactlons.

In addition, the catalog stores many other types of information that are needed by
the DBMS modules, which can then look up the catalog intormation as needed.
Casual users and persons with occasional need for information from the database
interact using the interactive query intertace in Figure 2.3. We have not explicitly
shown any nenu based or fom based or mobile interactions that are typically used
to generate lhe interactive quety autonatically or to access canned trunsactions.
Tliese queies are parsed and validated for correctness of the query syntax, the
Ines ol files and data elements, and so on by a query compiler that comples
them into an internal form. This internal query is subjectedto query optimization
(discussed in Chapters 18 and 19). Among other things, the query optimizer is
concerncd with the rearrangement and possible reordering of operations, climina
tion of redundancies, and use of efficient search algorithms during execution. It
consults the system catalog for statistical and other physical information about the
stored data and generates executable-code that performs the necessary operations
for the query and makes calls on the runtime processor.

Application programmers write programs in host languages such as Java, C. or C+t

that are submitted to a precompiler. The precompiler extracts DML commands
from an application program written in a host programming language. These com
mands are sent to the DML compiler for compilation into object code for database
access. The rest of the program is sent to the host language compiler. The object
codes for the DML commands and the rest of the program are linked, forming a
canned transaction whose executable code includes calls to the runtime database
procesor. It is also becoming increasingly common to use scripting languages such
as PHP and Python to write database programs. Canned transactions are executed
repeatedly by parametric users via PCs or mobile apps; these users simply supply
the parameters to the transactions. Each execution is considered to be a separate
transaction. An example is a bank payment transaction where the account number,
payee, and amount may be supplied as parameters.
In the lower part of Figure 2.3, the runtime database processor executes (1) the
privileged commands, (2) the executable query' plàns, and (3) the canned transac
tions with runtime parameters. It works with the system catalog and may update it
with statistics. It also works with the stored data manager, which in turn uses basic
operating system services for carrying out low-level input/output (read/write)
operations between the disk and main memory. The runtime database processor
handles other aspects of data transfer, such as management of buffers in the main
memory. Some DBMSs have their own buffer management module whereas others
depend on the OS for buffer management. We have shown concurrency control
and backup and recovery systems separately as a module in this figure. They are
integrated into the working of the runtime database processor for purposes of
transaction management.
It is common to have the client program that accesses the DBMS running on a
separate computer or device from the computer on which the database resides. The
former is called the client computer running DBMS client software and the latter is
called the database server. In many cases, the client accesses a middle computer,
called the application server, which in turn accesses the database server. We elabo
rate on this topic in Section 2.5.
Figure 2.3 is not meant to describe a specific DBMS; rather, it illustrates typical
DBMS modules. The DBMS interacts with the operating system when disk accesses
to the database or to the catalog--are needed. If the computer system is shared by
many users, the OS will schedule DBMS disk access requests and DBMS processing
along with other processes. On the other hand, if the computer system is mainly
dedicated to running the database server, the DBMS will control main memory
 2.4

buffering of disk pages. The DBMS also interfaces with compilers for general
and client pro
purpose host programming languages, and with application serversinterface.
grams running on separate machines through the system network
 3.10 Another Example:A UNIVERSITY Database
We now prescnt another ekample, a UNIVERSITYdatabase, lo illustrate the ER
modeling concepts, Suppose that a database is needed to keep track of student
enrollments in classes and students' final grades. After analyzing the miniworld
rules and the users' necds, the requirements for this database were determined to be
as follows (for brevity, we showthe chosen entity type names and attribute names
for the conceptualschema in parentheses as we describe the requirements; relation
ship (ype names are only shown in the ER schema diagram):
The university is organized into colleges (COLLEGE), and each college has a
unique name (CName), a main office (COfice) and phone (CPhone), and a
particular faculty member who is dean of the college. Each college adminis
ters a number of academic departments (DEPT). Each department has a
unique name (DName), a unique code number (DCode), a main office
(DOfice) and phone (DPhone), and a particular faculty member who chairs
thedepartment. We keep track of the start date (CStartDate) when that fac
ulty member began chairing the department.

1This notation allows us to determine the key of the relationship relation, as we discuss in Chapter 9.
ieThis is aksotrue for cardinality ratios of binary relationships.
1'The (min, max) constraints can deterrnine the keys for binary relationships.
 Can combinations the SecID The
diagrammnatic
you 3. 2. following
1. ER s
university.
ticular an teach Thidays/time.
s(Sem, and(Sem,during
specifies
(SecNo, as between and current arestricted
track
(DaysTime: (Bldg) (Year), tiplesectioncourse Courses track (Addr), dent lastnane The in tifier lrackhoursiunior, leunione vel 4
think instructor an diagram particular
the addition, deprment
two Year, year,Year, each combinations
specifies underlined of of and
sections and
also assigned
name database (ld), of (Level:
ofis (SName, (Credits), 4course
of
a that Sem, values notation. students
for offerings. al to
grade classroom are the plhone instructors for
any sections classroom semester.) the room a s (LName)),
student'
offered each
nane
this
DaysTime, CRoom,
particular t hese only for has
single senion,
other allowed is that the Year, is offered offers
sectionCCode must requirements
have key,Notice recorded and
sectionsexample,
The allowed number (CRoom: section
a (Phone),
toconmposedinstructor wi
kecp
l (IName), and can name
at in instructor grades as one (INSTRUCTOR); a(CoName),
attribute the a DaysTime): tobut sections). TheSecld during sections 5 be a
Id cannot semester be primary student studeni course lorcoded
particular
to
same numbers (of uniqueunique be because that when offered
database number major of office
umlber
teach (of
for
days/time
is (RoomNo)
'MWF th is the in works MS
mbinations days/time. the be
and the A unique for
isavailable is
and
(SECTION). each code idirst data (\0ffice),
academic description level, as a of
two
INSTRUCTOR
semester used This COURSE based for ofthshown e section
keeps 9am-9.50am'
th e coded
same
(SecNo: has (Sid, name lo r lor Icourses
year. a of the
eachSECTION for values). section(Major),(STUDENT) one and Ireshman and nnque
combined by
specifies past within
semester/year), a urnique
Note two particular miniworld
on
section in (this
must track al as this department. (FName), primaryplhone(CDesc).
unique cach
that and related the Figure sections,
is several a Each the and for (COURSE),
6 code
different that have a of (Note: the
combination codedsection student is
instruclor PhD level,
have sections year,
that typical
entity. entitymany-to-many
3. 20 the building), or section date for and(|Phonc), number
thisteaching course to constraints, at years, "TR middle
every acadenic The
to an sections a
in
miniworld
the type,using leaststudents not The semesteridentifier as ha s It of stores
level), lor 2
Cch
betogetherinstructorrul e particular SECTION): For ju st
3.30pm-5.20pm' I, is birth
is
student), database
has (CCode),
must example, wethe five
in
database and of 2,related completed. required name and sophomore, a
unique? wil the addition
in the cach
deparinmenl. a ol
severalmin-max students.
only relationship sections each building 3,...for (DoB). unique
rank coursc wbih
SECTION):
in not at be
constraints: days/times (Sem), (Secid). to (MNane), sludent': (Rank): also a
the applycannot the
semester different showed section, wil a toaddress A redt course bas
each to code year mul single keep stu id en keeps
par
same This other
ER for the keep for 3
if of A
 Credits CCode DOffice DCode 94

CoName DPhone DName CName

Chapter
COURSE (1,1) OFFERS (0,N) (1,1) ADMINS (0,N)COLLEGE
Level DEPT COffice

CDesc Data 3
CPhone
(0,N) Modeling
(0,N)
(1,1) CStartDate (1,1)
(0,N) Using
HAS
the
EMPLOYS CHAIR
DEAN Entity-Relationship
SECS (0,1)
Grade
Sld(SName (0,1)
(0,N)STUDENT (DOB (1,1)
(1,1) TAKES FName
(0,1)
DaysTime (5,N) (ER)
MName
Model
(LName Rank
Phone INSTRUCTOR
CRoom) Major Addr
SECTION IName
(1,1) TEACHES (0,N)
o Year IOfice

IPhone
Sem SecNo Secld
 the
for
prumber-D
(Ooname
work
who Drumber-DnoEMPLOY
employees

RESEARCH_DEPTGon
becomes:
A
all EMPS)
of
address Address(RESEARC
query
(RESEARCH_DEPT
this
and
expression
name
Lname.
department.
Research
the -
in-line
IFname,
Retrieve EMPS Address

single
RESEARCH
Lrame,
1.
101MdIWIS. RESULT 1Frarn
ery aAs
ouery 3. Find the names of employees who work on all the projects controlled by
department number 5.
DEPT5_PROJS - P(Pno)j(TPnumibor(Oonum-s(PROJECT))
EMP_PROJ-pSsn, Pno)(TEssn. Pno (WORKS_ON)
RESULT_EMP_SSNS -EMP_PROJ+ DEPT5_PROJS
RESULT Tname, Fname(RESULT_EMP_SSNS * EMPLOYEE)
n the proiect
 orders.
relationalINTERSECTION As ees this In this with
becomes:
query
employees
EMPS_WITH_DEPS. a We expression,
in-linethUNION
is
dependent.
we MGRS_WITH_DEPS- table oéry
with
EMPS_WITH_DEPS(Ssn)
-TEn(DEPENDENT) MGRS(Ssn) ery TLname,EMPLOYEE EMPS_WITH_DEPS(Ssn) firstRESULT
EMPS_WITHOUT TTssn(EMPLOYEE)
ALL_EMPS -RESULTuname.
operation. This T1(Ssn,distinct
12 aggregate algebra.Strictly (Tpnumber Ssn=Mar Npno
mentioned RESULTLname.
query, (-ONO aery
In at with
retrieve is 5. (WORKS Operation
addition,
algebra. 7. 6.
least List Fnarmel Ssns an
Retrieve Dependent
No spcaking, ssnDEPARTMENT))
We List
we the TLname, example of function. (Otname-"Smith(name,
operation retrieve (ssn(EMPLOYEE) the towith a of_dependents)
dependents> have the
earlier, one Ssns
relation ON on
some In names
ar
retrieve no Then the tothis names SMITH_
DEPS M
particular, Fname(MGRS_WITH_DEPS
operations samethe
dependent s n Fname(EMPS_WITHOUT_DEPS
dependents weof
of
the names
Fname
2()
name
We us e becomes:
Essn=Ssn query
to the (DEPARTMENT)
(MGRS of the employees with
-
values. thquery
e of
get Ssns managers apply (ALL type 2
*
assumne all pnum- bd (Tssn WORKER
desired ESsn(DEPENDENT)
all of
EMPLOYEE) Essn AGGREGATEcannot employees
thequery the in of n - EMPS employees of Dnumber(EMPLOYEE))
ber-DnumPROJECT)
EMPS_WITH_DEPS) S (Otname-"Smith(EMPLOYEE)))
Ssnsmanagers PssnEsn(DEPENDENT))
can EMPS_WITH_DEPS, inthemployee
e query that
operations cOUNT PROJS
be can EMPS_WITHOUT_DEPS,
who attributes. SET who -
dependents be
uised be of have
EMPS_WITH_DEPS) that Dependent FUNCTION done with
* DIFFERENCE have Ssns who and
specified
to managerS in
EMPLOYEE) uses tw o
in
replace can at * have SMITH_
MGRS, least As EMPLOYEE)
at in the name(DEPENDENT) the or
8.5
often a ALL_EMPS. of M Examples
in who then and one single least MINUS no the basic more
operation MGR
others; be many operation dependents. same dependents.
dependent. * (original)
applied have wethe EMPLOYEE) in-line and one (SET wi th Tpno O
PROJS.
of
for different apply Ssns dependent Then employee
example, at
of expression,
finally
to we
DIFFERENCE) the
relational
Queries
As
in least employ
the jo in
retrieve COUNT a in
various ways
the one SET this
create.
in
have single Relational
in

Algebra