The Entity-Relationship (ER) Model is one of the primary components of Database Management Systems and is

important for designing the logical structure of databases. It helps define data and the relationship between the data
entities, and it makes the system easier to visualize.
 ER Model is commonly used to design the structure of relational databases.
 Makes it easy to construct and visualize data hierarchies.
 Provides a clear framework for organizing database components.

Entity, Entity Set and Entity Type

Entity
An entity is anything real that has a defined and separate existence. It can be anything that can be described, named,
or identified in separation from the rest of the items. This is vital in database design since entities are the
fundamental components of information that are kept and controlled in a database. Each of these entities has
attributes that help in describing the nature of the entity, distinguishing it from the other entities.
 An entity may be concrete, like a student, or a book, or abstract, like a holiday or a particular concept.
 An entity is represented by a set of attributes.
 In a particular relation in RDBMS, a particular record is called an entity.
Types of Entity:
 Tangible Entity: Entities that exist in the real world physically.
 Intangible Entity: Entities that exist only logically and have no physical existence.
Example :
 A student with a particular roll number is an entity.
 A company with a particular registration number is an entity.
Entity Type
An entity type can be defined as a framework or a class of entities which are the focal point of this research. It is
smaller to a schematic diagram, which defines the properties of the objects of this class. Entity types assist in
classifying the same kind of entities into one group, which comes in use when dealing with their properties and
relations in the database.
 The category of a particular entity in the relation in RDBMS is called the entity type.
 It is represented by the name of the table and its schema.
Example :
 A table named student in a university database.
 Employee table in a company database.
Entity Set
An entity set is a comprehensive representation of all entities of the same type at a specific time. The use of an
entity set helps to aggregate and thus manage similar entities within databases. The entities of the entity-set have
common attributes for each entity, but the values of those attributes are different. Entity sets are important
components in database structure because they illustrate how information is organized and put away in tables.
 Entity sets need not be disjoint.
 The collection of all the entities in the relation of RDBMS is called an entity set.

Example :
 The collection of all the students from the student table.
 The collection of all the employees from the employee table.
Relation With Table :
Table Name : Student

Student_ID Student_Name Student_Age Student_Gender

1 John 19 M

2 Robert 23 M

3 Michael 21 M

4 Anna 16 F

 Entity : Each row (tuple) in a table represents one instance of an entity.

 Entity Type : Each entity belongs to the student type. Hence, the type of entity here is a student.
 Entity Set : The complete data set of all entities is called entity set. For the above table, the records with
student id 1, 2, 3, 4 are the entity set.
Entity vs Entity Set vs Entity Type

Entity Entity Type Entity Set

A thing in the real world with Set of all entities of a particular

A category of a particular entity
independent existence entity type.

Any particular row (a record) in a The name of a relation (table) in All rows of a relation (table)
relation (table) is known as an entity. RDBMS is an entity type in RDBMS is entity set
Entity Entity Type Entity Set

Defines attributes shared by Represents a snapshot of all

Entities can be tangible or intangible.
entities of that type. entities at a given time.

It is identified uniquely through a key It represents the structure of the It can grow or shrink as entities
attribute. table without data. are added or removed.

Types of Attributes in ER Model

In DBMS, an attribute is a characteristic of an entity that is used to describe an entity. Essentially, it is a column in a
table that holds data values. An entity may contain any number of attributes. One of the attributes is considered as
the primary key. In an Entity-Relation model, attributes are represented in an elliptical shape.
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
What is Relationship Set in DBMS?
Relationship set in a Database Management System (DBMS) is essential as it provides the ability to store, recover,
and oversee endless sums of information effectively in cutting-edge data administration, hence making a difference
in organizations.
In a Relational database, relationship sets are built up by utilizing keys, such as primary and foreign keys, to interface
related records over distinctive tables.
What is a Relation?
A Relation in a database management system (DBMS) organizes information into rows and columns. This organized
arrangement makes a difference in information storing and recovering information proficiently. Relations permit us
to query information utilizing SQL commands like SELECT, Update, Insert, and Delete. Henceforth, it becomes easier
and more demanding to control and extract data from the database.
Relations are alluded to as tables within the database management system.
What is a Relationship Set?
It is a set of Relationships of the Same type. Mathematical Relation on m > 2 (Possibly non-distinct) entity Sets.
If E1, E2,...... En are the entity sets for the Relationship Set R is a subset of {(e1, e2,... en) | e1 € E1, e2 € E2....en € En}
Where (e1, e2,...en) is a Relationship.
For Example, (E-R Diagram)

