DBMS Interview Preparation Questions and Answers

1. ER Diagrams

Easy Level
 What is an ER diagram, and why is it used?

An ER (Entity-Relationship) diagram is a visual representation of the entities, attributes,

and relationships in a database. It's used to design a database structure that reflects real-
world scenarios, helping to organize data efficiently.

 Define entities, attributes, and relationships in an ER diagram.

- Entities are objects or concepts (e.g., Student, Course).

- Attributes are properties that describe an entity (e.g., Name, Age for Student).
- Relationships connect entities (e.g., Enrollment between Student and Course).

 What is the difference between a strong and a weak entity?

- Strong Entity: Has a primary key that uniquely identifies each instance.
- Weak Entity: Depends on a strong entity for identification and lacks its own primary key.

 Can you explain what a primary key is?

A primary key is a unique identifier for each record in a table, ensuring no duplicate entries
exist.

Moderate Level
 What are composite and derived attributes in an ER diagram? Give examples.

- Composite Attribute: Contains multiple sub-attributes (e.g., Address with Street, City, ZIP).
- Derived Attribute: Can be calculated from other attributes (e.g., Age derived from Date of
Birth).

 How are relationships represented in ER diagrams?

Relationships are represented by diamond shapes connecting two or more entities, with
lines indicating the type and cardinality of the relationship.

 Explain how you would identify and represent a weak entity in an ER diagram.

A weak entity does not have its own primary key and relies on a strong entity for
identification. It’s typically represented with a double rectangle and a double-lined
relationship to indicate total participation.

 How does an ER diagram differ from a relational schema?

An ER diagram visually maps entities and relationships, while a relational schema defines
how tables and relationships are structured in the database, including keys and constraints.

Hard Level
 How would you represent a recursive relationship in an ER diagram?

A recursive relationship occurs when an entity relates to itself (e.g., Employee supervises
another Employee). This is represented by an entity having a relationship line looping back
to itself.

 Describe a situation where you would use an associative entity. How would you
represent it in an ER diagram?

When a many-to-many relationship has its own attributes (e.g., Order and Product forming
OrderDetails with Quantity), an associative entity is used to hold relationship-specific
details, represented as a rectangle connected to each participating entity.

 In a complex ER diagram with multiple entities and relationships, how do you

determine which entity should be represented as the main entity in a relationship?

The choice depends on the requirements, often with the entity that logically owns or
initiates the relationship (e.g., Department as the main entity in a Manages relationship with
Employee).

 Explain how you would convert an ER diagram into tables for a relational database.
What are the steps involved?

Steps include:
- Create a table for each entity with its attributes.
- Convert relationships based on cardinality (one-to-many as foreign keys, many-to-many as
join tables).
- For weak entities, include the primary key of the related strong entity as part of their
primary key.

2. Participation

Easy Level
 What is participation in the context of ER diagrams?

Participation specifies whether each instance of an entity must participate in a relationship,

categorized as total (mandatory) or partial (optional).

 Define total and partial participation with examples.

- Total Participation: Every instance of the entity must be in the relationship (e.g., every
Student must be Enrolled in a Course).
- Partial Participation: Only some instances participate (e.g., some Employees may be
assigned to a Project).

 How do you represent mandatory and optional participation in an ER diagram?

Mandatory participation is represented by a double line connecting the entity to the

relationship, while optional participation uses a single line.

Moderate Level
 Can an entity have both total and partial participation in different relationships? Explain
with an example.

Yes, an entity may have total participation in one relationship and partial in another. For
instance, Students must be enrolled in Courses (total participation) but may optionally join
Clubs (partial participation).

 How does participation affect the design of database constraints?

Participation dictates whether foreign keys can be nullable; total participation implies non-
null constraints, while partial participation allows nulls if an instance is not in the
relationship.

 What are some real-world scenarios where you would require total participation?

In a library system, every Book must be associated with a Category, and each Employee in a
payroll system must belong to a Department.

Hard Level
 How would you approach designing an ER diagram if all entities have total participation
in their relationships?

Every relationship would need to ensure all entity instances are included, possibly
requiring additional entities or constraints to avoid orphaned records.

 What issues might arise if an optional (partial) participation constraint is accidentally

left out in database design?

The database might enforce relationships where some entities should not be forced to
participate, leading to data inconsistency and incorrect data associations.

 Explain how participation constraints impact referential integrity in a relational

database.

Total participation requires non-null foreign keys, reinforcing referential integrity by

ensuring every entity instance is connected to another, while partial participation permits
nulls, giving flexibility.
3. Cardinality Ratios

Easy Level
 What is a cardinality ratio, and why is it important in ER diagrams?

A cardinality ratio defines the maximum number of instances of one entity that can relate to
another, helping to map relationships accurately.

 Explain the basic cardinality ratios: one-to-one, one-to-many, and many-to-many.

