Download as pdf or txt
Download as pdf or txt
You are on page 1of 74

Module-: |NTRODä CTiON to DATABAsE SysTtMs

Dota 9 is aw and isolated/ norganized facts Jhat con ke


ecOrde d (in Jhe form f text , Audio, video, mage etc)
Ly bata. needs to be þooces sed Oheol se it is o6 no use
Ly Infosmahon ! pooce ssed, meoning fl and (Usabe data
Ly Data and informahon Used intenchanyelouy
L eg' In Youhube clalciba se, Jhene milion o6 ideos. Pertson
A cd B' have eXam lomomw and Ohey e Se rchin DBM
Videos on Youuloe . Jhy got 'x', 'y, z ' channel, an Sugses ha
'A' is u0atthtng tom x is oalehin from
fo A! X in (oYinOicn Y, is data
for 8! Y is nGomah on X, Z is data
for Youhbe. evey hing dak only
Database: Database is Collechon Telated data Jhat

Tepresents SOme world enh hes.

L Meaning of el ated data ta Ke an eXample IRCTC, it hay


OLon dalabase. wshen you log in to IRCTC wht
inkormahons oi40 RCTC hawe Trains inkormchan pasengen
in foYmakcn , hotel, in (omahon in fomain. No w Buses

Passenge infomahcn contin in fomahon


Jhose passengeas sho have booked icket any ine,
lgcTC
not have infomahn about cUe pSSenGens
IRCTC Contun nly Jhe in ormahon
Anothen example,
Jhose horel usiich has Some tied
O6
not Con)oin infomahen oo l l hotely e .
Dotabase 0s not Colleci cn Ob any data 9t should be
Collechon related daas So Jha We. Can Temeve
cnd Solve Some
Some infomahon feChvely prble
Database is used o Teeve , in sent cand delote Jhe
cdaB estienty Cmodity also).
Newspoper is iso collec hcn o clata but not dalba se
because you cant mociy Jhe cdata about an eniy.

typialy stored . elechenically (Strucwyed/unstuchwveo)


Jhat 9 dijfeont
Comforts
Iheydata^s. tor
o6 an dalabase
oftype exeniv
daabas
Cdalabano)Cmpony
se. pes Dalabase
is
sualuy
danohed time
databa
elated ty datebase.
(dajabane)
Pixabey
daalsane) clireent gg .sysem
response
steret Aateu
se,Oononls this NOTE applicakona
pi asey
( Seng enter Conjainkand study Jhe Stoved
isSt Cenralized maÀntained
incye an
Youkube Jheir
undeas Such
il
each tho. Sevenol ’
update
’ We Oñented
dalabase
: data
the
fechin
consisBency
is Datcbase’l
daabane! all :databaseacceSS
databane!
database
dalclbane dalabase
dolcbase: understand dhrugh to
daleban database
database: at
dalabase
(image.Cdaa)
Song dalabano.
daabase Nor
eay
Videos
(daka)
daJa) Jhis Hieraschical daa
to
dala
fomm
is Cenraized
USers Poos!
Dala
a Nehuoyk ocah
ons
hashas wncdersood Cenhraiged
) Disibuted
Relahonal biey
a has databases
!. NOSQL
cloudObjec
stores
the
CONS:
hashas flipKut
faobookNetflix
lwhen
the lkeTC Having us
OLA
Let
i) j v) V) Vi) và) Vit)
L
and
heued
dis
Cahon
muni
Com (tupla/ecord) but
is
Seweel
velahonal
data
model 1970. wrde
ange
of
dfenent Heteogeneows of
in
diffeant form
in Docunmon-
omenled
databane.
enform Cselahon!
togeth fovm
tabulan
Cenhalized dasabase
in
aning
anons o res.
doabace
Gaph
systemn data sloing sto
cted
Conne Key
Vaue
storage..
of mn
bured
disbi distibuted use
Same.
ArpliCc«hon forme Stoyetables Colu
On for
used databQ9e.
Unike Same
operahng
handuoave. cand the not
only vau \ide
based
CUle
dalabane invented key
Jhe Columy
(atthbute
) Call
we
isdata,
:dalabase organlzahon Homoseneo
us Relakonal
database. : lahonal
daBabases Same
Dalabase stoes
data @ (D
daa
in
talabase elahonal
A dd
technically
Co re
Distibuked
on system
A
execas
E.F.
Typos
daabase Jhe
se
an
StoTes Sal L
not
a
itL
Jhis
No L>
i)
V) Cloud dabae, , A daoba se uhene ddata is Slored n
Vixal enionmon t and execulis Uen (ho cloud
Compubng ystems/ piatfma. S- pronce use1
S+
Vamos Cloud Compubng Sesvio, (SaaS
vancus ( PaaS, laa Se)
for accening tha database, cloud platfo e.
Amozon web enwico, (Aw)
Micosogt CIZZUYe

Cioogk cloud SQL et


v)
vi object -oniented database Jhe type ot database that
Uses object-based dadata modaly
moolely ppronch for storing daa
in dotaloona. ysler

vi) HiesaYchical dalabase : # selk shudy

vi) Nehoyk databaue # Selk Shudy.

. Why Use databa se ?


Ly Databases ase ed able to Stoye Vast mo, of beCords in
L ince di bly simple and quick to l9cate dala e(fecive man
grs Simple to add neuw dota, moci4y or delet also
LDala Can be easiy Seonched by datalsase techinques
ing, binau Seanch et.
indexing
yDae Can be and easily Sorted
qyickiy
L Daabase pronce. Secumlý of dala.
3

daba)
Having undensiood Jhe Concept o6 database (collecion of velahed
and ushy do We need database (fer esfcienty Solviy a problem
Nlow We,
oiu shedy what is DBMS.

DBMs): - Shands for daabace managemon ysk


also se fenied an daabase Syslems.
-the database.
St is SOtuoaie used to manaye
examples ! Oyacle MySQL, lBM DB 2 etc.
Now
gain,
hay to mangye
IRCTC caabase ue have, DBMS tach Compony uo20 hawe Jheiy
han to manaye
Netflix s database we hcves, DBNS database and to manaye
to manye Jhe. ewey company
flipKant han database we hove DBS wiee hawe Jheir Own dalcbane
manapemor sysem (DBMS)

B Data
Data
M Daa
(usen Daba
4sey Comnnicate to S Daba
bBMS interfac. for
efhient and faster
Diff Progpam
Cocle to in sert Daabase
way os Guil th Aling his dalet, update
Crd quoy dateubane
Tequivemont
infovmahon

prvides Qn
intonface to þei7otm vasous operchbny
liKe daabase Creahon, Serinr data updakns, doleiny data,
L poonden rolechon nd Secuihy to Jhe databane
DeMS’sohuane /managemont of daabase
Allows usen the follootng tas Ks.
(a)
CDaa. definahon : Used for cieahon , modiffcaion cand
that doGnes dhe
definihon -hat 7anizohen t
Temova o
Ihe daa
(o) Dala up daion.. Used for insenhon modifaakon ond cdeleion
aChual dala database
Tehievent data fom cdakaban
Daa retieval: used for

(a) Usen Adminsahca: used for monibin and regisheing


Usens matainy dala integiy, dalabase SecumlG ek.

ReLATIONAL DATABASE MANACtMENT sysTEM ( RDBMS

L All MOdean bBMS hke SQL, MYSQL ^eve , lBs DB2 yacle and
micYosot aC Ces based On ROMS
Based on, selahonal data model DBMS for veahonal(table)
L Al opeyahono liKe in Sert dolota "ane þergomed on
tables
Data is Depre Sented in tesm ok tuply CoLos) n RDBMS
Due. o a Collechon of oYganized Ser oG tables, dae
Can be accened eanily in RDBMS
4

Temin ot RDBNS Columns oy Atibute &

Records
Emp_i E Name Post Salay
tuples Rahul Cleik D0,000
E2
Rows
or Kapil Managen 80, o00
E3 Mukesh clenk 20, o00
E4
Manoj leon Lo, od0
E5
Radha 80, o00
E6
Shweta Manajea
Clik 20, o00

whole Table is called Relahon',


Rouws' called uples Re Covds.
Columns' CUle Callod AHilouheg.
Jhe. Telahon a 4 (n0.06 athibuhes)

Ihe Yelohon = 6 (no. of tuples)


Candinatiy of
Next topic is
File System Vs DBMS
File syshem is
Gke., abasicny
me dium cny o! aTmonging the files in a
shorage
had disk eg. NTEs, EXT
y
Before
File
DBMS
b ased
toadihonal
file syskem was used.
System Wete an eatly aHempt o Compuhen3e Jhe
manul Syskem. Also called Somahme FPs CRle proce sysem)
Vsen USen 2 Usen3
|Roli No)
Stud- fle Sub ile Resutt fle Nam
LCouy Lavecu
Roll No
Name Name mals
CouYse Ld
Credit
DBMS
U
Sen 2
Vsenl
eg- 4 ile syslem. DBMS.
Some impor tant diffeenc b/u Jhem:
Data Tedundoncy and Consiseny:
File Procenj Syslem (FPs) ’ Shing Same daa if. Gomats
and in diff progran'y Canjuage is þossible.
DBMS ’ Conols Kedundanuy in ado i on Swes a
Cot o Stoaye spaca.
it) Conc uvvency !
L mulhple USo1S
accomins tro clata Jhe. Samo me
Can Led toinconsisleny Fps but Jhero ane
Sore prorocols cdegined in DBMS
for
FPs. avoldinN
in conss.
Jhen is Such pobcola in
Secuiby'
L DBNS proiden Secuny
Role ba sed pe1m)ssjor, Ge have in DBMS
A Ccerm Conhoe prorocals
We CAn acce big amont 0f data and ufich
datc as pen youY wi' sh.
All Jhe info. o)l not be Visible to VSeny in D&MS.
File sy stem is handle by opevaing yshem
Which Paicen Secumw at al
iv) Data independence: A fPs does not þende data independeno
utile DBMS onces tuo ty pe, ot Dia in dopencdence
physical data indapendena
data indopendene
v)
Digpeulky in
Acaig data:
DBMS: Random quony
F Ps
Can give instont owtput
Seanch Youvsel 6 (Usen wi! Seaclh mGnualy)
w) Inteçhy Conshraints difhi cutt to apply in Fps
easy to opply
DBMS
Topc : Fle Based Syshem Vs
DBMS
when you open a Cempwen Jhe
cpesoing Sy sten has aieady a
file gstern use d to Store
nd mana data
Your Cormputen
for exam ple. Suppo You want to Store. Jhe date
Sudent tulleuing aaut
gnde youy Computen
’file Reot di vectory
Ar A
2 sahiL
3 Puja
Rai Cdive D- dve E-dive
docx

F-A f-0 f-E f-f

|File syslem
f-J

disk

File Syshem allos yow to Stose Jhe daa


4 ype ot SOthJoe enly to n Jhis ay
mage small amourt of
data C4. NTFS, EXt, PAT)
ohen you & istall any DeMs Csshave ) in yeuy Compule,St
Now,

uy sÙL >data shyed

file sysla

Hand dis
fle Syston but we ane wsiny D8MS
not emoved
We hawe
Jhe sota. moree etiieny.
to manaye
et take an eyample ! oc Shdont data in nvasiy

