Relational Database Management System

PeIatIonaI 0atabase hanagement System
Education & Research Department

Infosys TechnoIogies Ltd
No.350, Hebbal Electronics City
Hootagalli, Mysore 570 018

Authors: Hanumesh V.J., Seema Acharya
0ocument No. AuthorIzed y Ver.PevIsIon 0ate
EF/CDFP/CFS/0807/002 0r. | P FavIndra 1.0 24Jun2005

COMPANY CONFIDENTIAL
COPYRIGHT NOTICE

All ideas and information contained in this document are the intellectual propertv of Education
and Research Department, Infosvs Technologies Limited. This document is not for general
distribution and is meant for use onlv for the person thev are specificallv issued to. This
document shall not be loaned to anvone, within or outside Infosvs, including its customers.
Copving or unauthori:ed distribution of this document, in anv form or means including
electronic, mechanical, photocopving or otherwise is illegal.

Education and Research Department
nfosys Technologies Limited
Electronic City
Hosur Road
Bangalore - 561 229, ndia.

Tel: 91 80 852 0261-270
Fax: 91 80 852 0362
www.inIy.com
mailto:E&RinIy.com
nfosys TechnologIes LImIted Course 0escrIptIon and Feferences

EF/CDFP/CFS/0807/002 7ersIon 1.0 Page III

Course Description
Course
number
DB07 Course name Relational Database Management
System
Author Hanumesh V.J., hanumesh@infosys.com , E&R Dept, BangaIore
Seema Acharya, seema_acharya@infosys.com, E&R Dept, Mysore
Pre-requisites for attending course: Must have completed:
Computer Hardware and System Software Concepts, Programming Fundamentals
Suggested course duration 07 days

Modification Log

Version Date Author(s) Reviewer Description
1.0a 06-Jun-2005 Hanumesh V.J.
Seema Acharya
Sundar K.S.
Hanumesh V.J.
FP Restructure 2005
curriculum
1.0 24-Jun-2005 Seema Acharya ncorporated review
comments

References

1. 0atabase System Concepts, Henry F Korth, Abraham SIlberschatz, Fourth EdItIon,
|cCrawHIll nternatIonal EdItIon, Computer ScIence SerIes 2002

2. An ntroductIon to 0atabase Systems, C.J.0ate, Seventh EdItIon 200J, Pearson
EducatIon

J. The Complete Feference SQL, James F. Croff and Paul N. WeInberg, Second EdItIon,
Tata |cCraw HIll EdItIon 200J

nfosys TechnologIes LImIted Table of Contents

EF/CDFP/CFS/0807/002 7ersIon 1.0 Page II
TabIe of Contents

PUPPDSE ................................................................................................................. 1
1. INTPD0UCTIDN TD 0hS....................................................................................... 2
1.1. WHAT S A 0ATA8ASE: ......................................................................................... 2
1.2. WHAT S A 0ATA8ASE |ANACE|ENT SYSTE| (08|S): ......................................................... 5
1.J. FLE SYSTE| NTEFFACE 7EFSUS 08|S NTEFFACE ............................................................. 6
1.4. |ASTEF AN0 TFANSACTDN FLES .............................................................................. 8
1.5. TFA0TDNAL APPFDACH TD NFDF|ATDN PFDCESSNC ....................................................... 10
1.5.1. 0scdvcntcyes o] the Trcdtoncl Approcch to ln]ormcton Processny ................... 11
1.6. WHY 08|S:.................................................................................................. 14
1.7. TYPES DF 0ATA8ASES ......................................................................................... 15
1.8. THFEE LE7EL AFCHTECTUFE FDF A 08|S..................................................................... 18
1.9. 08|S USEFS ................................................................................................. 21
1.10. 0ATA |D0ELS ................................................................................................ 22
1.10.1. Db]ect 8csed Loyccl Model ...................................................................... 2J
1.10.2. Record 8csed Loyccl Model ...................................................................... 2J
1.11. F08|S....................................................................................................... 26
1.12. SD|E PDPULAF F08|S PACKACES............................................................................ 27
1.1J. APPLCATDN AFEAS DF F08|S............................................................................... 27
1.14. KEYS.......................................................................................................... 27
1.15. SU||AFY ..................................................................................................... J4
2. ENTITY-PELATIDNSHIP (E-P) hD0ELINC....................................................................36
2.1. NTFD0UCTDN................................................................................................ J6
2.2. ENTTY AN0 FELATDNSHP .................................................................................... J7
2.J. CAF0NALTY DF A FELATDNSHP .............................................................................. J8
2.J.1. Dne to Dne Relctonshp .......................................................................... J8
2.J.2. Dne to Mcny Relctonshp......................................................................... J
2.J.J. Mcny to Dne Relctonshp......................................................................... J
2.J.4. Mcny to Mcny Relctonshp ....................................................................... 40
2.4. EF 0ACFA| NDTATDNS..................................................................................... 41
2.5. |D0ELNC USNC EF 0ACFA|S .............................................................................. 42
2.5.1. Steps n ER Modelny.............................................................................. 42
2.6. CASE STU0Y 1: PFD8LE| STATE|ENT......................................................................... 4J
2..1. Ccse Study 1: Soluton............................................................................. 4J
2.7. CASE STU0Y 2: PFD8LE| STATE|ENT......................................................................... 46
2.Z.1. Ccse Study 2: Soluton............................................................................. 4Z
2.8. CASE STU0Y J: PFD8LE| STATE|ENT......................................................................... 48
2.8.1. Ccse Study J: Soluton............................................................................. 4
2.9. TFANSFDF|NC AN EF |D0EL NTD PHYSCAL 0ATA8ASE 0ESCN............................................. 52
2.10. |EFTS AN0 0E|EFTS DF EF |D0ELNC ..................................................................... 54
2.10.1. Merts o] ER Modelny ............................................................................ 54
2.10.2. 0emerts o] ER Modelny......................................................................... 54
2.11. SU||AFY ................................................................................................... 55
3. NDPhALIZATIDN ................................................................................................56
J.1. NTFD0UCTDN................................................................................................ 56
J.2. THE NEE0 FDF NDF|ALZATDN ............................................................................... 56
J.J. PFDCESS DF NDF|ALZATDN.................................................................................. 57
J.J.1. 0etermncnt......................................................................................... 5Z
J.J.2. Functoncl 0ependency............................................................................ 58
J.J.J. Full Functoncl 0ependency ...................................................................... 5

EF/CDFP/CFS/0807/002 7ersIon 1.0 Page III
J.J.4. Pcrtcl 0ependency ................................................................................ 5
J.J.5. Trcnstve 0ependency ............................................................................ 0
J.J.. Key cttrbutes ...................................................................................... 0
J.J.Z. Non key cttrbutes ................................................................................. 0
J.4. TYPES DF NDF|AL FDF|S..................................................................................... 60
J.4.1. Frst Normcl Form (1 NF) ......................................................................... 0
J.4.2. Second Normcl Form (2 NF)....................................................................... 2
J.4.J. Thrd Normcl Form (J NF) ........................................................................ 5
J.4.4. 8oyce Codd Normcl Form (8CNF) ................................................................ 5
J.5. |EFTS AN0 0E|EFTS DF NDF|ALZATDN .................................................................... 67
J.5.1. Merts ................................................................................................ Z
J.5.2. 0emerts ............................................................................................. Z
J.6. SU||AFY ..................................................................................................... 69
J.7. CASE STU0Y................................................................................................... 70
4. STPUCTUPE0 UEPY LANCUACE (SL).....................................................................74
4.1. THE PUFPDSE DF SQL ........................................................................................ 74
4.2. A 8FEF HSTDFY DF SQL..................................................................................... 75
4.J. 0ATA TYPES .................................................................................................. 76
4.4. STATE|ENT TYPES ............................................................................................ 78
4.5. 0ATA 0EFNTDN LANCUACE (00L) STATE|ENTS ............................................................. 78
4.5.1. CREATE TA8LE Stctement......................................................................... Z
4.5.2. ALTER TA8LE stctement .......................................................................... 85
4.5.J. 0RDP TA8LE stctement............................................................................ 8Z
4.5.4. TR0NCATE TA8LE stctement ..................................................................... 88
4.5.5. CREATE lN0EX stctement ......................................................................... 88
4.6. 0ATA |ANPULATDN LANCUACE (0|L) STATE|ENTS ......................................................... 91
4..1. lNSERT Stctement .................................................................................. 1
4..2. 0ELETE Stctement ................................................................................. 4
4..J. 0P0ATE Stctement.................................................................................
4..4. SELECT Stctement..................................................................................
4..5. SubQueres ........................................................................................115
4... 1DlNS ................................................................................................121
4..Z. Queres usny EXlSTS / NDT EXlSTS.............................................................12Z
4..8. The Drder o] Executon o] c SELECT stctement..............................................128
4.7. 7EWS .......................................................................................................129
4.Z.1. Horzontcl \ew ...................................................................................12
4.Z.2. \ertccl \ew.......................................................................................12
4.Z.J. 0RDP \lEW Stctement ............................................................................12
4.Z.4. 1oned \ews .......................................................................................1J0
4.Z.5. \lEW 0pdctes ......................................................................................1J0
4.Z.. Checkny \ew 0pdctes (CHECK DPTlDN)......................................................1J0
4.Z.Z. Advcntcyes o] \ews ..............................................................................1J2
4.Z.8. 0scdvcntcyes o] \ews...........................................................................1J2
4.8. 0ATA CDNTFDL LANCUACE (0CL) ...........................................................................1J2
4.8.1. 6rcntny Prvleyes................................................................................1JJ
4.8.2. Revokny Prvleyes (RE\DKE) ...................................................................1J4
4.9. E|8E00E0 SQL..............................................................................................1J5
4..1. Purpose .............................................................................................1J5
4..2. Why Embedded SQL ..............................................................................1J5
4.10. 8EST PFACTCES .............................................................................................1J8
4.11. SU||AFY ....................................................................................................142
5. DN-LINE TPANSACTIDN PPDCESSINC(DLTP) ............................................................. 143
5.1. PUFPDSE.....................................................................................................14J

EF/CDFP/CFS/0807/002 7ersIon 1.0 Page Iv
5.2. TFANSACTDN................................................................................................14J
5.J. TFANSACTDN SYSTE|S ......................................................................................145
5.J.1. 8ctch Trcnsccton Processny System..........................................................145
5.J.2. Dnlne Trcnsccton Processny System (DLTP)...............................................145
5.J.J. Recl tme Trcnsccton Processny System.....................................................14
5.4. TFANSACTDN PFDPEFTES ...................................................................................146
5.5. FEQUFE|ENTS FDF AN DLTP SYSTE| .......................................................................147
5.5.1. lnteyrty ............................................................................................14Z
5.5.2. Concurrency ........................................................................................148
5.6. LDCKS .......................................................................................................152
5..1. Shcred Lock (S) ....................................................................................15J
5..2. Exclusve Lock (X) .................................................................................15J
5.7. CFANULAFTY DF LDCKNC...................................................................................154
5.8. NTENT LDCKNC.............................................................................................156
5.8.1. lntent Shcre (lS) ...................................................................................15Z
5.8.2. lntent Exclusve (lX) ..............................................................................15Z
5.8.J. Shcred lntent Exclusve (SlX) ....................................................................15Z
5.8.4. Ccse study ]or lntent Locks......................................................................15
5.9. 0EA0LDCK ...................................................................................................161
5.10. T|ESTA|PNC ...............................................................................................162
5.11. SECUFTY ....................................................................................................164
5.12. FECD7EFY ...................................................................................................164
5.1J. TFANSACTDN LDC...........................................................................................165
5.1J.1. 0e]erred updcte...................................................................................1
5.1J.2. lmmedcte 0pdcte ................................................................................1Z
5.1J.J. CheckPonts .......................................................................................1
5.14. SU||AFY ....................................................................................................17J
6. DN LINE ANALYTICAL PPDCESSINC (DLAP) .............................................................. 175
6.1. 0FFEFENCE 8ETWEEN DLTP AN0 DLAP .....................................................................175
6.2. 0ATA WAFEHDUSE ...........................................................................................176
.2.1. Why dctc wcrehouse s needed ................................................................1Z
.2.2. Chcrccterstcs o] 0ctc Wcrehouse:............................................................1ZZ
.2.J. 0ctc Wcrehousny Termnoloyy.................................................................1ZZ
.2.4. 0ctc Collecton ]or 0ctc Wcrehouse Applcctons...........................................1Z8
.2.5. Storny o] dctc n 0ctc wcrehouse .............................................................1Z
.2.. Reportny o] c 0ctc wcrehouse cpplccton ..................................................181
.2.Z. 0]]erence between 0ctc Wcrehouse cnd 0ctc Mcrt........................................182
.2.8. Populcr tools cvclcble ]or dctc wcrehousny................................................18J
6.J. SU||AFY ....................................................................................................18J
CLDSSAPY............................................................................................................. 184
IN0EX .................................................................................................................. 187
nfosys TechnologIes LImIted FelatIonal 0atabase |anagement System
EF/CDFP/CFS/0807/002 7ersIon 1.0 Page 1
PUPPDSE
All busIness actIvItIes deal wIth a lot of data.

Examles:
Schools, colleyes cnd unverstes store dctc cbout students, courses, trcners, etc.
8cnks store dctc cbout ther customers, trcnscctons
1
(deposts, wthdrcwcls), locns,
etc.

A 0atabase |anagement System (08|S) provIdes an effIcIent storage and data management
mechanIsm.

All real lIfe software projects use databases to store huge volumes of data. t Is extremely
Important for a software engIneer to understand the concepts of 08|S. The knowledge of
08|S enables a software engIneer to:

Store data
Access data
|odIfy data
0elete data
Share data among the dIfferent users
Ensure securIty of the data

n short, 08|S concepts and technIques help In the effIcIent management of data.

1
TransactIon: A group of processIng steps that are treated as a sIngle actIvIty to achIeve a desIred
result. n 08|S, collectIons of operatIons that form a sIngle logIcal unIt of work are called transactIons.
A database system ensures proper executIon of transactIons despIte faIlures - eIther the entIre
transactIon executes, or none of It does.

1. IntroductIon to 0hS

1.1. What Is a 0atabase!
A database Is an organIzed collectIon of Interrelated data.

Examle: Consder c bcnk dctcbcse. The bcnk stores dctc cbout ther customers n c ]le
known cs Customer_0etcls. The Customer_0etcls ]le hcs the ]ollowny ]elds:

Cust_l0: The customer's dent]ccton number
Cust_Lcst_Ncme: The customer's lcst ncme
Cust_Md_Ncme: The customer's mddle ncme or ntcls
Cust_Frst_Ncme: The customer's ]rst ncme
Account_No: The customer's cccount number
Account_Type: The type o] cccount thct the customer hcs n the bcnk (Scvnys or
Checkny etc).
8cnk_8rcnch: The ncme o] the bcnk brcnch
Cust_Emcl: The customer's emcl l0

The bcnk clso stores dctc cbout the locn(s) tcken by ts customers. The locn detcls cre
stored n the ]le Customer_Locn. The Customer_Locn ]le hcs the ]ollowny ]elds:

Cust_l0: The customer's dent]ccton number
Locn_No: The locn number to dent]y the locn
Amount_n_0ollcrs: The cmount locned by the bcnk to the customer

Dne customer ccn cvcl multple locns ]rom the bcnk.

The dctc stored n the two ]les, Customer_0etcls cnd Customer_Locn consttutes
nterrelcted dctc.

Fefer to FIgure 11.

EF/CDFP/CFS/0807/002 7ersIon 1.0 Page J
Cust_IDCust_Last_
Name
Account
_No
Bank_Branch Cust_EmaiI
101Smith 1020 Downtown Smith_Mike@yahoo.com
105Jones 2389 Brighton Jones_Simon@rediffmail.com
104Quails 2367 Downtown Quails_Jack@yahoo.com
103Langer 3421 Plainsboro Langer_Justin@yahoo.com
102Smith 2348 Bridgewater Smith_Graham@rediffmail.com
Account_
Type
Savings
Checking
Savings
Checking
Checking
Cust_Mid
_Name
A.
S.
G.
D.
E.
Cust_First
_Name
Mike
Graham
Justin
Jack
Simon
Cust_ID Loan_No Amount_in_DoIIars
101 1011 8755.00
103 2010 2555.00
104 2056 3050.00
103 2015 2000.00
Customer_Detail records from Customer_Details file
Customer_Loan records from Customer_Loan file
Bank Database
Customer_Details file
Customer_Loan file

FIgure 1-1: ExampIe of a ank 0atabase
The data In the database Is Integrated whIch means that the database Is a collectIon of
several dstnct
2
fIles. These dIstInct fIles may have some duplIcate data but the duplIcatIon
of data Is kept to the mInImum.

Examle: Fyure 11 shows two ]les, Customer_0etcls cnd Customer_Locn. The two ]les
cre dstnct n the sense, Customer_0etcls ]le contcns detcls cbout the bcnk's customers
cnd the Customer_Locn ]le contcns detcls cbout cll the locns tcken by the customers o]
the bcnk. 8oth the ]les hcve the Cust_l0 ]eld.

ln order to scncton c locn to c customer, the bcnk requres the cccount number
(Account_No) o] the customer. There s no need to nclude the cccount number n]ormcton
cycn n the Customer_Locn ]le, beccuse t ccn clwcys be dscovered by re]errny to the
Customer_0etcls ]le.

The data In the database can be shared. SharIng means IndIvIdual pIeces of data In the
database can be shared among dIfferent users. Each of those users can have access to the
same pIece of data. They can use the data for dIfferent purposes.

Fefer to FIgure 12.

2
0IstInct: Not IdentIcal.
User in the Bank's Loan Department
User in the Bank's Fixed Deposit Department
Cust_IDCust_Last_
Name
Account
_No
101 Smith 1020 Downtown Smith_Mike@yahoo.com
105 Jones 2389 Brighton Jones_Simon@rediffmail.com
104 Quails 2367 Downtown Quails_Jack@yahoo.com
103 Langer 3421 Plainsboro Langer_Justin@yahoo.com
102 Smith 2348 Bridgewater Smith_Graham@rediffmail.com
Account_
Type
Savings
Checking
Savings
Checking
Checking
Cust_Mid
_Name
A.
S.
G.
D.
E.
Cust_First
_Name
Mike
Graham
Justin
Jack
Simon

FIgure 1-2: SharIng the Account_No InformatIon from the Customer_0etaIIs fIIe

As depcted n Fyure 12, the Account_No n]ormcton ]rom the Customer_0etcls ]le s
beny cccessed by the users n the bcnk's Fxed 0epost 0epcrtment cnd the users n the
bcnk's Locn 0epcrtment. The n]ormcton would typcclly be used ]or d]]erent purposes by
the two clcsses o] users.

The users can even concurrently access the database. Concurrent access ImplIes that
dIfferent users can access the same pIece of data at the same tIme.

PoInts to Pemember:

A database Is an organIzed collectIon of Interrelated data
0ata In the database:
s Integrated
Can be shared
Can be concurrently accessed

1.2. What Is a 0atabase hanagement System (0hS)!
A 0atabase hanagement System (0hS) Is a collectIon of Interrelated fIles and a set of
programs that allow users to access and modIfy these fIles. The prImary goal of a 08|S Is to
provIde a convenIent and effIcIent way to store, retrIeve and modIfy InformatIon.

FIgure 1J shows an end user
J
workIng wIth data from the Customer_0etaIls fIle, maIntaIned
In the bank database.

FIgure 1-3: SImpIIfIed pIcture of a database system
The database systems are desIgned to:
0efIne structures for the storage of data
ProvIde mechanIsms for the mcnpulcton
4
of data
Ensure the safety of the data stored, despIte system crashes or attempts at
unauthorIzed access
n short, database systems are desIgned to manage large volumes of data.

J
End User: The person for whom a system Is beIng developed. Example: a bank teller or a bank
manager Is an end user of a bank system.
4
hanIpuIatIon: 0ata manIpulatIon refers to the addItIon of new data, modIfIcatIon of exIstIng data,
etc.
1.3. FIIe System Interface versus 0hS Interface
n the tradItIonal fIle approach, data Is stored In ]lct ]les
5
whIch are maIntaIned by the fIle
system, under the operatIng system's control.

Fefer to FIgure 14.

The end users use the applIcatIon programs to perform specIfIc tasks. For example, personnel
In the bank's Loan 0epartment make use of the Loan_ProcessIng system to process the loan(s)
of customer(s).

All applIcatIon programs go through the fIle system to access the data stored In these flat
fIles.

Loan_Processing
(Application Program)
Fixed_Deposit_Processing
Transaction_Processing
Customer_Details.dat Customer_Loan.dat Customer_Fixed_Deposit.dat Customer_Transaction.dat

FIgure 1-4: TradItIonaI method of 0ata Storage

n the 08|S approach, all requests to use the data stored In the database are handled by the
08|S. The end user can use eIther the applIcatIon programs or the standard SQL
6
to access
the data.

Fefer to FIgure 15.

5
FIat fIIes: A flat fIle Is a fIle contaInIng records that has no structured InterrelatIonshIp. FIles used In
programmIng fundamentals (PF) projects were essentIally flat fIles.
6
SL: (Structured Query Language). A language used by relatIonal databases to query, update and
manage data. FelatIonal 0atabase Is explaIned In SectIon 1.10.2.J.
The applIcatIon programs are wrItten In some programmIng language such as CD8DL, PL/,
C++ or In some hIgher level ]ourth yenercton lcnyucye
7
. The standard SQL Interface Is
provIded as an Integral part of the database system software to access the database.

Loan_Processing
Bank Database
Customer_Details
Customer_Loan
Customer_Fixed_Deposit
Customer_Transaction

FIgure 1-5: 0hS handIes aII requests for access to the database

The 08|S acts as a layer of cbstrccton
8
over the fIle system.

7
Fourth CeneratIon Language (4CL): A 4CL Is typIcally nonprocedural and desIgned so that end users
can specIfy what they want wIthout havIng to know how the computer wIll process theIr requIrement.
8
AbstractIon: A sImplIfIed representatIon of somethIng that Is potentIally quIte complex. t Is often
not necessary to know the exact detaIls of how somethIng works, Is represented or Is Implemented,
because It can stIll be used In Its sImplIfIed form.
Examle: As depcted n Fyure 1, n the ]le system nter]cce, the end user uses cn
cpplccton proyrcm wrtten n c hyh level lcnyucye such cs CD8DL, to cccess the dctc ]rom
the Customer_0etcls ]le. The ]les cre mcntcned by the ]le system under the operctny
systems control. ln the 08MS nter]cce, the end user uses cn SQL nter]cce to plcce c request
to the 08MS to retreve dctc ]rom the Customer_0etcls tcble
.

FIgure 1-6: FIIe System Interface versus 0hS Interface
1.4. haster and TransactIon FIIes
A master fIle Is used to store relatIvely statIc data about some entty
10
. A transactIon fIle
contaIns relatIvely transIent data about a partIcular data processIng task.

Examle: Consder the bcnkny system consstny o] two ]les, the Customer_0etcls cnd the
Customer_Trcnsccton ]le.

9
TabIe: A table has a specIfIed number of columns but can have any number of rows. Fows stored In a
table are structurally equIvalent to records from flat fIles.
10
EntIty: An entIty Is a "thIng" or "object" In the real world that Is dIstInguIshable from other objects.
Example: each person Is an entIty, and bank accounts can be consIdered to be entItIes.
ln Fyure 1Z, Customer_0etcls s the mcster ]le contcnny cll the n]ormcton cbout the
bcnk's customers. ln Fyure 18, Customer_Trcnsccton s the trcnsccton ]le contcnny
n]ormcton cbout cll the trcnscctons thct c customer mckes wth the bcnk.

The Customer_0etcls ]le s mod]ed rcrely. For excmple, when c new cccount s crected or
whenever the exstny detcls o] c customer chcnyes. However, ]or every depost or
wthdrcwcl mcde by the customer(s), the Customer_Trcnsccton ]le s updcted.

FIgure 1-7: ExampIe of master fIIe - Customer_0etaIIs

FIgure 1-8: ExampIe of transactIon fIIe - Customer_TransactIon

PoInts to Pemember:

A master fIle
Stores relatIvely statIc data about an entIty
Changes rarely

A transactIon fIle
Stores relatIvely transIent data about a partIcular data processIng task
Changes frequently as transactIons happen more perIodIcally and In
large numbers

1.5. TradItIonaI Approach to InformatIon ProcessIng
n the tradItIonal fIle approach each applIcatIon maIntaIns Its own master fIle and generally
has Its own set of transactIon fIles. FIles are customdesIgned for each applIcatIon and there
Is lIttle sharIng of data among the varIous applIcatIons.

ApplIcatIon programs are datadependent. t Is ImpossIble to change the physIcal
representatIon (how the data Is physIcally represented In storage) or access technIque (how It
Is physIcally accessed) wIthout affectIng the applIcatIon.

Fefer to FIgure 19.

Although the tradItIonal, fIleorIented approach Is stIll wIdely used, It has some serIous
dIsadvantages. The next sectIon deals wIth the drawbacks of the tradItIonal approach to
InformatIon processIng.

Loan_Processing
(Application Programs)
Customer_Details
Customer_Transaction
Customer_Loan
End User uses
AppIication Programs
Application programs use
Transaction file(s) and Master file(s)
Master fiIe
Transaction fiIe

FIgure 1-: The tradItIonaI approach to InformatIon processIng

1.5.1. 0Isadvantages of the TradItIonaI Approach to InformatIon
ProcessIng
The dIsadvantages of the tradItIonal approach to InformatIon processIng are dIscussed below:
0ata SecurIty: The data as maIntaIned In the flat fIle(s) Is easIly accessIble and therefore
not secure

Examle: Consder the bcnkny system. The Customer_Trcnsccton ]le hcs detcls cbout the
totcl cvclcble bclcnce o] cll customers. A customer wcnts n]ormcton cbout hs cccount
bclcnce. ln c ]le system t s d]]cult to yve the customer cccess to only hs dctc n the ]le.
Thus en]orcny securty constrcnts
11
]or the entre ]le or ]or certcn dctc tems cre
d]]cult.

0ata Pedundancy: Dften the same InformatIon Is duplIcated In two or more fIles
Fefer to FIgure 110.

Cust_ID Fixed_Deposit
_No
Amount_in_
DoIIars
101 2011 8055.00
103 2015 2060.00
104 3010 3050.00
Cust_Last_
Name
Smith
Langer
Quails
Cust_Mid
_Name
A.
G.
D.
Cust_First
_Name
Mike
Justin
Jack
Rate_of_Interest
_in_Percent
6.5
6.5
6.5
Cust_EmaiI
Smith_Mike@yahoo.com
Langer_Justin@yahoo.com
Quails_Jack@yahoo.com
Customer_Fixed_Deposit records from Customer_Fixed_Deposit file
Redundant Data
Cust_IDCust_Last_
Name
Account
_No
Account_
Type
Savings
Checking
Savings
Checking
Checking
Cust_Mid
_Name
A.
S.
G.
D.
E.
Cust_First
_Name
Mike
Graham
Justin
Jack
Simon

FIgure 1-10: 0ata Pedundancy In fIIes
ThIs duplIcatIon of data (redundancy) leads to hIgher storage and access cost. n addItIon It
may lead to data nconsstency
12
. Examle: Assume thct the scme dctc s repected n two or
more ]les. l] chcnye s mcde to dctc n one ]le, t s requred thct the chcnye be mcde to
the dctc n the other ]le cs well. l] ths s not done, t wll lecd to error durny cccess to the
dctc.

Examle: As depcted n Fyure 110, customer's detcls such cs Cust_Lcst_Ncme,
Cust_Md_Ncme, Cust_Frst_Ncme, Cust_Emcl cre stored both n the Customer_0etcls ]le

11
ConstraInts: restrIctIon, lImItatIon.
12
InconsIstency: lackIng unIformIty or agreement.
cnd the Customer_Fxed_0epost ]le. l] the emcl l0 o] one customer, ]or excmple, Lcnyer
6. 1ustn chcnyes ]rom Lcnyer_1ustn@ychoo.com to Lcnyer_1ustn@red]]mcl.com, the
Cust_Emcl must be updcted n both the ]les; otherwse t wll lecd to nconsstent dctc.

However, one ccn desyn ]le systems wth mnmcl redundcncy. 0ctc redundcncy s
sometmes pre]erred. Examle: Assume thct the customer's detcls such cs Cust_Lcst_Ncme,
Cust_Md_Ncme, Cust_Frst_Ncme cnd Cust_Emcl cre not stored n the
Customer_Fxed_0epost ]le. l] t s requred to yet ths n]ormcton cbout the customer
clony wth hs ]xed depost detcls, t would mecn thct the detcls be retreved ]rom two
]les. Ths would mecn cn ncrecsed overhecd. lt s thus pre]erred to store the n]ormcton n
the Customer_Fxed_0epost ]le tsel].

0ata IsoIatIon: 0ata IsolatIon means that all the related data Is not avaIlable In one fIle.
Cenerally, the data Is scattered In varIous fIles, and the fIles may be In dIfferent formats,
therefore wrItIng new applIcatIon programs to retrIeve the approprIate data Is dIffIcult.

Programl0ata 0ependence: Under the tradItIonal fIle approach, applIcatIon programs are
datadependent. t Is ImpossIble to change the physIcal representatIon (how the data Is
physIcally represented In storage) or access technIque (how It Is physIcally accessed)
wIthout affectIng the applIcatIon. Changes In the physIcal format of the master fIle(s),
such as addItIon of a data fIeld requIres that the change be made In all the applIcatIon
programs that accesses the master fIle. Consequently, for each of the applIcatIon
programs that a programmer wrItes or maIntaIns, the programmer must also focus on data
management Issues. There can be no centrclzed
1J
executIon of the data management
functIons. 0ata management Is scattered among all the applIcatIon programs.

Examle: Consder the bcnkny system. The mcster ]le, Customer_Fxed_0epost contcns
detcls cbout the customers ]xed depost cccounts. Re]er to Fyure 111. A customer's ]xed
depost record s descrbed by:
Cust_l0
Cust_Lcst_Ncme
Cust_Md_Ncme
Cust_Frst_Ncme
Cust_Emcl
Fxed_0epost_No
Amount_n_0ollcrs
Rcte_o]_lnterest_n_Percent

An cpplccton proyrcm s cvclcble to dsplcy cll the detcls cbout the ]xed depost
cccounts o] cll the customers. Assume thct c new dctc ]eld, the

1J
CentraIIzed: Systems where decIsIon makIng, flow of data or the begInnIng of actIvItIes are InItIated
at the same central poInt and dIssemInated to remote poInts In the organIzatIon
EF/CDFP/CFS/0807/002 7ersIon 1.0 Page 1J
FIxed_0eposIt_|aturIty_0ate Is added to the master fIle. The applIcatIon program must also
be altered because It depends on the master fIle.

l] ]or excmple, the physccl ]ormct o] the mcster/trcnsccton ]le such cs the ]eld delmter
or record delmter s chcnyed, t necesstctes thct the cpplccton proyrcm whch depends
on t, clso be cltered.

FIgure 1-11: haster fIIe - Customer_FIxed_0eposIt

Lack of FIexIbIIIty: The tradItIonal systems are able to retrIeve InformatIon for
predetermIned requests for data. f the management needs unantIcIpated data, the
InformatIon can perhaps be provIded If It Is In the fIles of the system. ExtensIve
programmIng Is however requIred whIch may result In a delay. 8y the tIme the
InformatIon Is made avaIlable, It may no longer be requIred or useful.

Examle: Consder the bcnkny system. An cpplccton proyrcm s cvclcble to yenercte c lst
o] customer ncmes n c pcrtculcr crec o] the cty. However the bcnk mcncyer requres c
lst o] those customers who hcve cn cccount bclcnce yrecter thcn $10,000.00 cnd resde n c
pcrtculcr crec o] the cty. An cpplccton proyrcm ]or ths purpose does not exst. The bcnk
mcncyer hcs two choces:

To prnt the lst o] customer ncmes n c pcrtculcr crec o] the cty cnd then
mcnuclly ]nd out those wth cn cccount bclcnce yrecter thcn $10,000.00
Hre cn cpplccton proyrcmmer to wrte the cpplccton proyrcm ]or the scme

8oth the solutons cre cumbersome.

Concurrent Access AnomaIIes: |any tradItIonal systems allow multIple users to access
and update the same pIece of data sImultaneously. 8ut the InteractIon of concurrent
updates may result In InconsIstent data. To guard agaInst thIs possIbIlIty, the system must
maIntaIn some form of supervIsIon. 8ut supervIsIon Is dIffIcult because data may be
accessed by many dIfferent applIcatIon programs and these applIcatIon programs may not
have been coordInated prevIously.

Examle: Consder the bcnkny system. Assume thct the bcnk mcncyer s cnclyzny cll the
trcnscctons mcde by the customers. At cbout the scme tme, c customer cccesses hs
cccount to mcke c wthdrcwcl. The cccount s both recd by the bcnk mcncyer cnd updcted
by the customer ct the scme tme. Ths s cclled concurrent cccess. 8eccuse the customer's
cccount s beny updcted ct the scme tme, there s c possblty o] the bcnk mcncyer
recdny cn ncorrect bclcnce.

These dIffIcultIes prompted the development of database systems.

PoInts to Pemember:

0Isadvantages of the tradItIonal fIle approach:
0ata SecurIty - 0ata easIly accessIble by all and therefore not secure

0ata Pedundancy - Same data Is duplIcated In two or more fIles whIch
may lead to update anomalIes

0ata IsoIatIon - All the related data Is not avaIlable In one fIle. Thus
wrItIng a new applIcatIon program Is dIffIcult

Program l 0ata 0ependence - ApplIcatIon programs are data
dependent. t Is ImpossIble to change the physIcal representatIon (how
the data Is physIcally represented In storage) or access technIque (how
It Is physIcally accessed) wIthout affectIng the applIcatIon

Lack of FIexIbIIIty - Dnly predetermIned requests for InformatIon can
be met. t Is not flexIble enough to satIsfy unantIcIpated querIes

Concurrent Access AnomaIIes - Same pIece of data Is allowed to be
updated sImultaneously whIch leads to InconsIstencIes
1.6. Why 0hS!
08|S ensures the followIng:
ApplIcatIon programs and queres
14
are dataIndependent. They do not depend on any
one partIcular physIcal representatIon of data In secondary storage or access
technIque

Allows for sharIng of data among dIfferent users. Users are also able to access the
database concurrently wIthout facIng the Issues of InconsIstent data

Controls redundancy and InconsIstency

ProvIdes secure access to the database

14
uerIes: A query Is essentIally a request that a user makes on the database.
Enforces nteyrty constrcnts
15
(also known as busIness rules) by preventIng the entry
of InvalId InformatIon Into the database

Enables backup and recovery from system crashes

1.7. Types of 0atabases
There are two generIc database archItectures: centralIzed and dIstrIbuted. The basIc
dIfferences between the two archItectures are:
CentralIzed

0IstrIbuted

All data Is located at a sIngle sIte
Allows for greater control over
accessIng and updatIng data
7ulnerable to faIlure as they depend
on the avaIlabIlIty of resources at the
central sIte

Examle: The cccount n]ormcton o]
customers s stored n c pcrtculcr brcnch
o]]ce o] c bcnk. Ths n]ormcton must be
shcred ccross cll Automcted Teller Mcchnes
(ATM), so thct customers ccn wthdrcw
money ]rom ther cccounts. lnstecd o]
storny the customer n]ormcton n every
ATM mcchne t ccn be stored ct c common
plcce (the brcnch o]]ce o] the bcnk) cnd
shcred over c network.

Fefer to FIgure 11J.
The database Is stored on several
computers from personal computers
up to maInframe systems
Computers In a dIstrIbuted system
communIcate wIth one another
through varIous communIcatIon
medIa, such as hIgh speed networks
or telephone lInes
0IstrIbuted databases are
geographIcally separated and
managed
0IstrIbuted databases are separately
admInIstered
0IstrIbuted databases have a slower
InterconnectIon

Examle: Consder the bcnk system. The
bcnk's hecd o]]ce s loccted ct Chccyo cnd
the brcnch o]]ces cre ct Melbourne cnd
Tokyo. The bcnk dctcbcse s dstrbuted
ccross the brcnch o]]ces. The brcnch o]]ces
cre connected throuyh c network

