DBMS

UNIT - 1

Topic - Conceptual Design for a Large Enterprise.

Developing an Entity-Relationship (E-R) 4. Determine Cardinality and Participation
Diagram involves the following steps Specify the number of instances that can
participate in a relationship (e.g., one student can
enroll in multiple courses).
1. Identify the Entities
Define mandatory (total) or optional (partial)
Entities represent real-world objects or
participation.
concepts (e.g., Student, Course, Teacher).
5. Draw the E-R Diagram
Each entity must have a unique identifier
(Primary Key). Use rectangles for entities.
2. Identify Relationships Between Entities Use diamonds for relationships.
Determine how entities interact (e.g., Student Use ellipses for attributes.
enrolls in Course). Use lines to connect entities with
Relationships can be one-to-one (1:1), one- to- relationships.
many (1:M), or many-to-many (M:N). Use crow's foot or chen notation
3. Define Attributes for Entities and to indicate cardinality.
Relationships 6. Normalize the Diagram
Identify key attributes (e.g., Student_ID, Remove redundant relationships and
Name, Email for Student). optimize structure.
Determine composite, multivalued, or Ensure it aligns with business rules.
derived attributes, if needed.
Q1. Design an Entity-Relationship (ER) diagram for a Relationships and Constraints
Hospital Management System based on the 1. A Doctor can treat multiple Patients, but
following constraints and relationships: each Patient is treated by exactly one Doctor.
Entities and Attributes 2. A Bill can contain multiple Medicines, and
1. Doctor each Medicine can appear in multiple Bills.

o Doctor_id (Primary Key)

o Name (First, Middle, Last) Instructions:
o Qualification 1. Draw the ER diagram representing all entities,
attributes, relationships, and cardinalities.
o Specialization
2. Clearly mention Primary Keys and underline
2. Patient
them in the diagram.
o Patient_id (Primary Key)
3. Indicate Participation Constraints (whether
o Age Total or Partial) and Cardinality Constraints.
o Date of Birth (DOB)
o Address (Locality, Town/City)
3. Medicine
o Code (Primary Key)
o Price
o Quantity
Q2. A university wants to develop a University Relationships and Constraints
Management System to store and manage information
about Students, Programs, and Courses. Design an 1. Student - Program Relationship:
Entity-Relationship (ER) Diagram considering the o A Student can enroll in only one
following constraints and relationships. Program.
Entities and Attributes o A Program can have multiple Students
1. Student enrolled.
o Student_ID (Primary Key) 2. Program - Course Relationship:
o GivenNames o A Program contains multiple Courses.
o Surname o A Course can belong to only one
o Date_of_Birth Program.
o YearEnrolled 3. Student - Course Attempts Relationship:
2. Program o A Student can attempt multiple Courses
o Program_ID (Primary Key) in different Semesters.
o Name o Each Attempt has details like Year,
o CreditPoints Semester, Mark, and Grade.
o YearCommenced o Cardinality: N:M (Many Students →
3. Course Many Courses in Different Semesters)
o Course_ID (Primary Key)
o Name
o CreditPoints
o YearCommenced
 o Here, "Year" and "Semester" are
specific to the "Attempts"
Can relationship have attributes? relationship, not just the Student
or the Course.
Yes ,a relationship has attributes when 2. Employee - Project (WorksOn
there is data specific to the relationship Relationship)
itself and not to any single entity. o If an Employee works on a
Examples of Relationships with Project, the relationship
Attributes "WorksOn" can have:
1.Student - Course (Attempts ▪ Hours Worked
Relationship)
▪ Role
o If a Student enrolls in a Course, ▪ Start Date
the relationship "Attempts" can
have attributes like: ▪ End Date

