National University of Computer and Emerging Sciences, Lahore Campus

Course: Database systems Course Code: CS5059

Program: MSBA Semester: Fall 2024
Deadline Marks: 80

Paper: Assignment 1 Roll No.

Instruction/Notes: • This assignment is an individual assignment.
• Clearly mention any assumption you have made.
• You are required to submit the hard copy of your assignment at the start
of your class
• For any query please contact your TA

Question 1.
Draw an ER schema diagram for geography. It should contain the following kinds of entities together with
the listed attributes:
• Countries : Name, Area, Population, GDP ("Gross Domestic Product")
• Cities : Name , Population , Longitude , Latitude
• Rivers : Name , Length
• Seas : Name , Max depths

Model the following relationships between the geographical entities:

• Each city belongs to exactly one country
• Each river crosses one or several countries
• Each river ends in another river or in a sea.

State any assumptions you make about the additional requirements. (10 marks)

Question 2. (10 marks)

Design an ER schema for keeping track of information about votes taken in the U.S. House of
Representatives during the current two-year congressional session.
 The database needs to keep track of each U.S. State’s Name (e.g., Texas, New York, California)
and include the Region of the state (whose domain is {Northeast, Midwest, Southeast, Southwest,
and West}). Each state can have more than one congressperson, but each congressperson
can represent only one state.
 Each CONGRESSPERSON in the House of Representatives is described by their Name, the
District represented, the StartDate when the congressperson was first elected, and the political
Party to which they belong (whose domain is {Republican, Democrat, Independent, Other}). A
congressperson can sponsor many bills, but each bill can have only one sponsor.
 The database keeps track of each BILL (i.e., proposed law), including the BillName, the
DateOfVote on the bill, whether the bill PassedOrFailed (whose domain is {Yes, No}), and the
Sponsor (the congressperson who proposed the bill). Each congressperson can vote on
multiple bills, and each bill can be voted on by multiple congresspersons. The database also
records how each congressperson voted on each bill (the domain of the vote attribute is {Yes, No,
Abstain, Absent}).
 In addition to drawing the ER schema diagram for this application, clearly define the cardinality
relationships between each entity set (e.g., one-to-many, many-to-many) and state any
assumptions you make.
Question 3. (10 marks)
The company you work for wants to digitize their time cards. You have been asked to design the database
for submitting and approving time cards. Draw the database ER diagram with the following information:

• A timecard should have hours worked and date submitted

• Each timecard is associated with exactly one employee. An employee can be permanent or employed on
hourly basis.
• Each timecard should have a unique id
• Each timecard has a status: it is either approved, not approved, or pending
• Each employee has a unique id, name and address.
• Each employee submits a time card every pay period. i.e. In 1 year, they will submit multiple time cards
• Each employee either has direct deposit or physical check as their method of payment
• Each employee is associated with exactly one manager
• Each manager has a unique id and a name
• Each manager is in charge of multiple employees
• Each manager approves time cards for multiple employees.

Make sure that you indicate all cardinality constraints and your model should not contain redundant
entity sets, relationships, or attributes. If you need to make any assumptions, include them in your answer.

Question 4. (20 marks)

