ER Model in DBMS – Entities, Attributes, Relationships Complete Guide 2025 | GATE, IBPS

🗄️ Database Management · DBMS Exam 2025

ER Model in DBMS
Entities, Attributes & Relationships

Entity-Relationship Model · Strong & Weak Entities · Simple, Composite, Derived, Multivalued Attributes · Cardinality · Generalization · Specialization · Aggregation · ER Diagram Symbols · Banking Examples · 45 MCQs — GATE, IBPS, SSC, UPSC

GATE CSIBPS POSSC CGLUPSC GS-III NDA/CDSRBI Grade BCampus PlacementsBank Internal

📋 Table of Contents

1. What is the ER Model? 2. ER Diagram Symbols 3. Entities — Strong & Weak 4. Types of Attributes 5. Relationships & Degree 6. Cardinality (1:1, 1:N, M:N) 7. Participation Constraints 8. Generalisation, Specialisation, Aggregation 9. Banking ER Examples 10. Steps to Draw ER Diagram 11. MCQ Practice (45 Qs) 12. Quick Revision Cards

🗺️

Foundation — High Weight in GATE & IBPSWhat is the ER Model?

The Entity-Relationship (ER) Model is a conceptual data model — a high-level blueprint for designing a database. It visually represents the data structure of a system using three core elements: Entities (things), Attributes (properties), and Relationships (links). Proposed by Peter Chen in 1976.

⚡ Core Exam Facts

ER Model = conceptual/logical design tool — not physical implementation
Used before actual database creation — as a blueprint
ER diagrams are later converted to relational tables (normalisation)
Memory mnemonic: EAR = Entities + Attributes + Relationships
Proposed by: Peter Chen, 1976
Primary purpose: communicate database design to stakeholders before coding

🔷

Most Tested in Exams — Know All ShapesER Diagram Symbols

Rectangle

Strong Entity

Represents an entity that exists independently with its own primary key

Student, Bank, Account

Double Rectangle

Weak Entity

Entity that depends on a strong entity for existence. Has no primary key alone

Dependent, Loan_Payment

Oval

Attribute

Represents a property or characteristic of an entity or relationship

Name, Age, Balance

Dashed Oval

Derived Attribute

Attribute calculated from another stored attribute — not directly stored

Age (from DOB)

Double Oval

Multivalued Attribute

Attribute that can hold multiple values for a single entity

Phone Numbers, Skills

Diamond ♦

Relationship

Represents a relationship between two or more entities

WORKS_FOR, ENROLLS

Double Diamond

Identifying Relationship

Relationship that links a weak entity to its owner/identifying strong entity

BELONGS_TO (Dependent)

Underlined Oval

Key Attribute

Attribute that uniquely identifies each entity instance (primary key)

Student_ID, Account_No

Single / Double Line

Participation

Single line = partial participation. Double line = total participation (mandatory)

=Must participate

🎯 Symbols — Quick Exam Reference

Rectangle = Strong Entity | Double Rectangle = Weak Entity
Oval = Attribute | Dashed Oval = Derived Attribute | Double Oval = Multivalued
Underlined Oval = Key Attribute (Primary Key)
Diamond = Relationship | Double Diamond = Identifying Relationship (weak entity)
Single line = Partial participation | Double line = Total participation

📦

Two Types — Both Exam FavouritesEntities — Strong & Weak

An Entity is any real-world object or concept that has data stored about it and can be uniquely identified. Represented by a rectangle in ER diagrams.

□ Strong Entity

Rectangle — Single border

An entity that exists independently — it has its own primary key to uniquely identify each instance. Does not depend on any other entity for its existence.

Existence

Independent

Identifier

Has its own Primary Key

Symbol

Single Rectangle

Banking Examples

Customer, Account, Branch, Loan

▣ Weak Entity

Double Rectangle — Double border

An entity that cannot exist without a strong entity. Has no primary key of its own — identified using a partial key + foreign key of the owner (strong) entity. Its relationship with the owner is called an identifying relationship (double diamond).

Existence

Depends on strong entity

Identifier

