Module Code: COMP1845

Module Assessment Title: COURSEWORK 2024-25 TERM 2

Lecturer Name: Vu Thi Thuy Duong
Student Name: Nguyen Minh Anh
Student Code: GCS240028
Submission Date: 13/04/2025
 ​

TABLE OF CONTENTS
TABLE OF CONTENTS.......................................................................................................................1
Part 1....................................................................................................................................................... 3
QUESTION A................................................................................................................................... 4
1. Functional/Non-Functional Requirements..............................................................................4
1.1 Functional Requirements................................................................................................4
1.2 Non-Functional Requirements........................................................................................5
2. Business Case..........................................................................................................................6
2.1 System Purposes.............................................................................................................6
2.2 Key Users and Their Roles.............................................................................................6
3. Main Entities, Relationships................................................................................................... 6
3.1 Entities............................................................................................................................6
3.2 Relationships.................................................................................................................. 6
4. Business Scenarios.................................................................................................................7
User Registration and Role Assignment...............................................................................7
Form Submission and Processing.........................................................................................7
Room Assignment and Stay Management........................................................................... 8
Payment Handling................................................................................................................ 8
Feedback Collection............................................................................................................. 8
Role-Based Access and Permissions (through Rights)........................................................ 8
QUESTION B....................................................................................................................................9
1. Conceptual ER Diagram......................................................................................................... 9
2. Specify Keys, Relationships, Attributes (Logical ERD provided)......................................... 9
2.1 Constraints (Primary/Foreign Key)................................................................................ 9
2.2 Relationships (Updated)............................................................................................... 10
2.3 Attributes...................................................................................................................... 11
2.4 Logical ER Diagram.....................................................................................................13
3. Physical ER Diagram............................................................................................................ 13
3.1Note of Explanation.......................................................................................................14
3.1.1 Constraints (NULL / NOT NULL)..................................................................... 14
User Profile............................................................................................................14
User Role...............................................................................................................15
Rights.....................................................................................................................15
User Account.........................................................................................................15
Next of Kin............................................................................................................16
Source....................................................................................................................16
Form...................................................................................................................... 17
Payment................................................................................................................. 17
Room..................................................................................................................... 17
Stay........................................................................................................................18
Accommodation.................................................................................................... 19
Feedback................................................................................................................19
3.1.2 Data Types.......................................................................................................... 19

1
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

QUESTION C..................................................................................................................................20
Normalization Process (1NF->3NF).........................................................................................21
1. First Normal Form (1NF)......................................................................................................21
2. Second Normal Form (2NF)................................................................................................. 21
3. Third Normal Form (3NF).................................................................................................... 21
QUESTION D................................................................................................................................. 21
QUESTION E..................................................................................................................................21
QUESTION F.................................................................................................................................. 21
Part 2..................................................................................................................................................... 22
QUESTION A................................................................................................................................. 22
● Query:.................................................................................................................................... 22
● Output:................................................................................................................................... 23
QUESTION B..................................................................................................................................25
● Query:.................................................................................................................................... 25
● Output:................................................................................................................................... 25
QUESTION C..................................................................................................................................27
● Query:.................................................................................................................................... 28
● Output:................................................................................................................................... 28
QUESTION D................................................................................................................................. 29
● Query:.................................................................................................................................... 30
● Output:................................................................................................................................... 30
QUESTION E..................................................................................................................................31
● Query:.................................................................................................................................... 31
● Output:................................................................................................................................... 32
QUESTION F.................................................................................................................................. 32
● Query:.................................................................................................................................... 33
● Output:................................................................................................................................... 33
QUESTION G................................................................................................................................. 34
● Query:.................................................................................................................................... 34
● Output:................................................................................................................................... 35
QUESTION H................................................................................................................................. 35
● Query:.................................................................................................................................... 36
● Output:................................................................................................................................... 36

2
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

Part 1
(Design & Implementation of Database System)

3
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
NOTE:

------: Noun (Entity) ------: Verb (Relationship)

QUESTION A.
Provide proof of requirements elicitations to get some of the pertinent requirements. Clearly
demonstrate the scenario analysis and define the database design's scenario entities.

1. Functional/Non-Functional Requirements

1.1 Functional Requirements

-​ User Account & Role Management​

+​ Users must register, log in, and manage accounts via User Account​

+​ Each User Account is linked to a User Profile and a User Role (Client or
Staff)
-​ Form Submission & Processing​

+​ Clients submit accommodation request forms​