▪ Year
▪ Semester
▪ Marks
▪ Grade
Q3. A bank wants to develop a Bank Management System Relationships and Constraints
to efficiently store and manage information about 1. Bank - Branch Relationship:
Branches, Customers, Accounts, and Loans. Design an
o A Bank can have multiple Branches.
Entity-Relationship (ER) Diagram considering the
o Each Branch belongs to only one
following constraints and relationships.
Bank.
2. Branch - Loan Relationship:
Entities and Attributes o A Branch can offer multiple Loans.
1. Bank o Each Loan is associated with one
o Name
Branch.
o Code (Primary Key)
o Address
3. Branch - Account Relationship:
2. Branch o A Branch can maintain multiple
o Branch_ID (Primary Key) Accounts.
o Name o Each Account belongs to one Branch.
o Address
3. Customer
1. Customer - Loan Relationship:
o Cust_ID (Primary Key) o A Customer can avail multiple Loans.

o Name o A Loan can be availed by multiple

o Phone Customers.
o Address
2. Customer - Account Relationship:
4. Account
o A Customer can hold multiple
o Account_No (Primary Key)
o Acc_Type Accounts.
o Balance o An Account can be held by multiple
5. Loan Customers (joint account).
o Loan_ID (Primary Key)
o Loan_Type
o Amount
Q4. A university wants to develop a Faculty Information Relationships and Constraints
System to manage data about faculty members,
administrators, and users who interact with the system. 1. Common User - Faculty Information (Inquiry
The system should allow common users to inquire about Relationship):
faculty details, administrators to manage faculty o A Common User can inquire about
information, and teacher users to modify faculty records.
multiple Faculty members.
Design an Entity-Relationship (ER) Diagram based on the
given requirements and constraints. o A Faculty member can be inquired by
Entities and Attributes multiple Common Users.
2. Administrator - Faculty Information (Service
1. Common User
Relationship):
o ID (Primary Key)
o User Name o An Administrator provides services to
o Password faculty members.
2. Administrator
o ID (Primary Key)
o Each Faculty member is associated with
o User Name exactly one Administrator.
o Password
3. Teacher User - Faculty Information (Modify
3. Teacher User
Relationship):
o ID (Primary Key)
o User Name o A Teacher User can modify multiple
o Password Faculty Information records.
4. Faculty Information
o ID (Primary Key)
o A Faculty Information record can be
o Name modified by multiple Teacher Users.
o Department
o School
o Telephone No.
Question 4 – Design an ER diagram Hints
considering these steps.
Entities: Department, Instructor, Course,
1. Each University department Has multiple Student
instructor; one of them is the head of the
Relationships:
department
1. Department - Instructor (1:N) →One
2. An instructor belongs to only one HOD per department
department
2. Department - Course (1:N) →One
3. Each department offers multiple department has many courses
courses, each of which is taught by a single
3. Instructor - Course (1:1) →Each course
instructor
is taught by one instructor
4. A student may enroll for many courses
4. Student - Course (M:N) →A student can
offered by different departments
enroll in multiple courses
Entities Attributes Relationships s Constraints
1. Department 1. Department - Instructor Relationship (1:N)
• Dept_Name(Primary Key)
• Each department has multiple instructors.
• Location
• One instructor is the Head of the
• Instructor_Name(Foreign Key referring to
Instructor who is the Head of the Department)
Department (HOD).
2. Instructor
2. Instructor - Department Relationship (1:N)
• Each instructor belongs to only one
• Instructor_Name

• Telephone department.
• Room • Dept_ID is a foreign key in Instructor
• Dept_Name (Foreign Key referring to Department) referring to Department.
3. Course 3. Department - Course Relationship (1:N)
• Course_ID (Primary Key) • Each department offers multiple courses.
• Course_Name • Each course belongs to one department.
• Pre_Requisits 4. Instructor - Course Relationship (1:1)
• Duration • Each course is taught by a single
• Dept_Name (Foreign Key referring to Department)
instructor.
• Instructor_Name (Foreign Key referring to
Instructor) 5. Student - Course Relationship (M:N)
• A student can enroll in multiple courses.
4. Student
• Student_ID (Primary Key) • A course can have multiple students.

• Stuudent_Name

• DOB