Reduction of ER diagram to Table

The database can be represented using the notations, and these notations can be reduced to a collection
of tables.
In the database, every entity set or relationship set can be represented in tabular form.
The ER diagram is given below:

There are some points for converting the ER diagram to the table:
o Entity type becomes a table.
In the given ER diagram, LECTURE, STUDENT, SUBJECT and COURSE forms individual tables.
o All single-valued attribute becomes a column for the table.
In the STUDENT entity, STUDENT_NAME and STUDENT_ID form the column of STUDENT table.
Similarly, COURSE_NAME and COURSE_ID form the column of COURSE table and so on.
o A key attribute of the entity type represented by the primary key.
In the given ER diagram, COURSE_ID, STUDENT_ID, SUBJECT_ID, and LECTURE_ID are the key
attribute of the entity.
o The multivalued attribute is represented by a separate table.
In the student table, a hobby is a multivalued attribute. So, it is not possible to represent multiple values
in a single column of STUDENT table. Hence, we create a table STUD_HOBBY with column name
STUDENT_ID and HOBBY. Using both the column, we create a composite key.
o Composite attribute represented by components.
In the given ER diagram, student address is a composite attribute. It contains CITY, PIN, DOOR#,
STREET, and STATE. In the STUDENT table, these attributes can merge as an individual column.
o Derived attributes are not considered in the table.
In the STUDENT table, Age is the derived attribute. It can be calculated at any point of time by
calculating the difference between current date and Date of Birth.
Using these rules, you can convert the ER diagram to tables and columns and assign the mapping
between the tables. Table structure for the given ER diagram is as below:
Recursive Relationships in ER diagrams
A relationship between two entities of a similar entity type is called a recursive relationship. Recursive
relationships are often used to represent hierarchies or networks, where an entity can be connected to
other entities of the same type. For example, in an organizational chart, an employee can have a
relationship with other employees who are also in a managerial position. Similarly, in a social network,
a user can have a relationship with other users who are their friends. To represent a recursive relationship
in an ER diagram, we create a relationship between the same entity type.

Minimization of ER Diagrams
Minimization means reducing the number of tables from the ER diagram. We can minimize these tables
as much as possible to reduce the complexity of the database. Reducing the ER Diagram will depend
upon the cardinality of the relationship. So, we will see different cases for minimizing the er diagram:

o One to One Relationship:

When there is one to one relationship between two entities, then there can be two possibilities:
When there is Total Participation at one end:

Let's suppose we have two entities, and p1 and p2 are the attributes and primary keys of both the
entities, respectively. If there is total participation at the end of entity 1, then we can combine the two
tables into one with the primary key as p1.
Since entity 1 is in the total participation, which means each row of entity 1 relates to one row of entity
2. Still, it is not necessary that each entry of entity 2 will relate to rows of entity 1. So, we will choose
the primary keys as p1.
When there is no Total Participation:

Let's suppose we have two entities, and p1 and p2 are the attributes and primary keys of both the entities,
respectively. If there is no total participation, then we cannot combine and reduce the tables because if
we combine the tables with either p1 as the primary key or p2 as the primary key, then we will miss
some entries, and we will get null values in the combined table.
So at least two tables are required in one-to-one relationship if there is no total participation.

o Many to One Cardinality in ER Diagram:

We can understand it by an example. Let's suppose we have one entity as a student and another entity
as a course, and the relation is enrollment. One student can enroll in one course, but one course can be
enrolled by many students, so it is many to one cardinality.
We will have three tables: one is for students, one is for the course, and the last one is for enrollment.
We can combine any two tables to minimize the er diagram. We can combine the student and enrollment
table with the primary key as student id and other tables, of course. So, we can minimize it into two
tables.
So, in many to one cardinality, we require at least two tables.

o One to Many Cardinalities:

In one to many, cardinality works the same as many to one, and we combine the tables into at least two
tables to minimize the ER Diagram.

o Many to Many Cardinalities:

