SCHOOL OF COMPUTER SCIENCES

UNIVERSITI SAINS MALAYSIA

CMT221/CMM222: Database Organization and Design

Semester II, Academic Session: 2021/2022

Final Report

Group 22

Supervisor | Profesor Madya Dr. Zurinahni Binti Zainol & Dr. Azleena Binti Mohd Kassim

Project title:

i-Med Retail Pharmacy Database System

Names Matric USM Email Addresses Module Role Core/Minor

No
Darren Tan 151976 darrentanwh00@student.usm.my Customer Leader Minor
Wei-Hang
Tan Shi Ying 150665 shiyingtan99@student.usm.my Employee Member Minor
Ng Siau 150700 siauning@student.usm.my Sales Member Minor
Ning
Kan Xin Yan 152953 xinyankan@student.usm.my Inventory Member Minor

Date of submission

12 July 2022

1
Table of Contents

Contents Page
1.0 Introduction 3-5
1.1 Description of the Organization 3
1.2 Description of the Current System and its problems 3
1.3 Motivation 3
1.4 How will the system benefit the organization? 3
1.5 Module 4-5
- Customer Module
- Employee Module
- Sales Module
- Inventory Module

2.0 User Requirements and Business Rules 5-9

2.1 Customer Module 5
2.2 Employee Module 6
2.3 Sales Module 7
2.4 Inventory Module 8
2.5 Cross Module User requirements and Business Rules 9

3.0 Entity Relationship Modelling 10-24

3.1 Customer Module 10
3.2 Employee Module 13
3.3 Sales Module 16
3.4 Inventory Module 19
3.5 Combined ERD - Car Rental Database 23

4.0 Normalization 25-28

4.1 Customer Module 25
4.2 Employee Module 26
4.3 Sales Module 27
4.4 Inventory Module 28

5.0 Data Dictionary 29-40

5.1 Customer Module 29
5.2 Employee Module 31
5.3 Sales Module 34
5.4 Inventory Module 37

6.0 Data Implementation 41-55

7.0 Front-end System Design and Implementation 56-60
8.0 Project Problems and Pitfalls 61
9.0 Conclusion/ Recommendations/ Future Work 61
10.0 References 62

2
Introduction

Description of the Organization

In this current pandemic being extremely tough to cope with, retail pharmacies worldwide play a huge
role in selling medicines, supplements, equipment and many more to citizens in need. Dwelling into
such industry does shine a ray of business hope to us, therefore i-Med retail pharmacy wants to tag
along the retail pharmacy market in Penang and hopes to broaden it. This organization act as a platform
for new and existing customers to purchase product sold in stores with options of pick-up and delivery
method. The delivery method is only subjected to customers within the area so that their products will
be sent to their doorsteps without leaving the comfort of their own home. This retail pharmacy
organization also hopes that a successful database will open up a path for them to be one of the leading
retail pharmacies in Penang.

Description of the current system and its problems

The current database system allows customers to make purchase of products, but it only allows
customers within the area to purchase their desired product. Data storage, retrieval and manipulation
can be well-performed by the system, but limitations of the current system still do exist:

(1) Delivery method is not provided in this system. Customers are allowed to make pre-order and
pick up in store only.
(2) Payment method is limited to cash only.

Motivation

Our motivation is to design an efficient database management system that can provide convenience in
purchasing pharmacy products and managing the operation of retail pharmacy systematically. We also
wish to develop a database management system that can help end-users access highly accurate data
quickly, maintain data integrity and security at the same time.

How will the system benefit the organization

The main benefit of this system is to introduce i-Med Retail Pharmacy to ecommerce business.
Customers can make transaction with either online or offline method. By presenting online transaction
and delivery services, the organization is able to reach a wider range of customers as this make the
buying process more convenient for them. This system also eases the administration burden of the
organization by allowing the employees to manage and organize the information of sales, inventory,
employees, and customers.

3
Module

The i-Med Retail Pharmacy database system has 4 main modules, i.e., customer module, employee
module, sales module and inventory module:

1. Customer module
This module is designed to allow new customer to create their own account and update their
information respectively. In this database, this module will save the customer’s information
such as customer’s name, customer’s identification number, customer’s address, customer’s
email address, customer’s phone number, username and password. Every user must register
themselves in order to have access to the system. In doing so, user can browse through every
product that is available and purchase products from the system. After that, the customer will
have to choose either pick-up or delivery method for their products. The delivery method will
charge additional fees to user depending on the location of the customer. When the customer
proceeds to checkout, the customer can choose the payment method that they desired in order
to pay for the transaction with the options of cash, e-wallet, online banking and debit or credit
card.

2. Employee module
This module will save the employee’s information once the employee starts to work at i-Med
Retail Pharmacy. Employee’s information includes employee’s name, employee’s
identification number, employee’s phone number, employee’s username and password,
employee’s address and employee’s gender. This module also saves the register date of
employee, salary, qualification and status of employee. This module will allow employee to
view the information of customers, employees, sales and inventory according to the position of
the employee. The manager can view and updates the information on customers, employees,
inventory and sales. The pharmacist can view and updates the information on customer, sales
and inventory. In contrast, the pharmacy assistant can view and updates the information on
customer and inventory only. Specific information can be viewed and updated by specific
positions for the efficient running of the pharmacy.

3. Sales module
This module allows the customer to purchase various products in the pharmacy and generate a
receipt number for each purchase. The customer is required to log in to the account to be able
to purchase a product. This module will display the products with available stock based on their
categories such as over-the-counter (OTC) products, first-aid products, cosmetics, skincare

4
 products, supplements, personal care products, and other essentials. To purchase a product, the
customer is required to select the desired product, edit the required quantity, and add the product
to their cart. All products sold are not non-returnable and non-refundable. After the customer
completes their payment, the number of products in stock will be reduced in the inventory. The
sales record can be accessed by the employee to obtain information such as daily sales,
customer counts, peak purchase time, and best-selling products.

4. Inventory module
This module is designed to allow the employees to update the information of inventory storage
in i-Med Retail Pharmacy. All products are represented by different barcode based on their
categories. This module will display the barcode of products, order limit, quantity of product
in stock, product category, information of supplier company, product’s selling price and its
expiry date. The quantity of products in stock will be deducted when a customer has purchased
a product. Employees are able to access and update the information of products in the system.
When a product is running out of stock, employee will replenish stock from supplier and the
quantity of product in stock will be added. If a product is damaged or is expired, the product
will be returned to the supplier and stock of the product will be deducted. The invoice number
of buying and returning inventory will be stored in the system.

2.0 User Requirements and Business Rules

2.1 Customer Module

Table 1: User Requirements and Business Rules of Customer Module

User Requirements Business Rules

1.1) The system allows customers to make
multiple transactions. Customers can be
able to choose the products that they
want to buy based on the products’
availability.
1.2) After a transaction is made, customer
can choose their preferred payment
method such as cash, e-wallet, credit
card or debit card. Each transaction is
referred to a payment method but
1.1) One customer can make zero or many
transactions. Each transaction is made by only
one customer.
1.2) One transaction uses only one payment
method. Each payment method can be used in
many transactions.

5
 customers can choose different payment
methods for different transactions.

1.2) The customers can choose their
preferred pick-up time to collect their
product purchase from the pharmacy.
The pick-up time available for
customers to choose is only within 2
days of purchase.
1.3) The customers can apply for
memberships. Each customer needs to
provide their information such as his or
her name, IC number, phone number
and address. The customer who is
applying must be of age greater than or
equal to 18.
1.4) The customers who applied for
memberships are entitled for benefits
such as having privilege to buy certain
products first and discounts on
purchases.
1.3.1) One customer can choose only one
pick-up time per purchase. Each pick-up
time can be chosen by zero or many
customers per purchase.
1.3.2) The pick-up time available for
customers to choose is only within 2
days of purchase.
1.4.1) One customer can have zero or only one
membership. Membership can be
owned by one or many customers.
1.4.2) The customer’s age is greater than or
equal to 18.
1.5) One membership is entitled to one or many
benefits depending on availability. Each benefit
is entitled to one or many memberships.

2.2 Employee Module

Table 2: User Requirements and Business Rules of Employee Module

User Requirements Business Rules

2.1) Each employee in i-Med Retail Pharmacy 2.1) One employee can possess one position
can only possesses one position at one time. only. One position can be possessed by one or
There can be one or many employees hired for a many employees.
position. Examples of position include manager,
pharmacist, pharmacy technician, accountant,
etc.
2.2) Employees working in i-Med Retail 2.2) One employee can earn up to one type of
Pharmacy can be either part-time or full-time. salary depending on their working status. One

6
 Working status can influence the total salary type of salary can be earned only one employee
given to the employee. Each employee is not as referred to their working status and bonus.
allowed to have both working statuses.
2.3) One employee may signs zero or more 2.3) One employee can sign zero or many
invoices from suppliers each day. Only one invoices each day. One invoice can be signed by
signature from an employee is needed for an one employee only.
invoice after the products have been checked by
the employee.
2.4) One pharmacist may record zero or many 2.4) One pharmacist can record zero or many
prescriptions of customers each day. Each prescriptions per day. One prescription is
prescription from a customer is only written by recorded by one pharmacist only.
the specific pharmacist only.

2.3 Sales Module

Table 3: User Requirements and Business Rules of Sales Module

User Requirements Business Rules

3.1) The customer needs to buy at least one 3.1) One customer purchase one or many
product to make a transaction. Assumption is products. Each product is purchased by zero or
made that it can have multiple products on one many customers.
receipt. The quantity of the product will need to
be specified. The subtotal will be calculated
which equals to the number of quantities multiply
by the unit price.
3.2) The employee in charge for the cashier will 3.2) One cashier conduct zero or many sales
conduct the transaction. The total of all receipts transaction. Each sale is conducted by one and
generated in a cashier will be calculated and only one cashier.
recorded in the system.
3.3) Customer can purchase with discount 3.3) One sale include zero or one discount. Each
offered for certain products during promotion discount is included in zero or many sales.
and sale. Member will enjoy more discount
according to their privilege.
3.4) For different types of payment method used, 3.4) One sale have one and only one payment
the cashier will record the amount paid by the details. Each payment detail falls under one and
customer and other payment details such as bank only one sale.