Partial key + FK of owner

Symbol

Double Rectangle

Banking Examples

Dependent (of Employee), EMI (of Loan)

Feature	Strong Entity	Weak Entity
Existence	Independent	Depends on strong entity
Primary Key	Has its own PK	No PK — uses partial key + owner FK
Partial Key	Not applicable	Has discriminator (partial key) — underlined with dashed underline
Symbol	Single Rectangle	Double Rectangle
Relationship	Regular diamond	Identifying relationship = Double Diamond
Participation	Partial or Total	Always Total (mandatory)
Banking example	Customer, Account, Branch	Dependent of Employee, EMI of Loan

🏷️

5 Types — All Exam FavouritesTypes of Attributes

Simple Attribute

Oval

Cannot be divided into smaller sub-parts. Atomic single value. The most basic attribute type.

Example: Age, Gender, AccountNo

Composite Attribute

Oval with child Ovals

Can be divided into smaller meaningful sub-parts. Each sub-part is itself an attribute.

Example: Full Name → {First, Middle, Last}

Derived Attribute

Dashed Oval

Value is calculated from another stored attribute. Not directly stored in the database — computed on demand.

Example: Age (from Date_of_Birth), Tenure (from Join_Date)

Multivalued Attribute

Double Oval

Can have multiple values for a single entity. Like a list or set of values per entity.

Example: Phone_Numbers, Email_Addresses, Degrees

Key Attribute

Underlined Oval

Uniquely identifies each entity in the entity set. Becomes the primary key when converted to a table.

Example: Student_ID, Account_Number, EmpID

Attribute Type	ER Symbol	Can Split?	Stored?	Multi-value?	Banking Example
Simple	Oval	No	Yes	No	Account_No, Balance
Composite	Oval + child Ovals	Yes	Yes (sub-parts)	No	Name → {First, Last}
Derived	Dashed Oval	No	No (computed)	No	Age from DOB
Multivalued	Double Oval	No	Yes (multiple)	Yes	Phone_Numbers
Key	Underlined Oval	No	Yes	No	Customer_ID

✅ Attributes — Exam Key Points

Derived = dashed oval = computed (Age from DOB) — NOT stored directly
Multivalued = double oval = multiple values per entity (phone numbers)
Key attribute = underlined oval = uniquely identifies entity = becomes PK in table
Composite = can be split into sub-parts (Name → First + Last)
Simple = cannot be further divided (atomic) — most common type

🔗

Diamond Symbol — Very Frequently TestedRelationships

A Relationship describes an association between two or more entities. Represented by a diamond (♦) in ER diagrams. Relationships can have their own attributes (e.g., the date an employee joined a project).

Term	Meaning	Example
Degree	Number of entities participating in a relationship	Unary (1), Binary (2), Ternary (3)
Unary (degree 1)	An entity related to itself (recursive)	Employee MANAGES Employee
Binary (degree 2)	Two entities related — most common	Customer HAS Account
Ternary (degree 3)	Three entities related in one relationship	Supplier SUPPLIES Product to Project
Cardinality	How many instances of each entity participate	1:1, 1:N, M:N
Relationship attribute	Attribute belonging to the relationship itself	Date_of_Enrollment in ENROLLS relationship

📌 Relationship Degree — Exam Key Points

Degree = number of entities in a relationship (NOT the same as cardinality)
Unary/Recursive: Employee manages Employee (same entity type, related to itself)
Binary = most common type in exams | Ternary = 3 entities
Relationship can also have attributes — e.g., “Enrollment_Date” in Student ENROLLS Course
Relationship symbol = Diamond ♦ | Identifying relationship = Double Diamond

⚖️

1:1, 1:N, M:N — Most AskedCardinality Ratios

1 : 1

One-to-One

Entity A ←→ Entity B

Each instance of Entity A is associated with exactly one instance of Entity B, and vice versa. Rarest cardinality type.

🏦 Banking: A Person HAS one Passport. One Passport belongs to one Person.

1 : N

One-to-Many (Most Common)

Entity A ←→ Entity B₁, B₂, B₃…

