ER Diagram and Decision Tables in Software Engineering: Concepts & Examples
Software developers need to understand both data and decision logic before building a system. An ER Diagram helps us understand how important data is structured and related, while a Decision Table helps us understand what action should happen when different conditions occur.
An ER Diagram, or Entity Relationship Diagram, is a graphical model used to represent entities, their attributes and the relationships between them. It is mainly useful when we need to understand the data structure of a system.
A Decision Table is a tabular technique used to represent different combinations of conditions and the actions that should be performed for each combination.
In simple words: ER Diagram explains the data, while Decision Table explains the decision rules.
Why Do Students Find These Topics Confusing?
ER Diagram and Decision Table are normally taught during system analysis and design, but both solve completely different problems.
Students often mix ER Diagram with DFD because both use graphical symbols. They also confuse Decision Tables with flowcharts because both can represent logic.
DFD tells us how data moves.
ER Diagram tells us how data is organised and related.
Decision Table tells us what action should be taken under different conditions.
Part 1: ER Diagram in Software Engineering
What is an ER Diagram?
ER stands for Entity Relationship.
An Entity Relationship Diagram is a visual representation of the important entities in a system, their attributes and the relationships that exist between those entities.
ER diagrams are especially useful when analysing the data requirements of a software system and when preparing for database design.
Suppose a college software system stores information about students and courses.
A Student is an entity.
A Course is another entity.
The Student may enrol in a Course.
“Enrols In” is therefore a relationship between Student and Course.
Why is an ER Diagram Used?
Understand Data
It helps analysts understand what information the software needs to store.
Identify Relationships
It shows how different objects such as students, courses, orders or customers are connected.
Support Database Design
ER modelling provides a conceptual foundation before database tables are created.
Reduce Missing Data
Important entities and attributes can be identified before implementation starts.
Improve Communication
Developers and analysts can discuss the data model using a visual representation.
Find Design Problems Early
Incorrect relationships and missing identifiers can be noticed before coding begins.
Main Components of an ER Diagram
The three basic components of an ER model are:
- Entity
- Attribute
- Relationship
1. Entity
An entity is a real-world object, person, place, event or concept about which information needs to be stored.
An entity should normally represent something that is important to the system.
In traditional ER notation, an entity is generally represented using a rectangle.
Examples of Entities
- Student
- Teacher
- Employee
- Customer
- Product
- Book
- Order
- Department
Entity Type and Entity Instance
These two terms are related but different.
| Term | Meaning | Example |
|---|---|---|
| Entity Type | A category or class of similar entities | Student |
| Entity Instance | One specific member of that entity type | Student ID 101, Rahul |
2. Attribute
An attribute describes a property or characteristic of an entity.
In traditional Chen notation, an attribute is normally represented using an oval.
Example
For the entity Student, possible attributes may include:
- Student ID
- Name
- Date of Birth
- Phone Number
- Address
Types of Attributes in ER Diagram
1. Simple Attribute
A simple attribute cannot normally be divided into meaningful smaller parts.
Example: Gender or Salary.
2. Composite Attribute
A composite attribute can be divided into smaller meaningful attributes.
Address can be divided into:
- House Number
- Street
- City
- State
- PIN Code
3. Single-Valued Attribute
A single-valued attribute normally has one value for a particular entity instance.
Example: Date of Birth.
4. Multivalued Attribute
A multivalued attribute can contain more than one value for the same entity.
A person may have multiple phone numbers, so Phone Number can be modelled as a multivalued attribute in a conceptual ER model.
5. Derived Attribute
A derived attribute is calculated from another stored attribute.
For example, Age can be calculated using the Date of Birth.
6. Key Attribute
A key attribute uniquely identifies an entity instance.
Student ID may uniquely identify each student.
In Chen notation, a key attribute is commonly shown by underlining its name.
Keys in an ER Model
Understanding keys is important because databases need a reliable way to identify records.
| Key Type | Meaning | Example |
|---|---|---|
| Super Key | Any set of attributes that can uniquely identify an entity | Student ID, or Student ID + Email |
| Candidate Key | A minimal key that can uniquely identify the entity | Student ID |
| Primary Key | The candidate key selected as the main identifier | Student ID |
| Alternate Key | A candidate key not selected as the primary key | Email, if unique |
| Composite Key | A key formed using more than one attribute | Student ID + Course ID |
3. Relationship
A relationship represents an association between two or more entities.
In traditional Chen notation, a relationship is represented using a diamond.
Example
Here, a Student enrols in a Course.
Degree of Relationship
The degree of a relationship tells us how many entity types participate in that relationship.
Unary Relationship
A relationship involving one entity type.
Example: An Employee supervises another Employee.
Binary Relationship
A relationship involving two entity types.
Example: Student enrols in Course.
Ternary Relationship
A relationship involving three entity types.
Example: Supplier supplies Product to Project.
Cardinality in ER Diagram
Cardinality tells us how many instances of one entity can be associated with instances of another entity.
This is one of the most important ER Diagram concepts.
1. One-to-One Relationship (1:1)
One instance of Entity A is associated with one instance of Entity B.
One person may have one passport, and one passport belongs to one person within the assumptions of that model.
2. One-to-Many Relationship (1:M)
One instance of Entity A can be related to many instances of Entity B.
One Department can have many Employees.
3. Many-to-One Relationship (M:1)
Many instances of Entity A can be related to one instance of Entity B.
Example: Many Employees can belong to one Department.
4. Many-to-Many Relationship (M:N)
Many instances of one entity can be associated with many instances of another entity.
A Student may enrol in many Courses, and a Course may contain many Students.
Participation Constraint
Participation tells us whether an entity must participate in a relationship.
Total Participation
In total participation, every instance of an entity must participate in the relationship.
Example: If every dependent must belong to an employee, the dependent entity may have total participation in that relationship.
Partial Participation
In partial participation, some entity instances may participate while others may not.
Example: Not every employee has to manage a department.
Strong Entity and Weak Entity
Strong Entity
A strong entity can be uniquely identified using its own key attribute.
Example: Employee with Employee ID.
Weak Entity
A weak entity does not have a complete independent key of its own and depends on another entity for identification.
Consider Employee and Dependent.
A dependent may be identified using information connected with the Employee, together with a partial identifying attribute such as dependent name or number, depending on the model.
Chen Notation vs Crow's Foot Notation
ER diagrams are not always drawn in exactly the same notation. Two common styles are Chen notation and Crow's Foot notation.
| Basis | Chen Notation | Crow's Foot Notation |
|---|---|---|
| Entity | Rectangle | Entity box |
| Attribute | Separate oval | Usually listed inside entity box |
| Relationship | Diamond | Relationship line |
| Cardinality | Numbers or labels may be used | Crow's-foot style marks are commonly used |
| Best For | Conceptual explanation and teaching | Practical database modelling |
Complete ER Diagram Example: College Management System
Suppose we need to design a college management system.
Important entities may include:
- Student
- Course
- Teacher
- Department
Student Attributes
- Student ID
- Name
- Date of Birth
Course Attributes
- Course ID
- Course Name
- Credits
Teacher Attributes
- Teacher ID
- Name
Department Attributes
- Department ID
- Department Name
Possible Relationships
- Student enrols in Course.
- Teacher teaches Course.
- Teacher belongs to Department.
- Course belongs to Department.
This simplified relationship tells us that one student can enrol in many courses, while one course can contain many students.
How to Draw an ER Diagram Step by Step
Understand the System
Read the requirements carefully and understand what information the system needs.
Identify Entities
Find important people, objects, events or concepts such as Student, Product, Order or Employee.
Identify Attributes
Write the properties that describe each entity.
Identify Keys
Find an attribute or combination of attributes that can uniquely identify each entity.
Identify Relationships
Determine how entities are connected with one another.
Decide Cardinality
Decide whether each relationship is one-to-one, one-to-many or many-to-many.
Check Participation
Determine whether participation in a relationship is compulsory or optional.
Review the Model
Check for missing entities, duplicate data concepts, incorrect relationships and unclear keys.
ER Diagram vs Data Flow Diagram
| Basis | ER Diagram | DFD |
|---|---|---|
| Main Focus | Data structure and relationships | Movement of data |
| Main Elements | Entity, attribute, relationship | Entity, process, flow, data store |
| Used For | Data modelling and database planning | System and process analysis |
| Shows Process? | No detailed process flow | Yes |
| Shows Relationship? | Yes, between data entities | Focuses more on flows between system components |
Advantages of ER Diagram
- Easy to understand visually.
- Helps identify important system data.
- Shows relationships clearly.
- Useful before database implementation.
- Improves communication between analysts and developers.
- Helps identify missing data requirements.
- Provides useful design documentation.
Limitations of ER Diagram
- It does not explain detailed program logic.
- It does not show the complete sequence of system operations.
- Large systems can create very complex ER diagrams.
- Different notation styles may confuse beginners.
- Business rules may need additional documentation.
Part 2: Decision Tables in Software Engineering
What is a Decision Table?
A Decision Table is a table used to represent complex business rules by showing different conditions and the actions that should occur for each possible combination of those conditions.
It is useful when a system has many if-then type rules.
A Decision Table answers: “If these conditions are true or false, what action should the software perform?”
Simple Decision Table Example
Suppose an online shopping system provides free delivery only when:
- The customer is a premium member, or
- The order amount is ₹1000 or more.
| Conditions / Actions | Rule 1 | Rule 2 | Rule 3 | Rule 4 |
|---|---|---|---|---|
| Premium Member? | Y | Y | N | N |
| Order ≥ ₹1000? | Y | N | Y | N |
| Give Free Delivery | X | X | X | — |
| Charge Delivery Fee | — | — | — | X |
Here each column represents one possible rule.
Structure of a Decision Table
A standard decision table can be understood using four basic sections:
1. Condition Stub
Lists the conditions that affect the decision.
2. Condition Entries
Shows the value of each condition for different rules.
3. Action Stub
Lists the actions that the system may perform.
4. Action Entries
Shows which action is performed under each rule.
What is a Rule in a Decision Table?
A rule represents one possible combination of conditions and the action that should result from that combination.
Each vertical rule column answers one complete decision case.
Premium Member = No
Order Amount ≥ ₹1000 = No
Result = Charge Delivery Fee
This complete combination forms one decision rule.
How Many Rules Can a Decision Table Have?
If every condition has only two possible values, such as Yes or No, the maximum number of combinations can be calculated as:
where n is the number of binary conditions.
Example
If there are 3 Yes/No conditions:
23 = 8 possible combinations.
So the complete table can have up to 8 rule columns before simplification.
This 2n shortcut applies when all conditions are binary. If a condition has more than two possible values, the total number of combinations depends on the number of possible values for each condition.
Types of Decision Tables
1. Limited-Entry Decision Table
A limited-entry decision table uses simple binary condition values such as:
- Yes / No
- True / False
- Y / N
It is useful when every condition has only two possible states.
2. Extended-Entry Decision Table
An extended-entry decision table allows conditions to contain more detailed values instead of only Yes or No.
Customer Type: Regular / Premium / Corporate
Order Amount: Below ₹500 / ₹500–₹1000 / Above ₹1000
3. Mixed-Entry Decision Table
A mixed-entry decision table combines binary values and extended values.
For example:
- Premium Member? Yes / No
- Payment Mode: UPI / Card / Cash
What Does “–” Mean in a Decision Table?
A dash or “don't care” entry means that the value of a particular condition does not affect the action for that rule.
If an account is already blocked, the customer's transaction amount may not matter.
In such a rule, Transaction Amount can be marked with a dash because the result remains the same.
Don't-care values can help simplify a large decision table.
How to Construct a Decision Table Step by Step
Understand the Decision
Identify exactly what business or software decision must be represented.
Identify Conditions
List every condition that can affect the final decision.
Identify Possible Values
Decide whether conditions use Yes/No, True/False or multiple values.
Calculate Possible Combinations
Create rule columns for the combinations that need to be analysed.
Identify Actions
List every possible action the software may perform.
Assign Actions to Rules
For each condition combination, mark which action should be performed.
Check Completeness
Make sure important possible cases have not been forgotten.
Check for Conflicts
Make sure the same condition combination does not produce contradictory actions.
Remove Redundant Rules
Similar rules may sometimes be combined using a don't-care condition.
Complete Decision Table Example: Student Exam Eligibility
Suppose a college allows a student to appear in an examination only when:
- Attendance is sufficient.
- Exam fee has been paid.
If attendance is insufficient, the student needs special permission.
| Conditions / Actions | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Attendance Sufficient? | Y | Y | N | N |
| Exam Fee Paid? | Y | N | Y | N |
| Allow Exam | X | — | — | — |
| Ask to Pay Fee | — | X | — | X |
| Require Attendance Permission | — | — | X | X |
Understanding the Rules
Rule 1: Attendance sufficient + Fee paid → Student may appear in the exam.
Rule 2: Attendance sufficient + Fee not paid → Student must pay the fee.
Rule 3: Attendance insufficient + Fee paid → Attendance permission is required.
Rule 4: Attendance insufficient + Fee not paid → Both issues must be handled.
Quality Checks in a Decision Table
1. Completeness
A decision table is complete when all important condition combinations are represented.
Missing a valid combination may mean that the software has no defined behaviour for that situation.
2. Consistency
A decision table should not give conflicting actions for the same exact condition combination.
3. Redundancy
Two rules are redundant when they effectively describe the same decision and can be simplified without changing the required behaviour.
A decision table is not useful only because it looks organised. Its real value comes from helping analysts discover missing, conflicting and unnecessary business rules before those rules are implemented in code.
Decision Table vs Decision Tree
| Basis | Decision Table | Decision Tree |
|---|---|---|
| Format | Rows and columns | Branching tree |
| Best For | Many combinations of conditions | Sequential decisions |
| Reading Style | Compare rule columns | Follow branches |
| Complex Rules | Often compact and systematic | Can become large when many branches exist |
| Main Strength | Checking combinations and completeness | Showing decision sequence visually |
Decision Table vs Flowchart
| Basis | Decision Table | Flowchart |
|---|---|---|
| Main Focus | Conditions and resulting actions | Sequence and control flow |
| Representation | Table | Graphical symbols and arrows |
| Useful When | Many business-rule combinations exist | Steps must be shown in sequence |
| Rule Coverage | Easier to compare condition combinations | Can be harder to inspect when many decisions exist |
Advantages of Decision Tables
Clear Rules
Complex conditions become easier to understand.
Find Missing Cases
Analysts can see whether a condition combination has been ignored.
Detect Conflicts
Contradictory business rules become easier to notice.
Useful for Testing
Rule columns can help identify useful test scenarios.
Easy Communication
Developers and business users can discuss rules in a structured format.
Reduces Ambiguity
Conditions and actions are written more explicitly.
Limitations of Decision Tables
- Large numbers of conditions can create many rule combinations.
- Very large tables may become difficult to read.
- Decision tables do not naturally show time sequence.
- They are not ideal for every type of algorithm.
- Conditions must be written carefully to avoid ambiguity.
When Should We Use a Decision Table?
Decision tables are especially useful when:
- Several conditions affect one decision.
- Different condition combinations produce different actions.
- Business rules are becoming difficult to explain using normal paragraphs.
- The team needs to check whether all important cases are covered.
- Test cases need to be created from business rules.
How ER Diagrams and Decision Tables Work Together
ER diagrams and decision tables solve different problems, but both can support requirements analysis and system design.
An ER Diagram may show:
- Customer
- Order
- Product
- Payment
A Decision Table may separately decide:
- Whether a discount is allowed.
- Whether delivery is free.
- Whether payment should be accepted.
- Whether an order requires manual review.
ER Diagram vs Decision Table
| Basis | ER Diagram | Decision Table |
|---|---|---|
| Main Purpose | Model system data | Model decision logic |
| Representation | Graphical diagram | Tabular representation |
| Main Components | Entity, Attribute, Relationship | Conditions, Rules, Actions |
| Question Answered | How is data related? | What should happen under these conditions? |
| Useful For | Conceptual data and database design | Complex business-rule analysis |
Common Mistakes Students Make
Mistake 1: Treating ER Diagram Like DFD
ER Diagram shows entities and relationships. DFD shows movement of data through processes.
Mistake 2: Forgetting Cardinality
Writing entities and relationships without deciding whether they are 1:1, 1:M or M:N gives an incomplete understanding of the relationship.
Mistake 3: Using an Attribute as an Entity
Ask whether the item has its own meaningful identity and relationships. Not every data value should become a separate entity.
Mistake 4: Forgetting Primary Identification
Important entity types should normally have a way to uniquely identify instances.
Mistake 5: Writing Only One Decision Rule
A decision table should analyse the required combinations of conditions, not just the easiest case.
Mistake 6: Missing a Condition Combination
Missing rules may lead to undefined behaviour in the actual software.
Mistake 7: Conflicting Actions
The same exact condition combination should not accidentally result in contradictory actions.
Exam-Oriented Definition of ER Diagram
An Entity Relationship Diagram is a graphical model used to represent entities, their attributes and the relationships among them. It is used during data modelling and helps in understanding the data requirements of a software system.
Exam-Oriented Definition of Decision Table
A Decision Table is a tabular representation of decision logic in which different combinations of conditions are associated with the actions that should be performed for those combinations.
5 Marks: Explain Components of ER Diagram
- Entity: Represents a real-world object or concept.
- Attribute: Represents a property of an entity.
- Relationship: Represents an association between entities.
- Cardinality: Defines how many instances of entities may participate in a relationship.
- Keys: Help uniquely identify entity instances.
5 Marks: Explain Decision Table
A decision table represents conditions and actions in tabular form. Its main parts are condition stub, condition entries, action stub and action entries. Each rule column represents one condition combination and its resulting action. Decision tables are especially useful for analysing complex business rules and identifying missing or conflicting cases.
10 Marks: ER Diagram Long Answer Structure
For a long-answer question, use this sequence:
- Define ER Diagram.
- Explain its purpose.
- Explain Entity.
- Explain Attribute and its types.
- Explain Relationship.
- Explain Cardinality.
- Explain Participation.
- Explain Strong and Weak Entity.
- Draw one complete ER example.
- Write advantages and conclusion.
10 Marks: Decision Table Long Answer Structure
- Write the definition.
- Explain why decision tables are required.
- Explain condition stub.
- Explain condition entries.
- Explain action stub.
- Explain action entries.
- Explain rules.
- Explain types of decision tables.
- Draw one complete decision table.
- Write advantages and limitations.
Easy Memory Tricks
Entity → Attribute → Relationship
Use this to remember the basic ER model.
Conditions → Rules → Actions
Use this to understand Decision Tables quickly.
Quick Revision Notes
ER Diagram
- ER stands for Entity Relationship.
- An ER Diagram represents data entities and their relationships.
- Entity is normally represented by a rectangle in Chen notation.
- Attribute is normally represented by an oval.
- Relationship is normally represented by a diamond.
- A key attribute helps uniquely identify an entity.
- Attributes can be simple, composite, single-valued, multivalued or derived.
- Cardinality describes how many entity instances participate in a relationship.
- Main cardinalities are 1:1, 1:M and M:N.
- Total participation means every entity instance must participate.
- Partial participation means participation is optional for some instances.
- A weak entity depends on another entity for identification.
- Chen and Crow's Foot are two common ER notation styles.
Decision Table
- A Decision Table represents conditions and actions.
- Each column normally represents a decision rule.
- Main parts are condition stub, condition entries, action stub and action entries.
- Limited-entry tables commonly use Yes/No conditions.
- Extended-entry tables allow more detailed condition values.
- Mixed-entry tables combine both styles.
- A dash can represent a don't-care condition.
- For n binary conditions, maximum combinations may be 2n.
- Decision tables should be checked for completeness, consistency and redundancy.
- Decision tables are useful for business-rule analysis and test-case design.
Frequently Asked Questions
What is an ER Diagram in Software Engineering?
An ER Diagram is a graphical representation of entities, their attributes and relationships. It helps model the data requirements of a software system.
What are the main components of an ER Diagram?
The main components are Entity, Attribute and Relationship. Cardinality, participation and keys provide additional modelling detail.
What is cardinality in an ER Diagram?
Cardinality defines how many instances of one entity can be associated with instances of another entity, such as one-to-one, one-to-many or many-to-many.
What is a weak entity?
A weak entity cannot be fully identified independently and depends on another related entity for identification.
What is a multivalued attribute?
A multivalued attribute can contain multiple values for one entity, such as several phone numbers for one person.
What is a derived attribute?
A derived attribute is calculated from other data. Age calculated from Date of Birth is a common example.
What is the difference between ER Diagram and DFD?
An ER Diagram focuses on data structure and relationships, while a DFD focuses on the movement of data through processes.
What is a Decision Table?
A Decision Table is a tabular representation of conditions, condition combinations and the actions that should be performed for those combinations.
What are the main parts of a Decision Table?
The four major parts are condition stub, condition entries, action stub and action entries.
What is a rule in a Decision Table?
A rule is one specific combination of conditions together with the action or actions that should be performed for that combination.
What is a limited-entry Decision Table?
A limited-entry Decision Table generally uses binary condition values such as Yes/No or True/False.
What is an extended-entry Decision Table?
An extended-entry Decision Table allows conditions to use values beyond simple Yes/No choices.
What is the difference between a Decision Table and Decision Tree?
A Decision Table represents combinations of conditions using rows and columns, while a Decision Tree represents decisions using branches.
Why are Decision Tables useful in software testing?
Each important decision rule can represent a useful test situation, helping testers cover different combinations of business conditions.
Conclusion
ER Diagrams and Decision Tables are two useful modelling techniques in software engineering, but they solve different problems.
An ER Diagram helps us understand the data structure of a system. It identifies entities, their attributes, keys, relationships, cardinalities and participation constraints.
A Decision Table helps us understand decision logic. It organises conditions, rules and actions so that complex business requirements can be analysed clearly.
For ER Diagrams, remember: Entity → Attribute → Relationship → Cardinality.
For Decision Tables, remember: Conditions → Rules → Actions.
ER Diagram = What data exists and how is it related?
Decision Table = Under these conditions, what should the system do?