7
 name of the cardholder, account number stated in
the card or e-wallet account number.

2.4 Inventory Module

Table 4: User Requirements and Business Rules of Inventory Module

User Requirements Business Rules

4.1) The products in I-Med Retail Pharmacy are 4.1) One supplier can supply one or many
supplied by many suppliers. Each supplier can products. One product can be supplied by one or
supply many products at the same time. many suppliers.
4.2) There are many categories of products, such 4.2) One product is included under one and only
as over-the-counter medicine, skincare, one category. One category consists of one or
cosmetics, first-aid products, supplements and many products.
personal care products. All products are
classified based on their categories.
4.3) Employees can view the status of products in 4.3) One product can have one and only one
the system to monitor and adjust the stock status. One status can include zero or many
replenishment. The status of products includes products.
“in stock”, “out of stock”, “expired” and
“damaged”.
4.4) When employee has ordered and purchased 4.4.1) One invoice can include one or many
inventory from the supplier, an invoice will be products. One product can be included in one or
received. The employee may order many many invoice.
products from either a supplier or different
suppliers at the same time. 4.4.2) An order should be made when the
quantity on hand of product is less than or equal
to 10.
4.5) The products purchased from the supplier 4.5) One invoice is shown to return zero or many
can be returned if it is wrong item, expired, products. Each returning of product needs one
damaged and so on. An invoice of purchasing the and only one invoice.
products to be returned is shown as a prove to
return the product to the supplier.

8
2.5 Cross-module User Requirement and Business Rules

Table 5: User Requirements and Business Rules of Cross-module

5.1) Employees are needed to assist customers 5.1.1) An employee involves in zero or many
with their purchases. The customers can also purchases. A purchase can only be managed by
choose their preferred pick-up time and see the one and only one employee.
total amount needed to be paid before collecting
their purchase. 5.1.2) A customer can choose a pick-up time per
purchase. A pick-up time can be chosen by one
or many customers for their purchases.
5.2) The system saves prescription history of 5.2) A prescription history is owned by one and
customers. Prescription history of customers are only one customer. A customer can have zero or
recorded by pharmacist. many prescriptions history.
5.3) Cashiers are operated by one employee at a 5.3) An employee can be in charge of zero or
time to manage customer’s purchases. many cashiers at a time. A cashier can be
operated by one and only one employee at a time.
5.4) The customer who has applied for 5.4.1) A membership includes zero or many
membership of I-Med Retail Pharmacy will get discount when purchasing products. A discount
discount for certain products. is included in zero or one membership.

5.4.2) A product has zero or one discount. A

discount is included in zero or many products.

9
3.0 Entity Relationship Modelling

All the entity relationship diagrams are drawn with Crow’s foot notation

3.1 CUSTOMER MODULE

Figure 1:ERD Diagram for Customer Module

10
Explanation:

Customer module contain 6 entities, namely CUSTOMER, MEMBERSHIP,

MEMBERSHIP_STATUS, MEMBERSHIP_BENEFIT, PURCHASE, and PAYMENT_METHOD.

Relationships:

• CUSTOMER entity and PURCHASE entity has one-to-many relationship (refer to business
rule 1.1) which is a weak relationship. PURCHASE entity is an optional entity to CUSTOMER
entity while CUSTOMER entity is a mandatory entity to PURCHASE entity.
• PURCHASE entity and PAYMENT_METHOD entity has one-to-many relationship (refer to
business rule 1.2) which is also a weak relationship. This is because they do not inherit primary
key from each other.
• CUSTOMER entity and MEMBERSHIP entity has a one-to-many relationship (refer to
business rule 1.4.1) and it is a weak relationship as they do not inherit primary key from each
other.
• MEMBERSHIP entity and MEMBERSHIP_BENEFIT entity has a many-to many relationship
(refer to business rule 1.5). In order to resolve this many-to-many relationships in this ERD,
MEMBERSHIP_STATUS entity acts as a bridge entity between the two entities.
• MEMBERSHIP_STATUS entity has a strong relationship between both MEMBERSHIP entity
and MEMBERSHIP_BENEFIT entity as it inherits both primary key from both
MEMBERSHIP entity and MEMBERSHIP_BENEFIT entity. At the same time,
MEMBERSHIP_STATUS entity is known to be a weak entity as it is existence dependent to
MEMBERSHIP entity and MEMBERSHIP_BENEFIT entity.

Key Constraints:

• The primary key of CUSTOMER entity is CUSTOMER_ID AND

CUSTOMER_USERNAME.
• PURCHASE entity has CUSTOMER_ID as primary and foreign key inherited from
CUSTOMER entity. PURCHASE entity also has foreign keys which are EMPLOYEE_ID from
EMPLOYEE entity, DISCOUNT_ID from MEMBERSHIP_BENEFIT entity and
PAYMENT_METHOD_ID from PAYMENT_METHOD entity.
• PAYMENT_METHOD entity has a primary key named PAYMENT_METHOD_ID.
• MEMBERSHIP entity has a primary key named MEMBERSHIP_ID and CUSTOMER_ID as
primary and foreign key inherited from CUSTOMER entity.

11
 • MEMBERSHIP_STATUS entity is a weak entity as it inherits two primary and foreign keys
namely MEMBERSHIP_ID from MEMBERSHIP entity and DISCOUNT_ID from
MEMBERSHIP_BENEFIT entity
• MEMBERSHIP_BENEFIT entity has DISCOUNT_ID as its primary key.

Clarification:

• In CUSTOMER entity, CUSTOMER_ID is a primary key which is unique ID after they are
registered into the system. Additionally, CUSTOMER_USERNAME is the second primary key
in CUSTOMER table which is the username that customers created in order to sign in into the
application. The other attributes are CUSTOMER_PASSWORD, CUSTOMER_FNAME,
CUSTOMER_LNAME, CUSTOMER_IC, CUSTOMER_EMAIL, CUSTOMER_PHONE
and CUSTOMER_ADDRESS. They represent the customer’s password, customer’s first name,
customer’s last name, customer’s identification number, customer’s email, customer’s phone
number and customer’s address.
• In PURCHASE entity, the primary key and foreign key, CUSTOMER_ID which can be used
to track purchases made by the customer. The other attributes which are PICK_UP_TIME (the
time at which the customer can choose to pick up their purchased product in the pharmacy),
AMOUNT_PAID (total amount of purchase) and EMPLOYEE ID (the employee that serve the
customer for a specific purchase).
• In PAYMENT_METHOD entity, the primary key, PAYMENT_METHOD_ID is the ID which
stand for different types of payment method such as by cash, credit card or e-wallet.
PAYMENT_METHOD_DESCRIPTION is the description of each type of payment method.
• In MEMBERSHIP entity, MEMBERSHIP_ID which is the primary key is actually an ID
generated by the system after the customer has successfully applied for a membership.
• In MEMBERSHIP_STATUS entity, the STATUS_INFO attribute shows whether or not the
membership own by the customer is active.
• In MEMBERSHIP_BENEFIT entity, the primary key, DISCOUNT_ID is the discount code
entitled for customers to purchase products available in the pharmacy. The other attribute is
DISCOUNT_DESCRIPTION which is the description of each type of discount.

12
3.2 EMPLOYEE MODULE

Figure 2: ERD Diagram for Employee Module

Explanation:

Employee module contains 9 entities, consists of supertype entity, EMPLOYEE and its subtypes entities,
MANAGER, PHARMACIST, PHARMACY_TECHNICIAN and ACCOUNTANT as well as the other
entities such as EMPLOYEE_ACC, SALARY, POSITION, and PRESCRIPTION_HISTORY.

Relationships:

• POSITION entity and EMPLOYEE entity has a one-to-many relationship (refer to business
rule 2.1) which is a weak relationship as primary keys of EMPLOYEE entity do not consist of
the primary key of POSITION entity.

13
 • EMPLOYEE entity and SALARY entity has a one-to-one relationship (refer to business rule
2.2) which is a strong relationship as primary keys of SALARY entity contain a primary key
(EMPLOYEE_ID) component of EMPLOYEE entity.
• EMPLOYEE entity and EMPLOYEE_ACC entity has a one-to-one relationship. There is a
strong relationship as primary keys of EMPLOYEE_ACC entity contain a primary key
(EMPLOYEE_ID) component of EMPLOYEE entity. EMPLOYEE entity and
EMPLOYEE_ACC are mandatory to each other.
• EMPLOYEE entity has 4 subtypes namely MANAGER, PHARMACIST, PHARMACY
TECHNICIAN and ACCOUNTANT. They all inherit relationships of EMPLOYEE entity.
• PHARMACIST entity and PRESCRIPTION_HISTORY entity has a one-to-many relationship
(refer to business rule 2.4). There is a strong relationship as primary keys of
PRESCRIPTION_HISTORY entity contains a primary key (EMPLOYEE_ID) from
EMPLOYEE entity.

Key Constraints:

• EMPLOYEE_ID and EMPLOYEE_IC are the composite primary key of EMPLOYEE entity.
EMPLOYEE entity is a strong entity as its composite primary key uniquely identify each entity
and it is existence independent. EMPLOYEE entity contains POSITION_ID from POSITION
entity as foreign key.
• POSITION entity also is a strong entity whose existence does not depend on any entity.
POSITION_ID is the primary key of POSITION entity.
• SALARY and EMPLOYEE_ACC entities are weak entities as they depend on the existence of
EMPLOYEE entity. SALARY entity inherits EMPLOYEE_ID from EMPLOYEE entity as
primary key and foreign key. Another primary key for SALARY entity is SALARY_ID.
EMPLOYEE_ACC also inherits EMPLOYEE_ID from EMPLOYEE entity as primary key and
foreign key. EMPLOYEE_PASSWORD is another primary key of EMPLOYEE_ACC.
• EMPLOYEE entity has four disjoint entity subtypes in which an entity supertype occurrence
can be a member of only one of the subtypes and EMPLOYEE_TYPE is the subtype
discriminator. MANAGER subtype has ASSIGN_DATE as unique attribute. PHARMACIST
subtype has LICENCE_TYPE, APC_NO and REGISTRATION_CERT_NO as unique
attributes. PHARMACY_TECHNICIAN and ACCOUNTANT subtypes have
CERT_DESCRIPTION as their unique attribute.
• PRESCRIPTION_HISTORY entity inherits EMPLOYEE_ID from PHARMACIST subtype as
primary key and foreign key as well as inherits CUSTOMER_ID from CUSTOMER (in
Customer module) as primary key and foreign key. PRESCRIPTION_HISTORY entity is

