Neetu Bansla DBMS 18CSC303J

Unit-2
Topics covered: Database design, Design process, ER model/diagram, Keys, Attributes,
Constraints, Mapping cardinality, Extended ER diagram, Generalization, Specialization &
Aggregation, ER diagram issues, Weak entity, Relational modal, Conversion of ER to relational
table.

1. Database Design

What is Database Design?

Database design can be generally defined as a collection of tasks or processes that enhance
the designing, development, implementation, and maintenance of enterprise data
management system. Designing a proper database reduces the maintenance cost thereby
improving data consistency and the cost-effective measures are greatly influenced in terms
of disk storage space. Therefore, there has to be a brilliant concept of designing a database.
The designer should follow the constraints and decide how the elements correlate and what
kind of data must be stored.

The main objectives behind database designing are to produce physical and logical design
models of the proposed database system. To elaborate this, the logical model is primarily
concentrated on the requirements of data and the considerations must be made in terms of
monolithic considerations and hence the stored physical data must be stored independent
of the physical conditions. On the other hand, the physical database design model includes a
translation of the logical design model of the database by keep control of physical media
using hardware resources and software systems such as Database Management System
(DBMS).

Why is Database Design important?

The important consideration that can be taken into account while emphasizing the
importance of database design can be explained in terms of the following points given below.

1. Database designs provide the blueprints of how the data is going to be stored in a
system. A proper design of a database highly affects the overall performance of any
application.
2. The designing principles defined for a database give a clear idea of the behavior of
any application and how the requests are processed.
3. Another instance to emphasize the database design is that a proper database design
meets all the requirements of users.

1
Neetu Bansla DBMS 18CSC303J

4. Lastly, the processing time of an application is greatly reduced if the constraints of

designing a highly efficient database are properly implemented.

Life Cycle

Requirement Analysis

First of all, the planning has to be done on what are the basic requirements of the project
under which the design of the database has to be taken forward. Thus, they can be defined
as:-

Planning - This stage is concerned with planning the entire DDLC (Database Development
Life Cycle). The strategic considerations are taken into account before proceeding.

System definition - This stage covers the boundaries and scopes of the proper database
after planning.

Database Designing

The next step involves designing the database considering the user-based requirements and
splitting them out into various models so that load or heavy dependencies on a single aspect
are not imposed. Therefore, there has been some model-centric approach and that's where
logical and physical models play a crucial role.

Physical Model - The physical model is concerned with the practices and implementations
of the logical model.

Logical Model - This stage is primarily concerned with developing a model based on the
proposed requirements. The entire model is designed on paper without any implementation
or adopting DBMS considerations.

2
Neetu Bansla DBMS 18CSC303J

Implementation

The last step covers the implementation methods and checking out the behavior that
matches our requirements. It is ensured with continuous integration testing of the database
with different data sets and conversion of data into machine understandable language. The
manipulation of data is primarily focused on these steps where queries are made to run and
check if the application is designed satisfactorily or not.

Data conversion and loading - This section is used to import and convert data from the old
to the new system.

Testing - This stage is concerned with error identification in the newly implemented system.
Testing is a crucial step because it checks the database directly and compares the
requirement specifications.

2. Database Design Process

The process of designing a database carries various conceptual approaches that are needed
to be kept in mind. An ideal and well-structured database design must be able to:

1. Save disk space by eliminating redundant data.

2. Maintains data integrity and accuracy.
3. Provides data access in useful ways.
4. Comparing Logical and Physical data models.

Logical

A logical data model generally describes the data in as many details as possible, without
having to be concerned about the physical implementations in the database. Features of
logical data model might include:

1. All the entities and relationships amongst them.

2. Each entity has well-specified attributes.
3. The primary key for each entity is specified.
4. Foreign keys which are used to identify a relationship between different entities are
specified.
5. Normalization occurs at this level.

3
Neetu Bansla DBMS 18CSC303J

3. Entity –Relationship Modal

ER Model - Basic Concepts

The ER model defines the conceptual view of a database. It works around real-world entities
and the associations among them. At view level, the ER model is considered a good option
for designing databases.

Entity
An entity can be a real-world object, either animate or inanimate, that can be easily
identifiable. For example, in a school database, students, teachers, classes, and courses
offered can be considered as entities. All these entities have some attributes or properties
that give them their identity.
An entity set is a collection of similar types of entities. An entity set may contain entities
with attribute sharing similar values. For example, a Students set may contain all the
students of a school; likewise a Teachers set may contain all the teachers of a school from
all faculties. Entity sets need not be disjoint.

Attributes
Entities are represented by means of their properties, called attributes. All attributes have
values. For example, a student entity may have name, class, and age as attributes.
There exists a domain or range of values that can be assigned to attributes. For example, a
student's name cannot be a numeric value. It has to be alphabetic. A student's age cannot be
negative, etc.

