Database Design/Modelling

Conceptual Tool
Entity-Relationship(ER) Data Model

1
 Entity-Relationship Data Model
 What is Entity ? Ram
 What is Entity set ?
Ram
Aditya Entity Set (Student)
Annu
 An Entity Set do not need to be disjoint.
 Entity is represented by set of attributes.

2
 Types of attribute
(a) Simple & Composite attributes
Student ------- Name
------- Roll No
------- Branch
Composite
Address

Street City State Pin

Streeno Streetname aptno.

(b) Single Valued and Multivalued

Student
Phone Number 3
 Types of Attributes
( c ) Null Attributes
-- Not having a value
- Unknown but later on it is discovered.

(d) Derived Attributes

Join date
Employee
Employment length
4
 Relationship Set
R is subset of n≥ 2
{(e1, e2, . . . . . .,en) | e1Є E1, e2 Є E2 . . . . . enЄ En}
Where ( e1, e2, e3, . . . . . en) is a relationship

e.g. Student & Course entity sets

Register
 Participation - Total
- Partial

 Roles of Entity
• Implicit Explicit
Recursive relationship

 Descriptive attributes
5
 Types of Entity Sets
 Strong Entity Set
Weak Entity Set
Have sufficient
attributes to from a key

No key can be formed

e..g. Same loan – payment.
 Discriminator

6
 Steps of ER Analysis & Design
1. Identify Entity, then entity sets
 Completely model them, i.e. attributes (types) , Keys etc.

2. Identify Relationship sets, attach any descriptive attribute if

required.
 Draw an ER diagram
3. Identify Constraints
 Mapping Cardinalities
 Types of Participations
 Keys
 Denote them in ER Diagram

4. Mapping ER Diagram in to the set tables.

7
 Consistency Constraints
1. Mapping Cardinalities
2. Existence Dependency
3. Keys

a. One to One ( 1 : 1)
b. One to Many ( 1 : M)
c. Many to One ( M : 1)
d. Many to Many ( M : M )

8
(1) One to One ( 1 : 1)

Student Register Course

(2) One to Many ( 1 : M)

Student Opt Subject

RAM CO 3405
CO 3402
NEETU CO 2404
CO 2401
ANNU CO 3403

9
(3) Many to One ( 1 : 1)
Associated
Faculty HOD
with

(4) Many to Many ( 1 : M)

Opt Subject
Student

 Mapping cardinalities effect the placement of

descriptive attributes.
10
 2. Existence Dependency
X Y

Subordinate dominant
Entity Entity
Loan_ Pay_no Pay_date
amt
no

Loan Payment
Loan Payment

 Total Participation
 Partial Participation
11
 Keys
1. Super Key
( Custname, Cus-id, DOB)

2. Candidate Key
( Cust_id), ( Custname, DOB)

3. Primary Key
( Custid ) or ( Custname, DOB)
12
 Transforming ER Diagram to Tables
1. Tabular representation of strong Entity Sets
Roll_no Address C_id P_Marks

Student Opt

Courses

name Phone
C_name

(a) Student (Rollno, Address, name ) T_makrs

(b) Opt ( Rollno, C_id)

(C) Course ( C_id, Cname, T_marks, P_marks)
13
 For Relationship Sets
• Depends on mapping cardinalities (Binary RS)
– One to one (either of the primary key)
– Many to one (primary key of many side)
– One to many (primary key of many side)

• For n-ary RS

14
 2. Tabular Representation of Weak Entity Set
A  Weak
(a1, a2, . . . . an)
discriminator
B  Strong
(b1, b2, . . . . bn)
Primary Key (b1, b2)
Two tables
A (a1, a2, . . . . an) U (b1, b2)
B(b1, b2, . . . . bn)

2. For Relationship Set.

Primary key of participating entity sets and descriptive
attribute if any.
15
Redundancy of Tables ( weak entity set case)
AB B
A

If A is an existence dependency on B then only (two tables)

1. B tables  Tab 1
2. (A U AB)  Tab 2
Example
Balance bname City
Acct_no

Account Acct
Branch
Branc
Assets
Tab 1  Branch (bname, city, assets)
Tab 2  Account (Acct_no, balance, bname)
16
 Tabular Representation of ER Diagram
Multivalued Attribute Case

Emp_no
Employee ---------
Ename
Depatt.
Table  Dependent name name
Dependent name ( dname, emp_no)
 Composite Attribute Case Employee

Address

17
 Extended ER Features
Generalization / Specialization
Acctno Balance

Account

Interest_ Overdraft_
Rate ISA Amount

Saving Checking
Account Account

Tabular Representation
Tab 1 Account (Acctno, balance)
Tab 2 Saving Acct (Acctno, Interest_Rate)
Tab 3 Checking Acct (Acctno, Overdraft_ Amount) 18
 Constraints on Generalization
•Disjoint
E.g. Account entity set
•Overlapping
Employee

ISA

Designer Tester

Total / Partial Participation

 
Account Employee

ISA ISA
Disjoint
19
 Aggregation
Abstraction through which relationships are treated as higher
level entities.

Job

Work Branch
Emp
on

Aggregated
Entity
ManagesSets

Table for managers

Manager
Col 1. PK of manager entity set
Col 2. PK of work on
Col 3. Descriptive attribute of manager entity set
20
 Relational Database Design
Informal design guidline for relation shemas
1. Semantic of the attribute
2. Reducing the redundant values in the tuples.
3. Reducing the null values in the tuples
4. Disallowing the possibility of generating spurious tuples

Various Anomalies
- Insertion
- Deletion
- Modification
+

21
 Relational Data Model