14
 considered as weak entity as its primary keys are totally derived from other entities in the
relationship.

Clarification:

• In EMPLOYEE entity, a unique ID, EMPLOYEE_ID is generated after an employee is

registered into the system. EMPLOYEE_ID and EMPLOYEE_IC are the primary keys which
uniquely identify each entity. Attributes involved to store information of each employee such
as EMPLOYEE_FNAME, EMPLOYEE_LNAME, EMPLOYEE_PHONE,
EMPLOYEE_ADDRESS, EMPLOYEE_GENDER, EMPLOYEE_EMAIL,
EMPLOYEE_START_DATE, EMPLOYEE_TYPE and POSITION_ID. EMPLOYEE_TYPE
is to differentiate type of specific role in pharmacy.
• In POSITION entity, POSITION_ID is the primary key which represent for the various type of
position such as pharmacist assistant, staff and so on. POSITION_NAME describe the name of
position, CHARGE_HOUR describe the charge per hour for position.
• In SALARY entity, BASIC_SALARY is the basic salary without bonus involved while
EMPLOYEE_BONUS is the total amount of all bonuses only. EMPLOYEE_STATUS
represent whether the employee’s status is part-time or full time.
• EMPLOYEE_ACC entity has EMPLOYEE_PASSWORD which created by each employee
used to login into their own account together with their unique employee’s id.
• PRESCRIPTION_DESCRIPTION in PRESCRIPTION_HISTORY entity is used to describe
the prescription of a particular customer written by a particular pharmacist.
DATE_RECORDED is represents the date when the prescription is recorded. EMPLOYEE_ID
and CUSTOMER_ID are the primary keys used to identify each prescription.

15
3.3 SALE MODULE

Figure 3: ERD Diagram for Sale Module

Explanation:

Sales module contains 5 entities, namely SALE, SALE_ITEM, PAYMENT_DETAILS, DISCOUNT

and CASHIER.

Relationships:

• SALE entity and PRODUCT entity has a many-to-many relationship (Refer business rule 3.1).
To resolve this many-to-many relationship in this logical ERD, SALE_ITEM entity acts as a
bridge entity between the two entities.
• SALE_ITEM entity has a strong relationship between SALE entity and PRODUCT entity as it
inherits primary keys from both SALE entity and PRODUCT entity. The SALE_ITEM entity
is said to be a weak entity as itis existence dependent to SALE entity and PRODUCT entity.
• The relationship between CASHIER and SALE (Refer business rule 3.2) is one-to-many
relationship.
• DISCOUNT and SALE has a zero-to-many relationship (Refer business rule 3.3).

16
 • The relationship between SALE and DISCOUNT, SALE and CASHIER are weak
relationships. The primary keys of the DISCOUNT and CASHIER does not contain a primary
key component of the SALE entity.
• The relationship between SALE and PAYMENT_DETAILS is strong relationship as the
primary key of the PAYMENT_DETAILS entity is from the SALE entity. The
PAYMENT_DETAILS entity is said to be a weak entity and it is existence dependent on the
SALE entity as the entity occurrence of PAYMENT_DETAILS entity depends on the SALE
entity.
• PAYMENT_DETAILS and CASHIER entities are mandatory to SALE entity. SALE entity is
mandatory to SALE_ITEM entity.
• DISCOUNT entity is optional to SALE.

Key Constraints:

• The primary key of SALE entity is RECEIPT_NO. Foreign keys consist of CUSTOMER_ID,
DISCOUNT_ID and CASHIER_ID. CUSTOMER_ID refers CUSTOMER entity,
CASHIER_STATUS_ID refers CASHIER_STATUS entity, DISCOUNT_ID refers to
DISCOUNT entity.
• SALE_ITEM entity has a primary key named SALE_PRODUCT_ID and its foreign keys
consists of PRODUCT_ID from PRODUCT entity as well as RECEIPT_NO from SALE entity.
• PAYMENT_DETAILS is a weak entity which inherits RECEIPT_NO as primary key. Foreign
keys consist of CUSTOMER_ID from CUSTOMER entity and PAYMENT_METHOD_ID
from PAYMENT_METHOD entity.
• DISCOUNT entity has a primary key named DISCOUNT_ID which is inherited from
MEMBERSHIP entity. DISCOUNT entity also contains two foreign keys which is
PRODUCT_ID from PRODUCT entity and MEMBERSHIP_ID from MEMBERSHIP entity.
• CASHIER entity has a primary key named CASHIER_ID and a foreign key from EMPLOYEE
entity which is EMPLOYEE_ID.

Clarification:

• In SALE entity, the RECEIPT_NO is a unique ID when a receipt is generated each time after
the purchase of a customer. The other attributes are TIME_CREATED, TIME_PAID,
RECEIPT_AMOUNT and AMOUNT_PAID. TIME_CREATED is the time when a sale record
is generated in the system. RECEIPT_AMOUNT is the original amount that the customer is

17
 charged. AMOUNT_PAID is the actual amount that is paid by the customer. It can be null
because this information is not always existed at the moment a receipt is created.
• In SALE_ITEM entity, SALES_QTY is the quantity of product that is sold and is charged on
that receipt. UNIT_PRICE is the same value as PRODUCT_PRICE at the moment the sale is
created. The UNIT_PRICE is saved based on the time because PRODUCT_PRICE in the
PRODUCT table can change over time. SUB_TOTAL is the product of SALES_QTY and
UNIT_PRICE, this is different from RECEIPT_AMOUNT which is the sum of all product
prices belonging to the same sale.
• In PAYMENT_DETAILS entity, CASH is the amount of cash paid by the customer.
CARD_TYPE is the types of bank cards accepted such as credit cards or debit cards.
BANK_ACC_NAME is the bank name of the cardholder. BANK_ACC_NUMBER is the
account number stated in the debit or credit card used by the customer to make the payment.
EWALLET_TYPE is the type of e-wallet used by the customer for the payment, including
“Touchn’Go”, “Boost”, “GrabPay”, “ShopeePay”, etc. EWALLET_TRANSID is the ID
generated by the applications when the user makes payment using e-wallet which then will be
scanned by the cashier.
• In DISCOUNT entity, DISCOUNT_VALUE is the amount of discount offered. Generally, the
discount amount would be in percentage. DATE_CREATED is the date when the offer was
entered into the system. MAX_DISCOUNT_AMOUNT is the maximum discount that a
customer can get with a particular product offered.
• In CASHIER entity, TIME_CREATED is the time when an employee logs in to the cashier.
TIME_ENDED is the time when an employee logs out from the cashier. TOTAL_SALES is
the total amount of sale recorded in the period a cashier is logged in. DATE_CREATED is the
date when the cashier conducts transactions.

18
3.4 INVENTORY MODULE

Figure 4: ERD Diagram for Inventory Module

Explanation:

Inventory module contains 8 entities which includes PRODUCT, PRODUCT_INVOICE, INVOICE,

RETURN_PRODUCT, PRODUCT_SUPPLIER, SUPPLIER, PRODUCT_CATEGORY and
PRODUCT_STATUS.

19
Relationships:

• PRODUCT entity and SUPPLIER entity has a many-to-many relationship (Refer business rule
4.1). To resolve this many-to-many relationship, PRODUCT_SUPPLIER entity acts as a bridge
entity between the two entities.
• PRODUCT_SUPPLIER entity has a strong relationship with both PRODUCT entity and
SUPPLIER entity as it inherits both primary keys from PRODUCT entity and SUPPLIER
entity. PRODUCT_SUPPLIER entity is also a weak entity because it is existence dependent on
PRODUCT entity and SUPPLIER entity, which means it will only exist when it is associated
with the occurrence of PRODUCT entity and SUPPLIER entity.
• The relationship between PRODUCT entity and PRODUCT_CATEGORY entity is one-to-
many relationship (Refer business rule 4.2). These two entities have a weak relationship as the
primary key of the PRODUCT_CATEGORY entity does not contain the primary key
component of PRODUCT entity. PRODUCT_CATEGORY entity is mandatory to PRODUCT
entity.
• The relationship between PRODUCT entity and PRODUCT_STATUS entity is zero-to-many
relationship (Refer business rule 4.3). These two entities have a weak relationship as the
primary key of the PRODUCT_STATUS entity does not contain the primary key component
of PRODUCT entity. PRODUCT entity is optional to PRODUCT_STATUS entity.
• PRODUCT entity and INVOICE entity has a many-to-many relationship (Refer business rule
4.4.1). To resolve this many-to-many relationship, PRODUCT_INVOICE entity acts as a
bridge entity between the two entities.
• PRODUCT_INVOICE entity has a strong relationship with both PRODUCT entity and
INVOICE entity as it inherits both primary keys from PRODUCT entity and INVOICE entity.
PRODUCT_INVOICE entity is also a weak entity because it is existence dependent on
PRODUCT entity and INVOICE entity.
• INVOICE entity and RETURN_PRODUCT entity has a zero-to-many relationship (Refer
business rule 4.5). This is a weak relationship because the primary key of
RETURN_PRODUCT entity does not contain the primary key component of INVOICE entity.
RETURN_PRODUCT is optional to INVOICE.

Key Constraints:

• The primary key of PRODUCT entity is PRODUCT_ID. It contains foreign keys which are
PRODUCT_STATUS_ID and CATEGORY_ID. PRODUCT_STATUS_ID refers to
PRODUCT_STATUS entity, whereas CATEGORY_ID refers to PRODUCT_CATEGORY
entity.

20
 • SUPPLIER entity has primary key SUPPLIER_ID to determine SUPPLIER_NAME,
SUPPLIER_PHONE, SUPPLIER_ADDRESS, and SUPPLIER_EMAIL.
• In PRODUCT_SUPPLIER entity, PRODUCT_ID and SUPPLIER_ID are composite primary
key. This composite primary key are also foreign keys from PRODUCT entity and SUPPLIER
entity respectively. PRODUCT_SUPPLIER is a weak entity as it is existence dependent to the
PRODUCT and SUPPLIER entity.
• PRODUCT_CATEGORY entity has CATEGORY_ID as primary key to determine
CATEGORY_TYPE and CATEGORY_DESCRIPTION. PRODUCT_CATEGORY is a
strong entity as it is existence independent on other entities.
• The primary key of PRODUCT_STATUS entity is PRODUCT_STATUS_ID which
determines the STATUS_NAME. It is a strong entity as it is existence independent on other
entities.
• INVOICE entity has primary key INVOICE_ID. It has foreign key SUPPLIER_ID from
SUPPLIER entity and EMPLOYEE_ID from EMPLOYEE entity.
• In PRODUCT_INVOICE entity, PRODUCT_ID and INVOICE_ID are composite primary key
to determine QUANTITY_RESTOCK. This composite primary key are also foreign keys from
PRODUCT entity and INVOICE entity respectively. PRODUCT_INVOICE is a weak entity
as it is existence dependent to the PRODUCT and INVOICE entity.
• RETURN_PRODUCT has RETURN_ID as primary key. It also consists of INVOICE_ID from
INVOICE entity and PRODUCT_ID from PRODUCT entity as foreign key. It is a strong entity
as it is existence independent on other entities.

Clarification:

• In PRODUCT entity, PRODUCT_ID is a unique ID generated when a product is recorded into

the system. The other attributes such as PRODUCT_EXPIRY, PRODUCT_QUANTITY,
PRODUCT_PRICE and PRODUCT_NAME is to record the product expiry date, product
quantity on hand, product prices, and the full name of the product respectively.
• In SUPPLIER entity, the primary key SUPPLIER_ID is a unique ID after they are recorded
into the system. The other attributes such as SUPPLIER_NAME, SUPPLIER_PHONE,
SUPPLIER_ADDRESS and SUPPLIER_EMAIL is to represent the details of the supplier such
as name, phone number, address and email.
• In PRODUCT_INVOICE entity, QUANTITY_RESTOCK is to show the quantity of the
products that is ordered from the supplier for replenishment purpose.
• In INVOICE entity, the unique ID, INVOICE_ID is generated when an invoice is received from
the supplier. The other attributes, INVOICE_NO and INVOICE_DATE is to record the details

21
 of the invoice such as invoice number which is generated by the supplier and date of transaction
made. The INVOICE_AMOUNT is to show the total amount of product prices which have
ordered for replenishment. EMPLOYEE_ID is the id for employee who signed the invoice
whereas SIGN_DATE is to record the date of the employee signs on the invoice.
• In RETURN_PRODUCT entity, RETURN_ID is primary key. RETURN_DATE represents
the date of the day returning products, RETURN_QUANTITY is the quantity of products to be
returned and RETURN_REASON represents the reason of returning products such as product
damaged, products expired.
• In PRODUCT_CATEGORY entity, CATEGORY_ID is the ID of the products type.
CATEGORY_TYPE is the products type such as over-the-counter medicine, skincare,
cosmetics, first-aid products, supplements and personal care products.
CATEGORY_DESCRIPTION describes the product type.
• In PRODUCT_STATUS, PRODUCT_STATUS_ID is the ID of the product status whereas
STATUS_NAME is to describe the status including “in stock”, “out of stock”, “expired” and
“damaged”.

22
3.5 Combined ERD - i-Med Retail Pharmacy Database

Figure 5: ERD Diagram for the entire i-Med retail pharmacy database

Explanation:

This ERD is the combination of all the four modules. This ERD contains 29 entities and 34
relationships in total. After the combination of all 4 modules, there are 4 relationships that overlap
with each module.

Relationships:

• The relationship between EMPLOYEE and PURCHASE (Refer business rule 5.1.1),
CASHIER and EMPLOYEE (Refer business rule 5.3) have one-to-many relationships which
are weak relationships. The primary key of the PURCHASE and CASHIER entities do not
contain primary key component of the EMPLOYEE entity. CASHIER and PURCHASE
entities are optional to EMPLOYEE entity.

23
• The relationship between PHARMACIST and CUSTOMER is many-to-many relationship
(Refer business rule 5.2). PRESCRIPTION_HISTORY acts as a bridge entity to resolve this
many-to-many relationship.
• PRESCRIPTION_HISTORY has a strong relationship between both PHARMACIST and
CUSTOMER entity as the composite keys of the PRESCRIPTION_HISTORY entity namely
CUSTOMER_ID and EMPLOYEE_ID also exists as the primary key of the CUSTOMER
entity and PHARMACIST entity.
• DISCOUNT entity and PRODUCT entity have a zero-to-many relationship (Refer business
rule 5.4.2) which is a weak relationship as they do not inherit primary key from each other.
• The relationship between DISCOUNT and MEMBERSHIP_BENEFIT (Refer business rule
5.4.1) is a strong relationship as the primary key of the DISCOUNT entity are from the
MEMBERSHIP_BENEFIT entity. The DISCOUNT entity is said to be a weak entity as it is
existence dependent on the MEMBERSHIP_BENEFIT entity.
• CUSTOMER entity is mandatory to PRESCRIPTION_HISTORY entity, SALE entity and
PAYMENT_DETAILS entity.

24
4.0 Normalization

Normalization is practically a database schema design approach that involves the objectives of
modifying an existing schema to effectively reduce data redundancies and reliance. In order to improve
the clarity of data organization, normalization approach is used to separate a bigger table into several
smaller tables at which relationships are defined between them. The forms that are lower than that of
3NF is considered to have data redundancy that leads to anomalies such as insertion, deletion or update
ones. Moreover, partial and transitive dependencies do not exist in 3NF tables. However, the ones that
consist of more than one candidate key are not defined as BCNF. Furthermore, any forms that are
specifically higher than 3NF are considered as unnecessary as those tables are only required to obtain
specific results.

4.1 Customer module

All seven tables in the customer module are in 3NF due to no partial and transitive dependencies. The
below shows the dependency diagrams of the tables. Partial and transitive dependencies do not exist.

Note: In MEMBERSHIP_STATUS table, the DISCOUNT_ID can determine the current

STATUS_INFO but not the membership status needed for clarification at the time of transaction.
Therefore, partial dependencies are arguably absent in the MEMBERSHIP_STATUS table.

25
4.2 Employee module

All ten tables are in 3NF which do not contain partial dependency and transitive dependency. Below
shows the dependency diagrams of the tables.

NOTE: All attributes in table EMPLOYEE_ACC which is EMPLOYEE_ID and

EMPLOYEE_PASSWORD are primary keys.

26
4.3 Sales module

Tables named SALE, CASHIER, SALE_ITEM and DISCOUNT in the sales module are in 3NF
because there are no partial and transitive dependencies. The PAYMENT_DETAILS table is in 2NF
because there is transitive dependency.

27
4.4 Inventory module

All eight tables in the inventory module are in 3NF because there are no partial and transitive
dependencies. Below shows the dependency diagrams of the tables. Partial and transitive dependencies
are absent.

Note: All attributes in PRODUCT_SUPPLIER which is PRODUCT_ID and SUPPLIER_ID are

primary keys.

28
5.0 Data Dictionary

5.1 Customer module

Table Name Attribute Contents Data Type Format Null PK Reference

Name able or Table
FK
CUSTOMER CUSTOMER_ Customer’s NUMBER 1 No PK
ID id (*,0)
CUSTOMER_ Customer’s VARCHAR Tom1199 No PK
USERNAME username 2(20)
CUSTOMER_ Customer’s VARCHAR Tom No
FNAME first name 2(20)
CUSTOMER_ Customer’s VARCHAR Lim No
LNAME last name 2(20)
CUSTOMER_ Customer’s NUMBER 987056 Yes
IC ic (*,0) 321495
CUSTOMER_ Customer’s VARCHAR No
EMAIL email 2(30)
CUSTOMER_ Customer’s NUMBER Yes
PHONE phone no (11,0)
CUSTOMER_ Customer’s VARCHAR 54b, Lorong Yes
ADDRESS address 2(150) 3, Laguna
Merbok,
08000
Sungai
Petani,
Kedah
CUSTOMER_ Customer’s VARCHAR Abc123 No
PASSWORD password 2(20)
PURCHASE CUSTOMER_ Customer’s NUMBER 1 No PK, CUSTOM
ID id (*,0) FK ER
PICK_UP_TI Product’s DATE 10/06/2022 No
ME pick-up
time
chosen by
customer

29
 EMPLOYEE_ Employee’ VARCHAR 1 No FK EMPLOY
ID s id 2(8) EE
DISCOUNT_ Discount VARCHAR STK123 No FK MEMBER
ID code for 2(20) SHIP_BE
product NEFIT
PAYMENT_ Payment NUMBER 1 No FK PAYMEN
METHOD_ID method’s (1,0) T_METH
id OD
PAYMENT_ PAYMENT_ Payment NUMBER 1 No PK
METHOD METHOD_ID method’s (1,0)
id
PAYMENT_ Descriptio VARCHAR BY CASH No
METHOD_D n of 2(20)
ESCRIPTION payment
method
MEMBERS MEMBERSHI Customer’s NUMBER 1 No PK
HIP P_ID membershi (*,0)
p id
CUSTOMER_ Customer’s NUMBER 1 No PK, CUSTOM
ID id (*,0) FK ER
MEMBERS MEMBERSHI Customer’s NUMBER 1 No PK, MEMBER
HIP_STATU P_ID membershi (*,0) FK SHIP
S p id
DISCOUNT_ Discount VARCHAR STK123 No PK, MEMBER
ID code for 2(20) FK SHIP_BE
product NEFIT
STATUS_INF Customer’s VARCHAR ACTIVE No
O membershi 2 (10)
p status
MEMBERS DISCOUNT_ Discount VARCHAR STK123 No PK
HIP_BENEF ID code for 2(20)
IT product
DISCOUNT_ Descriptio VARCHAR SKINCARE No
DESCRIPTIO n of 2(50) 10% OFF
N discount

30
5.2 Employee module

Table Name Attribute Name Contents Data Format Nulla PK Reference

