Prerequisite – Normal Forms

The design of database proceeds in a following way:

- Talk to the stakeholder for which we are designing the database. Get all the requirements, what attributes need to be stored and establish functional dependencies over the given set of attributes.
- Draw an Entity-Relationship diagram on the basis of requirements analysis.
- Convert the ER-diagram into relational model and finally create these relations into our database with appropriate constraints.

We pretty much know, how to draw an ER-diagram. But, when we ask questions like how many minimum relations would be required satisfying first normal form (1NF), it is little confusing sometimes. We establish certain simple rules which are formed after deep analysis of each case and hence, could be used directly.

**Note –** It is not encouraged to mug up the rules, rather understanding the logic behind each case would help you remember them easily and for long time.

**Algorithm –**

- If there is total participation on both sides;

Merge the two entities involved and the relationship into 1 table. - Else if, one side is total participation and one side is partial;
**M:N**Merge the relationship on total participation side.**1:N**Merge the relationship on total participation side.**1:1**Merge the two entities involved and the relationship into 1 table.

- else if, both sides are partial participation;
**M:N**Separate table for each entity as well as relationship. Hence, 3 tables.**1:N**Merge the relationship on N-side using foreign key referencing 1-side.**1:1**Merge the relationship and one entity into 1 table using foreign key and 1 table for other entity.

Now, you would definitely have a question in your mind, how we form such rules? This is very easy and logical. Let’s understand the logic behind it for one case and you can similarly establish the results for other cases too.

We have been given a scenario of 1:N relationship with two entities E1(ABC) and E2(DEF), where A and D are primary keys, respectively. E1 has a partial participation while E2 has total participation in the relationship R.

Based on above scenario, we create certain tuples in E1:

A | B | C |
---|---|---|

a1 | b1 | c1 |

a2 | b2 | c2 |

a3 | b3 | c3 |

Similarly, create certain tuples for E2:

D | E | F |
---|---|---|

d1 | e1 | f1 |

d2 | e2 | f2 |

d3 | e3 | f3 |

Now, create a relationship R satisfying above conditions, i.e. E1 is partial pariticipation and E2 is total participation and E1 to E2 is 1:N relationship.

A | D |
---|---|

a1 | d1 |

a1 | d2 |

a2 | d3 |

Think about possibilities, how can we merge?

**Way-1:**Merge the two entities and relationship into a single table. This is not correct as (AD) will become primary key for this table, but primary key can never have a NULL value.

A B C D E F a1 b1 c1 d1 e1 f1 a1 b1 c1 d2 e2 f2 a2 b2 c2 d3 e3 f3 a3 b3 c3 NULL NULL NULL **Way-2:**Merge relationship on 1-side. This is not correct as (AD) will become primary key for this table, but primary key can never have a NULL value.

A B C D a1 b1 c1 d1 a1 b1 c1 d2 a2 b2 c2 d3 a3 b3 c3 NULL **Way-3:**Merge relationship on N-side. This is correct.

D E F A d1 e1 f1 a1 d2 e2 f2 a1 d3 e3 f3 a2 On the same grounds, could you think why we allow merging the two entities as well as relationship into 1 table, when it is a 1:1 relationship? Simply, we would not have a composite primary key there, so we will definitely have a primary key with no NULL values present in it. Stress some more, why we allow merging the entities and relationship with both sides total participation? The reason is even if we have a composite primary key for such merged table, we are sure that it will never have any NULL values for primary key.

**Note –**You can follow the same procedure as stated above to establish all the results.

Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the **CS Theory Course** at a student-friendly price and become industry ready.