Download as pdf or txt
Download as pdf or txt
You are on page 1of 56

PROJECT

Relational Database Design 1.1


INSTRUCTOR NOTES

The following are the inputs for the faculty for project allocation and evaluation:
 The project should be allocated to individual students by the end of the third
cycle.
 The student can start the project earliest after the first Experiment session of
Relational Database Design is over.
 During allocation, explain the students the scope of the project by referring to
the topic Project Activities and Project Timelines.
 Ask the students to refer to the sample case study and its solution given in the
sample project documentation.
 Ask the students to refer to the topic Project Standards and Guidelines before
starting the project documentation.
 Before project evaluation day, ask the students to verify their projects according
to the standards and guidelines given in the topic Project Standards and
Guidelines.
 Evaluate the students according to the guidelines given in the topic Project
Evaluation Guidelines.

1.2 Relational Database Design


CASE STUDY 1: SHOP HERE

Background
Shop Here is a leading departmental store in New York. The store is known for quality
products, affordable price range, timely services, and home delivery facility. The store
has customers from all sections of the society and procures goods from various
countries.

Existing System
Shop Here maintains an optimum inventory of various categories of items. The details
of the various categories are stored in the Categories file. This file contains data about
the item category numbers and the corresponding categories. The details of the items
are stored in a file named Items. The Items file contains records such as item number,
item description, item category number, serial number of the item, unit price of each
item, and reorder level of each item.
The store has several regular suppliers for the various items. The suppliers are spread
over various geographical locations. A detailed record is maintained for each supplier.
The supplier record consists of supplier code, supplier’s name, address, phone
number, country of origin, and shipment mode number and shipment mode for
outstation suppliers. All records are maintained in the Suppliers file.
Whenever the employee of a store places a purchase order, a purchase order form
needs to be filled out. The format of a purchase order form is shown in the following
figure.

PURCHASE ORDER FORM

Purchase Order ID: Supplier ID:

Employee ID: Order Date:

Shipment Date: Quantity:

Shipment Method ID: Freight Charge:


Purchase Order Form
A complete transaction takes place when the purchase is made and the payment is
done.

Relational Database Design 1.3


Envisioned System
Shop Here requires a computerized system that provides an effective method of
storing transaction details. The inventory-in-charge, Chris Symonds, realizes that with
growth in business, it becomes difficult to manually maintain the inventory. Shop Here
also wants to include the information about employees who place purchase orders with
the suppliers. Therefore, the management of the store has decided to computerize the
inventory management of the store. To fulfill this need, the store management has
contacted RedSky IT Systems to develop the computerized system. Don Allen, a
project manager at RedSky IT Systems, has been deputed to manage the assignment.
Don and his project team need to perform the following tasks:
1. Identify the various entities involved.
2. Identify the attributes that completely define the entities.
3. Draw an E/R diagram to demonstrate the relationship between the various
entities.
4. Map the E/R diagram to the tables.
5. Normalize the tables to 3 NF.
6. Identify the primary and foreign keys in the tables.
7. Draw a diagram to show the relationships between the various tables.

1.4 Relational Database Design


CASE STUDY 2: SHOWMAN HOUSE

Background
Showman House is a large event management company of New York. The company
organizes various types of events throughout the year. The events types include
fashion shows, celebrity shows, chat shows, musical extravaganza, exhibitions, fairs,
and charity shows.

Existing System
Showman House organizes events of different types. The details of the various event
types are stored in the Event Types file. This file contains data about the event type
codes and the corresponding event types. Customers who wish to organize an event
need to provide details about the nature of the event they want to organize. Along
with providing event details, they also make the payment for the event. The payment
for an event is made in instalments, according to the fee plan, which is stored in the
Fee Schedules file. The Fee Schedules file maintains details such as fee schedule id,
event id, fee description, and fee amount. An attendee needs to pay all the
instalments of the payment, on or before the start date of the event.
All details related to an event such as event code, event name, event type code,
location of the event, start date, end date, event description, number of people, and
the staffing required for the event are stored in the Events file. The payment details
that include payment amount, payment date, payment method id, and payment
method description are also stored in the Events file. The details of an attendee such
as attendee id, attendee name, and address are stored in the Attendees file.
Each event at Showman House is managed by an employee. The employee details
such as employee id, first name, last name, title, and phone are stored in the
Employees file.

Envisioned System
The management of Showman House have realized that it is difficult to maintain so
much data manually. Therefore, they have decided to computerize the entire system
of event management.

Relational Database Design 1.5


Blue Moon Computers have been assigned the task to computerize the system. The
project team needs to perform the following tasks:
1. Identify the various entities involved.
2. Identify the attributes that completely define the entities.
3. Draw an E/R diagram to demonstrate the relationship between the various
entities.
4. Map the E/R diagram to the tables.
5. Normalize the tables to 3 NF.
6. Identify the primary and foreign keys in the tables.
7. Draw a diagram to show the relationships between the various tables.

1.6 Relational Database Design


CASE STUDY 3: NEW PROJECT LTD.

Background
New Project Ltd. is a company that provides staff on contract for various project
assignments. The company is known for providing qualified and skilled staff that can
fulfill the project requirements efficiently. New Project employs professionals from
various fields that match the requirement of clients.

Existing System
New Project has a system of time cards. Time cards are issued to its employees for
working at the client site until the completion of the project. The employees use their
time cards for all work processes and expenses during the contract period. The time
card data enables New Project to prepare the final billing that needs to be submitted
to the clients for release of payment in lieu of work.

Relational Database Design 1.7


When a work agreement is signed, a project form needs to be filled out. The format of
this form is shown in the following figure.

A. PROJECT FORM

CLIENT SECTION

Client code: Company Name:

Address: Country:

Contact Person: Phone:

PROJECT SECTION

Project code: Project Name:

Project Description: Estimate Bill:

Start Date: End Date:

EMPLOYEE SECTION

Employee code: Employee Name:

Address: Country:

Work Phone: Billing Rate:

Project Form

1.8 Relational Database Design


The client details are stored in the Clients file, the project details are stored in the
Projects file, and the employee details are stored in the Employees file. The next form
that needs to be filled out is the Time Card Details form. The format of the form is
shown in the following figure.

TIME CARD DETAILS

Time Card code: Employee code:

EXPENSES DETAILS

Time Card Expense code: Expense Description:

Expense code ID: Expense code:

Expense Date: Expense amount:

WORK DETAILS

Work code ID: Work code:

Work Description: Work date:

Project code:

BILL SECTION

Billed Hours: Billing Rate:

Time Card Details


All employees fill the time card details on a daily basis. These details include Time
Card ID, Employee ID, Date Issued, Date Worked, Project ID, Work Description,
Billable Hours, and Work Code ID. The staffing-in-charge of New Project stores these
details in the Time Cards file. The work code ID defines the category of the task
performed by the employee in the project. The details related to the work codes are
stored in the Work Codes file, which includes details such as work code id and work
code description.
During the project life cycle, employees might also incur expenses due to conveyance
and food. The details of the expenses incurred by an employee in a project are stored
in the Time Card Expenses file. These details include time card expense id, time card
id, expense date, expense amount, expense description, project id, expense code id,
and expense code. After every project, the company calculates its payment due from
the client and raises an invoice. On realization of the payment, all related data is
stored in the Payments file. This file contains data about payment code, payment

Relational Database Design 1.9


mode ID, payment mode name, corresponding project code, payment amount,
payment date, and credit card details if the client pays through credit card. Credit card
details consist of card number, cardholder’s name, and expiry date of the credit card.

Envisioned System
The management decided that manually maintaining such records was a cumbersome
process. It also gave rise to data redundancy and record duplication. Therefore, to
streamline the entire process, the best solution was to create databases and convert
the manual process to a computerized process.
An in-house development team has been created to work on the project of
computerizing the staffing process of New Project Ltd. The development team has the
following tasks to perform:
1. Identify the various entities involved.
2. Identify the attributes that completely define the entities.
3. Draw an E/R diagram to demonstrate the relationship between the various
entities.
4. Map the E/R diagram to the tables.
5. Normalize the tables to 3 NF.
6. Identify the primary and foreign keys in the tables.
7. Draw a diagram to show the relationships between the various tables.

1.10 Relational Database Design


CASE STUDY 4: NEWHOPE HOSPITAL

Background
NewHope Hospital is a famous name in the United States in the field of medical
sciences. The hospital has a dedicated team of doctors and researchers who are
continuously working to build a better and healthy society. Today, NewHope has a
capacity of 1,500 beds and its Out Patient Department (OPD) can handle nearly 100
patients in a day.

Existing System
Every year, several thousands of patients are treated at NewHope. The hospital
maintains a record of each patient in the Patient Details register. The record of a
patient includes the name and address of the patient, nature of treatment done, and
name of the doctor who treated the patient. The medical history of each patient is
maintained in Medical History register by the NewHope staff. The medical history of
the patients is maintained for future reference for similar cases or if the same patient
is re-admitted. The medical history record of a patient is filed according to the ward
where the patient was admitted last. Information related to the various wards is
recorded in the Ward Details register. The various wards at NewHope hospital are:
 Out Patient Department (OPD)
 Intensive Care Unit (ICU)
 Cardiac Care Unit (CCU)
 Special Wards
 General Wards
 Emergency Unit
The details recorded in the Ward Details register also include the number of rooms
and beds in each ward and their availability status.
The Hospital also maintains a record of all the doctors (resident/visiting) in the Doctor
Details register. The register is used to store details about doctors such as the doctor’s
name, the ID number, the contact number, the employment type (resident/visiting),
the area of specialization, the ward assigned.
The medical history records also show the movement of a patient from one ward to
another. For instance, a patient who was first admitted to the ICU is shifted to the
general ward after the recommendation of a specified doctor. In addition, the medical

Relational Database Design 1.11


history record contains information related to the medical prescription sheet and other
tests conducted on the patient.
The format of the medical history record is shown in the following figure.

NewHope Hospital

Medical History Record

Patient Name & Address:

Relative Name & Address:

(Name of Father/Mother in case of Minor)

Age: Blood Group: Height: Weight:

Date When Patient was Admitted:

Nature of Disease:

Current Ward:

Ward to Which Patient was Admitted:

Doctor’s Name:

Document’s Enclosed:

Doctor’s Signature: Patient/Relative Signature:

Medical History Record

1.12 Relational Database Design


Before a patient is shifted to a ward, the staff members check the availability of beds
in the given ward. The availability status of rooms is checked from the Ward Details
register.

Envisioned System
With the increase in the number of records of patients, it has become difficult for the
staff at NewHope to maintain the details of all the patients. At times, the large volume
of patient information results in a delay in updating the patient records. Therefore, the
management of NewHope has decided to computerize the process of maintaining the
patient records.
The NewHope management has contacted RedSky Systems to develop a computerized
system. RedSky Systems has deputed Project Manager James Morrison to manage this
assignment. James and his team need to perform the following tasks:
1. Identify the various entities involved.
2. Identify the attributes that completely define the entities.
3. Draw an E/R diagram to demonstrate the relationship between the various
entities.
4. Map the E/R diagram to the tables.
5. Normalize the tables to 3 NF.
6. Identify the primary and foreign keys in the tables.
7. Draw a diagram to show the relationships between the various tables.

Relational Database Design 1.13


CASE STUDY 5: FIT-N-FINE HEALTH CLUB

Background
Fit-n-Fine Health Club is a recreational club that provides various fitness- and health-
related services to its members. The club has many branches in the city. All Fit-n-Fine
branches have a top-quality gymnasium and health facilities for its members. In
addition, the club provides premium services such as sauna/steam baths, yoga
classes, aerobic classes, and a Olympic-size swimming pool facility. All the branches
employ well-qualified instructors/coaches for the various services provided. This has
resulted in an exponential increase in the number of registered members.