+​ Staff approve, reject, or update form statuses​

-​ Room Allocation & Stay Management​

+​ Approved clients are assigned rooms​

+​ Stay Relationship links User Profile ↔ Room ↔ Payment​

-​ Payment Processing​

4
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
+​ Payments are recorded for each stay​

+​ Payments are linked to the Stay relationship

-​ Feedback System​

+​ Clients submit feedback about their experience​

+​ Staff can view feedback but cannot modify it​

-​ Security & Access Control​

+​ Clients see only their own data (forms, stays, payments)​

+​ Staff manage forms and rooms but cannot access client payments​

-​ Next of Kin & Source Tracking​

+​ Clients add next of kin details for emergencies​

+​ The system tracks a client’s Source (e.g., illness, poverty, immigration status)

1.2 Non-Functional Requirements

-​ Performance & Scalability​

+​ Supports multiple users without lag​

+​ Can expand to include more accommodation types​

-​ Security & Compliance​

+​ Encrypts sensitive data (accounts, payments)​

+​ Ensures role-based access control (RBAC)​

-​ Availability & Reliability​

+​ Must have at least 99.9% uptime​

+​ Includes data backup and recovery mechanisms​

-​ Usability & Accessibility​

+​ User-friendly for both clients and staff

+​ Mobile and desktop compatibility​

-​ Data Integrity & Consistency​

+​ Prevents duplicate Stay entries​

+​ Ensures payments correctly link to stays

5
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
-​ Maintainability & Modifiability​

+​ Allows easy updates for new features

+​ Well-documented system structure

2. Business Case

2.1 System Purposes

Track forms, manage client accommodations, process payments, and control role-based
access for clients and staff.

2.2 Key Users and Their Roles

Clients: Register, submit forms, get assigned rooms, make payments, and provide feedback​
​ Staff: Review/approve/reject forms, manage user roles, and ensure system integrity​
​ Rights: Define specific permissions for each user role (who can do what)

3. Main Entities, Relationships

3.1 Entities

ENTITIES (NAME) DESCRIPTION

User Profile Contains personal details of users (clients & staff)

User Role Defines whether a user is a client or staff

Rights Specifies permissions linked to user roles

User Account Stores login credentials and security details for users

Source Represents a client’s background (ill, poor, out of prison, etc.)

Form Clients submit this for accommodation requests, reviewed by staff

Next of Kin Emergency contacts for clients (Client’s relative)

Accommodation The buildings where clients are housed

Room Stores room details and availability status

Payment Tracks payments related to a client's stay

Feedback Clients submit reviews about their experience

3.2 Relationships

ENTITY 1 RELATIONSHIP ENTITY 2 CARDINALITY DESCRIPTION

6
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

User Profile is User Role 1:1 Each user profile has one role
(Client/Staff)

User Profile uses User Account 1:1 Each user profile is linked to one user
account.

User Profile has Next of Kin 1:0..N A client can have none or multiple next
(Client) of kin

User Profile​ has Source N:1 Many clients can have the same source
(Client)

User Profile​ submits Form 1:N A client can submit many forms
(Client)

User Profile processes Form 1:N Staff can process many forms
(Staff)

User Profile writes Feedback 1:0..N A client can write none or multiple
(Client) feedback

User Profile reviews Feedback 1:0..N Staff can review none or multiple
(Staff) feedback

User Role granted Rights 1:N User role is granted specific rights

Accommodation has Room 1:N An accommodation has multiple rooms

Payment stay “Transaction” M:N Many payments are generated from

[User Profile many transactions
(Client)<->Room]

User Profile​ stay Room M:N + A client can stay in multiple rooms
(Client) + A room can have multiple stays (by
many clients)

4. Business Scenarios

User Registration and Role Assignment

-​ Client register and create a User Account
-​ System assigns a User Profile and User Role (Client/Staff)
-​ Rights define specific permission base on User Role

Form Submission and Processing

-​ Clients submit Forms for accommodation requests.
-​ Forms go through pending and then are approved or rejected by Staff
-​ Rights ensure only Staff can process Forms

7
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
Room Assignment and Stay Management
-​ When a Form is approved, the system automatically assigns the client to a Room
-​ The “Stay” relationship links User Profile (Client) with Room and Payment

*p/s: There will be a transaction when linking User Profile (Client) with Room. Thus,
Payment will occur. This means Clients will make many payments while staying in
the transaction between them and Room.*

-​ Clients must have a valid room assignment and payment to stay

-​ Rights restrict room assignment access to the system only

Payment Handling
-​ When a Stay relationship is created, a Payment record is automatically generated
-​ Payment includes amount, date, and purpose
-​ The system handles transactions (staff do not manage payments)
-​ Rights ensure only Clients see and process payments

Feedback Collection
-​ Clients can submit feedback about their experience
-​ Rights restrict feedback visibility to staff/admins

Role-Based Access and Permissions (through Rights)

-​ User Roles (Client/Staff) define allowed actions
-​ Rights entity manages detailed permissions of Clients/Staff, such as:
●​ Clients: Submit forms, make payments, write feedback
●​ Staff: Approve/reject forms, manage user roles, view client feedback
●​ System: Assign rooms, generate payments

8
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

QUESTION B.
Using the physical characteristics of the entities, such as relationships, datatypes, cardinality,
etc., from the case above, create a complete ER diagram.

1. Conceptual ER Diagram

Figure 1: A conceptual diagram demonstrates the relationship of entities in the system

2. Specify Keys, Relationships, Attributes (Logical ERD provided)

2.1 Constraints (Primary/Foreign Key)

ENTITIES (NAME) PRIMARY KEY FOREIGN KEY

User Profile userprofile_id source_id

User Role userrole_id

Rights rights_id userrole_id

User Account useraccount_id

9
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

Source source_id

Form form_id user_profile_id

Next of Kin nextofkin_id user_profile_id

Accommodation accommodation_id

Room room_id accommodation_id

Payment payment_id

Feedback feedback_id user_profile_id

Stay (updated entity) stay_id user_profile_id, room_id, payment_id

2.2 Relationships (Updated)

ENTITY 1 RELATIONSHIP ENTITY 2 CARDINALITY DESCRIPTION

User Profile is User Role 1:1 Each user profile has one role
(Client/Staff)

User Profile uses User Account 1:1 Each user profile is linked to one user
account.

User Profile has Next of Kin 1:0..N A client can have none or multiple next
(Client) of kin

User Profile​ has Source N:1 Many clients can have the same source
(Client)

User Profile​ submits Form 1:N A client can submit many forms
(Client)

User Profile processes Form 1:N Staff can process many forms
(Staff)

User Profile writes Feedback 1:0..N A client can write none or multiple
(Client) feedback

User Profile reviews Feedback 1:0..N Staff can review none or multiple
(Staff) feedback

User Role granted Rights 1:N User role is granted specific rights

Accommodation has Room 1:N An accommodation has multiple rooms

User Profile​ assigned to Stay (updated 1:N A client can have multiple stays over
(Client) entity) time

Stay (updated Assigned to Room N:1 A stay belongs to one room, but a room
entity) can have multiple stays over time

10
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

Stay (updated generates Payment N:1 A stay requires one payment

entity) transaction, but a payment transaction
can have multiple stays over time
*p/s: The “Stay” relationship is converted to a weak entity “Stay” to store the key of User
Profile (Client), Room, and Payment. (This entity now represents a client's assigned room
duration, linking User Profile, Room, and Payment)*

2.3 Attributes

ENTITIES ATTRIBUTES
(NAME)

User Profile user_profile_id (PK)

full_name
date_of_birth
email
phone_number
age
passport_photograph
illness
last_residence_address
source_id (FK)

User Role role_id (PK)

type (Client/Staff)
description

Rights right_id (PK)

right_name
action_type
description
role_id (FK)

User Account user_account_id (PK)

username
password

Source source_id (PK)

name
description
recommended_source_address

Form form_id (PK)

status (Pending, Approved, Rejected)
date
note
user_profile_id (FK)

Next of Kin next_of_kin_id (PK)

full_name
relationship
contact_number
11
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

user_profile_id (FK)

Accommodation accommodation_id (PK)

address
type (Shelter, Temporary Stay, etc.)
contact_number

Room room_id (PK)

type (Single, Shared, etc.)
status (Available, Occupied, Maintenance)
accommodation_id (FK)

Payment payment_id (PK)

amount
date
purpose

Feedback feedback_id (PK)

rating
comment
date
user_profile_id (FK)

Stay (updated stay_id (PK)

entity) start_date
end_date
description
user_profile_id (FK)
room_id (FK)
payment_id (FK)

12
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
2.4 Logical ER Diagram

Figure 2: A logical diagram demonstrates the relationship of entities in the system

3. Physical ER Diagram

Figure 3: A physical diagram demonstrates the relationship of entities in the system

