Database Design and the E-R Model:

ER model in DBMS is the high-level data model. It stands for the Entity-relationship model and is used
to represent a logical view of the system from a data perspective.

An ER diagram in DBMS defines entities, associated attributes, and relationships between entities.
This helps visualize the logical structure of the database.

Entity:
An entity is referred to as an object or thing that exists in the real world. For example, customer, car,
pen, etc.

Entity Type:
A collection of entities with general characteristics is known as an entity type.
1. Strong Entity Type: It is an entity that has its own existence and is independent.

2. Weak Entity Type: It is an entity that does not have its own existence and relies on a strong entity
for its existence.

Entity Set
An entity set is a group of entities of the same entity type.
For example, an entity set of students, an entity set of motorbikes, an entity of smartphones, an
entity of customers, etc.

Attributes:

In a Database Management System (DBMS), an attribute is a property or characteristic of an entity

that is used to describe an entity.
Types of Attributes in ER Model

 Simple Attribute
 Composite Attribute
 Single-Valued Attribute
 Multi-Valued Attribute
 Derived Attribute
 Complex Attribute
 Key Attribute
 Null Attribute
 1.Simple Attribute
An attribute that cannot be further undivided into components is a simple attribute.
2.Composite Attribute
An attribute that can be split into components is a composite attribute.

3. Single-Valued Attribute
The attribute which takes up only a single value for each entity instance is a single-valued
attribute.
Example: The age of a student, Aadhar card number.

4. Multi-Valued Attribute
The attribute which takes up more than a single value for each entity instance is a multi-valued
attribute. And it is represented by double oval shape.

5.Derived Attribute
An attribute that can be derived from other attributes is derived attributes. And it is represented by
dotted oval shape.

6.Complex Attribute
 Those attributes, which can be formed by the nesting of composite and multi-valued attributes, are
called “Complex Attributes“.

7. Key attribute
Key attributes are those attributes that can uniquely identify the entity in the entity set.
Example: Roll-No is the key attribute because it can uniquely identify the student.

8. Null Attribute
This attribute can take NULL value when entity does not have value for it.
Example –The ‘Net Banking Active Bin’ attribute gives weather particular customer having net
banking facility activated or not activated.

What is Relationship in DBMS?

A relationship in DBMS is association between two or more entities. Entities are the real world
objects which hold data, participate in these relationships. Connection between different entities
are represented by a diamond shapes in ER (entity relationship) diagrams.

Types of Relationships in DBMS

There are three primary types of relationships in DBMS. Each type of relationship plays a unique
role in database design.
 One-to-One relationship
 One-to-Many or Many-to-One relationship
 Many-to-Many relationship
One-to-One Relationship
In one-to-one relationship a single record in one table is related with a single record in other table
and vice versa.

One-to-Many or Many-to-One Relationship

In one-to-many or many-to-one relationship, a single record in one table can be associated with
multiple records in another table and this is the most common type of relationship in DBMS.

Many-to-Many Relationship
A many-to-many relationship is relationship in which one multiple records in one table are
associated with multiple records in another table.
 Self-Referencing Relationships
A self-referencing relationship is also known as recursive relationship and it is useful is cases when
a table has relationship with itself.

Degree of Relationship

In DBMS, a degree of relationship represents the number of entity types that are associated with a
relationship.
Types of degree
1. Unary
2. Binary
3. Ternary
4. N-ary
Unary (Degree 1)
In this type of relationship, both the associating entity types are the same.

Binary (Degree 2)
Binary relationship exists when there are two types of entity and we call them a degree of
relationship is 2.

Ternary (Degree 3)
In the Ternary relationship, there are three types of entity associates.
we call them a degree of relationship is 3.

N-ary (n Degree)
In the N-ary relationship, there are n types of entity that associates. So, we can say that an N-ary
relationship exists when there are n types of entities.
ER (Entity-Relationship) Diagram:

It is a graphical representation of entities and their relationship to each other. In ER diagrams,

entities are represented by rectangles and the relation between them is represented by diamond.
Draw an E-R diagram for the University Enterprise
E-R Diagram for a University Enterprise. Schema Diagram. Relational Schemas. Classroom (building,
room-number, capacity) Department (dept-name, building, budget) Course (course- id, title, dept-
name, credits) Instructor (id, name, depart-name, salary) Student (ID, Name, Tot- credits) Section
(sec-id, semester, year) Time-slot (time-slot-id, day,start-time, end-time). This E-R diagram is
equivalent to the textual description of the university E R model. But with several additional
constraints and section now being a weak entity. University Enterprise, have a constraint that each
instructor must have exactly one associated department.

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.
The main objectives behind database designing are to produce physical and logical design models of
the proposed database system.
 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.
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.

