U nit 1- 1

D BMS-
I ntr oduction

Sour ce: A Silber schatz, H F K or th and S Sudar shan, “D atabase System

Concepts”, McGR AW Hill.

Edited by : Nishant D oshi

Menu

● D atabase system applications

● P ur pose of D atabase Systems
● V iew of D ata
● D ata models
● Appr oaches to building a database
● D atabase management system(D BMS)
● Thr ee levels of the ar chitectur e
● Challenges in building a D BMS
● V ar ious components of a D BMS ar chitectur e.

U nit 1- 1 I ntr oduction 2

D atabase Management System
(D
●
BMS)
D BMS is a
● Collection of inter r elated data i.e. database
● Set of pr ogr ams to access the data
● An envir onment that is both convenient and efficient to use
● D atabase Applications:
● B anking: tr ansactions
● Air lines: r eser vations, schedules
● U niver sities: r egistr ation, gr ades
● Sales: customer s, pr oducts, pur chases
● Online r etailer s: or der tr acking, r ecommendations
● Manufactur ing: pr oduction, inventor y, or der s, supply chain
● Human r esour ces: employee r ecor ds, salar ies, tax deductions
● D atabases can
U nit 1- 1
be very large.
I ntr oduction
Enter pr ise I nfor mation

● Sales:
● For customer, pr oduct, and pur chase infor mation.
● Accounting:
● For payments, r eceipts, account balances, assets and other accounting
infor mation.
● Human resources:
● For infor mation about employees, salar ies, payr oll taxes, and benefits,
and for gener ation of paychecks.
● Manufacturing:
● For management of the supply chain and for tr acking pr oduction of
items in factor ies, inventor ies of items in war ehouses and stor es, and
or der s for items.

U nit 1- 1 I ntr oduction 4

U nit 1- 1 I ntr oduction 5
PD PU D atabase Example

● Add new students, faculties, and cour ses

● R egister students for cour ses, and gener ate class master s
● Assign gr ades to students, compute Cumulative gr ade point aver ages (CGPA) and
gener ate tr anscr ipts
● Maintain attendance, placement, etc. r ecor d
● Maintain OR SP pr oject, alumni etc. r ecor d
● And so on.

U nit 1- 1 I ntr oduction

D rawbacks of using file systems to store data
● D ata redundancy
● Example of data r edundancy
●Account D epar tment
– Student Name, Address, I D , branch, fee, year

●Computer D epar tment (SOT admin)

– Student name, Address, I D , branch, class, batch, year

●P lacement D epar tment

– Student name, Address, I D , branch, class, batch, year

●And so on

U nit 1- 1 I ntr oduction

● D ata inconsistency
● V ar ious piece of infor mation not agr ee. i.e. addr ess in I CT depar tment file is
updated while same addr ess is not r eflected in account and placement.

U nit 1- 1 I ntr oduction 8

● D ifficulty in accessing data
● Consider that SOT admin wants to find the list of students
residing on the pincode 382007. how they do ?
●Fir st way : manually sear ch in database
●Second way : ask pr ogr ammer to make pr ogr am to sear ch in lar ge
database
● After several days, they want to know list of students
having CGPA > 8 (may be for placement purpose)
●Again they have to follow the same ways as ear lier.
● I n short, need to write a new program to carry out each
new task

U nit 1- 1 I ntr oduction 9

● D ata isolation
● D ata will be scattered among multiple files which
●also scatter ed among var ious for mats
● T hus, if makes difficult for programmers to write
programs.
● L ike excel file may not open in linux or mac environment
very well.

U nit 1- 1 I ntr oduction 10

● I ntegrity problems
● I ntegrity constraints (e.g., Marks >= 0 AND Marks <=100)
● D evelopers add these constraints by adding hard coded
lines in several programs.
● However, when new constraints are added,
●it is difficult to change
● T he problem is compounded when constraints involve
several data items from different files.