15
IntegrIty ConstraInts: A set of rules to ensure the correctness and accuracy of data.

FIgure 1-12: CentraIIzed 0atabase

FIgure 1-13: 0IstrIbuted 0atabases
The dIstrIbuted databases can be classIfIed as homoyeneous
16
or heteroyeneous
17
.

n a dIstrIbuted system, It Is easy to dIstInguIsh between local and global transactIons. A local
transactIon Is one that accesses data In the sIngle sIte at whIch the transactIon was InItIated.
A global transactIon, on the other hand, Is one whIch eIther accesses data In a sIte dIfferent
from the one at whIch the transactIon was InItIated, or access data In several dIfferent sItes.

Examle: Consder the bcnk system. The bcnk's hecd o]]ce s loccted ct Chccyo cnd the
brcnch o]]ces cre ct Melbourne cnd Tokyo. The brcnch o]]ces cre connected throuyh c
network. Ecch brcnch hcs ts own computer, wth c dctcbcse consstny o] cll the cccounts
mcntcned ct thct brcnch.
Re]er to Fyure 114.
The hecd o]]ce mcntcns n]ormcton cbout cll the brcnches o] the bcnk. Consder c
trcnsccton to cdd $50 to cccount number 1020 loccted ct the 0owntown bcnk brcnch n
Tokyo. l] the trcnsccton wcs ntcted ct the 0owntown bcnk brcnch n Tokyo, then t s
consdered loccl; otherwse, t s consdered ylobcl. A trcnsccton to trcns]er $50 ]rom
cccount 1020 to cccount 2J8, whch s loccted ct the 8ryhton bcnk brcnch n Melbourne, s
c ylobcl trcnsccton, snce cccounts n two d]]erent stes cre cccessed cs c result o] ts
executon.

Thus In a dIstrIbuted database system:

The varIous sItes are aware of one another
Each sIte provIdes an envIronment to execute both local and global transactIons
f each sIte runs the same dIstrIbuted database management software, It Is called
homogeneous dIstrIbuted database systems
f dIfferent sItes run dIfferent database management software, It Is dIffIcult to
manage global transactIons. Such systems are called multIdatabase systems or
heterogeneous dIstrIbuted database systems

FIgure 1-14: Customer_0etaIIs fIIe

16
Homogeneous: All the same, unIform, harmonIzed.
17
Heterogeneous: varIed, mIxed, dIverse.
1.8. Three IeveI archItecture for a 0hS
|ost commercIal databases are based on a threelevel archItecture model called the
ANS/SPAFC (AmerIcan NatIonal Standards nstItute/Standard PlannIng and FequIrements
CommIttee) model.


InternaI Schema
nternal level
(storage view)
ConceptuaI Schema
ExternaI Schema A ExternaI Schema B ExternaI Schema Z
Conceptual level
(common user view)
External / View Level
(individual user views)

FIgure 1-15: The three IeveIs of the archItecture

The overall desIgn of the database Is called database schema. Schemas are not changed
frequently. n general, database systems support one Internal schema, one conceptual
schema and several external schemas.

ExternaI l VIew IeveI: |any users of the database system are not concerned wIth all the
InformatIon In the database. nstead, they need to access only a part of the database. The
external level of abstractIon sImplIfIes the end user's InteractIon wIth the system. The system
may provIde many vIews for the same database.

ConceptuaI l LogIcaI IeveI: The conceptual level descrIbes what data are stored In the
database, and what relatIonshIps exIst among those data. ThIs level Is used by the 0ctcbcse
Admnstrctor
18
(s) (08A), who In turn decIde what InformatIon must be kept In the database.

18
0atabase AdmInIstrator: The 08A admInIsters the 08|S and Is In charge of creatIng, maIntaInIng and
modIfyIng all the three levels of the 08|S. The 08A also controls the allocatIon of system resources,
grants/revokes prIvIleges to/from users and ensures the consIstency of the database.
InternaI l PhysIcaI IeveI: The Internal level Is the lowest level of abstractIon and descrIbes
the data storage and access methods. 0atabase AdmInIstrator(s) may be aware of certaIn
detaIls of the physIcal organIzatIon of the data.

Examle: Consder c bcnkny system. lt uses:
A bcnk dctcbcse
Customer_0etcls tcble
Customer_Trcnsccton tcble

At the nterncl level, c Customer_0etcls or Customer_Trcnsccton record ccn be descrbed
cs c block o] consecutve storcye locctons (]or excmple, words or bytes). The lcnyucye
compler hdes ths level o] detcl ]rom proyrcmmers. Smlcrly, the dctcbcse system hdes
the lowestlevel storcye detcls (how the dctc s stored cnd cccessed) ]rom dctcbcse
proyrcmmers.

At the conceptucl level, the tcble de]nton (the cttrbute
1
dctc type cnd wdth de]nton)
cnd the nterrelctonshp cmony the dctc s descrbed.

Fnclly ct the externcl level, severcl vews
20
o] the dctcbcse cre de]ned, cnd dctcbcse end
users cre cble to see these vews. ln cddton to hdny detcls o] the conceptucl level o] the
dctcbcse, the vews clso provde c securty mechcnsm to prevent users ]rom cccessny pcrts
o] the dctcbcse. For excmple, tellers n the bcnk wll be cble to see only thct pcrt o] the
dctcbcse thct hcs n]ormcton on customer cccounts; they ccnnot cccess n]ormcton
concernny sclcres o] bcnk employees.

0etaIled system archItecture (FIgure 116).

The database management system (08|S) Is the software that handles all access to the
database. Conceptually, what happens Is the followIng:
A user Issues an access request (typIcally usIng SQL)
The 08|S Intercepts that request and analyzes It
The 08|S Inspects the external schema for that user, the correspondIng
external/conceptual mappIng, the conceptual schema, the conceptual/Internal
mappIng and the storage structure defInItIon
The 08|S executes the necessary operatIons on the stored database

19
AttrIbute: The lIteral meanIng Is qualIty; characterIstIc; traIt or feature. EntItIes are descrIbed In a
database by a set of attrIbutes. For Example, In the bank system, Cust_0, Cust_EmaIl etc. descrIbe
Customer0etaIl entIty set.
20
VIew: A vIew Is a vIrtual table In the database defIned by a query. For more detaIls on vIews see
Chapter 4.

FIgure 1-16: 0etaIIed System ArchItecture

The above fIgure depIcts the three levels of 08|S archItecture. The external vIew Is how the
customer, |Ike A SmIth vIews It. The conceptual vIew Is how the 08A vIews It. The Internal
vIew Is how the data Is actually stored.

CFEATE TA8LE Customer_Loan (
Cust_0 NU|8EF(4)
Loan_No NU|8EF(4)
Amount_In_0ollars NU|8EF(7,2))

Customer_Loan
Cust_0 : 101
Loan_No : 1011
Amount_In_0ollars : 8755.00

Cust_0 TYPE = 8YTE (4), DFFSET = 0
Loan_No TYPE = 8YTE (4), DFFSET = 4
Amount_In_0ollars TYPE = 8YTE (7), DFFSET = 8
Ccnceptuc|
Fxte|nc|
|nte|nc|
FIgure 1-17: An exampIe of the three IeveIs
1.. 0hS Users
The 08|S users, dependIng on theIr level of InteractIon wIth the system, fall Into one of the
three categorIes.
End User: End users deal only wIth the hIghest level of abstractIon. End users may not
be concerned wIth or even aware of the detaIls of the 08|S. TypIcally, the end user Is
Involved In updates to the database or querIes on the database.
AppIIcatIon Programmer: ApplIcatIon programmer Is responsIble for wrItIng database
applIcatIon programs In some programmIng language such as CD8DL, PL/, C++, or
some hIgherlevel fourth generatIon language. The applIcatIon programs access the
database by IssuIng the approprIate request to the 08|S
0atabase AdmInIstrator (0A): The 08A can be a sIngle person or a group of persons.
The functIons of the 08A Include the followIng:
0efInIng the ConceptuaI Schema: t Is the 08A's job to decIde exactly what
InformatIon Is to be held In the database. The 08A IdentIfIes the entItIes and
the InformatIon to be recorded about those entItIes. ThIs process Is usually
referred to as logIcal database desIgn. Dnce the 08A has decIded the content
of the database at an abstract level, he creates the correspondIng conceptual
schema
0efInIng the InternaI Schema: The 08A must also decIde how the data Is to be
represented In the database. ThIs process Is usually referred to as physIcal
database desIgn. HavIng done the physIcal desIgn, the 08A must then create
the correspondIng storage structure defInItIon. n addItIon, the 08A must also
defIne the assocIated conceptual/Internal mappIng
LIaIsIng wIth users: The 08A lIaIses wIth users to ensure that the data they
need Is avaIlable and to wrIte the necessary external schema. n addItIon, the
08A must also defIne the assocIated external/conceptual mappIng
CrantIng of authorIzatIon for data access: The grantIng of dIfferent types of
authorIzatIons (read, wrIte, etc.) allows the 08A to regulate whIch parts of the
database varIous users can access
0efInIng IntegrIty constraInts: The data values stored In the database must
satIsfy certaIn consIstency constraInts


FIgure 1-18: Users of 0hS

1.10. 0ata hodeIs
A data model Is a conceptual tool to descrIbe data, data relatIonshIps, data semantIcs and
consIstency constraInts.

Two of the wIdely used data models are dIscussed In the next sectIons.

1.10.1. Dbject ased LogIcaI hodeI
EntItyFelatIonshIp |odel (EF |odel) Is a wIdely known object based logIcal model. They are
used to descrIbe data at the conceptual and the vIew level.
The EF |odel Is based on the perceptIon of the real world that consIsts of a collectIon of
basIc objects called entItIes, and of relatIonshIps among these objects. The EF |odel Is
covered In detaIl In Chapter 2.

FIgure 1-1: EntIty PeIatIonshIp hodeI
1.10.2. Pecord ased LogIcaI hodeI
They are used to descrIbe data at the conceptual and the vIew level. They are used both to
specIfy the overall logIcal structure of the database and to provIde a hIgherlevel descrIptIon
of the ImplementatIon. There are three wIdely accepted record based logIcal models.

1.10.2.1. HIerarchIcaI 0ata hodeI
The hIerarchIcal data model organIzes data In a tree structure. There Is a hIerarchy of parent
and chIld data segments. ThIs structure ImplIes that a record can have repeatIng InformatIon,
generally In the chIld data segments.

0ata Is represented by a collectIon of records (record types). A record type Is the equIvalent
of a table In the relatIonal model, and wIth the IndIvIdual records beIng the equIvalent of
rows. To create lInks between these record types, the hIerarchIcal model uses parentchIld
relatIonshIps.

n a hIerarchIcal database the parentchIld relatIonshIp Is one to many. ThIs restrIcts a chIld
segment to havIng only one parent segment.

HIerarchIcal 08|Ss were popular from the late 1960s, wIth the IntroductIon of 8|'s
nformatIon |anagement System (|S) 08|S, through the 1970s.

Examle: Consder the bcnkny system. Fyure 120 shows the hercrchccl representcton o]
Customer_0etcls cnd Customer_Locn records ]rom Customer_0etcls cnd Customer_Locn
]les respectvely.

Note: Loan (Loan_No: 1011) Is shown as taken joIntly by |Ike A. SmIth and Craham S. SmIth
to explaIn the dIfference between hIerarchIcal and network |odel.

101 Smith Mike A. 1020 Savings Downtown Smith_Mike@yahoo.com
1011 8755.00
2010 2555.00 2015 2000.00
102 Smith Graham S. 2348 Checking Bridgewater Smith_Graham@rediffmail.com
ROOT
1011 8755.00
103 Langer Justin G. 3421 Savings Plainsboro Langer_Justin@yahoo.com

FIgure 1-20: HIerarchIcaI hodeI
1.10.2.2. Network 0ata hodeI
The network model permItted the modelIng of manytomany relatIonshIps In data. n 1971,
the Conference on 0ata Systems Languages (CD0ASYL) formally defIned the network model.

0ata In the network model Is represented by a collectIon of records and the relatIonshIps
among data are represented by lInks (poInters). The records In the database are organIzed as
collectIons of graphs. ExampIe: 0|S.

Examle: Re]er to Fyure 121. Assume thct locn (Locn_No:1011) s tcken ]ontly by two
customers (Mke A. Smth cnd 6rchcm S. Smth).

ln the hercrchccl model (Fyure 120), the locn n]ormcton hcs to be repected ]or ecch
customer ndvduclly beccuse t does not permt mcny to mcny relctonshp. The pcrent
chld relctonshp s one to mcny.

However n the network model, beccuse t cllows mcny to mcny relctonshp, the locn
n]ormcton s stored only once cnd both the customers ccn re]er to t.

FIgure 1-21: Network hodeI

1.10.2.3. PeIatIonaI 0ata hodeI
The relatIonal model uses a collectIon of tables (relatIons), each of whIch Is assIgned a unIque
name, to represent both data and the relatIonshIps among those data.

A table has a specIfIed number of columns but can have any number of rows. Fows stored In a
table resemble records from flat fIles. A row In a table represents a relatIonshIp among a set
of values. Fefer to FIgure 122, a row In the Customer_Loan table gIves the detaIls of a loan
taken by a customer. Examle: Customer (Cust_l0: 101) hcs tcken c locn (Locn_No: 1011) o]
cmount (Amount_n_0ollcrs: 8Z55.00)

SInce a table Is a collectIon of such relatIonshIps, there Is a close correspondence between
the concept of table and the mathematIcal concept of relatIon, from whIch the relatIonal
data model takes Its name.

101 1011 8755.00
103 2010 2555.00
104 2056 3050.00
103 2015 2000.00
Customer_Loan records from Customer_Loan table
Attributes / CoIumns / FieIds
Rows / Records / TupIes
No. of Records / Rows / TupIes:
CardinaIity of the ReIation
No. of Attributes / CoIumns / FieIds :
Degree of the ReIation
Cust_IDCust_Last_
Name
Account
_No
Account_
Type
Savings
Checking
Savings
Checking
Checking
Cust_Mid
_Name
A.
S.
G.
D.
E.
Cust_First
_Name
Mike
Graham
Justin
Jack
Simon
Customer_Detail records from Customer_Details table

FIgure 1-22: PeIatIons - Customer_Loan and Customer_0etaIIs

1.10.2.4. StructuraI TermInoIogy
1.11. P0hS
PeIatIonaI 0atabase: Any database for whIch the logIcal organIzatIon Is based on relatIonal
data model.

P0hS: A 08|S that manages the relatIonal database.

An F08|S Is a type of 08|S that stores data In the form of related tables.
Formal FelatIonal Term nformal EquIvalence

FelatIon Table
Tuple Fow or Fecord
CardInalIty of a FelatIon Number of rows
AttrIbute Column or FIeld
0egree of a FelatIon Number of Columns
PrImary Key UnIque dentIfIer
0omaIn A pool of values from whIch the values of
specIfIc attrIbutes of specIfIc relatIons are
taken

1.12. Some PopuIar P0hS packages

1.13. AppIIcatIon Areas of P0hS

0atabases are wIdely used In real lIfe applIcatIons such as:

1. AIrIInes: For reservatIons and schedule InformatIon.

2. ankIng: For customer InformatIon, accounts, loans and bankIng transactIons

J. UnIversItIes: For student InformatIon, course regIstratIons and grades.

4. TeIecommunIcatIons: For keepIng records of calls made, generatIng monthly bIlls,
maIntaInIng balances on prepaId callIng cards and storIng InformatIon about the
communIcatIon networks.

5. SaIes: For customer, product and purchase InformatIon In any Industry.

1.14. Keys
CandIdate Key: A candIdate key Is a set of one or more attrIbutes that can unIquely IdentIfy a
row In a gIven table.

Examle: Consder the Customer_0etcls tcble shown n FIgure 12J.
F08|S Package Company / CorporatIon
Dracle Dracle Corp.
Sybase Sybase nc.
nformIx nformIx Software nc.
|ySQL
082 8|
ngres Computer AssocIates nternatIonal nc.
SQL Server |Icrosoft

FIgure 1-23: Customer_0etaIIs TabIe
AssumptIons:
Dne customer ccn hcve only one cccount
Examle: As depcted n Fyure 12J, customer, Mke A. Smth hcs c Scvnys cccount wth
Account_No: 1020. Smlcrly, customer, 1ustn 6. Lcnyer hcs c Scvnys cccount wth
Account_No: J421.

An cccount ccn belony to only one customer
Examle: Account_No: 2JZ belonys to 1cck Qucls.

Two rows ccnnot hcve the scme vclues n the cttrbutes, Cust_Lcst_Ncme cnd
Cust_Frst_Ncme cttrbutes. ] two rows hcve the scme vclue ]or Cust_Lcst_Ncme,
they d]]er n ther vclues ]or Cust_Frst_Ncme

ln the Customer_0etcls tcble, there cre ]our ccnddcte Keys. Dut o] the ]our, three cre
smple ccnddcte keys cnd one s c composte ccnddcte key. They cre:

Smle Canddate Key: A ccnddcte key comprsny o] one cttrbute only.
Examle:
Account_No
Cust_l0
Cust_Emcl

Comoste Canddate Key: A ccnddcte key comprsny o] two or more cttrbutes.
Examle: [Cust_Lcst_Ncme, Cust_Frst_Ncme].
Cust_Lcst_Ncme clone s not su]]cent to dstnyush between rows n the tcble. 8ut clony
wth Cust_Frst_Ncme t ccn dstnyush between rows n the tcble. Ther combncton
consttutes c ccnddcte key.

lnvald Canddate Key: A ccnddcte key should be comprsed o] c set o] cttrbutes thct ccn
unquely dent]y c row. A subset o] the cttrbutes should not possess the unque
dent]ccton property. Examle: the combncton o] [Account_No, Account_Type] s cn
nvcld ccnddcte key. Althouyh the cttrbutes Account_No cnd Account_Type toyether ccn
dstnyush rows, ther combncton does not ]orm c ccnddcte key, snce the cttrbute
Account_No clone s c ccnddcte key.

CandIdate keys are IdentIfIed durIng the desIgn of the database.

PrImary Key: 0urIng the creatIon of the table (the ImplementatIon phase), the database
desIgner chooses one of the candIdate key from amongst the several avaIlable, to unIquely
IdentIfy rows In the Customer_0etaIls table. The candIdate key so chosen Is called the
prImary key.

Examle: The dctcbcse desyner chooses Account_No to d]]erentcte between rows n the
Customer_0etcls tcble. Account_No s the prmcry key ]or the Customer_0etcls tcble.
Re]er to Fyure 124.

EntIty IntegrIty constraInt: The prImary key of a table Is always not null and unIque. The
attrIbutes whIch constItute the prImary key cannot have duplIcate values In the rows of the
table. t Is mandatory to provIde Input for the prImary key attrIbutes. ThIs constraInt Is
referred to as the entIty IntegrIty constraInt. A null value Is an unknown value. t Is not a
blank character or a zero value.

It Is preferabIe to seIect a candIdate key wIth a mInImaI number of attrIbutes to functIon
as a prImary key.

Examle: lt s pre]ercble to select the ccnddcte key (Account_No) cs the prmcry key cs
opposed to the ccnddcte key (Cust_Lcst_Ncme, Cust_Frst_Ncme).

PoInts to Pemember:
A candIdate key Is a set of one or more attrIbutes that can unIquely
IdentIfy a row In a gIven table
There can be more than one candIdate keys In a table
CandIdate keys are IdentIfIed durIng the desIgn phase
WhIle creatIng the table, the database desIgner chooses one candIdate
key from amongst the several avaIlable, to serve as a prImary key
t Is preferred to select a candIdate key wIth a mInImal number of
attrIbutes to functIon as a prImary key

CuIdeIInes to seIect a prImary key:
CIve preference to numerIc column(s). The search algorIthm performs
better when the prImary key Is numerIc
CIve preference to a sIngle attrIbute. The search algorIthm gIves
better output wIth a sIngle attrIbute prImary key than wIth a
composIte attrIbute prImary key
CIve preference to the mInImal composIte key. A composIte key Is a
EF/CDFP/CFS/0807/002 7ersIon 1.0 Page J0
collectIon of two or more attrIbutes. Example: If the candIdate keys
are [x1,x2,xJ] and [y1,y2], the composIte key [y1,y2] Is the mInImal
composIte key and wIll therefore be chosen as the prImary key
PrImary keys are chosen accordIng to busIness convenIence

FIgure 1-24: Customer_0etaIIs TabIe wIth Account_No as PrImary Key

ForeIgn Key: A foreIgn key Is a set of attrIbute(s) the values of whIch are requIred to match
the values of a candIdate key In the same or another table. The foreIgn key attrIbute(s) can
have duplIcate or null values.

Examle: Consder the bcnkny system. The detcls o] cll the customers o] the bcnk cre
stored n the Customer_0etcls tcble. Whenever the customer mckes c trcnsccton ]or
excmple c depost or wthdrcwcl o] ]unds ]rom the bcnk, the trcnsccton s recorded n the
Customer_Trcnsccton tcble.

A trcnsccton s cllowed only ] the customer hcs cn cccount n the bcnk. The cccount
number n]ormcton s stored n the Customer_0etcls tcble. Ths n]ormcton s re]erred to
]or every trcnsccton. l] the cccount number does not exst, the trcnsccton wll not be
cllowed.


FIgure 1-25: An exampIe to demonstrate PeferentIaI IntegrIty
ln the excmple cbove, Account_No cttrbute o] Customer_Trcnsccton tcble s the ]oreyn
key re]errny to Account_No o] Customer_0etcls tcble. The foreIgn key attrIbutes can have
duplIcate values. ln the excmple cbove, Account_No 1020 occurs n two rows o] the tcble.
The foreIgn key attrIbutes can have NULL values.

The problem of ensurIng that the database does not Include any InvalId foreIgn key values Is
therefore known as the referentIal IntegrIty problem.

The constraInt that values of a gIven foreIgn key must match the values of the correspondIng
candIdate key Is known as a referentIal constraInt.

The relatIon that contaIns the foreIgn key Is the referencIng reIatIon (aIso caIIed the chIId
tabIe) and the relatIon that contaIns the correspondIng candIdate key Is the referenced
reIatIon (aIso caIIed the parent tabIe).

InvaIId foreIgn key vaIue: A value of 1050 In the Account_No attrIbute of
Customer_TransactIon table Is InvalId because a value of 1050 Is not present In the
Account_No attrIbute of the Customer_0etaIls table.

SeIf PeferencIng: A table mIght Include a foreIgn key, the values of whIch are requIred to
match the value of a candIdate key In the same table. ThIs Is known as self referencIng.


FIgure 1-26: An exampIe of SeIf PeferencIng
As ccn be seen ]rom Fyure 12, ecch employee belonys to c depcrtment. Ecch depcrtment
hcs c mcncyer. For excmple Cndy S. Atherton, Henry A. 6eorye cnd Mctt 6. 1cckson cre the
mcncyers o] the HR, Fncnce cnd 0esyn depcrtment respectvely. A N0LL vclue mecns cn
unknown vclue or ncpplccble vclue. lt does not mecn c blcnk vclue or zero.

All employees ncludny the mcncyer hcve c unque Employee_l0. The Mcncyer_l0 cttrbute
o] the Employee_Mcncyer tcble ccn only hcve cny exstny vclue ]rom the Employee_l0
cttrbute. Mcncyer_l0 s there]ore the ]oreyn key re]erencny the ccnddcte key,
Employee_l0.

Examle: Assume thct the employees n the orycnzcton hcve to undertcke c course. 0etcls
o] the courses cre cvclcble n the tcble Course_0escrpton cs shown n Fyure 12Z. Some
courses hcve c prerequste, ]or excmple cn employee must yo throuyh the Computer
Hcrdwcre cnd System So]twcre Concepts course be]ore tckny up the Proyrcmmny
Fundcmentcls course. Here, the cttrbute Prerequste, s the ]oreyn key re]erencny the
ccnddcte key, Course_l0.

FIgure 1-27: Another ExampIe of SeIf PeferencIng TabIe

EF/CDFP/CFS/0807/002 7ersIon 1.0 Page JJ
Super Key: Any superset of a candIdate key Is a super key.
Examle: Consder the ]ollowny sets comprsny o] cttrbutes ]rom the Customer_0etcls
tcble.
[Account_No]
[Account_No, Account_Type]
[Account_No, Account_Type, 8cnk_8rcnch]

[Account_No] s c ccnddcte key ]or the Customer_0etcls tcble. [Account_No, Account_Type]
s c superset o] [Account_No] cnd there]ore t s c super key ]or the Customer_0etcls tcble.
Scme s the ccse ]or the set [Account_No, Account_Type, 8cnk_8rcnch].

A super key may have unnecessary attrIbute(s).

Although the combInatIon of [Account_No, Account_Type] Is a super key but [Account_Type]
Is an unnecessary attrIbute as [Account_No] Is suffIcIent to unIquely dIstInguIsh between rows
In the Customer_0etaIls table.

Non-Key AttrIbutes: The attrIbutes other than the prImary key attrIbutes In a table/relatIon
are called nonkey attrIbutes.
Examle: Cust_Lcst_Ncme, Cust_Md_Ncme, Cust_Frst_Ncme, 8cnk_8rcnch, etc. cre non
key cttrbutes n the Customer_0etcls tcble.

PoInts to Pemember:
A foreIgn key Is a set of attrIbutes of a table, the values of whIch are
requIred to match values of some candIdate key In the same or another
table
The constraInt that values of a gIven foreIgn key must match the
values of the correspondIng candIdate key Is known as referentIal
constraInt
A table whIch has a foreIgn key referrIng to Its own candIdate key Is
known as selfreferencIng table
The foreIgn key attrIbute(s) can have duplIcate or null values
Any superset of a candIdate key Is a super key
The attrIbutes other than the prImary key attrIbutes In a table/relatIon
are called nonkey attrIbutes

1.15. Summary
A database Is an organIzed collectIon of Interrelated data
0ata In the database:
s Integrated
Can be shared
Can be concurrently accessed
The database systems are desIgned to:
0efIne structures for the storage of data
ProvIde mechanIsms for the manIpulatIon of data
Ensure the safety of the data stored, despIte system crashes or attempts at
unauthorIzed access
A master fIIe
Stores relatIvely statIc data about an entIty
Changes rarely
A transactIon fIIe
Stores relatIvely transIent data about a partIcular data processIng task
Changes frequently as transactIons happen more perIodIcally and In large
numbers
0Isadvantages of the tradItIonaI fIIe approach:
0ata securIty
0ata redundancy
0ata IsolatIon
Program / data dependence
Lack of flexIbIlIty
Concurrent access anomalIes
0hS ensures the foIIowIng:
0ata Independence
Allows for sharIng of data among the dIfferent users
Allows concurrent access to the database
Controls redundancy and InconsIstency
ProvIdes a secure access to the database
Enforces IntegrIty constraInts by preventIng the entry of InvalId InformatIon
Into the database
Enables backup and recovery from system crashes
CentraIIzed 0atabase: All data Is located at a sIngle sIte
0IstrIbuted 0atabase: The database Is stored on several computers
Three IeveI archItecture for a 0hS
ExternaIlVIew LeveI: Enables users to vIew/access only a part of the database
ConceptuaIlLogIcaI IeveI: 0escrIbes what data Is stored In the database and
what relatIonshIps exIst among those data
InternaIlPhysIcaI IeveI: 0escrIbes the data storage and access methods
0hS Users:
End Users: Works at the external level and generally makes updates to the
database or executes querIes on the database
AppIIcatIon Programmer: WrItes applIcatIon programs
0atabase AdmInIstrator: 0efInes the conceptual, Internal and external
schema, control access prIvIleges to/from users and ensures the consIstency of
the database
0ata hodeIs: s a conceptual tool whIch can be used to descrIbe data, data
relatIonshIps, data semantIcs and consIstency constraInts
Dbject ased LogIcaI hodeI: EF |odel
Pecord ased LogIcaI hodeI:
HIerarchIcaI 0ata hodeI: |S
Network hodeI: 0|S
PeIatIonaI 0ata hodeI: FelatIonal data model uses a collectIon of tables
(relatIons) to represent data and the relatIonshIps among those data.
Examle: Dracle, Sybase
PeIatIonaI 0atabase: Any database for whIch the logIcal organIzatIon Is based on
relatIonal data model
P0hS: A 08|S that manages the relatIonal database
Keys:
A candIdate key Is a set of one or more attrIbutes that can unIquely IdentIfy a
row In a gIven table
A table can have multIple candIdate keys
CandIdate keys are IdentIfIed durIng the desIgn phase
WhIle creatIng tables the database desIgner chooses one candIdate key from
amongst the several avaIlable, to serve as a prImary key
t Is preferable to select a candIdate key wIth a mInImal number of attrIbutes
to functIon as a prImary key In the table
A foreIgn key Is a set of attrIbute(s) of a table, the values of whIch are requIred
to match the values of a candIdate key In the same table or In a dIfferent table
The constraInt that values of a gIven foreIgn key must match the values of the
correspondIng candIdate key Is known as referentIal IntegrIty constraInt
A table whIch has a foreIgn key referrIng to Its own candIdate key Is known as
selfreferencIng table
Any superset of a candIdate key Is a super key
The attrIbutes other than the prImary key attrIbutes In a table/relatIon are
called nonkey attrIbutes

2. EntIty-PeIatIonshIp (E-P) hodeIIng
"A pIcture Is worth a thousand words"
Anonymous
2.1. IntroductIon
Cenerally the busIness scenarIos are complex In nature. A so]twcre cpplccton desyner
21

who Is not an expert In a partIcular busIness domaIn may faIl to capture the exact busIness
requIrement to buIld a software applIcatIon. ThIs Is one of the promInent causes of software
project faIlure. FIgure 21 explaIns how mIscommunIcatIons between dIfferent users could
create chaos In software development projects.

FIgure 2-1: Effect of mIscommunIcatIons In Software 0eveIopment

21
Software appIIcatIon desIgner: The person who desIgns software applIcatIons.
FevIewIng of requrement spec]ccton
22
document wIth the busness users
2J
(who are experts
In theIr respectIve busIness domaIns) wIll not yIeld the expected results because of the
followIng reasons:

The applIcatIon desIgner usually wrItes the requIrement specIfIcatIon documents usIng
software technology ]cryons
24
whIch are dIffIcult to understand by the busIness users

Usually these documents are quIte lengthy and the busIness users wIll not be able to
devote enough tIme to read and revIew the complete document

t Is always better to represents all the busness rules
25
In pIctorIal format so that the busIness
users can understand and revIew the busIness rules easIly and correctly.

Dne such technIque, whIch Is commonly used for desIgnIng of the databases, Is EntIty-
PeIatIonshIp hodeIIng (E-P hodeIIng). The dIagram used In thIs technIque Is called EntIty
PeIatIonshIp 0Iagram (EP0).

n nfosys, 60X to 70X of projects use thIs technIque to capture the requIrement specIfIcatIon
for the database applIcatIon desIgn and development.

EntIty FelatIonshIp 0Iagram (EF0) was fIrst defIned In 1976 by Peter Chen. SInce then Charles
8achman and James |artIn have added some small refInements to the basIc EF0 prIncIples.
0ue to Its sImplIcIty and ease of use, thIs technIque attracted consIderable attentIon durIng
early 1990's In both Industry and research communIty.
2.2. EntIty and PeIatIonshIp
8efore learnIng EF dIagrams technIque In detaIl let us understand EntIty and PeIatIonshIp.

EntIty
EntIty Is a common word anythIng real or cbstrcct
2
, about whIch we
want to store data. EntIty types fall Into fIve categorIes: roles, events,
locatIons, tcnyble
27
thIngs or concepts.

Some examples of entItIes are employee, hockey match, campus, book
and department. 0epartment Is an entIty, and EducatIon E Fesearch,
HF, FInance, etc., are nstcnces
28
of the department entIty.

22
PequIrement specIfIcatIon: A document whIch contaIns requIrement for a specIfIc applIcatIon.
2J
usIness users: The users who owns the applIcatIon.
24
Jargons: The specIalIzed or technIcal language of a trade, professIon, or sImIlar group.
25
usIness ruIes: The rules/polIcIes whIch govern the functIonIng of the applIcatIon.
26
Abstract: Conceptual/theoretIcal object.
27
TangIbIe: PhysIcal object.
28
Instance: Dccurrence.

SImIlarly Henry, Luther, Crystal, Jane etc., are Instances of employee entIty.

AttrIbute
An attrIbute Is a characterIstIc property of an entIty. An entIty could have multIple
attrIbutes.

Examle: For cn entty ccr, the cttrbutes would be the color, model number, number o]
doors, ryht or le]t hcnd drve etc.

PeIatIonshIp
FelatIonshIp Is a natural assocIatIon that exIsts between one or more entItIes.

Examle: Employee borrows books ]rom the lbrcry.
2.3. CardInaIIty of a reIatIonshIp
CardInalIty of relatIonshIp defInes the type of relatIonshIp between two partIcIpatIng entItIes.

Examle: Dne employee ccn tcke many books ]rom lbrcry. Dne book ccn be tcken by only
one employee. Ccrdnclty o] relctonshp between employee cnd book s "one to many".

Dne person ccn st on only one chcr ct cny pont o] tme. Dne chcr ccn cccommodcte only
one person n c yven pont o] tme. Ths relctonshp hcs "one to one" ccrdnclty.

PoInts to Pemember:
CardInalIty of relatIonshIp Is dIfferent from cardInalIty of FelatIon (CardInalIty
of relatIon was dIscussed In chapter one whIch refers to number of rows In
gIven relatIon).
There are four types of cardInalIty relatIonshIp.
2.3.1. Dne to Dne PeIatIonshIp
n thIs relatIonshIp, one Instance of entIty Is related to another Instance of the entIty. 8oth
partIcIpatIng entItIes have a one to one relatIonshIp.

Examle1: Dne person (P1,P2,PJ,P4) ccn st on only one chcr ct cny pont o] tme. And clso
one chcr (C1,C2,CJ,C4) ccn cccommodcte c mcxmum o] one person ct cny yven tme. ln
ths relctonshp both the pcrtcpctny enttes hcve onetoone relctonshp.

P1
P2
P3
P4
C1
C2
C3
C4
P1
P2
P3
P4
C1
C2
C3
C4

FIgure 2-2 : Dne to Dne PeIatIonshIp
Examle2: Dne country ccn hcve only one ctzen cs ts presdent cnd one ctzen ccn
become presdent o] only one country.
2.3.2. Dne to hany PeIatIonshIp
Dne Instance of entIty Is related to multIple Instance of another entIty.
Examle1: 0ne orycnzcton (D1, D2, DJ) ccn hcve many employees but one employee (E1,
E2, EJ, E4, E5) ccn work only jor one orycnzcton.

O1
O2
O3
E1
E2
E3
E4
E5
O1
O2
O3
E1
E2
E3
E4
E5

FIgure 2-3 : Dne to hany PeIatIonshIp
Examle2: 0ne wcrehouse (W1, W2, WJ) ccn be used to store many pcrts but one pcrt
(P1,P2,PJ.) ccn be stored only n one wcrehouse. ln ths excmple one nstcnce o] wcrehouse
cccommodctes many pcrts. Hence the relctonshp between wcrehouse cnd pcrt s one-to-
many

W1
W2
W3
P1
P2
P3
P4
P5
W1
W2
W3
P1
P2
P3
P4
P5

FIgure 2-4 : Another exampIe of Dne to hany PeIatIonshIp

2.3.3. hany to Dne PeIatIonshIp
ThIs Is the reverse of the one to many relatIonshIp.
Examle: Mcny employees (E1, E2, EJ.) ccn work ]or only one depcrtment but one
depcrtment (01, 02, 0J) ccn hcve mcny employees. The relctonshp between employee cnd
depcrtment s many to one.

D1
D2
D3
E1
E2
E3
E4
E5
D1
D2
D3
E1
E2
E3
E4
E5

FIgure 2-5 : hany to Dne PeIatIonshIp
2.3.4. hany to hany PeIatIonshIp
n thIs many to many relatIonshIp multIple Instances of one EntIty are related to multIple
Instances of another EntIty.
Examle1: Dne student (S1, S2, SJ, S4) s enrolled ]or many courses (C1, C2, CJ, C4) cnd one
course s enrolled by many students.

