DATABASE DESIGN USING E-R MODEL
OVERVIEW OF THE DESIGN PROCESS
The database design process can be divided into six steps. The ER Model is most
relevant to the first three steps. Next three steps are beyond the ER Model
1. Requirements Analysis: The very first step in designing a database application is to
understand what data is to be stored in the database, what applications must be built
on top of it, and what operations are most frequent and subject to performance
requirements. The database designers collect information of the organization and
analyzer, the information to identify the user’s requirements. The database designers
must find out what the users want from the database.
2. Conceptual Database Design: Once the information is gathered in the requirements
analysis step a conceptual database design is developed and is used to develop a high-
level description of the data to be stored in the database, along with the constraints
that are known to hold over this data. This step is often carried out using the ER
model, or a similar high-level data model.
3. Logical Database Design: In this step convert the conceptual database design into a
database schema (Logical Database Design) in the data model of the chosen DBMS.
We will only consider relational DBMSs, and therefore, the task in the logical design
step is to convert an ER schema into a relational database schema. The result is a
conceptual schema, sometimes called the logical schema, in the relational data model.
2.2.1 Beyond the ER Design
The first three steps are more relevant to the ER Model. Once the logical scheme is
defined designer consider the physical level implementation and finally provide certain
security measures. The remaining three steps of database design are briefly described below:
4. Schema Refinement: The fourth step in database design is to analyze the collection
of relations in our relational database schema to identify potential problems, and to
refine it. In contrast to the requirements analysis and conceptual design steps, which
are essentially subjective, schema refinement can be guided by some elegant and
powerful theory.
5. Physical Database Design: In this step we must consider typical expected workloads
that our database must support and further refine the database design to ensure that it
meets desired performance criteria. This step may simply involve building indexes on
some tables and clustering some tables, or it may involve a substantial redesign of
parts of the database schema obtained from the earlier design steps.
6. Security Design: The last step of database design is to include security features. This is
required to avoid unauthorized access to database practice after all the six steps. We
required Tuning step in which all the steps are interleaved and repeated until the design
is satisfactory.
The Entity Relationship Model
Peter Chen developed the ER diagram in 1976. The ER model was created
to provide a simple and understandable model for representing the
structure and logic of databases.
The Entity Relationship Diagram explains the relationship among the
entities present in the database. ER models are used to model real-world
objects like a person, a car, or a company and the relation between these
real-world objects. In short, the ER Diagram is the structural format of
the database.
Why Use ER Diagrams In DBMS?
ER diagrams represent the E-R model in a database, making them easy
to convert into relations (tables).
ER diagrams provide the purpose of real-world modeling of objects
which makes them intently useful.
ER diagrams require no technical knowledge and no hardware support.
These diagrams are very easy to understand and easy to create even for
a naive user.
It gives a standard solution for visualizing the data logically.
Symbols Used in ER Model
Rectangles: Rectangles represent Entities in the ER Model.
Ellipses: Ellipses represent Attributes in the ER Model.
Diamond: Diamonds represent Relationships among Entities.
Lines: Lines represent attributes to entities and entity sets with other
relationship types.
Double Ellipse: Double Ellipses represent Multi-Valued Attributes.
Double Rectangle: Double Rectangle represents a Weak Entity.
Components of ER Diagram
ER Model consists of Entities, Attributes, and Relationships among Entities in a Database System.
What is Entity?
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.
What is Entity Set?
An Entity is an object of Entity Type and a set of all entities is called an entity set. For Example, E1 is
an entity having Entity Type Student and the set of all students is called Entity Set. In ER diagram,
Entity Type is represented as:
Entity Set
We can represent the entity set in ER Diagram but can’t represent entity in ER Diagram because
entity is row and column in the relation and ER Diagram is graphical representation of data.
Types of Entity
There are two types of entity:
1. Strong Entity
A Strong Entity is a type of entity that has a key Attribute. Strong Entity does not depend on other
Entity in the Schema. It has a primary key, that helps in identifying it uniquely, and it is represented
by a rectangle. These are called Strong Entity Types.
2. Weak Entity
An Entity type has a key attribute that uniquely identifies each entity in the entity set. But some
entity type exists for which key attributes can’t be defined. These are called Weak Entity types .
For Example, A company may store the information of dependents (Parents, Children, Spouse) of an
Employee. But the dependents can’t exist without the employee. So Dependent will be a Weak
Entity Type and Employee will be Identifying Entity type for Dependent, which means it is Strong
Entity Type .
A weak entity type is represented by a Double Rectangle. The participation of weak entity types is
always total. The relationship between the weak entity type and its identifying strong entity type is
called identifying relationship and it is represented by a double diamond.
Strong Entity and Weak Entity
What is Attributes?
Attributes are the properties that define the entity type. For example, Roll_No, Name, DOB, Age,
Address, and Mobile_No are the attributes that define entity type Student. In ER diagram, the
attribute is represented by an oval.
Attribute
Types of Attributes
There are different types of attributes as discussed below-
Simple Attribute
Composite Attribute
Single-Valued Attribute
Multi-Valued Attribute
Derived Attribute
Complex Attribute
Stored Attribute
Key Attribute
Null Attribute
Descriptive Attribute
Let’s discuss each one by one:
1. Simple Attribute
An attribute that cannot be further subdivided into components is a simple attribute.
Example: The roll number of a student, the ID number of an employee, gender, and many more.
Simple Attribute
2.Composite Attribute
An attribute that can be split into components is a composite attribute.
Example: The address can be further split into house number, street number, city, state, country, and
pin code, the name can also be split into first name middle name, and last name.
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.
Single-Valued
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.
Example: Phone number of a student: Landline and mobile.
Multi-valued
5. Stored Attribute
The stored attribute are those attribute which doesn’t require any type of further update since they
are stored in the database.
Example: DOB(Date of birth) is the stored attribute.
Stored-attribute
6. Derived Attribute
An attribute that can be derived from other attributes is derived attributes. And it is represented by
dotted oval shape.
Example: Total and average marks of a student, age of an employee that is derived from date of
birth.
Derived-attribute
7. Complex Attribute
Those attributes, which can be formed by the nesting of composite and multi-valued attributes, are
called “Complex Attributes“. These attributes are rarely used in DBMS(DataBase Management
System). That’s why they are not so popular.
Example: Address because address contain composite value like street, city, state, PIN code and also
multivalued because one people has more that one house address.
Complex-attribute
Representation
Complex attributes are the nesting of two or more composite and multi-valued attributes. Therefore,
these multi-valued and composite attributes are called ‘Components’ of complex attributes
Relationships in ER diagrams
When designing a database model, creating relationships between tables is essential for organizing
data and ensuring data integrity. Relationships are the connections between tables that establish
how data in one table is related to data in another table. In this article, we will explore how to
create relationships in a database model and why they are important.
Types of Relationships in ER diagrams
There are three main types of relationships in a database model: one-to-one, one-to-many, and
many-to-many.
In a one-to-one relationship, each record in one table is associated with one and only one
record in another table.
In a one-to-many relationship, each record in one table can be associated with one or many
records in another table.
In a many-to-many relationship, each record in one table can be associated with many
records in another table, and vice versa.
Creating Relationships in ER diagrams
To create a relationship between two tables, you need to identify the primary key in one table and the
foreign key in the other table. The primary key is a unique identifier for each record in a table, while
the foreign key is a field in another table that references the primary key. You can create relationships
in a database model using SQL commands or using a database tool, incl. database modeling or
database design tool.
Benefits of Relationships
Creating relationships in a database model has several benefits.
First, it helps to eliminate data redundancy and inconsistency by ensuring that each piece of
data is only stored once in the database.
Second, it helps to maintain data integrity by enforcing referential integrity constraints that
prevent the creation of orphaned records.
Third, it allows for efficient querying and retrieval of data by allowing you to retrieve related
data from multiple tables with a single query.
Degree of a Relationship Set
The number of different entity sets participating in a relationship set is called
the degree of a relationship set.
1. Unary Relationship: When there is only ONE entity set participating in a
relation, the relationship is called a unary relationship. For example, one person is
married to only one person.
Unary Relationship
2. Binary Relationship: When there are TWO entities set participating in a
relationship, the relationship is called a binary relationship. For example, a Student
is enrolled in a Course.
Binary Relationship
3. Ternary Relationship: When there are three entity sets participating in a
relationship, the relationship is called a ternary relationship.
Mapping cardinalities
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 one female
and a female can marry one male. So the relationship will be one-to-one.
the total number of tables that can be used in this is 2.
one to one cardinality
Using Sets, it can be represented as:
Set Representation of One-to-One
2. One-to-Many: In one-to-many mapping as well where each entity can be related to more
than one entity and the total number of tables that can be used in this is 2. Let us assume
that one surgeon department can accommodate many doctors. So the Cardinality will be 1
to M. It means one department has many Doctors.
total number of tables that can used is 3.
one to many cardinality
Using sets, one-to-many cardinality can be represented as:
Set Representation of One-to-Many
3. Many-to-One: When entities in one entity set can take part only once in the relationship
set and entities in other entity sets 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.
The total number of tables that can be used in this is 3.
many to one cardinality
Using Sets, it can be represented as:
Set Representation of Many-to-One
In this case, each student is taking only 1 course but 1 course has been taken by many
students.
4. 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.
the total number of tables that can be used in this is 3.
many to many cardinality
Using Sets, it can be represented as: