0% found this document useful (0 votes)
25 views

DBMS Quiz

The document provides a comprehensive overview of Entity-Relationship (ER) and Enhanced Entity-Relationship (EER) diagrams, detailing their components, key concepts, and case studies in various domains such as university and hospital management systems. It outlines the process of transforming EER diagrams into relational schemas, including mapping entities, relationships, and constraints. Additionally, it discusses steps for database project planning, normalization, and implementation to ensure effective database management system (DBMS) preparation.

Uploaded by

hydrinairis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
25 views

DBMS Quiz

The document provides a comprehensive overview of Entity-Relationship (ER) and Enhanced Entity-Relationship (EER) diagrams, detailing their components, key concepts, and case studies in various domains such as university and hospital management systems. It outlines the process of transforming EER diagrams into relational schemas, including mapping entities, relationships, and constraints. Additionally, it discusses steps for database project planning, normalization, and implementation to ensure effective database management system (DBMS) preparation.

Uploaded by

hydrinairis
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 18

Week # 03

ER-Diagram Problems & Case Studies


 Entity-Relationship (ER) Diagram
ER diagrams are used to visually represent database structures, showing entities, attributes,
and relationships. These diagrams help in designing and understanding complex databases by
illustrating how entities interact with each other.
 Key Components of ER Diagrams:
1. Entities: Objects or things in the database that have a distinct existence (e.g., Student,
Course, Employee). These can be categorized into:
o Strong Entities: Exist independently in the database and have a primary key.
o Weak Entities: Depend on a strong entity and lack a primary key.
2. Attributes: Characteristics of an entity, further classified as:
o Simple (Atomic) Attributes: Indivisible values (e.g., Age, Name).
o Composite Attributes: Can be divided into smaller subparts (e.g., Full Name
→ First Name, Last Name).
o Derived Attributes: Derived from other attributes (e.g., Age from Date of
Birth).
o Multi-valued Attributes: Can have multiple values (e.g., Phone Numbers of a
person).
3. Primary Key: A unique identifier for each entity instance (e.g., Student_ID,
Employee_ID).
4. Relationships: Associations between entities, categorized as:
o One-to-One (1:1): Each entity in set A is related to at most one entity in set B.
o One-to-Many (1:M): One entity in set A is related to multiple entities in set B.
o Many-to-Many (M:N): Many entities in set A are related to many entities in
set B.
5. Cardinality: Defines the number of entities that can participate in a relationship.
6. Participation: Specifies whether all instances of an entity set are involved in a
relationship.
o Total Participation: Every entity instance must participate in the relationship.
o Partial Participation: Some instances may not participate.

 Case Study: University Database


 Entities: Student, Professor, Course, Department
 Relationships: "Enrolls" (Student-Course), "Teaches" (Professor-Course), "Belongs
To" (Course-Department)
 Attributes:
o Student: (ID, Name, Age, Email, Address)
o Course: (Code, Title, Credits)
o Professor: (ID, Name, Specialization, Department)

The Enhanced ER Model (EER Model)


The Enhanced ER Model extends the traditional ER model with additional concepts like
specialization, generalization, inheritance, and constraints.
 Key Concepts:
1. Super type & Subtype Representation:
o Super type: A general entity that has subtypes (e.g., Employee → Full-Time
& Part-Time Employees)
o Subtype: A specialized version of the super type with unique attributes.
2. Attribute Inheritance:
o Subtypes inherit all attributes and relationships of the super type.
3. Specialization & Generalization:
o Specialization: The process of creating subtypes from a super type (e.g.,
Employee → Manager, Engineer).
o Generalization: The process of combining subtypes into a super type (e.g.,
Car & Truck → Vehicle).
4. Completeness Constraints:
o Total Specialization Rule: Every instance of a super type must be in at least
one subtype.
o Partial Specialization Rule: Some instances of the super type may not belong
to any subtype.
5. Disjointness Constraints:
o Disjoint Rule: An entity can belong to only one subtype.
o Overlap Rule: An entity can belong to multiple subtypes.
6. Subtype Discriminator:
o An attribute that determines to which subtype an entity belongs (e.g.,
Employee_Type: 'FT' for Full-Time, 'PT' for Part-Time).
7. Super type / Subtype Hierarchy:
o A structured hierarchy where subtypes inherit attributes from the super type.
o Ensures that all inherited attributes remain consistent across subtypes.
8. Entity Clustering:
o Groups related entities into a single entity to simplify complex ER diagrams.