Draw an EER diagram for a small private airport database that is used to keep track of airplanes, their
owners, airport employees, and pilots. The following information has been collected:

 Each airplane has a registration number [Reg#], belongs to a particular plane type [OF-TYPE],
and is stored in a particular hangar [STORED-IN]. Each airplane can only belong to one plane
type and be stored in one hangar, but each hangar can store multiple airplanes.
 Each plane type has a model number [Model], a capacity [Capacity], and a location [Location].
Each plane type can have multiple airplanes, but each airplane belongs to only one plane
type.
 The database keeps track of the owners of each plane [OWNS] and the employees who have
maintained the plane [MAINTAIN]. Each airplane can have multiple owners over time, but an
owner can own many airplanes. Each relationship instance in OWNS relates an airplane to an
owner and includes the purchase date [Pdate].
 Each relationship instance in MAINTAIN relates an employee to a service record [SERVICE].
Each airplane can have many service records, and an employee can maintain many
airplanes. Each plane undergoes service many times; hence, it is related by [PLANE-SERVICE]
to a number of service records. A service record includes the date of maintenance [Date], the
number of hours spent on the work [Hours], and the type of work done [Workcode]. Each
service record is uniquely identified by the airplane registration number and the service
instance (this makes SERVICE a weak entity).
 Pilots have specific attributes like license number [Lic-Num] and restrictions [Restr], while
employees have attributes such as salary [Salary] and shift worked [Shift]. Each person (whether
a pilot or an employee) in the database has data kept on their social security number [Ssn], name
[Name], address [Address], and telephone number [Phone].
 The database also tracks the types of planes each pilot is authorized to fly [FLIES] and the types
of planes each employee can do maintenance work on [WORKS-ON]. A pilot can be authorized
to fly multiple plane types, and multiple pilots can be authorized for the same plane type.
Similarly, an employee can maintain multiple plane types, and multiple employees can work
on the same plane type.
Question 5. (15 marks)
A library service wants to create a database to store details of its libraries, books and borrowers. Details
include the following:
A book has a unique ISBN number, a title and one or more authors. The library service may own several
copies of a given book, each of which is located in one of the service’s libraries. A given library contains
many books, and in order to distinguish different copies of the same book a library assigns a different
copy-number to each of its copies of a given book; the price that was paid for each copy is also recorded.
Every library has a unique name and is either a main library or a branch library. A main library may have
zero or more branch libraries and every branch library is a branch of exactly one main library.
A borrower has a name and a unique ID code. A borrower can have many books on loan, but each copy
of a book can only be on loan to one borrower. A borrower could borrow the same book on several
occasions, but it is assumed that each such loan will take place on a different date.
Draw an EER Model for above requirement.

Question 6. (15 marks)

A taxi company needs to model their activities. There are two types of employees in the company: drivers
and operators.
 For drivers, it is important to know the date of issue and type of the driving license, and the date of
issue of the taxi driver's certificate.
 For all employees, the company keeps track of their personal number, address, and the available
phone numbers. Each employee can have multiple phone numbers, but a phone number
belongs to only one employee.
The company owns a number of cars.
 For each car, the company records its type, year of manufacturing, number of places, and the date
of the last service. Each car can be used for multiple trips, but each trip involves only one car.
The company also keeps a record of car trips.
 A trip may be initiated by a customer picking a taxi on the street or by placing an order through an
operator. Each trip is associated with one driver, one car, and possibly one operator (if
ordered through the company). Each operator can assign multiple trips, but each trip is
assigned by only one operator.
 The company records departure and destination addresses along with the times for each trip.
Additionally:
 Each driver can drive multiple cars over time, but a trip is driven by only one driver in one
car.
 Each car can be assigned to multiple drivers, but not at the same time.
In addition to modeling the entities, draw an ER schema diagram and define the cardinality relationships
between each entity set (e.g., one-to-many, many-to-many), and state any assumptions you make.
 Population
Population

Longitude Name Area

Latitude

Name
GDP
M 1
Cities Belongs to Countries

M M

Crosses

M
Name
1 M 1
Seas Ends In Rivers Ends In
MaxDepths

Length 1
Name
 C_Name
StateName StartDate
District
Region
PoliticalParty

U.S_StatesName 1 Represents M Congresspersons

M M

DateOfVote

Sponsored Votes

M
N N
M

Bill

BillName

PassedOrFailed

Yes No
 NotApproved
Approved Pending

Address

Date Status PaymentType

Name
HoursWorked
T_ID E_ID EmploymentType

M 1
TimeCard Submits Employee

Approves
Manages

1 1

Manager

M_ID

Name
 Salary Shift
Capacity M
M
Model Weight works on

Employee
M
PlaneType

maintain
1
M Restr Lic-Num
of type
M
M M
flies Pilot
Reg._No,
Airplane Date Workcode

M Date/Workcode Service Hours

M
stored in
1
1 P_date plane service

Hangar
M Owner
M
owns

Location
Corporation Person
Number Capacity Name
SSN

Address Address
Phone Name
Phone
 Title Author

ISBN

Book

Price Copy
B_ID Date
Name CopyNo.

M
1 M M 1
Barrower Barrow Loan to Copy

Location
No,-of-branches
Name

1
Library

Main Branch

1 M

Branch
 DepartureAddress
TripID
DestinationAddress
PersonalNumber
DepartureTime
Address
1 M Trip
Operator Assigns DestinationTime
M
M
Employee

1 1
Drives
Driver
M

Has Uses
LicenseType Assigned
LicenseDate 1

M CertificateDate

PhoneNumber
1
CarID
Car

Number Type

Yearofmanufacturing LastServiceDate

No.ofPlaces
 National University of Computer and Emerging Sciences, Lahore Campus
Course: Database systems Course Code: CS5059
Program: MSBA Semester: Fall 2024
Deadline Marks: 100

Paper: Assignment 2 Roll No.

Instruction/Notes:
• This assignment is an individual assignment. Refrain from plagiarism.
• Clearly mention any assumption you have made.
• You are required to submit the written copy of your assignment.
• For any query please contact your TA

Question 1.

The following narrative describes a simplified version of the organization of Olympic

facilities planned for the summer Olympics. Draw an EER diagram that shows the entity
types, attributes, relationships, and specializations for this application. State any
assumptions you make. Also convert the following EER Diagram into a Database
Schema (20 marks)

The Olympic facilities are divided into sports complexes. Sports complexes are divided into
onesport and multisport types. Multisport complexes have areas of the complex designated for
each sport with a location indicator (e.g., center, NE corner, and so on). A complex has a
location, chief organizing individual, total occupied area, and so on. Each complex holds a
series of events (e.g., the track stadium may hold many different races). For each event there is
a planned date, duration, number of participants, number of officials, and so on. A roster of all
officials will be maintained together with the list of events each official will be involved in.
Different equipment is needed for the events (e.g., goal posts, poles, parallel bars) as well as
for maintenance. The two types of facilities (one-sport and multisport) will have different types
of information. For each type the number of facilities needed is kept, together with an
approximate budget.
Question2:
Convert the following EER Diagram into a Database Schema. Make sure to reduce redundancy as much
as possible. Efficient tables will be given credit only. Mark primary and foreign keys as well. (10 marks)

Question 3:
Convert the following ER Diagram into a Database Schema. Make sure to reduce redundancy as much
as possible. Efficient tables will be given credit only. Mark primary and foreign keys as well. (15 marks)
Question 4:
Convert the following ER Diagram into a Database Schema. Make sure to reduce redundancy as much
as possible. Efficient tables will be given credit only. Mark primary and foreign keys as well. (15 marks)

Question 5: Convert the following EER Diagram into a Database Schema. Clearly identify primary and
foreign keys. (20 marks)
Question 6:
Convert the following EER Diagram into a Database Schema. Make sure to reduce redundancy as much
as possible. Efficient tables will be given credit only. Mark primary and foreign keys as well. (20 marks)
Answer 1: 20 marks
Answer 2: 10 marks

Answer 3: 15 marks

1. SHIP Table:

This represents the ships in the database.

● Attributes:
○ Sname (Primary Key)
○ Owner
○ Type (Foreign Key to SHIP_TYPE)
○ Home_Port (Foreign Key to PORT)
2. SHIP_TYPE Table:

This table represents the type of ship.

● Attributes:
○ Type (Primary Key)
○ Tonnage
○ Hull

3. SHIP_AT_PORT Table:

This table represents the relationship where a ship can be at multiple ports. It has a
many-to-many relationship between SHIP and PORT.

● Attributes:
○ Sname (Foreign Key to SHIP)
○ Pname (Foreign Key to PORT)
○ Start_date
○ End_date

4. PORT Table:

This represents ports in the system.

● Attributes:
○ Pname (Primary Key)
○ State_Country (Foreign Key to STATE/COUNTRY)
○ Sea_Ocean_Lake (Foreign Key to SEA/OCEAN/LAKE)

5. STATE/COUNTRY Table:

This represents the state or country where a port is located.

● Attributes:
○ Name (Primary Key)
○ Continent
6. SEA/OCEAN/LAKE Table:

This represents the body of water where the port is located.

● Attributes:
○ Name (Primary Key)

7. SHIP_MOVEMENT Table:

This stores movement data for a ship.

● Attributes:
○ Sname (Foreign Key to SHIP)
○ Date
○ Time
○ Longitude
○ Latitude

8. HISTORY Table:

This represents the history of ship movements.

● Attributes:
○ Sname (Foreign Key to SHIP)
○ Time_stamp (Primary Key)

9. PORT_VISIT Table:

This represents the visits of ships to ports.

● Attributes:
○ Sname (Foreign Key to SHIP)
○ Pname (Foreign Key to PORT)
○ Start_date
○ End_date
Answer 4: 15 marks

1. BANK Table

This table stores information about banks.

● Attributes:
○ Code (Primary Key)
○ Name
○ Addr (Address)

2. BANK_BRANCH Table

This table stores information about branches of a bank.

● Attributes:
○ Branch_no (Primary Key)
○ Addr (Address)
○ BankCode (Foreign Key from BANK)

3. ACCOUNT Table

This table stores information about bank accounts.

● Attributes:
○ Acct_no (Primary Key)
○ Balance
○ Type (Type of account, e.g., savings, checking)
○ Branch_no (Foreign Key from BANK_BRANCH)

4. LOAN Table

This table stores information about loans taken from the bank.

● Attributes:
○ Loan_no (Primary Key)
 ○ Amount
○ Type (Type of loan)
○ Branch_no (Foreign Key from BANK_BRANCH)

5. CUSTOMER Table

This table stores information about customers of the bank.

● Attributes:
○ Ssn (Primary Key)
○ Name
○ Phone
○ Addr (Address)

6. A_C Table (Account-Customer Relationship)

This table handles the many-to-many relationship between ACCOUNT and CUSTOMER.

● Attributes:
○ Acct_no (Foreign Key from ACCOUNT)
○ Ssn (Foreign Key from CUSTOMER)

7. L_C Table (Loan-Customer Relationship)

This table handles the many-to-many relationship between LOAN and CUSTOMER.

● Attributes:
○ Loan_no (Foreign Key from LOAN)
○ Ssn (Foreign Key from CUSTOMER)

Relationships:

● A BANK has multiple BANK_BRANCHES.

● A BANK_BRANCH has multiple ACCOUNTS and LOANS.
 ● A CUSTOMER can have multiple ACCOUNTS and LOANS, which leads to
many-to-many relationships between CUSTOMER and ACCOUNT, and between
CUSTOMER and LOAN, represented by the A_C and L_C tables.

Answer 5: 20 marks

1. PHOTO Table

This table stores information about photos.

● Attributes:
○ PhotoID (Primary Key)
○ Speed
○ Film
○ F-Stop
○ Color_BW (Boolean for Color or B&W)
○ Resolution
○ Date
○ Price

2. PHOTOGRAPHER Table

This table stores information about photographers.

● Attributes:
○ PName (Primary Key)
○ PBDate (Date of Birth)
○ PBio
○ PAddress
○ PNationality

3. TAKES Table

This is a relationship table between PHOTO and PHOTOGRAPHER.

● Attributes:
 ○ PhotoID (Foreign Key from PHOTO)
○ PName (Foreign Key from PHOTOGRAPHER)

4. LOCATION Table

This table stores the location data for LANDSCAPE photos.

● Attributes:
○ Place (Primary Key)
○ Country
○ Description

5. LANDSCAPE Table

This table stores information specific to landscape photos and has a relationship with
LOCATION.

● Attributes:
○ PhotoID (Foreign Key from PHOTO)
○ Place (Foreign Key from LOCATION)

6. ABSTRACT Table

This table stores information specific to abstract photos.

● Attributes:
○ PhotoID (Foreign Key from PHOTO)
○ Comment

7. MODEL Table

This table stores information about models involved in portrait photos.

● Attributes:
 ○ MName (Primary Key)
○ MBio
○ MSex
○ MBDate (Birthdate)

8. PORTRAIT Table

This table stores information specific to portrait photos and has a relationship with
MODEL.

● Attributes:
○ PhotoID (Foreign Key from PHOTO)
○ MName (Foreign Key from MODEL)
○ Agency

9. TRANSACTION Table

This table stores transaction details.

● Attributes:
○ TransID (Primary Key)
○ TDate
○ TotalAmount
○ CardNo
○ CardType
○ CardExpDate

10. CUSTOMER Table

This table stores customer details.

● Attributes:
○ LoginName (Primary Key)
○ Password
○ CName
○ CType
○ BillingAddress
 ○ CAddress (Foreign Key from CUSTOMER_ADDRESS)

11. CUSTOMER_ADDRESS Table

This table stores customer address details.

● Attributes:
○ StreetAddress1
○ StreetAddress2
○ City
○ State
○ ZipCode

12. INCLUDES Table

This table defines the relationship between PHOTO and TRANSACTION (a photo can be
part of multiple transactions, and a transaction can include multiple photos).

● Attributes:
○ PhotoID (Foreign Key from PHOTO)
○ TransID (Foreign Key from TRANSACTION)

13. INFLUENCES Table

This table defines a many-to-many relationship between PHOTOGRAPHERS.

● Attributes:
○ PName1 (Foreign Key to PHOTOGRAPHER)
○ PName2 (Foreign Key to PHOTOGRAPHER)
Answer 6: 20 marks

1. USER Table

This table stores information about users (teachers, headmasters, etc.).

● Attributes:
○ UserID (Primary Key)
○ Username
○ Password
○ Name
○ Address
○ Gender
○ Education
○ University
○ Mobile

2. STUDENT Table

This table stores information about students.

● Attributes:
○ S_ID (Primary Key)
○ Name
○ DOB (Date of Birth)
○ Fees
○ Gender
○ Phone

3. TEACHER Table

This table stores information about teachers.

● Attributes:
○ UserID (Foreign Key from USER)
○ Courses
4. HEADMASTER Table

This table stores information about headmasters.

● Attributes:
○ UserID (Foreign Key from USER)
○ YearsOfService

5. CLASS Table

This table stores information about different classes.

● Attributes:
○ C_ID (Primary Key)
○ ClassLevel
○ NumberOfStudents
○ Location

6. STUDENT_ASSESSMENT Table

This table stores information about student assessments.

● Attributes:
○ SA_ID (Primary Key)
○ WritingLevel
○ ReadingLevel
○ CleaningSkills
○ Attendance
○ Participation

7. TEACHER_ASSESSMENT Table

This table stores information about teacher assessments.

● Attributes:
○ TA_ID (Primary Key)
○ Attendance
 ○ TeachingSkills
○ Technology
○ Interaction
○ Preparation

8. CLASS_STUDENT_RELATION Table (Enrollment)

This table stores the many-to-many relationship between STUDENT and CLASS (students
are enrolled in classes).

● Attributes:
○ S_ID (Foreign Key from STUDENT)
○ C_ID (Foreign Key from CLASS)

9. TEACHES Table

This table stores the relationship between TEACHER and CLASS (teachers teach multiple
classes).

● Attributes:
○ UserID (Foreign Key from TEACHER)
○ C_ID (Foreign Key from CLASS)

10. STUDENT_ASSESSMENT_RELATION Table

This table stores the relationship between STUDENT and STUDENT_ASSESSMENT

(students have assessments).

● Attributes:
○ S_ID (Foreign Key from STUDENT)
○ SA_ID (Foreign Key from STUDENT_ASSESSMENT)
11. TEACHER_ASSESSMENT_RELATION Table

This table stores the relationship between TEACHER and TEACHER_ASSESSMENT

(teachers have assessments).

● Attributes:
○ UserID (Foreign Key from TEACHER)
○ TA_ID (Foreign Key from TEACHER_ASSESSMENT)

12. HEADMASTER_TEACHER_RELATION Table

This table stores the relationship between HEADMASTER and TEACHER (headmasters
oversee teachers).

● Attributes:
○ UserID_Headmaster (Foreign Key from HEADMASTER)
○ UserID_Teacher (Foreign Key from TEACHER)

Relationships:

● A USER can be a Teacher, Headmaster, or other roles.

● Students enroll in Classes, and Teachers teach Classes.
● Both Students and Teachers have assessments, tracked in separate tables.
● Headmasters manage Teachers, and this relationship is reflected in the
HEADMASTER_TEACHER_RELATION table.