Type ble or Table
FK
EMPLOYEE EMPLOYEE_I Employee’s id VARC ABCD12 No PK
D HAR2 34
(8)
EMPLOYEE_I Employee’s NUM 0123456 No
C identification BER 78900
card number (12)
EMPLOYEE_F Employee’s VARC Mike No
NAME first name HAR2
(20)
EMPLOYEE_ Employee’s VARC Lim No
LNAME last name HAR2
(20)
EMPLOYEE_P Employee’ NUM 0123456 No
HONE current phone BER 7890
number (11,0)
EMPLOYEE_ Employee’s VARC 62, No
ADDRESS current HAR2 Persiaran
address (150) Gurney,
10250
George
Town,
Pulau
Pinang
EMPLOYEE_ Employee’s CHAR F No
GENDER gender (1)
EMPLOYEE_ Employee’s VARC Someone No
EMAIL email HAR2 @gmail.c
(30) om
EMPLOYEE_S Start working DATE 11/11/20 No
TART_DATE date of 11
employee

31
 EMPLOYEE_ Belongs to CHAR M Yes
TYPE some specific (1)
position
POSITION_ID Id for NUM 0001 No FK POSITIO
verification of BER N
the position (4,0)
EMPLOYEE EMPLOYEE_I Employee’s id VARC ABCD12 No PK, EMPLOY
_ACC D HAR2 34 FK EE
(8)
EMPLOYEE_P Password VARC Abcd123 No PK
ASSWORD created by HAR2 45#
employee to (10)
login
POSITION POSITION_ID Id for NUM 0001 No PK
verification of BER
the position (4,0)

POSITION_N Position’s VARC Shelf No

AME name HAR2 Replenis
(50) her
CHARGE_HO Charge per NUM 50.00 No
UR hour BER
(7,2)
SALARY EMPLOYEE_I Employee’s id VARC ABCD12 No PK
D HAR2 34
(8)
SALARY_ID Salary’s id for NUM 1001 No PK
each salary BER
given (4,0)
BASIC_SALA Employee’s NUM 5000.00 No
RY month basic BER
salary (7,2)
excludes any
bonus

32
 TOTAL_SALA Tatal salary NUM 2100.00 No
RY includes basic BER(7
salary and ,2)
bonus
EMPLOYEE_ Bonus gained NUM 800.00 No
BONUS by employee BER
(7,2)
EMPLOYEE_S Employee’s VARC PART- No
TATUS working status HAR2 TIME
(Part- (9)
time/Full-
time)
PHARMAC EMPLOYEE_I Employee’s id VARC ABCD12 No PK, EMPLOY
Y_TECHNI D HAR2 34 FK EE
CIAN (8)
CERT_DESCR Description of VARC No
IPTION the HAR2
certification (150)
PHAMACIS EMPLOYEE_I Employee’s id VARC ABCD12 No PK, EMPLOY
T D HAR2 34 FK EE
(8)
LICENCE_TY Pharmacist's VARC E No
PE license type HAR2
(80)
APC_NO Annual NUM 1234567 No
Practicing BER 8
Certificate (8,0)
(APC)
number
REGISTRATI Registration NUM 1234567 No
ON_CERT_N certification BER 8
O number of (8,0)
pharmacist
MANAGER EMPLOYEE_I Employes'd VARC ABCD12 No PK, EMPLOY
D HAR2 34 FK EE
(8)

33
 ASSIGN_DAT Date when DATE 11/11/20 No
E become 11
manager
ACCOUNT EMPLOYEE_I Employee’s id VARC ABCD12 No PK, EMPLOY
ANT D HAR2 34 FK EE
(8)
CERT_DESCR Description of VARC Associati No
IPTION the HAR2 on of
certification (150) Chartere
d
Certified
Accounta
nts
(ACCA)
PRESCRIPT EMPLOYEE_I Employee’s id VARC ABCD12 No PK, EMPLOY
ION_HISTO D HAR2 34 FK EE
RY (8)
CUSTOMER_I Customer’s id NUM 1 No PK, CUSTO
D BER FK MER
(*,0)
PRESCRIPTIO Description of VARC Some No
N_DESCRIPTI the HAR2 prescripti
ON prescription (500) on
examples
DATE_RECO Date when the DATE 11/11/20 No
RDED prescription is 11
recorded

5.3 Sales module

Table Name Attribute Contents Data Type Format Null PK Reference

Name able or Table
FK
SALE RECEIPT_NO Receipt NUMBER 100001 No PK
number (10,0)

34
 CUSTOMER_ Customer’ NUMBER 1 No FK CUSTOM
ID s id (*,0) ER
CASHIER_ID Cashier’s NUMBER 001 Yes FK CASHIER
id (*,0)
DISCOUNT_I Id for VARCHAR STK123 Yes FK DISCOU
D discount 2(20) NT
TIME_CREA Receipt’s TIMESTA YYYY- No
TED generated MP(2) MM-DD
time HH24:MI:S
S
RECEIPT_A Total NUMBER 12345.67 No
MOUNT amount of (7,2)
receipt
AMOUNT_P Amount NUMBER 12345.67 Yes
AID paid by (7,2)
customer
SALE_ITEM SALE_PROD Sale- NUMBER 1 No PK
UCT_ID product id (*,0)
SALES_QTY Quantity NUMBER 1 No
purchased (*,0)
UNIT_PRICE Unit price NUMBER 12345.67 No
of the (7,2)
product
SUB_TOTAL The NUMBER 12345.67 No
product of (7,2)
quantity
and price
PRODUCT_I ID for NUMBER 0001 No FK PRODUC
D product (*,0) T
RECEIPT_NO Receipt NUMBER 100001 No FK SALE
number (10)
PAYMENT_ RECEIPT_NO Receipt NUMBER 100001 No PK, SALE
DETAILS number (10) FK
AMOUNT_P Amount NUMBER 12345.67 Yes
AID paid by (7,2)
customer

35
 CASH Cash NUMBER 1/0 No
payment or (*,0)
otherwise
PAYMENT_ Payment NUMBER 1 No FK PAYMEN
METHOD_ID method’s (1,0) T_METH
id OD
CUSTOMER_ Customer’ NUMBER 1 No FK CUSTOM
ID s id (*,0) ER
BANKCAR BANK_ACC_ BANK VARCHAR 123456XX No PK
D NUMBER ACCOUN 2(20) XXXX1234
T
NUMBER
CARD_TYPE Type of VARCHAR CREDIT/ No
the card 2(10) DEBIT
BANK_ACC_ Bank VARCHAR MAYBAN No
NAME account 2(50) K
name
EWALLET EWALLET_T Transactio VARCHAR ABC12345 No PK
RANSID n id for e- 2(50)
wallet
EWALLET_T Type of e- VARCHAR TNG No
YPE wallet 2(10)
DISCOUNT DISCOUNT_I Id for VARCHAR STK123 No PK
D discount 2(20)
DISCOUNT_ Discount NUMBER 15 No
VALUE value (2,0)
DATE_CREA Date DATE YYYY- No
TED created MM-DD
MAX_DISCO Maximum Number 123.45 Yes
UNT_AMOU amount for (5,2)
NT discount
PRODUCT_I Id for NUMBER 0001 No FK PRODUC
D product (*,0) T
MEMBERSHI Customer’ NUMBER 1 No FK MEMBER
P_ID s (*,0) SHIP

36
 membershi
p id
CASHIER CASHIER_ID Cashier’s NUMBER 001 No PK
id (*,0)
TIME_CREA Cashier’s TIMESTA YYYY- No
TED log-in time MP (2) MM-DD
HH24:MI:S
S
TIME_ENDE Cashier’s TIMESTA YYYY- No
D log-out MP (2) MM-DD
time HH24:MI:S
S
TOTAL_SAL Total sale NUMBER 12345.67 No
ES (7,2)
DATE_CREA Date DATE YYYY- No
TED created MM-DD
EMPLOYEE_ Employee’ VARCHAR ABCD1234 No FK EMPLOY
ID s id 2(8) EE

5.4 Inventory module

Table Name Attribute Contents Data Format Nulla PK Reference

Name Type ble or Table
FK
PRODUCT PRODUCT_I Id for products NUMB 10001 No PK
D ER (*,0)
PRODUCT_E Expiry date of DATE 31/12/2 No
XPIRY products 022
PRODUCT_ Quantity of NUMB 100 No
QUANTITY products on ER (*,0)
hand
PRODUCT_P Selling price of NUMB 90.50 No
RICE products ER (7,2)
PRODUCT_ Name of the VARCH APPET No
NAME products AR2 ON A-Z
(200) VITAM

37
 IN C
30MG
PRODUCT_S Id for status of NUMB 1 No FK PRODUC
TATUS_ID products ER (*,0) T_STAT
US
CATEGORY Id for category NUMB 1 No FK PRODUC
_ID of products ER (*,0) T_CATE
GORY
PRODUCT_ PRODUCT_I Id for products NUMB 10001 No PK, PRODUC
INVOICE D ER (*,0) FK T
INVOICE_ID Id for invoice NUMB 8210 No PK, INVOIC
ER (*,0) FK E
QUANTITY_ Quantity of NUMB 100 No
RESTOCK products have ER (*,0)
been restocked
INVOICE INVOICE_ID Id for invoice NUMB 8210 No PK
ER (*,0)
INVOICE_ Invoice number VARCH IMP- No
NO AR2(10) 123456
INVOICE_ Date on the day DATE 31/12/2 No
DATE which the 022
transaction
made
INVOICE_A Total amount of NUMB 90.50 No
MOUNT products ER (7,2)
purchased
SIGN_DATE Date when DATE 11/11/2 No
employee sign 022
the invoice
SUPPLIER_I Id for supplier NUMB 1 No FK SUPPLIE
D ER (*,0) R
EMPLOYEE_ Id for employee VARCH ABCD1 No FK EMPLO
ID who sign the AR2(8) 234 YEE
invoice
RETURN_P RETURN_ID Id for returning VARCH RP-001 No PK
RODUCT product AR2(8)

38
 RETURN_ Date on the day DATE 31/12/2 No
