Entity in DBMS: Meaning, Types, ER Model & ER Diagram Examples

Updated on April 16, 2026

•

18 min read

ARTICLE OUTLINE

What is an Entity in DBMS?Attributes of Entities in DBMS Types of Entities in DBMS Classification of Entity Types in DBMS What is the ER Model in DBMS?Entity Relationship Model in DBMS – Components in Detail ER Diagram in DBMS – How to Read and Build One DBMS Relationship Types What is an Entity Type in DBMS?What is an Entity Set in DBMS?Difference Between an Entity and Entity Set in DBMS ER Diagram of Database – Real-World Examples DBMS Diagram Summary – ER Diagram Quick Reference Conclusion People Also Ask FAQs

To understand database management systems foundationally, you must understand what an entity in dbms is. An entity is the fundamental building block of all database design – from the individual records stored in tables to the complex relationships modelled in an er diagram in dbms. This guide covers entities, entity types, entity sets, the er model in dbms, dbms relationship types, and how to read and build a dbms entity relationship diagram.

What is an Entity in DBMS?

An entity in dbms is any significant object, idea, or element – tangible or intangible – that can be uniquely identified and stored in a database. Every entity has attributes that describe its characteristics and distinguish it from other entities. Entities are the foundation of the entity relationship model in dbms.

Entity	Attributes	Primary Key
Student	student_name, student_id, student_course, student_dept	student_id
Employee	emp_name, emp_id, emp_dept, emp_phone	emp_id
Car	model, colour, year, VIN	VIN
Bank Branch	branch_name, IFSC_code, city	IFSC_code
Customer	customer_name, customer_email, purchase_id	purchase_id

Key Concept: An entity is always something about which data needs to be stored. It is represented as a rectangle in the er diagram in dbms – one of the core symbols of the er model in dbms.

POSTGRADUATE PROGRAM IN

Multi Cloud Architecture & DevOps

Master cloud architecture, DevOps practices, and automation to build scalable, resilient systems.

Attributes of Entities in DBMS

Attributes are the properties that describe and uniquely characterise an entity in a database management system er model. There are five main attribute types:

Attribute Type	Description	Example
Simple (Atomic)	Cannot be divided further – indivisible value	Age, Employee ID, Salary
Single-Valued	Holds exactly one value at a time	Date of Birth – only one DOB per person
Multi-Valued	Can hold multiple values of the same type	Phone Numbers, Email Addresses
Composite	Made from two or more sub-attributes combined	Address = Street + City + State + PIN
Derived	Derived from another attribute – not stored directly	Age derived from Date of Birth

In an er diagram in dbms, simple attributes are represented by ovals, composite attributes by subdivided ovals, multi-valued attributes by double ovals, and derived attributes by dashed ovals. These symbols are standardised across the er model in dbms.

Types of Entities in DBMS

Entities in dbms are classified into three primary types based on their ability to exist independently and how they relate to other entities in the database management system er model.

1. Strong Entity

A strong entity in dbms is an entity that can exist independently – it has a primary key (a unique identifier) and does not depend on any other entity for its existence. Strong entities are also called independent entities and are represented as single rectangles in a dbms diagram.

Property	Strong Entity
Primary key	Yes – has its own unique identifier
Independence	Exists independently – no parent entity needed
ER diagram symbol	Single rectangle
DBMS relationship	Can participate in relationships with other entities
Example	Student, Employee, Customer, Product, Course

Examples:

• Student (university database) – uniquely identified by student_id

• Employee (HR database) – uniquely identified by emp_id

• Customer (retail database) – uniquely identified by customer_purchase_id

2. Weak Entity

A weak entity in dbms is an entity that cannot exist independently – it depends on a strong (parent) entity for its identity. A weak entity has no primary key of its own; instead, it uses a partial key combined with the primary key of the related strong entity to form a composite key. It is represented as a double rectangle in an er diagram in dbms. The relationship connecting a weak entity to its owner is called an identifying relationship, shown as a double diamond in the dbms diagram.

Property	Weak Entity in DBMS
Primary key	No – uses partial key + owner’s primary key
Independence	Depends on a strong entity (owner/parent)
ER diagram symbol	Double rectangle
Relationship type	Identifying relationship – shown as double diamond
Example	Order_Item (depends on Order), Course_Enrollment (depends on Student + Course)

Examples:

• Course_Enrollment – depends on student_id (Student) and course_id (Course)

• Order – depends on customer_id (Customer entity)

• Email – depends on person_id (Person entity)