Types of Attributes
• Simple attribute − Simple attributes are atomic values, which cannot be divided
further. For example, a student's phone number is an atomic value of 10 digits.
• Composite attribute − Composite attributes are made of more than one simple
attribute. For example, a student's complete name may have first_name and
last_name.
• Derived attribute − Derived attributes are the attributes that do not exist in the
physical database, but their values are derived from other attributes present in the
database. For example, average_salary in a department should not be saved directly
in the database, instead it can be derived. For another example, age can be derived
from data_of_birth.
• Single-value attribute − Single-value attributes contain single value. For example −
Social_Security_Number.

4
Neetu Bansla DBMS 18CSC303J

• Multi-value attribute − Multi-value attributes may contain more than one values.
For example, a person can have more than one phone number, email_address, etc

Entity-Set and Keys

Key is an attribute or collection of attributes that uniquely identifies an entity among entity
set.
For example, the roll_number of a student makes him/her identifiable among students.
• Super Key − A set of attributes (one or more) that collectively identifies an entity in
an entity set.
• Candidate Key − A minimal super key is called a candidate key. An entity set may
have more than one candidate key.
• Primary Key − A primary key is one of the candidate keys chosen by the database
designer to uniquely identify the entity set.

Relationship
The association among entities is called a relationship. For example, an
employee works_at a department, a student enrolls in a course. Here, Works_at and
Enrolls are called relationships.

Relationship Set
A set of relationships of similar type is called a relationship set. Like entities, a relationship
too can have attributes. These attributes are called descriptive attributes.

Degree of Relationship
The number of participating entities in a relationship defines the degree of the relationship.

• Binary = degree 2
• Ternary = degree 3
• n-ary = degree

Mapping Cardinalities
Cardinality defines the number of entities in one entity set, which can be associated with
the number of entities of other set via relationship set.
• One-to-one − One entity from entity set A can be associated with at most one entity
of entity set B and vice versa.

5
Neetu Bansla DBMS 18CSC303J

• One-to-many − One entity from entity set A can be associated with more than one
entities of entity set B however an entity from entity set B, can be associated with at
most one entity.

• Many-to-one − More than one entities from entity set A can be associated with at
most one entity of entity set B, however an entity from entity set B can be associated
with more than one entity from entity set A.

• Many-to-many − One entity from A can be associated with more than one entity
from B and vice versa.

6
Neetu Bansla DBMS 18CSC303J

Let us now learn how the ER Model is represented by means of an ER diagram. Any object,
for example, entities, attributes of an entity, relationship sets, and attributes of relationship
sets, can be represented with the help of an ER diagram.

Entity
Entities are represented by means of rectangles. Rectangles are named with the entity set
they represent.

Attributes
Attributes are the properties of entities. Attributes are represented by means of ellipses.
Every ellipse represents one attribute and is directly connected to its entity (rectangle).

If the attributes are composite, they are further divided in a tree like structure. Every node
is then connected to its attribute. That is, composite attributes are represented by ellipses
that are connected with an ellipse.

7
Neetu Bansla DBMS 18CSC303J

Multivalued attributes are depicted by double ellipse.

Derived attributes are depicted by dashed ellipse.

Relationship
Relationships are represented by diamond-shaped box. Name of the relationship is written
inside the diamond-box. All the entities (rectangles) participating in a relationship, are
connected to it by a line.

8
Neetu Bansla DBMS 18CSC303J

4. Binary Relationship and Cardinality

A relationship where two entities are participating is called a binary relationship.
Cardinality is the number of instance of an entity from a relation that can be associated with
the relation.
• One-to-one − when only one instance of an entity is associated with the relationship,
it is marked as '1:1'. The following image reflects that only one instance of each entity
should be associated with the relationship. It depicts one-to-one relationship.

• One-to-many − when more than one instance of an entity is associated with a

relationship, it is marked as '1: N'. The following image reflects that only one instance
of entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts one-to-many relationship.

• Many-to-one − when more than one instance of entity is associated with the
relationship, it is marked as 'N:1'. The following image reflects that more than one
instance of an entity on the left and only one instance of an entity on the right can be
associated with the relationship. It depicts many-to-one relationship.

9
Neetu Bansla DBMS 18CSC303J

• Many-to-many − The following image reflects that more than one instance of an
entity on the left and more than one instance of an entity on the right can be
associated with the relationship. It depicts many-to-many relationship.

Participation Constraints
• Total Participation − each entity is involved in the relationship. Total participation
is represented by double lines.
• Partial participation − Not all entities are involved in the relationship. Partial
participation is represented by single lines.

10
Neetu Bansla DBMS 18CSC303J

Example of an ER-Diagram

• Hospital Management System

11
Neetu Bansla DBMS 18CSC303J

• Airline Reservation System

5. Extended ER-Diagram (EER)

EER is a high-level data model that incorporates the extensions to the original ER model.
Enhanced ERD are high level models that represent the requirements and complexities
of complex database.

In addition to ER model concepts EE-R includes −

• Subclasses and Super classes.

• Specialization and Generalization.

12
Neetu Bansla DBMS 18CSC303J

• Category or union type.

• Aggregation.
These concepts are used to create EE-R diagrams.

Subclasses and Super class

Super class is an entity that can be divided into further subtype.

For example − consider Shape super class.

Super class shape has sub groups: Triangle, Square and Circle.