Let's suppose we have the same example as we used in the above cases, but now one student can enrol
in more than one course, and one course can be enrolled by many students. So, it will be many to many
cardinality relationships. Now, if we merge the two tables, then we have to make primary keys either to
the student id or the course id, and in both cases, the combined table will have redundant data. So, we
cannot merge the tables, and at least three tables are required in the many to many cardinality
relationships.

Functional Dependency
The functional dependency is a relationship that exists between two attributes. It typically exists
between the primary key and non-key attribute within a table.
1. X → Y
The left side of FD is known as a determinant, the right side of the production is known as a dependent.
For example:
Assume we have an employee table with attributes: Emp_Id, Emp_Name, Emp_Address.
Here Emp_Id attribute can uniquely identify the Emp_Name attribute of employee table because if we
know the Emp_Id, we can tell that employee name associated with it.
Functional dependency can be written as:
1. Emp_Id → Emp_Name
We can say that Emp_Name is functionally dependent on Emp_Id.

Types of Functional dependency

1. Trivial functional dependency
o A → B has trivial functional dependency if B is a subset of A.
o The following dependencies are also trivial like: A → A, B → B
Example:
1. Consider a table with two columns Employee_Id and Employee_Name.
2. {Employee_id, Employee_Name} → Employee_Id is a trivial functional dependency as
3. Employee_Id is a subset of {Employee_Id, Employee_Name}.
4. Also, Employee_Id → Employee_Id and Employee_Name → Employee_Name are trivial
dependencies too.
2. Non-trivial functional dependency
o A → B has a non-trivial functional dependency if B is not a subset of A.
o When A intersection B is NULL, then A → B is called as complete non-trivial.
Example:
1. ID → Name,
2. Name → DOB
Equivalence of Functional Dependencies
1. If all FDs of FD1 can be derived from FDs present in FD2, we can say that FD2 ⊃ FD1.
2. If all FDs of FD2 can be derived from FDs present in FD1, we can say that FD1 ⊃ FD2.
3. If 1 and 2 both are true, FD1=FD2.

Attribute Closure
Attribute closure of an attribute set can be defined as set of attributes which can be functionally
determined from it.

How to find attribute closure of an attribute set?

To find attribute closure of an attribute set:
• Add elements of attribute set to the result set.
• Recursively add elements to the result set which can be functionally determined from the
elements of the result set.
Using FD set of table 1, attribute closure can be determined as:
(STUD_NO)+ = {STUD_NO, STUD_NAME, STUD_PHONE, STUD_STATE, STUD_COUNTRY,
STUD_AGE}
(STUD_STATE)+ = {STUD_STATE, STUD_COUNTRY}

Prime and Non-Prime Attributes

Attributes which are parts of any candidate key of relation are called as prime attribute, others are non-
prime attributes.

Inference Rule (IR):

