RELATIONAL DATABASE

DESIGN

Relational Database Design Features

of Good Relational Designs

NORMALIZATION
PRE REQUISITES

 Domain knowledge

 Defining Business Rules

 Functional Dependencies

 Keys

 Normal forms and Rules

2
INTRODUCTION
 Simplifying the relations

GOAL

 Allows us to retrieve information easily

Relational database design is to generate

a set of relation that allows us to
schemas store without unnecessary
information
redundancy.
3
FEATURES OF GOOD RELATIONAL DESIGNS:

 1. Relation for every entity

 2. Lesser number of Null values

 3. No spurious tuples

 4. No Redundancy

 5. No modification anomaly
4
1. RELATION FOR EVERY ENTITY

 Informally, each tuple in a relation should

represent one entity or relationship instance.
(Applies to individual relations and their
attributes).

5
 Attributes of different entities (EMPLOYEEs,
DEPARTMENTs, PROJECTs) 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.

6
2. LESSER NUMBER OF NULL
VALUES:
 Relations should be designed such that their
tuples will have as few NULL values as
possible

7
 Attributes that are NULL frequently
could
placed in separate relations (with the
be
primary key)

 Reasons for nulls:

 
Attribute not applicable or invalid
Attribute value unknown (may exist)
  Value known to exist, but unavailable
 
8
3. DECOMPOSITION (SPURIOUS TUPLES):

 Bad designs for a relational database may

result in erroneous results for certain JOIN
operations.

 The "lossless join" property is used to

guarantee meaningful results for join operations

 The relations should be designed to satisfy

the lossless join condition.

 No spurious tuples should be generated by

9
doing a natural-join of any relations.
 There are important properties of
decompositions:
two

 a) Non-additive or of the
corresponding join losslessness
 b) Preservation of the functional
dependencies.

  Property (a) is extremely important and

cannot be sacrificed.
  Property (b) is less strict and may be
10

sacrificed.
LOSSLESS DECOMPOSITION.
 It is a process of splitting a relation into
multiple relations and joins back the relations
to get the original relation; This process is
called as lossless decomposition.

11
EXAMPLE

12
13
4. DATA REDUNDANCY

 Redundancy is storing the same data item in

more one place.

14
 A redundancy creates several problems
like the following:

 Extra storage space: storingthe same data in

many places takes large amount of disk space.

 Entering same data more than once during

data insertion.

 Deleting data from more than one place

during deletion.

 Modifying data in more than one place.

 Anomalies may occur in the database if insertion,

deletion, modification etc are no done properly.
It creates inconsistency and unreliability in the 15

database.
5. MODIFICATION ANOMALY:

 Every schema must ensure the guarantee of

the data when modification happens to the
data.

 Types of anomaly:

1. Update anomalies

2. Deletion anomalies

3. Insert anomalies 16
5.1 Update anomalies

 If data items are scattered and are not

linked to each other properly, then it could
lead to strange situations.

 For example, when we try to update one

data item having its copies scattered over
several places, a few instances get updated
properly while a few others are left with old
values.

 Such instances leave the database in

an inconsistent state.
17
5.2 Deletion anomalies

 We tried to delete a record, but parts of it

was left undeleted because of unawareness,
the data is also saved somewhere else.

18
5.3 Insert anomalies

 We tried to insert data in a record that

does not exist at all.

19
EXAMPLE1 :

20
Update:
If user changes the name of the project
name, will affect all the tuples which matches
the project name.

Insertion:
 Until a employee assigned with a
project,
Project_id, project_name fields will be
empty.

 These fields may fill up with Null values; Nulls

are not really preferred.
no corresponding employee available, so
Employee_id
 When some newand employee_name
project is introduced, there isbe
21

will empty.
 Deletion:

When some project needs to be deleted, so

the corresponding employee detail may also
be deleted.

22
EXAMPLE 2

23
 CLASS WORK
Identify various anomalies for the below relation

24
 SOLUTION

 1. Insert Anomaly: We cannot insert prospective course

which does not have any registered student or we cannot
insert student details that is yet to register for any course.

 2. Update Anomaly: if we want to update the course M4’s

name we need to do this operation three times. Similarly we
may have to update student 1003’s name twice if it changes.

 3. Delete Anomaly: if we want to delete a course M4,

in addition to M4 occurs details, other critical details of
student
also will be deleted. This kind of deletion is harmful to
business. Moreover, M4 appears thrice in above table and
needs to be deleted thrice.

25
CLASS WORK

26
 SOLUTION

Update anomaly:
Clearly, Name and Address are redundant
(larger relation + you have to update 3 rows
to update the Address)

Insertion anomaly:
Cannot make a record Jones’address
because he is not taking any classes.

Delete anomaly:
Cannot delete Smith’s enrolment
without losing his address as well. 27