S1
S2
S3
S4
C1
C2
C3
C4
S1
S2
S3
S4
C1
C2
C3
C4

FIgure 2-6: hany to hany PeIatIonshIp
Examle2: Dne student(S1,S2,SJ,S4) trcned by many nstructors (l1,l2,lJ,l4) cnd one
nstructor trcns many students.

S1
S2
S3
S4
I1
I2
I3
I4
S1
S2
S3
S4
I1
I2
I3
I4

FIgure 2-7 : Another exampIe of hany to hany PeIatIonshIp
|any to many relatIonshIp Is superset of all the above mentIoned relatIonshIps. All other
relatIonshIps are specIal case of many to many relatIonshIps.

2.4. E-P 0Iagram NotatIons

EntIty
An entIty Is an object or concept about whIch busIness
user wants to store InformatIon.

Entity

Weak entIty
A weak entIty Is dependent on another entIty to exIst.
Example bank branch depends upon bank name for Its
exIstence. WIthout bank name It Is ImpossIble to IdentIfy
bank branch unIquely.

AttrIbutes
AttrIbutes are the propertIes or characterIstIcs of an
entIty.

Key attrIbute
A key attrIbute Is the unIque, dIstInguIshIng characterIstIc
of the entIty. For example, an employee's employee
number mIght be the employee's key attrIbute.

huItIvaIued attrIbute
A multIvalued attrIbute can have more than one value.
For example, an employee entIty can have multIple skIll
values.

0erIved attrIbute
A derIved attrIbute Is based on another attrIbute. For
example, an employee's monthly salary Is based on the
employee's basIc salary and house rent allowance.

PeIatIonshIps
FelatIonshIps Illustrate how two entItIes share
InformatIon In the database structure.

Customer
Account Transaction
N
1
1
M

CardInaIIty
CardInalIty specIfIes how many Instances of an entIty
relate to one Instance of another entIty. h,N both
represent 'hANY' and 1 represents 'DNE' cardInalIty

PecursIve reIatIonshIp
n some cases, entItIes can be selflInked. For example,
employees can supervIse other employees
FIgure 2-8 : E-P 0Iagram NotatIons
2.5. hodeIIng usIng E-P 0Iagrams
A model
29
Is an abstract form of any system or process that hIdes the unnecessary detaIls,
whIle hIghlIghtIng those detaIls Important to the applIcatIon. We
have notIced the model of huge campuses or buIldIngs whIch
help to vIsualIze the structure, before they are buIlt. Dn sImIlar
lInes, we can also model our software applIcatIons before they
are developed. ThIs wIll help the busIness users to vIsualIze the
applIcatIon before It Is developed and suggest changes, If It Is
not as per theIr requIrement.

|odelIng the databases usIng EF dIagrams Is called as EF |odelIng. ThIs technIque Is also
called as Top-0own approach, because one need not IdentIfy all the attrIbutes to model the
system usIng thIs technIque.
2.5.1. Steps In E-P hodeIIng
Usually the followIng sIx steps are followed to generate EF |odels.

29
hodeI: A representatIon or a scaled down structure of an object.
a) IdentIfy the entItIes: Look for general nouns In requIrement specIfIcatIon document
whIch are of busIness Interest to busIness users
b) FInd reIatIonshIps: dentIfy the natural relatIonshIp and theIr cardInalItIes between
the entItIes
c) IdentIfy the key attrIbutes for every entIty: dentIfy the attrIbute or set of
attrIbutes whIch can IdentIfy Instance of entIty unIquely
d) IdentIfy other reIevant attrIbutes: dentIfy other attrIbutes whIch are Interest to
busIness users and want to store the InformatIon In database
e) CompIete E-P dIagram: 0raw complete EF dIagram wIth all attrIbutes IncludIng
prImary key
f) PevIew your resuIts wIth your busIness users Look at the lIst of attrIbutes
assocIated wIth each entIty to see If anythIng has been omItted.

Note that whIle thIs Is an terctve
J0
approach and one cannot come to a fInal EF model In a
sIngle step. t requIres a great deal of patIence and numerous revIsIons before the model Is
created.
2.6. Case Study 1: ProbIem Statement
Let us apply the above methodology to model, UnIversIty
database appIIcatIon.
An unIversIty has many departments
Each department has multIple Instructors; one among them
Is the head of the department
An Instructor belongs to only one department
Each department offers multIple courses, each of whIch Is
taught by a sIngle Instructor
A student may enroll for many courses offered by dIfferent departments
2.6.1. Case Study 1: SoIutIon
Step 1: IdentIfy the EntItIes
Cenerally the entItIes wIll have multIple Instances In a gIven busIness scenarIo. As per thIs
guIdelIne, we can IdentIfy the followIng entItIes:
1. 0EPAFT|ENT
2. CDUFSE
J. NSTFUCTDF
4. STU0ENT
"Head of the department" Is NDT an EntIty. t Is a relatIonshIp between the nstructor and
department entItIes.

J0
IteratIve: Process of repeatIng the same task.

Note: Dne may be tempted to IdentIfy "unIversIty" as an entIty, but
It Is a false entIty because It has only one Instance.

Step 2: FInd reIatIonshIps
We can derIve the followIng relatIonshIps:
1. The department offers multIple courses and each course belongs to only one
department, hence cardInalIty between department and course Is one to many.

2. Dne course Is enrolled by multIple students and one student enrolls for multIple
courses, hence the relatIonshIp Is many to many.

J. Dne department has multIple Instructors and one Instructor belongs to one and only
one department, hence the relatIonshIp Is one to many.

4. Each department has one "Head of 0epartment" and one nstructor Is "Head of
0epartment" for only one department, hence the relatIonshIp Is one to one.

5. Dne course Is taught by only one Instructor but one Instructor teaches many courses,
hence the relatIonshIp between course and Instructor Is many to one.

The relatIonshIp between Instructor and student need NDT be defIned for followIng
reasons:
1. There Is no busIness sIgnIfIcance In thIs relatIonshIp.
2. We can always derIve thIs relatIonshIp IndIrectly through course and Instructor, and
course and students.

Step 3: IdentIfy the key attrIbutes
1. 0Name (0epartment Name) whIch IdentIfIes the department unIquely wIll be the key
attrIbute for "0EPAFT|ENT" entIty.
2. STU0ENT# (Student Number) Is the key attrIbute for "STU0ENT" entIty.
J. Name (nstructor Name) Is the key attrIbute for "NSTFUCTDF" entIty.
4. CDUFSE# (Course Number) Is the key attrIbute for CDUFSE entIty.

Step 4: IdentIfy other reIevant attrIbutes
1. For the "0epartment" entIty, the relevant attrIbute other than "0epartment Name" Is
"LocatIon".
2. For the "Course" entIty, the relevant attrIbutes other than "Course Number" are
"Course Name", "0uratIon" and "Pre FequIsIte".
J. For the "nstructor" entIty, the relevant attrIbutes other than "nstructor Name" are
"Foom Number" and "Telephone Number".
4. For the "Student" entIty, the relevant attrIbutes other than "Student Number" are
"Student Name" and "0ate of 8Irth".

Step 5: CompIete E-P dIagram
After consIderIng all the above mentIoned guIdelInes one can generate the EF |odel for the
unIversIty database as shown In FIgure 29.


FIgure 2- : E-P 0Iagram for UnIversIty
Let us consIder a unIversIty lIbrary scenarIo for developIng the EF model.

Assume In a unIversIty
There are multIple lIbrarIes and each lIbrary has multIple student members
Students can become members to multIple lIbrarIes by payIng approprIate membershIp
fee
Each lIbrary has Its own set of books. WIthIn the lIbrary these books are IdentIfIed by a
unIque number
Students can borrow multIple books from subscrIbed lIbrary
Students can order books usIng InterlIbrary loan. ThIs can be useful If a student
wIshes to borrow books from a lIbrary where s/he Is not a member. The student orders
the books through a lIbrary where s/he Is a member
Step 1: IdentIfy the entItIes
1. L8FAFY
2. 8DDK
J. STU0ENT

n thIs busIness scenarIo 8DDK Is a weak entIty because wIthout knowIng the lIbrary detaIls,
book cannot be IdentIfIed Independently. 8ook Is always assocIated wIth Its lIbrary.

Step 2: FInd PeIatIonshIps
1. Dne lIbrary has many member students and each student can become member of many
lIbrarIes, hence the cardInalIty between lIbrary and student Is many to many.
2. Dne book belongs to only one lIbrary and one lIbrary can have multIple books, hence
cardInalIty between lIbrary and book Is one to many.
J. Dne lIbrary can loan multIple books and each book can be loaned to only one lIbrary,
hence the cardInalIty between lIbrary and book Is one to many.
4. Dne student can borrow multIple books and one book can be borrowed by only one
student, hence the cardInalIty between student and book Is many to one.

1. LIbrary# (lIbrary 0) Is the key attrIbute for the entIty "LIbrary", as It IdentIfIes the
lIbrary unIquely.
2. 8ook# (book 0) and LIbrary# are together key attrIbutes for "8ook" entIty.
J. Student# (student number) Is the key attrIbute for "Student" entIty.

1. For the "LIbrary" entIty, the relevant attrIbutes other than "LIbrary#" would be
"LIbrary Name" and "LocatIon".
2. For the "8ook" entIty, the relevant attrIbutes other than "8ook#" would be "TItle"
and "S8N".
J. For the "Student" entIty, the relevant attrIbute other than "Student#" would be
"Student Name" and "0ate of 8Irth".

After consIderIng all the above mentIoned guIdelInes, one can generate the EF |odel for
above mentIoned unIversIty lIbrary busIness scenarIo as shown In FIgure 210.

Library
Student
Book# ISBN Date of Birth
Student#
Location Library#
Subscribed
by
Borrows
Has Loans
M
1
1
N M N
1 M
TitIe
Student
Name
Book
Library
Name

FIgure 2-10: E-P 0Iagram for UnIversIty LIbrary

Let us consIder a bankIng busIness scenarIo for developIng the EF
model.

Assume In a cIty
There are multIple banks and each bank has many branches.
Each branch has multIple customers
Customers have varIous types of accounts
Some customers also had taken dIfferent types of loans from these bank branches
Dne customer can have multIple accounts and loans
Step 1: IdentIfy the entItIes
1. 8ANK
2. 8FANCH
J. LDAN
4. ACCDUNT
5. CUSTD|EF

8FANCH Is consIdered a weak entIty because wIthout knowIng the 8ANK, we cannot defIne the
8FANCH Independently. 8FANCH Is always assocIated wIth Its 8ANK name.
Excmple: Ct bcnk 8rcnch, lClCl 8cnk 8rcnch, Wells Fcryo 8rcnch or Stcte 8cnk o] lndc
brcnch.

Note: Dne may be tempted to IdentIfy "CIty" as an entIty, but It Is a
false entIty because It has only one Instance.

Step 2: FInd PeIatIonshIps
1. Dne bank has many branches and each branch belongs to only one bank, hence the
cardInalIty between bank and branch Is one to many.
2. Dne branch offers many loans and each loan Is assocIated wIth one branch, hence the
cardInalIty between branch and loan Is one to many.
J. Dne branch maIntaIns multIple accounts and each account Is assocIated to one and
only one branch, hence the cardInalIty between branch and account Is one to many.
4. Dne Loan can be avaIled by multIple customers, and each customer can avaIl multIple
loans, hence the cardInalIty between loan and customer Is many to many.
5. Dne customer can hold multIple accounts, and each account can be held by multIple
customers, hence the cardInalIty between customer and account Is many to many.

1. 8ankCode (8ank Code) Is the key attrIbute for the entIty "8ank", as It IdentIfIes the
bank unIquely.
2. 8ranch# (8ranch Number) and 8ankCode (8ank Code) are together key attrIbutes for
"8ranch" entIty.
J. Customer# (Customer Number) Is the key attrIbute for "Customer" entIty.
4. Loan# (Loan Number) Is the key attrIbute for "Loan" entIty.
5. Account# (Account Number) Is the key attrIbute for "Account" entIty.

1. For the "8ank" entIty, the relevant attrIbutes other than "8ankCode" would be
"Name" and "Address".
2. For the "8ranch" entIty, the relevant attrIbutes other than "8ranch#" would be
"Name" and "Address".
J. For the "Loan" entIty, the relevant attrIbute other than "Loan#" would be "Loan
Type".
4. For the "Account" entIty, the relevant attrIbute other than "Account#" would be
"Account Type".
5. For the "Customer" entIty, the relevant attrIbutes other than "Customer#" would be
"Name", "Phone" and "Address".

After consIderIng all the above mentIoned guIdelInes, one can generate the EF |odel for
above mentIoned bankIng busIness scenarIo as shown In FIgure 211.


FIgure 2-11 : E-P 0Iagram for ank

2.. TransformIng an E-P hodeI Into PhysIcaI 0atabase 0esIgn
EF model helps maInly In capturIng and analyzIng the requIrements. t can also be used
durIng the desIgn of the physIcal database. The followIng Is a set of guIdelInes for convertIng
an EF model Into a physIcal database desIgn.

1. Each entIty represented In the EF model can be defIned as a table In the relatIonal
schema. All attrIbutes of the entIty wIll become columns of the table. As per thIs
guIdelIne we can translate 8ANK, 8FANCH, LDAN, ACCDUNT and CUSTD|EF entItIes to
followIng tables. AddItIonal columns can be added to the below tables as per the
busIness requIrements at the later stage.

BANK BRANCH
BankCode Name Address BankCode Branch# Name Address

LOAN ACCOUNT
Loan# LoanType Account# AccountType

CUSTOMER
Customer# Name Telephone# Address

FIgure 2-12 : EntIty based tabIes
Weak entIty types are converted Into a table of theIr own, wIth the prImary key of the
strong entIty actIng as a foreIgn key In the table. ThIs foreIgn key along wIth the key
of the weak entIty form the composIte prImary key of thIs table. As per thIs guIdelIne,
a "8ranch" table Is created wIth the above mentIoned structure, wIth 8ankCode and
8ranch# together as composIte prImary key.

2. Each relatIonshIp can be defIned as separate table In relatIonal schema. Key attrIbutes
of pcrtcpctny enttes
J1
wIll become key attrIbute of the relatIonshIp. As per thIs

J1
PartIcIpatIng entItIes: The entItIes whIch are joIned by the relatIon.
guIdelIne we can defIne LDAN_DFFEFNC_0ETALS table between 8FANCH and LDAN
entItIes, 8FANCH_ACCDUNT_0ETALS between 8FANCH and ACCDUNT entItIes,
LDAN_0ETALS table between LDAN and CUSTD|EF entItIes, ACCDUNT_0ETALS tables
between ACCDUNT and CUSTD|EF entItIes. 8ANK and 8FANCH relatIonshIp table Is not
defIned because thIs InformatIon Is already captured In 8FANCH table. Usually
relatIonshIp based tables wIll have theIr own attrIbutes In addItIon to prIme attrIbutes
of partIcIpatIng entItIes. For example, LDAN_0ETALS table contaIn prIme attrIbutes
from LDAN and CUSTD|EF table ( whIch together act as composIte prImary key) In
addItIon to other attrIbutes such as 0ateofSanctIon, ntFate, LoanAmount, 0uratIon
etc.

LOAN_OFFERING_DETAILS BRANCH_ACCOUNT_DETAILS
BankCode Branch# Loan# BankCode Branch# Account#

LOAN_DETAILS
Loan# Customer#
Dateof
Sanction ntRate LoanAmount Duration

ACCOUNT_DETAILS
Account# Customer# DateofOpen

FIgure 2-13 : PeIatIonshIp based tabIes

Note: At thIs stage entItIes and relatIonshIps are converted to tables
hence table does not have any data.

Actual database table desIgns are drIven by busIness requIrements.
The prIncIples of data base desIgn from EF0 mIght be subjected to
small changes dependIng on the requIrements. We wIll be exposed to
these detaIls once we get a real lIfe project experIence. Some of the
aspects we mIght have to keep In mInd are:

n one to one and one to many cases, we may not always have
separate tables for the partIcIpatIng entItIes and theIr
relatIonshIp. Dne combIned table for both the partIcIpatIng
entItIes and related attrIbutes of relatIonshIp may be
suffIcIent
n a many to many relatIonshIp, It Is mandatory to create
separate tables for partIcIpatIng entItIes and relatIonshIps. For
example, entItIes and relatIonshIp defIned In FIgure 2 11,
CUSTD|EF and LDAN entItIes have a many to many
relatIonshIp. Hence one should create separate tables for
CUSTD|EF, LDANS and LDAN_0ETALS. Here LDAN_0ETALS
refers to relatIonshIp table

2.10. herIts and 0emerIts of E-P hodeIIng
The followIng sectIons dIscuss the merIt and demerIts of EF modelIng.
2.10.1. herIts of E-P hodeIIng
1. Easy to understand. Fepresented In busIness users language. Can be understood by
nontechnIcal specIalIst.
2. lntutve
J2
and helps In physIcal database creatIon.
J. Can be generalIzed and specIalIzed based on needs.
4. Can help In database desIgn.
5. CIves a hIgher level abstractIon of the system.
2.10.2. 0emerIts of E-P hodeIIng
1. PhysIcal desIgn derIved from EF |odel may have some amount of ambIguItIes or
InconsIstency.
2. SometIme dIagrams may lead to mIsInterpretatIons.
Examle:

J2
IntuItIve: Natural.
ln c recl stucton, there could be severcl types o] borrowny, ]or excmple lony term, normcl
cnd short term. lt s not mmedctely clecr whether the cbove dcyrcm represents cll or
some o] these only. l] ths cspect s not clcr]ed, then people could come to c wrony
concluson. 6vny proper descrpton o] the relctonshp s extremely mportcnt ]or ensurny
better understcndny.

n the followIng set of fIgures, the relatIonshIp Is descrIbed clearly to overcome
mIsInterpretatIon.

2.11. SUhhAPY
|ost of the applIcatIon errors are because of mIscommunIcatIon between the
applIcatIon user and the desIgner and between the desIgner and the developer.
t Is always better to represent busIness fIndIngs In terms of pIcture to avoId
mIscommunIcatIon
t Is practIcally ImpossIble to revIew the complete requIrement document by busIness
users
An EF dIagram Is one of the many ways to represent busIness fIndIngs In pIctorIal
format
Four types of cardInalIty of relatIonshIps are
a. one to one
b. one to many
c. many to one
d. many to many
EF |odelIng wIll also help the database desIgn
EF modelIng has some amount of InconsIstency and anomalIes assocIated wIth It

3. NormaIIzatIon
"No human InvestIgatIon can be called real scIence If It can not be demonstrated
mathematIcally." Leonardo da 7IncI
3.1. IntroductIon
Usually In the software Industry desIgners use EF modelIng as a requIrement analysIs tool.
0atabase desIgn usIng EF dIagram Is a byproduct.
0atabase desIgned based on the EF model may have some amount of InconsIstency,
cmbyuty
JJ
and redundancy. To resolve these Issues some amount of refInement Is requIred.
ThIs refInement process Is called as NormaIIzatIon.

As normalIzatIon Involves buIldIng structures (lIke table/tables), startIng from the stage of
IdentIfyIng the columns (attrIbutes) assocIated In the table, It Is also called "ottom-Up"
approach.
ThIs normalIzatIon technIque Is based on a strong mathematIcal foundatIon.

8asIcally normalIzatIon elImInates the duplIcate data and makes Insert, update and delete
operatIons much more effIcIent In terms of performance and space requIrement to store the
data.

n nfosys, almost all the database desIgns are InItIally based on EF modelIng and later
refIned usIng normalIzatIon technIques before they are physIcally created.
3.2. The need for NormaIIzatIon
ConsIder a unIversIty scenarIo, where In the data assocIated wIth the students, courses and
theIr results are maIntaIned In a table called "Student_Course_Fesult".
Student_Course_ResuIt TabIe
Student_DetaiIs Course_DetaiIs ResuIt_DetaiIs
101 Davis 11/4/1986 M4 AppIied Mathematics Basic Mathematics 7 11/11/2004 82 A
102 DanieI 11/6/1987 M4 AppIied Mathematics Basic Mathematics 7 11/11/2004 62 C
101 Davis 11/4/1986 H6 American History 4 11/22/2004 79 B
103 Sandra 10/2/1988 C3 Bio Chemistry Basic Chemistry 11 11/16/2004 65 B
104 EveIyn 2/22/1986 B3 Botany 8 11/26/2004 77 B
102 DanieI 11/6/1987 P3 NucIear Physics Basic Physics 13 11/12/2004 68 B
105 Susan 8/31/1985 P3 NucIear Physics Basic Physics 13 11/12/2004 89 A
103 Sandra 10/2/1988 B4 ZooIogy 5 11/27/2004 54 D
105 Susan 8/31/1985 H6 American History 4 11/22/2004 87 A
104 EveIyn 2/22/1986 M4 AppIied Mathematics Basic Mathematics 7 11/11/2004 65 B
FIgure 3-1: 0ata fIIe In tabIe format

JJ
AmbIguIty: UncertaInty.
f we observe the table shown In FIgure J1 closely, we would fInd that the table has many
cnomcles
J4
. They are:

Insert AnomaIy
n some cases, nsertIon of new data Is dIffIcult.
Examle: We ccnnot nsert prospectve course whch does not hcve cny reystered student or
we ccn not nsert student detcls who s yet to reyster ]or cny course.
Update AnomaIy
n some cases, UpdatIon of exIstIng data Is dIffIcult.
Examle: l] we wcnt to updcte the course M4's ncme we need to do ths opercton three
tmes. Smlcrly we mcy hcve to updcte student 10J's ncme twce ] t chcnyes.
0eIete AnomaIy
n some cases, deletIon of exIstIng data Is not possIble.
Examle: l] we wcnt to delete c course M4, n cddton to M4 course detcls, other crtccl
detcls o] student clso wll be deleted. Ths knd o] deleton s hcrm]ul to busness.
Moreover, M4 cppecrs thrce n cbove tcble cnd needs to be deleted thrce.
0upIIcate 0ata
The table has lots of duplIcate data.
Examle: Course M4's dctc s stored thrce cnd student 102's dctc stored twce. Ths
redundcncy wll ncrecse cs the number o] course o]]erny cnd students ncrecses.

Hence we need to refIne our desIgn so that we make an effIcIent database In terms of storage
space and nserts, Updates and 0eletes operatIons. ThIs refInIng technIque Is called as
normalIzatIon.

3.3. Process of NormaIIzatIon
As mentIoned prevIously, normalIzatIon technIque Is based on strong mathematIcal
foundatIon.

8asIcally In software Industry four normal forms are used to desIgn the database.

8efore gettIng to know the normalIzatIon technIques In detaIl, let us defIne a few buIldIng
blocks whIch are used to defIne normal forms.
3.3.1. 0etermInant
AttrIbute X can be defIned as determInant If It unIquely defInes the attrIbute value Y In a
gIven relatIonshIp or entIty. To qualIfy as determInant attrIbute need NDT be a key attrIbute.
Usually dependency of an attrIbute Is represented as X Y, whIch means attrIbute X decIdes
attrIbute Y.

J4
AnomaIIes: rregularItIes.

Examle: ln RES0LT relcton, Mcrks cttrbute mcy decde the yrcde cttrbute. Ths s
represented cs Mcrks 6rcde cnd recd cs Mcrks decdes 6rcde.

FIgure 3-2: 0etermInant
n the FESULT relatIon, |arks attrIbute Is not a key attrIbute. Hence It can be concluded that
key attrIbutes are determInants but not all the determInants are key attrIbutes.
3.3.2. FunctIonaI 0ependency
ConsIder the followIng FelatIon
FEPDFT (Student#,Course#, CourseName, Name, Foom#, |arks, Crade)
Where:
Student# Student Number
Course# Course Number
CourseName Course Name
Name Name of the Instructor who delIvered the course
Foom# Foom number whIch Is assIgned to respectIve Instructor
|arks Scored In course Course# by student Student#
Crade DbtaIned by student Student# In course Course#

Student# Course# together (called composIte attrIbute) defInes EXACTLY DNE value of marks.
ThIs can be symbolIcally represented as

Student# Course# harks

ThIs type of dependency Is called as functIonal dependency. n above example marks Is
functIonaIIy dependent on Student# Course#.

Dther functIonal dependencIes In above examples are:
Course# CourseName,
Course# Name (AssumIng one course Is taught by one and only one Instructor)
Name Foom# (AssumIng each Instructor has hIs/her own and nonshared room)
|arks Crade.

Formally we can defIne functIonal dependency as: n a gIven relatIon F, X and Y are
attrIbutes. AttrIbute Y Is functIonaIIy dependent on attrIbute X If each value of X determInes
EXACTLY DNE value of Y. ThIs Is represented as:
X Y
However X may be composIte In nature.
3.3.3. FuII FunctIonaI 0ependency
n above example |arks Is fully functIonally dependent on Student# Course# and not on sub
set of Student# Course#. ThIs means |arks can not be determIned eIther by Student# DP
Course# alone. t can be determIned only usIng Student# AN0 Course# together. Hence |arks
Is fully functIonally dependent on Student# Course#.

CourseName Is not fully functIonally dependent on Student# Course# because one of the
subset Course# determInes the CourseName and Student# does not have any role In decIdIng
CourseName. Hence CourseName Is not fully functIonally dependent on Student# Course#.

FIgure 3-3: FuII FunctIonaI 0ependency
FormaI defInItIon of fuII functIonaI dependency Is: n a gIven relatIon F, X and Y are
attrIbutes. Y Is fully functIonally dependent on attrIbute X only If It Is not functIonally
dependent on subset of X. However X may be composIte In nature.
3.3.4. PartIaI 0ependency
n the above relatIonshIp CourseName, Name, Foom# are partIally dependent on composIte
attrIbutes Student# Course# because Course# alone defInes the CourseName, Name, Foom#.

FIgure 3-4: PartIaI 0ependency
FormaI defInItIon of partIaI dependency Is: n a gIven relatIon F, X and Y are attrIbutes.
AttrIbute Y Is partIally dependent on the attrIbute X only If It Is dependent on subset of
attrIbute X. However X may be composIte In nature.
3.3.5. TransItIve 0ependency
n above example, Foom# depends on Name and In turn Name depends on Course#. Hence
Foom# transItIvely depends on Course#.

FIgure 3-5: TransItIve 0ependency
SImIlarly Crade depends on |arks, In turn |arks depends on Student# Course# hence Crade
fully trcnstvely
J5
depends on Student# Course#.
3.3.6. Key attrIbutes
n a gIven relatIonshIp F, If the attrIbute X unIquely defInes all other attrIbutes, then the
attrIbute X Is a Key attrIbute whIch Is nothIng but the candIdate key whIch Is defIned In
Chapter Dne.

Examle1: Student# Course# toyether s c composte key cttrbute whch determnes cll
cttrbutes n relctonshp REPDRT (Student#,Course#, CourseNcme, lNcme, Room#, Mcrks,
6rcde) unquely. Hence Student# cnd Course# cre key cttrbutes.

Examle2: Student# cnd EMcll0 clso ccn be consdered cs ccnddcte keys ]or entty student
ST00ENT(Student#, StudentNcme, 0cteo]8rth, EMcll0). Student# or EMcll0 unquely
de]nes cll other cttrbutes o] student entty.
3.3.7. Non key attrIbutes
n a gIven relatIonshIp F, all the attrIbutes whIch are not key attrIbutes are consIdered as
nonkey attrIbutes.
3.4. Types of NormaI Forms

3.4.1. FIrst NormaI Form (1 NF)
A relatIon F Is saId to be In the fIrst normal form (1NF) If and only If all the attrIbutes of the
relatIon F are ctomc
J6
In nature.

J5
TransItIve: ndIrect.
J6
AtomIc: The smallest levels to whIch data may be broken down and remaIn meanIngful.

ConsIder the Student_Course_Fesult table whIch Is reproduced from the SectIon 3.2 The
need for NormaIIzatIon.
Student_DetaiIs Course_DetaiIs ResuIts
101 Davis 11/4/1986 M4 AppIied Mathematics Basic Mathematics 7 11/11/2004 82 A
102 DanieI 11/6/1987 M4 AppIied Mathematics Basic Mathematics 7 11/11/2004 62 C
101 Davis 11/4/1986 H6 American History 4 11/22/2004 79 B
103 Sandra 10/2/1988 C3 Bio Chemistry Basic Chemistry 11 11/16/2004 65 B
104 EveIyn 2/22/1986 B3 Botany 8 11/26/2004 77 B
102 DanieI 11/6/1987 P3 NucIear Physics Basic Physics 13 11/12/2004 68 B
105 Susan 8/31/1985 P3 NucIear Physics Basic Physics 13 11/12/2004 89 A
103 Sandra 10/2/1988 B4 ZooIogy 5 11/27/2004 54 D
105 Susan 8/31/1985 H6 American History 4 11/22/2004 87 A
104 EveIyn 2/22/1986 M4 AppIied Mathematics Basic Mathematics 7 11/11/2004 65 B
FIgure 3-6: 0ata fIIe In tabIe format
Table shown In FIgure J6, Student_0etaIls, Course_0etaIls and Fesults attrIbutes can be
further dIvIded. Student_0etaIls attrIbute Is dIvIded Into Student# (Student Number),
StudentName (Student Name) and 0ateof8Irth (0ate of 8Irth). Course_0etaIls attrIbute Is
dIvIded Into Course# (Course Number), CourseName, PrerequIsItes and 0uratIon. SImIlarly
Fesults attrIbute Is dIvIded Into 0ateofExam, |arks and Crade.

To make above table 1NF complIant, It Is redesIgned as shown below.

Student Dateof Pre Duration DateOf Student#
Name Birth
Course# CourseName
Requisite InDays Exam
Marks Grade
101 Davis 4-Nov-86 M4 AppIied
Mathematics
Basic
Mathematics
7 11-Nov-04 82 A
102 DanieI 6-Nov-86 M4 AppIied
Mathematics
Basic
Mathematics
7 11-Nov-04 62 C
101 Davis 4-Nov-86 H6 American
History
4 22-Nov-04 79 B
103 Sandra 2-Oct-88 C3 Bio Chemistry Basic
Chemistry
11 16-Nov-04 65 B
104 EveIyn 22-Feb-86 B3 Botany 8 26-Nov-04 77 B
102 DanieI 6-Nov-86 P3 NucIear
Physics
Basic
Physics
13 12-Nov-04 68 B
105 Susan 31-Aug-85 P3 NucIear
Physics
Basic
Physics
13 12-Nov-04 89 A
103 Sandra 2-Oct-88 B4 ZooIogy 5 27-Nov-04 54 D
105 Susan 31-Aug-85 H6 American
History
4 22-Nov-04 87 A
104 EveIyn 22-Feb-86 M4 AppIied
Mathematics
Basic
Mathematics
7 11-Nov-04 65 B
FIgure 3-7: FIrst NormaI Form
n the new form, all the attrIbutes are atomIc, meanIng they are not further decomposcble
J7
.
You can not dIvIde Student#, StudentName etc further Into smaller attrIbutes. Hence thIs
table Is In 1NF.

Let us revIsIt the Issues we had wIth unnormalIzed table. Even at thIs stage, It Is dIffIcult to
add prospectIve course or student InformatIon. StIll It Is dIffIcult to update or delete eIther
Course or Student InformatIon. Hence anomalIes In Inserts, updates and deletes are stIll to be
resolved.

Unfortunately fIrst normal form has all the problems whIch we faced In unnormalIzed table.
3.4.2. Second NormaI Form (2 NF)
A FelatIon Is saId to be In Second Normal Form If and only If:
t Is In the FIrst normal form, and
No partIal dependency exIsts between nonkey attrIbutes and key attrIbutes.

Let us revIsIt 1NF table structure.
Student# Is key attrIbute for Student,
Course# Is key attrIbute for Course
Student# Course# together form the composIte key attrIbutes for Fesult relatIonshIp
Dther attrIbutes lIke StudentName (Student Name), 0ateof8Irth, CourseName,
PreFequIsIte, 0uratIonn0ays, 0ateofExam, |arks and Crade are nonkey attrIbutes.

To make thIs table 2NF complIant, we have to remove all the partIal dependencIes.
StudentName and 0ateof8Irth depends only on Student#
CourseName, PreFequIsIte and 0uratIonn0ays depends only on Course#
0ateofExam depends only on Course#

To remove thIs partIal dependency we need to splIt Student_Course_Fesult table Into four
separate tables, STU0ENT, CDUFSE, FESULT and EXA|_0ATE tables as shown In FIgure J8 .

J7
0ecomposabIe: Further splIt or reduce.

STUDENT TABLE
Student# StudentName DateofBirth
101 Davis 4-Nov-86
102 DanieI 6-Nov-87
103 Sandra 2-Oct-88
104 EveIyn 22-Feb-86
105 Susan 31-Aug-85
106 Mike 4-Feb-87
107 JuIiet 9-Nov-86
108 Tom 7-Oct-86
109 Catherine 6-Jun-84

COURSE TABLE
Course# CourseName PreRequisite DurationInDays
M1 Basic
Mathematics
11
M4 AppIied
Mathematics
M1 7
H6 American
History
4
C1 Basic
Chemistry
5
C3 Bio Chemistry C1 11
B3 Botany 8
P1 Basic Physics 8
P3 NucIear
Physics
P1 13
B4 ZooIogy 5

RESULT TabIe
Student# Course# Marks Grade
101 M4 82 A
102 M4 62 C
101 H6 79 B
103 C3 65 B
104 B3 77 B
102 P3 68 B
105 P3 89 A
103 B4 54 D
105 H6 87 A
104 M4 65 B

EXAM_DATE TabIe
Course# DateOfExam
M4 11-Nov-04
H6 22-Nov-04
C3 16-Nov-04
B3 26-Nov-04
P3 12-Nov-04
B4 27-Nov-04

FIgure 3-8: Second NormaI Form
n the fIrst table (STU0ENT), the key attrIbute Is Student# and all other nonkey
attrIbutes, StudentName and 0ateof8Irth are fully functIonally dependant on the key
attrIbute
n the second table (CDUFSE), Course# Is the key attrIbute and all the nonkey
attrIbutes, CourseName, PreFequIsIte and 0uratIonn0ays are fully functIonally
dependant on the key attrIbute
n thIrd table (FESULT) Student# Course# together are key attrIbutes and all other non
key attrIbutes, |arks and Crade are fully functIonally dependant on the key attrIbutes
n the fourth table (EXA|_0ATE) Course# Is the key attrIbute and the nonkey
attrIbute, 0ateDfExam Is fully functIonally dependant on the key attrIbute
These four tables are also complIant wIth the FIrst Normal Form defInItIon. Hence
these four tables are In Second Normal Form (2NF)
At fIrst look It appears lIke all our anomalIes are taken away! Now we are storIng Student 10J
and |4 record only once. We can Insert prospectIve students and courses at our wIll. We wIll
update only once If we need to change any data In STU0ENT, CDUFSE tables. We can get rId
of any course or student detaIls by deletIng just one row.
Let us analyze the followIng table.

Student# Course# Marks Grade
101 M4 82 A
102 M4 62 C
101 H6 79 B
103 C3 65 B
104 B3 77 B
102 P3 68 B
105 P3 89 A
103 B4 54 D
105 H6 87 A
104 M4 65 B
FIgure 3-: PESULT TabIe

We already concluded that:
All the attrIbutes are atomIc In nature
No partIal dependency exIsts between the key attrIbutes and nonkey attrIbutes.
FESULT table Is In Second NormaI form (2NF)
Assume, at present, as per the unIversIty evaluatIon polIcy,
Students who score more than or equal to 80 marks are awarded wIth "A" grade
Students who score more than or equal to 65 up tIll 79 gets "8" grade
Students who score marks more than or equal to 50 up tIll 64 fetches "C" grade
Students who score marks less than 50 Is only "0" grade
The unIversIty management whIch Is commItted to Improve the qualIty of educatIon, wants to
change the exIstIng gradIng system to a new gradIng system as gIven below.
"A+" grade for 95 and above
"A" grade for 85 to 94
"8" grade for 70 to 84
"C" grade for 55 to 64
"E" grade for less than 40

