0% found this document useful (0 votes)
37 views

Relational Database Design

Uploaded by

findmyhostel1
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views

Relational Database Design

Uploaded by

findmyhostel1
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 43

DBMS

Unit 7: Relational Database Design

Instructor
Indra Chaudhary
[email protected]
DBMS: Syllabus
2

 Relational Database Design Using ER-to-Relational Mapping


 Informal Design Guidelines for Relational Schemas
 Functional Dependencies
 Normal Forms Based on Primary Keys
 First Normal Form,
 Second Normal Form
 Third Normal Form
 Boyce-Codd Normal Form
 Multivalued Dependency
 Fourth Normal Form
 Properties of Relational Decomposition
Relational Database Design Using ER-to-Relational Mapping

 Follow the slide of unit 3


Informal Design Guidelines for Relational
Schemas
4

Four informal guidelines that may be used as measures


to determine the quality of relation schema design:
 Semantics of the attributes

 Reducing the redundant values in tuples

 Reducing the null values in tuples

 Disallowing the possibility of generating spurious

tuples
Informal Design Guidelines for Relational
Schemas
5

 Guideline 1: Informally, each tuple in a relation


should represent one entity or relationship instance.
 Attributes of different entities should not be mixed in the
same relation.
 Only foreign keys should be used to refer to other entities.
 Entity and relationship attributes should be kept apart as
much as possible.
 Guideline 2: Design a schema that does not suffer
from the insertion, deletion and update anomalies.
 If there are any anomalies present, then note them so that
applications can be made to take them in account
Informal Design Guidelines for Relational
Schemas
6
 Guideline 2:
 Three data modification anomalies can be briefly explained as:
 Insert Anomaly:

 Insertion Anomaly refers to when one cannot insert a new tuple into a
relationship due to lack of data.
 This kind of anomaly can seriously damage a database
 Deletion Anomaly:
 The delete anomaly refers to the situation where the deletion of data
results in the unintended loss of some other important data.
 It could result in loss of vital data.
 Update Anomaly:
 The update anomaly is when an update of a single data value requires
multiple rows of data to be updated.
 This can lead to inefficiency.
Informal Design Guidelines for Relational
Schemas
7

 Guideline 3: Relation should be designed such that


their tuples will have as few NULL values as
possible.
 Attributes that are NULL frequently could be placed in
separate relations (with the primary key).
 Reasons for NULLs
 Attribute not applicable or invalid
 Attribute value unknown
 Value known to exist, but unavailable
Informal Design Guidelines for Relational
Schemas
8

 Guideline 4: Design relation schemas so that they


can be joined with equality conditions on attributes
that are appropriately related pairs in a way that
guarantees that no spurious tuples are generated.
Avoid relations that contain matching attributes that
are not (foreign key, primary key) combinations
because joining on such attributes may produce
spurious tuples.
 Spurious tuples are those they represent spurious
information that is not valid. The spurious tuples are
marked by asterisks (*)
Normalization of Relation
9

 Normalization: The process of decomposing


unsatisfactory "bad" relations by breaking up their
attributes into smaller relations

 Normal form: Condition using keys and Functional


Dependencies of a relation to certify whether a
relation schema is in a particular normal form
Normalization of Relation
10
 Normalization is carried out in practice so that the
resulting designs are of high quality and meet the
desirable properties
 The practical utility of these normal forms becomes
questionable when the constraints on which they are
based are hard to understand or to detect
 The database designers need not normalize to the
highest possible normal form. (usually up to 3NF,
BCNF or 4NF)
 Denormalization: the process of storing the join of
higher normal form relations as a base relation—which
is in a lower normal form
Functional Dependencies
11

 Read from book/ Provided note


Levels of Normalization
12

 Levels of normalization based on the amount of


redundancy in the database.
 Various levels of normalization are:
 First Normal Form (1NF)
 Second Normal Form (2NF)
 Third Normal Form (3NF)
 Boyce-Coded Normal Form (BCNF)
 Fourth Normal Form (4NF)
 Fifth Normal Form (5NF)
 Domain Key Normal Form (DKNF)

Most
Mostdatabases
databasesshould
shouldbe
be3NF
3NFininorder
ordertotoavoid
avoidthe
thedatabase
databaseanomalies.
anomalies.
Levels of Normalization
13

1NF
2NF
3NF
4NF
5NF
DKNF

Each
Eachhigher
higherlevel
levelisisaasubset
subsetofofthe
thelower
lowerlevel
level
Normal Forms: Levels / Types
14

Normal Form Description


1NF A relation is in 1NF if it contains an atomic value.
2NF A relation will be in 2NF if it is in 1NF and all non-key
attributes are fully functional dependent on the primary
key.
3NF A relation will be in 3NF if it is in 2NF and no transition
dependency exists.
BCNF A stronger definition of 3NF is known as Boyce Codd's
normal form.
4NF A relation will be in 4NF if it is in Boyce Codd's normal
form and has no multi-valued dependency.
5NF A relation is in 5NF. If it is in 4NF and does not contain
any join dependency, joining should be lossless.
Normal Forms: Review
15

 1 NF
 No multivalued attributes or repeating groups.
 2 NF
 1 NF plus no partial dependencies
 3 NF
 2 NF plus no transitive dependencies
 4 NF
 3 NF plus no multi-values dependencies
 5 NF
 4 NF plus no join dependencies
16

Some Normalization Examples


Dependencies: Definitions
17

 Multivalued Attributes (or repeating groups): non-key


attributes or groups of non-key attributes the values of which
are not uniquely identified by (directly or indirectly) (not
functionally dependent on) the value of the Primary Key (or
its part).

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Dependencies: Definitions
18

 Partial Dependency – when an non-key attribute is


