1) ER Diagrams

An E-R diagram can express the overall logical structure of a database

graphically.E-R diagrams are used to model real-world objects like a person, a
car, a company and the relation between these real-world objects.
Features of ER model
i) E-R diagrams are used to represent E-R model in a database, which makes
them easy to be converted into relations (tables).
ii) E-R diagrams provide the purpose of real-world modeling of objects which
makes them intently useful.
iii) E-R diagrams require no technical knowledge and no hardware support.
iv) These diagrams are very easy to understand and easy to create even by a
naive user.
v) It gives a standard solution of visualizing the data logically.
Various Components used in ER Model are-

Mapping Cardinality Representation using ER Diagram

There are four types of relationships that are considered for key constraints.
i) One to one relation: When entity A is associated with at the most one entity
B then it shares one to one relation. For example - There is one project manager
who manages only one project.

ii) One to many :When entity A is associated with more than one entities at a
time then there is one to many relation. For example - One customer places
order at a time.

iii) Many to one : When more than one entities are associated with only one
entity then there is is many to one relation. For example – Many student take a
ComputerSciCourse

Alternate representation can be

iv) Many to many: When more than one entities are associated with more than
one entities. For example -Many teachers can teach many students.

Alternate representation can be

Ternary Relationship
The relationship in which three entities are involved is called ternary
relationship. For example -

Binary and Ternary Relationships

• Although binary relationships seem natural to most of us, in reality it is
sometimes necessary to connect three or more entities. If a relationship connects
three entities, it is called ternary or "3-ary."
• Ternary relationships are required when binary relationships are not sufficient
to accurately describe the semantics of an association among three entities.
• For example - Suppose, you have a database for a company that contains the
entities, PRODUCT, SUPPLIER, and CUSTOMER. The usual relationships
might be PRODUCT/ SUPPLIER where the company buys products from a
supplier - a normal binary relationship. The intersection attribute for
PRODUCT/SUPPLIER is wholesale_price
• Now consider the CUSTOMER entity, and that the customer buys products. If
all customers pay the same price for a product, regardless of supplier, then you
have a simple binary relationship between CUSTOMER and PRODUCT. For
the CUSTOMER/PRODUCT relationship, the intersection attribute is
retail_price.

• Single ternary relation: Now consider a different scenario. Suppose the

customer buys products but the price depends not only on the product, but also
on the supplier. Suppose you needed a customerID, a productID, and a
supplierID to identify a price. Now you have an attribute that depends on three
things and hence you have a relationship between three entities (a ternary
relationship) that will have the intersection attribute, price.

Weak Entity Set

• A weak entity is an entity that cannot be uniquely identified by its attributes
alone. The entity set which does not have sufficient attributes to form a primary
key is called as weak entity set.
• Strong Entity Set
The entity set that has primary key is called as strong entity set
Weak entity set because each player needs a team
Weak entity rules
• A weak entity set has one or more many-one relationships to other
(supporting) entity sets.
• The key for a weak entity set is its own underlined attributes and the keys for
the supporting entity sets. For example - player-number and team-name is a key
for Players.

2)ER to Relational Mapping

Mapping of Entity Set to Relationship

• An entity set is mapped to a relation in a straightforward way.
• Each attribute of entity set becomes an attribute of the table.
• The primary key attribute of entity set becomes an entity of the table.
• For example - Consider following ER diagram.

The converted employee table is as follows –

The SQL statement captures the information for above ER diageam as follows -
CREATE TABLE Employee( EmpID CHAR(11),
EName CHAR(30),
Salary INTEGER,
PRIMARY KEY(EmpID))

Mapping Relationship Sets(Without Constraints) to Tables

• Create a table for the relationship set.
• Add all primary keys of the participating entity sets as fields of the table.
• Add a field for each attribute of the relationship.
• Declare a primary key using all key fields from the entity sets.
• Declare foreign key constraints for all these fields from the entity sets.
For example - Consider following ER model

The SQL statement captures the information for relationship present in above
ER diagram as follows -
CREATE TABLE Works In (EmpID CHAR(11),
DeptID CHAR(11),
EName CHAR(30),
Salary INTEGER,
DeptName CHAR(20),
Building CHAR(10),
PRIMARY KEY(EmpID,DeptID),
FOREIGN KEY (EmpID) REFERENCES Employee,
FOREIGN KEY (DeptID) REFERENCES Department
)

Mapping Relationship Sets( With Constraints) to Tables

• If a relationship set involves n entity sets and some m of them are linked via
arrows in the ER diagram, the key for anyone of these m entity sets constitutes a
key for the relation to which the relationship set is mapped.
• Hence we have m candidate keys, and one of these should be designated as the
primary key.
• There are two approaches used to convert a relationship sets with key
constraints into table.
• Approach 1:
 • By this approach the relationship associated with more than one entities is
separately represented using a table. For example - Consider following ER
diagram. Each Dept has at most one manager, according to the key constraint on
Manages.

Here the constraint is each department has at the most one manager to manage
it. Hence no two tuples can have same DeptID. Hence there can be a separate
table named Manages with DeptID as Primary Key. The table can be defined
using following SQL statement
CREATE TABLE Manages (EmpID CHAR(11),
DeptID INTEGER,
Since DATE,
PRIMARY KEY (DeptID),
FOREIGN KEY (EmpID) REFERENCES Employees,
FOREIGN KEY (DeptID) REFERENCES Departments)
Approach 2:
• In this approach, it is preferred to translate a relationship set with key
constraints.
• It is a superior approach because, it avoids creating a distinct table for the
relationship set.
• The idea is to include the information about the relationship set in the table
corresponding to the entity set with the key, taking advantage of the key
constraint.
• This approach eliminates the need for a separate Manages relation, and
queries asking for a department's manager can be answered without combining
information from two relations.
• The only drawback to this approach is that space could be wasted if several
departments have no managers.
• The following SQL statement, defining a Dep_Mgr relation that captures
the information in both Departments and Manages, illustrates the second
approach to translating relationship sets with key constraints:
CREATE TABLE Dep_Mgr (DeptID INTEGER,
DName CHAR(20),
Budget REAL,
EmpID CHAR (11),
since DATE,
PRIMARY KEY (DeptID),
FOREIGN KEY (EmpID) REFERENCES Employees)

Mapping Weak Entity Sets to Relational Mapping

• A weak entity can be identified uniquely only by considering the primary key
of another (owner) entity. Following steps are used for mapping Weak Entity
Set to Relational Mapping
• Create a table for the weak entity set.
• Make each attribute of the weak entity set a field of the table. AI baris M
• Add fields for the primary key attributes of the identifying owner.
• Declare a foreign key constraint on these identifying owner fields.
• Instruct the system to automatically delete any tuples in the table for which
there are no owners
For example - Consider following ER model,

Following SQL Statement illustrates this mapping

CREATE TABLE Department (DeptID CHAR(11),
DeptName CHAR(20),
Bldg No CHAR(5),
PRIMARY KEY (DeptID,Bldg_No),
FOREIGN KEY(Bldg_No) References Buildings on delete cascade
)

Mapping of Specialization / Generalization (EER Construct)to

Relational Mapping
The specialialization/Generalization relationship (Enhanced ER Construct) can
be mapped to database tables(relations) using three methods. To demonstrate
the methods, we will take the - InventoryItem, Book, DVD
Method 1: All the entities in the relationship are mapped to individual tables
InventoryItem(ID, name)
Book(ID,Publisher)
DVD(ID, Manufacturer)
Method 2: Only subclasses are mapped to tables. The attributes in the
superclass are duplicated in all subclasses. For example -
Book(ID,name, Publisher)
DVD(ID, name, Manufacturer)
Method 3: Only the superclass is mapped to a table. The attributes in the
subclasses are taken to the superclass. For example -
InventoryItem(ID, name, Publisher, Manufacturer)
This method will introduce null values. When we insert a Book record in the
table, the Manufacturer column value will be null. In the same way, when we
insert a DVD record in the table, the Publisher value will be null.

3)Normal Forms
• Normalization is the process of reorganizing data in a database so that it meets
two basic requirements:
1) There is no redundancy of data (all data is stored in only one place), and
2) data dependencies are logical (all related data items are stored together)
Need for normalization
1) It eliminates redundant data.
2) It reduces chances of data error.
3) The normalization is important because it allows database to take up less
disk space.
4) It also help in increasing the performance.
5) It improves the data integrity and consistency.

First Normal Form

The table is said to be in 1NF if it follows following rules –
i) It should only have single (atomic) valued attributes/columns.
ii) Values stored in a column should be of the same domain
iii) All the columns in a table should have unique names.
iv) And the order in which data is stored, does not matter.
Consider following Student table
Student

As there are multiple values of phone number for sid 1 and 3, the above table is
not in 1NF. We can make it in 1NF. The conversion is as follows -

Second Normal Form

Before understanding the second normal form let us first discuss the concept of
j functional dependency and prime and non prime attributes.
Concept of Partial Functional Dependency
Partial dependency means that a nonprime attribute is functionally dependent on
part of a candidate key.
For example: Consider a relation R(A,B,C,D) with functional dependency
{AB->CD,A->C}
Here (AB) is a candidate key because
(AB)+ = {ABCD} = {R}
Hence {A,B) are prime attributes and {C,D) are non prime attribute. In A->C,
the non prime attribute C is dependent upon A which is actually a part of
candidate key AB. Hence due to A->C we get partial functional dependency.
Prime and Non Prime Attributes
• Prime attribute: An attribute, which is a part of the candidate-key, is known
as a prime attribute.
• Non-prime attribute: An attribute, which is not a part of the prime-key, is
said to be a non-prime attribute.
• Example : Consider a Relation R ={A,B,C,D) and candidate key as AB, the
Prime attributes: A, B
Non Prime attributes: C, D
The Second Normal Form
For a table to be in the Second Normal Form, following conditions must be
followed
i) It should be in the First Normal form.
ii) It should not have partial functional dependency.
For example: Consider following table in which every information about a the
Student is maintained in a table such as student id(sid), student name(sname),
course id(cid) and course name(cname).
Student_Course