Relationship Set
Characteristics of Relationship Set
 Degree: Degree of a relationship set indicates to the number of properties related with the relationship set.
 Arity: Arity of a relationship set indicates the number of taking part relations. It can be like double (including
two relations), ternary (including three relations), and so on.
 Cardinality: Cardinality characterizes the number of occurrences or records that can be related with each
substance on both sides of the relationship.
This permits for the execution of different sorts of connections, such as one-to-one, one-to-many, and many-to-
many, reflecting real-world associations between substances.
Degree of Relationship Set
It denotes the number of entity sets that belong to that particular relationship set is called the degree of that
relationship set.
Degree of a Relationship Set = the number of entity set that belongs to that particular relationship set
Relationship Set Example With Tables
Let 'Customer' and 'Loan' entity sets defines the Relationship 'set Borrow' to denote the association between
Customer and bank loans.

Relationship Set between Customer and Loan

In the above example, In table Customer shows a customer borrows a loan from Table Loan. In other words, the
relationship borrows will be one to one.
Examples
1. Student-Student ID Relationship
In a one-to-one relationship, each student is assigned a unique student ID.

one to one
2. Teacher-Student Relationship
Consider two relations: Teacher and Student. The relationship set between them can be characterized as “mentors.”
Each teacher mentors in one class, but a class can have numerous students. So one teacher can have many students.
This is often an illustration of a one-to-many relationship.

one to many
3. Student-Course Relationship
In this situation, we have two relations: Understudy and Course. The relationship set between them can be
characterized as “enrolled_in.” Each understudy can be selected in numerous courses, and each course can have
different understudies.
This can be an illustration of a many-to-many relationship.

many to many

What is Mapping Cardinalities in ER Diagrams

Mapping cardinality (or cardinality ratio) in an ER diagram tells us how many instances of one entity can be
associated with how many instances of another entity through a relationship.
That is for each instance of Entity A, how many instances of Entity B can it relate to, and vice versa
Example:
Relationship

The relationship in the ER model is represented using a diamond-shaped box.

In the Entity-Relationship (ER) model, relationships represent how two or more entities interact with each other.
These relationships are often depicted as a diamond-shaped box connecting the related entities. For instance, a
customer buying products is a common business relationship where the customer and the product are two entities,
and the act of buying forms the relationship.

Each relationship can have attributes, such as a timestamp recording when a customer buys a product. Thus,
relationships can have their own unique characteristics that further define the interaction between entities.

Example:

Example of Relationship in DBMS

'Buys' is a relationship between customer entity and products. This relationship can be read as 'A customer buys a
product/products.

Therefore, a relationship is a way to connect multiple entities.

 When a customer buys a product, there is a timestamp associated with it, so the attribute "Time" will be an
attribute of 'Buys'.

 All the database concepts can be easily understood from the concepts of sets and relations.

 According to the Set-theoretic perspective, it will be represented as

 Example

By interpreting this, we can understand that many customers can buy the same type of product and many products
can be bought by many customers. And there are some products which are not bought by any customer and there
are some customers who do not buy any product.

According to the Relation/table perspective or relational model:

It can be represented as

Many
to many Relationship

As the relationship is many to many (M: N) between customer and product, therefore we require separate tables/
relations for 'buys'.
In buys relation, Cust_id and Prod_id are the foreign key to the customer and product.

Mapping Cardinality/Cardinality Ratio

Mapping cardinality is the maximum number of relationship instances in which an entity can participate.

Example:

Entity type employee is related to department entity type by

works_for relationship

Mathematically, here (e1, e2,e3...) are instances of an entity set Employee and (d1,d2, d3 ....) are the instances of
entity type department and (r1, r2, r3 ...) are relationship instances of relationship type.
Each instance ri(where i = 1,2,3,....) in R, is an association of entities, and the association includes exactly one entity
from each participating entity type. Each such relationship instance, ri represents that the entities participating in ri
are related in some way by any constraint/condition provided by the user to a designer.

 In works_for binary relationship type Department: Employee is of cardinality (N:1), this means each