n the present FESULT table structure,
We do not have an optIon to Introduce new grades lIke A+, 8 and E.
We need to do multIple updates on the exIstIng records to brIng them to the new
gradIng defInItIon.
We wIll not be able to take away "0" grade If we want to.
2NF does not take care of all the anomalIes and InconsIstencIes.
3.4.3. ThIrd NormaI Form (3 NF)
A relatIon F Is saId to be In the ThIrd Normal Form (JNF) If and only If
t Is In 2NF and
No transItIve dependency exIsts between nonkey attrIbutes and key attrIbutes

n the above FESULT table Student# and Course# are the key attrIbutes. All other attrIbutes,
except grade are nonpartIally, nontransItIvely dependent on key attrIbutes. The "Crade"
attrIbute Is dependant on "|arks" and In turn "|arks" Is dependent on Student# Course#. To
brIng thIs table to thIrd normal form we need to take off thIs transItIve dependency.

After takIng thIs transItIve dependency we can Infer the followIng table structures whIch are
In JNF.

Student# Course# Marks
101 M4 82
102 M4 62
101 H6 79
103 C3 65
104 B3 77
102 P3 68
105 P3 89
103 B4 54
105 H6 87
104 M4 65
MARKSGRADE TABLE
UpperBound LowerBound Grade
100 95 A+
94 85 A
84 70 B
69 65 B-
64 55 C
54 45 D
44 0 E
FIgure 3-10: ThIrd NormaI Form
After normalIzIng tables to ThIrd NormaI Form (3NF), we got rId off all the anomalIes and
InconsIstencIes. Now we can add new grade systems, update the exIstIng one and delete the
unwanted ones.
Hence the ThIrd NormaI Form Is the most optImal normal form and X of the databases
whIch requIre effIcIency In
NSEFT
UP0ATE and
0ELETE
DperatIons are desIgned In thIs normal form.
3.4.4. oyce Codd NormaI Form (CNF)
A relatIon Is saId to be In 8oyce Codd Normal Form (8CNF) If and only If all the determInants
are candIdate keys. 8CNF relatIon Is a strong JNF, but not every JNF relatIon Is 8CNF.

Let us understand thIs concept usIng slIghtly dIfferent Fesult table structure.

Student# EmaiIID Course# Marks
101 Davis@myuni.edu M4 82
102 Daniel@myuni.edu M4 62
101 Davis@myuni.edu H6 79
103 Sandra@myuni.edu C3 65
104 Evelyn@myuni.edu B3 77
102 Daniel@myuni.edu P3 68
105 Susan@myuni.edu P3 89
103 Sandra@myuni.edu B4 54
105 Susan@myuni.edu H6 87
104 Evelyn@myuni.edu M4 65
FIgure 3-11: PESULT TabIe

FIgure 3-12: DverIappIng CandIdate Key
n the FIgure J11, FESULT table, we have two candIdate keys namely Student# Course# and
Course# EmaIIId. Course# Is overlappIng among those candIdate keys. Hence these candIdate
keys are called as "overIappIng candIdate keys" whIch Is shown In FIgure J12.

The nonkey attrIbute, |arks Is nontransItIvely and fully functIonally dependant on key
attrIbutes. Hence thIs Is In JNF. 8ut thIs Is not In 8CNF because there are four determInants In
thIs relatIon namely:
Student# (Student# decIdes EmaIlI0)
E|aIl0 (EmaIl0 decIdes Student#)
Student# Course# (decIdes rest of the attrIbutes In FESULT table)
Course# E|aIl0 (decIdes rest of the attrIbutes In FESULT table)

All above determInants are not candIdate keys. E|aIl0 decIdes Student# but E|aIl0 on Its
own Is not a candIdate key. SImIlarly Student# decIdes E|aIl0 of a student but Student#
alone Is not a candIdate key. Dnly combInatIon of Student# Course# and Course# E|aIl0 are
candIdate keys.
To make thIs table 8CNF, we need to splIt thIs table Into the followIng structure:

STUDENT TABLE
Student# EmaiIID
101 Davis@myuni.edu
102 Daniel@myuni.edu
103 Sandra@myuni.edu
104 Evelyn@myuni.edu
105 Susan@myuni.edu
Student# Course# Marks
101 M4 82
102 M4 62
101 H6 79
103 C3 65
104 B3 77
102 P3 68
105 P3 89
103 B4 54
105 H6 87
104 M4 65
FIgure 3-13: oyce Codd NormaI Form
Now both the tables are not only In JNF, but also In 8CNF because all the determInants are
candIdate keys. n the fIrst table, Student# decIdes E|aIl0 and E|aIl0 decIdes Student# and
both are candIdate keys.

n second table, Student# Course# Is only determInant and candIdate key. Hence It qualIfIes
8CNF defInItIon that every determInant must be a candIdate key.

Note: f the table has only one noncomposIte candIdate key and If It
Is In JNF, then the table wIll also be In 8CNF.

8asIcally 2NF and JNF takes away the redundancy, anomalIes whIch exIst among the key and
nonkey attrIbutes on other hand 8CNF takes away the redundancy, anomalIes whIch exIst
among the key attrIbutes. At nfosys, we rarely (around 1 of database desIgn) normalIze the
databases to 8CNF.
3.5. herIts and 0emerIts of NormaIIzatIon
The followIng sectIons dIscuss merIts and demerIts of normalIzatIon.
3.5.1. herIts
1) NormalIzatIon Is based on mathematIcal foundatIon.
2) Femoves the redundancy to the greater extent. After JNF, data redundancy Is
mInImIzed to the extent of foreIgn keys.
J) Femoves the anomalIes present In nserts, Updates and 0eletes.
3.5.2. 0emerIts
1) 0ata retrIeval (Select) operatIon performance wIll be severely affected.
Examle: Let us cssume thct the unversty mcncyement wcnts to hcve the report o]
students per]ormcnce n the ]ollowny ]ormct.

UNIVERSITY REPORT
Student Name Course Name Date Of Exam Grade
DanieI AppIied Mathematics 11-Nov-04 C
DanieI NucIear Physics 12-Nov-04 B
Davis AppIied Mathematics 11-Nov-04 A
Davis American History 22-Nov-04 B
EveIyn Botany 26-Nov-04 B
EveIyn AppIied Mathematics 11-Nov-04 B
Sandra Bio Chemistry 16-Nov-04 B
Sandra ZooIogy 27-Nov-04 D
Susan NucIear Physics 12-Nov-04 A
Susan American History 22-Nov-04 A
FIgure 3-14: Proposed UnIversIty Peport
After applyIng JNF normalIzatIon technIque for database desIgn, a sIngle table wIll not
contaIn all the InformatIon as desIred by the college management.

We need to select Student Name from STU0ENT table, Course Name from CDUFSE table,
0ate of ExamInatIon from EXA|_0ATE table and Crade from |arksCrade table.
n an unnormalIzed format we would have retrIeved all these columns just from one
table.

Hence normalIzatIon wIll defInItely slow down the Select operatIons. t Is better to
restrIct normalIzatIon process to 2NF, If applIcatIon has more data retrIeval operatIons
than Insert or update or delete operatIons.

f the applIcatIon Is used for queryIng a database, It Is called as "FeportIng System".
Let us take the example of a FaIlway enquIry system. ThIs enquIry system Is used to
enquIre about reservatIon avaIlabIlIty and not used to book the tIckets. Dn the other hand
a FaIlway reservatIon system Is called as "DnlIne applIcatIon" because thIs system Is used
for bookIng tIckets (Inserts), changIng travel plans (updates) and cancelIng tIckets
(deletes).

Hence one may normaIIze onIy up to 2NF for PeportIng System and 3NF for DnIIne
appIIcatIons.

2) NormalIzatIon may not always represent real world scenarIos. t should be borne In
mInd however that full normalIzatIon may not always be desIrable and the database
desIgner may take advantage of hIs/her IntImate knowledge of the real world and
choose not to normalIze In some partIcular Instance.

Examle: consder the ]ollowny relcton: C0STDMER (Ncme, Street, Cty, Postcode.
Strctly speckny, the cttrbute Postcode unquely dent]es Cty, hence trcnstve
dependency exsts n the cbove scencro.

Postcode > Cty

Thus C0STDMER tcble s not n JNF. However n prcctce the cttrbutes Cty cnd
Postcode cre clwcys used toyether cs c unt cnd decomposny the relcton would not
be cdvscble n ths ccse.

Note: Some tIme to Increase the performance of select operatIons for
reportIng applIcatIon, database desIgn Is taken back from hIgher
normal form to lower normal form (ex: JNF to 2NF). ThIs process Is
called as denormalIzatIon or Second Level 0esIgn (SL0).

3.6. Summary
NormalIzatIon Is a refInement process. t helps In removIng anomalIes present In
Insert, update and delete operatIons.
NormalIzatIon Is also called "8ottomup approach", because thIs technIque requIres
mInute detaIls lIke every partIcIpatIng attrIbute and how It Is dependant on the key
attrIbutes Is crucIal. f you add new attrIbutes after normalIzatIon, It may change the
normal form Itself.
There are four normal forms that were defIned beIng commonly used.
1NF makes sure that all the attrIbutes are atomIc In nature.
2NF removes the partIal dependency.
JNF removes the transItIve dependency.
8CNF removes dependency among key attrIbutes.
ExcessIve normalIzatIon adversely affects select or retrIeval operatIons.
t Is always better to normalIze to JNF for Insert, update and delete IntensIve (onlIne
transactIon) systems.
t Is always better to restrIct to 2NF for select IntensIve (reportIng) systems.
WhIle normalIzIng, use common sense and don't use the normal forms as absolute measures.

PoInts to Pemember:
Normal Form Test Femedy
(NormalIzatIon)
1NF FelatIon should have atomIc
attrIbutes. The domaIn of an
attrIbute must Include only
atomIc (sImple, IndIvIsIble)
Form new relatIons for
each nonatomIc
attrIbute

3.7. Case study
CIven below Is the data In an unnormalIzed table. NormalIze It to 1NF. dentIfy the problems
encountered when the table Is In 1NF but not In 2NF. Subsequently normalIze to 2NF and JNF,
explaInIng the problems faced and the solutIon to It.

Proj_No Proj_Name Emp_No Emp_Name Fate_Category Hourly_Fate_In
_dollars
102J Amsterdam
travel sIte
101
102
10J
7Incent F
PaulIne J
Charles C
A
8
C
60
50
40
1056 Feal Estate
Agency
101
107
7Incent F
0avId F
A
8
60
50

SoIutIon:
values.
2NF For relatIons where prImary
key contaIns multIple
attrIbutes (composIte
prImary key), nonkey
attrIbute should not be
functIonally dependent on a
part of the prImary key.
0ecompose and form a
new relatIon for each
partIal key wIth Its
dependent attrIbute(s).
FetaIn the relatIon
wIth the orIgInal
prImary key and any
attrIbutes that are
fully functIonally
dependent on It.
JNF FelatIon should not have a
nonkey attrIbute
functIonally determIned by
another nonkey attrIbute
(or by a set of nonkey
attrIbutes). n other words
there should be no transItIve
dependency of a nonkey
attrIbute on the prImary
key.
0ecompose and form a
relatIon that Includes
the nonkey
attrIbute(s) that
functIonally
determIne(s) other
nonkey attrIbute(s).


TabIe (1NF)
Proj_No Proj_Name Emp_No Emp_Name Fate_Category Hourly_Fate_In
_dollars
102J Amsterdam
travel sIte
101 7Incent F

A 60
102J Amsterdam
travel sIte
102 PaulIne J

8 50
102J Amsterdam
travel sIte
10J Charles C C 40
1056 Feal Estate
Agency
101 7Incent F

A 60
1056 Feal Estate
Agency
107 0avId F 8 50

ProbIems encountered when the tabIe Is In 1NF but not In 2NF:
I. Wastage of space: nformatIon that code 102J refers to the Amsterdam travel sIte
appears three (J) tImes.
II. Update AnomaIy: f the project name has to be changed, It has to be done In all the
rows that the project name appears In. f It has not been changed In just one row, thIs
may lead to InconsIstency problems.
III. Insert AnomaIy: The InformatIon about a new employee cannot be Inserted Into the
table unless the employee Is assIgned to a project.
Iv. 0eIete AnomaIy: f there Is only one employee workIng on a project, It Is not possIble
to delete InformatIon about the employee wIthout losIng InformatIon about the
project. n other words It Is not possIble to delete a subset of a record.

SoIutIon: NormaIIze to 2NF
I. Take out the duplIcatIon
II. Look for partIal dependencIes I.e. fIelds that are dependent on a part of a key and not
on the entIre key.

n the above table, the key Is (Proj_No, Emp_No)

The functIonal dependencIes are as follows:
Proj_No Proj_Name
Emp_No Emp_Name, Fate_Category, Hourly_Fate_In_0ollars
Fate_Category Hourly_Fate_In_0ollars

The above table should be decomposed as follows:


Employee_Project Table
Proj_No Emp_No
102J 101
102J 102
102J 10J
1056 101
1056 107

Employee_Table
Emp_No Emp_Name Fate_Category Hourly_Fate_In_0ollars
101 7Incent F A 60
102 PaulIne J 8 50
10J Charles C C 40
107 0avId F 8 50

Project Table
Proj_No Proj_Name
102J Amsterdam Travel sIte
1056 Feal Estate Agency

ProbIems faced wIth the tabIe In 2NF
I. Stores data redundantIy: The Hourly_Fate_In_0ollars and Fate_Category are beIng
stored In Its entIrety for each employee.
II. Update AnomaIy: f the hourly rate In dollars has to be changed for a partIcular rate
category, It has to be done In all the rows that the rate category appears In. f It has
not been changed In just one row, thIs may lead to InconsIstency problems.
III. Insert AnomaIy: t Is not possIble to Insert InformatIon about a new rate category and
the correspondIng hourly rate In dollars unless there Is an employee In that rate
category.
Iv. 0eIete AnomaIy: f there Is only one employee In a partIcular rate category, It Is not
possIble to delete InformatIon about the employee wIthout losIng InformatIon about
that rate category and the correspondIng hourly rate In dollars.

SoIutIon: NormaIIze to 3NF
I. Femove thIs excess data Into Its own table.
II. Look for transItIve relatIonshIps or relatIonshIps where a nonkey attrIbute Is
dependent on another nonkey attrIbute.

n the above table (Employee table), Hourly_Fate_In_0ollars Is actually dependent on
Fate_Category accordIng to the functIonal dependency Fate_Category
Hourly_Fate_In_0ollars

The above table (Employee) should be decomposed as follows:

Employee Table
Emp_No Emp_Name Fate_Category
101 7Incent F A
102 PaulIne J 8
10J Charles C C
107 0avId F 8

Fate Table
Fate_Category Hourly_Fate_In_0ollars
A 60
8 50
C 40

4. Structured uery Language (SL)
SQL Is used to Interact wIth a database to manage and retrIeve data.
4.1. The Purpose of SL
SQL Is used to retrIeve data from the database. The 08|S processes the SQL request,
retrIeves the requested data from the database, and returns It. ThIs process of requestIng
data from the database and receIvIng back the results Is called a database query and hence
the name Structured Query Language.
Fefer to FIgure 41.

FIgure 4-1: UsIng SL for database access
SQL Is used to control all the functIons that a 08|S provIdes for Its users, IncludIng:

0ata 0efInItIon: SQL allows a user to defIne the structure and the organIzatIon of the
data to be stored and the relatIonshIps among the stored data Items
0ata PetrIevaI: SQL allows a user or an applIcatIon program to retrIeve the stored
data from the database
0ata hanIpuIatIon: SQL lets a user or an applIcatIon program update the database by
allowIng to add new data, delete the exIstIng data, and modIfy the exIstIng data
Access ControI: SQL can be used to restrIct a user's abIlIty to retrIeve, add, and
modIfy data, thus protectIng the stored data agaInst unauthorIzed access

4.2. A rIef HIstory of SL

0ate Event
1970 The relatIonal model devIsed by Codd was
explored durIng the 1970s, and commercIal
relatIonal database products began to emerge In
the 1980s, orIgInally for maInframe systems and
later for mIcrocomputers. Edgar Codd fIrst wrote
about the concept of relatIonal databases In hIs
paper 'A relatIonal model of data for large shared
data banks' In 1970.
1979 Dracle CorporatIon Introduced the fIrst commercIal F08|S
1982 ANS (AmerIcan NatIonal Standards nstItute) formed SQL Standards
CommIttee
198J 8| (nternatIonal 8usIness |achIne) announced 082 (a database)
1986 ANS (AmerIcan NatIonal Standards nstItute) SQL1 standard Is approved
1987 SD (nternatIonal DrganIzatIon for StandardIzatIon) SQL1 standard Is
approved
1992 ANS (AmerIcan NatIonal Standards nstItute) SQL2 standard Is approved
2000 |Icrosoft CorporatIon Introduces SQL Server 2000, aImed at enterprIse
applIcatIons
2002 Fesearch fIrm Cartner ranked 8| as #1 database vendor over Dracle
2004 SQL: 200J standard Is publIshed

4.3. 0ata Types
The data types are used to specIfy the type of data that wIll be stored In each column of the
table. The followIng table lIsts the typIcal dctc types
J8
used In Dracle 8I and Dracle 9I:

0ata Type
Syntax
Dracle 8I Dracle 9I ExplanatIon
(If applIcable)
dec(p, s)

Dr

decImal(p, s)
The maxImum
precIsIon Is J8 dIgIts.
The maxImum
Where p Is the
precIsIon and s Is the
scale.
Examle: dec(J, 1) Is
a number that has 2
dIgIts before the
decImal and 1 dIgIt
after the decImal.
numerIc(p, s)

Dr

number(p, s)
The maxImum
The maxImum
Where p Is the
precIsIon and s Is the
scale.
Examle: numerIc
(7, 2) Is a number
that has 5 dIgIts
before the decImal
and 2 dIgIts after the
decImal.
char (sIze) Up to 2000 bytes In
Dracle 8I.
Up to 2000 bytes In
Dracle 9I.
Where sIze Is the
number of characters
to store. FIxedlength
strIngs. Space
padded. Examle: If
the wIdth of a
character varIable Is
10 and the strIng
stored In It Is
'F08|S', It wIll be
stored as 'F08|S '
varchar2 (sIze) Up to 4000 bytes In
Dracle 8I.
Up to 4000 bytes In
Dracle 9I.
Where sIze Is the
number of characters
to store. 7arIable
length strIngs.
Examle: If the
wIdth of a character

J8
0ata Types: The descrIptIon of the kInds of data stored, passed and used.
varIable Is 10 and the
strIng stored In It Is
'F08|S', It wIll be
stored as 'F08|S'
Long Up to 2 gIgabytes. Up to 2 gIgabytes. 7arIablelength
strIngs. (bcckwcrd
compctble
J9
)
0ate A date between Jan
1, 4712 8C and 0ec
J1, 9999 A0.
A date between Jan
1, 4712 8C and 0ec
J1, 9999 A0.
Examle:
'25JAN2005'

J9
ackward CompatIbIe: A desIgn that contInues to work wIth earlIer versIons of a language, program,
etc.

4.4. Statement types
The followIng table lIsts the three types of SQL statements:

Type of SQL statement SQL keywords FunctIon

0ata 0efInItIon Language (00L) CFEATE
ALTEF
0FDP

TFUNCATE
Used to defIne, change
and drop the structure
of a table.

Used to remove all
rows from a table.
0ata |anIpulatIon Language(0|L) NSEFT NTD
UP0ATE
0ELETE FFD|
SELECT
Used to enter, modIfy,
delete and retrIeve
data from a table.
0ata Control Language (0CL) CFANT
FE7DKE

CD||T
FDLL8ACK
Used to control access
to the data In a
database.

Used to defIne the end
of a transactIon.

Note: All keywords must be entered as descrIbed otherwIse users get
syntax errors.
4.5. 0ata 0efInItIon Language (00L) Statements
00L statements are used to defIne and manage table(s).
0efIne and create a new table
Femove a table that Is no longer needed
Change the defInItIon of an exIstIng table
0efIne a vIrtual table (vIew) of data (Covered In sectIon 4.7)
8uIld an ndex
40
to access a table faster (Covered In sectIon 4.5.5)

40
Index: ndIces are created In an exIstIng table to locate rows more quIckly and effIcIently. t Is
possIble to create an Index on one or more columns of a table, and each Index Is gIven a name. The
users cannot see the Indexes; they are just used to speed up querIes. |ore on Index Is covered In
SectIon 4.5.5.
CDNSTPAINTS
0ata types lImIt the kInd of data that can be stored In a table. ThIs Is however, not enough.
For example, a column to store a product prIce should accept only posItIve values. 8ut there
Is no data type that accepts only posItIve numbers. Another requIrement could be to constraIn
column data wIth respect to other columns or rows. For example, In a table contaInIng
product InformatIon, there should only be one row for each product number.
SQL allows the defInItIon of constraInts on columns and tables. f a user attempts to store
data In a column that would vIolate a constraInt, an error Is raIsed.

Types of ConstraInts:
CoIumn ConstraInt: A column constraInt Is specIfIed as part of a column defInItIon and
applIes only to that column
TabIe ConstraInt: A table constraInt Is declared Independently from a column
defInItIon and can apply to more than one column In a table

Note: Table constraInts must be used when constraInt Is applIed for
more than one column of a table.

4.5.1. CPEATE TALE Statement
The CFEATE TA8LE statement can:
Create a table
0efIne column constraInts
0efIne table constraInts
Fefer to FIgure 42.
CREATE TABLE table-name
(---------- Column-Definitions ---------)
Table-Constraint-Definitions
CoIumn-Definition:
column-name data-type [ DEFAULT value ]
TabIe-Constraint-Definition:
CONSTRAINT constraint-name primary-key-constraint
foreign-key-constraint
uniqueness-constraint
check-constraint
Primary-Key-Constraint:
PRIMARY KEY ( column-name )
Foreign-Key-Constraint:
FOREIGN KEY ( column-name ) REFERENCES table-name [ column-name ]
Uniqueness-Constraint:
UNIQUE ( column-name )
Check-Constraint:
CHECK ( search-condition )

FIgure 4-2: CPEATE TALE syntax dIagram

Note: AnythIng enclosed between [ ] Is optIonal.

Example:

1. Create a table Customer_0etaIls wIth the followIng specIfIcatIons

Column Name 0ata Type and WIdth ConstraInt
Cust_0 Number(5) Not Null
Cust_Last_Name 7archar2(20) Not Null
Cust_|Id_Name 7arChar2(4)
Cust_FIrst_Name 7arChar2(20)
Account_No Number(5) PrImary Key
Account_Type 7arChar2(10) Not Null
8ank_8ranch 7archar2(25) Not Null
Cust_EmaIl 7arChar2(J0)

Syntax:

CkLA1L 1A8LL CusfomeDefa11s{

CusflD Numbe{5} CON51kAlN1 Nnu111 NO1 NuLL,
CusfLasfName vaCha2{20} CON51kAlN1 Nnu112 NO1 NuLL,
CusfM1dName vaCha2{4},
CusfI1sfName vaCha2{20},
AccounfNo Numbe{5} CON51kAlN1 Pkey1 PklMAkY kLY,
Accounf1ype vaCha2{10} CON51kAlN1 Nnu113 NO1 NuLL,
8ank8anch vaCha2{25} CON51kAlN1 Nnu114 NO1 NuLL,
CusfLma11 vaCha2{30}

}

2. Create a table Employee_|anager wIth the followIng specIfIcatIons

Column Name 0ata Type and WIdth ConstraInt
Employee_0 Number(6) PrImary Key
Employee_Last_Name 7arChar2(25)
Employee_|Id_Name 7archar2(5)
Employee_FIrst_Name 7archar2(25)
Employee_EmaIl 7arChar2(45)
0epartment 7arChar2(10)
Crade Number(2)
|anager_0 Number(6) ForeIgn Key FeferencIng Employee_0

Syntax:

CkLA1L 1A8LL Lmp1oyeeManage{

Lmp1oyeelD Numbe{6} CON51kAlN1 Pkey2 PklMAkY kLY,
Lmp1oyeeLasfName vaCha2{25},
Lmp1oyeeM1dName vaCha2{5},
Lmp1oyeeI1sfName vaCha2{25},
Lmp1oyeeLma11 vaCha2{45},
Depafmenf vaCha2{10},
Gade Numbe{2},
ManagelD Numbe{6} CON51kAlN1 Ikey2
kLILkLNCL5 Lmp1oyeeManage{Lmp1oyeelD}

}

A column level constraInt follows a column defInItIon whereas a table level constraInt follows
a table defInItIon. A table level constraInt generally Involves two or more columns.

J. A prImary key as a column constraInt

Syntax:

}

The prImary key defInItIon In the above example follows the column (Account_No) defInItIon.
A column defInItIon Includes the name of the column, data type and length of the column.

4. A prImary key as a table constraInt

Syntax:

AccounfNo Numbe{5},
CusfLma11 vaCha2{30}, CON51kAlN1 pkey1 PklMAkY kLY{CusflD,
AccounfNo}
}

The prImary key defInItIon In the above example follows the table defInItIon I.e. the prImary
key defInItIon occurs after all the columns In the table have been defIned for theIr data type
and wIdth.

5. To create a table from another table

Syntax:

CkLA1L 1A8LL CusfDefa11s A5
5LLLC1 CusflD, AccounfNo, Accounf1ype, 8ank8anch, CusfLma11
IkOM CusfomeDefa11s

n the example above Cust_0etaIls table Is created from Customer_0etaIls table. Cust_detaIls
table Is created wIth attrIbutes Cust_0, Account_No, Account_Type, 8ank_8ranch and
Cust_EmaIl. f It Is requIred that Cust_0etaIls table has exactly the same structure as
Customer_0etaIls table the syntax would be as follows:

CkLA1L 1A8LL CusfDefa11s as
5LLLC1 "
IkOM CusfomeDefa11s

n the examples above not only Is the structure copIed but the data Is also copIed.

To copy only the structure and not the data

CkLA1L 1A8LL CusfDefa11s as
5LLLC1 " IkOM CusfomeDefa11s WhLkL 1=2

Note: When a table Is created from another table, only the NDT NULL constraInts are copIed.
All the other constraInts are not copIed.

6. 0omaIn IntegrIty constraInt (check constraInt - column constraInt)

CusflD Numbe{5} CON51kAlN1 Nnu111 NO1 NuLL
CON51kAlN1 Ccheck1 ChLCk{ CusflD 8L1WLLN 101 AND 105},
}

7. 0omaIn IntegrIty constraInt ( check constraInt - table constraInt)

CusfLma11 vaCha2{30},
CON51kAlN1 Ccheck2 ChLCk{CusflD 8L1WLLN 101 AND 105 AND ACCOuN11YPL
1n {`5av1ngs`, `Check1ngs`}}
}

Note: Although gIvIng a name to a constraInt Is optIonal, It Is a good
programmIng practIce to gIve every constraInt a name (preferably a
meanIngful name) whIch Is unIque and can't be applIed to any other
constraInt of any table. The name of the constraInt Is requIred when the
constraInt has to be dropped.

A NDT NULL constraInt on a column(s) means that It Is mandatory to provIde a value for the
column(s).

A UNIUE constraInt on a column(s) means that the values In the column(s) should be dIstInct
although It can have NULL values.

n most of 08|S, a PPIhAPY KEY constraInt ImplIcItly Imposes a NDT NULL and UNQUE
constraInt. f there Is a composIte prImary key, each of the attrIbute constItutIng the prImary
key Is NDT NULL. n other words It wIll not allow a NULL value In any of the attrIbutes
constItutIng the composIte prImary key. However the combInatIon of attrIbutes constItutIng
the prImary key should offer a unIque value.

A ForeIgn Key constraInt on a set of attrIbute(s) does not prevent them from havIng duplIcate
or NULL values.

Note: Users can use the 0ESCF8E tablename or 0ESC tablename
statement to see the structure of the table.

ExampIe:
DL5Ckl8L CusfomeDefa11s

O

DL5C CusfomeDefa11s
4.5.2. ALTEP TALE statement
The ALTEF TA8LE statement can:
- Add a column defInItIon to a table
- 0rop a column from a table
- Add or drop a prImary key to / from a table
- Add or drop a foreIgn key to / from a table
- Add or drop a unIque constraInt to / from a table
- Add or drop a check constraInt to / from a table

FIgure 4-3: ALTEP TALE statement syntax dIagram

Note: The check constraInt enforces the domaIn IntegrIty constraInt. t
permIts only values allowed by the constraInt Into the column(s). The domaIn
IntegrIty constraInt wIll be covered In detaIl In chapter 5.

Examle:

1. AddIng a coIumn
Add a phone number to the Customer_0etaIls table

AL1Lk 1A8LL CusfomeDefa11s
ADD ConfacfPhone Cha{10}

2. hodIfyIng a coIumn defInItIon
|odIfy the sIze of the Contact_Phone column

MODlIY ConfacfPhone Cha{12}

J. AddIng a NDT NULL ConstraInt
Add the NDT NULL constraInt on the Contact_Phone column

MODlIY ConfacfPhone Cha{12} CON51kAlN1 Nnu115 NO1 NuLL
4. AddIng a UNIUE ConstraInt
Add the UNQUE constraInt on the Contact_Phone column

ADD CON51kAlN1 uun1que1 uNlquL {ConfacfPhone}

5. 0roppIng a constraInt
0rop the NDT NULL constraInt on Contact_Phone column

DkOP CON51kAlN1 Nnu115

6. 0roppIng a coIumn
0rop the Contact_Phone column from the Customer_0etaIls table

DkOP {ConfacfPhone}

7. AddIng a sImpIe PPIhAPY KEY
|ake the Account_No column as the prImary key

ADD CON51kAlN1 Pkey1 PklMAkY kLY {AccounfNo}

8. AddIng a composIte PPIhAPY KEY (tabIe IeveI constraInt)
|ake the Account_No and Cust_0 columns as the prImary key

ADD CON51kAlN1 Pkey2 PklMAkY kLY {AccounfNo, CusflD}

9. AddIng FDPEICN KEY
|ake Account_No column In Customer_TransactIon table as the foreIgn key referencIng
Account_No column of Customer_0etaIls

AL1Lk 1A8LL Cusfome1ansacf1on
ADD CON51kAlN1 Ikey1 IOkLlGN kLY {AccounfNo}
kLILkLNCL5 CusfomeDefa11s {AccounfNo}

10. AddIng a CHECK constraInt
ADD CON51kAlN1 Ccheck1 ChLCk {CusflD 8L1WLLN 101 AND 105}

11. 0roppIng a sImpIe or composIte PPIhAPY KEY constraInt
0rop the prImary key constraInt

DkOP PklMAkY kLY

Dr

DkOP CON51kAlN1 Pkey1

Note: The syntax Is the same IrrespectIve of whether the prImary key Is
sImple or composIte.

A table can have only one prImary key. A table can have one or more foreIgn keys. f a table
already has a prImary key, addIng a prImary key usIng the ALTEF TA8LE statement results In
error. The F08|S wIll not allow a PF|AFY KEY constraInt (usIng the ALTEF TA8LE statement)
on column(s) If the column(s) has NULL or duplIcate values.

Note: The ALTEF TA8LE statement cannot be used to change the name of a
column or a table. t can be used to change the data type or length of the
column. Columns to be modIfIed should be empty to decrease column length.
Columns to be modIfIed should be empty to change the data type.

f the table has only one column, the ALTEF TA8LE statement cannot be used to drop that
column because that would render the table defInItIon InvalId.
4.5.3. 0PDP TALE statement
The 0FDP TA8LE statement Is used to drop a table from the database.

FIgure 4-4: 0PDP TALE statement syntax dIagram

When the 0FDP TA8LE statement removes a table from the database, Its schema/structure
and all of Its contents are lost. There Is no way to recover the data.


Note: |ost F08|S wIll restrIct the droppIng of a table If It has attrIbute(s)
beIng referred to by attrIbute(s) of another table. ThIs Is called the
referentIal IntegrIty constraInt.

Examle:
0Iscard Customer_0etaIls table

DkOP 1A8LL CusfomeDefa11s

4.5.4. TPUNCATE TALE statement
The TFUNCATE TA8LE statement Is used to remove/delete all rows from a table.

FIgure 4-5: TPUNCATE TALE statement syntax dIagram
When the TFUNCATE TA8LE statement Is used, all the contents of the specIfIed table are lost
but Its defInItIon remaIns Intact. There Is no way to recover the data. t releases the memory
occupIed by the contents of the specIfIed table.
Examle:
0elete all rows from the Customer_0etaIls table

TFUNCATE TA8LE Customer_0etaIls;
4.5.5. CPEATE IN0EX statement
An Index Is a structure that provIdes rapId access to the rows of a table based on the values
of one or more columns. The Index stores the data values and poInters to the rows where
those data values occur. n the Index, the data values are arranged eIther In ascendIng or In
descendIng order, so that the F08|S can quIckly lookup the Index to fInd a partIcular value. t
then follows the poInter to locate the row contaInIng the value.

n FIgure 46, the Index Is created on the Account_No whIch In turn poInts to the
correspondIng rows In the table.

Note: The SQL user, who accesses a table, Is unaware of the presence or
absence of the Index on the table.


FIgure 4-6: An Index on the Customer_0etaIIs tabIe on coIumn Account_No

Advantages of havIng an IN0EX:
t speeds up the executIon of SQL statements wIth search condItIons that refer to the
Indexed column(s)
t Is most approprIate when retrIeval of data from tables Is more frequent than Inserts
and updates

0Isadvantages of havIng an IN0EX:
t consumes addItIonal dIsk space
The N0EX must be updated every tIme a row Is added to the table and every tIme the
Indexed column Is updated In an exIstIng row. ThIs Imposes addItIonal overhead on
NSEFT and UP0ATE statements for the table

Note:
|ost F08|S products automatIcally create an Index on the prImary key
of a table because they antIcIpate that most frequently access to the
table Is vIa the prImary key

|ost F08|S products also automatIcally create an Index on any column
(or column combInatIon) defIned wIth a unIque constraInt. The F08|S
must check the value of such a column whenever a new row Is
Inserted, or an exIstIng row Is updated, to make certaIn that the value
does not duplIcate a value already contaIned In the table. WIthout the
Index on the column(s), the F08|S would have to sequentIally search
through every row of the table to check the constraInt. WIth an Index,
the F08|S can sImply use the Index to fInd a row (If It exIsts) wIth the
value In questIon, whIch Is a much faster operatIon than a sequentIal
search

When the prImary key of the table or the unIque constraInt on
column(s) Is dropped, the Index whIch was buIlt on them Is also
dropped automatIcally

CREATE [UNIQUE] INDEX index-name on table-name (column-name)

FIgure 4-7: CPEATE IN0EX statement syntax dIagram

FIgure 4-8: 0PDP IN0EX statement syntax dIagram
Examle:
1. Create a sImple Index for the Customer_0etaIls table on Cust_0

CkLA1L uNlquL lNDLX Cusfldx
ON CusfomeDefa11s {CusflD}

2. Create a composIte Index for the Customer_0etaIls table on Cust_0 and Account_No

CkLA1L uNlquL lNDLX lDAccounfNoldx
ON CusfomeDefa11s {CusflD, AccounfNo}

J. 0rop the Index created earlIer

DkOP lNDLX lDAccounfNoldx

Note: The keyword UNQUE In the CFEATE N0EX statement Is optIonal. f the keyword
UNQUE Is omItted, the Index table may have duplIcates entrIes.

PoInts to Pemember:
The CFEATE TA8LE statement creates a table and defInes Its columns,
PF|AFY KEY, FDFECN KEY(s) and other constraInts lIke UNQUE and
NDT NULL

The 0FDP TA8LE statement removes a prevIously created table from
the database

The ALTEF TA8LE statement can be used to add a column to an
exIstIng table, modIfy a column defInItIon, add/drop a PF|AFY KEY,
FDFECN KEY and other constraInts lIke UNQUE and NDT NULL

The CFEATE N0EX statement can be used to defIne Indexes, whIch
speeds up database querIes but add overheads to database updates
4.6. 0ata hanIpuIatIon Language (0hL) Statements
The 0|L statements are used to:
nsert data Into the table
0elete data from the table
FetrIeve data from the table
|odIfy/update data In the table
4.6.1. INSEPT Statement
SInglerow Insert: A sInglerow NSEFT statement adds a sIngle new row of data to the table.

The SIngIe-Pow INSEPT statement