3. Composite Entity (Associative Entity)

A composite entity in dbms (also called an associative entity or junction table) represents a many-to-many relationship between two or more strong entities. It resolves the M:M relationship by acting as an intermediate entity that holds the foreign keys of both related entities – along with any additional attributes specific to that relationship.

Example: In a university database, Course_Enrollment represents the many-to-many relationship between Student and Course. It holds student_id and course_id as foreign keys, plus enroll_date and enroll_status as its own attributes.

Property	Composite (Associative) Entity
Purpose	Resolve many-to-many relationships between strong entities
Primary key	Composite key made from foreign keys of related entities
ER diagram	Rectangle connected to the entities it links
Example	Course_Enrollment (Student + Course), Project_Work (Student + Mentor)

Classification of Entity Types in DBMS

Beyond strong, weak, and composite, entities in dbms are also classified by their physical existence:

Classification	Description	Examples
Tangible Entity	Exists physically in the real world – can be touched	Car, Employee, Building, Product, Customer
Intangible Entity	Does not exist physically – conceptual or abstract	Bank Transaction, Course Enrollment, Insurance Policy, Software License

This classification matters when designing an entity relationship model in dbms – tangible entities typically map directly to real-world objects, while intangible entities usually represent events, transactions, or conceptual relationships between other entities.

82.9%

of professionals don't believe their degree can help them get ahead at work.

What is the ER Model in DBMS?

The er model in dbms (Entity-Relationship Model) is a conceptual data model used to describe the structure of a database in terms of entities, attributes, and relationships. Developed by Peter Chen in 1976, the er model in dbms serves as a blueprint for designing a relational database schema before implementation.

The database management system er model provides a visual, language-independent way to represent data requirements – making it a universal tool for communication between database designers, developers, and business stakeholders. Every er diagram in dbms is a visual representation of the er model.

ER Model Component	Description	ER Diagram Symbol
Entity	A real-world object or concept with data to be stored	Rectangle (single for strong, double for weak)
Attribute	A property that describes an entity	Oval (single for simple, double for multi-valued, dashed for derived)
Primary Key Attribute	The attribute that uniquely identifies each entity instance	Oval with underlined text
Relationship	An association between two or more entities	Diamond (single for regular, double for identifying)
Cardinality	The number of instances involved in a relationship	1:1, 1:M, M:N labels on relationship lines

The er model in dbms is the starting point for creating the dbms entity relationship diagram. Once the er model is validated, it is converted to a relational schema (tables, primary keys, foreign keys) for implementation in a database management system.

Entity Relationship Model in DBMS – Components in Detail

The entity relationship model in dbms is built from three core components – entities, attributes, and relationships. Together they form the complete er diagram of database that captures the full data structure of a system.

Entities in the ER Model

Entities are the nouns of the entity relationship model in dbms – the things about which data is stored. Every entity in the er model maps to a table in the final relational database. Strong entities become standalone tables; weak entities become tables with composite primary keys; composite entities become junction tables that resolve M:M relationships.

Relationships in the ER Model

Relationships are the connections between entities in the er model in dbms. They are categorised by cardinality – the number of entity instances that participate on each side:

Relationship Type	Cardinality	Description	Example
One-to-One (1:1)	One instance ↔ one instance	Each instance of Entity A is related to exactly one instance of Entity B	Person has one Passport
One-to-Many (1:M)	One instance ↔ many instances	One instance of Entity A is related to many instances of Entity B	Department has many Employees
Many-to-Many (M:M)	Many instances ↔ many instances	Multiple instances of A related to multiple instances of B	Students enrol in many Courses; Courses have many Students

These are the three fundamental dbms relationship types in the entity relationship model in dbms. Each type has specific implications for how foreign keys are placed in the resulting relational schema.

Participation Constraints in the ER Model

Participation	Description	ER Diagram Notation
Total Participation	Every entity instance must participate in the relationship	Double line connecting entity to relationship diamond
Partial Participation	Some entity instances may not participate	Single line connecting entity to relationship diamond

ER Diagram in DBMS – How to Read and Build One

An er diagram in dbms is a visual representation of the entity relationship model – showing entities, their attributes, and the relationships between them. The er diagram in dbms is the primary deliverable of the conceptual database design phase and is used as the blueprint for creating the actual database schema.

Standard ER Diagram Notation