Existing System
The club’s Customer Relations (CR) department serves as a liaison between the club
and its members. The main responsibility of this department is to enhance the image
of Fit-n-Fine, provide various details about the club to the prospective as well as
existing members, perform the registration process for the new members, and
monitor the feedback given by the members about the facilities and services of the
club. The details about the employees of the CR staff are maintained in a Staff Details
register.
Presently, the CR staff maintains a Membership Details register. It contains an
enumeration of the various plans offered (Premium/Standard/Guest), the
corresponding plan IDs, and the fee for each plan. A Plan Details register is also
maintained by the staff. This register contains a list of all the facilities included in each
plan. Whenever someone visits the front office of the health club and makes an
enquiry about the plans offered, the attending officer on duty refers to the
Plan Details register to inform the visitor about the club’s services.
The details of the registered members are recorded by the staff in the Member Details
register. These details include the member’s ID, the name, the subscribed plan, the
contact number, and the contact address.
Whenever a member wishes to visit the club to use a facility, he or she needs to book
the facility in advance by providing information such as the desired day and the time.
On receiving such a request from a member, the staff refers to the Booking Details
register to check the booking status of the desired facility. In case the facility is
already booked to capacity for the same day and time slot, the new request is
rejected. On the other hand, if the number of persons requesting the use of the facility
on the desired day and time has not reached the specified capacity, the new request is
accepted and the booking status is updated. The status is marked as booked after the
maximum number allowed is reached.

1.14 Relational Database Design


The club members provide regular feedback about the services provided by the club.
These comments are accepted by the CR personnel and recorded in the Feedback
Register. The entries are made depending on the type of feedback. The entries include
information such as the reference number, the member name, the member ID, the
feedback details, and the type of feedback. The type of feedback can be:
 Complaints - C
 Suggestions - S
 Appreciations – A

Envisioned System
Fit-n-Fine Health Club requires a computerized system that provides an effective
method of storing all such details. The manager of the Customer Relations
Department, Jim Morris, realizes that it is becoming increasingly difficult to manually
maintain the various registers. Fit-n-Fine also wants to include the information about
employees who interact with the members while recording their feedback. Therefore,
the management of the club has decided to computerize all the processes. To fulfill
this need, the club management has contacted IT4Enterprises, Inc. to develop the
computerized system. Tony Cage, a project manager working with IT4Enterprises Inc.,
has been asked to manage this assignment. Tony and his team need to perform the
following tasks:
1. Identify the various entities involved.
2. Identify the attributes that completely define the entities.
3. Draw an E/R diagram to demonstrate the relationship between the various
entities.
4. Map the E/R diagram to the tables.
5. Normalize the tables to 3 NF.
6. Identify the primary and foreign keys in the tables.
7. Draw a diagram to show the relationships between the various tables.

Relational Database Design 1.15


PROJECT EXECUTION
This book contains five case studies. These case studies will be allocated to individual
students.

Phases in Project Execution


The project will be carried out in the following phases:
 System Analysis: System analysis refers to an in-depth study of the existing
system to depict the functionality of the system. The analysis phase is the most
crucial phase in a project because it helps developers to identify the processes in
the system and the functioning of each process. The project teams will analyze
their respective case studies before moving on to the development phase.
 Design: This phase involves designing the database structure based on the
specifications.
 Documentation: The project documentation should be submitted to the
coordinator in the formats given in this book before the project evaluation. The
blank report following the case studies is to be filled up, detached from the
book, and submitted on the given date.

Project Evaluation Guidelines


The project is to be evaluated based on the following parameters:
 Quality: Refers to the following requirements: – 20 Marks

The solution maps to the requirements specified along with the case study.
 Timeliness: Refers to timely implementation of the project. – 20 Marks
 Quality of documentation: Refers to the following requirements: – 40 Marks

Completion of all the formats


Accuracy of design
Adherence to standards and processes
 Query handling: Refers to the handling of queries during project
walkthrough. – 20 Marks

1.16 Relational Database Design