Implementation
The last step covers the implementation methods and checking out the behavior that matches our
requirements. 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.

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.

Constraints in DBMS:
 Relational constraints are the restrictions imposed on the database contents and operations.
 They ensure the correctness of data in the database.

Types of Constraints in DBMS-

In DBMS, there are following 5 different types of relational constraints-

1. Domain Constraint-
 Domain constraint defines the domain or set of values for an attribute.
 It specifies that the value taken by the attribute must be the atomic value from its domain.
 Example-
Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S002 Abhishek 21

S003 Shashank 20

S004 Rahul A

Here, value ‘A’ is not allowed since only integer values can be taken by the age attribute.

2. Tuple Uniqueness Constraint-

Tuple Uniqueness constraint specifies that all the tuples must be necessarily unique in any relation.
Example-01:

Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S002 Abhishek 21

S003 Shashank 20

S004 Rahul 20

This relation satisfies the tuple uniqueness constraint since here all the tuples are unique.

Key Constraint-
Key constraint specifies that in any relation-
 All the values of primary key must be unique.
 The value of primary key must not be null.

Example-
Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S001 Abhishek 21

S003 Shashank 20

S004 Rahul 20

This relation does not satisfy the key constraint as here all the values of primary key are not unique.
 4. Entity Integrity Constraint-
 Entity integrity constraint specifies that no attribute of primary key must contain a null value in any
relation.
 This is because the presence of null value in the primary key violates the uniqueness property.

Example-
Consider the following Student table-

STU_ID Name Age

S001 Akshay 20

S002 Abhishek 21

S003 Shashank 20

Rahul 20

This relation does not satisfy the entity integrity constraint as here the primary key contains a NULL
value.

5. Referential Integrity Constraint-

 This constraint is enforced when a foreign key references the primary key of a relation.
 It specifies that all the values taken by the foreign key must either be available in the relation of the
primary key or be null.

Example-
Consider the following two relations- ‘Student’ and ‘Department’.
Here, relation ‘Student’ references the relation ‘Department’.

Removing Redundant attributes in entity sets?

• Once the entities and their corresponding attributes are chosen, the relationship sets among the
various entities are formed.
• These relationship sets may result in a situation where attributes in the various entity sets are
redundant and need to be removed
• Consider the entity sets instructor and department – Instructor includes the attributes ID, name,
dept_name, and salary with ID as primary key – Department includes the attributes dept_name,
building, and budget with dept_name as primary key
• Attribute dept_name appears in both entity sets. It is primary key for entity department, it is
redundant in the entity set instructor and needs to be removed.
• If both entities have one to one relationship then we can remove it from instructor table as it will
get added up in the relational schema of department.
• But if an instructor has more than one associated department, the relationship between the
entities is recorded in a separate relation inst_dept.

How to Create an Entity Relationship Diagram (ERD)

 Following are the steps to create an ER Diagram:

Step 1) Entity Identification We have three entities

 Student
 Course
 Professor

Step 2) Relationship Identification We have the following two relationships

 The student is assigned a course
 Professor delivers a course

Step 3) Cardinality Identification For them problem statement we know that,

 A student can be assigned multiple courses
 A Professor can deliver only one course

Step 4) Identify Attributes You need to study the files, forms, reports, data currently maintained
by the organization to identify attributes. You can also conduct interviews with various stakeholders
to identify entities. Initially, it‟s important to identify the attributes without mapping them to a
particular entity. Once, you have a list of Attributes, you need to map them to the identified entities.
Ensure an attribute is to be paired with exactly one entity. If you think an attribute should belong to
more than one entity, use a modifier to make it unique. Once the mapping is done, identify the
primary Keys. If a unique key is not readily available, create one. Entity Primary Key Attribute Student
Student_ID StudentName Professor Employee_ID ProfessorName Course Course_ID CourseName.

Step 5) Create the ERD Diagram A more modern representation of Entity Relationship Diagram
Example
 REDUCTION TO RELATION SCHEMAS:
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:
 What are Entity-Relationship Design Issues