o The Armstrong's axioms are the basic inference rule.
o Armstrong's axioms are used to conclude functional dependencies on a relational database.
o The inference rule is a type of assertion. It can apply to a set of FD (functional dependency) to
derive other FD.
o Using the inference rule, we can derive additional functional dependency from the initial set.
The Functional dependency has 6 types of inference rule:
1. Reflexive Rule (IR1)
In the reflexive rule, if Y is a subset of X, then X determines Y.
1. If X ⊇ Y then X → Y
Example:
1. X = {a, b, c, d, e}
2. Y = {a, b, c}
2. Augmentation Rule (IR2)
The augmentation is also called as a partial dependency. In augmentation, if X determines Y, then XZ
determines YZ for any Z.
1. If X → Y then XZ → YZ
Example:
1. For R(ABCD), if A → B then AC → BC
3. Transitive Rule (IR3)
In the transitive rule, if X determines Y and Y determine Z, then X must also determine Z.
1. If X → Y and Y → Z then X → Z
4. Union Rule (IR4)
Union rule says, if X determines Y and X determines Z, then X must also determine Y and Z.
1. If X → Y and X → Z then X → YZ
Proof:
1. X → Y (given)
2. X → Z (given)
3. X → XY (using IR2 on 1 by augmentation with X. Where XX = X)
4. XY → YZ (using IR2 on 2 by augmentation with Y)
5. X → YZ (using IR3 on 3 and 4)
5. Decomposition Rule (IR5)
Decomposition rule is also known as project rule. It is the reverse of union rule.
This Rule says, if X determines Y and Z, then X determines Y and X determines Z separately.
1. If X → YZ then X → Y and X → Z
Proof:
1. X → YZ (given)
2. YZ → Y (using IR1 Rule)
3. X → Y (using IR3 on 1 and 2)
6. Pseudo transitive Rule (IR6)
In Pseudo transitive Rule, if X determines Y and YZ determines W, then XZ determines W.
1. If X → Y and YZ → W then XZ → W
Proof:
1. X → Y (given)
2. WY → Z (given)
3. WX → WY (using IR2 on 1 by augmenting with W)
4. WX → Z (using IR3 on 3 and 2)
Armstrong Relation
Armstrong Relation can be stated as a relation that is able to satisfy all functional dependencies in the
F+ Closure. In the given set of dependencies, the size of the minimum Armstrong Relation is an
exponential function of the number of attributes present in the dependency under consideration.
Why Armstrong Axioms Refer to the Sound and Complete?
By sound, we mean that given a set of functional dependencies F specified on a relation schema R, any
dependency that we can infer from F by using the primary rules of Armstrong axioms holds in every
relation state r of R that satisfies the dependencies in F.

By complete, we mean that using primary rules of Armstrong axioms repeatedly to infer dependencies
until no more dependencies can be inferred results in the complete set of all possible dependencies that
can be inferred from F.

Steps to find out the Candidate Key of a Relational Table using Functional Dependencies
Step 1:
First, we will find out the essential and non-essential sets of attributes from the given set of attributes.
Those attributes which are dependent on other attributes are non-essential attributes, and their values
can be found out using essential attributes.
So, all the essential attributes will definitely be part of our candidate key.
Step 2:
We will combine all the essential attributes, and if they can determine all the attributes (by finding their
closure), then it will be the candidate key.
Step 3:
If a combination of essential attributes is not a candidate key, then we will try different combinations
of essential and non-essential attributes which are not subset of each other to find out all the candidate
keys.
Example 1:
Let's suppose we have a set of attributes as S: {A, B, C, D} and functional dependencies are:
A -> B
B -> C
C -> A
Solution:
In the above example, we have non-essential attributes as {A, B, C}, and the essential attribute is {D}.
So, D will be the part of the candidate key.
Closure of D: {D}
So, a combination of essential attributes is not able to find all the attributes, so we will add non-essential
attributes in different ways to find out the candidate keys.
Closure of (AD) = {A, B, C, D} (using A->B and B->C)
So, AD will be a candidate key.
Closure of (BD) = {A, B, C, D} (using C->A and B->C)
So, BD will be a candidate key.
Closure of (CD) = {A, B, C, D} (using C->A and A->B)
So, CD will be a candidate key.
No other combination of attributes is not possible, so candidate keys are {AD, BD, CD}
Example 2:
Let's suppose we have a set of attributes as S: {A, B, C, D, E, F} and functional dependencies are:
AB -> C
B -> AE
C -> D
Solution:
In the above example, we have non-essential attributes as {A, C, D, E}, and the essential attribute is
{B, F}.
So, BF will be the part of the candidate key.
Closure of BF: {B, A, E, C, D, F}
Since the combination of essential attributes is capable of finding all the attributes, it will be a candidate
key. All other combinations of the essential and non-essential attributes will not be minimal, so there
will be only one candidate key as {BF}.
Example 3:
Let's suppose we have a set of attributes as S: {A, B, C, D, E} and functional dependencies are:
CE -> D
D -> B
C -> A
Solution:
In the above example, we have non-essential attributes as {A, B, D}, and the essential attribute is {C,
E}.
So, CE will be the part of the candidate key.
Closure of CE: {C,E,D,B,A} using (CE->D, D->B and C->A)
Since the combination of essential attributes is capable of finding all the attributes, it will be a candidate
key. All other combinations of the essential and non-essential attributes will not be minimal, so there
will be only one candidate key as {CE}.
Example 4:
Let's suppose we have a set of attributes as S: {W, X, Y, Z} and functional dependencies are:
Z -> W
Y -> XZ
XW -> Y
Solution:
In the above example, we have non-essential attributes as {W, X, Y, Z}, and the essential attribute is {}.
In this example, we will explore each and every combination of attributes to find out the candidate key,
as there is no essential attribute.
Closure of W = {W}
Closure of X = {X}
Closure of Y = {Y,X,Z,W} (using Y->XZ and Z->W)
Closure of Z = {Z}
Since Y is capable of finding all the attributes so it will be a candidate key. Y will not be part of the next
combinations.
Closure of XW = {X,W,Y,Z} (using XW->Y and Y->XZ)
Closure of ZW = {Z,W}
Closure of XZ = {X,W,Y,Z} (using Z->W and XW->Y)
So, XW and XZ will be the next candidate keys, and the next other combinations will contain no
attributes apart from these candidate keys.
So, there will be three candidate keys which are {Y, XW, XZ}
Example 5:
Let's suppose we have a set of attributes as S: {A, B, C, D, E, F} and functional dependencies are:
AB -> C
C-> D
D -> BE
E -> F
F -> A
Solution:
In the above example, we have non-essential attributes as {A, B, C, D, E, F}, and the essential attribute
is {}.
Now in this example, we will explore each and every combination of attributes to find out the candidate
key, as there is no essential attribute.
If there is no essential attribute, then each non-essential attribute can be a candidate key, so it increases
the number of candidate keys.
Closure of A = {A}
Closure of B = {B}
Closure of C = {C, D, B, E, F, A} using (C->D, D->BE, E->F, F->A)
Closure of D = {D, B, E, F, A, C} using (AB->C, D->BE, E->F, F->A)
Closure of E = {E,F,A} using (A->F, F->A)
Closure of F = {F,A} using(F->A)
Since {C, D} are capable of finding all the attributes so it will be a set of candidate keys. {C, D} will
not be part of the next combinations.
Closure of AB = { A, B, C, D, E, F}
Closure of AE = { A,E,F}
Closure of AF = { A,F}
Closure of BE = { A, B, C, D, E, F}
Closure of BF = { A, B, C, D, E, F}
Closure of EF = { A,E,F}
So, AB, BE, and BF will be the next candidate keys, and the next other combinations will contain no
attributes apart from these candidate keys.
So, there will be five candidate keys which are {C, D, AB, BE, BF}
Example 6:
Let's suppose we have a set of attributes as S: {A, B, C, D, E, F, G, H} and functional dependencies are:
A -> BC
E -> A
B -> CFH
CH -> G
F -> EG
Solution:
In the above example, we have non-essential attributes as {A, B, C, E, F, G, H}, and the essential
attribute is {D}.
Closure of D = {D}
Since D is an essential attribute, it will be part of all the combinations of essential and non-essential
attributes.
Closure of AD = {A, B, C, D, E, F, G, H} using (A->BC, B->CFH, F->EG)
Closure of BD = {A, B, C, D, E, F, G, H} using (B->CFH, F->EG, E->A)
Closure of CD = {C,D}
Closure of ED = {A, B, C, D, E, F, G, H} using (E->A, A->BC, B-> CFH, F->EG)
Closure of FD = {A, B, C, D, E, F, G, H} using (F->EG, E->A, A->BC)
Closure of GD = {D,G}
Closure of HD = {D,H}
So, we have tried all the combinations of essential and non-essential attributes, and we got four
candidate keys which are {AD, BD, ED, FD}.