Project Standards and Guidelines
The following standards and guidelines should be followed while creating the project.
Following these standards and guidelines is one of the evaluation criteria for the
project:
 The E/R diagram should be simple to understand.
 A consistent naming convention should be used for tables.
 Fields in a table should not have a “.” character.

Project Activities
The students will get 6 hours to complete the project. The activities to be performed
during this period are:
1. Analyze the case study to identify the system processes.
2. Identify the entities.
3. Identify the attributes of the entities.
4. Draw the E/R diagram.
5. Map the E/R diagram to tables.
6. Normalize the tables to 3 NF.
7. Identify the primary keys and foreign keys.
8. Document the project by using the formats given in the later section.
9. Submit the documentation to the faculty.
After submitting the documentation, the faculty will query the student based on the
RDBMS concepts and the design created in the documentation. The faculty will assign
marks to the student based on the evaluation criteria specified in Project Evaluation
Guidelines section.

Relational Database Design 1.17


Project Timelines
The tasks listed in the following table should be completed in the specified sessions.

Session # Tasks to be Performed

1  Analyze the case study to identify the system


processes
 Identify the entities
 Identify the attributes of the entities

2  Draw the E/R diagram


 Map the E/R diagram to tables

3  Normalize the tables to 3 NF


 Identify the primary keys and foreign keys
 Document the project

Tasks to be Performed

1.18 Relational Database Design


SAMPLE CASE STUDY: PAY JUNCTION

Background
Pay Junction is a company that performs order processing and manages payment
realizations for other organizations.

Existing System
Pay junction maintains separate files for storing customer details and order details.
The Customer Details file consists of records such as customer code, customer name,
company name, address, country, phone number, and billing address.
When an order is processed, various parameters that affect the order are filled in a
form and then analyzed. The format of the Order Processing form is shown in the
following figure.

ORDER PROCESSING

Order code: Order Details code:

Customer code: Order Date:

Product code: Product Name:

Quantity: Unit Price:

Discount:

SHIPMENT DETAILS

Shipment Name: Shipping Address:

Shipping Country: Contact Phone:

Shipping Date: Shipping Mode ID:

Shipping Mode: Freight Charges:

Tax:
Order Processing Form
Total Value:

Relational Database Design 1.19


The data related to the order and shipment is transferred from the Order Processing
form to the Orders file. The data related to the products ordered is stored in the
Products file.
The payments for orders are accepted through cash or credit card. When the customer
makes the payment, the Payments file is updated with the data about payment code,
order code, payment amount, payment date, payment mode ID, payment mode, and
credit card details if the customer pays through a credit card. The credit card details
consist of card number, cardholder’s name, and card expiry date.

Envisioned System
Pay Junction has decided to stop manual data storage and start computerized
database management and order processing. This would also enable the company to
have quicker communication with the clients.
A small group of database designers have been deployed by Pay Junction to develop a
computerized system of order processing and database management. Pay Junction
also wants to include the information about an employee who processes an order. This
information will include the employee code, name, title, and phone number.
The development team needs to perform the following activities:
1. Identify the various entities involved.
2. Identify the attributes that completely define the entities.
3. Draw an E/R diagram to demonstrate the relationship between the various
entities.
4. Map the E/R diagram to the tables.
5. Normalize the tables to 3 NF.
6. Identify the primary and foreign keys in the tables.
7. Draw a diagram to show the relationships between the various tables.

1.20 Relational Database Design


SAMPLE PROJECT DOCUMENTATION: PAY
JUNCTION

PROJECT ON
Pay Junction

Developed by

Name: Debbie Howe

Reg. No.: 4701-10-258

Relational Database Design 1.21


Pay Junction
(Project Title)

Batch Code :
Start Date : June 1, 2007 End Date: June 10, 2007
Name of the Coordinator : Alex Norton
Name of Developer : Debbie Howe

Date of Submission : June 11, 2007

1.22 Relational Database Design


CERTIFICATE

This is to certify that this report titled Pay Junction embodies the
original work done by Debbie Howe in partial fulfillment of their course
requirement at NIIT.