EER-Diagram Problems & Case Studies


 Case Study: Hospital Management System
 Super type: Patient
 Subtypes: Inpatient, Outpatient
 Attributes:
o Common: Name, Age, Contact, Address
o Inpatient: Admission Date, Room Number, Discharge Date
o Outpatient: Visit Date, Consulting Doctor
 Relationships: "Admitted" (Inpatient-Hospital), "Consults" (Outpatient-Doctor)
 Constraints: Disjoint constraint (a patient can be either Inpatient or Outpatient, not
both).
 Case Study: Banking System
 Super type: Account
 Subtypes: Savings Account, Checking Account
 Attributes:
o Common: Account_Number, Holder_Name, Balance
o Savings: Interest Rate
o Checking: Overdraft Limit
 Relationships: "Operated by" (Customer-Account), "Linked to" (Account-Branch)
 Disjoint Constraint: An account can either be a Savings or Checking account, but
not both.
These notes provide a detailed and structured approach to understanding and applying ER
& EER diagrams effectively for your DBMS quiz preparation.
Week # 04
Transforming EER Diagrams into Relations

When converting an Enhanced Entity-Relationship (EER) Diagram into a relational


schema, each component must be mapped carefully to maintain data integrity and
relationships.

1. 1. Mapping Regular Entities

 Each regular entity is transformed into a relational table.


 The attributes become columns.
 The primary key of the entity becomes the primary key of the table.

2. 2. Mapping Weak Entities

 Weak entities depend on a strong entity and lack a primary key.


 Create a separate relation for the weak entity.
 Add a foreign key that references the primary key of the strong entity.
 Use the combination of the weak entity’s attributes and the foreign key as the
primary key.

3. 3. Mapping Associative Entities

 If an associative entity has attributes, create a separate relation.


 Include foreign keys referencing the related entities.
 If no attributes exist, represent it as a many-to-many (M:N) relationship table.

4. 4. Mapping Unary Relations

Unary One-to-One (1:1)

 Add a foreign key in the same table that references its own primary key.

Unary Many-to-Many (M:N)

 Create a separate table with two foreign keys, both referencing the same entity.

5. 5. Mapping Binary Relations

One-to-One (1:1)

 Add a foreign key in one of the tables.


 If participation is total, ensure the foreign key is NOT NULL.
One-to-Many (1:M)

 Place the foreign key on the “many” side.


 The foreign key references the primary key of the “one” side.

Many-to-Many (M:N)

 Create a junction table that includes:


o Two foreign keys referencing both entities.
o Additional attributes (if any) related to the relationship.

6. 6. Mapping Ternary Relations

 Create a new relation (table) that includes foreign keys from all three participating
entities.
 Add any relationship attributes to this table.

7. 7. Mapping Super type / Subtype Relationship

There are two common methods to map super type/subtype relationships:

Option 1: Create Separate Tables

 Create a table for the super type (with common attributes).


 Create separate tables for each subtype (with unique attributes).
 Use the same primary key in the subtype tables as in the super type table.

Option 2: Single Table with Discriminator Column

 Store both super type and subtype attributes in a single table.


 Add a discriminator column to differentiate between subtypes.

8. 8. Merging Relations

 If multiple relations share a one-to-one (1:1) relationship, consider merging them


into a single table.
 Redundant attributes should be minimized to avoid data redundancy.

Project Discussion
9. Steps in Database Project Planning

1. Identify Requirements
o Understand the business rules and data needs.
o Identify entities, attributes, relationships, and constraints.

2. Create ER and EER Diagrams


o Develop an ER model to visualize the database structure.
o Extend it to EER model if needed (specialization/generalization).

3. Convert ER/EER to Relational Schema


o Apply the transformation rules discussed above.

4. Normalization
o Apply normalization techniques (1NF, 2NF, 3NF, BCNF) to reduce
redundancy.

5. Database Implementation
o Choose a DBMS (e.g., MySQL, PostgreSQL, Oracle).
o Write SQL scripts to create tables, define constraints, and establish
relationships.

6. Testing and Optimization


o Test queries to ensure data integrity.
o Optimize queries for better performance.

These detailed notes will help you prepare effectively for your DBMS quiz. Let me know if
you need more explanations or examples! 🚀📚
Final Revision
1. ER-Diagram Problems & Case Studies
10. Entity-Relationship (ER) Diagram Overview

An ER diagram is a graphical representation of entities, their attributes, and relationships