department can be related to any number of employees but an employee can be related to (works for) only
one department.

 The possible cardinality ratios of binary relationship types are (1:1, 1:N, N:1, N:M).

All possible cardinality ratios for binary relationships are explained below with an example.

1. One to one relationship (1:1)

One item is connected to only one other item,

and that item is also connected to only one in return.

It is represented using an arrow(⇢,⇠)(There can be many notations possible for the ER diagram).
Example:

One
to One relationship

In this ER diagram, both entities customer and driving license having an arrow which means the entity Customer is
participating in the relation "has a" in a one-to-one fashion. It could be read as 'Each customer has exactly one
driving license and every driving license is associated with exactly one customer.

The set-theoretic perspective of the ER diagram is

one to one relationship

There may be customers who do not have a credit card, but every credit card is associated with exactly one
customer. Therefore, the entity customer has total participation in a relation.

2. One to many relationship (1:M)

One item is connected to many items,

but each of those many items is connected to only that one.

Example:
 one
to many relationship

This relationship is one to many because "There are some employees who manage more than one team while there
is only one manager to manage a team".
The set-theoretic perspective of the ER diagram is:

ER diagram

3. Many to one relationship (M:1)

Many items from one group are connected to just one item in another group.

Example:

Many
to one relationship

This is a one-to-many relationship, but the difference comes from who must participate .The set-theoretic
perspective of the ER diagram is:

 A customer can have many credit cards, but some customers might not have any. So, customer
participation is partial.

 Every credit card must be linked to one customer. So, credit card participation is total.

 Also, a credit card belongs to only one customer — it cannot be shared by multiple customers.
 ER diagram

4. Many to many relationship (M:N)

One entity in the first set can be related to many entities in the second set,
and One entity in the second set can also be related to many entities in the first set.

Example:
A customer can buy any number of products and a product can be bought by many customers.

Many
to many Relationship

The set-theoretic perspective of the ER diagram is:

ER diagram

Any of the four cardinalities of a binary relationship can have both sides partial, both total, and one partial, and one
total participation, depending on the constraints specified by user requirements.
Relationship Table

Relationship Type Entity A Entity B Example

One-to-One 1 1 person<->passport

One-to-Many 1 Many Department -> Employees

Many-to-One Many 1 Orders -> Customer

Many-to-Many Many Many Students <-> Courses

Keys in Relational Model

Keys are fundamental elements of the relational database model that ensure uniqueness, data integrity, and
efficient data access.
 They uniquely identify each row in a table.
 They prevent data duplication and maintain consistency.
 They create relationships between different tables.
Importance of Keys in DBMS
Keys are important in a Database Management System (DBMS) for several reasons:
 Uniqueness: Keys ensure that each record in a table is unique and can be identified distinctly.
 Data Integrity: Keys prevent data duplication and maintain the consistency of the data.
 Efficient Data Retrieval: Keys help in creating relationships between tables, allowing faster queries and
better data organization.
 Without keys, managing large databases would become difficult, and data retrieval would be slow and error-
prone.
Types of Database Keys
1. Candidate Key
The minimal set of attributes that can uniquely identify a tuple is known as a candidate key. For Example, STUD_NO
in STUDENT relation.
 It is a super key with no repeated data is called a candidate key.
 A candidate key must contain unique values, ensuring that no two rows have the same value in the
candidate key’s columns.
 Every table must have at least a single candidate key.
 A table can have multiple candidate keys but only one primary key.
Example: For the STUDENT table below, STUD_NO can be a candidate key, as it uniquely identifies each record.

STUDENT Table
Table: STUDENT_COURSE
STUDENT_COURSE Table
A composite candidate key example: {STUD_NO, COURSE_NO} can be a candidate key for a STUDENT_COURSE table.
2. Super Key
The set of one or more attributes (columns) that can uniquely identify a tuple (record) is known as Super Key. It may
include extra attributes that aren't important for uniqueness but still uniquely identify the row. For Example,
STUD_NO, (STUD_NO, STUD_NAME), etc.
 A super key can contain extra attributes that aren’t necessary for uniqueness and supports NULL values in
rows.
 For example, if the "STUD_NO" column can uniquely identify a student, adding "SNAME" to it will still form a