Sub classes are the group of entities with some unique attributes. Sub class inherits the
properties and attributes from super class.

6. Specialization and Generalization

Generalization –
Generalization is the process of extracting common properties from a set of entities and
creates a generalized entity from it. It is a bottom-up approach in which two or more
entities can be generalized to a higher level entity if they have some attributes in
common. For Example, STUDENT and FACULTY can be generalized to a higher level
entity called PERSON as shown in Figure 1. In this case, common attributes like
P_NAME, P_ADD become part of higher entity (PERSON) and specialized attributes like
S_FEE become part of specialized entity (STUDENT).

13
Neetu Bansla DBMS 18CSC303J

Specialization –
In specialization, an entity is divided into sub-entities based on their characteristics. It is
a top-down approach where higher level entity is specialized into two or more lower
level entities. For Example, EMPLOYEE entity in an Employee management system can be
specialized into DEVELOPER, TESTER etc. as shown in Figure 2. In this case, common
attributes like E_NAME, E_SAL etc. become part of higher entity (EMPLOYEE) and
specialized attributes like TES_TYPE become part of specialized entity (TESTER).

14
Neetu Bansla DBMS 18CSC303J

7. Aggregation
An ER diagram is not capable of representing relationship between an entity and a
relationship which may be required in some scenarios. In those cases, a relationship
with its corresponding entities is aggregated into a higher level entity. Aggregation is
an abstraction through which we can represent relationships as higher level entity
sets.
For Example, Employee working for a project may require some machinery. So,
REQUIRE relationship is needed between relationship WORKS_FOR and entity
MACHINERY. Using aggregation, WORKS_FOR relationship with its entities
EMPLOYEE and PROJECT is aggregated into single entity and relationship REQUIRE is
created between aggregated entity and MACHINERY.

8. ER Design Issues

Here, we will discuss the basic design issues of an ER database schema in the following
points:

o Use of Entity Set vs. attributes

• The use of an entity set or attribute depends on the structure of the real-world
enterprise that is being modeled and the semantics associated with its attributes. It
leads to a mistake when the user use the primary key of an entity set as an attribute
of another entity set. Instead, he should use the relationship to do so. Also, the
primary key attributes are implicit in the relationship set, but we designate it in the
relationship sets.
15
Neetu Bansla DBMS 18CSC303J

o Use of Entity Set vs. Relationship Sets

• It is difficult to examine if an object can be best expressed by an entity set or
relationship set. To understand and determine the right use, the user need to
designate a relationship set for describing an action that occurs in-between the
entities. If there is a requirement of representing the object as a relationship set, then
it’s better not to mix it with the entity set.

o Use of Binary vs. n-ary Relationship Sets

• Generally, the relationships described in the databases are binary relationships.
However, non-binary relationships can be represented by several binary
relationships. For example, we can create and represent a ternary relationship
'parent' that may relate to a child, his father, as well as his mother. Such relationship
can also be represented by two binary relationships i.e., mother and father that may
relate to their child. Thus, it is possible to represent a non-binary relationship by a set
of distinct binary relationships.

o Placing Relationship Attributes

• The cardinality ratios can become an affective measure in the placement of the
relationship attributes. So, it is better to associate the attributes of one-to-one or one-
to-many relationship sets with any participating entity sets, instead of any
relationship set. The decision of placing the specified attribute as a relationship or
entity attribute should possess the characteristics of the real world enterprise that is
being modeled.

For example, if there is an entity which can be determined by the combination of

participating entity sets, instead of determining it as a separate entity. Such type of attribute
must be associated with the many-to-many relationship sets.

Thus, it requires the overall knowledge of each part that is involved in designing and
modeling an ER diagram. The basic requirement is to analyze the real-world enterprise and
the connectivity of one entity or attribute with other.

9. Types of DBMS Entities

The following are the types of entities in DBMS −

16
Neetu Bansla DBMS 18CSC303J

Strong Entity
The strong entity has a primary key. Weak entities are dependent on strong entity. Its
existence is not dependent on any other entity.

Strong Entity is represented by a single rectangle −

Continuing our previous example, Professor is a strong entity here, and the primary key
is Professor_ID.

Weak Entity
A weak entity in DBMS does not have a primary key and are dependent on the parent entity.
It mainly depends on other entities.

Weak Entity is represented by double rectangle −

Continuing our previous example, Professor is a strong entity, and the primary key
is Professor_ID. However, another entity is Professor_Dependents, which is our Weak
Entity.

<Professor_Dependents>

17
Neetu Bansla DBMS 18CSC303J

Name DOB Relation

This is a weak entity since its existence is dependent on another entity Professor, which we
saw above. A Professor has Dependents.

Example of Strong and Weak Entity

The example of a strong and weak entity can be understood by the below figure.

The Strong Entity is Professor, whereas Dependent is a Weak Entity.

ID is the primary key (represented with a line) and the Name in Dependent entity is
called Partial Key (represented with a dotted line).

10. 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:

18
Neetu Bansla DBMS 18CSC303J

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.

19
Neetu Bansla DBMS 18CSC303J

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:

20