Introduced by Ted Codd in 1970
Based on the concept of Mathematical relation
Some Important definitions
(represent the terminologies)
(1) A relation schema R
(2) A relation r
(3) Mathematical Definition of relation (r)
r(R)  ( dom (A1) X dom (A2) X . . . . X dom (A3) )

22
 Relational Data Model
Characteristics of Relations
1. Ordering of tuples in a relation
2. Ordering of values within a tuple
3. Values in the tuples must be atomic
4. Value of a tuple may be null
Relational Data Model ( 3 Parts )
1. Relational Database
2. Relational Rules
3. Relational Operations

23
 Relational Data Model
Terminologies
-Relation table
- tuple row
-Attribute column
- Cardinality no. of tuples
-Degree number of attribute or arity
- Domain Set of permitted values
- Primary Key
-Relation Schema

24
Relational Database Design

25
 Relational Database Design
-Proposed by Codd (1972)
- Codd
1 NF
2 NF
3 NF ( Stronger definition by Byoce & Codd)
BCNF
4 NF
:
:
-Significance
Reducing redundancy
Eliminate Various types of anomalies
To simplifying the enforcement of certain integrity constraints

26
 2 NF Based on Functional Dependency
What is functional Dependency (FD) ?
Definition 

A B C D
a1 b1 c1 d1
a1 b2 c1 d2
a2 b2 c2 d2
a2 b3 c2 d3
a3 b3 c2 d4
27
 Uses of Functional Dependency
1. F holds on R
2. r satisfying F

Trivial Functional Dependency

If they are satisfying by all relations
AA
AB A
 if 
Functional dependency is a constraint which is
generalization of a notion of key
28
•The notion of Functional Dependency is generalization
of the notion of superkey
KR K is a superkey
•A subset K of R is a superkey of any legal relation r (R),
for all pairs t1 and t2 of tuples in r such that t1  t2 then
t1 [k]  t2 [k]
• Functional Dependencies allow us to express constraints
that we can not express with superkey.
Student ( Rollno, name, year, hostelname, branch,
subject)
Emp ( . . . , Designation, salary ,
Designation  salary
29
 Closure of a set of Functional Dependencies F+
Example
emp_proj (eno, pno, hrs, ename, pname,plocatin )
F = { eno ename , pno  pname, plocation
eno, pno,  Hrs}
F+ Closure is the set of FDs logically implied by F
Rules of Inference
( 1) Reflexivity Rule ( Armstrong’s Axioms )
If  then 
(2) Augmentation Rule



30
 Rules of Inference (cont..)
(3) Transitivity Rules
if 
 
then  holds

( 4) Union Rule
if  and  
then   
( 5) Decomposition Rule
if   , then  and  

(6) Pseudotrasitivity Rule

if  holds
    then
    holds
31
Example
R = (A,B,C,G,H, I)
F = {AB, A C, CG H, CG I, B H}

Algorithm for evaluating +, Closure for  under F

result = 
While ( Changes to result ) do for each FD  in F do
begin if ( result ) then
result = result U 
end
endwhile
32
Example of Attribute Set Closure
• R = (A, B, C, G, H, I)
• F = {A  B
AC
CG  H
CG  I
B  H}
• (AG)+
1. result = AG
2. result = ABCG (A  C and A  B)
3. result = ABCGH (CG  H and CG  AGBC)
4. result = ABCGHI (CG  I and CG  AGBCH)
• Is AG a candidate key?
1. Is AG a super key?
1. Does AG  R?
2. Is any subset of AG a superkey?
1. Does A  R?
2. Does G  R?
 Uses of Attribute Closure
There are several uses of the attribute closure algorithm:
• Testing for superkey:
– To test if  is a superkey, we compute +, and check if + contains all
attributes of R.
• Testing functional dependencies
– To check if a functional dependency    holds (or, in other words, is
in F+), just check if   +.
– That is, we compute + by using attribute closure, and then check if it
contains .
– Is a simple and cheap test, and very useful
• Computing closure of F
– For each   R, we find the closure +, and for each S  +, we output a
functional dependency   S.
Equivalence set of Functional Dependency
Definition 
A set of FDs E is covered by a set of FDs F –
or alternatively, F is said to cover E – if every FD in
E is also in F+; that is E is covered if every
dependency in E can be inferred from F and vice
versa.

Two sets of FDs E and F are equivalent if E+ =F+

35
 Canonical Cover Fc
-Minimal set of FDs
-Efforts for testing the FDs are reduced.
- Reduce the size of F without changing its closure, new
set thus formed is Fc.

- Also called as
Irreducible sets of FDs
Or
Minimal sets of FDs
-reduction is done by eliminating extraneous attributes.
36
 Algorithm for Fc evaluation
1.Set Fc = F
2.Replace each FD, X  A1, A2, . . . . . An in Fc by n FDs.
X  A1, X  A2, . . . . . . X  An
3.For each FD X  A in Fc
For each attribute B is an element of X
if (( Fc – {X  A}) U {(X - B)  A})
is equivalent to Fc then
replace X  A with (X - B)  A
in Fc
4. For each remaining FDs XA in Fc
If (Fc – {XA}) is equivalent to Fc then remove
XA from Fc
37
 Algorithm for Fc evaluation (cont..)
Setp 3
If ((Fc – {X A}) U {(X -B) A} is
equivalent to Fc
Check :----
Let X – {B} =  and check if  can be
inferred from Fc. To do so, compute +
under F; if + includes all attributes in A
then B is extraneous in X 38
 Relational Database Design
Informal design guidline for relation shemas
1. Semantic of the attribute
2. Reducing the redundant values in the tuples.
3. Reducing the null values in the tuples
4. Disallowing the possibility of generating spurious tuples

Various Anomalies
- Insertion
- Deletion
- Modification
+

39
Exercises

Thanks

Any Queries ?

40