U nit 1- 1 I ntr oduction 11

● Atomicity of updates
● Failur es may leave database in an inconsistent state with par tial updates
car r ied out
● Example :

● Consider a program to send I NR 5000 from my

account to you.
● I f system failure during program execution than it
may happen that 5000 deducted from account while it
may not deposited in your account.

U nit 1- 1 I ntr oduction 12

● Security problems
● I n general, it is suggested that every user have specific
access to certain files/ data, not all.
● Example : Account department user does not need access
to academic records of student.
● Hard to provide user access to some, but not all, data

U nit 1- 1 I ntr oduction 13

D rawbacks of using file systems to store data (Cont.)

● Concurrent access by multiple users

● Concurrent access needed for performance
● Example : department C has balance 1,00,000. Clerk A
will see this and run program to withdraw 10,000. Same
time clerk B will run withdraw of 5,000.
●W hat will final balance ?
– W hoever’s program last executed that balance will be reflected.

● U ncontrolled concurrent accesses can lead to

inconsistencies

D atabase
U nit systems
1- 1 offer solutions to all the above
I ntr oduction
D ata Abstr action

U nit 1- 1 I ntr oduction

L evels of Abstr action

● P hysical level: describes how a record (e.g., faculty)

is stored.
● L ogical level: describes data stored in database, and
the relationships among the data.
type faculty = record
I D : string;
name : string;
dept_name : string;
salar y : integer;
end;

● V iew level: application programs hide details of data