13
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
3.1Note of Explanation

3.1.1 Constraints (NULL / NOT NULL)

User Profile

ATTRIBUTE NULL / NOT NULL DESCRIPTION

user_profile_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a user_profile_id, a
record cannot be uniquely
identified

full_name NOT NULL A user's full name is

considered core identifying
information

date_of_birth NOT NULL Date of birth is also a core

piece of identifying
information, and is needed
to calculate age

email NULL Email is optional. Some

users may not have or want
to provide an email address

phone_number NULL Phone number is optional.

Some users may not have or
want to provide a phone
number

age NOT NULL Although this can be

calculated, it is a core piece
of information, and should
always have a value

passport_photograph NULL Not all users may provide a

passport photo

illness NULL Illness information is

sensitive and optional

last_residence_address NULL Previous address is optional

source_id (FK) NOT NULL Every user profile must be

associated with a referral
source

User Role

14
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

ATTRIBUTE NULL / NOT NULL DESCRIPTION

role_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a role_id, a record
cannot be uniquely
identified

type (Client/Staff) NOT NULL Every role must have a

defined type

description NULL Role description is optional.

Rights

ATTRIBUTE NULL / NOT NULL DESCRIPTION

right_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a right_id, a record
cannot be uniquely
identified

right_name NOT NULL Every right must have a

name

action_type NOT NULL Every right must have an

action type

description NULL The description of a right is

optional

role_id (FK) NOT NULL Every rights must be

associated with a referral
user role

User Account

ATTRIBUTE NULL / NOT NULL DESCRIPTION

user_account_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a user_account_id,
a record cannot be uniquely
identified

username NOT NULL A username is essential for

user login and identification.
Without it, the system
15
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

wouldn't know who is trying

to access their account

password NOT NULL A password is vital for

security. Without it, anyone
could access a user's account

Next of Kin

ATTRIBUTE NULL / NOT NULL DESCRIPTION

next_of_kin_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a next_of_kin_id, a
record cannot be uniquely
identified

full_name NOT NULL Every next of kin must have

a full name

relationship NOT NULL Every next of kin must have

a relationship to the user
(client)

contact_number NOT NULL Every next of kin must have

a contact number

user_profile_id (FK) NULL Not every user profile

(client) will have emergency
contact information (which
is next of kin)

Source

ATTRIBUTE NULL / NOT NULL DESCRIPTION

source_id (PK) NOT NULL Primary keys must be unique

and cannot be empty. Without a
source_id, a record cannot be
uniquely identified

name NOT NULL Every source must have a name

description NULL Description is optional

recommended_source_addre NULL Address is optional

ss

16
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
Form

ATTRIBUTE NULL / NOT NULL DESCRIPTION

form_id (PK) NOT NULL Primary keys must be unique

and cannot be empty. Without
a form_id, a record cannot be
uniquely identified

status (Pending, Approved, NOT NULL Every form must have a status
Rejected)

date NOT NULL Every form must have a

submission date

note NULL Additional notes are optional

user_profile_id (FK) NOT NULL Every form must be associated

with a user profile (client)

Payment

ATTRIBUTE NULL / NOT NULL DESCRIPTION

payment_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a payment_id, a
record cannot be uniquely
identified

amount NOT NULL Every payment must have

an amount

date NOT NULL Every payment must have a

date

purpose NOT NULL Every payment must have a

purpose

Room

ATTRIBUTE NULL / NOT NULL DESCRIPTION

room_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a room_id, a record
cannot be uniquely
identified

17
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

type (Single, Shared, etc.) NOT NULL Every room must have a
defined type