valid super key, though it's unnecessary.
Example: Consider the STUDENT table

STUDENT Table
A super key could be a combination of STUD_NO and PHONE, as this combination uniquely identifies a student.

Relation between Primary Key, Candidate Key, and Super Key

3. Alternate Key
An alternate key is any candidate key in a table that is not chosen as the primary key. In other words, all the keys
that are not selected as the primary key are considered alternate keys.
 An alternate key is also referred to as a secondary key because it can uniquely identify records in a table, just
like the primary key.
 An alternate key can consist of one or more columns (fields) that can uniquely identify a record, but it is not
the primary key
Example: In the STUDENT table, both STUD_NO and PHONE are candidate keys. If STUD_NO is chosen as the primary
key, then PHONE would be considered an alternate key.

Primary Key, Candidate Key, and Alternate Key

4. Foreign Key
A foreign key is an attribute in one table that refers to the primary key in another table. The table that contains the
foreign key is called the referencing table and the table that is referenced is called the referenced table.

Relation between Primary Key and Foreign Key

 A foreign key in one table points to the primary key in another table, establishing a relationship between
them.
 It helps connect two or more tables, enabling you to create relationships between them. This is important
for maintaining data integrity and preventing data redundancy.
 They act as a cross-reference between the tables.
Example: Consider the STUDENT_COURSE table
STUDENT_COURSE Table
 STUD_NO in the STUDENT_COURSE table is a foreign key that refers to the STUD_NO primary key of the
STUDENT table.
 Unlike a primary key, a foreign key can contain duplicate values and may be NULL. For example, STUD_NO
appears multiple times in STUDENT_COURSE because a student can enroll in more than one course.
 However, STUD_NO in the STUDENT table is a primary key, so it must always be unique and non-NULL.
5. Partial Key
A partial key is chosen from a weak entity to help identify records, but it cannot uniquely identify a record by itself.
 Helps distinguish records in a weak entity when combined with data from a related strong entity.
 It cannot be NULL, as it is needed to identify records with other data.
 It can be a single column or a combination of columns.
 Ensures consistency when paired with data from a strong entity.
Example: In a STUDENT_COURSE table, the combination of STUD_NO and COURSE_CODE can be a partial key.

6. Primary Key
A primary key is chosen from the set of candidate keys to uniquely identify each record in a table. For example, in
the STUDENT table, both STUD_NO and STUD_PHONE can be candidate keys, but STUD_NO is selected as the
primary key.
 It cannot be NULL, as each record must have a valid identifier.
 It may be single-column or composite (made of multiple columns).
 Databases often organize data using the primary key to allow faster access and searching.
Example: The STUDENT table has the structure Student(STUD_NO, SNAME, ADDRESS, PHONE), where STUD_NO is
the primary key.

7. Secondary Key
A Secondary Key is an attribute or a combination of attributes used to search or query records in a table, but it
doesn’t guarantee uniqueness.
 It helps in retrieving data quickly, often by creating indexes.
 It doesn’t uniquely identify each record; multiple records can have the same value.
 For example, STUD_NAME in a STUDENT table can be used to find students by name, even though many
students may share the same name.
 It’s mainly for improving search efficiency, not for maintaining data uniqueness.
Here's an example of how the STUDENT table might look with STUD_NAME as a secondary key:
STUD_NO STUD_NAME STUD_AGE STUD_ADDRESS

101 John 21 123 Oak St

102 Emily 22 456 Pine St

103 John 23 789 Maple St

104 Michael 20 321 Birch St

105 Emily 22 654 Cedar St

8. Unique Key
A Unique Key is a database constraint that ensures that all values in a specific column or a combination of columns
are unique across all the rows in a table. It guarantees that no two rows in the table can have the same value in the
columns defined as part of the unique key.
 Prevents duplicate values in the specified column(s).
 It allows NULL values, but only one NULL per column.
 It can be applied to a single column or multiple columns.
 Helps maintain the integrity and accuracy of the data in the table.
Example: In the STUDENT_COURSE table, the combination of STUD_EMAIL and STUD_NAME can form a Unique Key
to ensure that each student’s email and name pair is unique across the table.

STUD_NO STUD_EMAIL STUD_NAME

101 john@[Link] John

102 emily@[Link] Emily

103 michael@[Link] Michael

104 sara@[Link] Sara