This table is not in 2NF. For converting above table to 2NF we must follow the
following steps -
Step 1: The above table is in 1NF.
Step 2: Here sname and sid are associated similarly cid and cname are
associated with each other. Now if we delete a record with sid=2, then
automatically the course C++ will also get deleted. Thus,
sid->sname or cid->cname is a partial functional dependency, because {sid,cid}
should be essentially a candidate key for above table. Hence to bring the above
table to 2NF we must decompose it as follows:
Student:

Course:
Thus now table is in 2NF as there is no partial functional dependency

Third Normal Form

Before understanding the third normal form let us first discuss the concept of
transitive dependency, super key and candidate key.
Concept of Transitive Dependency
A functional dependency is said to be transitive if it is indirectly formed by two
functional dependencies. For example -
X -> Z is a transitive dependency if the following functional dependencies hold
true:
X->Y
Y->Z
Concept of Super key and Candidate Key
Superkey: A super key is a set or one of more columns (attributes) to uniquely
identify rows in a table.
Candidate key: The minimal set of attribute which can uniquely identify a
tuple is known as candidate key. For example consider following table:

Superkeys
• {RegID}
• {RegID, RollNo}
• {RegID,Sname}
• {RollNo,Sname}
• {RegID, RollNo,Sname}
Candidate Keys
• {RegID}
• {RollNo}
Third Normal Form
A table is said to be in the Third Normal Form when,
i) It is in the Second Normal form.(i.e. it does not have partial functional
dependency)
ii) It doesn't have transitive dependency.
Or in other words
In other words 3NF can be defined as: A table is in 3NF if it is in 2NF and for
each functional dependency
X-> Y
at least one of the following conditions hold :
i) X is a super key of table
ii) Y is a prime attribute of table
For example: Consider following table Student_details as follows -

Here
Super keys: {sid}, {sid,sname}, {sid,sname,zipcode},
{sid,zipcode,cityname}... and so on.
Candidate keys:{sid}
Non-Prime attributes: {sname,zipcode,cityname,state}
The dependencies can be denoted as,
sid->sname
sid->zipcode
zipcode->cityname
cityname->state
The above denotes the transitive dependency. Hence above table is not in 3NF.
We can convert it into 3NF as follows:
Student

Zip
Multivalued Dependencies and Fourth Normal Form
• A table is said to have multi-valued dependency, if the following conditions
are true,
1) For a dependency A→B, if for a single value of A, multiple values of B
exists, then the table may have multi-values dependency.
2) Also, a table should have at-least 3 columns for it to have a multi-valued
dependency.
3) And, for a relation R(A,B,C), if there is a multi-valued dependency between,
A and B, then B and C should be independent of each other.
Fourth Normal Form
Definition: For a table to satisfy the Fourth Normal Form, it should satisfy the
following two conditions:
1) It should be in the Boyce-Codd Normal Form(BCNF).
2) And, the table should not have any multi-valued dependency.
For example: Consider following student relation which is not in 4NF as it
contains multivalued dependency.
Student Table

Now to convert the above table to 4NF we must decompose the table into
following two tables.
Student_Course Table
Key: (sid,Course)
Student Skill Table
Key: (sid, Skill)

4)Boyce / Codd Normal Form (BCNF)

Boyce and Codd Normal Form is a higher version of the Third Normal form.
This form deals with certain type of anomaly that is not handled by 3NF.
A 3NF table which does not have multiple overlapping candidate keys is said to
be in BCNF.
Or in other words,
For a table to be in BCNF, following conditions must be satisfied:
i) R must be in 3rd Normal Form
ii) For each functional dependency (X → Y), X should be a super Key. In
simple words if Y is a prime attribute then X can not be non prime attribute.
For example - Consider following table that represents that a Student enrollment
for the course -
Enrollment Table

From above table following observations can be made:

• One student can enroll for multiple courses. For example student with sid=1
can enroll for C as well as Java.
• For each course, a teacher is assigned to the student.
• There can be multiple teachers teaching one course for example course C can
be taught by both the teachers namely - Ankita and Archana.
• The candidate key for above table can be (sid,course), because using these two
columns we can find
• The above table holds following dependencies,
• (sid,course)->Teacher
• Teacher->courseann
• The above table is not in BCNF because of the dependency teacher->course.
Note NS that the teacher is not a superkey or in other words, teacher is a non
prime attribute and course is a prime attribute and non-prime attribute derives
the prime attribute.
• To convert the above table to BCNF we must decompose above table into
Student and Course tables
Student

Course

Now the table is in BCNF