1.

Consider the following set of requirements for a UNIVERSITY database as follows.

a. The university keeps track of each student’s name, student number, Social Security
number, current address and phone number, permanent address and phone number, birth
date, sex, class (freshman, sophomore, ..., graduate), major department, minor department
(if any), and degree program (B.A., B.S., ..., Ph.D.). Some user applications need to refer
to the city, state, and ZIP Code of the student’s permanent address and to the student’s
last name. Both Social Security number and student number haveunique values for each
student.
CREATE TABLE Student (
student_number INT PRIMARY KEY,
ssn INT UNIQUE,
name VARCHAR(100),
current_address VARCHAR(255),
current_phone_number VARCHAR(15),
permanent_address VARCHAR(255),
permanent_phone_number VARCHAR(15),
birth_date DATE,
sex CHAR(1),
class VARCHAR(50),
major_department VARCHAR(100),
minor_department VARCHAR(100),
degree_program VARCHAR(50),
city VARCHAR(50),
state VARCHAR(50),
zip_code INT,
last_name VARCHAR(50)
);
b. Each department is described by a name, department code, office number, office phone
number, and college. Both name and code have unique values for each department.
CREATE TABLE Department (
department_code INT PRIMARY KEY,
name VARCHAR(100) UNIQUE,
office_number VARCHAR(10),
office_phone_number VARCHAR(15),
college VARCHAR(100)
);

c. Each course has a course name, description, course number, number of semester hours,
level, and offering department. The value of the course number is unique for each course.
CREATE TABLE Course (
course_number INT PRIMARY KEY,
course_name VARCHAR(100),
description TEXT,
semester_hours INT,
level VARCHAR(50),
offering_department VARCHAR(100)
);

d. Each section has an instructor, semester, year, course, and section number.The section
number distinguishes sections of the same course that are taught during the same
semester/year; its values are 1, 2, 3, ..., up to the number of sections taught during each
semester.
CREATE TABLE Section (
section_number INT,
instructor VARCHAR(100),
semester VARCHAR(50),
year INT,
course INT,
 PRIMARY KEY (section_number, semester, year, course)
);

e. A grade report has a student, section, letter grade, and numeric grade (0, 1, 2, 3, or 4).

- Design an ER schema for this application, and draw an ER diagram for the
schema. Specify key attributes of each entity type and constraints on each
relationship type.
- Mapping the result of the above exercise to relational schemas.
CREATE TABLE Student (
StudentID INT PRIMARY KEY,
StudentName VARCHAR(50) NOT NULL
);
CREATE TABLE Student (
StudentID INT PRIMARY KEY,
StudentName VARCHAR(50) NOT NULL
);
CREATE TABLE Grade (
GradeID INT PRIMARY KEY,
LetterGrade VARCHAR(1) NOT NULL,
NumericGrade INT NOT NULL CHECK (NumericGrade >= 0 AND NumericGrade
<= 4),
StudentID INT NOT NULL REFERENCES Student(StudentID),
SectionID INT NOT NULL REFERENCES Section(SectionID)
);

2.
Consider the ER diagram shown below for part of a BANK database. Each bank can have
multiple branches, and each branch can have multiple accounts and loans.
a. List the strong (nonweak) entity types in the ER diagram.
 Strong (nonweak) entity types in the ER diagram:

 Bank: Representing the financial institution with branches and accounts.

 Branch: Representing a physical location of the bank with accounts and loans.
 Account: Representing a financial relationship between a customer and the bank.
 Loan: Representing a financial agreement between a customer and the bank for borrowing
money.

b. Is there a weak entity type? If so, give its name, partial key, and identifying
relationship.

Name: Depositor

Partial key: AccountNumber (foreign key referencing Account entity)

Identifying relationship: Depositor is identified by a combination of its AccountNumber and

the BankIdentifier (primary key of the Bank entity).

c. What constraints do the partial key and the identifying relationship of the weak entity
type specify in this diagram?

Partial Key Constraint:

 Each Depositor must have a valid AccountNumber.

This constraint ensures that every Depositor record is associated with an existing Account record.

Identifying Relationship Constraint:

 No two Depositors with the same AccountNumber can belong to different banks.

d. List the names of all relationship types, and specify the (min, max) constraint on each
participation of an entity type in a relationship type. Justify your choices.

1.
HAS_BRANCH:

2.
1. Bank (1, N): Each bank can have one or more branches (minimum of 1, no maximum).
2. Branch (1, 1): Each branch belongs to one and only one bank.
3.
HAS_ACCOUNT:

4.

1. Bank (1, N): Each bank can have one or more accounts (minimum of 1, no maximum).
2. Account (1, 1): Each account belongs to one and only one bank.

5.
HAS_LOAN:

6.

1. Bank (1, N): Each bank can have one or more loans (minimum of 1, no maximum).
2. Loan (1, 1): Each loan belongs to one and only one bank.

7.
MAINTAINS:

8.

1. Branch (1, N): Each branch maintains one or more accounts (minimum of 1, no maximum).
2. Account (N, 1): Each account is maintained by one and only one branch.

9.
PROVIDES:

10.

1. Branch (1, N): Each branch provides one or more loans (minimum of 1, no maximum).
2. Loan (N, 1): Each loan is provided by one and only one branch.

11.
HAS_DEPOSITOR:

12.

1. Account (1, N): Each account can have one or more depositors (minimum of 1, no maximum).
2. Depositor (N, 1): Each depositor is associated with one and only one account.

Justifications:


HAS_BRANCH: Each bank can have multiple branches, but each branch belongs to only one bank. This reflects the hierarchical
relationship between banks and their branches.


HAS_ACCOUNT: Similar to the HAS_BRANCH relationship, each bank can have multiple accounts, but each account belongs to
only one bank. This represents the ownership relationship between banks and their accounts.



HAS_LOAN: Similar to the HAS_ACCOUNT relationship, each bank can have multiple loans, but each loan belongs to only one
bank. This represents the ownership relationship between banks and their loans.



MAINTAINS: Each branch maintains multiple accounts, reflecting its role in managing customer accounts. Each account is
maintained by only one branch, ensuring clear ownership and responsibility.



PROVIDES: Similar to the MAINTAINS relationship, each branch provides multiple loans, reflecting its role in issuing loans to
customers. Each loan is provided by only one branch, ensuring clear ownership and responsibility.



HAS_DEPOSITOR: Each account can have multiple depositors, representing the possibility of joint accounts. Each depositor is
associated with only one account, ensuring that their financial records are properly linked.

e. List concisely the user requirements that led to this ER schema design.

1.
Manage Bank Information: The system should store and manage information about banks, including their names, identifiers, and
contact details.

2.
3.
Maintain Branch Hierarchy: The system should maintain the hierarchical relationship between banks and their branches, allowing
for the creation, modification, and deletion of branches associated with specific banks.

4.
5.
Handle Account Management: The system should handle the creation, modification, and deletion of accounts, ensuring their
association with specific banks and branches.

6.
7.
Manage Loan Issuance: The system should manage the issuance of loans, linking them to specific banks and branches.

8.
9.
 Track Depositor Information: The system should track information about depositors, including their names and account
associations.

10.
11.
Enforce Relationship Constraints: The system should enforce the constraints specified in the ER schema, ensuring data integrity
and preventing invalid relationships between entities.

12.

f. Suppose that every customer must have at least one account but is restricted to at most
two loans at a time, and that a bank branch cannot have more than 1,000 loans. How does
this show up on the (min, max) constraints?

Customer-Account Relationship:

 Minimum Cardinality (min): 1

This means that each customer must have at least one account. The original ER schema did not specify a minimum cardinality for
this relationship, but the new requirement mandates that every customer must be associated with at least one account.

Customer-Loan Relationship:

 Maximum Cardinality (max): 2

This means that each customer can have a maximum of two loans at a time. The original ER schema did not specify a maximum
cardinality for this relationship, but the new requirement limits the number of loans per customer to two.

Branch-Loan Relationship:

 Maximum Cardinality (max): 1000

This means that each bank branch cannot have more than 1000 loans at a time. The original ER schema did not specify a maximum
cardinality for this relationship, but the new requirement limits the number of loans per branch to 1000.

These constraints ensure that the system adheres to the specified business rules regarding customer accounts and branch loan
limits.

g. Mapping the ERD below to relational schemas

3. Mapping the following ERDs to relational schemas.

3.a An ER schema for a COMPANY database

3.b An ER schema for a SHIP_TRACKING database
3.c ER diagram for a car dealer

3.d ER diagram for a

3.e
 MaBacSi
MaBenhNhan HoTen
1 Nhan N
HoTen BacSi BenhNhan GioiTinh
M N
N
DieuTri NgaySinh
ChuyenMon Nam
Ngay Có
Thang
Ngay
KetQua
ThoiGian
1

ThanNhan

HoTenTN DiaChi SoDThoai