ACcount [AtAdon JHustee


Aost. Name. en vollad.
9rnde
iles Jhs
cbout shelont n
Lyevey depavmcn sto'y clat daseba apoael
b t in
Callopl (ile sysom a voach.
we have
DBM
Acco
ACodon

Shore ’databau aoach.

tneis O6 dBMS
what e dhe domeiG of Ale syslem
shucluved data pyecdetined ’ easy data
acle
File sysem daa ype is
( stuched data. ’
DBMS
Matl ilems arayemont
Road ije nalage Acodeni,
cifferent sechon ( Acco DD- MM- YYYY
Diff pepk Date’
kollow dif. (onak MMa DD -YYYY
may utich Con MM- yy- DD
ile bamed sysonm
inconsisleney qlso YY- DD- My
(ead to clala
have stuolned data
DBMS we
but in

Accan Secien. (le.


Suprose ALso 9 only to
Name fees Pad
Roll
A 20, D/
A 30, / no Yetet in oh
2
Bo, vo/. Places or tabu wtich j
Cye li dale et incoms
able. to clont
file cyslenn is
Jhe duut caein
Diyfcullg Qccenin Jhe. data.
fw g. (ind6ind ohe nome Shudon uske SCoYed A
and nYoled n Cicket fom Hosat 'AB'. gracda
ABove data acceniy is vey
difhut in Rle sty sleme ot eosy ia
ncolh.

9n file syslem we neod


6ile tocalien.
DBMs need to
No

Con (uny cdcnlaye in DeM S.


Secuily ’ DBMS þide s
Secwilg
Role based peA m) ss] ern
Accen conr. prohocols DBMs.
A| Jhe in fo. uoj 20 not be isible in
Rile sy slam handed by ufich doen not
Proide cny secuikg.
A file basecd Sy slem is a ty pe ot softwqre Jhat
Sumnagy
allo usens to Qcce SS and ovgari3e Smal 90up of data

9 is wnually integYaed into Compuleis 0s and Terpomube foy


and Tehies Gles sBorage meium
sonng digitad Vension ol paper bauad ( imy yem
File sysk
What are Data Models in DBMS?

Data models in DBMS help to understand the design at the conceptual, physical, and logical levels as it provides a clear
picture of the data making it easier for developers to create a physical database.

Data models are used to describe how the data is stored, accessed, and updated in a DBMS. A set of symbols and text
is used to represent them so that all the members of an organization can understand how the data is organized. It
provides a set of conceptual tools that are vastly used to represent the description of data.

Types of Data Models in DBMS

(a) Hierarchical Model

The hierarchical data model is one of the oldest data models, developed in the 1950s by IBM. In this data model, the
data is organized in a hierarchical tree-like structure. This data model can be easily visualized because each record in
DBMS has one parent and many children (possibly 0) as shown in the image given below.

(b) Network Model

A network model is nothing but a generalization of the hierarchical data model as this data model allows many to many
relationships therefore in this model a record can also have more than one parent.

The network model in DBMS can be represented as a graph and hence it replaces the hierarchical tree with a graph in
which object types are the nodes and relationships are the edges.
(c) Entity-Relationship Model (ER Model)

An Entity-Relationship model is a high-level data model that describes the structure of the database in a pictorial form
which is known as ER-diagram. In simple words, an ER diagram is used to represent logical structure of the database
easily.

ER model develops a conceptual view of the data hence it can be used as a blueprint to implement the database in the
future.

Developers can easily understand the system just by looking at ER diagram. Let's first have a look at the components
of an ER diagram.

Entity - Anything that has an independent existence about which we collect the data. To learn more about Entity in
DBMS click here.

They are represented as rectangles in the ER diagram. For example - Car, house, employee.

Entity Set - A set of the same type of entities is known as an entity set. For example - Set of students studying in a
college.

Attributes - Properties that define entities are called attributes. They are represented by an ellipse shape.

Relationships - A relationship in DBMS is used to describe the association between entities. They are represented as
diamond or rhombus shapes in the ER diagram.

In the above-represented ER diagram, we have two entities that are Employee and Company, and the relationship
among them. Also, in the above-represented ER diagram, we can see that both the employee and company have some
attributes and the relationship is of "works in" type, which means the employee works in a company.
(d) Relational Model

This is the most widely accepted data model. In this model, the database is represented as a collection of relations in
the form of rows and columns of a two-dimensional table. Each row is known as a tuple (a tuple contains all the data
for an individual record) while each column represents an attribute. For example -

The above table shows a relation "STUDENT" with attributes such as Stu. Id, Name, and Branch which consists of 4
records or tuples.

(e) Object-Oriented Data model

As suggested by its name, the object-oriented data model is a combination of object-oriented programming and
relational data model. In this data model, the data and their relationship are represented in a single structure which
is known as an object.

Since data is stored as objects we can easily store audio, video, images, etc in the database which was very difficult
and inconvenient to do in the relational model. As shown in the image below two objects are connected with each
other through links.

In the above image, we have two objects that are Employee and Department in which all the data is contained in a
single unit (object). They are linked with each other as they share a common attribute i.e. department_id
(f) Object Relational Data Model

Again as suggested by its name, the object-relational data model is an integration of the object-oriented model and
the relational model. Since it inherits properties from both of the models it supports objects, classes, etc like object-
oriented models, and tabular structures like the relational model.
Schona.
o6 Coect
aSeloct Comnicar
olaa
aCCos fer
tool
hendy Dhis
intenaci'
on pla
the
oncoos
opt clone d'Yectly
Con DBs
need
we for pialtesm
example
DBMS
wjh be ony
A (maion) infoahon
to uned
DBMS clisecty lnguoye
Usen Cen Fr ’
tontmanagement.
.claba,
impor Jawa
languaye
cny
(in
Conci
the on auchiechye&
de.
of Databne qpplicai Aexpcundimacine
client
any for
Data to oiee cloest
ibel,
94
local JDBeCinrochi
Arehieie it
Cihical available.
he91e for
DBMS/ a9chitechuve
Arei
techm o Seswer ne.
dalab
Java
is Av
ajsechve e dovelomeat Senu
en(client- ODBC1
trekilec done. se i
DBMS dotcba
og ctiyecHy for Ofhce
Ms
eq. Lwe
Can
use
ce fAient Jhe
3Tie Oot Hen Any
changes Suilabla dclaloou onlyWe
veVS far open
to
a DBMS|tie1
- her darabana aychitecwe
Syslemcho ^ecuvely. ie Dalabone
aachilecve
2Ties
ano inmducicn le store NO-
wed applicahong
todays AP's
for 2
3
ODBC
File
dalabse Same
-’ San and
quicuy Types
aMchilechYe
(a)
1-
tie
Lec-I -a
lec
Ly
Lot
w A
(0) 2)
Seswes
Serven
Sowe
aComecie cient Cnd
Cient
SeweN
oih
Senven Clieat
utich
rovlhen
cemuicat
cala
cat teracli
Comeni
esryishon Deskto
papplicaiony atni
|Applitaion in 1Appl
SeveN
S
DBM Dalaba Use
USe loyen end
no
hen web
clive
cty
aicaon ent
cli
lape
Can
h
side.
ey
ampleg
’ 3-
Tien
Arclilecue aken for
on
Applic
clien
Conlai
Seyen used
chent
L
L
L
enG colvefi.
velayonl
in
dalclane Canephod
Schene, stchne
clala
Ohone
uhia
Sysle
m dechni
dala ancd
name
of orgomized objec inced
held
o
vepvenonlei oG
pant to schema typically
Cyel
Snvolved.
dalabou
Schem
Schema
be Compan
teguivemo
projeck
ARCHITECTU
RE Schome dotonengm
Conshci
tubte Synax
luds
inc
logicad co
not
Cogical
databan ure Cne
Less
clean,
cbstact
aban
pic houwbu'snen
ruler
inkpiy
dal Ihey
DBMS physicad big wwually
iniil JheySueh
SchemaConcepul Cisntin
offers
phys'cal:
MonuE-9 y
Ls Conaphal Cogicad
Concept
(a)
Lec-3
Lec-4’ Lec-2 Lec
Schemna ’
for
Extenal
schema
aMchiechures D3MS
hhat is
ConcoptDBMS File
Quwshion
Aie Sys
Stou
chye ok lem
table
Slore Schema Vs
ue 20 Houo CEPTUAL
CoN
PHYsICAL tencQ Ex DBMS
soye SCHEMA
ScHEMA cro
table
Jhen Jha dhe
iim-acjn.
Anit Schema Lec-y
d wtich Jhyee
data data
above
(ouel
Cin yn
clale
(Etupkat,
çomaion) ER schona
o Ralaliaad Extesna
Can
in Schemos
Amozon, stuce anchece.
tables, whc cismbuta
Conwoli3el
con ke be. .

Pad
is s
tove CPhysiSntesnal
cleau)ue) togicadCaue
schema
Jhen Jhe Qm
ele:) in level)
yied
struchye to
Usig
Y)
6
to
lo
isinkomain
Lha acce
Cant
inteact
skoved ciff. uew
dat
isfer is lno)
do Afendonce (
indepencone
data
and
Usen ca
fenont Wedile.Schema
diyecHy vieos.
mls poic,
(ees
Ahoyh Cevel pasuoord Use
ale
for c
he
Mol
peon
on
sn
manu
physicoll, per exten
vole
Don 2e ot
Jhe w
data View
ord View
(for it
fomm uthee om: manls Shudet
foViecs yne
(heu to
or dau ys login
fepyesent
icd
(acug
Saefor cifforuntTfaculg login sJhat
is
the
Use)
utich mana. Unedin
pafe
knoe schoma kils Role
Selec
avels 9n stoved
is Shou.
toHo0 A shown is
evel
Jhvec Sloved, F8 shudent
coñ GnmaiL
f.
Unive1sil new
Jis
But
made wtonee
Extenal vieuhuder
S we
See
USen
is Take
when
we
No
#Why e
2 solaianhip
a /shems call, lo (reymen.
mauy
telaionlp. tieh Cie)
schema
Extenal
physi
fiw
Concenheel
viesschoma mods
fere to schoma
Physicod
alh
enhien
bu be Rolaicnal is data,dise,chjie le
DBMS)
(Cayen
bluepink daba eh cMow schema
Concephol
in
Tables istorad
ele
). INRo
Jhe decid,
Dnd
ondl
Schoma
ER
,Age. dale
stoyod
isdata male
atmin
Dabon
lelahonal
Moclel dala ia
DB’
Achl
Concopheal
schorna Roll
no)
Moclol o6 schoma inten
(au Admin
palabo
doisner
Bavah
an
deignen
Usen
See
exampe
dabab
an
HowSudont
Wehue
to ER cal bu
physi
she
So :NOTE
e. *
3
DBMS Architecture
• The DBMS design depends upon its architecture. So, DBMS architecture depends upon how users can connect
to the database to meet their requirements.
• The architecture of a database management system plays an important role in determining the actual design and
layout of the database
• To understand the DBMS architecture, you must have a clear idea about the client and server. The client is the
user requesting service, in this case, access to the data stored in the database. The server side is the side that
answers the request of the client.

• The architecture can be divided into the following three


categories based on the layers between the server and client
layer.
(a)1 tier Architecture
(b) 2 tier Architecture
(c) 3 tier Architecture
1-Tier Architecture
•1-tier architecture is a simplest architecture where the Client, Server, and Database all reside on the same
machine. So, anytime you install a database in your machine and access it through SQL queries. Therefore, This
type of architecture is an example of 1-tier architecture.

•The user directly interacts with the database itself, which means that it is accessible to the user to create, alter or
delete the data

•In simple words, in 1-tier architecture, the user can directly sit on the DBMS and uses it.

•1-tier architecture is rarely used in production. It is used where the quick response is required. For example,
development of the local application

• The user directly sits on the database, and there is no layer between
the user and the database. Therefore, there is no data abstraction; the
whole data is available. There is no interactive user interface.

Data Abstraction is a process of hiding unwanted or irrelevant details


from the end user. It provides a different view and helps in achieving data
independence which is used to enhance the security of data.
2-Tier Architecture
•In the two-tier architecture, applications on the client side(i.e. PC,
Mobile, Tablet, etc.) can directly communicate with the database (server
side).
•User interfaces (API’s like: ODBC, JDBC) and application programs
are run on the client-side, because to establish a connection with server

•The database server is responsible for query processing


and transaction management.

ODBC:

JDBC:

Real Life Example


When any person Go to bank or railway station. And Fill a manual application form for ticket reservation or bank
transaction. These forms are given to some operators. Operators are using client’s machines behind the window.
Then client’s machines access the database to verify details. So, this is example of 2-tier architecture.
2-Tier Architecture
Advantages of 2-Tier architecture
•It is simple and easy to use and maintain because it has limited or authorized clients.

Disadvantages of 2-Tier architecture

•But problem with this architecture is scalability. Scalability means when the number of users increased then two-
tier architecture does not work properly.

•Security is other main problem because It does not allow the role base access. It means author can work as
administrator because every client has direct and similar access to database.

•Traffic load on database server is high because it first processes the query and then provides the required data
as well.

Example of 2-TIER AND 3 TIER ARCHITECTURE: Ticket counter and IRCTC , Bank counter and online banking
3-Tier Architecture
•In 3-tier architecture, client cannot directly communicate with the database server. It contains another layer
(application layer) between the client and server.

•The user on the client-end interacts with an application server (also called business layer) which further
communicates with the database system.

•End user has no idea about database and database also has no idea about any end user. The 3-Tier architecture
mostly use in web application.

Advantages of 3-tier architecture

•High security because of role base


architecture.

•Highly flexibility (scalability)

Disadvantages of 3-tier architecture

•Tough to maintain as compare to 2-tier


architecture
3-Tier Architecture
• In this architecture, the user connects through the user application, and that user application interacts with the
application server that communicates with the databases.

• This provides ample layer to abstract the data.

• Any modification in the data done by the user does not directly affect the database itself. The changes are first
performed on the application layer. There is no real connection between the database and the user.

• The query processing and other functionalities of the database management system are performed at the server-
side application.

• It allows the DBA to manage the access of the various users. It also enables concurrent transactions on the
database.
3-Schema Architecture
The three schema architecture divides the database into three-level to create a separation between the physical
database and the user application. In simple words, this architecture hides the details of physical storage from the
user. The database administrator (DBA) should be able to change the structure of database storage without affecting
the user’s view.

This architecture contains three layers or levels of the database management system:

• External level
• Conceptual level
• Internal level

Three schema architecture hides the details of DB from the user. It’s other name is three Level of Abstraction.
The database administrator should be able to change the structure of database as according to need, without
affecting the user’s view. This effective three schema architecture holds 3-layers as below

1.External level (front end developer, user level)


2.Conceptual level (database designer, logical level)
3.Internal level (administrator, physical level)
3-Tier Architecture

1. External or View level


•This is the highest level of database abstraction.

•External or view level tells the actual view of data that is relevant to the particular user.

•View/External level provides different views of the same DB for a specific user or a group of users. For example
view for faculty student is different than faculty admin.

•External level develops with the help of front end programming (Javascript, HTML etc)

•An external view provides a powerful and flexible security by hiding some information of the database from a
particular user.
3-Tier Architecture
2. Conceptual or Logical level
•The logical/conceptual level tells the structure of the entire database.

•Conceptual level acts as a intermediate layer between the physical storage(DB) and external level.

•Database designer works on this layer which provides the structure of database.

•Database any model (i.e. Relational or ER Model) can use at this level which provides the structure of database.

3. Internal or Physical level


•This is the lowest level of database abstraction.
•Database administrator works on this layer where it has complete control over data
•It describes how the physical data is actually stored (in the form of file) in the database and provides methods to
access data from the database.
•It shows the physical representation of the database. As it exists actual on the computer system.
•It means that the changes in physical database storage devices (i.e. hard disks) and the files organization on
database storage devices, are hidden to application programs and users.
3-Tier Architecture
As we know Basic purpose of 3-level schema is to achieve the goal of, data
Independence. Data independence means, independent the data from user.
Therefore, It follows the 3-level of abstraction (3-schema architecture).

Types of Data Independence


There are two basic types of data independence, As explain below
1. Logical Data Independence
•Logical data independence separates the external level from the
logical/conceptual level.
•If any change is occur at conceptual schema then it will not affect the user
view.

2. Physical Data Independence


Physical data independence separates the physical level (internal) from the
conceptual view.
In the same way, if any change is require in physical schema then it will not
affect the conceptual schema.

i.e Gmail makes changes in conceptual and physical schema at regular basis without changing the user view.
Schema and Instance

•The collection of information stored in the database at a particular moment of time is called database
instance.
•The overall design or structure of the database is called database Schema

Types of Schema
The different types of schemas are as follows −
•Physical schema − It is a database design at the physical level.It is hidden below the logical schema and can be
changed easily without affecting the application programs.
•Logical schema − It is a database design at the logical level. Programmers construct applications using logical
schema.
•External − It is schema at view level. It is the highest level of a schema which defines the views for end users.
Schema and Instance
Database Languages
Database Languages
Database Languages
Database Key Features
Database Key Features
lopic: ER (Enkky- Relakonship) Tiagaam
the research pape)
. ntodu ced by Dr. Petey chen in l976 (You Can check

descibe, the Strcre Ok


2. An (ER Mode!)
Enhly - Relahonship modet Knouon o ER- diqgram
dakabase wth the help Of dagram
doabase Jhat Can late be mplermented as
9% is a blueprint o
a database
a daab ese
fich
. 9t is basically diagram nahc depsesenlahsn
non- techmical
eony to undestand even by

Let us che ck one examplel


Fnane
Ron no. S-nane
Tid

Teache Teache) Student

Dog Couvse Phorc no

Can you lndes tand the logie?


. An ER diagrim Con
sists f
: enity (eniy set)
: Aibute
(Relahonhip set)
Relahons hip
one by ne .
Let w undentnd above componenk Jhat is
object in Jhe
an
An enihy
Enihy based Jhe valwo o6
ble
diskinguishat from othei objecks
athibute Cpropenhen) þassevs.
Jhe
back Ba) maiken pen
we hqve. Jhree (Gy an not
mauke ane object; but
not entiy becoune Jhey
L Jhvee
baned on any propenty (Company Colouy, pe)
be idonihed.
ure hqye. Jhvee blacu, bluu, Yed) manken pen.
L Nous SuppoSe it Can be ideniied
eniy be Cawne
gn Jhis Case maiker s
boned qhibut ( CotbuY).
Non tangible exíst in

Tangble Teal w OTld ).


(physically exisk in Account
Teal orld )
Pen, Bank locKey:
enhhen
Collechon of Same ty pe of
Now let w unde1sand enihy set !

( inglana/dat
ER diagsam ag it is
Can not be tepresented
in an
Enhy in ER diagrOn
Enkhy set is vepesented by ectangla
Relahonal Model
Enky ah be eprerented by ow/ uple.in Yelahonal modol
( Enky Set s Tepveenhed by table
Studenbt
Rollas Name Age.

one enil
Roll No
Nae
18
anohen enil 3
Student
S
his is an enht Set
´Set of all 20
enikes is 18 dont
Cauted enity set ER Mocle', we
Shudent able is an eniy set. Inset cak only Visucl
epyenenkaho. (iogcal schema)
enhy Can net be yepvenentad inn
ER diagvam
Types of enhy set
.enhy
Weak enhy
Let w
mas und ond Jhe Secomd omporo ot ER madal
(b) Athi buteg Athibuten in Qn ER diagram is Jhat Componenb
Jhat descibe Jhe chavacerisie, enhie,.
ER diagra m Athibutes ane Tepye sented an ellipse ot oval shape
Sn elahonal mod e!, AHibui Yepvenenlad Sepavat Columng.
for each eniy we dyaw a table
a elqhonad modol.
fov each atmbub we cdd exha Column

Shudenk
phone nt
(Roll NO D.0. B
(f-name
ame Studen t
(m-nan

(Age Tkoll Phrd mulivqluod

Types os Atributey :
Simple nd Composite Atibulin
Simple Cannot ke diided Guyhe
sepresented by Gimpl 0va shape
C omposite atibuli Can be divjded GUyhen in
reptenenlad by Oval Connecto to nothno o¯a. Simple atibute.
Simple Roll NO.
ComposileeBe 9 Name, Addve.
9n velaioncu mode! Corposi le. ahbur epyencnsed an Separaa o lumng
) and
single ’ Cqn Muilivalued AHnbue
haue ’ can have mote
Dny one Value
Jhan ona value.

Muihvalued Ahibu is ere Sente d an ER Moclel, Sn


Relqhono model mulhvaued albut Ce
Tepy in dfenen toble.
) Stored ard douved AHibut
Oish. emain. Cdesnat - une poß
D.o"8
.'. Dist is an dani ved alnble

KEy ATTRI3UTE -’ dhe athibute wthich uniquoly idenhhe each


enhy in
dhe enhy set is Called Key athñbure denoleol by Roll wo
nouw undenstan@ Jhe dhrd Comþoon
in an ER
dtagam.
'Retalionhip'
* Relakonship is assocaahon behweon too oy more enhhe
Same or dienent enilg set
enhy set Gelakonship set
> eniy set
|Teachen teache Student Shudont mang shudent
.reiahotip

enhhy
S
T Sg

9enty sek enily sek


Kelaionship set Set
similan type of elaionip
y gn ER diagram Relaionohi p st is ep vesenhed using dianond hap

L Sn Telahonel odel Relahonship set is Tepvenenbed e hen by


Sepavake tabla by Sepavat Column C foreyn Kay)

Every Telabonship type has thvee Componon


L Name

Degree
L Candialiy
3

Dagree a oelahonship : Numben Of enhhy set anociaed in

the Tela konship Set

L Unany tela konship ’ ohen Jhete. is only one enhhy Set


selahon, the delahnship is Called a
paniipahng
uny elahonship
|employea Enployec
* tuo ways oG Tepresenhy unay relaionhip

Ly Binaly velakormhip ’ when Jhete two enhhy et


pavihipaing in a Telakonship is Callod biy elaionhip

student Cou re

y secnd eniy set.


’ htst enhly set
L n-ayoelahonship : when here enhhey seb
Callad
panlicipaking in setahon, dhe e laionshp
an -any reiakonhip.
Tennay elahonhip.

Quateinauy
CAROINALITIGS Jhe mumbeg O6 ime an enhhy ot an eniy Set

panhcipae, a. telohonship set Knocon ay Candinatia


candinatiy Can be o6 difernt types.
Can bake
(ne-to- One : when each enily in each enhy Set
Once /n Jhe relahmship Jhe Candinalit
Pat only
One- o- one..
let assume that male Can mauy 0ne female
Can nay one male So Jhe Telahonip
and a female
to One.
will be One.

1 1 feale
male maried
to

Can e Yeprerened an
using Sets )

A B

À2

One- to - many: Uhe- to- many mapping -a9 well ukheao


Can be Te lae to mOYe
Qach enhhy in an enhy Set
Jhorr One ve lahonship
Seienhst Can 'nvent mony invenhong but Jhe in venhern is

done by mly Specil'c senhsl

M
Sjenist Kinee

Av
Many-to-one !
when enkhes in one
enthy Set Can ta ke
part only onCe Sn the Telahonshi'p Set and nhhe in
othey enhy Set Can take pant more Jhon on Ce in Jha

Yelah onhp Bet candinatiy is many to One.


let Jhat Sudent Can take on ly one CouYse
eg. qssumne

but One. CourSe Can be taken by many Studens

M
Student

sets Can
be represertad by
B

A
A
2 B2
A :

Au

al enhy Sets Can take


Many - to Many when enhhe in

Jhon Jha reiahonship . Candinaliy


paut
many to Many

Em ployec - Can aipn by nany prjecls vd þrojec


have many en ployee
M
Employe
M
piny sels: B

A2 2
A3
A4
* ParhodpaHon Constyaint
Specities whealhen the exislen ce o an enty depend,
elated to anothei enhy uia a Delahonship ype.
being and maximu m
Ly Jhis minimum
Conshaint Specity dha each enky must/Can
umben of telahons hip io tan os Jhat
panhipate

Project Enplose.
many relahonhip
Jhi's Conshaint Spec (be o how uek
Sn Simply Language exiStena in
inolan enhy mwt hawe max,
database. Jhe enhhy may have
Can ACWe.
'mik of Teloenship it

Max eandnallg Max. mo. of Hme, an enhly pasclpaing in ape


elatons ip.
Min Codi nallg Min 0. Hnes an
enily panhipals
relaw onhi P
Smjn

M Employea
|Projeck (o,22
(3 smaX

Ey

tae 4 Inter
eg. Real life Supenssa Can

Dre Suden hao to shudy onuy 5 Couv in One sem.

Coohains. Cat be ayied by


Jhis type
Candinalia vaio. Panhal pavh.
Too ype, ot panhcipahen Total paali -denolei
Yelaiontip
otype an
Can alilen
Did
each One-ne
o hon
oi E-d
Loe Munh
ApraHDelli Koy woYy.
associabed beyonhnont
Pepaushne
Nam as jha
Con
D. to vepealed ma
accovciny
any
pin
D.3d Taole
V3
Dy Koy
primay
can
1
be you e
tab asE-id
sand 3
Dajd.
Ks
wor
f% D-i
E-id D2
D3
Canh Erngloyet-id.Norne (relalonb
table
Woves
enihes Wuyks table velaiodip
E3 E2 Ey
repeaAew
oho
No
Jhe
two m take
pomay
Koy.
how |M- M
M- put eTab
G.ia
E.Nan
Age Table be
2 22
22 many
E
mployee be |-

Empbyea wie
Relakonship C
nSo How
"Ty
pea E3 whas
bata
ahsut
Udenan
Cost Gved
Cidlnam.
-n0. kay.
pimag
deCost
6-n hawe
we
2o0
3sivt
alo Lo
shocy
2 elahonwp. Couvse PK
Can rdens
VelakonNp yprimas
is ,C-ld-fu
fuRal melahionip
M ey.
iCompos
C C2 Cz
x M Date Shdy
oMany
p! 2 2
]0-r0
Date
relakanhiphive TD
2 table relancnhi Mony t
of
Give
1 ang
m
pi explanahon
Many
Shudet to Combinahon
many
Deli inKoy
primay
Many Mum
Customer Cus
omen Roll
name
Ip to
B Jhose
One
to Same
Moy
name
2
est, follooing Stes ane
followed for an ER Mode! rom problom
statement
9denkby Jhe pnhly Set
2) Sdonhky Jhe levant
elev ant athibutea.
3) Sdonity Jhe prime athibua
4) find oelakonships b/ eniy Set
S) Draw comple EA Mocol..

Pooblem Stalement-l. Draw an ER Modol tor an nensil daabau


a cahon ushee
my dopanment
@ A nivensiy han mny
Each depanhrent han nulhple ivgucto One amony
)
thom is he head Jhe dopanhment
An Instuctor belongs to only dapasentb
Each depanhnent fos mlhple Courses,each ot
wshich taught, by a Sing le inohcta.
-A studentr may enll fa Mony Couvses

lfeed by dit depolrord


Step-1: We Can
jdenify folluon; eniy set
L dapanhnont
Inohvctar
Couvse
Ly shudon t

t* Vnivensiy fs not an enhy set

step Sdanhy Jhe relevont ahibuteg


Depannert (D_noy D narme locabon )
Lourse C_Name, Durahen, pve-neput)
I. Nama Ruom No, Mob. )
ghudort
(Roil No, S nome S_ enil, Dob)
Step-3:
Depanmeat
C- No.
Couvse.
Insheco I. No.

sudot
Roll No,

step- 4: M 9nshnch
from Depavnon hw
from depart to tnomeel
3h is 1 to Many Yelahowip
*
fom JDepaanod
haodad 9nstucta
by

M M Cowrse.

DeFavhru!
M Cour
fom ) Snstect by