between them. It helps in designing a structured database schema.

11. Components of ER Diagrams

1. Entities
o Real-world objects represented as rectangles in ER diagrams.
o Example: A university database may have entities like Student, Course, and
Professor.

2. Attributes
o Characteristics of an entity represented by ellipses.
o Example: A Student entity may have attributes: ID, Name, Age, and Email.
o Types of attributes:
 Simple (Atomic): Cannot be divided further (e.g., Age, Roll Number).
 Composite: Can be divided into sub-parts (e.g., Full Name → First
Name, Last Name).
 Derived: Computed from another attribute (e.g., Age from DOB).
 Multi-valued: An entity can have multiple values for the attribute
(e.g., Phone Numbers).

3. Primary Key
o A unique identifier for each entity instance.
o Example: A Student’s primary key can be Student_ID.

4. Relationships
o Represent associations between entities using diamonds.
o Example: A Student "Enrolls in" a Course.

5. Cardinality
o Specifies the number of entity instances in a relationship.
o Example:
 1:1 - Each person has one passport.
 1:M - A professor teaches multiple students.
 M:N - Students can enroll in multiple courses, and each course can
have multiple students.

12. Case Study: Library Management System

Entities:

 Book (ISBN, Title, Author, Publisher)


 Member (Member_ID, Name, Address, Phone)
 Librarian (Librarian_ID, Name, Salary)
 Transaction (Transaction_ID, Issue_Date, Due_Date)

Relationships:

 Member borrows Book (1:M)


 Librarian manages Transactions (1:M)
 Book belongs to Publisher (M:1)

Example ER Diagram Representation:

 Book → ISBN (Primary Key), Title, Author, Publisher


 Member → Member_ID (Primary Key), Name, Address, Phone
 Transaction → Transaction_ID (Primary Key), Issue_Date, Due_Date, Member_ID
(Foreign Key), ISBN (Foreign Key)

2. The Enhanced ER (EER) Model

The Enhanced Entity-Relationship (EER) Model is an extension of the ER model with


advanced features.

13. Key Features:

1. Super type & Subtype


o A super type is a general entity.
o A subtype is a specialized version of the super type.
o Example:
 In a banking system, an "Account" can be either a "Savings
Account" or a "Checking Account."
 Account (Super type) → Savings Account & Checking Account
(Subtypes).

2. Attribute Inheritance
o Subtypes inherit all attributes from the super type.
o Example:
 Employee (Super type) → Manager & Engineer (Subtypes).
 Attributes like Employee_ID and Name are inherited by both
subtypes.

3. Specialization vs. Generalization


o Specialization: Splitting a super type into subtypes.
 Example: A "Vehicle" can be specialized into "Car" and "Truck".
o Generalization: Combining multiple subtypes into a super type.
 Example: "Doctor" and "Nurse" can be generalized into "Medical
Staff".
4. Constraints in EER
o Completeness Constraints
 Total Specialization Rule: Every entity must belong to a subtype (e.g.,
every Account is either Savings or Checking).
 Partial Specialization Rule: Some entities may not belong to a
subtype (e.g., some Employees don’t belong to a specific category).
o Disjointness Constraints
 Disjoint Rule: An entity belongs to only one subtype.
 Overlap Rule: An entity can belong to multiple subtypes.

14. Case Study: Hospital Management System

Super type: Patient

Subtypes: Inpatient, Outpatient

Attributes:

 Common: Patient_ID, Name, Age, Address


 Inpatient-specific: Admission Date, Room Number
 Outpatient-specific: Visit Date, Consulting Doctor

Relationships:

 Patient “Admitted to” Hospital


 Outpatient “Consults” Doctor

3. Transforming EER Diagram into Relations


15. Steps for Mapping EER Diagrams to Relational Tables

1. Mapping Regular Entities


o Create a separate table for each entity.
o The primary key is used to uniquely identify each row.
o Example:
o STUDENT (Student_ID, Name, Age, Email)

2. Mapping Weak Entities


o Create a separate table with a foreign key linking it to the strong entity.
o The primary key is a combination of the foreign key and its own key.
o Example:
o DEPENDENT (Dependent_ID, Name, Relationship, Employee_ID (FK))

3. Mapping Associative Entities