Symbol	Shape	Represents
Entity	Single rectangle	Strong entity – independent object with its own primary key
Weak Entity	Double rectangle	Dependent entity – needs a strong entity’s key for identification
Attribute	Oval	A property or characteristic of an entity
Primary Key Attribute	Underlined oval	The attribute that uniquely identifies entity instances
Multi-Valued Attribute	Double oval	Attribute that can hold multiple values (e.g., phone numbers)
Derived Attribute	Dashed oval	Attribute computed from another (e.g., Age from DOB)
Composite Attribute	Oval with sub-ovals	Attribute composed of sub-attributes (e.g., Address)
Relationship	Diamond	Association between two or more entities
Identifying Relationship	Double diamond	Relationship connecting a weak entity to its owner
Relationship line	Straight line	Connects entities to relationships; labels show cardinality
Total Participation	Double line	All instances of the entity must participate in the relationship
Partial Participation	Single line	Some instances may not participate

Steps to Build an ER Diagram in DBMS

1. Identify all entities in the domain – these become rectangles in your dbms diagram

2. Identify the attributes of each entity – classify as simple, composite, multi-valued, or derived

3. Determine the primary key for each strong entity – underline in the er diagram

4. Identify all relationships between entities and determine cardinality (1:1, 1:M, M:M)

5. Identify weak entities and their identifying relationships – draw with double rectangles and double diamonds

6. Add participation constraints (total/partial) using single or double lines

7. Review and validate the complete er diagram of database against the requirements

DBMS Relationship Types

Relationships are a critical component of the er model in dbms – they define how entities connect and interact within the database. Understanding dbms relationship types is essential for reading any dbms diagram and designing a correct relational schema.

Relationship Type	Symbol in ER Diagram	Description	Key Design Implication
One-to-One (1:1)	1 – 1 on relationship line	Each entity instance on both sides is related to exactly one instance on the other	Foreign key can be placed in either table; consider merging if always 1:1
One-to-Many (1:M)	1 – M on relationship line	One entity instance is related to many on the other side	Foreign key placed in the ‘many’ side table
Many-to-Many (M:M)	M – N on relationship line	Multiple instances on both sides are mutually related	Requires a composite (junction) entity/table to implement

These dbms relationship types directly map to how foreign keys are structured in a relational database. A 1:M relationship means the foreign key goes in the ‘many’ table. An M:M relationship requires a separate junction table – which is the composite entity in the entity relationship model in dbms.

What is an Entity Type in DBMS?

An entity type is the definition or template for a class of entities that share the same attributes and participate in the same relationships. Entity types are the rectangles in an er diagram in dbms – they define the schema, not the data. Individual instances of an entity type are the entities themselves.

Entity Type	Entity Type Classification	Primary Key	Example Instance
Student	Strong entity type	student_id	Mohan Sharma (student_id: S001)
Course_Enrollment	Weak entity type	student_id + course_id (composite)	Enrollment record for S001 in CS101
Course_Student	Composite/Associative entity type	student_id + course_id	Many-to-many resolution table
Email	Multi-valued attribute entity type	email_id + person_id	work@domain.com for Person P001

What is an Entity Set in DBMS?

An entity set in dbms is a collection of all instances (entities) of the same entity type at a given point in time. If an entity type is the schema/definition, the entity set is the actual data – all the rows in a table. Each entity in the set is called an instance.

Property	Entity Set Description
Definition	Collection of all instances of the same entity type
ER model representation	The entity type rectangle represents the set – individual rows are instances
Size	Dynamic – instances are added, modified, or deleted over time
Example	‘Employee’ entity set = all current rows in the Employee table
Key property	Every instance in the set must be uniquely identifiable via the primary key

Types of Entity Sets in DBMS

Entity Set Type	Independence	Key	Example
Strong Entity Set	Independent – exists without any other set	Primary key	Course entity set in a college database
Weak Entity Set	Dependent – requires a parent entity set	Partial key + owner’s primary key	Student_Enroll depends on course_id + student_id
Associative (Junction) Set	Bridge – connects two or more entity sets	Composite primary key from related sets	Project_Work connecting Student and Mentor sets
Recursive (Self-Referencing) Set	Self-referencing – instances relate to other instances of the same set	Primary key	Employee manages Employee (supervisor relationship)

Difference Between an Entity and Entity Set in DBMS

Parameter	Entity	Entity Set
Definition	A single object or idea stored in the database	A collection of all entities of the same type
Existence	Represents one instance – a single row in a table	Represents all instances – the entire table
Analogy	A specific student: Mohan, student_id S001	The ‘Students’ table containing all student records
Attributes	Attributes of that one specific instance	Attributes are the columns – shared structure across all instances
Identification	Identified by its primary key value	Identified by the entity type name
Usage	Store and retrieve a single piece of information	Organise and manage an entire collection of records
ER model role	The data inside the rectangle	The rectangle itself in the er diagram in dbms

