Overview of Design Process

Design of the Database Schema, design of the programs that access and update the
data, design of a security scheme for controlling access to the data are all involved
in the creation of a Database. The central role in the designing process involves the
requirements of the user.

For designing a database, there are four phases, namely:

Initial Phase : The Initial Phase of database design is to fully describe the data needs of the
potential database users.

Conceptual Design Phase : The designer chooses a data model, by applying the concepts of
the data model that is chosen and translates these requirements into a conceptual schema of the
database.

A fully developed conceptual schema indicates the functional needs of the user.
Here, the users describe various operations that have to be performed on the data.

The operations can include updating, searching, retrieving and deleting data.

Logical Design Phase : The database designer plots the high-level conceptual schema onto the
implementation of the data model of the database system that has to be used.

The implementation data model is also called the relational data model.
Physical Design Phase : Here, the designer uses the resulting system-specific database schema.
In this phase, the physical features of the database are specified.
Design Alternatives :A major part of the database design process is deciding how to represent in
the design the various types of “things” such as people, places, products, and the like. We use the term
entity to refer to any such distinctly identifiable item.
In designing a database schema, we must ensure that we avoid two major pitfalls:
1. Redundancy: A bad design may repeat information. For example, if we store the course identifier
and title of a course with each course offering, the title would be stored redundantly (that is, multiple
times, unnecessarily) with each course offering.
2.Incompleteness: A bad design may make certain aspects of the enterprise difficult or impossible to
model. For example, suppose that, as in case (1) above, we only had entities corresponding to course
offering, without having an entity corresponding to courses.
Avoiding bad designs is not enough. There may be a large number of good designs from which we must
choose. As a simple example, consider a customer who buys a product. Is the sale of this product a
relationship between the customer and the product? Alternatively, is the sale itself an entity that is
related both to the customer and to the product? This choice, though simple, may make an important
difference in what aspects of the enterprise can be modeled well.

Introduction of ER Model
ER model stands for an Entity-Relationship model. ER Model is used to model the logical
view of the system from data perspective which consists of these components:
Entity, Entity Type, Entity Set –
An Entity may be an object with a physical existence – a particular person, car, house, or
employee – or it may be an object with a conceptual existence – a company, a job, or a university
course.
An Entity is an object of Entity Type and set of all entities is called as entity set. e.g.; E1 is an
entity having Entity Type Student and set of all students is called Entity Set. In ER diagram,
Entity Type is represented as:
Attribute(s):
Attributes are the properties which define the entity type. For example, Roll_No, Name, DOB,
Age, Address, Mobile_No are the attributes which defines entity type Student. In ER diagram,
attribute is represented by an oval.

1. Key Attribute –
The attribute which uniquely identifies each entity in the entity set is called key attribute.For
example, Roll_No will be unique for each student. In ER diagram, key attribute is represented by
an oval with underlying lines.
2. Composite Attribute –
An attribute composed of many other attribute is called as composite attribute. For example,
Address attribute of student Entity type consists of Street, City, State, and Country. In ER
diagram, composite attribute is represented by an oval comprising of ovals.

3. Multivalued Attribute –
An attribute consisting more than one value for a given entity. For example, Phone_No (can be
more than one for a given student). In ER diagram, multivalued attribute is represented by
double oval.

4. Derived Attribute –
An attribute which can be derived from other attributes of the entity type is known as derived
attribute. e.g.; Age (can be derived from DOB). In ER diagram, derived attribute is represented
by dashed oval.

The complete entity type Student with its attributes can be represented as:
Relationship Type and Relationship Set:
A relationship type represents the association between entity types. For example,‘Enrolled in’
is a relationship type that exists between entity type Student and Course. In ER diagram,
relationship type is represented by a diamond and connecting the entities with lines.

A set of relationships of same type is known as relationship set. The following relationship set
depicts S1 is enrolled in C2, S2 is enrolled in C1 and S3 is enrolled in C3.
Degree of a relationship set:
The number of different entity sets participating in a relationship set is called as degree of a
relationship set.
1. Unary Relationship –
When there is only ONE entity set participating in a relation, the relationship is called as
unary relationship. For example, one person is married to only one person.

2. Binary Relationship –
When there are TWO entities set participating in a relation, the relationship is called as binary
relationship.For example, Student is enrolled in Course.
3. n-ary Relationship –
When there are n entities set participating in a relation, the relationship is called as n-ary
relationship.

Cardinality:
The number of times an entity of an entity set participates in a relationship set is known as
cardinality. Cardinality can be of different types:
1. One to one – When each entity in each entity set can take part only once in the relationship,
the cardinality is one to one. Let us assume that a male can marry to one female and a female can
marry to one male. So the relationship will be one to one.

Using Sets, it can be represented as:

2. Many to one – When entities in one entity set can take part only once in the relationship
set and entities in other entity set can take part more than once in the relationship
set, cardinality is many to one. Let us assume that a student can take only one course but one
course can be taken by many students. So the cardinality will be n to 1. It means that for one
course there can be n students but for one student, there will be only one course.
Using Sets, it can be represented as:

In this case, each student is taking only 1 course but 1 course has been taken by many students.
3. Many to many – When entities in all entity sets can take part more than once in the
relationship cardinality is many to many. Let us assume that a student can take more than one
course and one course can be taken by many students. So the relationship will be many to many.

Using sets, it can be represented as:

In this example, student S1 is enrolled in C1 and C3 and Course C3 is enrolled by S1, S3 and S4.
So it is many to many relationships.
Participation Constraint:
Participation Constraint is applied on the entity participating in the relationship set.
1. Total Participation – Each entity in the entity set must participate in the relationship. If
each student must enroll in a course, the participation of student will be total. Total participation
is shown by double line in ER diagram.
2. Partial Participation – The entity in the entity set may or may NOT participate in the
relationship. If some courses are not enrolled by any of the student, the participation of course
will be partial.
The diagram depicts the ‘Enrolled in’ relationship set with Student Entity set having total
participation and Course Entity set having partial participation.

Using set, it can be represented as,

Every student in Student Entity set is participating in relationship but there exists a course C4
which is not taking part in the relationship.
Entity Sets: An entity is a “thing” or “object” in the real world that is distinguishable from all other
objects. For example, each person in a university is an entity. An entity has a set of properties, and the
values for some set of properties may uniquely identify an entity.

Weak Entity Type and Identifying Relationship:

As discussed before, an entity type has a key attribute which uniquely identifies each entity in
the entity set. But there exists some entity type for which key attribute can’t be defined.
These are called Weak Entity type.
For example, A company may store the information of dependents (Parents, Children, Spouse) of
an Employee. But the dependents don’t have existence without the employee. So Dependent will
be weak entity type and Employee will be Identifying Entity type for Dependent.
A weak entity type is represented by a double rectangle. The participation of weak entity type is
always total. The relationship between weak entity type and its identifying strong entity type is
called identifying relationship and it is represented by double diamond.