o If the associative entity has attributes, create a new table.
o Example:
o ENROLLS (Student_ID (FK), Course_ID (FK), Enrollment_Date)
4. Mapping Unary Relations
o Unary One-to-One (1:1): Add a foreign key in the same table.
o Unary Many-to-Many (M:N): Create an intersection table.
o Example:
o EMPLOYEE (Emp_ID, Name, Manager_ID (FK))

5. Mapping Binary Relations


o One-to-One (1:1): Place a foreign key in one of the tables.
o One-to-Many (1:M): Place the foreign key on the "many" side.
o Many-to-Many (M:N): Create a junction table.

6. Mapping Ternary Relations


o Create a separate table with foreign keys referencing all three entities.
o Example:
o SUPPLY (Supplier_ID (FK), Product_ID (FK), Warehouse_ID (FK),
Quantity)

7. Mapping Super type / Subtype Relationship


o Option 1: Separate Tables
 Example:
 EMPLOYEE (Emp_ID, Name, Salary)
 MANAGER (Emp_ID (FK), Bonus)
 ENGINEER (Emp_ID (FK), Specialization)
o Option 2: Single Table with Discriminator Column
o EMPLOYEE (Emp_ID, Name, Salary, Type, Bonus, Specialization)

4. Project Discussion
16. Steps to Design a Database Project

1. Identify Requirements
o Define the scope and business rules.

2. Create ER/EER Diagrams


o Model entities, attributes, and relationships.

3. Convert ER/EER to Relations


o Apply mapping techniques to relational schema.

4. Normalization
o Remove redundancy using 1NF, 2NF, 3NF, BCNF.

5. Implementation in DBMS
o Write SQL queries to create and manage tables.

6. Testing & Optimization


o Check for data integrity and optimize performance.
Potential Questions
 DBMS Quiz (10 Marks) - Questions and Answers

 Q1. Explain the process of mapping a regular entity into a relational


schema. (2 Marks)

Answer:

Mapping a regular entity into a relational schema involves the following steps:

1. Identify the Entity → Determine the entity and its attributes.


2. Create a Table → Convert the entity into a relational table.
3. Define the Primary Key → Choose an attribute (or a combination) that uniquely
identifies each row.
4. Define Attributes → Convert all attributes of the entity into columns of the table.

💡 Example:
Consider an entity Student (Student_ID, Name, Age, Address)

 The relational schema would be:


 CREATE TABLE Student (
 Student_ID INT PRIMARY KEY,
 Name VARCHAR(50),
 Age INT,
 Address VARCHAR(100)
 );
 Here, Student_ID is the Primary Key.

 Q2. How do you map a weak entity into relations? Explain with an
example. (2 Marks)

Answer:

A weak entity does not have a primary key and depends on a strong entity. The steps to map
it into a relation are:

1. Create a table for the weak entity → Include all attributes.


2. Add a foreign key → Reference the strong entity.
3. Combine with a partial key → Ensure uniqueness.

💡 Example:
Consider Dependent (Dependent_Name, Age, Relationship, Employee_ID), where
Employee_ID is from the strong entity Employee (Emp_ID, Name, Salary).
 Relational Schema:
 CREATE TABLE Employee (
 Emp_ID INT PRIMARY KEY,
 Name VARCHAR(50),
 Salary DECIMAL(10,2)
 );

 CREATE TABLE Dependent (
 Dependent_Name VARCHAR(50),
 Age INT,
 Relationship VARCHAR(30),
 Employee_ID INT,
 PRIMARY KEY (Dependent_Name, Employee_ID),
 FOREIGN KEY (Employee_ID) REFERENCES Employee(Emp_ID)
 );
 The Primary Key for Dependent is a combination of Dependent_Name and
Employee_ID.

 Q3. Explain the concept of super type and subtype with an example. (2
Marks)

Answer:

 Super type: A general entity that contains common attributes.


 Subtype: A specialized version of the super type with additional attributes.

💡 Example:
Consider an Employee entity with two subtypes Manager and Technician.

 Super type: Employee (Emp_ID, Name, Salary)


 Subtypes:
o Manager (Emp_ID, Bonus, Department)
o Technician (Emp_ID, Skill_Set, Certification)

Diagram Representation:

Employee (Emp_ID, Name, Salary)


/ \
Manager Technician
(Bonus, Department) (Skill_Set, Certification)

 Q4. Differentiate between specialization and generalization. (2 Marks)

Answer:

Feature Specialization Generalization


Breaking down a super type into multiple Combining multiple entities into a
Definition
subtypes. single super type.
Direction Top-down approach. Bottom-up approach.
Feature Specialization Generalization
Example Employee → Manager, Technician. Car, Truck → Vehicle.
Used for handling different specific
Purpose Used to unify common attributes.
attributes of subtypes.