One instance of Entity A can be associated with many instances of Entity B, but each B is associated with only one A.

🏦 Banking: One Customer HAS many Accounts. One Branch has many Employees.

M : N

Many-to-Many

Entity A₁,A₂… ↔ Entity B₁,B₂…

Many instances of Entity A can be associated with many instances of Entity B, and vice versa.

🏦 Banking: Many Customers can have many Loan Types. Many Students can ENROLL in many Courses.

🎯 Cardinality — Exam Key Points

1:1 (One-to-One): Passport ↔ Person, Husband ↔ Wife, CEO ↔ Company
1:N (One-to-Many): Teacher → Students, Customer → Accounts, Dept → Employees (MOST COMMON)
M:N (Many-to-Many): Student ↔ Course, Employee ↔ Project, Doctor ↔ Patient
M:N relationship → needs a junction/associative table when converted to relational schema
Degree ≠ Cardinality: Degree = number of entity types; Cardinality = how many instances

🎯

Total vs Partial — Exam DistinctionParticipation Constraints

Participation constraint specifies whether the existence of an entity depends on its being related to another entity through a relationship.

Type	Meaning	Symbol	Example
Total Participation	Every entity instance MUST participate in the relationship (mandatory)	Double line (=====)	Every Loan MUST have a Customer; Every employee MUST work in a department
Partial Participation	Some entity instances may NOT participate in the relationship (optional)	Single line (——)	Not every Customer has a Loan; Not every Employee manages a project

📌 Participation — Exam Key Points

Total = Double line = mandatory — “Every X must be associated with Y”
Partial = Single line = optional — “Some X may not be associated with Y”
A weak entity always has total participation in its identifying relationship
Cardinality + Participation together fully define relationship constraints

🚀

Frequently Tested Advanced ConceptsGeneralisation, Specialisation, Aggregation & Participation

Generalisation

Bottom → Top

Process of extracting common features from multiple lower-level entities and creating a higher-level entity. Combines specifics into a general concept.

Car + Truck + Bus → Vehicle
Savings_Account + Current_Account → Account

Specialisation

Top → Bottom

Process of dividing a higher-level entity into lower-level sub-entities based on distinguishing characteristics. Creates more specific types from a general one.

Employee → Manager + Engineer + Clerk
Account → Savings + Current + NRE

Aggregation

Relationship → Entity

Treats a relationship (set) as a higher-level entity. Used when a relationship needs to participate in another relationship — abstracting the relationship into an entity.

Employee WORKS_ON Project [aggregated] → Manager OVERSEES this aggregate

IS-A Hierarchy

Inheritance

Lower-level entities inherit attributes of the higher-level entity. Also known as IS-A relationship. Supports attribute and relationship inheritance.

Manager IS-A Employee (inherits EmpID, Name, Salary from Employee)

Concept	Direction	Memory Hook	Example
Generalisation	Bottom → Top (upward)	“Combine many → one general”	Car + Truck → Vehicle
Specialisation	Top → Bottom (downward)	“Split one → many specific”	Employee → Manager + Engineer
Aggregation	Relationship → becomes Entity	“Relationship treated as entity”	Project-Employee → Manager oversees
IS-A	Subtype ← Supertype	“Subclass inherits superclass”	Manager IS-A Employee

✅ Advanced Concepts — Exam Tricks

Generalisation = bottom-up (combine low-level into high-level)
Specialisation = top-down (split high-level into sub-entities)
Aggregation = when a relationship itself must relate to another entity
Both generalisation and specialisation result in the same ER structure — only the design process differs
“Vehicle split into Car and Truck” = Specialisation (top-down) | “Car and Truck merged into Vehicle” = Generalisation (bottom-up)

🏦

Banking Context — High Exam RelevanceBanking ER Model Examples

