Open In App

# Minimum relations satisfying First Normal Form (1NF)

Prerequisite – Normal Forms
The design of database proceeds in a following way:

1. 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.
2. Draw an Entity-Relationship diagram on the basis of requirements analysis.
3. 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.

Notes –

1. If there is total participation on both sides;
Merge the two entities involved and the relationship into 1 table.
2. 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.
3. 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:

ABC
a1b1c1
a2b2c2
a3b3c3

Similarly, create certain tuples for E2:

DEF
d1e1f1
d2e2f2
d3e3f3

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

a1d1
a1d2
a2d3

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.
ABCDEF
a1b1c1d1e1f1
a1b1c1d2e2f2
a2b2c2d3e3f3
a3b3c3NULLNULLNULL
• 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.
ABCD
a1b1c1d1
a1b1c1d2
a2b2c2d3
a3b3c3NULL
• Way-3: Merge relationship on N-side. This is correct.
DEFA
d1e1f1a1
d2e2f2a1
d3e3f3a2

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.