💡 Example:

 Specialization: Employee → Full-time Employee, Part-time Employee.


 Generalization: Savings Account, Checking Account → Bank Account.

 Q5. What are the completeness constraints in EER diagrams? Explain


with examples. (2 Marks)

Answer:

Completeness constraints define whether an instance of a super type must be a member of a


subtype.

1. Total Specialization Rule (Double Line):


o Every entity in the super type must belong to at least one subtype.
o Example: A Vehicle must be either a Car or a Truck.
2. Partial Specialization Rule (Single Line):
o Some instances of the super type may not belong to any subtype.
o Example: An Employee may be a Manager or a Technician, but some
employees may not belong to any subtype.

💡 Example Representation:

Vehicle (Total Specialization)


/ \
Car Truck

Here, every vehicle must be either a Car or Truck (Total Specialization).

Employee (Partial Specialization)


/ \
Manager Technician

Here, an employee may be a Manager or Technician, but some employees might not belong
to any subtype.

 Q6. How is a super type/subtype relationship mapped into relations? (2


Marks)

Answer:
There are three approaches to map a super type/subtype relationship into a relational
schema:

1. Single Table (One Table for All)


o One table includes all attributes of both super type and subtypes.
o Disadvantage: Wastes space if many NULL values exist.
2. CREATE TABLE Employee (
3. Emp_ID INT PRIMARY KEY,
4. Name VARCHAR(50),
5. Salary DECIMAL(10,2),
6. Bonus DECIMAL(10,2), -- Only for Managers
7. Skill_Set VARCHAR(50) -- Only for Technicians
8. );
9. Separate Tables for Each Subtype
o The super type and each subtype have separate tables.
o Advantage: Avoids NULL values.
10. CREATE TABLE Employee (
11. Emp_ID INT PRIMARY KEY,
12. Name VARCHAR(50),
13. Salary DECIMAL(10,2)
14. );
15.
16. CREATE TABLE Manager (
17. Emp_ID INT PRIMARY KEY,
18. Bonus DECIMAL(10,2),
19. FOREIGN KEY (Emp_ID) REFERENCES Employee(Emp_ID)
20. );
21.
22. CREATE TABLE Technician (
23. Emp_ID INT PRIMARY KEY,
24. Skill_Set VARCHAR(50),
25. FOREIGN KEY (Emp_ID) REFERENCES Employee(Emp_ID)
26. );
27. Using a Discriminator Column
o A column determines the subtype an entity belongs to.
28. CREATE TABLE Employee (
29. Emp_ID INT PRIMARY KEY,
30. Name VARCHAR(50),
31. Salary DECIMAL(10,2),
32. Emp_Type VARCHAR(20) CHECK (Emp_Type IN ('Manager',
'Technician')),
33. Bonus DECIMAL(10,2),
34. Skill_Set VARCHAR(50)
35. );

💡 Best Approach: Separate tables for subtypes (2nd approach) provide better normalization.

 DBMS Quiz (10 Marks) - Additional Questions and Answers

 Q7. Explain the process of mapping associative entities into relational


schemas with an example. (2 Marks)
Answer:

An associative entity (also called a bridge entity) represents a many-to-many relationship


between two entities and often has its own attributes.

Steps to Map an Associative Entity:

1. Create tables for the two main entities.


2. Create a separate table for the associative entity.
3. Include foreign keys from both entities.
4. Add any attributes of the associative entity.

💡 Example:
Consider Student and Course entities with a many-to-many relationship through
Enrollment (associative entity).

 Entities:
o Student (Student_ID, Name, Age)
o Course (Course_ID, Title, Credits)
o Enrollment (Enrollment_ID, Student_ID, Course_ID, Enrollment_Date)

Relational Schema:

CREATE TABLE Student (


Student_ID INT PRIMARY KEY,
Name VARCHAR(50),
Age INT
);

CREATE TABLE Course (


Course_ID INT PRIMARY KEY,
Title VARCHAR(100),
Credits INT
);

CREATE TABLE Enrollment (


Enrollment_ID INT PRIMARY KEY,
Student_ID INT,
Course_ID INT,
Enrollment_Date DATE,
FOREIGN KEY (Student_ID) REFERENCES Student(Student_ID),
FOREIGN KEY (Course_ID) REFERENCES Course(Course_ID)
);