types. UVnit iews
1- 1 can also hide information (such as an
I ntr oduction
I nstances and Schemas

● Similar to types and variables in programming languages

● L ogical Schema – the overall logical structure of the database
● Example: The database consists of infor mation about a set of customer s
and accounts in a bank and the r elationship between them
● Analogous to type infor mation of a var iable in a pr ogr am

● P hysical schema– the overall physical structure of the

database
● I nstance – the actual content of the database at a particular
point in time
● Analogous to the value of a var iable
● P hysical D ata I ndependence – the ability to modify the
physical schema without changing the logical schema
● Applications
U nit 1- 1 depend
I ntr oduction on the logical schema
D atabase Engine

● Stor age manager

● Quer y pr ocessing
● Tr ansaction manager

U nit 1- 1 I ntr oduction

Stor age Management

● Storage manager is a program module that provides

the interface between the low- level data stored in the
database and the application programs and queries
submitted to the system.
● The storage manager is responsible to the following
tasks:
● I nteraction with the OS file manager
● Efficient storing, retrieving and updating of data
● I ssues:
● Storage access
● File organization
U nit 1- 1 I ntr oduction
Quer y P r ocessing

1. P ar sing and tr anslation

2. Optimization
3. Evaluation

U nit 1- 1 I ntr oduction

Tr ansaction Management

● W hat if the system fails?

● W hat if more than one user is concurrently updating
the same data?
● A transaction is a collection of operations that
performs a single logical function in a database
application
● Transaction- management component ensures that
the database remains in a consistent (correct) state
despite system failures (e.g., power failures and
operating system crashes) and transaction failures.
● Concurrency-
U nit 1- 1 control manager controls the
I ntr oduction
D atabase U ser s and Administr ator s

D atabase

U nit 1- 1 I ntr oduction

D atabase System I nter nals

U nit 1- 1 I ntr oduction

D atabase Ar chitectur e

The ar chitectur e of a database systems is gr eatly influenced by

the under lying computer system on which the database is r unning:
● Centr alized
● Client- ser ver
● P ar allel (multi- pr ocessor )
● D istr ibuted

U nit 1- 1 I ntr oduction

Thr ee level of ar chitectur e

U nit 1- 1 I ntr oduction 25

● Conceptual level
● L ike one can see the student_I D
● I nter nal L evel
● L ike one can see the type of student_I D and any constr aints
● Exter nal level
● L ike one can see the stor age allocation of student_I D

U nit 1- 1 I ntr oduction 26

U nit 1- 1 I ntr oduction 27
U nit 1- 1 I ntr oduction 28
U nit 1- 1 I ntr oduction 29
B ased on tier

U nit 1- 1 I ntr oduction 30

B ased on tier

U nit 1- 1 I ntr oduction 31

● D atabase applications ar e usually par titioned into two or thr ee par ts.
● I n a two- tier ar chitectur e,
● the application r esides at the client machine,
● wher e it invokes database system functionality at the ser ver machine thr ough
quer y language statements.
● Application pr ogr am inter face standar ds like OD BC and JD BC ar e used for
inter action between the client and the ser ver.

U nit 1- 1 I ntr oduction 32

● I n contr ast, in a thr ee- tier ar chitectur e, the client machine acts as mer ely a fr ont end
and does not contain any dir ect database calls.
● I nstead, the client end communicates with an application ser ver , usually thr ough a
for ms inter face.
● The application ser ver in tur n communicates with a database system to access data.

U nit 1- 1 I ntr oduction 33

● The business logic of the application,
● which says what actions to car r y out under what conditions, is embedded in
the application ser ver, instead of being distr ibuted acr oss multiple clients.
● Thr ee- tier applications ar e mor e appr opr iate
● for lar ge applications, and for applications that r un on the W or ld W ide W eb.

U nit 1- 1 I ntr oduction 34

D ata Models

● A collection of tools for describing

● D ata
● D ata relationships
● D ata semantics
● D ata constraints
● R elational model
● Entity- R elationship data model
● Object- based data models
● Object- or iented
● Object- r elational
● Semistructured data model (XML)
● Other older models:
U nit 1- 1 I ntr oduction
Example of a R elation

attr ibutes
(or columns)

tuples
(or r ows)

U nit 1- 1 I ntr oduction

Attr ibute Types

● The set of allowed values for each attr ibute is called the domain of the attr ibute
● Thus, the domain of the salar y attr ibute of the instr uctor r elation is the set of all
possible salar y values.
● The domain of the name attr ibute is the set of all possible instr uctor names.
● The domain of the I D attr ibute is the set of all possible I D i.e. fr om 1to 70.

U nit 1- 1 I ntr oduction

Attr ibute Types

● Attr ibute values ar e (nor mally) r equir ed to be atomic.

● A domain is atomic if elements of the domain ar e consider ed to be indivisible units.
● For example, suppose the table instr uctor had an attr ibute phone number , which can
stor e a set of phone number s cor r esponding to the instr uctor.
● Then the domain of phone number would not be atomic, since an element of the
domain is a set of phone number s, and it has subpar ts, namely the individual phone
number s in the set.

U nit 1- 1 I ntr oduction

● Suppose now that the phone number attr ibute stor es a single phone number.
● Even then, if we split the value fr om the phone number attr ibute into a countr y code,
an ar ea code and a local number, we would be tr eating it as a nonatomic value.
● I f we tr eat each phone number as a single indivisible unit, then the attr ibute phone
number would have an atomic domain.

U nit 1- 1 I ntr oduction 39

Attr ibute Types

● The special value null is a member of ever y domain. I ndicated that the value is
“unknown”
● The null value causes complications in the definition of many oper ations

U nit 1- 1 I ntr oduction

D epar tment r elation

depar tment (dept_name, building, budget)

U nit 1- 1 I ntr oduction 41

D epar tment r elation

U nit 1- 1 I ntr oduction 42

R elation Schema and I nstance

● A1, A2, …, An are attr ibutes

● R = (A1, A2, …, An ) is a r elation schema

Example:

instr uctor = (I D , name, dept_name, salar y)

● Formally, given sets D 1, D 2, …. D n a relation r is a subset of
D1x D2 x … x Dn
T hus, a relation is a set of n- tuples (a1, a2, …, an) where each ai
D i
■ T he current values (relation instance) of a relation are
specifiedU nitby
1- 1
a Itable
ntr oduction
R elations ar e U nor der ed

■ Or der of tuples is ir r elevant (tuples may be stor ed in an ar bitr ar y or der )

■ Example: instr uctor r elation with unor der ed tuples

U nit 1- 1 I ntr oduction

instr uctor

U nit 1- 1 I ntr oduction 45

D epar tment r elation

U nit 1- 1 I ntr oduction 46

univer sity database example

● Each cour se in a univer sity may be offer ed multiple times, acr oss differ ent semester s,
or even within a semester.
● W e need a r elation to descr ibe each individual offer ing, or section, of the class. The
schema is
● section (cour se id, sec id, semester, year, building, r oom number , time slot id)

U nit 1- 1 I ntr oduction 47

U nit 1- 1 I ntr oduction 48
pr er eq r elation

U nit 1- 1 I ntr oduction 49

cour se r elation

U nit 1- 1 I ntr oduction 50

teaches r elation

U nit 1- 1 I ntr oduction 51

K eys

● L et K R
● K is a super key of R if values for K ar e sufficient to identify a unique
tuple of each possible r elation r(R )
● Example: {I D } and {I D ,name} ar e both super keys of instructor.

● Super key K is a candidate key if K is minimal

Example: {I D } is a candidate key for I nstructor
● One of the candidate keys is selected to be the pr imar y key.
● which one?
● For eign key constr aint: V alue in one r elation must appear in another
● R efer encing r elation
● R efer enced r elation
● Example
U nit 1- 1 – Idept_name
ntr oduction in instructor is a for eign key fr om
 Entity-
R elationship
Model
U nit 1- 1 I ntr oduction
Entity Sets

■ Entities can be r epr esented gr aphically as follows:

● R ectangles r epr esent entity sets.
● Attr ibutes listed inside entity r ectangle
● U nder line indicates pr imar y key attr ibutes

U nit 1- 1 I ntr oduction

R elationship Sets

■ D iamonds r epr esent r elationship sets.

U nit 1- 1 I ntr oduction

R elationship Sets with Attr ibutes

U nit 1- 1 I ntr oduction

R oles

● Entity sets of a r elationship need not be distinct

● Each occur r ence of an entity set plays a “r ole” in the r elationship
● The labels “cour se_id” and “pr er eq_id” ar e called r oles.

U nit 1- 1 I ntr oduction

Car dinality Constr aints

● W e express cardinality constraints by drawing either

a directed line (), signifying “one,” or an undirected
line (—), signifying “many,” between the relationship
set and the entity set.
● One- to- one relationship between an instr uctor and a
student :
● A student is associated with at most one instr uctor via the
relationship advisor
● A student is associated with at most one depar tment via
stud_dept

U nit 1- 1 I ntr oduction

One- to- Many R elationship

● one- to- many r elationship between an instr uctor and a student

● an instr uctor is associated with sever al (including 0) students via advisor
● a student is associated with at most one instr uctor via advisor,

U nit 1- 1 I ntr oduction

Many- to- One R elationships

● I n a many- to- one r elationship between an instr uctor and a student,

● an instr uctor is associated with at most one student via advisor ,
● and a student is associated with sever al (including 0) instr uctor s via advisor

U nit 1- 1 I ntr oduction

Many- to- Many R elationship

● An instr uctor is associated with sever al (possibly 0) students via advisor

● A student is associated with sever al (possibly 0) instr uctor s via advisor

U nit 1- 1 I ntr oduction

Total and P artial P articipation
■ Total par ticipation (indicated by double line): ever y entity in the entity
set par ticipates in at least one r elationship in the r elationship set

par ticipation of student in advisor r elation is total

● ever y student must have an associated instr uctor
■ P ar tial par ticipation: some entities may not par ticipate in any
r elationship in the r elationship set
● Example: par ticipation of instr uctor in advisor is par tial

U nit 1- 1 I ntr oduction

Notation for Expressing More Complex Constraints

■ A line may have an associated minimum and maximum car dinality,

shown in the for m l..h, wher e l is the minimum and h the maximum
car dinality
■ A minimum value of 1indicates total par ticipation.
■ A maximum value of 1indicates that the entity par ticipates in at
most one r elationship
■ A maximum value of * indicates no limit.

I nstr uctor can advise 0 or mor e students. A student must have 1

advisor ; cannot have multiple advisor s

U nit 1- 1 I ntr oduction

Notation to Express Entity with Complex Attributes

U nit 1- 1 I ntr oduction

Expressing W eak Entity Sets
● I n E- R diagrams, a weak entity set is depicted via a
double rectangle.
● W e underline the discriminator of a weak entity set
with a dashed line.
● The relationship set connecting the weak entity set to
the identifying strong entity set is depicted by a
double diamond.
● P rimary key for section – (cour se_id, sec_id,
semester, year)

U nit 1- 1 I ntr oduction

E- R D iagram for a U niversity
Enterprise

U nit 1- 1 I ntr oduction

R eduction to R elation Schemas

U nit 1- 1 I ntr oduction

R eduction to R elation Schemas

● Entity sets and r elationship sets can be expr essed unifor mly as r elation schemas
that r epr esent the contents of the database.
● A database which confor ms to an E- R diagr am can be r epr esented by a collection of
schemas.
● For each entity set and r elationship set ther e is a unique schema that is assigned the
name of the cor r esponding entity set or r elationship set.
● Each schema has a number of columns (gener ally cor r esponding to attr ibutes),
which have unique names.

U nit 1- 1 I ntr oduction

R epr esenting Entity Sets

● A str ong entity set r educes to a schema with the same attr ibutes

student(I D , name, tot_cr ed)

● A weak entity set becomes a table that includes a column for the pr imar y key of the
identifying str ong entity set

section ( cour se_id, sec_id, sem, year )

U nit 1- 1 I ntr oduction

R epr esenting R elationship Sets

● A many- to- many r elationship set is r epr esented as a schema with attr ibutes for the
pr imar y keys of the two par ticipating entity sets, and any descr iptive attr ibutes of the
r elationship set.
● Example: schema for r elationship set advisor

advisor = (s_id, i_id)

U nit 1- 1 I ntr oduction

R epresentation of Entity Sets with Composite Attributes

● Composite attr ibutes ar e flattened out by cr eating a

separ ate attr ibute for each component attr ibute
● Example: given entity set instr uctor with composite
attr ibute name with component attr ibutes
fir st_name and last_name the schema
cor r esponding to the entity set has two attr ibutes
name_fir st_name and name_last_name
● P refix omitted if there is no ambiguity (name_first_name
could be first_name)

● I gnor ing multivalued attr ibutes, extended instr uctor

schema is
● instr uctor (I D ,
fir st_name, middle_initial, last_name,
str eet_number , str eet_name,
apt_number , city, state, zip_code,
date_of_bir th)
U nit 1- 1 I ntr oduction
R epresentation of Entity Sets with Multivalued Attributes

● A multivalued attribute M of an entity E is represented

by a separate schema EM
● Schema EM has attributes corresponding to the
primary key of E and an attribute corresponding to
multivalued attribute M
● Example: Multivalued attribute phone_number of
instr uctor is represented by a schema:
inst_phone= ( I D , phone_number )
● Each value of the multivalued attribute maps to a
separate tuple of the relation on schema EM
● For Uexample,
nit 1- 1
an instr uctor entity with primary key 22222
I ntr oduction
R edundancy of Schemas

■ Many- to- one and one- to- many r elationship sets that ar e total on the
many- side can be r epr esented by adding an extr a attr ibute to the “many”
side, containing the pr imar y key of the “one” side
■ Example: I nstead of cr eating a schema for r elationship set inst_dept, add
an attr ibute dept_name to the schema ar ising fr om entity set instr uctor

U nit 1- 1 I ntr oduction

R edundancy of Schemas (Cont.)

● For one- to- one r elationship sets, either side can be chosen to act as the “many” side
● That is, an extr a attr ibute can be added to either of the tables cor r esponding to
the two entity sets
● I f par ticipation is par tial on the “many” side, r eplacing a schema by an extr a
attr ibute in the schema cor r esponding to the “many” side could r esult in null values

U nit 1- 1 I ntr oduction

R edundancy of Schemas (Cont.)

● The schema cor r esponding to a r elationship set linking a weak entity set to its
identifying str ong entity set is r edundant.

● Example: The section schema alr eady contains the attr ibutes that would appear in
the sec_cour se schema

U nit 1- 1 I ntr oduction

Advanced Topics

U nit 1- 1 I ntr oduction

Non- binary R elationship Sets
● Most r elationship sets ar e binar y
● Ther e ar e occasions when it is mor e convenient to r epr esent r elationships as non-
binar y.
● E- R D iagr am with a Ter nar y R elationship

U nit 1- 1 I ntr oduction

Specialization

● Top- down design process; we designate sub-

groupings within an entity set that are distinctive
from other entities in the set.
● These sub- groupings become lower- level entity sets
that have attributes or participate in relationships
that do not apply to the higher- level entity set.
● D epicted by a tr iangle component labeled I SA (e.g.,
instr uctor “is a” per son).
● Attribute inheritance – a lower- level entity set inherits
all the attributes and relationship participation of the
higher-U nitlevel
1- 1
entity set to which it is linked.
I ntr oduction
Specialization Example

● Over lapping – employee and student

● D isjoint – instr uctor and secr etar y
● Total and par tial

U nit 1- 1 I ntr oduction

R epresenting Specialization via Schemas
● Method 1:
● For m a schema for the higher - level entity
● For m a schema for each lower - level entity set, include pr imar y key of higher -
level entity set and local attr ibutes

schema attributes
● D r awback:
person getting inforstreet,
I D , name, mation cityabout, an employee r equir es accessing two
student the one
r elations, I Dcor
, tot_cred
r esponding to the low- level schema and the one
cor employee
r esponding toItheD , salary
high- level schema

U nit 1- 1 I ntr oduction

R epresenting Specialization as Schemas (Cont.)
● Method 2:
● For m a schema for each entity set with all local and inher ited attr ibutes

schema attributes
person I D , name, street, city
student I D , name, street, city, tot_cred
● D r awback:employee
name, str eetIand city may
D , name, street,be stor
city, ed r edundantly for people who
salary
ar e both students and employees

U nit 1- 1 I ntr oduction

Gener alization

● A bottom- up design pr ocess – combine a number of entity sets that shar e the same
featur es into a higher - level entity set.
● Specialization and gener alization ar e simple inver sions of each other ; they ar e
r epr esented in an E- R diagr am in the same way.
● The ter ms specialization and gener alization ar e used inter changeably.

U nit 1- 1 I ntr oduction

Aggr egation

■ Consider the ter nar y r elationship pr oj_guide, which we saw ear lier
■ Suppose we want to r ecor d evaluations of a student by a guide on a
pr oject

U nit 1- 1 I ntr oduction

Aggr egation (Cont.)

● R elationship sets eval_for and pr oj_guide r epr esent over lapping infor mation
● Ever y eval_for r elationship cor r esponds to a pr oj_guide r elationship
● However, some pr oj_guide r elationships may not cor r espond to any eval_for
r elationships
● So we can’t discard the pr oj_guide relationship
● Eliminate this r edundancy via aggr egation
● Tr eat r elationship as an abstr act entity
● Allows r elationships between r elationships
● Abstr action of r elationship into new entity

U nit 1- 1 I ntr oduction

Aggr egation (Cont.)

● Eliminate this redundancy via aggr egation without

introducing redundancy, the following diagram
represents:
● A student is guided by a particular instructor on a
particular project
● A student, instructor, project combination may have an
associated evaluation

U nit 1- 1 I ntr oduction

R epresenting Aggregation via Schemas

■ To r epr esent aggr egation, cr eate a schema containing

● P r imar y key of the aggr egated r elationship,
● The pr imar y key of the associated entity set
● Any descr iptive attr ibutes
■ I n our example:
● The schema eval_for is:
eval_for (s_I D , pr oject_id, i_I D , evaluation_id)
● The schema pr oj_guide is r edundant.

U nit 1- 1 I ntr oduction

D esign I ssues

U nit 1- 1 I ntr oduction

Entities vs. Attr ibutes

● U se of entity sets vs. attr ibutes

● U se of phone as an entity allows extr a infor mation about phone number s (plus
multiple phone number s)

U nit 1- 1 I ntr oduction

Entities vs. R elationship sets

● U se of entity sets vs. r elationship sets

P ossible guideline is to designate a r elationship set to descr ibe an action that occur s
between entities

● P lacement of r elationship attr ibutes

For example, attr ibute date as attr ibute of advisor or as
attr ibute of student

U nit 1- 1 I ntr oduction

B inar y V s. Non- B inar y R elationships

● Although it is possible to replace any non- binary (n- ary, for n

> 2) relationship set by a number of distinct binary
relationship sets, a n- ary relationship set shows more clearly
that several entities participate in a single relationship.
● Some relationships that appear to be non- binary may be
better represented using binary relationships
● For example, a ter nar y r elationship parents, r elating a child to his/ her
father and mother, is best r eplaced by two binar y r elationships, father
and mother
● U sing two binar y r elationships allows par tial infor mation (e.g., only
mother being known)
● B ut ther e ar e some r elationships that ar e natur ally non- binar y
● Example: pr oj_guide

U nit 1- 1 I ntr oduction

Converting Non- B inary R elationships to B inary Form

● I n general, any non- binary relationship can be represented

using binary relationships by creating an artificial entity set.
● R eplace R between entity sets A, B and C by an entity set E, and thr ee
r elationship sets:
1. R A, relating E and A 2. R B , relating E and B
3. R C, relating E and C
● Cr eate an identifying attr ibute for E and add any attr ibutes of R to E
● For each r elationship (ai , bi , ci) in R , cr eate

1. a new entity ei in the entity set E 2. add (ei , ai ) to R A

3. add (ei , bi ) to R B 4. add (ei , ci ) to R C

U nit 1- 1 I ntr oduction

Converting Non- B inary R elationships (Cont.)
● Also need to tr anslate constr aints
● Tr anslating all constr aints may not be possible
● Ther e may be instances in the tr anslated schema that
cannot cor r espond to any instance of R
● Exercise: add constr aints to the r elationships R A, R B
and R C to ensure that a newly created entity
corresponds to exactly one entity in each of entity sets
A, B and C
● W e can avoid cr eating an identifying attr ibute by making E a weak entity set
(descr ibed shor tly) identified by the thr ee r elationship sets

U nit 1- 1 I ntr oduction

E- R D esign D ecisions

● The use of an attribute or entity set to represent an

object.
● W hether a real- world concept is best expressed by an
entity set or a relationship set.
● The use of a ternary relationship versus a pair of
binary relationships.
● The use of a strong or weak entity set.
● The use of specialization/generalization –
contributes to modularity in the design.
● The use of aggregation – can treat the aggregate
entity set
U nit 1- as
1 a single unit without concern for the
I ntr oduction
Summary of Symbols U sed in E- R Notation

U nit 1- 1 I ntr oduction

Symbols U sed in E- R Notation (Cont.)

U nit 1- 1 I ntr oduction

Alter native ER Notations

● Chen, I D E1F X, …

U nit 1- 1 I ntr oduction

Alter native ER Notations

Chen I D E1F X (Cr ows feet notation)

U nit 1- 1 I ntr oduction

U ML

● U ML: U nified Modeling L anguage

● U ML has many components to gr aphically model differ ent aspects of an entir e
softwar e system
● U ML Class D iagr ams cor r espond to E- R D iagr am, but sever al differ ences.

U nit 1- 1 I ntr oduction

ER vs. U ML Class D iagr ams

*Note r ever sal of position in car dinality constr aint depiction

U nit 1- 1 I ntr oduction
ER vs. U ML Class D iagr ams

ER D iagr am Notation Equivalent in U ML

*Gener alization can use mer ged or separ ate ar r ows independent
of disjoint/ over lapping
U nit 1- 1 I ntr oduction
Object- B ased D ata Model

● Object- or iented pr ogr amming (Java, C++, or C#)

● has become the dominant softwar e- development methodology.
● This led to the development of an object- or iented data model that can be seen as
● extending the E- R model with notions of encapsulation, methods (functions),
and object identity.
● The object- r elational data model combines
● featur es of the object- or iented data model and r elational data model

U nit 1- 1 I ntr oduction 102

Semistr uctur ed D ata Model

● individual data items of the same type

● may have differ ent sets of attr ibutes.
● This is in contr ast to the data models mentioned ear lier,
● wher e ever y data item of a par ticular type must have the same set of attr ibutes.
● The Extensible Mar kup L anguage (XML) is widely used to r epr esent semistr uctur ed
data.

U nit 1- 1 I ntr oduction 103

XML

● <instr uctor >

● <I D > 10101</ I D >

● <name> Srinivasan </ name>
● <dept name> Comp. Sci.</ dept name>
● <salary> 65000 </ salary>
● <teaches>
● <cour se>
– <cour se id> CS- 101</ cour se id>
– <title> I ntr o. to Computer Science </ title>
– <dept name> Comp. Sci. </ dept name>
– <cr edits> 4 </ cr edits>

● </ cour se>

● </ teaches>
● </ instr uctor >
U nit 1- 1 I ntr oduction 104
Histor y of D atabase Systems

● 1950s and early 1960s:

● D ata processing using magnetic tapes for storage
●Tapes pr ovided only sequential access
● P unched cards for input
● L ate 1960s and 1970s:
● Hard disks allowed direct access to data
● Network and hierarchical data models in widespread use
● Ted Codd defines the relational data model
●W ould win the ACM Tur ing Awar d for this wor k
●I BM R esear ch begins System R pr ototype
●U C B er keley begins I ngr es pr ototype
● High- performance
U nit 1- 1 I ntr oduction (for the era) transaction processing
Histor y (cont.)

● 1980s:
● R esear ch r elational pr ototypes evolve into commer cial systems
● SQL becomes industr ial standar d
● P ar allel and distr ibuted database systems
● Object- or iented database systems
● 1990s:
● L ar ge decision suppor t and data- mining applications
● L ar ge multi- ter abyte data war ehouses
● Emer gence of W eb commer ce
● Early 2000s:
● XML and XQuer y standar ds
● Automated database administr ation
● L ater 2000s:
● GiantU nit 1- 1
data stor age systems
I ntr oduction
R efer ences

● A Silber schatz, H F Kor th and S Sudar shan, “D atabase System Concepts”,

McGR AW Hill.
● C. J. D ate, A. Kennan, and S. Swamynathan, “An I ntroduction to D atabase
Systems”, P er son Education
● R amez Elmasr i and Shamkant B Navathe, “Fundamentals of D atabase
Systems”, Addison W esley
● I van B ayr oss, “SQL , PL/SQL the P rogramming L anguage of Oracle”, BPB
P ublication.
● R amkr ishnan, R aghu, “D atabase Management Systems”, Mc- Gr aw Hill
● NPTEL video lectur es
● Google

U nit 1- 1 I ntr oduction 108

U nit 1- 1 I ntr oduction