We also understood the various designing shapes that represent a
relationship, an entity and its attributes. However, users often mislead the
concept of the elements and the design process of the ER diagram. Thus, it
leads to a complex structure of the ER diagram and certain issues that does
not meet the characteristics of the real-world enterprise model. The basic
design issues of an ER database schema in the following points:
1. 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.
2. 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.
3. 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 that is 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.
4.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.
Redundancy of Schemas:
Many to many and one to many relationship sets that are total on the many side can be represented
by adding extra attribute to the many side, containing the primary key of the "one" side.
Extended Entity Relationship Model(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.
 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.

Specialization and Generalization

Generalization is a process of generalizing an entity which contains generalized attributes or

properties of generalized entities.

It is a Bottom up process i.e. consider we have 3 sub entities Car, Truck and Motorcycle. Now these
three entities can be generalized into one super class named as Vehicle.

Specialization is a process of identifying subsets of an entity that share some different characteristic.
It is a top down approach in which one entity is broken down into low level entity.

In above example Vehicle entity can be a Car, Truck or Motorcycle.

Category or Union

Relationship of one super or sub class with more than one super class.
Owner is the subset of two super class: Vehicle and House.

Aggregation

Represents relationship between a whole object and its component.

Consider a ternary relationship Works_On between Employee, Branch and Manager. Now the best
way to model this situation is to use aggregation, So, the relationship-set, Works_On is a higher level
entity-set. Such an entity-set is treated in the same manner as any other entity-set. We can create a
binary relationship, Manager, between Works_On and Manager to represent who manages what
tasks.

Notation of ER diagram
Database can be represented using the notations. In ER diagram, many notations are used to express
the cardinality. These notations are as follows:

Fig: Notations of ER diagram

Other Aspects of Database Design :

1. Data Constraints and Relational Database Design: Data constraints that

can be expressed using SQL, including primary-key constraints, foreign-key

constraints, check constraints, assertions and triggers. Constraints serve several

purposes in Database.

2. Usage Requirements: Queries, Performance: Database system performance

is a critical aspect of most enterprise information systems. Performance pertains

not only to the efficient use of the computing and storage hardware being used, but

also to the efficiency of people who interact with the system and of processes that

depend upon database data.

There are two main metrics for performance:

Throughput: The number of queries or updates (often referred to as transactions)

that can be processed on average per unit of time.

Response time: The amount of time a single transaction takes from start to finish

in either the average case or the worst case.

3. Authorization Requirements: Authorization constraints affect design of the

database as well because SQL allows access to be granted to users on the basis of

components of the logical design of the database.

4.Data Flow, Workflow: Database applications are often part of a larger enterprise application that
interacts not only with the database system but also with various specialized applications.

Features of good relational design

Good Database Design is what everyone wants to achieve to avoid the consequences of dealing
with a bad design. The following are the objectives of a good database design −
Avoid Redundant Data
The table in the database should be constructed following standards and with utmost dedication.
It should have different fields and minimize redundant data. The table should always have a
Primary Key that would be a unique id.
Faultless Information
The database should follow the standards and conventions and provide meaningful information
useful to the organization.
Data Integrity
Integrity assists in guaranteeing that the values are valid and faultless. Data Integrity is set to
tables, relationships, etc.
Modify
The database developed should be worked upon with the conventions and standards, so that it
can be easily modified whenever the need arise
Good Database Design is what everyone wants to achieve to avoid the consequences of dealing
with a bad design. The following are the objectives of a good database design −
Avoid Redundant Data
The table in the database should be constructed following standards and with utmost dedication.
It should have different fields and minimize redundant data. The table should always have a
Primary Key that would be a unique id.
Faultless Information
The database should follow the standards and conventions and provide meaningful information
useful to the organization.
Data Integrity
Integrity assists in guaranteeing that the values are valid and faultless. Data Integrity is set to
tables, relationships, etc.
Modify
The database developed should be worked upon with the conventions and standards, so that it
can be easily modified whenever the need arise

The Database Design Methodology for Relational Databases.

Database Design Methodologies has phases to guide the designer for assistance. The Methodology
has a structured approach to help in the design process.

The following are the phases/ models −

Conceptual Phase

The Conceptual phase lets you know the entities and the relation between them. It describes the
conceptual schema. The entities & relations are defined here.

Logical Phase

Logical data model provides details about the data to the physical phase. The physical process gives
ER Diagram, data dictionary, schema, etc that acts as a source for the physical design process.

Physical Phase

The physical database design allows the designer to decide on how the database will be
implemented.