105 david@[Link] David

9. Composite Key
Sometimes, a single column is not enough to uniquely identify all records in a table, so a combination of multiple
attributes is used. An optimal set of such attributes is chosen to ensure that every row is uniquely identifiable.
It acts as a primary key if there is no primary key in a table
 Two or more attributes are used together to make a composite key .
 Different combinations of attributes may give different accuracy in terms of identifying the rows uniquely.
Example: In the STUDENT_COURSE table, {STUD_NO, COURSE_NO} can form a composite key to uniquely identify
each record.
10. Surrogate Keys
A surrogate key is an artificial attribute created to uniquely identify each record in a table when no suitable natural
key is available.
 It is usually generated automatically by the system (like auto-increment numbers).
 It acts as a primary key when natural or composite keys are not practical or efficient.
 A single system-generated attribute is used to make a surrogate key.
 It does not have any real-world meaning and is used only for identification purposes.
Example: STUDENT_ID is used as a surrogate key to uniquely identify each record in the STUDENT_COURSE table,
without relying on natural attributes like name or email.

Degree of Relations in DBMS

In DBMS, the degree of a relationship refers to the number of entity types involved in that relationship. For instance,
if a Student entity is connected to a Bag entity through a primary key–foreign key relationship, the interaction
between these two entities represents a relationship of degree two.

Unary (Degree 1)

In this type of relationship, both the associating entity types are the same. So, we can say that unary relationships
exist when both entity types are the same and we call them the degree of relationship is 1. In other words, in a
relation only one entity set is participating then such type of relationship is known as a unary relationship.

Example: In a particular class, we have many students, there are monitors too. So, here class monitors are also
students. Thus, we can say that only students are participating here. So the degree of such type of relationship is 1.
 Unary

Binary (Degree 2)

In a Binary relationship, there are two types of entity associates. So, we can say that a Binary relationship exists
when there are two types of entity. Or in other words, in a relation when two entity sets are participating then such
type of relationship is known as a binary relationship. This is the most used relationship and one can easily be
converted into a relational table.

Example: We have two entity types 'Student' and 'ID' where each ‘Student’ has his 'ID'. So, here two entity types are
associating we can say it is a binary relationship. Also, one ‘Father’ can have many ‘daughters’ but each ‘daughter’
should belong to only one ‘father. We can say that it is a one-to-many binary relationship.

Binary

Ternary (Degree 3)

In the Ternary relationship, there are three types of entity associates. So, we can say that a Ternary relationship
exists when there are three types of entity and we call them a degree of relationship is 3. Since the number of
entities increases due to this, it becomes very complex to turn E-R into a relational table. Now let's understand with
the examples.

Example: We have three entity types ‘Teacher’, ‘Course’, and ‘Class’. The relationship between these entities is
defined as the teacher teaching a particular course, also the teacher teaches a particular class. So, here three entity
types are associating we can say it is a ternary relationship.

Ternary

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. There is one limitation of the N-ary relationship, as there are many entities so it is
very hard to convert into an entity, rational table. So, this is very uncommon, unlike binary which is very much
popular.

Example: We have 5 entities Teacher, Class, Location, Salary, Course. So, here five entity types are associating we
can say an n-ary relationship is 5.

N-ary

Introduction of ER Model
Uses of ER Diagrams in DBMS
 ER diagrams represent the E-R model in a database, making them easy to convert into relations (tables).
 These diagrams serve the purpose of real-world modeling of objects which makes them intently useful.
 Unlike technical schemas, ER diagrams require no technical knowledge of the underlying DBMS used.
 They visually model data and its relationships, making complex systems easier to understand.

Symbols Used in ER Model

ER Model is used to model the logical view of the system from a data perspective which consists of these symbols:
Types of Entity

There are two main types of entities:

1. Strong Entity

A type of entity that has a key Attribute that can uniquely identify each instance of the entity. A Strong Entity does
not depend on any other Entity in the Schema for its identification. It has a primary key that ensures its uniqueness
and is represented by a rectangle in an ER diagram.

2. Weak Entity

It cannot be uniquely identified by its own attributes alone. It depends on a strong entity to be identified. A weak
entity is associated with an identifying entity (strong entity), which helps in its identification. A weak entity are
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.

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.

Subclasses and Superclasses