FIgure 4-: SIngIe-row Insert statement syntax dIagram
INSERT INTO Customer_Details
( Cust_D, Cust_Last_Name, Cust_Mid_Name, Cust_First_Name,Account_No, Account_Type, Bank_Branch, Cust_Email)
VALUES ( 106,'Costner', 'A.', 'Kevin', 3350, 'Savings', 'Brighton', 'Costner_Kevin@times.com' );
106Costner A. Kevin 3350Savings Costner_Kevin@times.com Brighton
Cust_IDCust_Last_
Name
Account
_No
Account_
Type
Savings
Checking
Savings
Checking
Checking
Cust_Mid
_Name
A.
S.
G.
D.
E.
Cust_First
_Name
Mike
Graham
Justin
Jack
Simon
Customer_Details table

FIgure 4-10: InsertIng a sIngIe row

Note: The purpose of the column lIst In the NSEFT statement Is to match the
data values In the 7ALUES clause wIth the columns. The lIst of values and the
column lIst must both contaIn the same number of Items, and the data type
of each value must be compatIble wIth the data type of the correspondIng
column, or an error wIll occur.

0ata of type Char, 7archar2 and 0ate are always enclosed wIthIn sIngle quotes.
Examle: 'Costner', '12Jan2005'.

Users can use the SELECT * from tablename to vIew the records Inserted Into the specIfIed
table. The SELECT statement Is covered In detaIl In SectIon 4.6.4.

Examle oj lnvald lNSERT statements:

lN5Lk1 lN1O CusfomeDefa11s
{CusflD, CusfLasfName, CusfM1dName, CusfI1sfName,
AccounfNo, Accounf1ype, 8ank8anch}
vALuL5 {106, `Cosfne`, À.`, `kev1n`, 3350, `5av1ngs`, `81ghfon`,
Cosfnekev1n0f1mes.com`}

The above NSEFT statement Is InvalId because the number of values In the 7ALUES clause
exceeds the number of columns that are to receIve them.

AccounfNo, Accounf1ype, 8ank8anch, CusfLma11}
vALuL5 {106, `Cosfne`, À.`, `kev1n`, 3350, `5av1ngs`,`81ghfon`}

The above NSEFT statement Is InvalId because the number of values In the 7ALUES clause Is
less than the columns that are to receIve them.

Assume Account_No Is the PrImary Key for the Customer_0etaIls table

Accounf1ype, 8ank8anch}
vALuL5 {106, `Cosfne`, À.`, `kev1n`, `5av1ngs`, `81ghfon`}

The above NSEFT statement Is InvalId because the column lIst specIfIed does not Include the
attrIbute, Account_No whIch happens to be the prImary key for the table. 8ecause It has not
been Included In the column lIst, SQL automatIcally assIgns a NULL value to It. 8eIng a
prImary key attrIbute It cannot have a NULL value.

InsertIng NULL vaIues
SQL supports mIssIng, unknown, or InapplIcable data explIcItly, through the concept of a NULL
value. A NULL value Is an IndIcator that tells SQL (and the user) that the data Is mIssIng or not
applIcable. 8ut the NULL value Is not a real data value lIke 0, 47J.8J or 'John Clark'. The
NULL value occupIes space.

FIgure 4-11: NULL VaIues In the Customer_0etaIIs TabIe

When SQL Inserts a new row of data to a table, It automatIcally assIgns a NULL value to any
column whose name Is mIssIng from the column lIst In the NSEFT statement.

Examle:

The assIgnment of NULL value can be made more explIcIt by IncludIng these columns In the
column lIst and specIfyIng the keyword NULL In the values lIst.

Examle:

InsertIng aII coIumns:
SQL permIts omIttIng of the column lIst from the NSEFT statement. When the column lIst Is
omItted, SQL automatIcally generates a column lIst consIstIng of all columns of the table, In
left to rIght sequence.

Examle:

Note: When the column lIst Is omItted, the NULL keyword must be used In the
values lIst to explIcItly assIgn NULL values to columns. n addItIon, the
sequence of data values must correspond exactly to the sequence of columns
In the table.

Examle:
To nsert a row Into the Customer_TransactIon Table

lN5Lk1 lN1O Cusfome1ansacf1on
vALuL5 {2367,17-JAN-2005,Depos1f`, 2000.00, 14456}

Note: The 0ate value should be Input In the format 'ddmmmyyyy' or
'ddmmmyy'.

ExampIe of InvaIId INSEPT Into the Customer_0etaIIs TabIe
lN5Lk1 lN1O CusfomeDefa11s vALuL5 {106,`Cosfne`}

n the above NSEFT statement, the column lIst Is omItted. The value for all columns should
have been provIded but the value for only Cust_0 and Cust_Last_Name Is provIded.
4.6.2. 0ELETE Statement
The 0ELETE statement can delete one or more rows from a table.

Note: Even If all the data Is deleted from the table, the defInItIon of the table
and Its column Is stIll stored In the database. The table stIll exIsts. To erase
the defInItIon of the table from the database, the 0FDP TA8LE statement
must be used.

The 0ELETE statement cannot delete column(s) from a table. t deletes only
row(s). To delete a column from a table, the ALTEF TA8LE statement must be
used.

FIgure 4-12: The 0ELETE statement syntax dIagram
Examle:
1. 0eletIng all rows of a table 0elete all current customers

DLLL1L
IkOM CusfomeDefa11s

2. 0eletIng some rows of a table 0elete Customer wIth Cust_0=102 from the lIst of
customers

DLLL1L
IkOM CusfomeDefa11s
WhLkL CusflD = 102

J. Examples of InvalId 0ELETE Statements

DLLL1L "
IkOM CusfomeDefa11s

DF

DLLL1L CusflD
IkOM CusfomeDefa11s

0Ifference between TPUNCATE and 0ELETE statement
TFUNCATE Is a 00L statement whereas 0ELETE Is a 0|L statement
TFUNCATE deletes all records from the table whereas 0ELETE can be used to
selectIvely delete records from a table usIng the WHEFE clause
TFUNCATE releases the memory occupIed by the records of the table whereas 0ELETE
does not do so
0ata removed usIng TFUNCATE cannot be recovered whereas data removed usIng
0ELETE can be recovered (usIng FDLL8ACK, a 0CL statement whIch Is covered In
chapter 5)
4.6.3. UP0ATE Statement
The UP0ATE statement modIfIes the values of one or more columns In selected rows of a
table.

The target table to be updated Is named In the statement. The 'WHEFE clause' selects the
rows of the table to be modIfIed. The 'SET clause' specIfIes whIch columns are to be updated
and calculates the new values for them.

FIgure 4-13: UP0ATE statement syntax dIagram

Examle:
1. ChangIng all rows

UntIl fresh InstructIons come In, delete Fate_of_nterest values for all customers.

uPDA1L CusfomeI1xedDepos1f
5L1 kafeoflnfeesf1nPecenf = NuLL

2. ChangIng some rows

For customers wIth a fIxed deposIt J000, Increase Fate_of_nterest to 7.J.

5L1 kafeoflnfeesf1nPecenf = 7.3
WhLkL Amounf1nDo11as > 3000

J. ChangIng the value for more than one column.

Change the EmaIl_0 and Fate_of_nterest of Customer (Cust_0 = 104)

5L1 CusfLma11 = `qua11sJack0ed1ffma11.com`,
kafeoflnfeesf1nPecenf = 7.3
WhLkL CusflD = 104

4.6.4. SELECT Statement
The SELECT statement retrIeves data from a database and returns It In the form of query
results. Fefer to FIgure 414. The result of a SQL query Is always a table of data.


FIgure 4-14: SELECT statement syntax dIagram

FIgure 4-15: The tabuIar pIcture of SL query resuIts

4.6.4.1. SImpIe SELECT Statement
The SELECT statement Is used to select eIther some or all the columns from a table.

The asterIsk (*) character Is a wIldcard that Is used to denote all columns. t Is a good
programmIng practIce to avoId the use of SELECT *. t Is better to lIst the column names.

Examle:
1. SelectIng all columns

LIst all InformatIon about all the customers

5LLLC1 CusflD, CusfLasfName, CusfM1dName, CusfI1sfName,
AccounfNo, Accounf1ype, 8ank8anch, CusfLma11
IkOM CusfomeDefa11s
Dr

5LLLC1 "
IkOM CusfomeDefa11s

2. SelectIng some columns

LIst Cust_0, Account_No of all customers

5LLLC1 CusflD, AccounfNo
IkOM CusfomeDefa11s
4.6.4.2. AvoIdIng dupIIcates (0ISTINCT)
8y default the SELECT statement retrIeves all rows that are fIltered by the SELECT statement.
ThIs may however contaIn duplIcates rows. n order to elImInate duplIcate rows from the
result set returned by the SELECT statement use the keyword 0STNCT. The default keyword
Is ALL.

Examle:
1. LIst all customers name

5LLLC1 ALL CusfLasfName
IkOM CusfomeDefa11s

ThIs Is equIvalent to:

5LLLC1 CusfLasfName
IkOM CusfomeDefa11s

2. ThIs Is lIkely to return duplIcate rows. To avoId thIs:

5LLLC1 Dl51lNC1 CusfLasfName
IkOM CusfomeDefa11s
4.6.4.3. Pow SeIectIon (WHEPE cIause)
The WHEFE clause Is used to specIfy a search condItIon that lImIts the number of rows
retrIeved. t Is a row wIse operatIon.


For each row, the search condItIon can produce one of the three results:
f the search condItIon Is true, the row Is Included In the query results
f the search condItIon Is false, the row Is excluded from the query results
f the column beIng searched has a NULL value, the row Is excluded from the query
results
ProbIem Statement: To select rows whIch have 102 In the |anager column.

FIgure 4-16: Pow seIectIon wIth the WHEPE cIause
Examle:
1. LIst all customers wIth an account balance S10000

5LLLC1 AccounfNo, 1ofa1Ava11ab1e8a1ance1nDo11as
IkOM Cusfome1ansacf1on
WhLkL 1ofa1Ava11ab1e8a1ance1nDo11as > 10000.00

2. LIst the Cust_0, Account_No of 'Craham'.

5LLLC1 CusflD, AccounfNo
IkOM CusfomeDefa11s
WhLkL CusfI1sfName = `Gaham`

Note: The comparIson Is case sensItIve. The columnnames are not casesensItIve; the values
of the column(s) are case sensItIve.

For Example: 'CFAHA|' Is not the same as 'graham' or 'Craham'
The WHEFE clause can be used wIth any of the comparIson operators (=, , , =, =, ) or
the logIcal operators (AN0, DF, NDT).

FIgure 4-17: ComparIson test syntax dIagram
When SQL compares the values of the two expressIons In the comparIson test, three results
can occur:
1. The test may yIeld a TFUE result
2. The test may yIeld a FALSE result
J. f eIther of the two expressIons produces a NULL value, the comparIson yIelds a NULL
result.

Examle:
1. LIst all Account_No where Total_AvaIlable_8alance_In_0ollars Is atleast S10000.00

5LLLC1 AccounfNo
WhLkL 1ofa1Ava11ab1e8a1ance1nDo11as >= 10000.00

2. LIst all Cust_0, Cust_Last_Name where Account_type Is 'SavIngs' and 8ank_8ranch Is
'0owntown'.

5LLLC1 CusflD, CusfLasfName
IkOM CusfomeDefa11s
WhLkL Accounf1ype = `5av1ngs`
AND 8ank8anch = `DoWnfoWn`

J. LIst all Cust_0, Cust_Last_Name where neIther Account_type Is 'SavIngs' and nor
8ank_8ranch Is '0owntown'.

IkOM CusfomeDefa11s
WhLkL NO1 Accounf1ype = `5av1ngs`
AND NO1 8ank8anch = `DoWnfoWn`

4. LIst all Cust_0, Cust_Last_Name where eIther Account_type Is 'SavIngs' or 8ank_8ranch Is
'0owntown'.

IkOM CusfomeDefa11s
Ok 8ank8anch = `DoWnfoWn`

The huItI-Pow INSEPT statement (the dIscussIon of muItI-row Insert was deferred because
It uses a SELECT statement)
A multIrow NSEFT statement extracts rows of data from another part of the database and
adds them to a table.
n thIs form of the NSEFT statement, the data values for the new rows are not explIcItly
specIfIed wIthIn the statement text. nstead, the source of new rows Is a database query,
specIfIed In the statement as shown In FIgure 419.

FIgure 4-18: huItI-row INSEPT statement syntax dIagram
Examle:
lN5Lk1 lN1O O1dCusfdefa11s
{AccounfNo, 1ansacf1onDafe,1ofa1Ava11ab1e8a1ance1nDo11as}
5LLLC1 AccounfNo,1ansacf1onDafe,1ofa1Ava11ab1e8a1ance1nDo11as
Iom Cusfome1ansacf1on

SELECT Account_No, Transaction_Date, Total_Available_Balance_in_Dollars
FROM Customer_Transaction
WHERE Total_Available_Balance_in_Dollars > 10000
Account_No
TotaI_AvaiIabIe_BaIance
_in_DoIIars
2367 12456.00
3421 27234.00
2348 13500.00
Transaction_
Date
14-Jan-2005
14-Jan-2005
16-Jan-2005
Query Results
Account_No TotaI_AvaiIabIe_BaIance
_in_DoIIars
2348 13500.00
3421 27234.00
2367 12456.00
Transaction_
Date
14-Jan-2005
14-Jan-2005
16-Jan-2005
OldCust_details Table
Query uses data from
Customer_Transaction table
Account
_No
Transaction
_Date
Transaction
_Type
Transaction_Amount
_in_DoIIars
TotaI_AvaiIabIe_BaIance
_in_DoIIars
102012-Jan-2005 Deposit 5000.00 10000.00
234814-Jan-2005 Withdrawal 2500.00 13500.00
342114-Jan-2005 Deposit 2000.00 27234.00
236716-Jan-2005 Withdrawal 1200.00 12456.00
102017-Jan-2005 Withdrawal 1500.00 8500.00
Customer_Transaction records from Customer_Transaction table
Step 1
Step 2

FIgure 4-1: InsertIng huItIpIe Pows
The logIcal restrIctIons on the query that appears wIthIn the multIrow NSEFT statement:

The query results must contaIn the same number of columns as the column lIst In the NSEFT
statement and the data types must be compatIble, column by column

4.6.4.4. ETWEEN, IN, LIKE
The 8ETWEEN operator Includes both the end values specIfIed.

The N operator Is used to check If a value belongs to a set of values.

Note that 8ETWEEN and N can be fully substItuted wIth a combInatIon of AN0, DF, NDT.

The LKE operator Is used to check for sImIlarIty of strIngs.

When used wIth LKE the use of "_" refers to exactly one unknown character; "" refers to an
unknown number of unknown characters.

FIgure 4-20: Pange test (etween) syntax dIagram

FIgure 4-21: Set membershIp test (IN) syntax dIagram

FIgure 4-22: Pattern matchIng test (LIKE) syntax dIagram
Examle:
1. LIst all Account_Nos wIth balance In the range S10000.00 to S20000.00.

5LLLC1 AccounfNo
WhLkL 1ofa1Ava11ab1e8a1ance1nDo11as
8L1WLLN 10000.00 AND 20000.00
Dr

5LLLC1 AccounfNo
WhLkL 1ofa1Ava11ab1e8a1ance1nDo11as >= 10000.00
AND 1ofa1Ava11ab1e8a1ance1nDo11as <= 20000.00

2. LIst all customers who have account In 0owntown or 8rIghton.

5LLLC1 CusflD
IkOM CusfomeDefa11s
WhLkL 8ank8anch lN {`DoWnfoWn`, `81ghfon`}

Dr

5LLLC1 CusflD
IkOM CusfomeDefa11s
WhLkL 8ank8anch = `DoWnfoWn`
Ok 8ank8anch = `81ghfon`

J. LIst all Accounts where the 8ank_8ranch begIns wIth a '0' and has 'o' as the second
character.

5LLLC1 CusflD, CusfLasfName, AccounfNo
IkOM CusfomeDefa11s
WhLkL 8ank8anch LlkL `Dox`

4. LIst all Accounts where the 8ank_8ranch column has 'o' as the second character.

5LLLC1 CusflD, CusfLasfName, AccounfNo
IkOM CusfomeDefa11s
WhLkL 8ank8anch LlkL òx`

5. LIst all Account_Nos wIth balance not In the range S10000.00 to S20000.00.

5LLLC1 AccounfNo
WhLkL 1ofa1Ava11ab1e8a1ance1nDo11as
NO1 8L1WLLN 10000.00 AND 20000.00
4.6.4.5. IS NULL, IS NDT NULL
The NULL value Is used to IndIcate the absence of a value. t Is not a zero or blank character.
NULL cannot be compared to any other value. f compared, sInce the result of the comparIson
cannot be determIned, the result of the comparIson Is also a NULL.

FIgure 4-23: NULL vaIue test (IS NULL) syntax dIagram

Note: A NULL value Is not equal to another NULL value. The result of
comparIng two NULL values Is NULL. t Is neIther TFUE nor FALSE.

Examle:
1. LIst employees who have not been assIgned a |anager yet.

5LLLC1 Lmp1oyeelD
IkOM Lmp1oyeeManage
WhLkL ManagelD l5 NuLL

2. LIst employees who have been assIgned to some |anager.
5LLLC1 Lmp1oyeelD
IkOM Lmp1oyeeManage
WhLkL ManagelD l5 NO1 NuLL
4.6.4.6. CoIumn tItIes usIng AS
When the SELECT statement returns a column, the tItle of the result column set Is the name
of the column. f the statement Includes an evaluated expressIon, the column tItle Is a
default name that the F08|S gIves the expressIon.

To gIve meanIngful column tItles use the keyword AS.

Examle:
LIst those customer accounts whose account balance Is greater than S10000.00.

5LLLC1 AccounfNo A5 Cusfome Accounf No.,
1ofa1Ava11ab1e8a1ance1nDo11as A5 1ofa1 8a1ance
4.6.4.7. SortIng uery PesuIts (DP0EP Y cIause)
The rows of the query results are not arranged In any partIcular order. SQL can sort the
results of a query by IncludIng the DF0EF 8Y clause In the SELECT statement. The DF0EF 8Y
Is a rowwIse operatIon. 8y default the DF0EF 8Y clause arranges the rows of the query result
In ascendIng order. To arrange the rows of the query result In descendIng order, use the
keyword 0ESC.

FIgure 4-24: The DP0EP Y cIause syntax dIagram
Examle:
1. LIst the customers account numbers and theIr account balances, In the IncreasIng order of
the balance.

5LLLC1 AccounfNo, 1ofa1Ava11ab1e8a1ance1nDo11as
OkDLk 8Y 1ofa1Ava11ab1e8a1ance1nDo11as

2. LIst the customers and theIr account numbers In the decreasIng order of the account
numbers.

5LLLC1 CusfLasfName, CusfI1sfName, AccounfNo
IkOM CusfomeDefa11s
OkDLk 8Y 3 DL5C

Note: DF0EF 8Y clause can be followed by the column name or the posItIon of the column as
It appears In the SELECT statement.

J. LIst the customers and theIr account numbers In the decreasIng order of the Customer
Last Name and IncreasIng order of account numbers.

IkOM CusfomeDefa11s
OkDLk 8Y CusfLasfName DL5C, AccounfNo
Dr

IkOM CusfomeDefa11s
OkDLk 8Y 1 DL5C, 3
4.6.4.8. Aggregate FunctIons l CoIumn FunctIons
SQL allows summarIzIng data from the database through a set of column functIons. A SQL
column functIon takes an entIre column of data as Its arguments and produces a sIngle data
Item that summarIzes the column.

FollowIng are some of the wIdely used column functIons:

SU|() : computes the total of a column

A7C() : computes the average value In a column

|N() : fInds the smallest value In a column

|AX() : fInds the largest value In a column

CDUNT() : counts the number of nonNULL values In a column

CDUNT (*): counts rows of query results and does not depend on the presence or
absence of NULL values In a column. f there are no rows, It returns a value of zero.

Note: Fows that have a NULL value In the relevant column are Ignored by all
the above aggregate functIon except count (*).


FIgure 4-25: CoIumn functIons syntax dIagram
Examle:
1. LIst the mInImum account balance.

5LLLC1 MlN {1ofa1Ava11ab1e8a1ance1nDo11as}

2. LIst the maxImum account balance.

5LLLC1 MAX {1ofa1Ava11ab1e8a1ance1nDo11as}

J. LIst the average account balance of customers.

5LLLC1 AvG {1ofa1Ava11ab1e8a1ance1nDo11as}

4. LIst total number of account holders In the '0owntown' 8ranch.

5LLLC1 COuN1 {"}
IkOM CusfomeDefa11s
WhLkL 8ank8anch = `DoWnfoWn`

5. LIst total number of Customers.

5LLLC1 COuN1 {"}
IkOM CusfomeDefa11s

6. LIst number of Customers havIng "SavIngs" Account.

5LLLC1 COuN1 {"}
IkOM CusfomeDefa11s

7. LIst the mInImum and sum of all account balances.

5LLLC1 MlN {1ofa1Ava11ab1e8a1ance1nDo11as},
5uM {1ofa1Ava11ab1e8a1ance1nDo11as}

8. LIst total number of unIque Customer Last Names.

5LLLC1 COuN1 {Dl51lNC1 CusfLasfName}
IkOM CusfomeDefa11s

0Ifference between CDUNT(*) and CDUNT(Columnname):

9. LIst total number of Employees.

5LLLC1 COuN1 {"}
IkOM Lmp1oyeeManage

10. LIst total number of Employees who have been assIgned a |anager.

5LLLC1 COuN1 {ManagelD}
IkOM Lmp1oyeeManage

Note: CDUNT (ColumnName) counts the number of nonNULL values In a column whereas
CDUNT (*) counts rows of query results and does not depend on the presence or absence of
NULL values In a column.

4.6.4.. CPDUP Y
The CFDUP 8Y clause Is used In a SELECT statement to collect data across multIple records
and group the results by one or more columns.

SometImes It Is requIred to get InformatIon not about each row, but about each group.

Examle: Consder the Customer_Locn tcble thct hcs dctc cbout cll the locns tcken by cll
the customers o] the bcnk. Assume thct we wcnt to retreve the totcl locncmount o] cll
locns tcken by ecch customer.

Felated rows can be grouped together by the CFDUP 8Y clause by specIfyIng a column as a
groupIng column.

n the above example, the Cust_0 wIll be the groupIng column.

n the output table all the rows wIth an IdentIcal value In the groupIng column wIll be
grouped together. Hence, the number of rows In the output Is equal to the number of dIstInct
values of the groupIng column.

FIgure 4-26: ExampIe of Croup Y CIause

SELECT Department, COUNT (Employee_D) FROM Employee_Manager GROUP BY Department ;
Department Count(EmpIoyee_ID)
HR 3
Finance 3
Design 2
Query Results
EmpIoyee
_ID
EmpIoyee_
Last_Name
EmpIoyee_
Mid_Name
EmpIoyee_
First_Name
Department
2345Atherton S. Cindy HR
3556George A. Henry Finance
22789Stevenson S. Crystal HR
23456Smith A. Luther Finance
Grade
1
1
2
2
Manager_ID
NULL
NULL
2345
3556
30456Langer C. Christiana HR 3 2345
31234Frost J. Robert Finance 3 3556
32345Austen L. Jane Design 2 3620
3620Jackson G. Matt Design 1 NULL
EmpIoyee_EmaiI
Atherton_Cindy@yahoo.com
George_Henry@rediffmail.com
Jackson_Matt@samsonite.co.in
Stevenson_Crystal@mag.com
Smith_Luther@yahoo.com
Langer_Christiana@rediffmail.com
Frost_Robert@training.com
Austen_Jane@yahoo.com
Records from EmpIoyee_Manager TabIe
GROUP BYDepartment

FIgure 4-27: ExampIe of CPDUP Y cIause


FIgure 4-28: ExampIe of CPDUP Y cIause
F CFDUP 8Y clause has been used In a SELECT statement, all the rows wIth an IdentIcal value
In the groupIng column wIll be grouped together.

Dnce the CFDUP 8Y clause Is used, the aggregate functIons In the SELECT statement are
calculated after groupIng I.e., there Is one value of the aggregate column for each value of
the groupIng column.

Examle: Re]er to FIgure 428. ln the excmple, the yroupny s bcsed on the Mcncyer_l0
column. There cre three records wth N0LL vclues n the Mcncyer_l0 column. All the three
records cre plcced n the scme yroup. lt s the yroup wth ndetermncte vclues. Ths does
not mply thct N0LL vclues cre equcl.

Note: f the CFDUP 8Y clause has been used In a SELECT statement, only the
groupIng columns (columns on whIch groupIng has been done) or aggregate
functIons can appear In the column lIst specIfIed In the SELECT statement.

Examle:

InvaIId SL statement

5LLLC1 Depafmenf, ManagelD, COuN1{Lmp1oyeelD}
IkOM Lmp1oyeeManage
GkOuP 8Y ManagelD


The above SQL statement should be wrItten as:

5LLLC1 Depafmenf, ManagelD, COuN1{Lmp1oyeelD}
IkOM Lmp1oyeeManage
GkOuP 8Y ManagelD, Depafmenf


SELECT Department, Manager_D, COUNT (Employee_D) FROM Employee_Manager
GROUP BY Manager_D, Department ;
Manager_ID Count(EmpIoyee_ID)
2345 2
3556 2
3620 1
NULL 1
Department
HR
Finance
Design
HR
Design NULL 1
Finance NULL 1
Query Results
EmpIoyee
_ID
EmpIoyee_
Last_Name
EmpIoyee_
Mid_Name
EmpIoyee_
First_Name
Department
Grade
1
1
2
2
Manager_ID
NULL
NULL
2345
3556
EmpIoyee_EmaiI
Group By Manager_D,Department

FIgure 4-2: An exampIe of CPDUP Y cIause
4.6.4.10. HAVINC
The HA7NC clause Is used along wIth the CFDUP 8Y clause. The HA7NC clause can be used
to select and reject row groups. The format of the HA7NC clause Is sImIlar to the WHEFE
clause, consIstIng of the keyword HA7NC followed by a search condItIon. The HA7NC clause
thus specIfIes a search condItIon for groups.

FIgure 4-30: An exampIe of HAVINC CIause
SELECT Department, COUNT (Employee_D) FROM Employee_Manager GROUP BY Department HAVNG COUNT(Employee_D) > 2 ;
Department Count(EmpIoyee_ID)
HR 3
Finance 3
Query Results
EmpIoyee
_ID
EmpIoyee_
Last_Name
EmpIoyee_
Mid_Name
EmpIoyee_
First_Name
Department
Grade
1
1
2
2
Manager_ID
NULL
NULL
2345
3556
EmpIoyee_EmaiI
GROUP BYDepartment

FIgure 4-31: An exampIe of HAVINC CIause


Note: The WHEFE clause can be used to select and reject the IndIvIdual rows
that partIcIpate In a query. The HA7NC clause can be used to select and
reject row groups.

4.6.4.11. PetrIevaI usIng UNIDN
The UNDN operatIon combInes the rows from two sets of query results. 8y default, the UNDN
operatIon elImInates duplIcate rows as part of Its processIng.

Examle:
5LLLC1 CusflD
IkOM CusfomeI1xedDepos1f

uNlON

5LLLC1 CusflD
IkOM CusfomeLoan

Fefer to FIgure 4J2.

To retaIn duplIcate rows In a UNDN operatIon, specIfy the ALL keyword ImmedIately
followIng the word UNDN.

Examle:
SELECT Cust_0
FFD| Customer_FIxed_0eposIt

UNDN ALL

SELECT Cust_0
FFD| Customer_Loan;

Fefer to FIgure 4JJ.

101 1011 8755.00
103 2010 2555.00
104 2056 3050.00
103 2015 2000.00
_No
Amount_in_
DoIIars
101 2011 8055.00
103 2015 2060.00
104 3010 3050.00
Cust_Last_
Name
Smith
Langer
Quails
Cust_Mid
_Name
A.
G.
D.
Cust_First
_Name
Mike
Justin
Jack
Rate_of_Interest
_in_Percent
6.5
6.5
6.5
Cust_EmaiI
Customer_Fixed_Deposit records from Customer_Fixed_Deposit table
Cust_ID
101
103
104
Cust_ID
101
103
104
103
UNION
101
103
104
Query ResuIts

FIgure 4-32: UsIng UNIDN to combIne query resuIts

101 1011 8755.00
103 2010 2555.00
104 2056 3050.00
103 2015 2000.00
_No
Amount_in_
DoIIars
101 2011 8055.00
103 2015 2060.00
104 3010 3050.00
Cust_Last_
Name
Smith
Langer
Quails
Cust_Mid
_Name
A.
G.
D.
Cust_First
_Name
Mike
Justin
Jack
Rate_of_Interest
_in_Percent
6.5
6.5
6.5
Cust_EmaiI
Customer_Fixed_Deposit records from Customer_Fixed_Deposit table
Cust_ID
101
103
104
Cust_ID
101
103
104
103
UNION ALL
101
104
103
104
103
101
103
Query ResuIts

FIgure 4-33: UsIng UNIDN ALL to combIne query resuIts
There are some restrIctIons on the table that can be combIned by a UNDN operatIon:

The SELECT statements combIned usIng UNDN or UNDN ALL must contaIn the same
number of columns
The data type of each column In the fIrst table must be the same as the data type of
the correspondIng column In the second table. The data wIdth and column name can
dIffer
NeIther of the two tables can be sorted wIth the DF0EF 8Y clause. However, the
combIned query results can be sorted

Note: ElImInatIng duplIcate rows from query results Is a tImeconsumIng
process, especIally If the query results contaIn a large number of rows. f one
Is sure that the UNDN operatIon cannot produce duplIcate rows, one should
specIfIcally use the UNDN ALL operatIon because the query wIll execute much
more quIckly.

4.6.4.12. PetrIevaI usIng INTEPSECT
The NTEFSECT operatIon selects the common row from two sets of query results.

Examle:
5LLLC1 CusflD

lN1Lk5LC1

5LLLC1 CusflD
IkOM CusfomeLoan

FIgure 4-34: UsIng INTEPSECT to combIne query resuIts

4.6.5. Sub-uerIes
A subquery Is a query wIthIn a query. The results of the subquery are used by the 08|S to
determIne the results of the hIgherlevel query that contaIns the subquery. Usually, the sub
query appears wIthIn the WHEFE or HA7NC clause of another SQL statement.

FIgure 4-35: asIc sub-query syntax dIagram
The sub-query s enclosed n arentheses, but otherwIse It has a form sImIlar to that of a
SELECT statement, wIth a FFD| clause and optIonal WHEFE, CFDUP 8Y, and HA7NC clauses.
The form of these clauses In a subquery Is IdentIcal to that In a SELECT statement, and they
perform theIr normal functIons when used wIthIn a subquery.
4.6.5.1. Independent Sub-uerIes
nner Query Is Independent of Duter Query
nner Query Is executed fIrst and the results are stored
Duter Query then runs on the stored results

Examle: To lst the Cust_l0 cnd Locn_No ]or cll Customers who hcve tcken c locn o]
cmount yrecter thcn the locn cmount o] Customer (Cust_l0 = 104).

FIgure 4-36: How an Independent sub-query executes
The Inner query, whIch retrIeves the Amount_In_0ollars of Cust_0, 104 can be executed
Independent of the outer query. Hence the name Independent subquery.

The Inner query needs to be executed only once, sInce It returns one constant value
IrrespectIve of the outer query.
n the above example, the Innermost query Is executed fIrst, the result Is stored and then the
outer query Is executed for each row of the Customer_Loan table.
The Inner query Is executed only once, whIle the outer one Is executed as many tImes as the
number of rows In the Customer_Loan table.

Examle:
1. LIst customer names of all customers who have taken a loan SJ000.00.

5LLLC1 CusfLasfName, CusfM1dName, CusfI1sfName
IkOM CusfomeDefa11s
WhLkL CusflD lN
{ 5LLLC1 CusflD
IkOM CusfomeLoan
WhLkL Amounf1nDo11as > 3000.00}

2. LIst customer names of all customers who have the same Account_type as Customer
'Jones SImon'.

IkOM CusfomeDefa11s
WhLkL Accounf1ype =
{ 5LLLC1 Accounf1ype
IkOM CusfomeDefa11s
WhLkL CusfLasfName = `Jones`
AND CusfI1sfName = `51mon`}

J. LIst customer names of all customers who do not have a FIxed 0eposIt.

IkOM CusfomeDefa11s
WhLkL CusflD NO1 lN
{ 5LLLC1 CusflD
IkOM CusfomeI1xedDepos1f}

4. LIst customer names of all customers who have eIther a FIxed 0eposIt or a loan but not
both at any of the 8ank 8ranches. t wIll Include names that have no fIxed deposIt and
loan as well.

IkOM CusfomeDefa11s
WhLkL CusflD NO1 lN
{ 5LLLC1 CusflD
IkOM CusfomeLoan
WhLkL CusflD lN
{5LLLC1 CusflD
IkOM CusfomeI1xedDepos1f}}
4.6.5.2. Co-PeIated Sub-uerIes
n corelated subquerIes, SQL performs a subquery, once for each row of the maIn query.
The column(s) from the table of the outer query Is always referred In the Inner query.

Examle: To lst cll Customers who hcve c ]xed depost o] cmount less thcn the sum o] cll
ther locns.

uery:

FIgure 4-37: A CorreIated uery
Exlanaton oj the query:
The nner query s repected once ]or every record o] the outer query. The outer query uses
the Customer_Fxed_0epost tcble. Re]er to Fyure 4J8.

FIgure 4-38: Customer_FIxed_0eposIt tabIe
The nner query uses the Customer_Locn tcble. Re]er to Fyure 4J.

FIgure 4-3: Customer_Loan tabIe
The Customer_Fxed_0epost tcble hcs three records. The nner query wll be repected three
tmes. Ths s smlcr to the nested FDR loop thct hcs been covered n Proyrcmmny
Fundcmentcls course.

For the jrst record n the Customer_Fxed_0eost table:
1. The record wth the vclue o] 101 n the Cust_l0 column o] the Customer_Fxed_0epost
tcble s recd.

2. All records wth c vclue o] 101 n the Cust_l0 column o] the Customer_Locn tcble cre
retreved cnd ther Amount_n_0ollcrs vclues cre summed up. ln the Excmple, there s
only one record wth c vclue o] 101 n the Cust_l0 column cnd the Amount_n_0ollcrs
vclue s $8Z55.00.
101 1011 8755.00
103 2010 2555.00
104 2056 3050.00
103 2015 2000.00
Step 2

J. Ths vclue s compcred wth $8055.00. Snce the tcryet vclue o] $8055.00 s less thcn the
Amount_n_0ollcrs vclue o] $8Z55.00, the record wth the Cust_l0 vclue o] 101 s pcrt o]
the query result.

For the second record n the Customer_Fxed_0eost table:
1. The record wth the vclue o] 10J n the Cust_l0 column o] the Customer_Fxed_0epost
tcble s recd.

2. All records wth c vclue o] 10J n the Cust_l0 column o] the Customer_Locn tcble cre
retreved cnd ther Amount_n_0ollcrs vclues cre summed up. ln the Excmple, there cre
two records wth c vclue o] 10J n the Cust_l0 column cnd the sum o] ther
Amount_n_0ollcrs vclues s $4555.00.
101 1011 8755.00
103 2010 2555.00
104 2056 3050.00
103 2015 2000.00
Step 2

J. Ths vclue s compcred wth $200.00. Snce the tcryet vclue o] $200.00 s less thcn the
sum(Amount_n_0ollcrs) vclue o] $4555.00, the record wth the Cust_l0 vclue o] 10J s
pcrt o] the query result.

For the thrd record n the Customer_Fxed_0eost table:
1. The record wth the vclue o] 104 n the Cust_l0 column o] the Customer_Fxed_0epost
tcble s recd.
_No
Amount_in_
DoIIars
101 2011 8055.00
103 2015 2060.00
104 3010 3050.00
Cust_Last_
Name
Smith
Langer
Quails
Cust_Mid
_Name
A.
G.
D.
Cust_First
_Name
Mike
Justin
Jack
Rate_of_Interest
_in_Percent
6.5
6.5
6.5
Cust_EmaiI
Step 1

