1

Chapter 4: Relational Database design

Database Design – ER to Relational

 ER diagrams mainly comprise of −
 Entity and its attributes
Relationship, which is association among entities

 Mapping Entity
 An entity is a real-world object with some attributes.
 Mapping Process (Algorithm)
 Create table for each entity.
 Entity's attributes should become fields of tables with their respective data types.
 Declare primary key.

DR. R K MAHTO CA & IT DSPMU

 2

What is a relation

A relation is a table that holds the data we are interested in. It is two-dimensional and has
rows and columns.

Each entity type in the ER model is mapped into a relation.

The attributes become the columns.
The individual entities become the rows

Mapping Relationship
A relationship is an association among entities.
Mapping Process

DR. R K MAHTO CA & IT DSPMU

 3

Create table for a relationship.

Add the primary keys of all participating Entities as fields of table with their respective
data types.
If relationship has any attribute, add each attribute as field of table.
Declare a primary key composing all the primary keys of participating entities.
Declare all foreign key constraints.
Mapping Hierarchical Entities specialization or generalization
ER specialization or generalization comes in the form of hierarchical entity sets.
Mapping Process
Create tables for all higher-level entities.
Create tables for lower-level entities.
Add primary keys of higher-level entities in the table of lower-level entities.
In lower-level tables, add all other attributes of lower-level entities.
Declare primary key of higher-level table and the primary key for lower-level table.
Declare foreign key constraints.
Mapping Weak Entity Sets
A weak entity set is one which does not have any primary key associated with it.
Mapping Process
Create table for weak entity set.
Add all its attributes to table as field.
Add the primary key of identifying entity set.
Declare all foreign key constraints
Functional Dependencies
 Functional dependency
 Functional dependency (FD) is a set of constraints between two attributes in a relation.
 Functional dependency says that if two tuples have same values for attributes A1, A2,...,
An, then those two tuples must have to have same values for attributes B1, B2, ..., Bn.
 Functional dependency is represented by an arrow sign (→)
 that is, X→Y, where X functionally determines Y.
 The left-hand side attributes determine the values of attributes on the right-hand side.
 describes the relationship between attributes in a relation.
 Let R be the relation, and let x and y be the arbitrary subset of the set of attributes of R.
Then we say that Y is functionally dependent on x – in symbol.
XY

DR. R K MAHTO CA & IT DSPMU

 4

(Read x functionally determines y) –

 If and only if each x value in R has associated with it precisely one y value in R
In other words
 Whenever two tuples of R agree on their x value, they also agree on their Y value.

 EX: if A and B are attributes of relation R, and B is functionally dependent on A,if each
value of A is associated with exactly one value of B. ( A and B may each consist of one
or more attributes.)
 Example on Student (sid, name, supervisor_id, specialization):
{supervisor_id}  {specialization} means
 If two student records have the same supervisor, then their specialization (e.g.,
Databases) must be the same
 On the other hand, if the supervisors of 2 students are different, we do not care about
their specializations (they may be the same or different)

Product table
One FD : - ( { S#}  {City})
 Because every tuple of that relation with a given S# value also has the same city value.
TRIVIAL DEPENDENCIES
 One-way to reduce the size of the set of FD we need to deal with is to eliminate the
trivial dependencies.
 Trival functional dependency means that the right-hand side is a subset ( not
necessarily a proper subset) of the left-hand side.
 A functional dependency X  Y is trivial if Y is a subset of X
e.g. <S#, P#>  <S#>. (Trivial)
{name, supervisor_id}  {name}

DR. R K MAHTO CA & IT DSPMU

 5

staffNo, sName  sName

staffNo, sName  staffNo
 They do not provide any additional information about possible integrity constraints on
the values held by these attributes.
NON-TRIVIAL DEPENDENCIES
 Nontrivial dependencies are the one, which are not trivial.
 We are normally more interested in nontrivial dependencies because they represent
integrity constraints for the relation.
 A functional dependency X  Y is non-trivial if YX = 
{supervisor_id}  {specialization}
 Non-trivial FDs are given implicitly in the form of constraints when designing a
database.
 For instance, the specialization of a students must be the same as that of the
supervisor.
 They constrain the set of legal relation instances. For instance, if I try to insert two
students under the same supervisor with different specializations, the insertion will
be rejected by the DBMS
Full functional dependency
 Full functional dependency indicates that if A and B are attributes of a relation, B is
fully functionally dependent on A if B is functionally dependent on A, but not on any
proper subset of A.
 A functional dependency AB is partially dependent if there is some attributes that
can be removed from A and the dependency still holds.
E.g X Y
ABC D D is fully functionally dependent on ABC
BC D BC OR C OR A these subset can not be C D determine D
A D D can not be determine by any of the
subset or proper subset of ABC

Armstrong’s Axioms
 Be X, Y, Z be subset of the relation scheme of a relation R
 Reflexivity:
If YX, then XY (trivial FDs)

DR. R K MAHTO CA & IT DSPMU

 6

{name, supervisor_id}{name}
 Augmentation:
If XY , then XZYZ
if {supervisor_id} {spesialization} ,
then {supervisor_id, name}{spesialization, name}
 Transitivity:
If XY and YZ, then XZ
◦ if {supervisor_id} {spesialization} and {spesialization} {lab}, then
{supervisor_id}{lab}
 Self-determination:
AA
 Decomposition:
If A  B,C then A  B and A C
 Union:
If A  B and A  C, then A B,C
 Composition:
If A  B and C  D, then A,C B,

Anomalies
 An anomaly is an inconsistent, incomplete, or contradictory state of the database
 Insertion anomaly – user is unable to insert a new record of data when it should be
possible to do so because not all other information is available.
 Deletion anomaly – when a record is deleted, other information that is tied to it is also
deleted
 Update anomaly –a record is updated, but other appearances of the same items are not
updated
 Redundancy leads to the following anomalies:
 Update anomaly: A change in Address must be made in several places. Updating one
fact may require updating multiple tuples.
 Deletion anomaly: Deleting one fact may delete other information. Suppose a person
gives up all hobbies. Do we:
 Set Hobby attribute to null? No, since Hobby is part of key

DR. R K MAHTO CA & IT DSPMU

 7

 Delete the entire row? No, since we lose other information in the row
 Insertion anomaly: To record one fact may require more information than is available.
Hobby value must be supplied for any inserted row since Hobby is part of key

Normalization
Database Normalization is a technique of organizing the data in the database.
Normalization is a systematic approach of decomposing tables to eliminate data redundancy
and undesirable characteristics like Insertion,Update and Deletion Anomalies.

 It is a multi-step process that puts data into tabular form by removing duplicated data
from the relation tables.
 Normalization is used for mainly two purpose,
 Eliminating redundant(useless) data.
 Ensuring data dependencies make sense i.e data is logically stored.
What is Normalization
Normalization is a database design technique which organizes tables in a manner that
reduces redundancy and dependency of data.
 OR
 Normalization is the process of removing redundant data from your tables.
Improve storage efficiency, data integrity, and scalability.
 Normalization generally involves splitting existing tables into multiple ones, which
must be re-joined or linked each time a query is issued.
 It divides larger tables to smaller tables and link them using relationships.
 Decomposition

DR. R K MAHTO CA & IT DSPMU

 8

 Database normalization: The process of removing redundant data from your tables.
 To improve storage efficiency, Data integrity, and scalability.
 In the relational model, methods exist for quantifying how efficient a database is.
 These classifications are called normal forms (or NF).
 Normalization generally involves splitting existing tables into multiple ones, which
must be re-joined or linked each time a query is issued.
Normal Form
 E.F. Codd originally established three normal forms: 1NF, 2NF and 3NF.
 There are now others that are generally accepted, but 3NF is widely considered to be
sufficient for most applications.
 Most tables when reaching 3NF are also in BCNF (Boyce-Codd Normal Form).
Unnormalized Form (UNF)
 A table that contains one or more repeating groups.
 To create an unnormalized table: Transform data from information source (e.g. form)
into table format with columns and rows.
First Normal Form (1NF)
• A relation in which the intersection of each row and column contains one and only one
value.
• Remove horizontal redundancies
• No two columns hold the same information
• No single column holds more than a single item
• (No composite value e.g. Full name (fname ,mname,lname))
• Each table cell should contain single value(atomic value).
• Each column must have a unique name

DR. R K MAHTO CA & IT DSPMU

 9

• Each row must be unique

• Use a primary key
• Benefits
• Easier to query/sort the data
• More scalable
• Each row can be identified for updating
UNF to 1NF
• Nominate an attribute or group of attributes to act as the key for the
unnormalized table.
• Identify repeating group(s) in unnormalized table which repeats for the key
attribute(s).
• All key attributes defined
• No repeating groups in table
• All attributes dependent on primary key
•

 Roll No  Name  Courses

 101  Amit  DBMS,C

Prog,SE,BPD
 (Not Atomic value)

 102  Ramesh  CO,DS,C++

 103  Sayali  CO,DS,CN,DBMS

• Work on -Not Atomic value

 Roll No  Name  Courses

 101  Amit  DBMS

 101  Amit  C Prog

 101  Amit  SE,

 101  Amit  BPD

 102  Ramesh  CO

 102  Ramesh  DS

DR. R K MAHTO CA & IT DSPMU

 10

 102  Ramesh  C++

 103  Sayali  CO

 103  Sayali  DS

 103  Sayali  CN

 103  Sayali  DBMS

• Before we learn about the second normal form, we need to understand :

• Prime attribute − An attribute, which is a part of the primary-key (Candidate key), is
known as a prime attribute.
• Non-prime attribute − An attribute, which is not a part of the primary-key (Candidate
key), is said to be a non-prime attribute.
• If we follow second normal form, then every non-prime attribute should be fully
functionally dependent on prime key attribute.
•
Second Normal Form
 Based on concept of full functional dependency: A and B are attributes of a relation,
B is fully dependent on A if B is functionally dependent on A but not on any proper
subset of A.
 Every non-primary-key attribute is fully functionally dependent on the primary key.
 Table must be in First Normal Form
 Remove vertical redundancy
 The same value should not repeat across rows
 Composite keys : All columns in a row must refer to BOTH parts of the key
 Benefits
◦ Increased storage efficiency
◦ Less data repetition
 Rule 2NF –
◦ Rule 1- Be in 1NF
◦ Rule 2- Single Column Primary Key
 1NF to 2NF
 Identify primary key for the 1NF relation.
◦ Identify functional dependencies in the relation.

DR. R K MAHTO CA & IT DSPMU

 11

◦ If partial dependencies exist on the primary key remove them by placing them in a new
relation along with copy of their determinant.

Third Normal Form

 Rule 1-It Should be in 2NF
 Rule 2- Has no transitive functional dependencies
 There should not be the case that a non prime attribute is determined by another non
prime attribute
 To move our 2NF table into 3NF we again need to need divide our table

 Transitive dependency : A condition where A, B, and C are attributes of a relation such

that if A  B and B  C, then C is transitively dependent on A via B (provided that A
is not functionally dependent on B or C).
• A relation that is in first and second normal form, and no non-primary-key attribute is
transitively dependent on the primary key.
• The normalization of 2NF relations to 3NF involves the removal of transitive
dependencies by placing the attribute(s) in a new relation along with a copy of the
determinant.
• All columns must relate directly to the primary key

BCNF( Boyce-Codd Normal Form) : A relation is in BCNF, if and only if, every determinant
is a candidate key.
 The difference between 3NF and BCNF:
Functional dependency A  B,
• 3NF : Allows this dependency in a relation if B is a primary-key attribute and A is not a
candidate key, whereas BCNF insists that for this dependency to remain in a relation, A
must be a candidate key. Every relation in BCNF is also in 3NF. However, relation in 3NF
may not be in BCNF.

DR. R K MAHTO CA & IT DSPMU

 12

4th Normal Form

If no database table instance contains two or more, independent and multi valued data
describing the relevant entity , then it is in 4th Normal Form.
5th Normal Form
 Relationship R must be in 4 NF
 If join dependency (JD)not exist then it will be in 5Nf
 A table is in 5th Normal Form only if it is in 4NF and it cannot be decomposed in to
any number of smaller tables without loss of data..
 Additive Join (getting extra table after joining table )

DR. R K MAHTO CA & IT DSPMU

 13

 Non additive lossless join –if we don’t getting extra record or row after joining without
losing any information or data.

 After Join These three tables


Summery
 1NF :
 A relation in which the intersection of each row and column contains one and only
one value.
 2NF :
 Based on concept of full functional dependency
 Every non-primary-key attribute is fully functionally dependent on the primary key.
 3NF :
 Based on concept of Transitive dependency
 No non-primary-key attribute is transitively dependent on the primary
key.
 BCNF :
 Every determinant is a candidate key
 4th Normal Form

DR. R K MAHTO CA & IT DSPMU

 14

 If no database table instance contains two or more, independent and multivalued

data describing the relevant entity , then it is in 4th Normal Form.
 5th Normal Form
 Relationship R must be in 4 NF
 If join dependency (JD)not exixt then it will be in 5Nf
 A table is in 5th Normal Form only if it is in 4NF and it cannot be decomposed in
to any number of smaller tables without loss of data.
 Normalization Example 1

DR. R K MAHTO CA & IT DSPMU

 15


 Relationships for Example


 Normalization Example 2

DR. R K MAHTO CA & IT DSPMU

 16

DR. R K MAHTO CA & IT DSPMU