System	Entities	Key Attributes	Relationships	Cardinality
Core Banking	Customer, Account, Branch, Transaction	Customer_ID, Account_No, IFSC_Code, Txn_ID	HAS (Customer-Account), PERFORMED_AT (Account-Branch), RECORDS (Account-Transaction)	1:N, M:N, 1:N
Loan System	Customer, Loan, Branch, EMI (weak)	Customer_ID, Loan_No, Branch_Code, EMI_No	APPLIES_FOR (Customer-Loan), PROCESSED_AT (Loan-Branch), HAS (Loan-EMI)	M:N, M:1, 1:N
Employee HR	Employee, Department, Manager, Dependent (weak)	EmpID, Dept_Code, Dependent_Name	WORKS_IN (Emp-Dept), MANAGES (Emp-Emp), HAS_DEPENDENT (Emp-Dependent)	M:1, 1:N, 1:N
ATM Network	Customer, Card, ATM_Machine, Transaction	Customer_ID, Card_No, ATM_ID, Txn_ID	HOLDS (Customer-Card), PERFORMS (Card-ATM_Transaction), LOCATED_AT (ATM-Branch)	1:1, M:N, M:1

📐 Sample ER Diagram — Bank Customer-Account System

📋

Design ProcessSteps to Draw an ER Diagram

📝

Identify Entities

Look for nouns in the requirements — these are candidate entities

🏷️

List Attributes

For each entity, identify its properties. Mark the key attribute (underline)

🔗

Find Relationships

Look for verbs — MANAGES, HAS, ENROLLS, WORKS_FOR

⚖️

Set Cardinality

Determine 1:1, 1:N, or M:N for each relationship

✏️

Draw with Symbols

Use rectangles, ovals, diamonds, lines with correct notation

📝

Tap Any Option to Reveal AnswerMCQ Practice — 45 Questions (4 Chapters)

Score: 0 / 0

CH.1ER Model Basics & EntitiesQ.01–Q.12

Q.01ER Model🔥 Most Asked

The ER Model was proposed by:

✔ Correct: B — Peter Chen, 1976

The Entity-Relationship (ER) Model was proposed by Peter Chen in 1976. E.F. Codd proposed the relational model. The ER model is a conceptual design tool used before building an actual database.

Q.02ER Model🔥 Most Asked

The ER Model is primarily used for:

✔ Correct: B — Conceptual blueprint before implementation

The ER Model is a conceptual design tool — it provides a visual blueprint for database structure before the actual database is built. ER diagrams are then converted to relational tables (schema).

Q.03Elements🔥 Most Asked

The three core elements of the ER Model are:

✔ Correct: A — Entities, Attributes, Relationships (EAR)

Memory mnemonic: EAR = Entities (things) + Attributes (properties) + Relationships (links). Tables/Columns/Rows belong to the relational model (implementation). ER model is the conceptual design stage.

Q.04Entity🔥 Most Asked

An entity in the ER Model is represented by:

✔ Correct: A — Rectangle

Symbol mapping: Rectangle = Entity | Oval = Attribute | Diamond = Relationship. The most fundamental symbol-to-element mapping in ER diagrams.

Q.05Weak Entity🔥 Most Asked

A weak entity is represented in an ER diagram by:

✔ Correct: B — Double rectangle

Weak entity = Double rectangle. Strong entity = Single rectangle. The double border visually indicates the weak entity’s dependence on another entity. Its identifying relationship is shown by a double diamond.

Q.06Weak Entity🔥 Most Asked

Which of the following is the best example of a weak entity?

✔ Correct: C — Dependent of an Employee

A Dependent cannot exist without its associated Employee — if the employee record is deleted, dependents lose meaning. Student, Book, Product are all strong entities (exist independently).

Q.07Strong Entity🔥 Most Asked

What uniquely identifies a strong entity in an ER diagram?

✔ Correct: C — Its own Primary Key

A strong entity has its own primary key (shown as an underlined oval in ER diagram). A weak entity has no PK — it uses a partial key + foreign key of the owner entity to identify instances.

Q.08Weak Entity🔥 Most Asked

The relationship between a weak entity and its identifying (owner) strong entity is shown by:

✔ Correct: B — Double diamond

The identifying relationship (between weak entity and its owner) = Double Diamond. Regular relationship between two strong entities = Single Diamond. This is a frequently tested distinction.