A superclass shows a broad category of entities, however its subclasses define more specific groupings within that
category. The superclass-subclass relationship helps us model hierarchical data.
For example, consider the EMPLOYEE entity type in a company’s database. It is a broad category that might include
subclasses such as:
 SECRETARY − Employees who handle administrative tasks.
 TECHNICIAN − Employees who provide technical support or services.
 ENGINEER − Employees who design and develop systems or products.
The EMPLOYEE entity type is like the superclass, it has the shared characteristics of all employees. The specific roles
like ENGINEER or SECRETARY are the subclasses.
The Class / Subclass Relationship
The connection between a superclass and its subclasses is known as the class-subclass relationship. This relationship
shows that entities in a subclass are also members of the superclass.
For example, a TECHNICIAN entity is an EMPLOYEE with additional characteristics specific to the TECHNICIAN role.
Similarly, a SECRETARY is an EMPLOYEE but with unique attributes, such as Typing_speed. This relationship is often
described using an "is-a" relationship:
 A TECHNICIAN is an
 A SECRETARY is an

EER diagrams illustrate these relationships clearly –

 Like ER diagrams, rectangles represent entities (both superclasses and subclasses).
 Circles denote specialization or generalization processes.
 Subset symbols point from subclasses back to their superclass.
For example, the EMPLOYEE superclass connects to its subclasses through a circle. Specific attributes, like
Typing_speed for SECRETARY, are attached to the respective subclass rectangle.
Inheritance in Superclass-Subclass Relationship
Inheritance is one of the key features of the superclass-subclass relationship. Inheritance ensures that entities in a
subclass retain the attributes and relationships of their superclass. It is used to enables reuse and prevents
redundancy.
Attribute Inheritance
Entities in a subclass inherit −
 Superclass Attributes − For instance, all EMPLOYEES might have attributes such as Name, SSN, and Address.
These are inherited by subclasses like ENGINEER and TECHNICIAN.
 Subclass-Specific Attributes − Each subclass has its unique attributes. For example –
 SECRETARY might have Typing_speed.
 TECHNICIAN might have Tgrade.
This hierarchical organization helps ensure that common characteristics remain at the superclass level while allowing
subclasses to specialize further.
Relationship Inheritance
Subclasses also inherit the relationships of their superclasses. For example, If EMPLOYEE participates in a MANAGES
relationship with a PROJECT, all subclasses of EMPLOYEE inherit this relationship.
This flexibility is useful for subclasses to focus on unique relationships while sharing inherited ones.
Generalization
Process of extracting common properties from a set of entities and creating 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.

Generalization
Example: STUDENT and FACULTY can be generalized to a higher-level entity called PERSON as shown in diagram
below. In this case, common attributes like P_NAME and P_ADD become part of a higher entity (PERSON) and
specialized attributes like S_FEE become part of a specialized entity (STUDENT).
Specialization
In specialization, an entity is divided into sub-entities based on its characteristics. It is a top-down approach where
the higher-level entity is specialized into two or more lower-level entities.

Specialization
Example: an EMPLOYEE entity in an Employee management system can be specialized into DEVELOPER, TESTER, etc.
In this case, common attributes like E_NAME, E_SAL, etc. become part of a higher entity (EMPLOYEE) and specialized
attributes like TES_TYPE become part of a specialized entity (TESTER).
Inheritance
It is an important feature of generalization and specialization. In specialization, a higher-level entity is divided into
lower-level sub-entities that inherit its attributes. In generalization, similar lower-level entities are combined into a
higher-level entity that holds common attributes. In both cases, inheritance allows sub-entities to reuse the
properties of the parent entity.
1. Attribute inheritance: It allows lower level entities to inherit the attributes of higher level entities but not
vice versa. In below diagram Car is a subclass of Vehicle and inherits its attributes.
2. Relationship Inheritance: Sub-entities also inherit relationships of the parent entity.
3. Overriding Inheritance: Sub-entities can override or add their own attributes or behaviors different from the
parent.
4. Participation inheritance: Participation inheritance in ER modeling refers to the inheritance of participation
constraints from a higher-level entity (superclass) to a lower-level entity (subclass). It ensures that subclasses
adhere to the same participation rules in relationships, although attributes and relationships themselves are
inherited differently.