M M Cows
fom shucent enToll
Nouw
Jhe Complet ER diagm
nae

D_ NO Cocai

Deportrou heal

Co No
Iname
name han

(Oural Couv 9nshuct Room no

DoB
Pie-vepuisb
shuden
S-emei
Roll No S.name
DoB.
ER Model notes from internet source

Entity Relationship Diagram – ER Diagram in DBMS

An Entity–relationship model (ER model) describes the structure of a database with the help
of a diagram, which is known as Entity Relationship Diagram (ER Diagram). An ER model
is a design or blueprint of a database that can later be implemented as a database. The main
components of E-R model are: entity set and relationship set.

What is an Entity Relationship Diagram (ER Diagram)?

An ER diagram shows the relationship among entity sets. An entity set is a group of similar
entities and these entities can have attributes. In terms of DBMS, an entity is a table or attribute
of a table in database, so by showing relationship among tables and their attributes, ER diagram
shows the complete logical structure of a database. Lets have a look at a simple ER diagram to
understand this concept.

Facts about ER Diagram Model:


ER model allows you to draw Database Design
It is an easy to use graphical tool for modeling data
Widely used in Database Design
It is a GUI representation of the logical structure of a Database
It helps you to identifies the entities which exist in a system and the relationships between those
entities

Why use ER Diagrams?

Here, are prime reasons for using the ER Diagram


Helps you to define terms related to entity relationship modeling
Provide a preview of how all your tables should connect, what fields are going to be on each
table
Helps to describe entities, attributes, relationships
ER diagrams are translatable into relational tables which allows you to build databases quickly
ER diagrams can be used by database designers as a blueprint for implementing data in specific
software applications

A simple ER Diagram:

In the following diagram we have two entities Student and College and their relationship. The
relationship between Student and College is many to one as a college can have many students
however a student cannot study in multiple colleges at the same time. Student entity has
attributes such as Stu_Id, Stu_Name & Stu_Addr and College entity has attributes such as
Col_ID & Col_Name.
Here are the geometric shapes and their meaning in an E-R Diagram. We will discuss these
terms in detail in the next section (Components of a ER Diagram) of this guide so don’t worry
too much about these terms now, just go through them once.

Rectangle: Represents Entity sets.


Ellipses: Attributes
Diamonds: Relationship Set
Lines: They link attributes to Entity Sets and Entity sets to Relationship Set
Double Ellipses: Multivalued Attributes
Dashed Ellipses: Derived Attributes
Double Rectangles: Weak Entity Sets
Double Lines: Total participation of an entity in a relationship set

Components of a ER Diagram
As shown in the above diagram, an ER diagram has three main components:
1. Entity
2. Attribute
3. Relationship

1. Entity

An entity is an object or component of data. An entity is represented as rectangle in an ER


diagram.
For example: In the following ER diagram we have two entities Student and College and these
two entities have many to one relationship as many students study in a single college. We will
read more about relationships later, for now focus on entities.

Weak Entity:

An entity that cannot be uniquely identified by its own attributes and relies on the relationship
with other entity is called weak entity. The weak entity is represented by a double rectangle.
For example – a bank account cannot be uniquely identified without knowing the bank to which
the account belongs, so bank account is a weak entity.

Weak Entities

A weak entity is a type of entity which doesn't have its key attribute. It can be identified
uniquely by considering the primary key of another entity. For that, weak entity sets need to
have participation.
In above example, "Trans No" is a discriminator within a group of transactions in an ATM.Let's
learn more about a weak entity by comparing it with a Strong Entity

Strong Entity Set Weak Entity Set

Strong entity set always has a primary key. It does not have enough attributes to build a
primary key.

It is represented by a rectangle symbol. It is represented by a double rectangle


symbol.

It contains a Primary key represented by the It contains a Partial Key which is represented
underline symbol. by a dashed underline symbol.

The member of a strong entity set is called The member of a weak entity set called as a
as dominant entity set. subordinate entity set.

Primary Key is one of its attributes which In a weak entity set, it is a combination of
helps to identify its member. primary key and partial key of the strong
entity set.

In the ER diagram the relationship between The relationship between one strong and a
two strong entity set shown by using a weak entity set shown by using the double
diamond symbol. diamond symbol.

The connecting line of the strong entity set The line connecting the weak entity set for
with the relationship is single. identifying relationship is double.

2. Attribute
An attribute describes the property of an entity. An attribute is represented as Oval in an ER
diagram. There are four types of attributes:
1. Key attribute
2. Composite attribute
3. Multivalued attribute
4. Derived attribute
1. Key attribute:

A key attribute can uniquely identify an entity from an entity set. For example, student roll
number can uniquely identify a student from a set of students. Key attribute is represented by
oval same as other attributes however the text of key attribute is underlined.

2. Composite attribute: An attribute that is a combination of other attributes is known as


composite attribute. For example, In student entity, the student address is a composite attribute
as an address is composed of other attributes such as pin code, state, country.

3. Multivalued attribute:

An attribute that can hold multiple values is known as multivalued attribute. It is represented
with double ovals in an ER Diagram. For example – A person can have more than one phone
numbers so the phone number attribute is multivalued.

4. Derived attribute:

A derived attribute is one whose value is dynamic and derived from another attribute. It is
represented by dashed oval in an ER Diagram. For example – Person age is a derived attribute
as it changes over time and can be derived from another attribute (Date of birth).
E-R diagram with multivalued and derived attributes:

3. Relationship

Cardinality: Defines the numerical attributes of the relationship between two entities or entity
sets.

A relationship is represented by diamond shape in ER diagram, it shows the relationship among


entities. There are four types of cardinal relationships:
1. One to One
2. One to Many
3. Many to One
4. Many to Many

1. One to One Relationship

When a single instance of an entity is associated with a single instance of another entity then it
is called one to one relationship. For example, a person has only one passport and a passport is
given to one person.

2. One to Many Relationship

When a single instance of an entity is associated with more than one instances of another entity
then it is called one to many relationship. For example – a customer can place many orders but
a order cannot be placed by many customers.
3. Many to One Relationship

When more than one instances of an entity is associated with a single instance of another entity
then it is called many to one relationship. For example – many students can study in a single
college but a student cannot study in many colleges at the same time.

4. Many to Many Relationship

When more than one instances of an entity is associated with more than one instances of another
entity then it is called many to many relationship. For example, a can be assigned to many
projects and a project can be assigned to many students.

Total Participation of an Entity set

A Total participation of an entity set represents that each entity in entity set must have at least
one relationship in a relationship set. For example: In the below diagram each college must
have at-least one associated Student.
Steps to Create an ERD (E-R Digram)
Following are the steps to create an ERD.

Let's study them with an example:


In a university, a Student enrolls in Courses. A student must be assigned to at least one or more
Courses. Each course is taught by a single Professor. To maintain instruction quality, a
Professor can deliver only one course
Step 1) Entity Identification
We have three entities
 Student
 Course
 Professor