2. All records wth c vclue o] 104 n the Cust_l0 column o] the Customer_Locn tcble cre
retreved cnd ther Amount_n_0ollcrs vclues cre summed up. ln the Excmple, there s
only one record wth c vclue o] 104 n the Cust_l0 column cnd the Amount_n_0ollcrs
vclue s $J050.00.
101 1011 8755.00
103 2010 2555.00
104 2056 3050.00
103 2015 2000.00
Step 2

J. Ths vclue s compcred wth $J050.00. Snce the tcryet vclue o] $J050.00 s equcl to the
Amount_n_0ollcrs o] $J050.00, the record wth the Cust_l0 vclue o] 104 s not pcrt o]
the query result.

Dutput of the co-reIated query:

FIgure 4-40: Dutput of co-reIated query


Note: For each row of the Customer_FIxed_0eposIt table to be tested by the
WHEFE clause of the maIn query, the Cust_0 column (whIch appears In the
subquery as an outer reference) has a dIfferent value. Thus SQL carrIes out
thIs subquery once for each row In the Customer_FIxed_0eposIt table.
A subquery contaInIng an outer reference Is called a correlated subquery because Its results
are correlated wIth each IndIvIdual row of the maIn query. For the same reason, an outer
reference Is sometImes called a correlated reference.

Examle:
LIst customer 0s of all customers who have both a FIxed 0eposIt and a loan at any of 8ank
8ranches.

5LLLC1 CusflD
IkOM CusfomeDefa11s
WhLkL CusflD lN
{5LLLC1 CusflD
IkOM CusfomeLoan
WhLkL CusfomeLoan.CusflD = CusfomeDefa11s.CusflD}

AND CusflD lN

{5LLLC1 CusflD
WhLkL CusfomeI1xedDepos1f.CusflD = CusfomeDefa11s.CusflD}
4.6.6. JDINS
JoIn operatIons take two tables and return another table as a result.

CartesIan Product l Cross JoIn

Cross joIns return all rows from the fIrst table. Each row from the fIrst table Is combIned wIth
all rows from the second table. Cross joIns are also known as the Ccrtescn product
41
(or just
the product) of two tables. The columns of the product table are all the columns of the fIrst
table, followed by all the columns of the second table.


41
CartesIan product: A mathematIcal term that, when applIed to relatIonal databases, refers to the
result obtaIned by joInIng all the rows of one table wIth all the rows of another table In every possIble
combInatIon.

FIgure 4-41: The CartesIan product of two tabIes

4.6.6.1. SELF JDIN
JoInIng a table wIth Itself Is a selfjoIn.

Examle:
ProbIem Statement: To lIst all the Employees (Employee_0, Employee_Last_Name,
Employee_FIrst_Name) along wIth theIr |anagers (|anager_0, |anager_Last_Name,
|anager_FIrst_Name).

uery:
5LLLC1 Lmp.Lmp1oyeelD as Lmp1oyee lD,
Lmp.Lmp1oyeeLasfName as Lmp1oyee Lasf Name,
Lmp.Lmp1oyeeI1sfName as Lmp1oyee I1sf Name,
Lmp.ManagelD as Manage lD,
Manage.Lmp1oyeeLasfName as Manage Lasf Name,
Manage.Lmp1oyeeI1sfName as Manage I1sf Name
IkOM Lmp1oyeeManage Lmp, Lmp1oyeeManage Manage
WhLkL Lmp.ManagelD = Manage.Lmp1oyeelD

ProcessIng of the uery:

Step 1: The table Employee_|anager has two alIases (another name), Emp and |anager.

Step 2: |anager_0 attrIbute of Emp (alIas for Employee_|anager) Is matched wIth
Employee_0 attrIbute of |anager (alIas for Employee_|anager). The FIgure below shows the
matchIng of only two records. The other records are matched sImIlarly.

Step 3: The columns that appear In the output table are specIfIed In the column lIst used
wIth the SELECT statement.

FIgure 4-42: Dutput of SELF JDIN
4.6.6.2. INNEP JDINS
An Inner joIn between two (or more) tables Is the CartesIan product that satIsfIes the joIn
condItIon In the WHEFE clause.

nner joIns use a comparIson operator lIke = or to match rows from two tables based on the
values In common columns from each table.

nner JoIns Include EquIJoIns A joIn In whIch the joInIng condItIon Is based on equalIty
between values In the common columns.

Examle:
5LLLC1 1ab1e1.LmplD, 1ab1e1.C1fy, 1ab1e2.CusflD, 1ab1e2.C1fy
IkOM 1ab1e1, 1ab1e2
WhLkL 1ab1e1.C1fy = 1ab1e2.C1fy


FIgure 4-43: An ExampIe of Inner joIn
4.6.6.3. DUTEP JDINS
An Inner joIn provIdes only those values that satIsfy the WHEFE condItIon. However, It may be
worthwhIle sometImes, to retrIeve all rows that match the WHEFE clause and those that have
unmatched rows In the column beIng compared. An outer joIn Is then used to retrIeve the
rows wIth an unmatched value In the relevant column.


ConstructIng a FULL DUTEP JDIN:

8egIn wIth the NNEF JDN of the two tables, usIng matchIng columns
For each row of the left table that Is not matched by any row In the rIght table, add
one row to the query results, usIng the values of the columns In the left table, and
assumIng a NULL value for all columns of the rIght table
For each row of the rIght table that Is not matched by any row In the left table, add
one row to the query results, usIng the values of the columns In the rIght table, and
assumIng a NULL value for all columns of the left table


FIgure 4-44: an exampIe of DUTEP JDIN

Note: Full Duter JoIn Is supported by Dracle 9I and later versIons.
4.6.6.4. LEFT DUTEP JDIN
ConstructIng a LEFT DUTEP JDIN:

For each row of the left table that Is not matched by any row In the rIght table, add
one row to the query results, usIng the values of the columns In the left table, and
assumIng a NULL value for all columns of the rIght table


Note: The LEFT DUTEF JDN thus Includes NULLextended copIes of the
unmatched rows from the fIrst (left) table but does not Include any
unmatched rows from the second (rIght) table.

Examle: The syntax gIven Is Dracle specIfIc.
IkOM 1ab1e1, 1ab1e2
WhLkL 1ab1e1.C1fy = 1ab1e2.C1fy {+}

Emp_ID CITY
A1 New YorK
A2 NULL
A3 Chicago
A4 Chicago
A5 Paris
Cust_ID CITY
B1 New York
B2 New York
B3 NULL
B4 Chicago
B5 Moscow
TabIe1
TabIe2
TabIe1.Emp_ID TabIe1.City TabIe2.Cust_ID TabIe2.City
A1 New York B1 New York
A3 Chicago B4 Chicago
A5 Paris NULL NULL
A2 NULL NULL NULL
INNER
JOIN
Unmatched
rows
Left_Outer_Join TabIe

FIgure 4-45: An exampIe of LEFT DUTEP JDIN

4.6.6.5. PICHT DUTEP JDIN
ConstructIng a FCHT DUTEF JDN:

For each row of the rIght table that Is not matched by any row In the left table, add
one row to the query results, usIng the values of the columns In the rIght table, and
assumIng a NULL value for all columns of the left table


Note: The FCHT DUTEF JDN thus Includes NULLextended copIes of the
unmatched rows from the SECDN0 (rIght) table but does not Include any
unmatched rows from the fIrst (left) table.

Examle: The syntax gIven Is Dracle specIfIc.

IkOM 1ab1e1, 1ab1e2
WhLkL 1ab1e1.C1fy {+} = 1ab1e2.C1fy


Emp_ID CITY
A1 New YorK
A2 NULL
A3 Chicago
A4 Chicago
A5 Paris
Cust_ID CITY
B1 New York
B2 New York
B3 NULL
B4 Chicago
B5 Moscow
TabIe1
TabIe2
TabIe1.Emp_ID TabIe1.City TabIe2.Cust_ID TabIe2.City
NULL NULL B5 Moscow
NULL NULL B3 NULL
INNER
JOIN
Unmatched rows
Right_Outer_Join TabIe

FIgure 4-46: an exampIe of PICHT DUTEP JDIN
4.6.7. uerIes usIng EXISTS l NDT EXISTS
4.6.7.1. EXISTS
The EXSTS checks whether a subquery produces any row(s) of results.

ConsIder a nested query. f the query followIng the EXSTS returns at least one row, the
EXSTS returns TFUE and stops further executIon of the Inner SELECT statement. The outer
query wIll be executed only If the EXSTS returns true.

f the Inner query produces no rows, the EXSTS returns FALSE and the outer query wIll not be
executed. The EXSTS test cannot produce a NULL value.

Examle:
1. LIst all Customers who have at least one FIxed 0eposIt more than SJ000.00.

5LLLC1 CusflD, CusfLasfName, CusfM1dName, CusfI1sfName
IkOM CusfomeDefa11s CD
WhLkL LXl515
{5LLLC1 "
IkOM CusfomeI1xedDepos1f CID
WhLkL CID.Amounf1nDo11as > 3000.00 AND CID.CusflD = CD.CusflD}

Note: C0 Is the alIas for Customer_0etaIls. CF0 Is the alIas for Customer_FIxed_0eposIt.

2. LIst all Customers who have both a FIxed 0eposIt and a Loan at the 8ank.

5LLLC1 CusflD
WhLkL LXl515
{5LLLC1 "
IkOM CusfomeLoan
WhLkL CusfomeLoan.CusflD = CusfomeI1xedDepos1f.CusflD}

4.6.7.2. NDT EXISTS
The logIc of the EXSTS test can be reversed by usIng the NDT EXSTS form. n thIs case, the
test Is TFUE If the subquery produces no rows, and FALSE otherwIse.

Examle:
LIst all Customers who do not have a sIngle FIxed 0eposIt over SJ000.00.

5LLLC1 CusflD, CusfLasfName, CusfM1dName, CusfI1sfName
IkOM CusfomeDefa11s CD
WhLkL NO1 LXl515
{5LLLC1 "
IkOM CusfomeI1xedDepos1f CID
WhLkL CID.Amounf1nDo11as > 3000.00
AND CID.CusflD = CD.CusflD}

4.6.8. The Drder of ExecutIon of a SELECT statement
f a SELECT Statement contaIns a WHEFE, CFDUP 8Y, HA7NC and DF0EF 8Y CLAUSE, the
order of executIon Is as follows:

1. The WHEFE clause Is applIed fIrst, and the rows for whIch the search condItIon In the
WHEFE clause returns a TFUE are retaIned.

2. Next a CFDUP 8Y clause Is applIed. t wIll group the rows selected by the WHEFE clause
such that all the rows In each group have the same value for the column In the CFDUP 8Y
clause.

J. Next the HA7NC clause Is applIed. t wIll retaIn row groups for whIch the search condItIon
In the HA7NC clause returns a TFUE value.

4. Lastly the query result Is sorted In the order specIfIed In the DF0EF 8Y clause.
4.7. VIews
A vIew Is a vIrtual table In the database defIned by a query. A vIew does not exIst In the
database as a stored set of data values. The rows and columns of data vIsIble through the
vIew are produced by the query that defInes the vIew.

FIgure 4-47: The CPEATE VIEW statement syntax dIagram
4.7.1. HorIzontaI VIew
HorIzontal vIew restrIcts a user's access to selected rows of a table.

FIgure 4-48: HorIzontaI VIew
4.7.2. VertIcaI VIew
7ertIcal vIew restrIcts a user's access to select columns of a table.

FIgure 4-4: VertIcaI VIew
4.7.3. 0PDP VIEW Statement
The 0FDP 7EW statement Is used to drop a vIew.

FIgure 4-50: 0PDP VIEW statement syntax dIagram
EF/CDFP/CFS/0807/002 7ersIon 1.0 Page 1J0
4.7.4. JoIned VIews
JoIned 7Iews are used to sImplIfy multItable querIes. A joIned vIew draws Its data from two
or three dIfferent tables and presents the query results as a sIngle vIrtual table. Dnce the
vIew Is defIned, one can use a sIngletable query agaInst the vIew for requests that would
otherwIse each requIre a twotable or threetable joIn.

FIgure 4-51: JoIned VIews
A vIew can be referenced lIke a real table In a SELECT, NSEFT, 0ELETE, or UP0ATE
statement. However, more complex vIews cannot be updated; they are read only vIews.
4.7.5. VIEW Updates
A vIew can be updated If the query that defInes the vIew meets all of the followIng
restrIctIons:

0STNCT must not be specIfIed; that Is, duplIcate rows must not be elImInated from
the query results
The FFD| clause must specIfy only one updateable table; the vIew must have a sIngle
underlyIng source table
The SELECT lIst cannot contaIn expressIons, calculated columns, or column functIons
The WHEFE clause must not Include a sub query; only sImple rowbyrow search
condItIons may be used
The SELECT lIst must Include all the columns specIfIed wIth the NDT NULL constraInt
4.7.6. CheckIng VIew Updates (CHECK DPTIDN)
f a vIew Is defIned by a query that Includes the WHEFE clause, only rows that meet the
search crIterIa are vIsIble In the vIew. Dther rows may be present In the source table(s) from
whIch the vIew Is derIved, but they are not vIsIble through the vIew.

Examle:

FIgure 4-52: CreatIon of a sImpIe vIew

FIgure 4-53: InsertIon In a sImpIe vIew

Note: ThIs Is a perfectly valId SQL statement, and the F08|S Inserts a new
row wIth the specIfIed column values Into the Customer_0etaIls table.
However, the newly Inserted row does not meet the search condItIon for the
vIew. As a result, If one runs thIs query ImmedIately after the NSEFT
statement the newly added row does not show up In the vIew.

SQL can allow 08|S to detect and prevent thIs type of NSEFT or UP0ATE from takIng place
through the vIew by creatIng the vIew wIth the CHECK DPTDN. The CHECK DPTDN Is
specIfIed In the CFEATE 7EW statement, as shown below:


FIgure 4-54: Create vIew wIth CHECK DPTIDN
4.7.7. Advantages of VIews
SecurIty: A user can be permItted to access the database, only through a small set of
vIews that contaIn the specIfIc data the user Is authorIzed to see
uery sImpIIcIty: A vIew can draw data from several dIfferent tables and present It as
a sIngle table, thus effectIvely turnIng multItable querIes Into sIngletable querIes.
nternally F08|S uses multItable querIes
StructuraI sImpIIcIty: 7Iews can gIve a user, a personalIzed vIew of the database
structure, presentIng the database as a set of vIrtual tables that make sense to the
user
0ata IntegrIty: f data Is accessed and entered through a vIew, the 08|S can
automatIcally check the data to ensure that It meets specIfIed IntegrIty constraInts
4.7.8. 0Isadvantages of VIews
Performance: The 08|S translates the querIes agaInst the vIew Into querIes agaInst
the underlyIng source tables. f a vIew Is defIned by a multItable query, then even a
sImple query agaInst a vIew becomes a complIcated joIn, and It may take a long tIme
to complete. ThIs Is In reference to Insert, delete and update operatIons

Update restrIctIons: When a user trIes to update rows of a vIew, the 08|S must
translate the request Into an update on rows of the underlyIng source tables. ThIs Is
possIble for sImple vIews, but more complIcated vIews cannot be updated
4.8. 0ata ControI Language (0CL)
0CL statements are used to control access to the database and the data In It. t Is used to
enforce data securIty.

EF/CDFP/CFS/0807/002 7ersIon 1.0 Page 1JJ
4.8.1. CrantIng PrIvIIeges
The CFANT statement Is used to grant securIty prIvIleges on database objects to specIfIc
users. Normally, the CFANT statement Is used by the owner of the table or vIew to gIve other
users access to the data.

FIgure 4-55: The CPANT statement syntax dIagram
Examle:
GkAN1 5LLLC1, lN5Lk1
ON CusfomeDefa11s
1O LdW1n

GkAN1 ALL PklvlLLGL5
ON CusfomeLoan
1O JACk

GkAN1 ALL
ON CusfomeLoan
1O Pu8LlC

4.8.1.1. PassIng PrIvIIeges (CPANT DPTIDN)
A CFANT statement wIth the WTH CFANT DPTDN clause conveys, along wIth the specIfIed
prIvIleges, the rIght to grant those prIvIleges to other users.

FIgure 4-56: UsIng the CPANT DPTIDN

4.8.2. PevokIng PrIvIIeges (PEVDKE)
The FE7DKE statement Is used to FE7DKE prIvIleges prevIously granted wIth the CFANT
statement.

FIgure 4-57: The PEVDKE statement syntax dIagram
Examle:
kLvOkL 5LLLC1, lN5Lk1
ON CusfomeDefa11s
IkOM LdW1n

kLvOkL ALL PklvlLLGL5
ON CusfomeLoan
IkOM JACk

kLvOkL ALL
ON CusfomeLoan
IkOM Pu8LlC

FIgure 4-58: PEVDKE wIth CASCA0E
4.. Embedded SL

4..1. Purpose
To blend SQL language statements dIrectly Into a program wrItten In a host programmIng
languages, such as C, Pascal, CD8DL, FDFTFAN and PL/, use embedded SQL statements.

The foIIowIng technIques are used to embed the SL statements:

SQL statements are IntermIxed wIth statements of the host language In the source
program. ThIs embedded SQL source program Is submItted to a SQL precomplIer,
whIch processes the SQL statements
7arIables of the host programmIng language can be referenced In the embedded SQL
statements, allowIng values calculated by the program to be used by the SQL
statements
Program language varIables are also used by the embedded SQL statements to receIve
the results of SQL querIes, allowIng the program to use and process the retrIeved
values
SpecIal program varIables are used to assIgn NULL values to database columns and to
support the retrIeval of NULL values from the database

4..2. Why Embedded SL!
SL has the foIIowIng IImItatIons:

No provIsIon to declare varIables
No uncondItIonal branchIng/jump statement
No F statement to test condItIons
No FDF, 0D or WHLE statements to construct loops
No block structure

n order to understand the embedded SQL program, one has to be famIlIar wIth the followIng
termInologIes:

EXEC SL: Every embedded SQL statement begIns wIth an Introducer that flags It as a SQL
statement. The 8| SQL products use the Introducer exec sql for most host languages.

SLCA: The sqlca (SQL CommunIcatIon Area) Is a data structure that contaIns error varIables
and status IndIcators. 8y examInIng the SQLCA, the applIcatIon program can determIne the
success or faIlure of Its embedded SQL statements.

exec sql Include sqlca;
ThIs statement tells the SQL precomplIer to Include a SQL CommunIcatIons Area In the
program.

As F08|S executes each embedded SQL statement, It sets the value of the varIable sqlcode In
the SQLCA to IndIcate the completIon status of the statement.
A sqlcode of zero IndIcates successful completIon of the statement
A negatIve sqlcode IndIcates a serIous error that prevented the statement from
executIng correctly
A posItIve sqlcode IndIcates a warnIng condItIon. The most common warnIng wIth a
value of 100, Is the out of data warnIng returned when a program trIes to retrIeve the
next row of query results and no more rows are left to retrIeve.

Host varIabIes: A host varIable Is a program varIable. t Is declared usIng the data types of
the programmIng language such as "C" and manIpulated by programmIng language
statements. A host varIable Is also used In embedded SQL statements to store/retrIeve data
to/from the database. To IdentIfy the host varIable, the varIable Is prefIxed by a colon (:)
when It appears In an embedded SQL statement. A host varIable can appear In an embedded
SQL statement wherever a constant can appear.

The two embedded SQL statements begIn declare sectIon and end declare sectIon bracket the
host varIable declaratIons and are nonexecutable.

Use of host varIabIes to store data Into the database:
The Input provIded by the user usIng the standard Input devIce Is stored In the host
varIables
7alues of the host varIable Is then wrItten to the database usIng the NSEFT SQL
statement

Use of host varIabIes to retrIeve data from the database:
The data values retrIeved from the database usIng the SELECT SQL statement are held
In the host varIables
The contents of the host varIables are then dIsplayed on the standard output devIce
usIng functIons such as prIntf() In "C"

IndIcator varIabIes: To store NULL values In the database or retrIeve NULL values from the
database, embedded SQL allows each host varIable to have a companIon host IndIcator
varIable. n an embedded SQL statement, the host varIable and the IndIcator varIable
together specIfy a sIngle SQLstyle value, as follows:
An IndIcator value of zero IndIcates that the host varIable contaIns a valId value
A negatIve IndIcator value IndIcates that the host varIable should be assumed to have
a NULL value; the actual value of the host varIable Is Irrelevant and should be
dIsregarded
A posItIve IndIcator value IndIcates that the host varIable contaIns a valId value, whIch
may have been rounded off or truncated

A host varIable Is ImmedIately followed by the name of the correspondIng IndIcator varIable.
8oth varIable names are preceded by a colon.

ExampIe: A sImple embedded SQL program wrItten In C.

ProbIem statement: ThIs program asks the customer for hIs Cust_0, retrIeves hIs record from
the Customer_0etaIls table and dIsplays It on the standard output devIce.

1nf ma1n{1nf agc, cha" agv}
{
/" 1nc1us1on of fhe 5qL Commun1caf1on Aea 1n fhe pogam "/ /" 1nc1us1on of fhe 5qL Commun1caf1on Aea 1n fhe pogam "/ /" 1nc1us1on of fhe 5qL Commun1caf1on Aea 1n fhe pogam "/ /" 1nc1us1on of fhe 5qL Commun1caf1on Aea 1n fhe pogam "/
exec sq1 1nc1ude sq1ca

/" /" /" /" dec1aaf1on of fhe hO51 vAklA8LL5 "/ dec1aaf1on of fhe hO51 vAklA8LL5 "/ dec1aaf1on of fhe hO51 vAklA8LL5 "/ dec1aaf1on of fhe hO51 vAklA8LL5 "/
exec sq1 beg1n dec1ae secf1on

cha MemCusflD|5]
cha MemCusfLasfName|25]
cha MemAccounfNo|5]
cha Mem8ank8anch|25]
cha MemCusfLma11|30]
shof 18ank8anch

exec sq1 end dec1ae secf1on

/" Pompf fhe use fo Cusfome lD "/ /" Pompf fhe use fo Cusfome lD "/ /" Pompf fhe use fo Cusfome lD "/ /" Pompf fhe use fo Cusfome lD "/
p1nff{Lnfe Cusfome lD:}
scanf{xs,MemCusflD}

/" e /" e /" e /" execufe fhe 5qL quey "/ xecufe fhe 5qL quey "/ xecufe fhe 5qL quey "/ xecufe fhe 5qL quey "/
/" hO51 vAklA8LL5 ae peceded by a co1on {:} e.g.: /" hO51 vAklA8LL5 ae peceded by a co1on {:} e.g.: /" hO51 vAklA8LL5 ae peceded by a co1on {:} e.g.: /" hO51 vAklA8LL5 ae peceded by a co1on {:} e.g.:MemCusflD "/ MemCusflD "/ MemCusflD "/ MemCusflD "/
/" hO51 va1ab1e fo11oWed by a compan1on /" hO51 va1ab1e fo11oWed by a compan1on /" hO51 va1ab1e fo11oWed by a compan1on /" hO51 va1ab1e fo11oWed by a compan1on "/ "/ "/ "/
/" /" /" /" hosf hosf hosf hosf 1nd1cafo va1ab1e 1nd1cafo va1ab1e 1nd1cafo va1ab1e 1nd1cafo va1ab1e "/ "/ "/ "/
/" /" /" /" e.g. :Mem8ank8anch e.g. :Mem8ank8anch e.g. :Mem8ank8anch e.g. :Mem8ank8anch :18ank8anch "/ :18ank8anch "/ :18ank8anch "/ :18ank8anch "/
exec sq1 5LLLC1 CusflD, CusfLasfName,
AccounfNo, 8ank8anch, CusfLma11
IkOM CusfomeDefa11s
WhLkL CusflD =:MemCusflD lN1O
:MemCusflD,
:MemCusfLasfName,
:MemAccounfNo,
:Mem8ank8anch :18ank8anch,
:MemCusfLma11

/" D1sp1ay fhe ef1eved dafa "/ /" D1sp1ay fhe ef1eved dafa "/ /" D1sp1ay fhe ef1eved dafa "/ /" D1sp1ay fhe ef1eved dafa "/
/" s /" s /" s /" sq1ca.sq1code confa1ns sfafus 1nfomaf1on q1ca.sq1code confa1ns sfafus 1nfomaf1on q1ca.sq1code confa1ns sfafus 1nfomaf1on q1ca.sq1code confa1ns sfafus 1nfomaf1on
of fhe embedded 5qL sfafemenf execufed "/ of fhe embedded 5qL sfafemenf execufed "/ of fhe embedded 5qL sfafemenf execufed "/ of fhe embedded 5qL sfafemenf execufed "/
1f {sq1ca.sq1code = = 0} {
p1nff{Cusfome lD: xs\n, MemCusflD}
p1nff{Cusfome Name: xs\n, MemCusfLasfName}
p1nff{Accounf No.: xs\n, MemAccounfNo}

/" check1ng fhe va1ue of fhe lNDlCA1Ok /" check1ng fhe va1ue of fhe lNDlCA1Ok /" check1ng fhe va1ue of fhe lNDlCA1Ok /" check1ng fhe va1ue of fhe lNDlCA1Ok vAklA8LL "/ vAklA8LL "/ vAklA8LL "/ vAklA8LL "/
1f {18ank8anch < 0} {
p1nff{8ank 8anch 1s NuLL\n}
}
e1se {
p1nff{8ank 8anch: xs\n, Mem8ank8anch}
}

p1nff{Cusfome Lma11: xs\n, MemCusfLma11}
}
e1se 1f {sq1ca.sq1code = = 100} {
p1nff{No cusfome W1fh fhaf Cusfome lD.\n}
}
e1se {
p1nff{5qL eo: x1d\n, sq1ca.sq1code}
}

/" efuns s /" efuns s /" efuns s /" efuns success code fo fhe opeaf1ng sysfem "/ uccess code fo fhe opeaf1ng sysfem "/ uccess code fo fhe opeaf1ng sysfem "/ uccess code fo fhe opeaf1ng sysfem "/
efun 0
}

4.10. est PractIces
1. 0o not use SELECT *. ThIs Is tImeconsumIng and reduces performance. nstead, lIst
out each fIeld that Is requIred.

2. t Is potentIally dangerous to use SELECT * In embedded SQL I.e. SQL embedded In an
applIcatIon program because the meanIng of the asterIsk (*) mIght change. Example: If
a column Is added to or dropped from some table.

J. WhIle EvaluatIng NULL In a WHEFE clause of a query, use S NULL as opposed to =
NULL.

4. f one Is sure that the UNDN operatIon cannot produce duplIcate rows, use the UNDN
ALL as opposed to UNDN because the query wIll execute much more quIckly.

5. f the CFDUP 8Y clause has been used In a SELECT statement, then use only the
groupIng columns (columns on whIch groupIng has been done) or aggregate functIons In
the column lIst of the SELECT statement.

6. Fows that have a NULL value In the relevant column are Ignored by all the aggregate
functIon except count (*).

7. ndex Is most approprIate when querIes agaInst a table are more frequent than NSEFT
and UP0ATE operatIons

8. EXSTS Is benefIcIal when the most selectIve fIlter Is In the parent query. ThIs allows
the selectIve predIcates In the parent query to be applIed before fIlterIng the rows
agaInst the EXSTS crIterIa.

9. N Is most benefIcIal when the most selectIve fIlter appears In the subquery and there
are Indexes on the joIn columns

TIps to wrIte a good query:

TIp 1:
5LLLC1 accounfno, fansdafe, amounf
IkOM fansacf1on
WhLkL amounf + 3000 < 5000

Feplace the above query wIth the followIng

5LLLC1 accounfno, fansdafe, amounf
IkOM fansacf1on
WhLkL amounf < 2000

Peason: AvoId unnecessary computatIonal overhead In querIes.

TIp2:
5LLLC1 quanf1fy, AvG{acfua1p1ce}
IkOM 1fem
GkOuP 8Y quanf1fy
hAvlNG quanf1fy > 40

Feplace the above query wIth the followIng:

5LLLC1 quanf1fy, AvG{acfua1p1ce}
IkOM 1fem
WhLkL quanf1fy > 40
GkOuP 8Y quanf1fy

Peason: The WHEFE clause fIlters the rows from the table accordIng to the search condItIon.
Then the CFDUP 8Y clause Is applIed only on the fIltered rows. t saves tIme. f as opposed to
thIs, If the rows are grouped fIrst then the row groups are fIltered usIng the HA7NC clause, It
leads to an Increased overhead In terms of tIme requIred for executIon of the query.

TIp 3:
ProbIem Statement: To retrIeve the average salary for 'presIdents' and 'managers'.
5LLLC1 ob, avg{sa1}
IkOM emp GkOuP 8Y ob
hAvlNG ob = pes1denf Ok ob = manage