Q.09Participation🔥 Most Asked

A weak entity always has which type of participation in its identifying relationship?

✔ Correct: B — Total (mandatory) participation

A weak entity always has total participation in its identifying relationship — every instance of the weak entity MUST be associated with a strong entity (it cannot exist without it).

Q.10Symbols🔥 Most Asked

In an ER diagram, a relationship is represented by:

✔ Correct: C — Diamond

Symbol summary: Rectangle = Entity | Oval = Attribute | Diamond = Relationship | Dashed oval = Derived Attribute | Double oval = Multivalued Attribute. This is the most fundamental ER diagram fact.

Q.11Entity🔥 Most Asked

Which of the following is an entity in an ER diagram?

✔ Correct: C — Student

An entity is a real-world object or concept about which data is stored. Student, Employee, Account, Branch are entities. WORKS_FOR is a relationship. Age and Phone_Number are attributes.

Q.12ER Model

Which statement is TRUE about the ER Model?

✔ Correct: B

The ER Model describes data conceptually using entities, attributes, and relationships. It is NOT a physical model (no disk storage details). Tables are the relational model’s representation — ER model comes before that.

CH.2Attributes, Cardinality & DegreeQ.13–Q.26

Q.13Attributes🔥 Most Asked

Which attribute type is represented by a DASHED oval in an ER diagram?

✔ Correct: D — Derived attribute

Attribute symbols: Dashed Oval = Derived Attribute (computed from other data). Double Oval = Multivalued. Underlined Oval = Key. Regular Oval = Simple attribute. Dashed indicates it’s not directly stored.

Q.14Attributes🔥 Most Asked

Which attribute type is represented by a DOUBLE oval?

✔ Correct: B — Multivalued attribute

Double Oval = Multivalued Attribute (can have multiple values per entity — e.g., Phone Numbers, Email addresses). Dashed Oval = Derived. Underlined Oval = Key. Regular Oval = Simple.

Q.15Attributes🔥 Most Asked

Age (calculated from Date of Birth) is an example of which attribute type?

✔ Correct: C — Derived attribute

Derived attribute = calculated from another stored attribute. Age = computed from Date_of_Birth. It is NOT directly stored. Shown with a dashed oval. Other examples: Tenure (from Join_Date), Loan_Remaining (from Loan-EMIs_paid).

Q.16Attributes🔥 Most Asked

Full Name split into First Name, Middle Name, Last Name is an example of which attribute type?

✔ Correct: A — Composite attribute

Composite attribute = can be broken into meaningful sub-parts. Full_Name → {First, Middle, Last}. Address → {Street, City, State, PIN}. In ER diagrams, composite attributes have child ovals branching from the main oval.

Q.17Attributes🔥 Most Asked

A key attribute in an ER diagram is shown as:

✔ Correct: C — Underlined oval

Key attribute = oval with the attribute name underlined. This becomes the primary key when the ER diagram is converted to a relational table. Example: Student_ID, Account_No with underline.

Q.18Attributes

Phone Numbers (a customer may have multiple) is an example of:

✔ Correct: D — Multivalued attribute

Phone Numbers = multivalued attribute — one customer can have multiple phone numbers. Shown with a double oval. When converted to a table, multivalued attributes create a separate table.

Q.19Cardinality🔥 Most Asked

The relationship “A student can enroll in multiple courses, and each course can have multiple students” has cardinality:

✔ Correct: C — Many-to-Many (M:N)

When BOTH sides can have multiple instances → M:N (Many-to-Many). Student enrolls in many courses; each course has many students. M:N relationships need a junction table when converted to relational schema.

Q.20Cardinality🔥 Most Asked

Passport ↔ Person is an example of which cardinality?

✔ Correct: A — One-to-One (1:1)

One person has one passport; one passport belongs to one person → 1:1. Other 1:1 examples: Husband-Wife, CEO-Company. 1:1 is the rarest cardinality in real systems.

Q.21Cardinality🔥 Most Asked

One Teacher can teach many Students, but each Student is taught by one Teacher. This is:

✔ Correct: B — One-to-Many (1:N)

1:N: one entity A maps to many of entity B, but each B maps to only one A. Teacher (1) → Students (N). Also: Customer HAS Accounts, Branch has Employees, Dept has multiple Workers.

Q.22Degree🔥 Most Asked

The “degree” of a relationship refers to:

✔ Correct: A — Number of entity types participating

Degree = number of entity types in a relationship. Unary (1 entity type, recursive), Binary (2 types — most common), Ternary (3 types). Degree ≠ Cardinality: Degree counts entity types; Cardinality counts instances.

Q.23Degree🔥 Most Asked

“Employee MANAGES Employee” is an example of which degree of relationship?

✔ Correct: A — Unary (recursive)

An entity relating to itself = Unary (degree 1) or recursive relationship. “Employee MANAGES Employee” means one employee manages other employees. The same entity participates twice in the relationship.

Q.24Participation🔥 Most Asked

In an ER diagram, TOTAL participation (mandatory) is shown by:

✔ Correct: B — Double line

Total participation = Double line (every entity must participate — mandatory). Partial participation = Single line (some entities may not participate — optional). Double line signals “all members of this set must be in this relationship.”

Q.25Cardinality

In banking, Customer HAS Account relationship has which cardinality?

✔ Correct: B — 1:N

One customer can hold multiple bank accounts (savings, current, FD, etc.) → 1:N. However, each account typically belongs to one primary account holder. A joint account scenario could make it M:N.

Q.26Relationship

In “Employee WORKS_FOR Department”, which element is the relationship?

✔ Correct: B — WORKS_FOR

WORKS_FOR is the relationship (verb/link) — shown as a diamond. Employee and Department are the entities (nouns) — shown as rectangles. Relationships are typically named as verbs: HAS, MANAGES, ENROLLS, TEACHES.

CH.3Generalisation, Specialisation & AggregationQ.27–Q.36

Q.27Generalisation🔥 Most Asked

Generalisation in the ER Model means:

✔ Correct: A — Bottom-up: combining into a higher-level entity

Generalisation = bottom-up process. Combine specific entities (Car, Truck, Bus) into a general entity (Vehicle). Common attributes are “generalised up.” Opposite of Specialisation.

Q.28Specialisation🔥 Most Asked

“Vehicle split into Car, Truck, and Bus” is an example of:

✔ Correct: B — Specialisation

Specialisation = top-down process. Divide one entity (Vehicle) into more specific sub-entities (Car, Truck, Bus). Each sub-entity inherits attributes of the parent and adds its own distinguishing attributes.

Q.29Generalisation🔥 Most Asked

“Car and Truck merged to form Vehicle” is an example of:

✔ Correct: A — Generalisation

Generalisation = bottom-up: multiple specific entities → one general entity. Car + Truck → Vehicle. Common attributes (Engine, Colour, Speed) are moved to the Vehicle superclass. The direction memory trick: “Bottom → Top = Generalisation”.

Q.30Aggregation🔥 Most Asked

Aggregation in the ER Model is used when:

✔ Correct: A — Relationship participates in another relationship

Aggregation = treating a relationship (and its participating entities) as a higher-level entity so it can participate in another relationship. Example: “Employee WORKS_ON Project” aggregated → Manager OVERSEES this entire work arrangement.

Q.31IS-A

In the ER Model, “Manager IS-A Employee” represents:

✔ Correct: C — IS-A hierarchy with inheritance

“Manager IS-A Employee” = Manager is a specialisation of Employee. Manager inherits all attributes of Employee (EmpID, Name, Salary) and adds its own (Department, Reports_To). This is the IS-A (inheritance) hierarchy.

Q.32Advanced🔥 Most Asked

Which pair is CORRECTLY matched?

✔ Correct: B

Generalisation = bottom-up (Car + Truck → Vehicle). Specialisation = top-down (Vehicle → Car, Truck). Aggregation = treating a relationship set as an entity (neither up nor down — lateral abstraction).

Q.33Applied🔥 Most Asked