DATE which returning 022
the products
RETURN_ Reason of VARCH WRON No
REASON returning AR2 G ITEM
products (50)
RETURN_Q Quantity of NUMB 100 No
UANTITY products to be ER (*,0)
returned
INVOICE_ID Id for invoice NUMB 1 No FK INVOIC
ER (*,0) E
PRODUCT_I Id for products NUMB 10001 No FK PRODUC
D to be returned ER (*,0) T
PRODUCT_ PRODUCT_I Id for products NUMB 0001 No PK, PRODUC
SUPPLIER D ER (*,0) FK T
SUPPLIER_I Id for suppliers NUMB 1 No PK, SUPPLIE
D ER (*,0) FK R
SUPPLIER SUPPLIER_I Id for suppliers NUMB 1 No PK
D ER (*,0)
SUPPLIER_N Suppliers’ VARCH SIANG No
AME company name AR2 WAY
(100) SDN
BHD
SUPPLIER_P Suppliers’ NUMB 0114561 No
HONE phone number ER 2984
(11,0)
SUPPLIER_A Suppliers’ VARCH 19, No
DDRESS company AR2 Lorong
address (150) Helang
3,
Taman
Tikus,
11800
Gelugor
,
Penang.

39
 SUPPLIER_E Suppliers' email VARCH siangwa No
MAIL AR2 y@gmai
(50) l.com
PRODUCT_ CATEGORY Id for category NUMB 1 No PK
CATEGOR _ID of products ER (*,0)
Y CATEGORY Type of VARCH Skin No
_TYPE category of AR2 care
products (20)
CATEGORY Description of VARCH Products No
_DESCRIPTI category AR2 that
ON (150) support
skin
integrity
,
enhance
its
appeara
nce and
relieve
skin
conditio
n.
PRODUCT_ PRODUCT_S Id for status of NUMB 1 No PK
STATUS TATUS_ID product ER (*,0)
STATUS_ Description of VARCH EXPIRE No
NAME status of AR2 D
product (20)

40
6.0 Data Implementation

CREATE TABLE “CUSTOMER”