ER Diagram of Database – Real-World Examples

Understanding the er diagram of database through real-world scenarios bridges theory and practice. The following examples show how entities, relationships, and dbms relationship types come together in complete database designs.

Example 1: University Database – ER Diagram

Entity	Type	Key Attribute	Relationships
Student	Strong	student_id	Enrolls in Course (M:M via Enrollment), Supervised by Faculty (M:1)
Course	Strong	course_id	Enrolled in by Student (M:M), Taught by Faculty (M:1)
Faculty	Strong	faculty_id	Supervises Student, Teaches Course (1:M)
Enrollment	Composite/Weak	student_id + course_id	Bridges Student and Course (resolves M:M)
Department	Strong	dept_id	Has Faculty (1:M), Offers Course (1:M)

In this er diagram of database: Student and Course have a many-to-many dbms relationship resolved by the Enrollment associative entity. Faculty has a one-to-many relationship with Course (one faculty teaches many courses). Department has a one-to-many relationship with both Faculty and Course. Enrollment is a weak entity in dbms – it cannot exist without both Student and Course.

Example 2: E-Commerce Database – ER Diagram

Entity	Type	Key Attribute	Relationships
Customer	Strong	customer_id	Places Order (1:M), Has Address (1:M)
Order	Weak	order_id + customer_id	Placed by Customer, Contains Products (M:M via Order_Item)
Product	Strong	product_id	Listed by Supplier (M:1), Contained in Orders (M:M)
Order_Item	Composite	order_id + product_id	Junction: resolves Order-Product M:M relationship
Supplier	Strong	supplier_id	Supplies Product (1:M)

This er diagram of database demonstrates all three dbms relationship types: Customer to Order (1:M), Product to Supplier (M:1), and Order to Product (M:M resolved via Order_Item). Order is a weak entity in dbms – it requires a customer_id to be uniquely identified.

DBMS Diagram Summary – ER Diagram Quick Reference

A dbms diagram (specifically an er diagram in dbms) uses standardised notation to represent the full entity relationship model. This quick reference covers all key symbols, what they represent, and when each is used – making it useful for reading any dbms entity relationship diagram.

ER Diagram Element	DBMS Diagram Symbol	When to Use
Strong Entity	Single rectangle	Any entity with its own primary key – most entities
Weak Entity	Double rectangle	Entity that cannot be identified without a parent entity
Simple Attribute	Single oval	Basic, atomic attribute – cannot be subdivided
Primary Key	Underlined oval	The unique identifier of a strong entity
Partial Key	Dashed underlined oval	Partial identifier of a weak entity (used with owner’s key)
Multi-Valued Attribute	Double oval	Attribute that can hold multiple values (email, phone)
Derived Attribute	Dashed oval	Calculated from another attribute – not stored directly
Composite Attribute	Oval with sub-ovals	Attribute built from sub-components (e.g., Name = First + Last)
Relationship	Single diamond	Regular association between two strong entities
Identifying Relationship	Double diamond	Relationship connecting weak entity to its owner
1:1 Relationship Line	1 on both sides of diamond	Exactly one instance on each side
1:M Relationship Line	1 and M on respective sides	One-to-many between entities
M:N Relationship Line	M and N on respective sides	Many-to-many – requires junction table
Total Participation	Double line to diamond	All instances must participate in the relationship
Partial Participation	Single line to diamond	Some instances may not participate

This dbms diagram reference covers all elements of the standard entity relationship model in dbms as defined by Peter Chen’s original notation and the enhanced ER (EER) model extensions. When building a database management system er model, always refer to this notation guide to ensure your er diagram in dbms is correctly and consistently drawn.

Conclusion

An entity in dbms is the foundational concept of all database design – from individual strong entities with their own primary keys, to weak entities that depend on owner entities for identification, to composite entities that resolve many-to-many relationships. Understanding entities and their types is the first step toward building a correct entity relationship model in dbms.

The er model in dbms, visualised through the er diagram in dbms, captures the complete structure of a database – entities, attributes, dbms relationship types, and participation constraints. The dbms entity relationship diagram then serves as the blueprint for translating the conceptual model into a physical relational database schema.

To explore DBMS design further, try the Accelerator Program in Business Analytics and Data Science offered by Hero Vired in collaboration with edX and Harvard University.