In a bank, “Account split into Savings Account and Current Account” is an example of:

✔ Correct: B — Specialisation

Account (general) → Savings Account + Current Account (specific) = Specialisation (top-down, dividing into sub-types). Savings has Interest_Rate; Current has Overdraft_Limit — specialised attributes added.

Q.34Applied

In a hospital ER diagram, “Patient undergoes Treatment” — what is Treatment best described as?

✔ Correct: B — Weak entity

Treatment cannot meaningfully exist without the Patient (if a patient’s record is deleted, the treatment records lose context). Treatment is a weak entity with an identifying relationship to Patient (strong entity).

Q.35Cardinality🔥 Most Asked

Many-to-Many (M:N) relationships in ER diagrams, when converted to relational tables, require:

✔ Correct: B — Junction/associative table

M:N relationships cannot be directly represented in two tables. A junction table (also called bridge/associative table) is created with foreign keys from both entity tables. Example: Student_Course table with StudentID + CourseID.

Q.36Applied

In a university system — Student ENROLLS_IN Course — which element is the relationship?

✔ Correct: C — ENROLLS_IN

In ER diagrams: entities = nouns (Student, Course). Relationships = verbs (ENROLLS_IN, MANAGES, TEACHES). The relationship ENROLLS_IN is shown as a diamond connecting the two entity rectangles.

CH.4Applied & Banking-Context QuestionsQ.37–Q.45

Q.37Applied🔥 Most Asked

In a bank ER diagram, what are the entities and relationships for “Customer has Account”?

✔ Correct: A

Correct ER mapping: Entities = Customer (rectangle) + Account (rectangle). Relationship = HAS (diamond). Cardinality = 1:N (one customer can have many accounts). Entity names are nouns; relationship names are verbs.

Q.38Applied🔥 Most Asked

In a bank ER diagram, EMI (installment payment) of a Loan is best modelled as:

✔ Correct: B — Weak entity

An EMI record cannot exist without its parent Loan. If the loan is deleted, all EMI records lose meaning. EMI is identified by (Loan_No + EMI_No) — using the owner loan’s PK + its own partial key. → Weak entity.

Q.39Applied🔥 Most Asked

In a university database, the entities and their relationship are:

✔ Correct: A

Student ENROLLS_IN Course → Entities = Student + Course (rectangles), Relationship = ENROLLS_IN (diamond), Cardinality = M:N (a student takes many courses, each course has many students). Marks could be an attribute of the ENROLLS_IN relationship.

Q.40Applied🔥 Most Asked

Address of an Employee can be broken into Street, City, State, PIN. What type of attribute is Address?

✔ Correct: A — Composite attribute

Address → {Street, City, State, PIN} = Composite attribute (can be split into meaningful sub-parts). Full_Name → {First, Middle, Last} is another classic composite attribute example in exams.

Q.41Applied

Loan_Balance (= original loan amount − total EMIs paid) is an example of:

✔ Correct: C — Derived attribute

Loan_Balance is computed (Loan_Amount − EMIs_paid) from stored values — not directly stored. This makes it a derived attribute, shown with a dashed oval in the ER diagram.

Q.42Applied🔥 Most Asked

Which of the following CORRECTLY describes the ER diagram symbols?

✔ Correct: B — Rectangle = Entity, Diamond = Relationship, Oval = Attribute

The fundamental ER symbol mapping: Rectangle → Entity | Diamond → Relationship | Oval → Attribute. This is the single most tested fact about ER diagrams — memorise it.

Q.43Applied🔥 Most Asked

What is the correct sequence for drawing an ER diagram?

✔ Correct: B

Steps: 1) Identify entities (nouns) → 2) List attributes → 3) Find relationships (verbs) → 4) Set cardinality (1:1, 1:N, M:N) → 5) Draw with correct ER symbols. Normalisation comes AFTER ER design.

Q.44Applied🔥 Most Asked

In an ER diagram for a library system, which is the correct set of entities?

✔ Correct: A