determined by a part, but not the whole, of a
COMPOSITE primary key.
Partial
CUSTOMER Dependency

Cust_ID Name Order_ID


101 AT&T 1234
101 AT&T 156
125 Cisco 1250
Dependencies: Definitions
19

 Transitive Dependency – when a non-key attribute


determines another non-key attribute.
Transitive
Dependency

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Example 1: Determine NF
20

 ISBN  Title All attributes are directly


 ISBN  Publisher or indirectly determined by
the primary key; therefore,
 Publisher  Address the relation is at least in 1
NF

BOOK

ISBN Title Publisher Address


Example 1: Determine NF
21

 ISBN  Title The relation is at least in 1NF.


 ISBN  Publisher There is no COMPOSITE
primary key, therefore there
 Publisher  Address can’t be partial dependencies.
Therefore, the relation is at least
in 2NF
BOOK

ISBN Title Publisher Address


Example 1: Determine NF
22

 ISBN  Title
Publisher is a non-key attribute, and
 ISBN  Publisher it determines Address, another non-
 Publisher  Address key attribute. Therefore, there is a
transitive dependency, which means
that the relation is NOT in 3 NF.
BOOK

ISBN Title Publisher Address


Example 1: Determine NF
23

 ISBN  Title We know that the relation is at


 ISBN  Publisher least in 2NF, and it is not in 3 NF.
Therefore, we conclude that the
 Publisher  Address relation is in 2NF.

BOOK

ISBN Title Publisher Address


Example 1: Determine NF
24

 ISBN  Title In your solution you will write the


 ISBN  Publisher following justification:
1) No M/V attributes, therefore at least
 Publisher  Address 1NF
2) No partial dependencies, therefore at
least 2NF
3) There is a transitive dependency
(Publisher  Address), therefore, not
3NF
Conclusion: The relation is in 2NF

BOOK

ISBN Title Publisher Address


Example 2: Determine NF
25

 Product_ID  Description

All attributes are directly or indirectly


determined by the primary key;
therefore, the relation is at least in 1 NF
ORDER

Order_No Product_ID Description


Example 2: Determine NF
26

 Product_ID  Description

The relation is at least in 1NF.


There is a COMPOSITE Primary Key (PK) (Order_No,
Product_ID), therefore there can be partial dependencies.
Product_ID, which is a part of PK, determines
Description; hence, there is a partial dependency.
Therefore, the relation is not 2NF. No sense to check for
transitive dependencies!

ORDER

Order_No Product_ID Description


Example 2: Determine NF
27

 Product_ID  Description

We know that the relation is at least in


1NF, and it is not in 2 NF. Therefore, we
conclude that the relation is in 1 NF.

ORDER

Order_No Product_ID Description


Example 2: Determine NF
28

 Product_ID  Description

In your solution you will write the following


justification:
1) No M/V attributes, therefore at least 1NF
2) There is a partial dependency (Product_ID
 Description), therefore not in 2NF
Conclusion: The relation is in 1NF
ORDER

Order_No Product_ID Description


Example 3: Determine NF
29

 Part_ID  Description Comp_ID and No are not


 Part_ID  Price determined by the primary
key; therefore, the relation is
 Part_ID, Comp_ID  No NOT in 1 NF. No sense in
looking at partial or
transitive dependencies.

PART

Part_ID Descr Price Comp_ID No


Example 3: Determine NF
30

 Part_ID  Description In your solution you will write the


following justification:
 Part_ID  Price 1) There are M/V attributes;
 Part_ID, Comp_ID  No therefore, not 1NF
Conclusion: The relation is not
normalized.

PART

Part_ID Descr Price Comp_ID No


Bringing a Relation to 1NF
31

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 1NF
32

 Option 1: Make a determinant of the repeating


group (or the multivalued attribute) a part of the
primary key.
Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 1NF
33

 Option 2: Remove the entire repeating group from the


relation. Create another relation which would contain all the
attributes of the repeating group, plus the primary key from
the first relation. In this new relation, the primary key from
the original relation and the determinant of the repeating
group will comprise a primary key.

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 1NF
34

STUDENT

Stud_ID Name
101 Lennon
125 Jonson

STUDENT_COURSE

Stud_ID Course Units


101 MSI 250 3
101 MSI 415 3
125 MSI 331 3
Bringing a Relation to 2NF
35

Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 2NF
36

 Goal: Remove Partial Dependencies


Partial
Composite Dependencies
Primary Key

STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 2NF
37

 Remove attributes that are dependent from the part but not the
whole of the primary key from the original relation. For each
partial dependency, create a new relation, with the
corresponding part of the primary key from the original as the
primary key.
STUDENT

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 2NF
38

CUSTOMER STUDENT_COURSE
Stud_ID Name Course_ID Units
101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
Stud_ID Course_ID
125 Johnson MSI 331 3.00
101 MSI 250
101 MSI 415
125 MSI 331
STUDENT COURSE

Stud_ID Name Course_ID Units


101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
Bringing a Relation to 3NF
39

 Goal: Get rid of transitive dependencies.

Transitive
Dependency
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Bringing a Relation to 3NF
40

 Remove the attributes, which are dependent on a non-key


attribute, from the original relation. For each transitive
dependency, create a new relation with the non-key attribute
which is a determinant in the transitive dependency as a
primary key, and the dependent non-key attribute as a
dependent.
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Bringing a Relation to 3NF
41
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name


111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID


111 Mary Jones 1
122 Sarah Smith 2

DEPARTMENT

Dept_ID Dept_Name
1 Acct
2 Mktg
42

 Remaining Contents read from book /note.


43

Thank You

You might also like