Coordinator:
Alex Norton

Relational Database Design 1.23


ACKNOWLEDGEMENT

We have benefited a lot from the feedback and suggestions given to


us by Mr. Alex Norton and other faculty members.

1.24 Relational Database Design


SYSTEM ANALYSIS

System Summary: Pay Junction is a company that has been taken


up by a leading leather accessories manufacturer for order processing
and managing payment realizations. Pay Junction maintains separate
files for storing customer details and order details. When an order is
processed, various parameters that affect the order are filled in a form
and then analyzed. The payments for orders are accepted through
cash or credit card.

Relational Database Design 1.25


ENTITIES

Number of entities: 5
Names of entities:
1. Customers
2. Orders
3. Products
4. Payments
5. Employees

1.26 Relational Database Design


ATTRIBUTES
Attributes:
The various entities and their attributes are listed in the following table.

Entity Attributes
Customers Cust-Code
First Name
Last Name
Address
Country
Zip Code
Phone No
Orders Order-Code
Cust-Code
Prod-Code
Emp-Code
Order-Dt
Ship Name
Ship Address
Ship Country
Ship Phone
Ship-Dt
Ship Method Id
Ship Method
Freight Charge
Sales Tax
Quantity
Discount
Total Cost
Products Prod-Code
Prod-Name
Description
Unit Price
Payments Payment-Code
Order-Code
Payment Amount
Payment-Dt
Payment Mode Id
Payment Mode
CreditCard No
Cardholders Name
CreditCardExpiry-Dt

Relational Database Design 1.27


Entity Attributes
Employees Emp-Code
First Name
Last Name
Title
Phone No

1.28 Relational Database Design


E/R DIAGRAM

SHIP SHIP SHIP-


ADDRESS PHONE DT SHIP
METHOD

SHIP
SHIP COUNTRY
SHIP
NAME
METHOD
ID

ORDER- SALES
DT TAX
ZIP CODE FREIGHT
EMP-
COUNTRY CHARGE
CODE
PHONE NO
ADDRESS QUANTITY

LAST NAME
DISCOUNT
CUST-
FIRST NAME CODE
TOTAL COST

CUST-CODE ORDER-
CODE

1 m m m
CUSTOMERS PLACES ORDERS FOR PRODUCTS
1
m 1
UNIT PRICE

MAKES PROCESSES FOR


DESCRIPTION PROD-CODE
1 1
EMP- m
CODE EMPLOYEES PAYMENTS PROD-NAME

FIRST
NAME
PAYMENT-CODE
LAST PHONE NO
NAME TITLE
ORDER-
CODE
CREDITCARDEXPIRY-
DT PAYMENT
AMOUNT
CARDHOLDERS NAME
PAYMENT-DT
CREDITCARD NO
PAYMENT MODE ID
PAYMENT MODE

Relational Database Design 1.29


TABLES
Number of Tables: 6
Structure of Tables: The table structures are shown here.
Customers [Entity] Orders [Entity] Order Details [Relationship]

Customers Orders Order Details

Cust-Code Order-Code OrderDetail-ID

First-Name Cust-Code Order-Code

Last-Name Emp-Code Prod-Code

Address Order-Dt Quantity

Country Ship-Name Discount

Zip-Code Ship-Address Total-Cost

Phone-No Ship-Country

Ship-Phone

Ship-Dt

Ship-Method-ID

Ship-Method

Freight-Charge

Sales-Tax

1.30 Relational Database Design


Products [Entity] Payments [Entity] Employees [Entity]

Products Payments Employees

Prod-Code Payment- Code Emp-Code

Prod-Name Order-Code First-Name

Description Payment-Amount Last-Name

Unit-Price Payment-Dt Title

Payment-Mode- ID Phone-No

Payment-Mode

Credit Card-No

Card Holders-Name

CreditCardExpiry-Dt

The Order Details table is formed because of a many-to-many relationship between


the Orders and Products entities.

Relational Database Design 1.31