In this schema:

 Enrollment is an associative entity connecting Student and Course.


 Foreign keys ensure referential integrity.

 Q8. How do you map unary relationships (one-to-one and many-to-


many) into a relational model? (2 Marks)
Answer:

Unary relationships occur when an entity is related to itself.

1. Unary One-to-One Relationship:


o Add a foreign key in the same table referencing the primary key.
o Example: Employee (Emp_ID, Name, Manager_ID) (where Manager_ID
refers to another Employee).
2. CREATE TABLE Employee (
3. Emp_ID INT PRIMARY KEY,
4. Name VARCHAR(50),
5. Manager_ID INT UNIQUE, -- Each employee has one manager
6. FOREIGN KEY (Manager_ID) REFERENCES Employee(Emp_ID)
7. );
8. Unary Many-to-Many Relationship:
o Create an associative table with two foreign keys referencing the same entity.
o Example: Employee supervises other employees.
9. CREATE TABLE Supervision (
10. Supervisor_ID INT,
11. Subordinate_ID INT,
12. PRIMARY KEY (Supervisor_ID, Subordinate_ID),
13. FOREIGN KEY (Supervisor_ID) REFERENCES Employee(Emp_ID),
14. FOREIGN KEY (Subordinate_ID) REFERENCES Employee(Emp_ID)
15. );

💡 Example:

 If Employee A supervises B and C, the Supervision table will have:

Supervisor_ID Subordinate_ID
A B
A C

 Q9. How do you map a ternary relationship into relations? Explain with
an example. (2 Marks)

Answer:

A ternary relationship involves three entities at the same time.

Steps to Map a Ternary Relationship:

1. Create tables for the three entities.


2. Create a separate table for the ternary relationship.
3. Include foreign keys referencing each entity.

💡 Example:
Consider a Supplier supplies a Product to a Warehouse.

 Entities:
o Supplier (Supplier_ID, Name)
o Product (Product_ID, Name)
o Warehouse (Warehouse_ID, Location)
o Supplies (Supplier_ID, Product_ID, Warehouse_ID, Quantity,
Supply_Date)

Relational Schema:

CREATE TABLE Supplier (


Supplier_ID INT PRIMARY KEY,
Name VARCHAR(50)
);

CREATE TABLE Product (


Product_ID INT PRIMARY KEY,
Name VARCHAR(50)
);

CREATE TABLE Warehouse (


Warehouse_ID INT PRIMARY KEY,
Location VARCHAR(100)
);

CREATE TABLE Supplies (


Supplier_ID INT,
Product_ID INT,
Warehouse_ID INT,
Quantity INT,
Supply_Date DATE,
PRIMARY KEY (Supplier_ID, Product_ID, Warehouse_ID),
FOREIGN KEY (Supplier_ID) REFERENCES Supplier(Supplier_ID),
FOREIGN KEY (Product_ID) REFERENCES Product(Product_ID),
FOREIGN KEY (Warehouse_ID) REFERENCES Warehouse(Warehouse_ID)
);

💡 Example Data:

Supplier_ID Product_ID Warehouse_ID Quantity Supply_Date


1 101 5 50 2025-02-10
2 102 3 30 2025-02-12

 Q10. What is relation merging in database design, and when should it


be used? (2 Marks)

Answer:

Relation merging is the process of combining multiple relations (tables) into one to improve
efficiency, reduce redundancy, and simplify queries.

When to Use Relation Merging?

1. When two relations have similar attributes (to avoid redundancy).


2. When there is a 1:1 relationship (to avoid excessive joins).
3. When normalization has led to excessive fragmentation.

💡 Example:
Suppose we have:

 Employee (Emp_ID, Name, Salary, Dept_ID)


 Department (Dept_ID, Dept_Name, Location)

Instead of two separate tables, we merge them into one:

CREATE TABLE Employee_Department (


Emp_ID INT PRIMARY KEY,
Name VARCHAR(50),
Salary DECIMAL(10,2),
Dept_ID INT,
Dept_Name VARCHAR(50),
Location VARCHAR(100)
);

 This removes the need for joins, but denormalizes the structure.

 Final Recap:

This quiz covers 10 questions, explaining:


✅ Mapping regular, weak, and associative entities.
✅ Handling unary, binary, and ternary relationships.
✅ Specialization vs. Generalization with constraints.
✅ Relation merging in database design.

Would you like more case studies or practice questions? 😊

You might also like