( “CUSTOMER_ID” NUMBER (*,0) NOT NULL

“CUSTOMER_USERNAME” VARCHAR2(20) NOT NULL,

“CUSTOMER_FNAME” VARCHAR2(20) NOT NULL,

“CUSTOMER_LNAME” VARCHAR2(20) NOT NULL,

“CUSTOMER_IC” NUMBER (*,0),

“CUSTOMER_EMAIL” VARCHAR2(30) NOT NULL,

“CUSTOMER_PHONE” NUMBER (11,0),

“CUSTOMER_ADDRESS” VARCHAR2(150),

“CUSTOMER_PASSWORD” VARCHAR2(20) NOT NULL,

CONSTRAINT “CUSTOMER_PK” PRIMARY KEY (“CUSTOMER_ID”),

CONSTRAINT “CUSTOMER_ACC_PK2” PRIMARY KEY (“CUSTOMER_USERNAME”)

CREATE TABLE “PAYMENT_METHOD”

( “PAYMENT_METHOD_ID” NUMBER (1,0) NOT NULL,

“PAYMENT_METHOD_DESCRIPTION” VARCHAR2 (20) NOT NULL,

CONSTRAINT “PAYMENT_METHOD_PK” PRIMARY KEY

(“PAYMENT_METHOD_ID”)

CREATE TABLE “PURCHASE”

( “CUSTOMER_ID” NUMBER (*,0) NOT NULL,

“PICK_UP_TIME” DATE NOT NULL,

“EMPLOYEE_ID” VARCHAR2(8) NOT NULL,

41
 “DISCOUNT_ID” VARCHAR2(20),

“PAYMENT_METHOD_ID” NUMBER (1,0) NOT NULL,

CONSTRAINT “PURCHASE_PK” PRIMARY KEY (“CUSTOMER_ID”),

CONSTRAINT “PURCHASE_FK_1” FOREIGN KEY (“CUSTOMER_ID”) REFERENCES

“CUSTOMER” (“CUSTOMER_ID”),

CONSTRAINT “PURCHASE_FK_2” FOREIGN KEY (“EMPLOYEE_ID”) REFERENCES

“EMPLOYEE” (“EMPLOYEE_ID”),

CONSTRAINT “PURCHASE_FK_3” FOREIGN KEY (“DISCOUNT_ID”) REFERENCES

“MEMBERSHIP_BENEFIT” (“DISCOUNT_ID”),

CONSTRAINT “PURCHASE_FK_4” FOREIGN KEY (“PAYMENT_METHOD_ID”)

REFERENCES “PAYMENT_METHOD” (“PAYMENT_METHOD_ID”)

CREATE TABLE “MEMBERSHIP”

( “MEMBERSHIP_ID” NUMBER (*,0) NOT NULL,

“CUSTOMER_ID” NUMBER (*,0) NOT NULL,

CONSTRAINT “MEMBERSHIP_PK” PRIMARY KEY (“MEMBERSHIP_ID”,

“CUSTOMER_ID”),

CONSTRAINT “MEMBERSHIP_FK” FOREIGN KEY (“CUSTOMER_ID”) REFERENCES

“CUSTOMER” (“CUSTOMER_ID”)

CREATE TABLE “MEMBERSHIP_STATUS”

( “MEMBERSHIP_ID” NUMBER (*,0) NOT NULL,

“DISCOUNT_ID” VARCHAR2(20) NOT NULL,

“STATUS_INFO” VARCHAR2(10) NOT NULL,

CONSTRAINT “MEMBERSHIP_STATUS_PK” PRIMARY KEY (“MEMBERSHIP_ID”,

“DISCOUNT_ID”),

42
 CONSTRAINT “MEMBERSHIP_STATUS_FK_1” FOREIGN KEY (“MEMBERSHIP_ID”)
REFERENCES “MEMBERSHIP” (“MEMBERSHIP_ID”),

CONSTRAINT “MEMBERSHIP_STATUS_FK_2” FOREIGN KEY (“DISCOUNT_ID”)

REFERENCES “MEMBERSHIP_BENEFIT” (“DISCOUNT_ID”)

CREATE TABLE “MEMBERSHIP_BENEFIT”

( “DISCOUNT_ID” VARCHAR2(20) NOT NULL,

“DISCOUNT_DESCRIPTION” VARCHAR2(50) NOT NULL,

CONSTRAINT “MEMBERSHIP_BENEFIT_PK” PRIMARY KEY (“DISCOUNT_ID”)

CREATE TABLE “EMPLOYEE”

( “EMPLOYEE_ID” VARCHAR2(8) NOT NULL ENABLE,

“EMPLOYEE_IC” NUMBER(12) NOT NULL ENABLE,

“EMPLOYEE_FNAME” VARCHAR2(20) NOT NULL ENABLE,

“EMPLOYEE_LNAME” VARCHAR2(20) NOT NULL ENABLE,

“EMPLOYEE_PHONE” NUMBER(11,0) NOT NULL ENABLE,

“EMPLOYEE_ADDRESS” VARCHAR2(150) NOT NULL ENABLE,

“EMPLOYEE_GENDER” CHAR(1) NOT NULL ENABLE,

“EMPLOYEE_EMAIL” VARCHAR2(30) NOT NULL ENABLE,

“EMPLOYEE_START_DATE” DATE NOT NULL ENABLE,

“EMPLOYEE_TYPE” CHAR(1),

“POSITION_ID” NUMBER(4) NOT NULL ENABLE,

CONSTRAINT “EMPLOYEE_PK” PRIMARY KEY (“EMPLOYEE_ID”,

“EMPLOYEE_IC”),

43
 CONSTRAINT “EMPLOYEE_FK” FOREIGN KEY (“POSITION_ID”) REFERENCES
“POSITION” (“POSITION_ID”)

CREATE TABLE “EMPLOYEE__ACC”

( “EMPLOYEE_ID” VARCHAR2(8) NOT NULL ENABLE,

“EMPLOYEE_PASSWORD” VARCHAR2(10) NOT NULL ENABLE,

CONSTRAINT “EMPLOYEE_ACC_PK” PRIMARY KEY (“EMPLOYEE_ID”,

“EMPLOYEE_PASSWORD”)

CONSTRAINT “EMPLOYEE_ACC_FK” FOREIGN KEY (“EMPLOYEE_ID”)

REFERENCES “EMPLOYEE” (“EMPLOYEE_ID”)

CREATE TABLE “POSITION”

( “POSITION_ID” NUMBER (4) NOT NULL ENABLE,

“POSITION_NAME” VARCHAR2(50) NOT NULL ENABLE,

“CHARGE_HOUR” NUMBER(7,2) NOT NULL ENABLE,

CONSTRAINT “EMPLOYEE_POS_PK” PRIMARY KEY (“POSITION_ID”)

CREATE TABLE “SALARY”

( “EMPLOYEE_ID” VARCAHR2(8) NOT NULL ENABLE,

“SALARY_ID” NUMBER(10) NOT NULL ENABLE,

“BASIC_SALARY” NUMBER(7,2) NOT NULL ENABLE,

“EMPLOYEE_BONUS” NUMBER(7,2) NOT NULL ENABLE,

“EMPLOYEE_STATUS” VARCHAR2(9) NOT NULL ENABLE,

“TOTAL_SALARY” NUMBER(7,2) NOT NULL;

44
 CONSTRAINT “SALARY_PK” PRIMARY KEY (“EMPLOYEE_ID”, “SALARY_ID”),

CONSTRAINT “SALARY_FK” FOREIGN KEY (“EMPLOYEE_ID”) REFERENCES

“EMPLOYEE” (“EMPLOYEE_ID”)

CREATE TABLE “PHARMACY_TECHNICIAN”

( “EMPLOYEE_ID” VARCAHR2(8) NOT NULL ENABLE,

“CERT_DESCRIPTION” VARCHAR2(150) NOT NULL ENABLE,

CONSTRAINT “PHARMACY_TECHNICIAN_PK” PRIMARY KEY (“EMPLOYEE_ID”),

CONSTRAINT “PHARMACY_TECHNICIAN_FK” FOREIGN KEY (“EMPLOYEE_ID”)

REFERENCES “EMPLOYEE” (“EMPLOYEE_ID”)

CREATE TABLE “PHAMACIST”

( “EMPLOYEE_ID” VARCHAR2(8) NOT NULL ENABLE,

“LICENCE_TYPE” VARCHAR2(80) NOT NULL ENABLE,

“APC_NO” NUMBER(8,0) NOT NULL ENABLE,

“REGISTRATION_CERT_NO” NUMBER(8,0) NOT NULL ENABLE,

CONSTRAINT “PHARMACIST_PK” PRIMARY KEY (“EMPLOYEE_ID”),

CONSTRAINT “PHARMACIST_FK” FOREIGN KEY (“EMPLOYEE_ID”) REFERENCES

“EMPLOYEE” (“EMPLOYEE_ID”)

CREATE TABLE “MANAGER”

( “EMPLOYEE_ID” VARCHAR2(8) NOT NULL ENABLE,

“ASSIGN_DATE” DATE NOT NULL ENABLE,

CONSTRAINT “MANAGER_PK” PRIMARY KEY (“EMPLOYEE_ID”)

45
 CONSTRAINT “MANAGER_FK” FOREIGN KEY (“EMPLOYEE_ID”) REFERENCES
“EMPLOYEE” (“EMPLOYEE_ID”)

CREATE TABLE “ACCOUNTANT”

( “EMPLOYEE_ID” VARCHAR2(8) NOT NULL ENABLE,

“CERT_DESCRIPTION” VARCHAR2(150) NOT NULL ENABLE,

CONSTRAINT “ACCOUNTANT_PK” PRIMARY KEY (“EMPLOYEE_ID”)

CONSTRAINT “ACCOUNTANT_FK” FOREIGN KEY (“EMPLOYEE_ID”)

REFERENCES “EMPLOYEE” (“EMPLOYEE_ID”)

CREATE TABLE “PRESCRIPTION_HISTORY”

( “EMPLOYEE_ID” VARCHAR2(8) NOT NULL ENABLE,

“CUSTOMER_ID” NUMBER NOT NULL ENABLE,

“PRESCRIPTION_DESCRIPTION” VARCHAR2(500) NOT NULL ENABLE,

“DATE_RECORDED” NUMBER NOT NULL ENABLE,

CONSTRAINT “PRESCRIPTION_HISTORY_PK” PRIMARY KEY (“EMPLOYEE_ID”,

“CUSTOMER_ID”),

CONSTRAINT “PRESCRIPTION_HISTORY_FK1” FOREIGN KEY (“EMPLOYEE_ID”)

REFERENCES “EMPLOYEE” (“EMPLOYEE_ID”),

CONSTRAINT “PRESCRIPTION_HISTORY_FK2” FOREIGN KEY (“CUSTOMER_ID”)

REFERENCES “CUSTOMER” (“CUSTOMER_ID”)

);

CREATE SEQUENCE RECPT_SEQ START WITH 100001 NOCACHE;

CREATE TABLE SALE

46
( RECEIPT_NO NUMBER(10) DEFAULT RECPT_SEQ.NEXTVAL NOT NULL,

CUSTOMER_ID NUMBER(*,0) NOT NULL,

CASHIER_ID NUMBER(10) NOT NULL,

DISCOUNT_ID VARCHAR2(20) NOT NULL,

TIME_CREATED TIMESTAMP(2) NOT NULL,

RECEIPT_AMOUNT NUMBER(7,2) NOT NULL,

AMOUNT_PAID NUMBER(7,2),

CONSTRAINT SALE_PK PRIMARY KEY(RECEIPT_NO),

CONSTRAINT SALE_FK1 FOREIGN KEY (CUSTOMER_ID)

REFERENCES CUSTOMER(CUSTOMER_ID)

);

CREATE SEQUENCE SALE_PRO_SEQ START WITH 101 NOCACHE;

CREATE TABLE SALE_ITEM

( SALE_PRODUCT_ID NUMBER(10) DEFAULT SALE_PRO_SEQ.NEXTVAL NOT NULL,

SALES_QTY NUMBER(*,0) NOT NULL,

UNIT_PRICE NUMBER(7,2) NOT NULL,

SUB_TOTAL NUMBER(7,2) NOT NULL,

PRODUCT_ID NUMBER(*,0) NOT NULL,

RECEIPT_NO NUMBER(10) NOT NULL,

CONSTRAINT SALE_ITEM_PK PRIMARY KEY(SALE_PRODUCT_ID),

CONSTRAINT SALE_ITEM_FK1 FOREIGN KEY(PRODUCT_ID)

REFERENCES PRODUCT(PRODUCT_ID),

CONSTRAINT SALE_ITEM_FK2 FOREIGN KEY(RECEIPT_NO)

REFERENCES SALE(RECEIPT_NO)

);

47
/

CREATE SEQUENCE CASHIER_SEQ START WITH 1 NOCACHE;

CREATE TABLE CASHIER

( CASHIER_ID NUMBER(10) DEFAULT SALE_PRO_SEQ.NEXTVAL NOT NULL,

TIME_CREATED TIMESTAMP(2) NOT NULL,

TIME_ENDED TIMESTAMP(2) NOT NULL,

TOTAL_SALES NUMBER(7,2) NOT NULL,

DATE_CREATED DATE NOT NULL,

EMPLOYEE_ID VARCHAR2(8) NOT NULL,

CONSTRAINT CASHIER_PK PRIMARY KEY(CASHIER_ID),

CONSTRAINT CASHIER_FK FOREIGN KEY(EMPLOYEE_ID)

REFERENCES EMPLOYEE(EMPLOYEE_ID)

);

CREATE TABLE DISCOUNT

( DISCOUNT_ID VARCHAR2(20) NOT NULL,

DISCOUNT_VALUE NUMBER(2) NOT NULL,

DATE_CREATED DATE NOT NULL,

MAX_DISCOUNT_AMOUNT NUMBER(5,2),

PRODUCT_ID NUMBER(*,0) NOT NULL,

MEMBERSHIP_ID NUMBER(*,0) NOT NULL,

CONSTRAINT DISCOUNT_PK PRIMARY KEY(DISCOUNT_ID),

CONSTRAINT DISCOUNT_FK1 FOREIGN KEY(PRODUCT_ID)

REFERENCES PRODUCT(PRODUCT_ID),

CONSTRAINT DISCOUNT_FK2 FOREIGN KEY(MEMBERSHIP_ID)

REFERENCES MEMBERSHIP(MEMBERSHIP_ID)

48
);

CREATE TABLE PAYMENT_DETAILS

( RECEIPT_NO NUMBER(10) NOT NULL,

AMOUNT_PAID NUMBER(7,2) NOT NULL,

CASH NUMBER(1),

PAYMENT_METHOD_ID NUMBER(1,0) NOT NULL,

CONSTRAINT PAY_DETAILS_PK PRIMARY KEY(RECEIPT_NO),

CONSTRAINT PAY_DETAILS_FK FOREIGN KEY(PAYMENT_METHOD_ID)

REFERENCES PAYMENT_METHOD(PAYMENT_METHOD_ID)

);

CREATE TABLE BANKCARD

BANK_ACC_NUMBER VARCHAR2(20) NOT NULL,

CARD_TYPE VARCHAR2(10) NOT NULL,

BANK_ACC_NAME VARCHAR2(50) NOT NULL,

CONSTRAINT BANKCARD_PK PRIMARY KEY(BANK_ACC_NUMBER)

CREATE TABLE EWALLET

EWALLET_TRANSID VARCHAR2(50) NOT NULL,

EWALLET_TYPE VARCHAR2(10) NOT NULL,

CONSTRAINT EWALLET_PK PRIMARY KEY(EWALLET_TRANSID)

);

49
/

CREATE TABLE PRODUCT

PRODUCT_ID NUMBER(*,0) NOT NULL,

PRODUCT_EXPIRY DATE NOT NULL,

PRODUCT_QUANTITY NUMBER(*,0) NOT NULL,

PRODUCT_PRICE NUMBER(7,2) NOT NULL,

PRODUCT_NAME VARCHAR2(100) NOT NULL,

PRODUCT_STATUS_ID NUMBER(*,0) NOT NULL,

CATEGORY_ID NUMBER(*,0) NOT NULL,

CONSTRAINT PRODUCT_PK PRIMARY KEY(PRODUCT_ID),

CONSTRAINT PRODUCT_FK1 FOREIGN KEY(PRODUCT_STATUS_ID)

REFERENCES PRODUCT_STATUS (PRODUCT_STATUS_ID),

CONSTRAINT PRODUCT_FK2 FOREIGN KEY(CATEGORY_ID)

REFERENCES PRODUCT_CATEGORY(CATEGORY_ID)

);

CREATE TABLE PRODUCT_INVOICE

PRODUCT_ID NUMBER(*,0) NOT NULL,

INVOICE_ID NUMBER(*,0) NOT NULL,

QUANTITY_RESTOCK NUMBER(*,0) NOT NULL,

CONSTRAINT PRO_INV_PK PRIMARY KEY(PRODUCT_ID, INVOICE_ID),

CONSTRAINT PRO_INV_FK1 FOREIGN KEY(PRODUCT_ID)

REFERENCES PRODUCT(PRODUCT_ID),

CONSTRAINT PRO_INV_FK2 FOREIGN KEY(INVOICE_ID)

50
REFERENCES INVOICE(INVOICE_ID)

);

CREATE TABLE INVOICE

INVOICE_ID NUMBER(*,0) NOT NULL,

INVOICE_NO NUMBER(*,0) NOT NULL,

INVOICE_DATE DATE NOT NULL,

INVOICE_AMOUNT NUMBER(7,2) NOT NULL,

SIGN_DATE DATE,

SUPPLIER_ID NUMBER(*,0) NOT NULL,

EMPLOYEE_ID VARCHAR2(8),

CONSTRAINT INVOICE_PK PRIMARY KEY(INVOICE_ID),

CONSTRAINT INVOICE_FK FOREIGN KEY(SUPPLIER_ID)

REFERENCES SUPPLIER(SUPPLIER_ID),

CONSTRAINT INVOICE_FK2 FOREIGN KEY (EMPLOYEE_ID)

REFERENCES EMPLOYEE(EMPLOYEE_ID)

);

CREATE TABLE RETURN_PRODUCT

RETURN_ID VARCHAR2(8) NOT NULL,

RETURN_DATE DATE NOT NULL,

RETURN_REASON VARCHAR2(50) NOT NULL,

RETURN_QUANTITY NUMBER(*,0) NOT NULL,

INVOICE_ID NUMBER(*,0) NOT NULL,

51
PRODUCT_ID NUMBER(*,0) NOT NULL,

CONSTRAINT RETURN_PRODUCT_PK PRIMARY KEY(RETURN_ID),

CONSTRAINT RETURN_PRODUCT_FK1 FOREIGN KEY(INVOICE_ID)

REFERENCES INVOICE (INVOICE_ID),

CONSTRAINT RETURN_PRODUCT_FK2 FOREIGN KEY(PRODUCT_ID)

REFERENCES PRODUCT(PRODUCT_ID)

);

CREATE TABLE PRODUCT_SUPPLIER

PRODUCT_ID NUMBER(*,0) NOT NULL,

SUPPLIER_ID NUMBER(*,0) NOT NULL,

QUANTITY_SUPPLIED NUMBER(*,0) NOT NULL,

CONSTRAINT PRO_SUP_PK PRIMARY KEY(PRODUCT_ID, SUPPLIER_ID),

CONSTRAINT PRO_SUP_FK1 FOREIGN KEY(PRODUCT_ID)

REFERENCES PRODUCT(PRODUCT_ID),

CONSTRAINT PRO_SUP_FK2 FOREIGN KEY(SUPPLIER_ID)

REFERENCES SUPPLIER(SUPPLIER_ID)

);

CREATE TABLE SUPPLIER

SUPPLIER_ID NUMBER(*,0) NOT NULL,

SUPPLIER_NAME VARCHAR2(100) NOT NULL,

SUPPLIER_PHONE NUMBER(11,0) NOT NULL,

SUPPLIER_ADDRESS VARCHAR2(150) NOT NULL,

52
SUPPLIER_EMAIL VARCHAR2(50) NOT NULL,

CONSTRAINT SUPPLIER_PK PRIMARY KEY(SUPPLIER_ID)

);

CREATE TABLE PRODUCT_CATEGORY

CATEGORY_ID NUMBER(*,0) NOT NULL,

CATEGORY_TYPE VARCHAR2(20) NOT NULL,

CATEGORY_DESCRIPTION VARCHAR2(150) NOT NULL,

CONSTRAINT PRO_CATEGORY_PK PRIMARY KEY (CATEGORY_ID)

);

CREATE TABLE PRODUCT_STATUS

PRODUCT_STATUS_ID NUMBER(*,0) NOT NULL,

STATUS_NAME VARCHAR2(20) NOT NULL,

CONSTRAINT PRODUCT_STATUS_PK PRIMARY KEY(PRODUCT_STATUS_ID)

);

CREATE OR REPLACE FUNCTION AUTHENTICATE_USER_LOGIN

(P_USERNAME IN VARCHAR2,

P_PASSWORD IN VARCHAR2)

RETURN BOOLEAN

IS

L_USERNAME VARCHAR2(30) := UPPER(P_USERNAME);

L_PASSWORD VARCHAR2(20) := P_PASSWORD;

53
 L_COUNT NUMBER;

BEGIN

-- CHECK TO SEE IF THE USER EXISTS

SELECT COUNT(*) INTO L_COUNT FROM CUSTOMER WHERE CUSTOMER_USERNAME

= L_USERNAME AND CUSTOMER_PASSWORD = L_PASSWORD;

IF L_COUNT = 0 THEN

RETURN TRUE;

ELSE

RETURN TRUE;

END IF;

EXCEPTION

WHEN OTHERS THEN

RETURN FALSE;

END AUTHENTICATE_USER_LOGIN;

CREATE OR REPLACE EDITIONABLE TRIGGER "PROMPT_CUSTOMERID"

BEFORE INSERT ON CUSTOMER
for each row
BEGIN
SELECT CUSTOMER_SEQ2.nextval INTO :new.CUSTOMER_ID FROM dual;
END;
/
ALTER TRIGGER “PROMPT_CUSTOMERID" ENABLE
/

CREATE OR REPLACE EDITIONABLE TRIGGER "PROMPT_PRODUCT_ID"

BEFORE INSERT ON PRODUCT
for each row
BEGIN
SELECT PRODUCT_ID_SEQ.nextval INTO :new.PRODUCT_ID FROM dual;
END;

54
/
ALTER TRIGGER "PROMPT_PRODUCT_ID" ENABLE
/
CREATE OR REPLACE EDITIONABLE TRIGGER "PROMPT_SALARY_ID"
BEFORE INSERT ON SALARY
for each row
BEGIN
SELECT SALARY_ID.nextval INTO :new.SALARY_ID FROM dual;
END;
/
ALTER TRIGGER "PROMPT_SALARY_ID" ENABLE
/
CREATE OR REPLACE EDITIONABLE TRIGGER "PROMPT_SUPPLIER_ID"
BEFORE INSERT ON SUPPLIER
for each row
BEGIN
SELECT SUPPLIER_ID_SEQ.nextval INTO :new.SUPPLIER_ID FROM dual;
END;
/
ALTER TRIGGER "PROMPT_SUPPLIER_ID" ENABLE
/

CREATE OR REPLACE EDITIONABLE TRIGGER "PROMPT_SALES_PROD_ID"

BEFORE INSERT ON SALE_ITEM
for each row
declare sale_product_id NUMBER;
BEGIN
if :new.sale_product_id is null then
select SALE_PRO_SEQ.nextval
into sale_product_id
from dual;
:new.sale_product_id := sale_product_id;
end if;
END;
/

ALTER TRIGGER "PROMPT_SALES_PROD_ID" ENABLE

/

55
7.0 Front-End System Design and Implementation

Figure 1: Login Page

The figure above is the login page of our i-Med Retail Pharmacy Database. Users are required to click
on sign in as existing customer or either owner with their usernames and password. Username and
password are case-sensitive.

Figure 2: Sign Up Page

The figure above is the sign up page for new users to sign in with.

56
Figure 3: Home Page & Edit information

The figure above is the home page which have the user’s username displayed at the top right corner.
Besides that, the user’s profile is also displayed on the home page.

Figure 4: Navigation Menu in customer’s view

Figure 5: Navigation Menu in owner’s view

57
Figure 6: Edit Information

Figure 7: Edit Information (continued)

After clicking the ‘Edit’ icon, it will lead user to a ‘Edit information’ page. User’s information had
divided into several rows which is Customer’ username, password, fname, lname and many more.

Figure 8: Product catalog

58
Figure 9: Product catalog -Add to cart (Step 1)

By clicking the ‘add to cart’ button, the figure below will appear.

Figure 10: Checkout page (Step 2)

After choosing the product quantity, click the ‘CREATE’ button and it will lead user to the pick-up
page.

59
Figure 11: Pick-up page (Step 3)

The user will be prompt to pick their desire pick-up date, discount and payment method to create their
order. Employee will based on the pick-up date that user has chosen to prepared the customer’s order
for pick-up.

Figure 12: Order History

After the user has created their order, the user can refer to the order history page on the order that they
had just made and the ones made previously.

60
8.0 Project Problems and Pitfalls

We use Oracle Application Express (APEX) for structuring the user interface for our database.
Throughout the process, we did face a lot of problems which was quite a challenge as all of us minor
students are new to this application. APEX which uses SQL language that is a totally new programming
language that all of us just started to learn. Fortunately, we had an amazing tutor that taught us on how
to us ORACLE APEX during our lab sessions for several times. However, lacking in experience to use
ORACLE APEX really did make us doubt from time to time on what we are really trying to convey in
our application. ORACLE APEX do always update to different versions throughout the years which is
a big problem to us as information on using ORACLE APEX post by bloggers are of earlier versions.
This has resulted us to do lots of research just to understand how the newest version of ORACLE APEX
works.

Besides that, implementation of the user interface using ORACLE APEX was done after we
completed all of the ERD diagram. This has posted some minor adjustment on all of our ERD as some
of the attributed on particular entity was not needed for implementation. Therefore, the entire
implementation process was really time-consuming, not alone in just doing research but also modifying
our ERD which matches that of what we use for the implementation of user interface.

9.0 Conclusion/ Recommendations/Future Work

Conclusion

In conclusion, it can be said that it is difficult to construct a good database system. Making a
database system requires a lot of effort and expertise. We have created a retail pharmacy system which
enable both owner and customers of the pharmacy too obtain information and edit them based on
relevancy. Customers can also sign in to the application to browse through the products in stores and
add their desire products in cart. After that, customer can choose their pick-up date so that employee
can make arrangement for the customer order on that chosen date. Database also stores a relatively large
amount of data using various tables, relationships between tables and constraints of each table. Frankly
speaking, owner can manage the database easily and more efficient with decrease in data consistency
as data sharing between users have been make more smoother throughout this project. Additionally,
reports are created for users to aid in their decision-making.

This endeavor has taught us a lot of new information. As an illustration, we have developed our
database system using SQL Database that we have just learned in early of April in order to complete
our project’s main objective. We learn on how to create ERD when working on our project, we can also
differentiate and identify any strong or weak relationships between entity in different modules. Besides
that, we can also perform normalization for ERD. In the midst of all of the challenges we have faced,

61
we are still able to overcome them thanks to the cooperation and support of every team member on
board. We are able to work properly with each other and also assist each other when any of us face
difficulties. With this project, we can put our skills that we have learnt throughout this course to the test.

Future Works

We will work harder in the future to provide a better database system which show
professionalism for every user. The database system that we have came out as a team only can handle
the essential tasks. With that saying, we strongly think that our database system still has lots of
improvements to be made. We will also create a more appealing Graphical User Interface to improve
the system’s usefulness. We would also like to design a better login and sign-up process so that the
security of our database system can be improve. Moreover, increase in product variety and better check-
out procedure are also a better idea.

10.0 References

1. Coronel, C., and Morris S., Database Systems: Design, Implementation and Management, 13th ed.
(International or Asia Edition), Course Technology, Cengage Learning, 2018.

2. https://blogs.oracle.com/apex/post/custom-authentication-and-authorization-using-built-in-apex-
access-control-a-how-to

3. https://stackoverflow.com/

Group Project: Oracle Credentials

Oracle APEX Cloud

Workspace: Project_grp22
Username: darrentanwh00@student.usm.my
Password: projectgroup22usm

62