Step 2) Relationship Identification


We have the following two relationships
 The student is assigned a course
 Professor delivers a course

Step 3) Cardinality Identification


For them problem statement we know that,
 A student can be assigned multiple courses
 A Professor can deliver only one course

Step 4) Identify Attributes


You need to study the files, forms, reports, data currently maintained by the organization to
identify attributes. You can also conduct interviews with various stakeholders to identify
entities. Initially, it's important to identify the attributes without mapping them to a particular
entity.
Once, you have a list of Attributes, you need to map them to the identified entities. Ensure an
attribute is to be paired with exactly one entity. If you think an attribute should belong to more
than one entity, use a modifier to make it unique.
Once the mapping is done, identify the primary Keys. If a unique key is not readily available,
create one.

Entity Primary Key Attribute

Student Student_ID StudentName

Professor Employee_ID ProfessorName

Course Course_ID CourseName


For Course Entity, attributes could be Duration, Credits, Assignments, etc. For the sake of ease
we have considered just one attribute.
Step 5) Create the ERD
A more modern representation of ERD Diagram

Best Practices for Developing Effective ER Diagrams


 Eliminate any redundant entities or relationships
 You need to make sure that all your entities and relationships are properly labeled
 There may be various valid approaches to an ER diagram. You need to make sure that