TABLES AFTER 1 NF
The tables are already in 1 NF. The table structures are shown here.
Customers Orders Order Details

Customers Orders Order Details

Cust-Code Order-Code OrderDetail-ID

First-Name Cust-Code Order-Code

Last-Name Emp-Code Prod-Code

Address Order-Dt Quantity

Country Ship-Name Discount

Zip-Code Ship-Address Total-Cost

Phone-No Ship-Country

Ship-Phone

Ship-Dt

Ship-Method-ID

Ship-Method

Freight-Charge

Sales-Tax

1.32 Relational Database Design


Products Payments Employees

Products Payments Employees

Prod-Code Payment- Code Emp-Code

Prod-Name Order-Code First-Name

Description Payment-Amount Last-Name

Unit-Price Payment-Dt Title

Payment-Mode- ID Phone-No

Payment-Mode

Credit Card-No

Card Holders-Name

CreditCardExpiry-Dt

Relational Database Design 1.33


TABLES AFTER 2 NF
The tables are already in 2 NF as the attributes in each table depend on the primary
key. The table structures are shown here.

Customers Orders Order Details

Customers Orders Order Details

Cust-Code Order-Code OrderDetail-ID

First-Name Cust-Code Order-Code

Last-Name Emp-Code Prod-Code

Address Order-Dt Quantity

Country Ship-Name Discount

Zip-Code Ship-Address Total-Cost

Phone-No Ship-Country

Ship-Phone

Ship-Dt

Ship-Method-ID

Ship-Method

Freight-Charge

Sales-Tax

1.34 Relational Database Design


Products Payments Employees

Products Payments Employees

Prod-Code Payment- Code Emp-Code

Prod-Name Order-Code First-Name

Description Payment-Amount Last-Name

Unit-Price Payment-Dt Title

Payment-Mode- ID Phone-No

Payment-Mode

Credit Card-No

Card Holders-Name

CreditCardExpiry-Dt

Relational Database Design 1.35


TABLES AFTER 3 NF
In the Orders table, the attribute Ship-Method depends on Ship-Method-ID and not on
Order-Code. Therefore, for the tables to be in 3 NF, we need to create another table,
Shipment Methods. Also, in the Payments table, the attribute Payment-Mode depends
on Payment-Mode-ID and not on Payment-Code. Therefore, we need to create a
separate table, Payment Modes. In addition, the attributes Cardholders-Name and
CreditCardExpiry-Dt depend on CreditCard-No and not on Payment-Code. Therefore,
we need to create another table, Credit Cards. The updated table structures are shown
here.
Customers Orders Order Details

Customers Orders Order Details

Cust-Code Order-Code OrderDetail-ID

First-Name Cust-Code Order-Code

Last-Name Emp-Code Prod-Code

Address Order-Dt Quantity

Country Ship-Name Discount

Zip-Code Ship-Address Total-Cost

Phone-No Ship-Country

Ship-Phone

Ship-Dt

Ship-Method-ID

Ship-Method

Freight-Charge

Sales-Tax

1.36 Relational Database Design


Products Payments Employees

Products Payments Employees

Prod-Code Payment- Code Emp-Code

Prod-Name Order-Code First-Name

Description Payment-Amount Last-Name

Unit-Price Payment-Dt Title

Payment-Mode-ID Phone-No

Credit Card-No

Shipment Methods Payment Modes Credit Cards

Shipment Payment Credit Cards


Methods Modes

Ship-Method-ID Payment- Credit Card-No


Mode-ID

Ship-Method Payment-Mode Card Holders-Name

CreditCardExpiry-Dt

Relational Database Design 1.37


TABLES AFTER DENORMALIZATION
When we place the information about credit card in a separate table, the query
performance during the generation of payment receipt will get affected due to creation
of joins in every payment receipt. Therefore, for optimum performance, we
denormalize and place the credit card information back into the Payments table. The
updated table structures are shown here.

Customers Orders Order Details

Customers Orders Order Details

Cust-Code Order-Code OrderDetail-ID

First-Name Cust-Code Order-Code