- One-to-One: Each instance of an entity is associated with one instance of another (e.g., each
Person has one Passport).
- One-to-Many: One entity instance relates to many others (e.g., one Department has
multiple Employees).
- Many-to-Many: Multiple instances in one entity relate to multiple instances in another
(e.g., Students and Courses).

 Give an example of each cardinality ratio type.

- One-to-One: Student to Library Card.

- One-to-Many: Teacher to Class.
- Many-to-Many: Customer to Product in Purchases.

Moderate Level
 What cardinality ratio would you assign in an ER diagram for a school where each
student has a unique library card, but each library card is assigned to only one student?

One-to-One, as each Student corresponds to a unique Library Card, and each Library Card to
one Student.

 How would you represent a one-to-many relationship in an ER diagram? What about a

many-to-many relationship?

- One-to-Many: A single line from one entity to another.

- Many-to-Many: Represented as a diamond connecting both entities, often requiring an
associative table.

 Explain why many-to-many relationships are typically avoided in database design.

What’s a common way to handle them?

Many-to-many relationships create data redundancy and inefficiency. They’re typically

broken down into two one-to-many relationships using a join (associative) table.

Hard Level
 Can you describe how cardinality ratios influence table design when converting an ER
diagram into a relational model?
One-to-one and one-to-many relationships are handled with foreign keys, while many-to-
many require a join table with foreign keys from both entities.

 Suppose a company has a one-to-many relationship between Departments and

Employees, but the requirements change so that an employee can now belong to
multiple departments. How would you modify the ER diagram and the database design?

Change the relationship to many-to-many, introduce an associative table (e.g.,

Employee_Department), and update the schema to support multiple departments per
employee.

 How do cardinality ratios impact performance and storage considerations in a relational

database?

Many-to-many relationships increase storage and query complexity due to additional join
tables, while one-to-many and one-to-one are more efficient for storage and retrieval.
 How can you convert an M

relationship into 1
relationships in an ER model? Explain with an example.

 To convert an M

relationship into 1

relationships, introduce an associative entity (also called a junction table) that acts
as an intermediary. This associative entity will hold foreign keys to both original
entities, representing each unique combination. For instance, for a relationship
between "Student" and "Course," where each student can enroll in multiple
courses and each course can have multiple students, an "Enrollment" associative
entity can be created. This entity will have two foreign keys: Student ID and
Course ID. Now, "Student" has a 1

relationship with "Enrollment," and "Course" also has a 1

relationship with "Enrollment."

 What is an associative (or junction) entity, and why is it used in database design
to handle many-to-many relationships?

 An associative entity is a table created to transform an M

relationship into 1

relationships by acting as a bridge between two entities. It contains foreign keys

to each of the entities involved in the M

relationship. This setup is essential in relational databases because they don’t

support direct M

relationships, and it helps avoid data redundancy while maintaining relationship

integrity.

 Given an M

relationship between entities "Author" and "Book," how would you modify the ER
diagram to represent this relationship as 1
relationships?

 To convert this M
 relationship, create an associative entity called "AuthorBook," which has foreign
keys for both "Author ID" and "Book ID." Now, the relationship becomes two 1

relationships: "Author" to "AuthorBook" and "Book" to "AuthorBook." This

setup ensures that each author can be linked to multiple books, and each book can
be linked to multiple authors.

 What changes are necessary in the relational schema when converting a many-to-
many relationship to one-to-many relationships?

 When converting an M

relationship to 1

, add a new table (associative entity) to serve as a bridge. This new table should
include foreign keys referencing each of the original entities, which establish two
one-to-many relationships. Constraints may be added to these foreign keys to
enforce referential integrity.

 If you have an M

relationship between "Product" and "Order," explain the steps and table structure
needed to convert this into a one-to-many schema.

 First, create an associative entity, e.g., "OrderProduct," with foreign keys for both
"Product ID" and "Order ID." This table will store each unique combination of
products and orders. The "Product" entity now has a 1

relationship with "OrderProduct," and "Order" also has a 1

relationship with "OrderProduct."

 Describe the purpose of foreign keys in the associative table when converting an
M

relationship to 1
. Why are these keys critical?

 Foreign keys in an associative table establish the connections between the original
entities, allowing each instance of one entity to link to multiple instances of the
other. They are critical because they ensure referential integrity by linking entries
in the associative table back to the original tables, preventing orphaned records
and enforcing valid data relationships.

 When an M
relationship is converted to 1
relationships, what constraints are applied to ensure data integrity?

 To maintain integrity, foreign key constraints are applied on the associative

entity's fields. These constraints enforce that each record in the associative entity
references valid records in both original entities, preventing any null or invalid
references.

 How does introducing an associative entity impact database design and

performance when converting from M

to 1
relationships?

 Introducing an associative entity adds complexity to the database structure, as it

increases the number of joins required for queries. However, it maintains data
integrity and reduces redundancy, improving data management. Performance may
be impacted in read-heavy operations, but efficient indexing on foreign keys can
help mitigate performance loss.