the ER diagram supports all the data you need to store
 You should assure that each entity only appears a single time in the ER diagram
 Name every relationship, entity, and attribute are represented on your diagram
 Never connect relationships to each other
 You should use colors to highlight important portions of the ER diagram
Summary
 The ER model is a high-level data model diagram
 ER diagrams are a visual tool which is helpful to represent the ER model
 Entity relationship diagram displays the relationships of entity set stored in a database
 ER diagrams help you to define terms related to entity relationship modeling
 ER model is based on three basic concepts: Entities, Attributes & Relationships
 An entity can be place, person, object, event or a concept, which stores data in the
database
 Relationship is nothing but an association among two or more entities
 A weak entity is a type of entity which doesn't have its key attribute
 It is a single-valued property of either an entity-type or a relationship-type
 It helps you to defines the numerical attributes of the relationship between two entities
or entity sets
 ER- Diagram is a visual representation of data that describe how data is related to each
other
 While Drawing ER diagram you need to make sure all your entities and relationships
are properly labeled.

DBMS Generalization
Generalization is a process in which the common attributes of more than one entities form a
new entity. This newly formed entity is called generalized entity.
Generalization Example
Lets say we have two entities Student and Teacher.
Attributes of Entity Student are: Name, Address & Grade
Attributes of Entity Teacher are: Name, Address & Salary