Last-Name Emp-Code Prod-Code

Address Order-Dt Quantity

Country Ship-Name Discount

Zip-Code Ship-Address Total-Cost

Phone-No Ship-Country

Ship-Phone

Ship-Dt

Ship-Method-ID

Ship-Method

Freight-Charge

Sales-Tax

1.38 Relational Database Design


Products Payments Employees

Products Payments Employees

Prod-Code Payment- Code Emp-Code

Prod-Name Order-Code First-Name

Description Payment-Amount Last-Name

Unit-Price Payment-Dt Title

Payment-Mode-ID Phone-No

Credit Card-No

Shipment Methods Payment Modes

Shipment Methods Payment Modes

Ship-Method-ID Payment-Mode-ID

Ship-Method Payment-Mode

Relational Database Design 1.39


PRIMARY AND FOREIGN KEYS

The Primary and Foreign keys (wherever applicable) for each table are listed with their
respective table names:
 Customers
Primary key: Cust-Code
 Orders
Primary key: Order-Code
Foreign keys: Cust-Code, Emp-Code, Ship-Method-ID
 Order Details
Primary key: OrderDetail-ID
Foreign keys: Order-Code, Prod-Code
 Shipment Methods
Primary key: Ship-Method-ID
 Products
Primary key: Prod-Code
 Payments
Primary key: Payment-Code
Foreign keys: Order-Code, Payment-Mode-ID
 Payment Modes
Primary key: Payment-Mode-ID
 Employees
Primary key: Emp-Code

1.40 Relational Database Design


RELATIONSHIPS BETWEEN FINAL TABLES
Order Details Products
Orders
Customers
Field Name Field Name
Field Name
Field Name
OrderDetail-ID Prod-Code
Order-Code
Cust-Code
Order-Code Prod-Name
Cust-Code
First-Name
Prod-Code Description
Emp-Code
Last-Name
Quantity Unit-Price
Order-Dt
Address
Discount
Ship-Name
Country
Total-Cost
Ship-Address
Zip-Code

Ship-Country
Phone-No
Shipment Methods
Ship-Phone
Field Name
Ship-Dt
Ship-Method-ID
Ship-Method-ID

Ship-Method
Freight-Charge

Sales-Tax
Payments

Field Name
Employees

Payment-Code Field Name

Order-Code Emp-Code

Payment-Amount First-Name

Payment-Dt Last-Name

Payment-Mode-ID Payment Modes Title

CreditCard-No Field Name


Phone-No

CardHolders-Name Payment-Mode-ID

CreditCardExpiry-Dt Payment-Mode

Relational Database Design 1.41


BLANK DOCUMENTATION FORMATS

PROJECT ON

Developed by

Name:

Reg. No.:

1.42 Relational Database Design


(Project Title)

Batch Code :
Start Date : End Date:
Name of the Coordinator :
Name of Developer :

Date of Submission :

Relational Database Design 1.43


CERTIFICATE

This is to certify that this report titled ______ embodies the original
work done by ______ in partial fulfillment of their course requirement
at NIIT.

Coordinator:

1.44 Relational Database Design


ACKNOWLEDGEMENT

Relational Database Design 1.45


SYSTEM ANALYSIS

System Summary:

1.46 Relational Database Design


ENTITIES
Number of entities:
Names of entities:

Relational Database Design 1.47


ATTRIBUTES
Attributes:

1.48 Relational Database Design


E/R DIAGRAM

Relational Database Design 1.49


TABLES
Number of Tables:
Structure of Tables:

1.50 Relational Database Design


TABLES AFTER 1 NF

Relational Database Design 1.51


TABLES AFTER 2 NF

1.52 Relational Database Design


TABLES AFTER 3 NF

Relational Database Design 1.53


TABLES AFTER DENORMALIZATION

1.54 Relational Database Design


PRIMARY AND FOREIGN KEYS

Relational Database Design 1.55


RELATIONSHIPS BETWEEN FINAL TABLES

1.56 Relational Database Design

You might also like