5LLLC1 ob, avg{sa1}
IkOM emp
WhLkL ob = pes1denf` Ok ob = manage
GkOuP 8Y ob

Peason: The WHEFE clause fIlters the rows from the table accordIng to the search condItIon.
Then the CFDUP 8Y clause Is applIed only on the fIltered rows. t saves tIme. f as opposed to
thIs, If the rows are grouped fIrst then the row groups are fIltered usIng the HA7NC clause, It
leads to an Increased overhead In terms of tIme requIred for executIon of the query.

TIp 4:
ProbIem Statement: To select records from debIt_transactIons table, credIt_transactIons
table where tran_date Is 'J10EC99'
5LLLC1 accfnum, ba1anceamf
IkOM deb1ffansacf1ons
WhLkL fandafe = 31-DLC-99

uNlON

IkOM ced1ffansacf1ons


IkOM deb1ffansacf1ons

uNlON ALL

IkOM ced1ffansacf1ons

Peason: ElImInatIng duplIcate rows from query results Is a very tImeconsumIng process,
especIally If the query results contaIn a large number of rows. f one Is sure that the UNDN
operatIon cannot produce duplIcate rows, one should specIfIcally use the UNDN ALL
operatIon because the query wIll execute much more quIckly.

TIp 5:
ProbIem statement: To determIne If transactIon(s) was made on '25JAN2005'

5LLLC1 COuN1{"}
WhLkL 1ansacf1onDafe = `25-JAN-2005`


IkOM CusfomeDefa11s
WhLkL LXl515 {5LLLC1 CusflD
WhLkL 1ansacf1onDafe = `25-JAN-2005`}
Peason: When CDUNT (*) Is used, It scans the entIre table whIch Is a tIme consumIng
operatIon. f EXSTS Is used, It checks whether a subquery produces any rows of query
results. f the subquery followIng the EXSTS returns at least one row, the EXSTS test returns
TFUE and stops further executIon of the Inner SELECT statement. t thus mInImIzes overhead.


4.11. Summary

The CFEATE TA8LE statement creates a table and defInes Its columns, PF|AFY KEY,
FDFECN KEY(s) and other constraInts lIke UNQUE and NDT NULL

The 0FDP TA8LE statement removes a prevIously created table from the database

The ALTEF TA8LE statement can be used to add a column to an exIstIng table, modIfy
a column defInItIon, add/drop a PF|AFY KEY, FDFECN KEY and other constraInts lIke
UNQUE and NDT NULL

The CFEATE N0EX statement can be used to defIne Indexes, whIch speeds up
database querIes but add overheads to database updates

f a SELECT Statement contaIns a WHEFE, CFDUP 8Y, HA7NC and DF0EF 8Y CLAUSE,
the order of executIon Is as follows:

The WHEFE clause Is applIed fIrst, and the rows for whIch the search condItIon
In the WHEFE clause returns a TFUE are retaIned.

Next a CFDUP 8Y clause Is applIed. t wIll group the rows selected by the
WHEFE clause such that all the rows In each group have the same value for the
column In the CFDUP 8Y clause.

Next the HA7NC clause Is applIed. t wIll retaIn row groups for whIch the
search condItIon In the HA7NC clause returns a TFUE value.

Lastly the query result Is sorted In the order specIfIed In the DF0EF 8Y clause.

0CL statements are used to control access to the database and the data In It. t Is used
to enforce data securIty

5. Dn-LIne TransactIon ProcessIng(DLTP)
"n our database we have 270 mIllIon records for one mIllIon customers!" Anonymous
5.1. Purpose
The bIggest responsIbIlIty of the modern day InformatIon system Is
To smulcte
42
the manual system
To record every transactIon that the organIzatIon undertakes
Capture the daytoday actIvItIes In the lIfe cycle of an enterprIse
Help the organIzatIon to make quIck and correct decIsIons based on the data
Protect the data from unauthorIzed access
FecoverIng the data In case of faIlures

Every organIzatIon needs some onlIne systems to manage theIr day to day actIvItIes. These
systems help In recordIng the transactIons, the organIzatIon goes through wIth theIr
employees, customers and vendors. t Is ImpossIble to ImagIne an enterprIse wIthout an on
lIne transactIon system.

To buIld an effIcIent onlIne transactIon system, It Is necessary to know how these systems
are buIlt, the dIffIcultIes that may encounter and how to overcome them.

n thIs cyberage, we need to know how to protect data from unauthorIzed usage and how to
recover the data In case of faIlures.
5.2. TransactIon
A transactIon Is nothIng but an InteractIon between dIfferent users, or dIfferent systems or
user and a system.

A transactIon Is a IogIcaI unIt of work whIch takes the database from one consIstent state to
another consIstent state. WhIle movIng from one consIstent state to another consIstent state,
the database may pass through multIple dIscrete steps.

At the end of the transactIon, the database may move back to Its orIgInal state (In the case of
faIlure) or to the next logIcal step (In the case of success).
ConsIder the followIng examples:

Examle1: 0rawIng money from a bank account Is one transactIon.
ThIs transactIon has multIple steps.

42
SImuIate: To make a model.
nsert the AT| card Into the AT| machIne
Enter the PN number
|achIne valIdates the PN number
Choose the approprIate menu for money wIthdrawal
The AT| machIne checks for the account balance to ensure that all bankIng busIness
rules are strIctly followed.
After doIng all the checks, the AT| machIne correctly dIspenses out the exact amount
and updates the records accordIngly

For any reason, If any of the above steps faIl, then the transactIon Itself faIls and the records
are not modIfIed. ThIs means the system Is goes back to orIgInal state and there wIll not be
any changes to the system.

f ALL the steps have been successfully carrIed out, then the records are updated accordIngly
and the system Is ready for the next transactIon.

Examle2: A person Is Interested In transferrIng money from account A to account 8. ThIs
transactIon has followIng steps:

nsert the AT| card Into the AT| machIne
Enter the PN number
|achIne valIdates the PN number
Choose the approprIate menu for money transfer
Enter InformatIon of the benefIcIary account
The AT| machIne checks for the account balance to ensure that all bankIng busIness
rules are strIctly followed
After verIfyIng the balance, amount wIll be debIted from account A and the records
are updated accordIngly
The debIted amount wIll be credIted to Account 8 and the records are updated
accordIngly

From the above steps, It Is evIdent that the transactIon may have 'n' number of physIcal
steps. TransactIon Is successful only If ALL the steps are carrIed out successfully. A
transactIon cannot be dIvIded Into smaller tasks.

The successful completIon of the transactIon Is called as the CDhhIT state. After thIs state,
changes are permanent and IrreversIble.

f ANY DNE step faIls, the complete transactIon faIls and the system Is taken back to the
orIgInal state that exIsted before the start of the transactIon. ThIs process of goIng back to
orIgInal state Is called as PDLLACK.
f the transactIon rolls back, then the transactIon reaches the ADPT state.

The TransactIon state dIagram Is as shown In FIgure 51:

Active
Partially
completed
Failed
Aborted
Committed
While executing
After the final
statement
has been
executed
When normal
execution can't
proceed
After rolling
back and
restoration to
previous state
After
successful
completion
BEGN

FIgure 5-1: TransactIon State 0Iagram
5.3. TransactIon Systems
The transactIon processIng (TP) systems whIch mImIc the real lIfe system lIke Salary
processIng, lIbrary, bankIng, aIrlIne, defence mIssIle systems are basIcally dIvIded Into three
categorIes.
5.3.1. atch TransactIon ProcessIng System
n the batch transactIon processIng system, a set of applIcatIon programs wIll be workIng on a
set of Input data to produce the desIred output. n thIs process there
wIll be absolutely ND human InteractIon.

The best example for batch processIng Is the salary slIp generatIon
applIcatIon. The salary slIp generatIon program may read the data lIke
employee name, grade, basIc salary, date of joInIng, overtIme for the
week, loss of pay, loans, recoverIes, etc., from the database and
generates the salary slIps. |aIl wIll be sent to employees
automatIcally, wIthout any InterventIon by the users.
5.3.2. Dn-IIne TransactIon ProcessIng System (DLTP)
n DLTP system, the user wIll be contInuously InteractIng wIth the system through a computer
or a termInal on a regular basIs. Some examples for the onlIne systems are the AIrlIne
reservatIon, FaIlway reservatIon system, the 8ankIng AT| machIne, the LIbrary applIcatIon,
etc.

n these kInd of systems, the user needs to enter predefIned
Inputs lIke flIght number, traIn number, date of journey, amount
to wIthdraw, book access number, return date, etc.
8ased on these predefIned Inputs, the system produces pre
defIned outputs lIke the confIrmed tIckets, or non avaIlabIlIty of
tIcket, the IssuIng of lIbrary book for a certaIn perIod, etc.
We shall study Indepth about the DLTP system In thIs chapter.

5.3.3. PeaI tIme TransactIon ProcessIng System
ThIs system Is the most complIcated among all the transactIon
systems. t Is capable of handlIng unexpected Inputs to unexpected
outputs. Examles: Ar trc]]c control system or Mssle de]ence
system.
These systems are capable of handlIng a sudden change In the aIr
pressure, the temperature, the wInd dIrectIon, the target speed and
the dIrectIon and can change theIr output based on these Inputs.

These real tIme applIcatIons are sImIlar to onlIne systems except for the reason that Input
and output to the system Is not all the tIme predefIned.
5.4. TransactIon PropertIes
Every transactIon system must possess the followIng characterIstIcs:

AtomIcIty: TransactIons should eIther completely succeed or completely faIl. For any reasons,
If the system crashes before the transactIon completes, the database state should not
change. The data In the database, whIch was Involved wIth the transactIon, should be
restored to the prevIous consIstent state. The transactIon Is IndIvIsIble whIch means It cannot
be dIvIded Into sub tasks

ConsIstency: TransactIons must preserve database consIstency. A transactIon transforms the
database from one consIstent state to another consIstent state.

IsoIatIon: A transactIon's operatIons lIke SELECT, NSEFT, UP0ATE and 0ELETE do not
Interfere wIth other transactIons, or other users of the database. UntIl a transactIon
completely succeeds, the database system conceals the IndIvIdual changes from other
transactIons.

0urabIIIty: Dnce a transactIon completes (commIts), the changes made to database
permanent and are avaIlable to all the transactIons that follow It.

These propertIes are called as ACI0 (derIved from the fIrst letter of the above characterIstIcs)
propertIes.
5.5. PequIrements for an DLTP System
n addItIon to AC0 propertIes, DLTP systems have addItIonal requIrements to meet. n the
followIng sectIons, these requIrements are dIscussed.
5.5.1. IntegrIty
All the data enterIng Into the system must be valIdated for Its correctness and adherence to
the organIzatIon's busIness rules. ThIs Is Implemented In F08|S through three types of
IntegrIty checks.

0omaIn IntegrIty Involves the ImplementatIon of busIness domaIn specIfIc rules.

Examle: l] cn orycnzcton decdes not to hre cn employee who s less thcn 18 yecrs cnd
cbove 0 yecrs. Ths ccn be mplemented usny the CHECK constrcnt.

CFEATE TA8LE Employee (
Emp_number Number(5) PF|AFY KEY,
Emp_Name 7archar2(25) NDT NULL,
0ept_number Number(5) FEFEFENCES 0EPAFT|ENT(0ept_number),
0ate_of_8Irth 0ate NDT NULL,
0ate_of_joInIng 0ate 0efault sysdate,
CHECK ((0ate_of_joInIng 0ate_of_8Irth) = 18 AN0
(0ate_of_joInIng 0ate_of_8Irth) = 60 ));

EntIty IntegrIty Is Implemented usIng the prImary key constraInt. 8asIcally entIty IntegrIty
refers to the fact that a partIcular attrIbute unIquely IdentIfIes the physIcal entIty.

Examle: For ecch employee, the employee number unquely dent]es cn employee. Ths
mecns employee number J882 clwcys represent detcls o] employee Hcnumesh. Hence entty
nteyrty en]orces thct prmcry keys cannot hcve null vclues cnd duplccte vclues.

PeferentIaI IntegrIty Is Implemented usIng the relatIonshIps between prImary keys and
foreIgn keys of a tables wIthIn a database. ThIs ensures data
consIstency. FeferentIal IntegrIty requIres that the value of every
foreIgn key In every table be matched by the value of a prImary key In
another table. ThIs relatIonshIp Is called as parentchIld relatIonshIp.
For example, every employee of the organIzatIon must belong to a valId
department. Hence department number column of the employee table
refers to the department number column of department table.

Dne can not Insert Into the department number column of employee table unless the value Is
present In the department number column of department table (except for NULL values). f
foreIgn key column Is NULL, It represents the 'unknown state' and Is not a vIolatIon of
referentIal IntegrIty. n above example, department table Is parent and employee table Is
chIld.

After enforcIng referentIal IntegrIty, the parent table prImary key value mIght be deleted.
ThIs wIll vIolate the referentIal IntegrIty of the chIld table. ThIs Is because the chIld table
mIght stIll contaIn records contaInIng the orIgInal parent table prImary key value.

For example, employee table contaIns department number as the foreIgn key referrIng to the
prImary key of the department table. f department number Is deleted from the parent table
(department table), If the employee table contaIn the correspondIng department number
value, It leads to vIolatIon of referentIal IntegrIty. To avoId such sItuatIons, the followIng
restrIctIons can be put on the foreIgn key columns of chIld table at the tIme of creatIon.
DN 0ELETE PESTPICT - 0o not allow to delete the parent table data If It Is referred In
chIld table. For example If department number 10 Is referred In employee table, then
do not allow to delete the department number 10 In department table. ThIs Is default
clause for Dracle
DN 0ELETE SET NULL - Dn delete of the parent data, set NULL value In chIld table
wherever the deleted data Is referred. For example If department number 10 Is
referred In employee table, and It Is deleted In department table, set NULL values In
correspondIng department number columns of employee table (wherever department
number 10 was referred)
DN 0ELETE SET 0EFAULT - Set the default values to chIld records on deletIon of
parent records. For example If department number 10 Is referred In employee table,
and It Is deleted In department table, set default values (say 0000) In employee table
wherever department number 10 was referred
DN 0ELETE SET CASCA0E - 0elete all the chIld table records from chIld table on
deletIon of parent record In parent table. For example If department number 10 Is
referred In employee table, and It Is deleted In department table delete all the
records In employee table wherever department number 10 was referred

5.5.2. Concurrency
Concurrency means allowIng dIfferent transactIons to execute sImultaneously. The bIggest
challenge of havIng a concurrent system Is maIntenance of consIstency In the system, In spIte
of the multIple transactIons executIng sImultaneously.

ConsIder a sImple example to know how concurrency affects consIstency.

Assume there are only three seats avaIlable between 8angalore and SIngapore on a partIcular
day and around ten people are tryIng to book the tIcket on the same flIght, the same day.

The system allows transactIons to occur sImultaneously and these ten people can book those
three seats from dIfferent locatIons. These ten people get a tIcket each when there were just
three seats avaIlable! ThIs Is a 8C vIolatIon of consIstency or IntegrIty of the system.

n next sectIon lIsted all the possIble consIstency problems wIth transactIons, occurrIng
sImultaneously.
5.5.2.1. Lost Update
Let us understand lost update concept usIng a bankIng applIcatIon. Assume Person named
HIlary holds an account In the CapItal 8ank, San Jose branch wIth US0 1500 account balance.

Dne fIne day she deposIts US0 2000 by cash to her account.

WhIle the branch clerk Is updatIng her account at San Jose, her husband KevIn deposIts US0
1800 to her account almost at the same tIme In San FrancIsco.

Clerk In San FrancIsco Is not aware of the other transactIon and adds thIs amount to her
balance. Her balance Is now updated to US0 JJ00 thereby IgnorIng her last deposIt of US0
2000 at San Jose. 8asIcally we lost one update whIch happened on her account!

ThIs problem has occurred because two transactIons are workIng on the same resource
wIthout knowIng each other's actIvIty.

The FIgure 52 gIves the snapshot of mcn memory
4J
In whIch these two transactIons operatIng
on HIlary's account.

Note that:
ThIs dIagram Is not F08|S table. t Is a snapshot of maIn memory at that poInt of tIme
8alance column IndIcates the current avaIlable balance of HIlary when two
transactIons are concurrently runnIng

4J
haIn hemory: Please recall CHSSC concepts All the read and wrIte operatIons happen In maIn
memory before they are wrItten Into hard dIsks.

Time HiIary's Deposit BaIance Kevin's Deposit
10:22 Read BaIance (1500) 1500
10:23 BaIance=1500+2000
10:24 Read BaIance (1500)
10:25 Write new BaIance (3500) 3500
10:26 Commit
10:27 BaIance=+1800
10:28 3300 Write new BaIance
10:29 Commit
FIgure 5-2: Lost Update
5.5.2.2. 0Irty Pead
Let us revIsIt the same example dIscussed for lost update case wIth slIghtly dIfferent scenarIo
as shown In FIgure 5J.

ThIs tIme, HIlary agaIn trIes to deposIt US0 2000 to her account but due to some technIcal
reasons the transactIon wIll not be successful. We know that a transactIon can be eIther In
the prIor state or a new state after the completIon of the transactIon. So, her deposIt
transactIon Is aborted and her balance Is rolled back to the orIgInal value US0 1500.

8ut unfortunately KevIn's transactIon read the balance value as US0 J500 In maIn memory
before the roll back of prevIous transactIon. 0ue to thIs problem, KevIn's transactIon
occurrIng In San FrancIsco read the dIrty data. ThIs kInd of problem Is known as dIrty read.
Time HiIary's Deposit BaIance Kevin's Deposit
11:22 Read BaIance (1500) 1500
11:23 BaIance=1500+2000
11:25 Read BaIance
11:26 RoIIback
11:27 BaIance= + 1800
11:28 5300 Write new BaIance
11:29 Commit
FIgure 5-3: 0Irty Pead
5.5.2.3. Incorrect Summary
Let us consIder another scenarIo where HIlary wants to transfer amount of US0 500 to her
sIster Evelyn's account In the same branch. After deductIng US0 500, HIlary's balance wIll be
US0 1000.

Evelyn's account balance was US0 1500 before and now wIll become US0 2000 wIth the
addItIon of US0 500.

Almost at the same tIme, the bank branch manager starts another transactIon to calculate the
total sum avaIlable In bank through customer deposIts.

ThIs program calculates the sum by readIng HIlary's balance amount as US0 1500 (before
deductIon of transfer amount) and Evelyn's balance as US0 2000 (after addItIon of transfer
amount). ThIs program concludes that the sum Is US0 J500 (sum of HIlary's balance amount
and Evelyn's balance amount) but actually It Is only US0 J000. ThIs problem Is known as
Incorrect summary. Snapshot of maIn memory for these transactIons are shown In FIgure 54.

Time HiIary's Transfer BaIance Summary Transaction
12:22
Read HiIary's BaIance
(1500) 1500 Sum = 0
12:23 BaIance=1500-500 Read HiIary's BaIance
12:25 Sum=Sum + BaIance
12:26
Read EveIyn's BaIance
(1500) 1500
12:27 BaIance=1500 + 500
12:29 Commit 2000
12:30 Read EveIyn's BaIance
12:31 Sum=Sum + BaIance
12:32 3500 Write Sum
12:33 Commit
FIgure 5-4: Incorrect Summary
5.5.2.4. Phantom Pecord
Let us consIder the snapshot of two dIfferent transactIons whIch are runnIng sImultaneously
almost at the same tIme as shown In FIgure 55.

Dne transactIon Is countIng the number of accounts held by the bank. Another transactIon Is
creatIng new accounts. Though two accounts are created and commItted before completIon
of "Total Accounts" transactIon, these accounts
(SImon's account and |Ike's account) are mIssed by "Total accounts" transactIon for
countIng.

These newly Inserted rows appear as phantom to the "Total Accounts" transactIon,
InconsIstently appearIng and dIsappearIng. ThIs Is called Phantom record because Phantom Is
consIdered as an InvIsIble ghost as In the case of newly Inserted rows.
Time Create account TotaI Accounts
13:22
13:23
13:24
Read the totaI number of accounts
in the bank as totaI
13:25
Create account for Simon
with a deposit of 500
13:26
Create account for Mike
with a deposit of 1000
13:27
13:28 Commit
13:29 Write TotaI
13:30 Commit
FIgure 5-5: Phantom Pecord
f we observe these problems closely, all these problems are because of InterleavIng of the
transactIons. The solutIon to over come these problems would be to make every transactIon
follow each other. ThIs Is called as serIalIzatIon. SerIalIzatIon of transactIons can be achIeved
by settIng followIng rules on transactIons.

1. f any row Is beIng modIfIed, then do not allow any other transactIon eIther to read or
update/delete that row untIl the fIrst transactIon completes.
2. f a transactIon Is readIng a partIcular row, prevent other transactIons from makIng any
changes to that row untIl the fIrst transactIon completes.
J. f a transactIon Is readIng some data, do not allow any other transactIon to Insert new
rows Into the same table untIl the fIrst transactIon completes. ThIs wIll avoId problems
lIke Phantom records.

SerIaIIzatIon can be achIeved usIng LockIng or TIme StampIng technIques.
5.6. Locks
LockIng Is a technIque to have a controlled access to the resources lIke a database,
tcblespcce
44
, table, rows and columns. WhIle these resources are put under lock by some
transactIon, other transactIons have very restrIcted or no access to these resources,
dependIng on the lockIng mode.

LockIng Is one of the most wIdely used technIques In commercIal F08|S products to achIeve
consIstency whIle supportIng concurrency of transactIons.

44
TabIespace: The logIcal part of the database whIch represents collectIon of the structures lIke
tables, etc created by varIous users.
8asIcally resources can be locked eIther In Shared (S) mode for Fead purpose or In ExclusIve
(X) mode for Update, 0elete or nsert purpose.
5.6.1. Shared Lock (S)
ThIs lockIng technIque allows a hIgher transactIon concurrency.
When a partIcular resource lIke a table or a row Is locked In the
shared mode by one transactIon, all other transactIons can
perform the read operatIon on the locked resource, but no
updates or modIfIcatIons are possIble by other transactIons.
Usually SELECT operatIon takes the S lock on resources.
5.6.2. ExcIusIve Lock (X)
ThIs Is the most restrIctIve lock. Dnce a transactIon puts the X
lock on a partIcular resource, no other transactIon can put any
kInd of lock on thIs resource. ThIs resource Is exclusIvely
reserved for the fIrst transactIon and no other transactIon can
use It for read or wrIte operatIon. Hence thIs X lock allows the
least concurrency.

Usually NSEFT/UP0ATE/0ELETE operatIons put the X lock on
resources before wrItIng/modIfyIng/deletIng operatIons.

The FIgure 56 explaIns the compatIbIlIty of these locks. ThIs fIgure can be Interpreted as:
f transactIon T1 locks the resource A (database/tablespace/table/row/fIeld) In shared(S)
mode, another transactIon T2 can also lock the same resource A, In shared(S) mode.

f transactIon T1 locks the resource A (database/tablespace/table/row/fIeld) In shared (S)
mode, another transactIon T2 can not lock the same resource A, In exclusIve (X) mode untIl
T1 releases Its S lock on the resource A.

f transactIon T1 locks resource A In X mode no other transactIon can lock resource A In any
other (S or X) mode untIl T1 releases Its X lock on the resource A.

Transaction T1
A X S
X

T
r
a
n
s
a
c
t
i
o
n

T
2

S

FIgure 5-6: Share - ExcIusIve Lock hatrIx

n FIgure 56, symbol represents IncompatIbIlIty of the lock and symbol represents
compatIbIlIty of the lock.
5.7. CranuIarIty of LockIng
CranularIty of lockIng refers to the granular level at whIch a resource can be locked. ConsIder
for example a database. A database Is made up of multIple tablespaces. Each tablespace
hosts multIple tables. WIthIn a table there are multIple rows and fIelds as shown In FIgure
57. t Is possIble to lock a

0atabase
Tablespace
Table
Fow
FIeld

f F08|S applIcatIon Is capable of lockIng a fIeld of a table explIcItly, then the granularIty of
lockIng Is at fIeld level. f It can lock only up to the row level, the lockIng granularIty of that
F08|S product Is row level. Thus, the hIgher the granularIty of lockIng, the hIgher wIll be the
concurrency.

n above case database, tablespace, table and row are all the ancestors of the fIeld. SImIlarly
database, tablespace are ancestors of the table.

Tablespace, table, row and fIelds are descendants of database. n the same way rows and
fIelds are descendants of table.

S and X locks alone cannot achIeve complete concurrency. ThIs Is Illustrated below.
Let us consIder the followIng scenarIo and analyze the concurrency that can be possIble.

Assume In a bankIng applIcatIon transactIon called 8alanceUpdate has locked Fow F7 of table
ACC_0ETALS In X mode for updatIng the account balance. 8ecause of thIs X mode lock, no
other transactIons can acquIre eIther S or X lock on row F7 or any of Its fIelds.


FIgure 5-7: CranuIarIty of LockIng
Let us assume followIng scenarIos:
A transactIon called 8alanceEnquIry requIres a lock on fIrst row of table ACC_0ETALS
In S mode
A transactIon called SummaryFeport requIres a lock on complete table ACC_0ETALS In
S mode

n Ideal condItIon:
System should allow to lock fIrst row of ACC_0ETALS table for transactIon
8alanceEnquIry
System should prevent transactIon SummaryFeport from acquIrIng a lock on table
ACC_0ETALS

TransactIon SummaryFeport should be prevented from acquIrIng a lock on table ACC_0ETALS
because row F7 of table ACC_0ETALS Is already locked by transactIon 8alanceUpdate In X
mode.

f transactIon SummaryFeport Is allowed to acquIre S lock on table ACC_0ETALS, we may
encounter the dIrty read problem. Dn same lInes no S or X locks are allowed by any other
transactIon on the tablespace TS_CUST_0ETALS or database 08_8ANK_0ETALS because row
F7 Is part of TS_CUST_0ETALS and database 08_8ANK_0ETALS.

n other words, although row F7 of table ACC_0ETALS was locked explIcItly In X mode, the
table ACC_0ETALS, the tablespace TS_CUST_0ETALS and the entIre database
08_8ANK_0ETALS, was locked ImplIcItly In the X mode to avoId any parents of F7 beIng
locked by some other transactIons.

ThIs ImplIcIt lockIng of complete database now avoIds lock on row F1 of Table ACC_0ETALS
by transactIon 8alanceEnquIry. ThIs Is serIous threat to concurrency of the transactIons.

Let us look at the solutIon for thIs problem In next sectIon.

5.8. Intent LockIng
n ntent lockIng only the IntentIon of lockIng Is expressed at the ancestor node of the
requIred resource and the resource at the lower level Is locked explIcItly only when requIred.

ConsIder the example dIscussed In SectIon 5.7. n the earlIer case, It was requIred to lock row
F7 of table ACC_0ETALS In X mode explIcItly but all Its ancestors were ImplIcItly locked In
the same mode (Fefer FIgure 57). ThIs has reduced the concurrency consIderably.

To overcome thIs concurrency Issue It Is necessary for a transactIon to express only the
IntensIon of lockIng the database 08_8ANK_0ETALS, the tablespace TS_CUST_0ETALS and
the table ACC_0ETALS In the X mode and In turn lock the row F7 explIcItly In X mode. ThIs
concept Is called as Intent lockIng.

Some other transactIons stIll can express theIr IntensIon of exclusIve or shared lockIng on
database 08_8ANK_0ETALS or tablespace TS_CUST_0ETALS or table ACC_0ETALS and
explIcItly lock any other row other than Fow F7, eIther In X or S mode.

ThIs Intent lockIng mechanIsm not only Increases concurrency but also stops the ImplIcIt
lockIng of ancestral resources.

Hence Intent lockIng Is called as ParentChIld lockIng. You express your IntensIon of lockIng at
parent level and lock chIld resource In explIcIt mode.

ntent lockIng Is classIfIed as ntent Shared (S) lockIng and ntent ExclusIve (X) lockIng.

5.8.1. Intent Share (IS)
ThIs lock has the IntentIon to share the requested node. ThIs also allows the requester to
explIcItly lock the descendants of thIs node In S or S mode.

Examle: Trcnsccton SummcryReport explcned n secton 5.Z ccn lock entre dctcbcse
08_8ANK_0ETAlLS cnd tcblespcce TS_C0ST_0ETAlLS n lS mode cnd ACC_0ETAlLS tcble
explctly n S mode.
5.8.2. Intent ExcIusIve (IX)
ThIs lock has the IntentIon to have exclusIve access to the requested node and allows the
requester to explIcItly lock the descendants In X or X modes.

Examle: Trcnsccton 8clcnce0pdcte explcned n secton 5.Z ccn lock dctcbcse
08_8ANK_0ETAlLS, the tcblespcce TS_C0ST_0ETAlLS cnd the tcble ACC_0ETAlLS n lX mode
cnd lock the row RZ explctly n X mode.
5.8.3. Shared Intent ExcIusIve (SIX)
The CombInatIon of Shared and ntent exclusIve lock Is referred to as Shared ntent ExclusIve
Lock or SX Lock.
A share and Intent exclusIve lock (or SX lock, pronounced as the separate letters S X rather
than lIke the number sIx) IndIcates an S lock at the current level plus an IntentIon to Insert,
delete, update data at a lower level of granularIty. ThInk of a SX lock as an S lock plus an X
lock as shown In FIgure 58. Dnly one transactIon can be granted a SX lock on a table at a
tIme.

FIgure 5-8: SIX Lock
A SX lock on a table IndIcates an IntentIon to read all of the rows In the table and to
delete/update/Insert to a few. The S lock In the SX lock at the table level covers all of the
rows. Fows that are updated wIll obtaIn X locks, but only after X IntentIon locks have been
obtaIned on the pcyes
45
that contaIn them.

45
Page: t Is part of a table. Usually In one page multIple rows are stored.
A SX lock Is stronger than a S lock or an X lock. When a transactIon obtaIns a SX lock on a
table, only that transactIon wIll be able to modIfy data In the table. n thIs respect, a SX lock
slIghtly resembles an X lock. WIth a SX lock, however, other transactIons that want to read
some of the data (read data at the row or page level and obtaIn an S lock on the table) are
allowed to proceed, so concurrency Is better than wIth an X lock. Lock mode compatIbIlIty
wIll be descrIbed In greater detaIl later In thIs module.

f other transactIons obtaIn S lock on row of a table or S lock on page of a table the SX
transactIons wants to modIfy, the SX transactIon must waIt untIl the S locks are released
before It can modIfy the data.

Dther transactIons that want to read all of the data (obtaIn an S lock on the table) or that
want to wrIte to any portIon of the data are not allowed to proceed untIl the SX lock Is
released.

A SX lock Is also called a share subexclusIve lock.

A complete compatIbIlIty matrIx of these locks Is shown FIgure 59. Note that In FIgure 59
symbol represents IncompatIbIlIty of the lock and symbol represents compatIbIlIty of
the lock.

Transaction T1
A X S IS IX SIX
X

IS

IX

T
r
a
n
s
a
c
t
i
o
n

T
2

SIX

FIgure 5-: CompIete Lock hatrIx

ThIs lock matrIx can be Interpreted as:

f resource A (tablespace/table/row) Is locked In X mode by transactIon T1, no other
transactIons can lock resource A In any mode.

f resource A Is locked In S mode by transactIon T1, another transactIon say T2 can lock the
same resource A In S or S mode but It can not lock In X or SX or X mode.

f resource A Is locked In S mode by transactIon T1, another transactIon say T2 can lock the
same resource A In S or S or X or SX mode but It can not lock In X mode.

f resource A Is locked In X mode by transactIon T1, another transactIon say T2 can lock the
same resource A In S or X mode but It can not lock In S or X or X or SX mode.

f resource A Is locked In SX mode by transactIon T1, another transactIon say T2 can lock the
same resource A In S mode but It can not lock In S or X or X or SX mode. SX lock Is
combInatIon of S and X. Hence SX lock Is compatIble wIth that lock whIch has the common
compatIbIlIty wIth S and X locks. SInce S and X are together compatIble wIth S lock, SX lock
Is compatIble wIth S lock only.

The bIggest problem wIth lockIng technIque Is that It may lead to 0eadlock.
5.8.4. Case study for Intent Locks
DbjectIve: To study about the compatIbIlIty of locks.

AssumptIons:
A database db has two tables (fIles) f1 and f2.

FIle f1 has pages p11, p12, and p1J.
FIle f2 has pages p21, p22 and p2J.

Page p11 has 2 records, r111 and r112.
Page p1J has 2 records, r1J1 and r1J2.

Page p2J has 2 records, r2J1 and r2J2.

ConsIder the followIng sItuatIon:

TransactIon T1 wants to update record r111 and record r211.
TransactIon T2 wants to update all records on page p12.
TransactIon TJ wants to read record r112 and the entIre fIle f2.
Assume that transactIon T4 and T5 starts only after all the other transactIons have
commItted.
TransactIon T4 wants to modIfy r111 and transactIon T5 wants to read record r112.

ProbIem statement: SpecIfy
The locks whIch wIll be acquIred by the transactIons
The order In whIch the locks wIll be acquIred by the transactIons
The order In whIch the locks wIll be released by the transactIons

SoIutIon:
T1 T2 TJ
X(db)
X(f1)
X(db)
S(db)
S(f1)
s(p11)
X(p11)
X(r111)
X(f1)
X(p12)
S(r112)
X(f2)
X(p21)
X(r211)
0o the updatIon
Unlock(r211)
Unlock(p21)
Unlock(f2)

S(f2)
Unlock(p12)
Unlock(f1)
Unlock(db)
Unlock(r111)
Unlock(p11)
Unlock(f1)
Unlock(db)
Unlock(r112)
Unlock(p11)
Unlock(f1)
Unlock(f2)
Unlock(db)
AssumptIon: TransactIon T4 and transactIon T5 start after the transactIons T1, T2 and TJ
have commItted and released the locks.

T4 T5
SX(db) S(db)
SX(f1) S(f1)
X(p11) S(p11)
X(r111) S(r112)
Unlock(r111) Unlock(r112)
Unlock(p11) Unlock(p11)
Unlock(f1) Unlock(f1)
Unlock(db) Unlock(db)

LearnIng's from the above case study:
Locks are acquIred from the root to the place (node) one wants to lock. (top to
bottom)
S or X mode locks are applIed only at very fIne granularIty (only on the specIfIc node
that the user wIshes to read or update)
Locks are released In bottom to top fashIon
Check for the compatIbIlIty of the locks In cases where a transactIon already holds a
lock on the node and another transactIon wants to acquIre a lock on the same node
5.. 0eadIock
0eadlock Is a sItuatIon where one transactIon Is waItIng for another transactIon to release the
resource It needs, and vIce versa. Each transactIon wIll be
waItIng forever for the other to release the resource. ThIs Is
shown In the FIgure 510:
Time
Transaction
BaIanceUpdate
Transaction
LoanUpdate
10:22 Lock ACC_DETAILS Lock LOAN_DETAILS
10:23 Update ACC_DETAILS Update LOAN_DETAILS
10:24
Try for Iock on
LOAN_DETAILS Try for Iock on ACC_DETAILS
10:25 Wait for Iock Wait for Iock
FIgure 5-10: 0eadIock
n above dIagram transactIon 8alanceUpdate locked the table ACC_0ETALS In X mode at tIme
10:22 and waItIng to acquIre lock on table LDAN_0ETALS for some updatIon. 8ut transactIon
LoanUpdate already has the X lock on table LDAN_0ETALS and waItIng for table ACC_0ETALS
whIch Is locked by transactIon 8alanceUpdate. These two transactIons wIll be waItIng
InfInItely for each other to release the locked resources. ThIs Is known as 0eadlock.

f a 0eadlock occurs, one of the partIcIpatIng transactIons must be rolled back to allow the
other to proceed. There are varIous methods to choose whIch transactIon to roll back when a
deadlock Is detected. Usually rollback actIon Is decIded on:
How long the transactIons have been runnIng
0ata already updated by the transactIon
0ata that remaIns to be updated by the transactIon

There are schemes avaIlable for preventIng deadlock. |ost of the F08|S products allow
deadlocks to occur and resolve them, when they are detected.
5.10. TImestampIng
Another concurrency management technIque Is TImestampIng. Every resource In database wIll
be assocIated wIth last successful read and last successful wrIte tImestamp (tIme of
occurrence up to mIllIseconds Ex: 12th 0ecember 2004 11:22:JJ.J45).

Let us consIder:

F08|S author by name Hanu Is modIfyIng thIs course materIal as one transactIon
TraInees readIng thIs course materIal as another transactIon

f other F08|S author, say Seema, Is also modIfyIng the same course materIal at the same
tIme, It leads to Lost update and Phantom record condItIons.

f Hanu starts modIfyIng whIle traInees are studyIng thIs materIal, It leads to dIrty read or
Incorrect summary problems.

To avoId these problems we can follow these two rules:

Hanu can start the course modIfIcatIon transactIon only If:
Course materIal Is successfully modIfIed before startIng thIs transactIon
No TraInees are currently readIng thIs course materIal

SImIlarly TraInees can start readIng course materIal transactIon only If:
t was successfully updated before they start readIng It

Let us consIder an example of database 08_8ANK_0ETALS (Fefer FIgure 5 7). n table
ACC_0ETALS, a partIcular row Is read successfully by transactIon 8alanceEnquIry at
12:11:45.J45 of 12th 0ecember 1945. ThIs wIll be the last read tImestamp of thIs row. f any
other transactIon reads thIs row after thIs tIme, that partIcular tIme wIll be the last read
tImestamp of the row.

SImIlarly every row wIll have last updated tImestamp. f transactIon 8alanceUpdate updates
the row F1 at 1J:J2:22.J45 of 12th 0ecember 1945, thIs wIll be recorded as last updated
tImestamp of the row F1.

A transactIon can read only rows or columns that have been updated by an older transactIon
If not, transactIon Is rolled back.

Let us assume that Fow F7 of the table ACC_0ETALS was successfully updated at 09:24:22.46
Hrs of 15th August 1947 by some transactIon.

Any transactIons started after 09:24:22.46 Hrs of 15th August 1947 can read thIs row.

TransactIons started before 09:24:22.46 Hrs of 15th August 1947 need to be rolled back and
start afresh to read thIs data.

In generaI for read, the condItIon can be defIned as TS > TU where TS Is the start tIme of
transactIon and TU Is the Iast successfuI update tImestamp of the resource.

A transactIon can update only rows or columns that have been read and updated by an older
transactIon else thIs transactIon Is rolled back.

SImIlarly any transactIon can update row F7 only If It Is started after the last successful
update and the last successful read.

Assume a transactIon started at 10:24:2J.49 Hrs of 15th August 1947 and wIshes to update
row F7 at 10:29:11.J4 Hrs of 15th August 1947.

t Is possIble to update thIs row only If the row F7 was successfully updated and read before
10:24:2J.49 Hrs of 15th August 1947.

Any transactIon started after 10:24:2J.49 Hrs of 15th August 1947 can not change the value of
thIs row.

CenerIc ruIe for updatIng data Is TS > TU and TS > TP. Where TS Is transactIon start
tImestamp, TU Is the Iast successfuI updated tImestamp and TP Is the Iast successfuI read
tIme.

The bIggest advantage of tImestampIng Is It leads to no dead lock condItIon as no resources
are locked.

TImestampIng technIque leads to large number of rollbacks. 0ue to thIs reason tImestampIng
technIque Is not Implemented as the concurrency control mechanIsm In most of the
commercIal F08|S applIcatIons.

Note: Almost all the commercIal F08|S packages use a lockIng technIque as
the concurrency controllIng mechanIsm whIle maIntaInIng the consIstency In
the system.

5.11. SecurIty
SecurIty Is one of the best Implemented strategIes In F08|S.

SecurIty Is Implemented In F08|S packages usIng:

1. USEF0 and PASSWDF0 to restrIct the users from acquIrIng an unauthorIzed access
2. Crant and Fevoke statements (0ata Control Language) to provIde restrIcted access
control to resources lIke Tables
J. 0atabase vIews to restrIct access to sensItIve data
4. Encrypton
46
of data to avoId unauthorIzed access
5.12. Pecovery
A database mIght be left In an InconsIstent state by:
An ApplIcatIon error
Power faIlure
D/S or 0atabase faIlure
Network faIlure
Hardware or |edIa faIlures

f the database Is In an InconsIstent state, It Is necessary to restore It to a consIstent state.
Fecovery process can be achIeved eIther usIng log fIles or backups of the database.

The sImplest backup technIque Is '0umpIng'. The entIre content of the database are backed
up on to secondary devIces lIke tapes on a regular basIs. ThIs backIng up operatIon must be
performed when the state of the database Is consIstent. Therefore no transactIons whIch
modIfy the database can be runnIng durIng thIs backup process.

46
EncryptIon: The process of manIpulatIon of data to prevent accurate InterpretatIon by all but those
for whom the data Is Intended.

ThIs dumpIng process can take a long tIme to perform and one may not be able to stop
transactIons for a longer tIme In the productIon envIronment. Hence It cannot be performed
as often as one would lIke to. ThIs type of backup Is called cold back up and Is usually done
on a perIodIc basIs lIke once a week or once a month at nIght when transactIons In system are
at theIr mInImal threshold. These tapes can then be used In case of complete hard dIsk
faIlures. ThIs Is showed In the FIgure 511.

FIgure 5-11: 0atabase ackup
f the database back up Is done whIle transactIons are runnIng, It Is called as Hot backups.
Usually hot backups are Incremental In nature. ThIs means only modIfIed data sInce the last
backups are captured. Usually It takes less tIme and Is done on a daIly basIs.
The hot and cold backups are useful only In the case of medIa or hard dIsk faIlure. ThIs back
up cannot be used for

Unplanned power shutdown
Sudden breakdown In D/S or database
|emory faIlure

These kInds of faIlures are called as Instance faIlures. nstance faIlures can be handled by
makIng use of transactIonal log or redo log fIles. These are further explaIned In the followIng
sectIons.
5.13. TransactIon Log
TransactIon log or the journal log or redolog Is a physIcal fIle. Usually the TransactIon 0, the
tIme stamp of the transactIon, the old value and the new values of the data are stored In
transactIon logs fIle. Therefore the F08|S Is aware of the state of the database I.e. before
and after Image of data after each transactIon. Every database Is returned to a consIstent
state and the log may be truncated to remove commItted transactIons.

Normally there are two technIques used to maIntaIn the log fIles.
5.13.1. 0eferred update
0eferred update, or ND UN0D/FE0D, Is an algorIthm to support transactIon faIlures owIng to
D/S, applIcatIon, power, memory and machIne faIlures.

WhIle a transactIon runs, not updates/alteratIons made by that transactIon are recorded In
the database but captured only In the log fIles.

Dn commIt, data changes are applIed to the database usIng the log fIles. ThIs process Is called
as "FedoIng"

Dn rollback, data changes whIch are captured In the log fIles are dIscarded and no changes
are made to the database.

Dn system restart, due to any of the above mentIoned reasons If transactIon faIls and It Is not
commItted, contents of the log fIles are dIscarded and the transactIon wIll be restarted. f It
Is commItted before crashIng then after restart, the log fIle contents are applIed to the
database.
Sequences of deferred update are explaIned In FIgure 512 and FIgure 51J.

Time Transaction Disk Before Disk After Log
10:22 Start 6 6
Start
Timestamp
10:23 Read fieId F1 6 6
10:24 Update F1 to 23 6 6 (6,23)
10:25 Read fieId F2 12 12
10:24 Update F2 to 45 12 12 (12,45)
10:25 Commit F1=23, F2=45 Commit
FIgure 5-12: 0eferred Update
From FIgure 512 It Is evIdent that when transactIon updates the fIeld F1 to 2J and fIeld F2 to
45 In maIn memory log fIle wIll have old value and new value of the fIeld. 0atabase dIsk fIle
stIll holds the old values. Contents of database are modIfIed usIng log fIle only after
transactIon commIts. The process or redoIng the transactIon from the log Is sometImes
referred as 'PoIIforward'. 0Isadvantage of deferred update technIque Is Increased tIme of
recovery In case of system faIlure.

FIgure 5-13: Sequences of 0eferred Update
5.13.2. ImmedIate Update
mmedIate update, or UN0D/FE0D, Is another algorIthm to support transactIon faIlure owIng
to D/S, applIcatIon, power, memory or machIne faIlure.

WhIle a transactIon runs, updates/alteratIons made by that transactIon can be wrItten to the
database dIrectly. However, the orIgInal and the new data beIng wrItten must both be stored
In the log 8EFDFE wrItIng It to the database.
Dn commIt, all the changes to the database are made permanent and log contents are
dIscarded.
Dn rollback, usIng the log entrIes, old values are restored. All the changes whIch that
transactIon has made to the database dIsk are dIscarded. ThIs process Is called as "UndoIng".
0atabase changes are made permanent once the system restarts, after the crash for
commItted transactIons. The orIgInal values are restored usIng the log fIles for uncommItted
transactIons.

TransactIon snapshot Is shown In FIgure 514 and sequences of ImmedIate update process are
shown In FIgure 515.
Time Transaction Disk Before Disk After Log
10:22 Start 6 6
Start
Timestamp
10:23 Read coIumn F1 6 6
10:24 Update F1 to 23 6 23 (6,23)
10:25 Read CoIumn F2 12 12
10:24 Update F2 to 45 12 45 (12,45)
10:25 Commit F1=23, F2=45 Commit
FIgure 5-14: ImmedIate Update
From FIgure 514 Is evIdent that when transactIon updates the fIeld F1 to 2J and fIeld F2 to
45 In maIn memory log fIle wIll have old value and new value of the fIeld. SImultaneously
database dIsk fIle also modIfIed to reflect the new values even before transactIon commIts.
For any reason If transactIon faIls to commIt, contents of database dIsk fIles values are
restored to old values usIng log fIle. The process of undoIng changes usIng the log fIles Is
frequently referred to as roIIback. 0Isadvantage of ImmedIate update technIque Is frequent
/D operatIons whIle the transactIon Is actIve.


FIgure 5-15: Sequences In ImmedIate Update
5.13.3. Check-PoInts
Usually In commercIal F08|S applIcatIons neIther the deferred updates nor the ImmedIate
updates are used because of theIr dIsadvantages. n these commercIal F08|S applIcatIons,
databases are updated at fIxed Intervals of tIme; say every 2 mInutes, IrrespectIve of the
transactIon commIt/uncommIt state. UpdatIng the database at fIxed Intervals of tIme Is
called as checkpoIntIng.

At the check poInt tIme, the contents of the log fIles are applIed to the database.
TransactIons may be commItted or noncommItted at the check poInt. Later If the transactIon
rolls back, the database Is restored to the orIgInal state usIng the log fIles. As already
explaIned, thIs process Is called as "UndoIng". f the transactIon commIts, changes are made
permanent, agaIn usIng the log fIles. ThIs process Is called as "FedoIng". Hence check poInt
based updates use both the Follforward and the Follback mechanIsm. To some extent thIs
technIque speeds up the recovery mechanIsm durIng Instance faIlures.

For example consIder the snapshot of the database shown In FIgure 516.

Memory Memory
Crash Crash
Memory Memory
Crash Crash
Memory Memory
Crash Crash
CC
Ts Ts
Tc Tc
Tf Tf
B A B A
T2
T1: ABC T1: ABC
T2: AB T2: AB
T4: AB T4: AB
T1: ABC T1: ABC
T2: AB T2: AB
T4: AB T4: AB
T1: ABC T1: ABC
T2: AB T2: AB
T4: AB T4: AB
T2: C T2: C
T3: ABC T3: ABC
B A BB AA
T5
T5: AB T5: AB
Check Check
Point Point
Check Check
Point Point
Log FiIe Log FiIe
Database Database
Start Start
FaiIure FaiIure

FIgure 5-16: CheckpoInt ScenarIo
Let us analyze the sItuatIon on a system restart, after an unfortunate crash

1. TransactIon T1 commItted before check poInt and also wrote to the database hence no
changes are requIred In the database.
2. TransactIon T2 commItted before system faIlure but partIally wrote to the database at
the check poInt. After restart, other parts of T2 should be wrItten to the database
usIng the log fIles.
J. TransactIon TJ began after the checkpoInt hence contents were not wrItten to the
database but successfully completed before crash. Complete transactIon needs to be
wrItten to the database usIng the log fIle.
4. TransactIon T4 began before the checkpoInt hence part of T4 was wrItten to the
database. The unfortunate crash happened before T4 commItted. Hence It Is requIred
to undo the changes to the database usIng the log fIles and restore It to the old values.
5. The contents of the transactIon T5 In the log fIles needs to be dIscarded and the
transactIon needs to be restarted as thIs transactIon started after checkpoInt and
hence no traces of thIs transactIon exIst In the database.

Fecovery scenarIo Is explaIned In the FIgure 517:

T1: ABC T1: ABC
T2: AB T2: AB
T4: AB T4: AB
T1: ABC T1: ABC
T2: AB T2: AB
T4: AB T4: AB
T2: C T2: C
T3: ABC T3: ABC
T5: AB T5: AB
Log FiIe Log FiIe
Database Database
Start Start Check Point Check Point Memory Crash Memory Crash
T1 : No Changes T1 : No Changes
T2 : Redo C T2 : Redo C
T3 : Redo ABC T3 : Redo ABC
T4 : Undo AB T4 : Undo AB
T5 : Discard AB T5 : Discard AB
C C
T3 : ABC T3 : ABC
T1 T1
Commits Commits
C B A
T2
B A
T5 T5
T2 T2
Commits Commits
T3 T3
Commits Commits
T4 T4
No Commit No Commit
T5 No T5 No
Commit Commit
T1: ABC T1: ABC
T2: AB T2: AB
T4: AB T4: AB
T1: ABC T1: ABC
T2: AB T2: AB
T4: AB T4: AB
T2: C T2: C
T3: ABC T3: ABC
T5: AB T5: AB
Log FiIe Log FiIe
Database Database
Start Start Check Point Check Point Memory Crash Memory Crash
T1 : No Changes T1 : No Changes
T2 : Redo C T2 : Redo C
T3 : Redo ABC T3 : Redo ABC
T4 : Undo AB T4 : Undo AB
T5 : Discard AB T5 : Discard AB
C C
T3 : ABC T3 : ABC
T1 T1
Commits Commits
C B A
T2
B A
C B A
T2
CC B A B A
T2
B A BB AA
T5 T5
T2 T2
Commits Commits
T3 T3
Commits Commits
T4 T4
No Commit No Commit
T5 No T5 No
Commit Commit

FIgure 5-17: Pecovery from Crash

Note: System can not be restored usIng the log fIles for hard dIsk faIlure(s).
Dnly backup of data fIles and log fIles can save databases from medIa faIlures.

Examles:
1. Pecovery usIng deferred update In a sIngIe-user envIronment

ConsIder the read and wrIte operatIons of two transactIons T1 and T2 gIven below:

T1 T2
read_Item(A) read_Item(8)
read_Item(0) wrIte_Item(8)
wrIte_Item(0) read_Item(0)
wrIte_Item(0)
The system log at the tIme of crash Is as gIven below:

start T1
wrIte_Item, T1, 0, 20
commIt T1
start T2
wrIte_Item, T2, 0, 25 System crash

SoIutIon: TransactIon T1 commIts before the system crash. The operatIons of transactIon
T1 are therefore redone (redone means contents of the log fIles are applIed to the data fIle).
The entrIes In the log correspondIng to transactIon T2 are Ignored by the system because T2 Is
not commItted.

2. Pecovery usIng check poInts (concurrent transactIons consIdered)

ConsIder the read and wrIte operatIons of transactIons T1, T2, TJ and T4 gIven below:

T1 T2 TJ T4
read_Item(A) read_Item(C) read_Item(A) read_Item(C)
read_Item(8) wrIte_Item(C) wrIte_Item(A) wrIte_Item(C)
wrIte_Item(8) read_Item(8) read_Item(E) read_Item(A)
wrIte_Item(8) wrIte_Item(E) wrIte_Item(A)

The system log at the tIme of crash Is as gIven below:

start T1
commIt T1
checkpoInt
start T4
wrIte_Item, T4, C, 15
wrIte_Item, T4, A, 20
commIt T4
start T2
wrIte_Item, T2, C, 12
start TJ
wrIte_Item, TJ, A, J0
wrIte_Item, T2, E, 25 System crash

SoIutIon:

TransactIon T1 commItted before the checkpoInt. Therefore no operatIon Is performed on
account of It.

TransactIon T4 Is redone because Its commIt poInt Is after the last system checkpoInt.

TransactIon T2 and TJ are Ignored because they dId not reach theIr commIt poInts.
5.14. Summary
All transactIons should be:
AtomIc
ConsIstent
solated
0urable

DLTP applIcatIons should ensure:
ntegrIty
Concurrency
SecurIty
Fecovery

ntegrIty of the F08|S applIcatIon can be maIntaIned usIng:
EntIty ntegrIty
FeferentIal ntegrIty
0omaIn ntegrIty

WhIle allowIng Concurrency one may face problems In ImplementIng consIstency.
FollowIng are the four major problems encountered:
Lost Updates
0Irty Fead
ncorrect Summary
Phantom records

ConsIstency can be Implemented usIng serIalIzatIon technIques lIke:
LockIng
TImestampIng

LockIng technIque leads to the dead lock problem
TIme stampIng technIque leads to many rollback problem

SecurIty Is Implemented In F08|S usIng:
User 0 / Password
Crant and Fevoke commands
7Iews
Two types of recovery mechanIsm can be Implemented In the F08|S applIcatIon:
|edIa faIlures usIng backup strategy
nstance recovery usIng transactIon log fIles
Two types of backups are possIble:
Cold backup
Hot backup
Three types of updates to the database are possIble, usIng the transactIon log fIles:
mmedIate update
0eferred update
CheckpoInt based updates


6. Dn LIne AnaIytIcaI ProcessIng (DLAP)
0ata Is the key asset of any organIzatIon or enterprIse. DperatIonal actIvItIes of an
organIzatIon Include daytoday busIness processes necessary to run It. Systems that support
such processes are called the Dn LIne TransactIon ProcessIng (DLTP) systems. DperatIonal
data are hIghly structured data that Is contInuously generated and stored In what Is typIcally
called as operatIonal or transactIonal or DLTP databases.

An organIzatIon's success also depends on Its abIlIty to analyze data and to make IntellIgent
decIsIons that would potentIally affect Its future. Systems that facIlItate such analysIs are
called Dn LIne AnalytIcal ProcessIng (DLAP) systems.

An DLTP applIcatIon rarely requIres hIstorIcal data. An DLAP applIcatIon requIres hIstorIcal
data because an analysIs Is generally based on a substantIal amount of hIstorIcal data to
enable trend analysIs and future predIctIons.

An DLTP transactIon Is characterIzed by several users creatIng, updatIng or retrIevIng
IndIvIdual records whereas DLAP applIcatIon Is characterIzed by hIgher level vIews of the
data.

Thus the focus of DLTP and DLAP are fundamentally dIfferent. The followIng sectIon gIves
the dIfference between DLTP and DLAP.
6.1. 0Ifference between DLTP and DLAP

DLTP DLAP
0efInItIon Dn LIne TransactIon
ProcessIng
Dn LIne AnalytIcal ProcessIng
0ata 0ynamIc (day to day
transactIon / operatIonal
data)
StatIc (hIstorIcal data)
0ata AtomIcIty 0ata Is stored at mIcroscopIc
level
0ata Is aggregated or
summarIzed and stored at the
hIgher level
NormalIzatIon NormalIzed 0atabases to
facIlItate InsertIon, deletIon
and updatIon
0enormalIzed 0atabases to
facIlItate querIes and analysIs
HIstory Dld data Is purged or archIved HIstorIcal data stored to enable
trend analysIs and future
predIctIons
QuerIes SImple querIes and updates
QuerIes use small amounts of
data
( one record or a few records)
Example:
update account balance
enroll for a course

Complex querIes
QuerIes use large amounts of
data

Example:
Total annual sales for north
regIon
Total monthly sales for north
regIon
Updates Updates are frequent Updates are Infrequent
Fesponse tIme Fast response tIme Is
Important
0ata must be uptodate,
consIstent at all tImes
TransactIons are slow
QuerIes consume a lot of
bandwIdth
JoIns In querIes JoIns are more and complex as
tables are normalIzed
JoIns are few and sImple as
tables are denormalIzed
An DLTP system aIms at one
specIfIc process
Example: orderIng from an
onlIne store
An DLAP Integrates data from
dIfferent processes
Example: CombInes sales,
Inventory and purchasIng data
0ata models Complex data models, many
tables
SImple data models, fewer
tables
Focus DLTP focuses on performance DLAP focuses on flexIbIlIty and
broader scope

A practIcal solutIon to enable analytIcal processes Is to Implement a data warehouse.
6.2. 0ata Warehouse
A data warehouse Is a reposItory whIch stores Integrated InformatIon for effIcIent queryIng
and analysIs. 0ata warehouse has data collected from multIple, dIsparate sources of an
organIzatIon. t Is the basIs for decIsIon support and data analysIs systems.
6.2.1. Why data warehouse Is needed!
AnalysIs requIres mIllIons of records of data whIch are hIstorIcal In nature
0ata Is collected from heterogeneous sources (e.g. F08|S, flat fIles, etc.)
Need to make quIck and effectIve strategIc decIsIons

n essence, It Is a copy of the organIzatIon's operatIonal data adequately modIfIed to support
the needs of analytIcal processes and stored outsIde the operatIonal database.
6.2.2. CharacterIstIcs of 0ata Warehouse:
AccordIng to 8Ill nmon, known as the father of 0ata WarehousIng, a data warehouse Is a
subject orIented, Integrated, tImevarIant, nonvolatIle collectIon of data In support of
management decIsIons.

Subject-orIented: means that all data pertInent to a subject/ busIness area are
collected and stored as a sIngle unIt

Integrated: means that data from multIple dIsparate sources are transformed and
stored In a globally accepted fashIon

StatIclnon-voIatIIe: means data once entered Into the warehouse does not change
frequently. t Is perIodIcally updated If requIred

TIme varIant: 0ata warehouse maIntaIns hIstorIcal data whIch are used to analyse the
busIness or market trends and facIlItate future predIctIons

FIgure 6-1: 0ata warehouse archItecture
6.2.3. 0ata WarehousIng TermInoIogy
0ata sources: An organIzatIon has many functIonal unIts wIth theIr own data. 0ata from all
such sources have to be consolIdated and put Into a consIstent form that would reflect the
busIness of an organIzatIon as a whole. These sources of data for a data warehouse are known
as data sources or operatIonal data sources.

hetadata: |etadata Is the InformatIon about the data. ThIs Is the layer of the data
warehouse whIch stores the InformatIon lIke the source data, transformed data, date and
tIme of data extractIon, target databases, date and tIme of data loadIng, etc.

heasure attrIbutes: A numerIcal value that can be summarIzed or can be aggregated upon.
Examle: Consder cn nventory cpplccton. Assume thct the nventory store sells twenty
products n one dcy, ecch ]or 5 dollcrs. Thus t yenerctes 100 dollcrs n totcl scles ]or the
dcy. There]ore, scles dollcrs s one mecsure. The store owner myht wcnt to know how mcny
customers they hcd thct dcy. 0d 5 customers buy 4 products ecch, or dd one customer buy
twenty products. Thus, customer count s cnother mecsure.

0ImensIon attrIbutes: 0ImensIons can be defIned as the perspectIves used for lookIng at the
data. 0ImensIons are the answer to the questIon "How do you want to see your data:" Some
examples of dImensIons are:

Product
TIme
LocatIon
Customer Age
Customer ncome

There Is almost always a tIme dImensIon on anythIng whIch Is beIng analyzed. Consderny
the excmple yven ]or mecsure cttrbutes, scles ccn be cnclyzed by dcy, or by qucrter, or by
yecr. Scles ccn clso be cnclyzed by ccteyory or by product. There Is almost always a tIme
dImensIon and product and geographIc dImensIons are very common as well.

0ata that can be modeled as dImensIon attrIbutes and measure attrIbutes are called
multIdImensIonal data.
6.2.4. 0ata CoIIectIon for 0ata Warehouse AppIIcatIons
ExtractIon, transformatIon and IoadIng (ETL): ETL Is the most Important step In 0ata
WarehousIng.

0efInItIon of ETL: Extract, transform and load process Is descrIbed as the process of
selectIng, mIgratIng, transformIng, cleansIng and convertIng mapped data from the
operatIonal envIronment to data warehouse envIronment.

0ata needs to be taken from varIous dIsparate sources to the data preparatIon area. ThIs
process Is known as data extractIon. ThIs data preparatIon area, also known as data stagIng
area consIsts of relatIonal tables. 0ata from varIous heterogeneous sources are transformed
Into a common format and put Into relatIonal tables of data preparatIon area, so that It can
be loaded Into the data warehouse database. ThIs process Is known as loadIng. The data Is
loaded Into the fact table and dImensIon tables In the data warehouse database. Fefer to
FIgure 62.
Source Systems
Data Staging Area
Data
Warehouse
Data is periodicaIIy extracted
Data is cIeansed and transformed
User query the data warehouse

FIgure 6-2: ExtractIon, TransformatIon and LoadIng Process
6.2.5. StorIng of data In 0ata warehouse
0ImensIonaI hodeIIng: The dImensIonal modelIng Is also known as star schema because In
dImensIonal modelIng there Is a large central fact table wIth many dImensIon tables
surroundIng It.

Fact TabIes: Each data warehouse or data mart Includes one or more fact tables. A fact table
Is central to a star or snowflake schema, and captures the data that measures the
organIzatIon's busIness operatIons. Fact tables usually contaIn large numbers of rows.

A key characterIstIc of a fact table Is that It contaIns numerIcal data (facts) that can be
summarIzed to provIde InformatIon about the hIstory of the operatIon of the organIzatIon.
Each fact table also Includes a multIpart Index that contaIns as foreIgn keys, the prImary keys
of related dImensIon tables, whIch contaIn the attrIbutes of the fact records. Fact tables
should not contaIn descrIptIve InformatIon or any data other than the numerIcal measurement
fIelds and the Index fIelds that relate the facts to correspondIng entrIes In the dImensIon
tables.

0ImensIon TabIes: 0ImensIon tables contaIn attrIbutes that descrIbe fact records In the fact
table. Some of these attrIbutes provIde descrIptIve InformatIon; others are used to specIfy
how fact table data should be summarIzed to provIde useful InformatIon to the analyst.
0ImensIon tables contaIn hIerarchIes of attrIbutes that aId In summarIzatIon. For example, a
dImensIon contaInIng product InformatIon would often contaIn a hIerarchy that separates
products Into categorIes, wIth each of these categorIes further subdIvIded Into manufacturer.
Cube: The DLAP tools allows you to turn data stored In relatIonal databases Into meanIngful,
easy to navIgate busIness InformatIon by creatIng data cube. The dImensIons of a cube
represent dIstInct categorIes for analyzIng busIness data. CategorIes such as tIme, geography
or product lIne breakdowns are typIcal cube dImensIons.

0ImensIon hIerarchIes: Fefer to FIgure 6J. The product dImensIon contaIns IndIvIdual
products. Products are classIfIed Into categorIes, and further classIfIed accordIng to
manufacturer. The hIerarchy for the dImensIon Is stored In the dImensIon table.

Products
Products_
Category
Products_
Manufacturer
Year
Quarter
Month
Day

FIgure 6-3: 0ImensIon HIerarchIes

AvaIIabIe Schemas for dImensIonaI modeIIng:

Star schema
Snowflake Schema

Star Schema: t Is the sImplest data warehouse schema. t resembles a star. The center of the
star consIsts of one or more fact tables and the poInts radIatIng from the center are the
dImensIon tables. Fefer to FIgure 64.

FIgure 6-4: Star Schema

SnowfIake Schema: t Is a complex data warehouse schema. The snowflake schema has a
sIngle, central fact table surrounded by normalIzed dImensIon hIerarchIes. Each dImensIon
level Is represented In a table. Fefer to FIgure 65.

FIgure 6-5: SnowfIake Schema

0Isadvantages of SnowfIake Schema:
t Increase the number of dImensIon tables
t requIres more foreIgn key joIns
6.2.6. PeportIng of a 0ata warehouse appIIcatIon
A data mart Is a focused subset of a data warehouse that deals wIth a sIngle area of data and
Is organIzed for quIck analysIs. t can be a small data warehouse Itself.
6.2.6.1. Advantages of 0ata harts:
t focuses on presentatIon rather than the organIzatIon of data
t facIlItates data reportIng
t provIdes meanIngful reports to the users pertaInIng to theIr busIness area thereby
allowIng them to vIew and concentrate only on the data that Is related to theIr
busIness area
Examle: provdny scles dctc to the scles depcrtment, provdny ]ncnccl dctc to
the ]ncnccl depcrtment
t makes the data desIgn sImpler and easIer. t breaks the whole desIgn Into several
smaller sub unIts whIch Is benefIcIal to the customers and the development team. t Is
also easIer to maIntaIn
FeportIng of data becomes faster and more effIcIent because reportIng Is generally
done at the sub unIt level and data marts assIst In faster retrIeval compared to
queryIng the entIre data warehouse
t helps In Incrementally buIldIng up the enterprIse data warehouse
t helps to ensure securIty

FIgure 6-6: Each end user works wIth a focused subset of 0ata Warehouse caIIed 0ata hart
Several data marts can be buIlt, each for a partIcular busIness area provIded they all conform
to the data warehouse archItecture from where they get the data for reportIng. 0ata marts
can be used In conjunctIon wIth each other. Fefer to FIgure 66.
6.2.7. 0Ifference between 0ata Warehouse and 0ata hart
0ata Warehouse 0ata |art
A data warehouse Is a reposItory whIch
stores Integrated InformatIon from
multIple dIsparate sources for effIcIent
queryIng and analysIs

A data mart Is a focused subset of a data
warehouse that deals wIth a sIngle area of
data and Is organIzed for quIck analysIs.
t Is concerned wIth the organIzatIon of
data and offers lIttle concern regardIng
the presentatIon of data to the customers
t Is concerned maInly wIth the
presentatIon of data to the customers
rather than the organIzatIon of data In
the data warehouse
There Is usually a central data warehouse
system
There can be several data marts that
operate on the central data warehouse
0ata Warehouse Is used on an enterprIse
level
0ata |art Is used on a busIness dIvIsIon /
department level
0ata Warehouse contaIns data from
heterogeneous sources for analysIs
0ata |art only contaIns the requIred
subject specIfIc data for local analysIs
6.2.8. PopuIar tooIs avaIIabIe for data warehousIng

PeportIng l AnaIysIs TooIs:
|Icro Strategy: 0SS Agent / Server
Cognos: mproptu
8rIo Technology: 8rIo Query
Seagate Software: Crystal Feports

ETL:
0ata JunctIon
|Icrosoft 0TS (AvaIlable wIth SQL Server 7.0 and above)
Dracle Warehouse 8uIlder
nformatIca: Power|art
8|: 0ataPropagator
Acta: ActaWorks

0atabases:
|008
Dracle Express
SAS
6.3. Summary
An DLAP applIcatIon requIres hIstorIcal data because an analysIs Is generally based on
a substantIal amount of hIstorIcal data to enable trend analysIs and future predIctIons
A data warehouse Is a reposItory whIch stores Integrated InformatIon for effIcIent
queryIng and analysIs
Extract, transform and load process (ETL) Is descrIbed as the process of selectIng,
mIgratIng, transformIng, cleansIng and convertIng mapped data from the operatIonal
envIronment to data warehouse envIronment
A data mart Is a focused subset of a data warehouse that deals wIth a sIngle area of
data and Is organIzed for quIck analysIs
Star schema Is the sImplest data warehouse schema. t resembles a star. The center of
the star consIsts of one or more fact tables and the poInts radIatIng from the center
are the dImensIon tables
Snowflake schema has a sIngle, central fact table surrounded by normalIzed dImensIon
hIerarchIes

nfosys TechnologIes LImIted Clossary

CIossary
Abstract: Conceptual/theoretIcal object.

AbstractIon: A sImplIfIed representatIon of somethIng that Is potentIally quIte complex. t Is often not
necessary to know the exact detaIls of how somethIng works, Is represented or Is Implemented,
because It can stIll be used In Its sImplIfIed form.

AmbIguIty: UncertaInty.

AnomaIIes: rregularItIes.

AnomaIy: A departure from the expected; an abnormalIty.

AtomIc: The smallest levels to whIch data may be broken down and remaIn meanIngful.

AttrIbute: The lIteral meanIng Is qualIty; characterIstIc; traIt or feature. EntItIes are descrIbed In a
database by a set of attrIbutes. For Example, In the bank system, Cust_0, Cust_EmaIl etc. descrIbe
Customer0etaIl entIty set.

ackup: A second copy of a fIle or set of fIles to be used In case the prImary fIle(s) are destroyed or
corrupted. 8ackups are essentIal for all but the most trIvIal work. For crItIcal work, two backup sets
are advIsable.

usIness ruIes: The rules/polIcIes whIch govern the functIonIng of the applIcatIon.

usIness users: The users who owns the applIcatIon.

CardInaIIty of a reIatIon: The number of records / tuples In a table.

CentraIIzed: Systems where decIsIon makIng, flow of data or the begInnIng of actIvItIes are InItIated at
the same central poInt and dIssemInated to remote poInts In the organIzatIon

ConceptuaI: To generalIze abstract Ideas from specIfIc Instances.

Concurrent Access: PerformIng two (or more) operatIons on the same data at the same tIme.

ConstraInts: restrIctIon, lImItatIon.

0ata manIpuIatIon: 0ata manIpulatIon refers to the addItIon of new data, modIfIcatIon of exIstIng
data, etc.

0ata Pedundancy: HavIng the same data stored In more than one place In a database.

0ecomposabIe: Further splIt or reduce.

0egree of a reIatIon: The number of columns/ attrIbutes In a table.

0IstInct: Not IdentIcal.

0IstrIbuted: A computer system Is dIstrIbuted when dIfferent components and objects comprIsIng an
applIcatIon can be located on dIfferent computers connected to a network.


EncryptIon: The process of manIpulatIon of data to prevent accurate InterpretatIon by all but those for
whom the data Is Intended.

End User: The person for whom a system Is beIng developed. Example: a bank teller or a bank manager
Is an end user of a bank system.

EntIty: An entIty Is a "thIng" or "object" In the real world that Is dIstInguIshable from other objects.
Example: each person Is an entIty, and bank accounts can be consIdered to be entItIes.

FIat fIIes: A flat fIle Is a fIle contaInIng records that has no structured InterrelatIonshIp. FIles used In
programmIng fundamentals (PF) projects were essentIally flat fIles.

Fourth CeneratIon Language (4CL): A 4CL Is typIcally nonprocedural and desIgned so that end users
can specIfy what they want wIthout havIng to know how the computer wIll process theIr requIrement.

Crant PrIvIIege: To assIgn a prIvIlege to a user or group.

Heterogeneous: varIed, mIxed, dIverse.

Heterogeneous Network: A network that consIsts of workstatIons, servers, network Interface cards,
operatIng systems, and applIcatIons from many vendors, all workIng together as a sIngle unIt. The
network may also use dIfferent medIa and dIfferent protocols over dIfferent network lInks.

Homogeneous: All the same, unIform, harmonIzed.

Homogeneous Network: A network composed of systems of sImIlar archItecture and runs a sIngle
network layer protocol.

InconsIstency: lackIng unIformIty or agreement.

Instance: Dccurrence.

Integrated: UnIted Into a larger unIt. 8rought together to form a satIsfactory and workIng whole

IntegrIty ConstraInts: A set of rules to ensure the correctness and accuracy of data.

InterreIated: Interconnected

IntuItIve: Natural.

IteratIve: Process of repeatIng the same task.

Jargons: The specIalIzed or technIcal language of a trade, professIon, or sImIlar group.

haIn hemory: Please recall CHSSC concepts All the read and wrIte operatIons happen In maIn
memory before they are wrItten Into hard dIsks.

hInImaI: |InImum, the least possIble.

hodeI: A representatIon or a scaled down structure of an object.

Page: t Is part of a table. Usually In one page multIple rows are stored.

PartIcIpatIng entItIes: The entItIes whIch are joIned by the relatIon.


uerIes: A query Is essentIally a request that a user makes on the database.

Pecovery: FestoratIon, return to an orIgInal state.

Pefer: relate to.

PequIrement specIfIcatIon: A document whIch contaIns requIrement for a specIfIc applIcatIon.

Pevoke PrIvIIege: Cancel, wIthdraw.

Schema: A descrIptIon of a database. t specIfIes (among other thIngs) the relatIons, theIr attrIbutes,
and the domaIns of the attrIbutes.

SemantIc: |eanIng.

Shared: A type of database access that allows multIple users to be logged on sImultaneously to the
same database

SImuIate: To make a model.

SIte: CeographIcal locatIon.

Software appIIcatIon desIgner: The person who desIgns software applIcatIons.

SL: (Structured Query Language). A language used by relatIonal databases to query, update and
manage data.

StatIc: SomethIng whIch does not change. (Example: the typIcal web page Is statIc In that It does not
change untIl the webmaster physIcally alters the document.)

Superset: CIven two sets, A and 8, A Is a superset of 8 If all elements of 8 are also elements of A.
Every set Is a superset of Itself, and every set Is a superset of the empty set.

TabIe: A table has a specIfIed number of columns but can have any number of rows. Fows stored In a
table are structurally equIvalent to records from flat fIles.

TabIespace: The logIcal part of the database whIch represents collectIon of the structures lIke tables,
etc created by varIous users.

TangIbIe: PhysIcal object.

TransactIon: A group of processIng steps that are treated as a sIngle actIvIty to achIeve a desIred
result. n 08|S, collectIons of operatIons that form a sIngle logIcal unIt of work are called
transactIons. A database system ensures proper executIon of transactIons despIte faIlures - eIther the
entIre transactIon executes, or none of It does.

TransIent: Temporary, transItory, momentary.

TransItIve: ndIrect.

TupIe: ThIs Is a mathematIcal term for a fInIte sequence of n terms. For example, the set [1, 2, J, 4] Is
a fourtuple. A tuple Is equIvalent of a record. n F08|S, a table has n tuples.

UnauthorIzed: Not permItted, Illegal, unlawful.
VIew: A vIew Is a vIrtual table In the database defIned by a query.
nfosys TechnologIes LImIted ndex

Index

A
A8DFT..............................................144
AC0 ................................................147
ALTEF TA8LE....................................... 85
ApplIcatIon Programmer ......................... 21
AttrIbute............................................ J8
8
8ottomUp.......................................... 56
8oyce Codd Normal Form........................ 65
C
CandIdate Key ..................................... 27
CardInalIty of a FelatIon......................... 26
CardInalIty of relatIonshIp....................... J8
Ccrtescn product................................121
CentralIzed......................................... 15
CHECK DPTDN....................................1J1
CheckPoInts ......................................169
CD||T ............................................144
Conceptual / LogIcal level....................... 18
Concurrency.......................................148
Concurrent Access ..................................4
Concurrent Access AnomalIes ................... 1J
CoFelated SubQuerIes .........................117
CFEATE TA8LE ..................................... 79
Cube................................................180
0
0ata Control Language (0CL)...................1J2
0ata 0efInItIon Language (00L) ................ 78
0ata solatIon ...................................... 12
0ata |anIpulatIon Language (0|L)............. 91
0ata |art ..........................................181
0ata |odel ......................................... 22
0ata Fedundancy.................................. 11
0ata SecurIty ...................................... 11
0ata Warehouse ..................................176
0atabase..............................................2
0atabase AdmInIstrator .......................... 21
0atabase |anagement System....................1
08MS lnter]cce ......................................8
0eadlock...........................................161
0eferred Update .................................166
0egree of a FelatIon.............................. 26
0ELETE.............................................. 94
0erIved AttrIbute ................................. 41
0etermInant ....................................... 57
0ImensIon HIerarchIes...........................180
0ImensIon Tables.................................179
0ImensIonal |odelIng............................179
0Irty Fead .........................................150
0IstrIbuted ......................................... 15
0omaIn ntegrIty..................................147
0FDP TA8LE........................................ 87
0FDP 7EW ........................................129
E
Embedded SQL....................................1J5
End User ............................................ 21
EntIty................................................ J7
EntIty ntegrIty ConstraInt ....................... 29
ExclusIve Lock ....................................15J
EXSTS ..............................................127
External / 7Iew level ............................. 18
F
Fact Tables ........................................179
FIle System.......................................... 6
FIrst Normal Form................................. 60
Flct Fles............................................. 6
ForeIgn Key......................................... J0
Full FunctIonal 0ependency ..................... 59
FunctIonally 0ependent .......................... 58
6
CFANT..............................................1JJ
CFDUP 8Y .........................................107
H
HA7NC.............................................110
Heteroyeneous..................................... 17
HIerarchIcal 0ata |odel.......................... 2J
Homoyeneous ...................................... 17
HorIzontal 7Iew...................................129
l
mmedIate Update ...............................167
ncorrect Summary...............................150
ndependent SubQuerIes .......................115
ndex ................................................ 88
NNEF JDNS.......................................12J
NSEFT............................................... 91
ntegrated ........................................... J
ntent LockIng.....................................156
nternal / PhysIcal level.......................... 19
lnterrelcted......................................... 2
NTEFSECT.........................................114
nfosys TechnologIes LImIted ndex

1
JoIns................................................121
K
Key AttrIbute ................................. 41, 60
L
Lack of FlexIbIlIty ................................. 1J
LEFT DUTEF JDN ................................125
Lost Update .......................................149
M
|any to |any FelatIonshIp ...................... 40
|any to Dne FelatIonshIp........................ J9
|aster FIle ...........................................8
|ultIvalued AttrIbute............................. 41
N
Network |odel..................................... 24
NonKey AttrIbutes................................ JJ
NormalIzatIon...................................... 56
NDT EXSTS........................................128
D
Dbject 8ased LogIcal |odel ..................... 2J
Dn LIne AnalytIcal ProcessIng (DLAP).........175
Dne to |any FelatIonshIp........................ J9
Dne to Dne FelatIonshIp ......................... J8
DF0EF 8Y..........................................104
DverlappIng CandIdate Keys..................... 66
P
PartIally 0ependent .............................. 60
Pcrtcpctny Enttes............................. 52
Phantom Fecord..................................151
PrImary Key ........................................ 29
Program/0ata 0ependence...................... 12
R
F08|S............................................... 26
Fecord 8ased LogIcal |odel ..................... 2J
FecursIve FelatIonshIp ........................... 42
FeferentIal ConstraInt............................ J1
FelatIonal 0atabase............................... 26
FelatIonal |odel................................... 25
FelatIonshIp........................................ J8
FE7DKE ............................................1J4
FCHT DUTEF JDN...............................126
FDLL8ACK .........................................144
S
Second Normal Form.............................. 62
SELECT .............................................. 96
SELF JDN..........................................122
Self FeferencIng................................... J1
Shared ntent ExclusIve .........................157
Shared Lock .......................................15J
SharIng ............................................... J
Snowflake Schema ...............................181
SQL .................................................. 74
Star Schema.......................................180
Super Key........................................... JJ
T
ThIrd Normal Form................................ 65
TImestampIng.....................................162
Top0own Approach .............................. 42
TransactIon Log...................................165
Trcnscctons ........................................ 1
TransItIve 0ependency ........................... 60
TFUNCATE TA8LE.................................. 88
0
UNDN ..............................................112
UP0ATE ............................................. 96
\
7ertIcal 7Iew......................................129
7Iew................................................129
W
WHEFE .............................................. 98

Relational Database Management System

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Relational Database Management System

Uploaded by

Copyright:

Available Formats

PeIatIonaI 0atabase hanagement System

Education & Research Department

You might also like