Example of Relation
Example: In diagram Vehicle entity has an relationship with Cycle entity, but but it does not automatically inherit the
relationship itself with the Vehicle entity. Participation inheritance only refers to the inheritance of participation
constraints, not the actual relationships between entities.
Aggregation
 An ER diagram is not capable of representing the 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.
Example: an Employee working on a project may require some machinery. So, REQUIRE relationship is needed
between the relationship WORKS_FOR and entity MACHINERY. Using aggregation, WORKS_FOR relationship with its
entities EMPLOYEE and PROJECT is aggregated into a single entity and relationship REQUIRE is created between the
aggregated entity and MACHINERY.
Difference Between Strong and Weak Entity

Strong Entity Weak Entity

Strong entity always has a primary key. While a weak entity has a partial discriminator key.

Strong entity is not dependent on any other

Weak entity depends on strong entity.
entity.

Strong entity is represented by a single

Weak entity is represented by a double rectangle.
rectangle.

Two strong entity's relationship is represented While the relation between one strong and one weak entity is
by a single diamond. represented by a double diamond.

Strong entities have either total participation

A weak entity has a total participation constraint.
or partial participation.

What is Unified Modeling Language (UML)?

Unified Modeling Language (UML) is a type of general modeling language that is used to diagram, describe, build,
and document the static and dynamic structure of software systems. UML diagrams refer to tools that assist
developers and designers in designing structures and processes of constructing software by the use of symbols. Use
case diagrams, class diagrams, sequence diagrams, and activity diagrams, which are part of UML, all assist in
comprehending the movement of a system.

Advantages of UML

 Comprehensive Software Representation: UML also permits the delineation of software structures and
behaviors of a certain system in a more refined manner in contrast to data flow diagrams.
  Standardization: It uses standard notations that enhance how the different teams interact and share
information during the development phase of the software.

 Flexibility: One of the main advantages of utilizing UML is the fact that it has the capability of being used in
both small-scale and large-scale systems and does not restrict its usage to certain technologies.

 Extensive Diagram Types: UML is comprised of various diagrams, including class diagrams, sequence
diagrams, activity diagrams, and so on, which are designed to provide specific support to particular activities
in software development processes.

Disadvantages of UML

 Complexity: However, for small projects, UML seems to complicate things and, if not well guided, may lead
to higher costs of development than necessary.

 Steep Learning Curve: Each diagram in UML has been developed for a particular purpose, and it is important
to understand them all while using UML. This poses a challenge to persons new to system design or to those
non-technical stakeholders who want to understand UML simplified.

 Time-Consuming: While creating the detailed UML diagrams, it is a very time-consuming process, especially
for the large systems consisting of many components and interactions.

Difference Between UML and ER Diagram

CATEGORY UML ER Diagram

UML stands for Unified Modelling

Full Form ER Diagram stands for Entity Relationship Diagram.
Language.

It is a general modelling language

It is a pictorial representation of the real-world
Definition which is used to visualize the design of
entities and their relationships with each other.
a software system.

Relationship It is the parent of ER diagram. It is the child of UML.

Use It is used to design the entire software. It is used to design only the databases.

It is mainly used in case of large-scale IT can be used in case of database development of

Scale
software development. all scales.

Components It has use cases and workflows. It has entities, attributes and relationships.

Diagrams It involves use case diagrams and

It is itself involved in representation.
Involved activity diagrams.
CATEGORY UML ER Diagram

It is made for the understanding of Stake holders

It is used by developers to understand
Primary User and enterprise owners, to understand that their
flow of program.
requirements have been correctly met.

Depiction Flow of control is depicted. Relationships are depicted.

It is a form of dynamic modelling as it

It depicts static modelling (as unlike UML it does not
Modelling can depict what activities are being
depict state of the activities).
performed at what time.

States It involves a final and an initial state. It has no state representation.

It is uses circles, rectangles with round

Shapes Used corners, arrow heads, diamonds, It uses only 3 shapes (oval, rectangle and diamond).
rectangular bars etc.

Use of
It uses swimlanes. It does not use swimlanes.
Swimlanes

It can represent time taken during

Time It does not depict time.
activities.

It does not have types, however, it contains entities,

It is of 2 types, Structural UML
Types relationships and attributes each of which have
diagrams and Behavioral UML diagrams
several types.