Entities (nouns in problem domain): Book, Member, Librarian. Relationships (verbs): BORROWS (Member-Book), MANAGES (Librarian-Library). Title, ISBN, Author are attributes of Book, not entities themselves.

Q.45Comprehensive🔥 Most Asked

Which statement BEST summarises the purpose and components of the ER Model?

✔ Correct: C

ER Model = conceptual design tool. Entities (rectangles) = things. Attributes (ovals) = properties. Relationships (diamonds) = links. Created BEFORE building the actual database. Later converted to relational tables. Proposed by Peter Chen, 1976.

⚡

Last-Minute PrepQuick Revision Flash Cards

🗺️ ER Model Basics

ER Model = conceptual blueprint for DB design
Proposed by Peter Chen, 1976
3 elements: EAR = Entities + Attributes + Relationships
Used BEFORE actual DB creation

🔷 ER Symbols

Rectangle = Entity (strong)
Double Rectangle = Weak Entity
Oval = Attribute
Dashed Oval = Derived Attribute
Double Oval = Multivalued
Underlined Oval = Key Attribute
Diamond = Relationship
Double Diamond = Identifying Relationship

📦 Entities

Strong: independent, has own PK, single rectangle
Weak: depends on strong entity, no PK alone, double rectangle
Weak uses partial key + FK of owner
Weak always has total participation
Banking: Customer/Account = strong; EMI = weak

🏷️ Attribute Types

Simple = atomic, oval
Composite = divisible (Name → First + Last)
Derived = computed (Age from DOB), dashed oval
Multivalued = multiple values (Phones), double oval
Key = unique identifier, underlined oval

⚖️ Cardinality

1:1 = Passport ↔ Person
1:N = Customer → Accounts (most common)
M:N = Student ↔ Course
M:N needs a junction table in relational schema

🎯 Participation

Total = mandatory = double line (==)
Partial = optional = single line (—)
Weak entity always has total participation

🚀 Advanced Concepts

Generalisation = Bottom-up (Car+Truck → Vehicle)
Specialisation = Top-down (Employee → Manager+Clerk)
Aggregation = Relationship becomes Entity
IS-A = inheritance hierarchy

🏦 Banking ER

Entities: Customer, Account, Loan, Branch, Employee
Weak entities: EMI (of Loan), Dependent (of Employee)
Customer HAS Account = 1:N
Employee WORKS_IN Branch = M:1
Customer APPLIES_FOR Loan = M:N

📌 Must-Know Keywords

Rectangle = EntityOval = Attribute Diamond = RelationshipDashed Oval = Derived Double Oval = MultivaluedUnderlined Oval = Key Double Rectangle = Weak Entity1:N = Most Common Generalisation = Bottom-upSpecialisation = Top-down Aggregation = Relationship as EntityTotal Participation = Double Line

📚 Exam Focus: ER Model = Peter Chen 1976 = conceptual blueprint · EAR = Entities+Attributes+Relationships · Rectangle=Entity, Oval=Attribute, Diamond=Relationship · Double Rectangle=Weak Entity, Double Diamond=Identifying Relationship · Dashed Oval=Derived (Age from DOB), Double Oval=Multivalued (Phone_Numbers), Underlined Oval=Key Attribute · Strong Entity=has own PK, Weak Entity=no PK, uses partial key+FK · Weak entity always has total participation · 1:1=Passport-Person, 1:N=Customer-Accounts (MOST COMMON), M:N=Student-Course · Degree=number of entity types (Unary=1, Binary=2, Ternary=3) · Total participation=double line (mandatory), Partial=single line (optional) · Generalisation=Bottom-up (combine), Specialisation=Top-down (divide) · Aggregation=Relationship treated as Entity · M:N needs junction table

© GyanDesk — ER Model: Entities, Attributes, Relationships | GATE · IBPS · SSC · UPSC · NDA · Bank Exams 2025

Related notes

More free study notes in Information Technology — all part of the GyanDesk study library.

Difference between OSI and TCP IP model

DBMS Vs RDBMS

ACID properties in DBMS

Functional Dependencies in DBMS

DCL: GRANT, REVOKE