The ER diagram before generalization looks like this:

These two entities have two common attributes: Name and Address, we can make a generalized
entity with these common attributes. Lets have a look at the ER model after generalization.
The ER diagram after generalization:
O1

Lec o6 Keys n DOMS

athibute o set of atibules


Meys uniquelyleniy any aow (record)
tables.
06 table

elahonship behueon two differonE


establis hing
wl be used in funchond dopendonc 4 Nomaligahon
will Sudy in nexk chaphes
STUDENNT TABIE
RoN NO Name Phone mo. Age city
AJay 1234S 6780 21 Agra
02 Bobby 98315 61234 19 Mawra
03 Kiara Agro
Rahul Delhi
OS
Pooja ao Mumbai
o6 Ajay 19 Bungalove
Ra Ke sh aucalloY

Attributes Roll No. Name phone mo. Age city


Ned o Key n DeMS
LLet us dfscuss difterent dype o Keys:

Employee Table
ID No. Name Adhan no saly phene email Ahibue

ASupen Key
denh6ty Jhe tuple (athhbule orT sek-o( aribuka, )
Uniquely oho deucb)
tilo Super se C fom uhe Keys onu

9t Can acopt Nu values

iv) Nome 3 is not a Supen Key


Addhon no.3
ÀID, Adan mo.3
1 , Adhan no.2 I D Name
Nome, phone , Name,ennoL
exanpba
examploo 1D, phone , 'D, email
Nome, Adhon no, phone9
Name Can ldenhy unique ows

Can icdonhty Lniq OS Supen Key.


Name + emoiL
Candidae Key
Minimal Supe
Supen Keys ae Colled Candida Keys
Adha no.
xID, Name Togehe boh achng an Supen Key but
but we Cant take ib a Candidatb Key becouun
Jhere îs an amnu& 11) stWh is alreod a Conddals
Key
X1D, Adha Not a Cadidat Key
key
tuwo altibuh
Censitut Condidal Koy
Name, phone ne.7 Candidat Koy possibla i

x Name Adhas na, emoil Nok a Ccandidat


ey
9 6 may alse Conlcin NULL value.
NOTE
Supen
Supen Key Can Conlin Tedundank atinule
Candidat Key No edundon- a i u l e
A cardidab Key ane &pen Keys bu
2) Key
A Supen Keys mok Concidab Keys.

Primany Key
1 Now we hove fo llouain 9 Cand'ddat Key s

D Adhan no Na me, phono no emoi l


Cvi teuia> UNIQUE NO NULL VALVES