status (Available, Occupied, NOT NULL Every room must have a

Maintenance status

accommodation_id (FK) NOT NULL Every room must be

associated with an
accommodation

Stay

ATTRIBUTE NULL / NOT NULL DESCRIPTION

stay_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a stay_id, a record
cannot be uniquely
identified

start_date NOT NULL A stay needs a starting date

to be meaningful. Without a
start date, it's impossible to
track when the stay began

end_date NULL The end_date could be

NULL because a stay might
be ongoing. Client won't
have an end date until the
stay is complete

description NULL A description of the stay is

optional

user_profile_id (FK) NOT NULL Every stay must be

associated with a user
profile

room_id (FK) NOT NULL Every stay must be

associated with a room

payment_id (FK) NOT NULL Every stay must be

associated with a payment

Accommodation

ATTRIBUTE NULL / NOT NULL DESCRIPTION

accommodation_id (PK) NOT NULL Primary keys must be

18
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

unique and cannot be empty.

Without a
accommodation_id, a record
cannot be uniquely
identified

address NOT NULL Every accommodation must

have an address

type (Shelter, Temporary NOT NULL Every accommodation must

Stay, etc.) have a type

contact_number NOT NULL Every accommodation must

have a contact number

Feedback

ATTRIBUTE NULL / NOT NULL DESCRIPTION

feedback_id (PK) NOT NULL Primary keys must be

unique and cannot be empty.
Without a feedback_id, a
record cannot be uniquely
identified

rating NOT NULL Every feedback must have a

rating

comment NULL A comment of the feedback

is optional

date NOT NULL Every feedback must have a

date

user_profile_id (FK) NULL Not every user profile

(client) will give a feedback

3.1.2 Data Types

-​ ENUM (Enumerated Type):

+​ Description: An ENUM is a data type that allows defining a list of predefined string
values. When creating an ENUM column, the allowed values are specified, and the
column can only store one of those values.
+​ Use Case: Ideal for columns with a limited set of possible values, like status fields
('Pending', 'Approved', 'Rejected') or roles ('Client', 'Staff'). It ensures data
consistency.

19
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​
-​ BLOB (Binary Large Object):
+​ Description: A BLOB is used to store binary data, such as images, audio, or video
files. It can handle large amounts of unstructured data.
+​ Use Case: Perfect for storing files directly in the database, though often a file path is
stored as text instead.
-​ INT CHECK (Integer with Check Constraint):
+​ Description: An INT is a data type for storing whole numbers (integers). The CHECK
constraint allows defining rules that the integer values must satisfy.
+​ Use Case: Useful for enforcing ranges or specific conditions on integer values, like a
rating system where values must be between 1 and 5.
-​ INT (Integer):
+​ Description: A standard data type for storing whole numbers (integers).
+​ Use Case: Used for numeric IDs, quantities, ages, and other whole number values.
-​ VARCHAR (Variable Character):
+​ Description: A VARCHAR is used to store variable-length strings of characters.
Specifying the maximum length of the string when defining the column.
+​ Use Case: Suitable for names, usernames, addresses, and other text data where the
length varies.
-​ TEXT:
+​ Description: A TEXT data type is used to store large amounts of text data. It's similar
to VARCHAR, but it can handle much longer strings.
+​ Use Case: Ideal for storing descriptions, comments, notes, and other long text fields.
-​ DECIMAL:
+​ Description: A DECIMAL is used to store precise numeric values with a fixed
number of decimal places. Specifying how many decimal places and how many digits
there are in total.
+​ Use Case: Essential for storing currency values, financial data, and other numbers
where precision is critical.
-​ DATE:
+​ Description: A DATE is used to store date values (year, month, day).
+​ Use Case: Perfect for storing dates of birth, submission dates, payment dates, and
other date-related information.

QUESTION C.
Using the case above as proof of normalization to the third normal

Normalization Process (1NF->3NF)

* Based on: User Profile, Next of Kin, and Source*

20
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

1. First Normal Form (1NF)

-​ Rule:
+​ Each column contains atomic (indivisible) values
+​ Each record is unique
-​ Result (Unnormalized Table):

User_Profile Full_Name DOB Illness Next_of_Kin Next_of_Kin_ Source Source_Address

_ID _Name Phone _Name

1 Nguyen 2006-10-10 Dementia Hoang Vy 0912345678 Police 123 Brook Park,

Anh Ohio

2 Nguyen 2006-11-11 Down Le Vinh 0987654321 Prison 543 Drake Ct.,

Bao Syndrome CA

-> This table contains repeating groups and multiple facts per entity

2. Second Normal Form (2NF)

-​ Rule:
+ Be in 1NF
+ No partial dependencies on a composite key
-​ Problem (Partial Dependencies): In the original table, Next of Kin details and Source details
that depend on Profile_ID but are repeating. For example:
+​ Next of Kin info is not directly related to the user’s profile attributes but instead to
their Next of Kin, which is a separate entity
+​ Source info (like Source Name and Source Address) also depends on Source, not
directly on the User_Profile
-​ Fixing: Create separate tables
-​ Result:
+ User_Profile table:
The User_Profile table now contains only attributes that depend on Profile_ID, like the user's
name, DOB, and illness

User_Profile_ID Full_Name DOB Illness

1 Nguyen Anh 2006-10-10 Dementia

2 Nguyen Bao 2006-11-11 Down Syndrome

+ Next_of_Kin table:
Profile_ID is a foreign key in the Next_of_Kin table, linking it to the User_Profile table. This
helps maintain the relationship between the user and their next of kin

21
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

Next_of_Kin_ID User_Profile_ID Next_of_Kin_Name Next_of_Kin_Phone

1 1 Hoang Vy 0912345678

2 2 Le Vinh 0987654321

+ Source table:
Source_ID is a primary key for the SOURCE table and is used in the User_Profile table to
link a user to their source

Source_ID Source_Name Source_Address

1 Police 123 Brook Park, Ohio

2 Prison 543 Drake Ct., CA

-> Every non-key attribute is now fully dependent on its table’s primary key (no partial dependency).
-> Still having transitive dependencies inside Source, like Source_Address depending on
Source_Name.

3. Third Normal Form (3NF)

-​ Rule:
+ Be in 2NF
+ No transitive dependency (non-key depending on another non-key)
-​ Problem (Transitive Dependency): In 2NF, Source_Address depends on Source_Name
(which is a non-key attribute), but Source_Name depends on the primary key (Source_ID).
-​ Fixing: Giving Source its own primary key (Source_ID) and making all attributes depend
only on that. Let the Source_ID be the foreign key in User_Profile table to link these source
information with the user (client)
-​ Result:
+ User_Profile table:

User_Profile_ID Full_Name DOB Illness Source_ID

1 Nguyen Anh 2006-10-10 Dementia 1

2 Nguyen Bao 2006-11-11 Down Syndrome 2

+ Next_of_Kin table:

Next_of_Kin_ID User_Profile_ID Next_of_Kin_Name Next_of_Kin_Phone

1 1 Hoang Vy 0912345678

2 2 Le Vinh 0987654321

22
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

+ Source table:

Source_ID Source_Name Source_Address

1 Police 123 Brook Park, Ohio

2 Prison 543 Drake Ct., CA

-> User_Profile links to Source via Source_ID

-> Source stores unique name and address
-> No non-key attribute depends on another non-key ( only on the primary key)

QUESTION D.
To illustrate the implementations, create tables and other required database objects.

QUESTION E.
Demonstrate that you have added more than 10 pieces of data to each database table.

QUESTION F.
To show that your database is working, you need to declare and execute two SQL queries that
join two or more of your tables.

23
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

Part 2
(Data Manipulation)

QUESTION A.

To retrieve every entry and column from the Adventureworks database's employee table, use
a SQL query. The results are sorted by job title in descending order.

●​ Query:

24
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

●​ Output:

25
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

26
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

QUESTION B.

Using table aliasing in the Adventureworks database, create a SQL query to retrieve every
row and column from the Person table. The output is sorted by first name in ascending order.

●​ Query:

●​ Output:

27
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

28
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

QUESTION C.

Create a SQL query to get every record and a subset of the AdventureWorks database's
person table's fields (FirstName, Middle, Name LastName, and businessentityid). The header
of the fourth column is now called Employee_id. Sorted the result by first name in ascending
order.

29
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

●​ Query:

●​ Output:

30
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

QUESTION D.​

Write a SQL query to retrieve just the product rows with a productline of 'T' and a
sellstartdate that is not NULL. Give back the product name, product number, and product
ID. The output was arranged by name in ascending order.

31
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

●​ Query:

●​ Output:

32
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

QUESTION E.

Create a SQL query that will get every row from the Adventureworks database's
salesorderheader table and determine the tax percentage on the outstanding balance. Return
the customer ID, sales order ID, order date, subtotal, and tax percentage column. The result
set was arranged on the subtotal in ascending order.

●​ Query:

33
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

●​ Output:

QUESTION F.

Create a SQL query to generate a list of unique job titles for the Adventureworks database's
employee table. The resultset was sorted in ascending order using the return jobtitle column.

34
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

●​ Query:

●​ Output:

35
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

QUESTION G. ​

Create a SQL query to determine how much freight each client has paid overall. Account
number, territory ID, return customer ID, and total freight. Using the customerid, sort the
output in ascending order.

●​ Query:

36
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

●​ Output:

QUESTION H.
Create a SQL query to determine each customer's average and subtotal sum. Return
customer ID, subtotal amount, and average. The results were grouped by salesperson and
customer IDs. The customerid column is used to sort the results.

37
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

●​ Query:

●​ Output:

38
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong
 ​

39
Module Code: COMP1845
Lecturer Name: Vu Thi Thuy Duong