Primany Key ID
AlOTE
Jhe WILQ be only One Pri mang key in a. table
DBA hauwe to
L |chose Cave(ully| pimay Keys om
set 06 Cardudat Keys
Neven oY
Vexy arely changeo
L Candi' dat
eys wi h NUL Value
Keys NOb a

Pnmay Key.
ALTER NATE KEYS: 4
9n n he Se o Candidat Keys hawe choSen
One Key aD pmmay ey cund e t Candidals Koygs
wi be Coulled alkeinau keys
Supn
Caidal

Prima alternat Loy

L Adhon na Nam phum. n:


emall3
Ohen
Keys for Sel
Keys nouoleolge uniquo Kuy, Composile Key ey
Candi da ey s

Roll No.eis. No. Name Fahen Nam ma

Pimong clteanali Koy


Ley
cho sen
Lec-o4
eign Key and
Tegyenenkal integig
roseign Key
St deals wi% two 0 mote table in a dalabase

establishe Selahon.ship blo tablen ie Gnko Columo 06


one tablo to
anoher
Concept oG Sefeonhad integm
Conp obereisn Key
USERS
usen id Name
oRDERS Books
emai ordon no. wen id Proclucld-id Poddd He
lo Sadio
Prica
s 3 I 123 23
Mchamaeme 7-89 4S6
12 Rin sola e
3 489 48
13 Amalie Ae 6 Lo

Primony PrimaA)
oy Prony

Foveign Key
NOTE: ORDERS Table is taking
i)Jhe usen id a Hibut oG
anoho table.
6eenona from prima Kay o

trle TekenonCo. om Pprmany Kou


Ovelgn Keys always
i Fovehn koy abla regenoncin s abl
Poimouy ay abla TebenonCacd able

Let us study first different types of integrity constraints in RDBMS before


understanding referential integrity
Tapic: lntegnihy C onst saints Relakon
What is Inheaih Conshaints
Jhe data
uYa cy cnd Consislency ct
L used to ensuse acc uYay
in Telaborna doaba se,
Ly set of rules Jhat calcibase is nok bomiHed to Violate

y Conshraints may be applied to


Ls Relahenship v
insenhom ) made
L ensue. Jhat changes ( updote, delehon
dele ,
to Jhe tbasese
daBciba by auhonged usens clo no Tesult
loss daa Consis leny
A blocd must be Ag' or O nly
gocup
b, 6 , H.
b Jhis We haue to detino in a table.

TYpes of integrihy onshraints


) Domcin Conshaint Applisd AHibute.

Conghaint Apnien Athi loul


Enty
Refenenhad Snlegiy Cong aint Applies Reloh anship
Key Conshrcirnts Appties Atibuta

) Domdin Conohaint :
De kines Jhe clomain ot Valid (set of Values ) o6
ahhbuhe
shoud be tve inteçe.
should not e rnegah ve
should no be chavacen.

be numbe Special chavact.


eg. Name hold no
Phone no should not be greata. Jhon
Enkky Sntegiy Conohnt
Telatea to bima, Key ano Jhis ohoint en syre
primay
Pimayalus Coñt be NULL.
St pnmay Koy has a mul valua. Jhon we
ant ldonity those.

5 Retenial Snlegyilg Coohcint:


Speckd 6 elahomhip b/o too table g.
Let us take an eNample :
Employe. Table.
Emp-1D Emp- Name Age Dep. No
Mohan 21 DI

|0 2. Rohan 33 DI
103 Sohan 24 D2

Dohan 22 D3
’Pimay Key Porelgn Key in Rejoneniny table
Deparmonlal Table
Dep No LOcahon No O6 emplo
Humba 200
DI
133
D2 Agra
600
D3 Beryal

in ReterDnced able.
Primay ey
NOte.
L’
We. cant add D5. Jin Dep. No bE Employe. table becane
Jhot athib is detirod a toreign ay kich is taking
Yelerre 6rom Deposmonas Table Dep No
Al values Preront in Tejeenty table m t bo.
pveront in
(Fovein Koy)
Pirauy Kay table Ohenolse NULL' Can bo put in toreign Kay Jabu
Jhe Rulen
from pnmay key thble
6 malchin
) You cañt detete a ecord
records exists elqted table (teterenCad tabl)
value jn
2) You Cant [Change pimay Key
Ye Cord
has Te<aled recordy
fovegn Koy held if
ta bl. Jha
value in
3) You Cañt 9nsert
but you Can put
exis- in primos Kay
( NUL in Foveign Koy tabe.

Ly How you Cn check!


. Foreigo Key
tab le CResenening
table)
tab le)
Paimay key tab e ( Ke7erercod
> nsent dolet
> delels ? updal

KEY CoNSTRAINT:
Candicdct Key
An enhy Set Can houe mUliple Keys be Jhe
but wfich one Key

Primay Key Yelaen -


in
Specilies Jhct
L Key Conshraint
Al ahe Value, of rimany hey
be
unique
mut
Jhe Volue poimay Key
National Institute of Electronics & Information Technology (NIELIT), Gorakhpur
राष्ट्रीय इलेक्ट्रॉनिकी एवं सूचिा प्रौद्योनगकी संस्थाि ,गोरखपुर

Course Name: A Level (1st Sem) Subject : Introduction to DBMS


Let us check another example of foriegn key from internet source
Topic: Keys in RDBMS (Part 4) Date: 27-Mar-2020
-------------------------------------------------------------------------------------------------------------------------------

Foreign Key:

Foreign key is/are column(s)/attribute(s) of a table that point to the primary key
or candidate key of another table. They act as a cross-reference between two
tables.

Foreign key creates relationship between two tables. It helps to maintain data
integrity which is known as “Referential Integrity Constraints”.

The table/relation which is being referenced is called referenced/primary table and


corresponding attribute is called referenced attribute and the relation which refers to
referenced relation is called referencing/related table and corresponding attribute is
called referencing attribute
Let us suppose following tables: Referenced/Primary Table
Primary Key Table1: department_info
dept_id dept_name dept_location dept_budget
101 IT GF-20 500000
102 Electronics GF-23 400000
103 Admin FF-24 350000
104 Accounts FF-24 250000

Foreign Key
Referencing/Related Table
Table2: employee_info
emp_id emp_name emp_dob emp_city dept_id
10001 Rakesh 11-Mar-1990 Gorkahpur 101
10002 Shyam 03-Feb-1980 Lucknow 103
10003 Mahesh Sharma 01-Aug-1991 Gorakhpur 101
10004 Reena 25-Feb-1990 Prayagraj 103
10005 Amit Sharma 08-Jul-1992 Lucknow 104
10006 Rakesh Kumar 04-Apr-1989 Gorakhpur 104

Prepared By
National Institute of Electronics & Information Technology (NIELIT), Gorakhpur
राष्ट्रीय इलेक्ट्रॉनिकी एवं सूचिा प्रौद्योनगकी संस्थाि ,गोरखपुर

dept_id is primary key in department_info table

dept_id is foreign key in employee_info table.

It means that dept_id field of employee_info table can have only those value which
are present in dept_id field of department_info table.

dept_id field in department_info table is for unique identification of the records in


the table.

dept_id field in employee_info table is for knowing which employee is working on


which department.

There are some important differences between primary foreign key

 Primary key cannot be NULL; on the other hand foreign key can be NULL.
 The foreign key field can have only those values which are present in primary
key field of another table.
 The values of Primary key are always unique while foreign key field can have
duplicate values.
 There is one and only one primary key in a table, but we can have more than one
foreign key in a table.

--------------------------------------------------------------------------------------------------------------------

Exercises:

1. Explain another example of foreign key.

Prepared By

You might also like