DATA FLOW DIAGRAM

Government/Private Sector

Tender
Bid
Selection of
Company

Accepted

Rejected
If rejected then
select another
company

Contract
Inspection
Process

Rejected

Work Permit
Payment

Supplier

Hire
Workers

Allocation
of
Employees

Supply

Material

Labor

Employee
Payment if
approved

Partial
payment
(Phase to
phase)

Project in
progress

Project Completed

Quality
Testing

Compensate

Court Notification

Contract

Tender

Supplier

Employee
Contract
Management
System

Labor

Payment

Tender

Project
Completed

Selecting
Company

Quality
Testing

Contract

Payment

Material

Machinery

Inspection
Process

Process
in
progress

Work Permit

Allocation
Of
Employees

Charges Payment

Tender

has

For simplicity, I
put the contract
here.

Contracts needs

Measurement
criteria

requires

Material
details

requires

Machinery
details

Employee
allocation

has

requires Employees has

Material

has

Contract

has

Machinery supplies

supplies

Job
type

Is associated
Designation
with

Supplier

Tender

Is filled
with

Bid

Is filled
for

charges

M Payment

allocates

M Employee

allocates

1
Contract
1

Supplier 1

supplies

Material

requires

1
supplies

Machinery

requires

Labor

charges

Payment

1
Tender

has

Contract

needs

Employee
allocation

supplies

has

M Material 1

has

1
Measurement
criteria

Job type

1
has

supplies

1 Employee
1

has

Supplier 1

requires

M Machinery 1

has

Material
detail

Is
associated
with

M
Machinery
detail

Designation

The major entities of Contract Management System are:

Tender
(Tender_Ref_Num, Cost_of_Tender, Anticiapted_Cost, Opening_Date)

Contract
(Contract_ID, Tender_Ref_Num, Status, Bid_Amount, Location)

Payment
(Contract_ID, Date, Amount_Paid)

Supplier
(Supplier_ID, Supplier_Name)

Employee
(Employee_ID, Employee_Name, Designation, Salary, No_of_Days, Address, Date_of_birth,
Job_Type, Joining_Date, Contract_ID)

Material
(Material_ID, Material_Name, Cost, Quantity, Measurement_Criteria, Supplier_ID,
Contract_ID)

Machinery
(Machine_ID, Machine_Name, Rent_Rate, Hiring_date, Returning_Date, Comission_Date,
Purchasing_Date, Supplier_ID, Contract_ID)

FIRST NORMAL FORM

DEFINITION:
A relation is in first normal form if and only if every attribute is single-valued for each tuple.
MULTI VALUED ATTRIBUTES:
Considering the entities of Contract Management System, it seems that the following 3 entities can be
multi-valued:
Employee
Material
Machinery
Employee:

We can have more than one Contract ID for a single employee. Similarly we can have more than one
employee for a single Contract. So these two attributes will become multi-valued and as we have more
than one Contract IDs for an employee, then its logical that there will be different salaries for an
employee because of more than one Contracts (an employee can take different salaries with respect to
the number and type of Contracts).In the same way, an Employee can have more than one designations
depending upon the contract. Similarly, Job Type Allocation Date and No. of days will also become
multivalued due to the multivalued ContractID.
Material /Machinery:
We have multi valued attributes in the material and machinery Entities. A material/machine can be
bought from more than one supplier and for more than one contract. As the requirements will be
different for different contracts, so there will be different quantities of material for each contract. So the
whole setup will make these attributes multi valued.

MAKING ENTITIES SINGLE VALUED:

EMPLOYEE:
(Employee_ID, Employee_Name, Designation, Salary, No_of_Days, Address, Date_of_birth, Job_Type,
Joining_Date, Allocation_Date, Contract_ID)
We first take out the multi valued attributes from the Employee that are ContractID, Salary,
Designation, Job type, Allocation_Date and No_of_Days and make new entities for them. A new entity
namely Employee Allocation will be maintained for these multivalued attributes.
The Entities and attributes will now be:
Employee:

Employee_ID (PK)
Employee_Name
Address
Date_of_birth
Joining_Date

Employee Allocation:
Employee_ID (FK)
Contract_ID (FK)
Salary
Allocation_Date
No_of_Day
Designation
Job_Type
Composite Key: (Employee_ID, Contract_ID)

So now every attribute will be single valued at one instance in each entity.

MATERIAL:
(Material_ID, Material_Name, Cost, Quantity, Measurement_Criteria, Supplier_ID, Contract_ID)
Since Contract ID and Supplier ID are multivalued attributes so we'll maintain them in another entity
namely Material Detail.
Material:
Material_ID (PK)
Material_Name
Measurement_Criteria
Material Detail:
Material_ID (FK)
Cost
Quantity
Supplier_ID (FK)
Contract_ID (FK)
Composite Key: (Material_ID, Supplier_ID, Contract_ID)
MACHINERY:
(Machine_ID, Machine_Name, Rent_Rate, Hiring_date, Returning_Date, Comission_Date,
Purchasing_Date, Supplier_ID, Contract_ID)
Making a weak entity (Machine Detail) for the multivalued attributes:
Machinery:
Machine_ID (PK)
Machine_Name
Rent_Rate
Hiring_date
Returning_Date
Comission_Date
Purchasing_date
Machinery Detail:

Machine_ID (FK)
Supplier_ID (FK)
Contract_ID (FK)
Composite Key: (Machine_ID, Supplier_ID, Contract_ID)
So now Contract_ID and Supplier_ID are single valued at each instance in the Material / Machinery
Detail entity.

SECOND NORMAL FORM

DEFINITION:
A relation is in second normal form (2NF) if and only if it is in first normal form and all the non key
attributes are fully functionally dependent on the key.
Full Functional Dependence:
In a relation R, attribute B of R is fully functionally dependent on an attribute or set of attributes A of R
if B is functionally dependent on A but not functionally dependent on any proper subset of A.
CHECKING FUNCTIONAL DEPENDENCY:
We have composite keys in the following entities:
Payment
Employee Allocation
Material Detail
Machine Detail
Payment:
Composite key: (Contract_ID, Date)
FD: Contract_ID, Date Amount_Paid
The non key attribute Amount_Paid is fully functionally dependent on the Composite key and not on the
subset of the key so Payment is in 2NF.
Employee Allocation:
Composite Key: (Employee_ID, Contract_ID)
FD: Employee_ID, Contract_ID Allocation_Date, No_of_Days, Salary, Designation, Job_Type
The non key attributes Allocation_Date, No_of_Days, Salary, Designation and Job_Type are fully
functionally dependent on the Composite key and not on the subset of the key so this entity is in 2NF.
Material Detail:

Composite Key: (Material_ID, Supplier_ID, Contract_ID)

FD: Material_ID, Supplier_ID, Contract_ID Cost, Quantity
The non key attributes Cost and Quantity are fully functionally dependent on the Composite key and not
on the subset of the key so this entity is in 2NF.

Machine Detail:
Composite Key: (Machine_ID, Supplier_ID, Contract_ID)
It is a weak entity set and there is no non key attribute in this entity. It holds for 2NF.

THIRD NORMAL FORM

DEFINITION:
A relation is in Third normal form (3NF) if it is in second normal form and no non key attribute is
transitively dependent on the key.

Transitive Dependency:
A transitive dependency occurs when one non key attribute determines another non key attribute. For
third normal form we concentrate on relations with only one candidate key, and we eliminate transitive
dependencies.

CHECKING TRANSITIVE DEPENDENCY:

After checking the 2nd normal form, when we switch to the 3rd normal form then some of our tables have
Transitive dependency, which have to be resolved. The description given below shows the problems
during the 3NF and then solution is provided.
Following are the tables which have Transitive dependency:

Employee Allocation
Material

Employee_Allocation:
Attributes of "Employee Allocation" are:

Employee_ID (FK)
Contract_ID (FK)

Salary
Allocation_Date
No_of_Day
Designation
Job_Type

Here the Composite Key is " Employee_ID and Contract_ID", which determines all the remaining
attributes, but the problem is that here is another attribute which is a non key attribute namely
Designation which also determines other non key attributes that is Job_type, which involves the
Transitive dependency and due to this dependency anomalies can occur in the project, so it must be
resolved.
In order to resolve this Transitive dependency, we need to add another table namely "Designation",
having the following attributes:
Designation:

Designation_ID
Designation_Name

Here Designation_ID is the primary key, which determines the non key attribute Designation_Name.
Since Job_Type field is dependent upon both Designation and Employee so we can't place it in the
Employee Allocation table, neither can we add it in the Designation table. So a weak entity set is created
for compensating the Job_Type attribute namely:
Job_Type
Employee_ID
Designation_ID
Job_Type
Composite Key: (Employee_ID, Designation _ID)
From the Employee relation we have got the following new relations:
Employee:

Employee_ID (PK)
Employee_Name
Address
Date_of_birth
Joining_Date

Employee Allocation:

 Employee_ID (FK)
Contract_ID (FK)
Salary
Allocation_Date
No_of_Day
Composite Key: (Employee_ID, Contract_ID)
Designation:

Designation_ID (PK)
Designation_Name

Job_Type
Employee_ID
Designation_ID
Job_Type
Composite Key: (Employee_ID, Designation _ID)
MATERIAL:
Again the problem is also same with this table, it also holds Transitive dependency, this relation contains
following attributes:

Material_ID
Material_Name
Measurement_Criteria

Here the Primary Key is "Material_ID" which determines the remaining two attributes, but the problem
is that "Material_Name" which is a non key attribute also determines another non key attribute that is
"Measurement_Criteria", so it also has Transitive dependency.
We resolve this problem by breaking the table of "Material" into two tables, these two tables and their
corresponding attributes are given below:
Material:

Material_ID (PK)
Material_Name

Here Material_ID determines Material_Name.

Measurement_Criteria:

Material_ID (PK)
Measurement_Criteria

Now we have total three tables related to the Material altogether, and these are:

Material
Measurement_Criteria
Material_Detail

We have defined the fields of first two tables above but the attributes of the "Matrial_Detail" table are:

Material_Detail:
Material_ID (FK)
Contract_ID (FK)
Supplier_ID (FK)
Date
Quantity
Cost
Composite key: Material_ID, Contract_ID, Supplier_ID and Date
Remaining tables remains the same because they don't have Transitive dependency, so they are in 3rd
normal form (3NF).

BOYCE-CODD NORMAL FORM (BCNF)

DEFINITION:
A relation is in Boyce-Codd normal form (BCNF) if and only if every determinant a candidate key.
All the tables up till now which are involved in the project are in Boyce-Codd normal form, because
every determinant is a candidate key and all the non key attributes are fully functionally dependent on
the identifier.

FOURTH NORMAL FORM (4NF)

DEFINITION:
A relation is in fourth normal form if and only if it is in Boyce-Codd normal form and there are no non
trivial multivalued dependencies.
Multivalued Dependencies:
Let R be a relation having attributes or sets A, B and C. There is a multivalued dependence of attribute B
on attribute A if and only if the set of B values associated with a given A values are independent of the C
values.
The dependency A
all of R.

B is called a Trivial multivalued dependency if B is a subset of A or A U B is

All the tables involving in this project are in fourth normal form (4NF), because there is not any table
which contains any multivalued attribute.

FIFTH NORMAL FORM

DEFINITION:
A relation is in fifth normal form (5NF) if no remaining nonloss projections are possible, except the
trivial one in which the key appears in each projection.
LOSSLESS DECOMPOSITION:
Definition of Decomposition:
A decomposition of a relation R is a set of relations {R1, R2., Rn} such that each Ri is a subset of R and
the union of all of the Ri is R.
Definition of Lossless Decomposition:
A decomposition {R1, R2,., Rn} of a relation R is called a lossless decomposition for R if the natural
join of R1, R2,., Rn produces exactly the relation R.
EMPLOYEE:
Consider the relation Employee (say R) in the Contract Management System
After Normalization, this relation is further structured into 4 relations:

Employee (say R1)

Employee Allocation (say R2)

Designation (say R3)
Job Type (say R4)

Naming the attributes of the relations in the following manner:

Employee ID = A
Employee_Name = B
Address = C
Date_of_birth = D
Joining_Date = E
Contract_ID = F
Salary = G
Allocation_Date = H
No_of_Days = I
Designation_ID = J
Designation_Name = K
Job_Type = L
R(A,B,C,D,E,F,G,H,I,J,K,L)
Decomposition: R1(A,B,C,D,E), R2 (A,F,G,H,I), R3 (J,K), R4(A,J,L)
FDs: A BCDE, AF GHI, J K, AJ L
Initial Placement of values:
R1(A,B,C,D,E)
R2(A,F,G,H,I)
R3(J,K)
R4(A,J,L)

A
Y
Y
N
Y

B
Y
N
N
N

C
Y
N
N
N

D
Y
N
N
N

E
Y
N
N
N

F
N
Y
N
N

G
N
Y
N
N

H
N
Y
N
N

D
Y
Y
N
N

E
Y
Y
N
N

F
N
Y
N
N

G
N
Y
N
N

H
N
Y
N
N

J
N
N
Y
Y

K
N
N
Y
N

L
N
N
N
Y

J
N
N
Y
Y

K
N
N
Y
Y

L
N
N
N
Y

N
Y
N
N

Table after considering all FD's:

A
R1(A,B,C,D,E) Y
R2(A,F,G,H,I) Y
R3(J,K)
N
R4(A,J,L)
Y

B
Y
Y
N
N

C
Y
Y
N
N

N
Y
N
N

Since not a single row yields to complete Ys so it shows that it is not in 5NF.Again considering all the
relations and their FDs:
Reconsidering Job_Type Relation:

 Employee_ID
Designation_ID
Job_Type
FD: Employee_ID, Designation_ID Job_Type
Adding the Contract_ID in the Composite key of Job Type, the attributes will be:
Employee_ID
Designation_ID
Contract_ID
Job_Type
FD: Contract_ID, Employee_ID, Designation_ID Job_Type
The above entity holds for 1NF, 2NF, 3NF, 4NF and BCNF as well.
Checking The Relation For 5NF.
R(A,B,C,D,E,F,G,H,I,J,K,L)
Decomposition: R1(A,B,C,D,E), R2 (A,F,G,H,I), R3 (J,K), R4(A,F,J,L)
FDs: A BCDE, AF GHI, J K, AFJ L
Initial Placement of values:
R1(A,B,C,D,E)
R2(A,F,G,H,I)
R3(J,K)
R4(A,F,J,L)

A
Y
Y
N
Y

B
Y
N
N
N

C
Y
N
N
N

D
Y
N
N
N

E
Y
N
N
N

F
N
Y
N
Y

G
N
Y
N
N

H
N
Y
N
N

J
N
N
Y
Y

N
Y
N
N

K
N
N
Y
N

Table after considering all FD's:

A
R1(A,B,C,D,E) Y
R2(A,F,G,H,I) Y
R3(J,K)
N
R4(A,F,J,L)
Y

B
Y
N
N

C
Y
N
N

D
Y
N
N

E
Y
N
N

F
N
Y
N

G
N
Y
N

H
N
Y
N

I
N
Y
N

J
N
N
Y

K
N
N
Y

L
N
N
N

So the relation holds for Fifth Normal Form as well.

MATERIAL:
Consider the relation Material (say R) in the Contract Management System
This relation is further structured into 2 relations:

L
N
N
N
Y

Material (namely R1)

Material Detail (namely R2)
Material Criteria (namely R3)

Naming the attributes of the relations in the following manner:

Material_ID = A
Material_Name = B
Measurement_Criteria = C
Cost = D
Quantity = E
Date = F
Supplier_ID = G
Contract_ID = H
R(A,B,C,D,E,F,G,H)
Decomposition: R1(A,B), R2(A,D,E,F,G,H), R3(A,C)
FDs: A B, AFGH DE, A C
Initial Placement of values:
A
R1(A,B)
Y
R2(A,D,E,F,G,H) Y
R3(A,C)
Y

B
Y
N
N

C
N
N
Y

D
N
Y
N

E
N
Y
N

F
N
Y
N

G
N
Y
N

H
N
Y
N

Table after considering all FD's:

A
R1(A,B)
Y
R2(A,D,E,F,G,H) Y
R3(A,C)
Y

B
Y

C
N

D
N

E
N

F
N

G
N

H
N

The relation holds for Fifth Normal Form.

MACHINE:
Consider the relation Machine (say R) in the Contract Management System
This relation is further structured into 2 relations:

Machine (namely R1)

Machine Detail (namely R2)

Naming the attributes of the relations in the following manner:

Machine_ID = A
Machine_Name = B
Rent_Rate = C
Hiring_date = D
Returning_Date = E
Comission_Date = F
Purchasing_date = G
Supplier_ID = H
Contract_ID = I
R(A,B,C,D,E,F,G,H,I)
Decomposition: R1 (A,B,C,D,E,F,G), R2 (A,H,I)
FDs: A BCDEFG
Initial Placement of values:
A
R1(A,B,C,D,E,F,G) Y
R2(A,H,I)
Y

B
Y
N

C
Y
N

D
Y
N

E
Y
N

F
Y
N

G
Y
N

H
N
Y

I
N
Y

Table after considering all FD's:

A
R1(A,B,C,D,E,F,G) Y
R2(A,H,I)
Y

B
Y

C
Y

D
Y

E
Y

F
Y

G
Y

H
N

I
N

The relation holds for Fifth Normal Form.

After Normalization, the entities of Contract Management System are:

Tender
(Tender_Reference_Number, Cost_of_Tender, Anticiapted_Cost, Opening_Date)

Contract
(Contract_ID, Tender_Reference_Number, Status, Bid_Amount, Location)

Payment
(Contract_ID, Date, Amount_Paid)

Supplier
(Supplier_ID, Supplier_Name)

Employee
(Employee_ID, Employee_Name, Address, Date_of_birth, Joining_Date,)

Employee Allocation
(Employee_ID, Contract_ID, Salary, Allocation_Date, No_of_Day)

Designation
(Designation_ID, Designation_Name)

Job_Type
(Employee_ID, Designation_ID, Job_Type)

Material
(Material_ID, Material_Name)

Measurement_Criteria
(Material_ID, Measurement_Criteria)

Material_Detail
(Material_ID, Contract_ID, Supplier_ID, Date, Quantity, Cost)

Machinery
(Machine_ID, Machine_Name, Rent_Rate, Hiring_date, Returning_Date, Comission_Date,
Purchasing_Date,)

Machinery Detail:
(Machine_ID, Supplier_ID, Contract_ID)

DATA DICTIONARY
Table # 1: Tender
Tender_Ref_Num (nvarchar)
Cost_Of_Tender (money)
Anticipated_Cost (money)
Opening_Date (datetime)

Reference number of Tender

Cost of Tender in Rs.
Cost of Contract (in Rs.) offered by the Client
Opening Date of Tender after bid filling

Primary Key: TenderRefNum

Table # 2: Contract
Contract_ID (int)

Identity number of Contract

Tender_Ref_Num (nvarchar)
Status (char)
Bid (int)
Location (nvarchar)

Reference number of Tender

Either bid accepted or rejected (Yes/No)
Amount filled by the Company (in Rs.)
Location of the Contract

Primary key: Contract_ID

Table # 3: Payment
Contract_ID (int)
Date (datetime)
Amount_Paid (money)

Identity number of Contract

Date of getting Payment
Amount paid by the client (in Rs.)

Composite Key: Contract_ID, Date

Table # 4: Supplier
Supplier_ID (int)
Supplier_Name (nvarchar)

Identity number of Supplier

Name of the Supplying Company

Primary key: Supplier_ID

Table # 5: Employee
Employee_ID (int)
Employee_Name (nvarchar)
Address (nvarchar)
Date_of_birth (datetime)
Joining_Date (datetime)

Identity number of Employee

Name of the Employee
Address of the Employee
Date of birth of the Employee
Joining date of the Employee

Primary key: Employee_ID

Table # 6: Employee Allocation

Employee_ID (int)
Contract_ID (int)
Salary (money)
Allocation_Date (datetime)
No_of_Days (int)

Identity number of Employee

Identity number of Contract
Salary paid to Employee (in Rs.)
Date of Allocation of Employee to the corresponding
Contract
Total number of working days of an employee on the
corresponding Contract

Composite key: Employee_ID, Contract_ID

Table # 7:Designation
Designation_ID (int)
Designation_Name (nvarchar)

Identity number of Designation

Name of Designation

Primary key: Designation_ID

Table # 8:Job_Type
Employee_ID (int)
Contract_ID (int)
Designation_ID (int)
Job_Type (nvarchar)

Identity number of Employee

Identity number of Contract
Identity number of Designation
Type of Job(Permanent, Daily wages etc.)

Composite key: Employee_ID, Contract_ID, Designation_ID

Table # 9: Material
Material_ID (int)
Material_Name (nvarchar)

Identity number of material

Name of Material (cement, sand etc.)

Primary key: Material_ID

Table # 10: Material Detail

Material_ID (int)
Contract_ID (int)
Supplier_ID (int)
Date (datetime)
Quantity (int)
Cost (money)

Identity number of Material

Identity number of Contract
Identity number of Supplier
Purchasing Date of Material
Quantity of Material
Cost of Material (in Rs.)

Composite key: Material_ID, Contract_ID, Supplier_ID

Table # 11: Material Criteria

Material_ID (int)
Measurement_Criteria (char)
Primary key: Material_ID

Table # 12: Machinery

Identity number of Material

Measurement criteria of material (in kgs etc.)

Machine_ID (int)
Machine_Name (nvarchar)
Rent_Rate (money)
Hiring_Date (datetime)
Returning_Date (datetime)
Comission_Date (datetime)
Purchasing_Date (datetime)

Identity number of Machinery

Name of Machinery
Rent Rate of Hired Machinery (inRs.)
Hiring Date of Machinery
Returning Date of Machinery
Comission Date of Machinery
Purchasing Date of
Machinery bought

Primary key: Machine_ID

Table # 13: Machinery Detail

Machine_ID (int)
Supplier_ID (int)
Contract_ID (int)

Identity number of Machinery

Identity number of Supplier
Identity number of Contract

Composite key: Machine_ID, Supplier_ID, Contract_ID

"RELATIONAL SCHEMA"

TENDER(Tender_Reference_No, Cost_Of_tender, Anticipated_Cost,

Openeing_Date)

CONTRACT(Contract_Id, Tender_Refernce_No, Bid, Location, Status)

EMPLOYEE(Employee_Id, Employee_Name, DOB, Address, Company_Joining_Date)
EMPLOYEE_ALLOCATION(Employee_Id, Contract_Id, Allocation_Date, Salary,
No_Of_Days_Worked)
DESIGNATION(Designation_Id, Designation_Name)
JOB_TYPE(Designation_Id, Employee_Id, Contract_Id, Job_Type)
SUPPLIER(Supplier_Id, Supplier_Name)
MATERIAL(Material_Id, Material_Name)
MEASUREMENT_CRITERIA(Material_Id, Measurement_Criteria)
MATERIAL_DETAIL(Material_Id, Contract_Id, Supplier_Id, Date, Quantity, Cost)

MACHINERY(Machine_Id, Machine_Name, Commission_Date, Purchasing_Date, Hiring_Date,

Returning_Date, Rent_Rate)
MACHINERY_DETAIL(Machine_Id, Contract_Id, Supplier_Id)
PAYMENT(Contract_Id, Date, Amount_Paid)
FORWARD this to ALL SECTION A MEMBERS ALSO!
NOW THIS IS ONE SURPRISE!! (Ye mjy bhe nahe pata tha SHAKIR! xD!!)
WORDS FROM SIR KJ!!
TASK 1)
Assalamualaikum
I am attaching herewith a softcopy about the way you have to follow the project. you can consider this
as a roadmap for the DB project, same methodology should be followed for all the projects
best wishes
wassalam
TASK 2)
OUR PAPERS WOULD END on 11th of June! Just AFTER 7 days, i.e 19th June, would be the
SUBMISSION DEADLINE for DB PROJECT!
Our DB SHOULD be in POSTER PRESENTATION
I.e size of Panaflex should be 9 ft x 5 ft
Having following entries::
_______________________________________________________________
|
|
|
|
|
|
|
|
|
|
Dfd
|
Erd
|
|
|
|
|
|
|
|
|
|
|
|
|
|______________________________ |______________________________ |

|
| Normalization |
|
|
Semantic |
|
Front End
|
|
Net
|
|
Forms/Projects
|
|
|
|
|
|
|
|
|
|
|
|
|
|________________|______________|______________________________|
PS: Enjoy Summer Vacations!

| Give Peace a Chance|

Peace!

Please consider the environmental cost of paper. Save a tree...

Please don't print this e-mail unless you really need it.

1st Normal Form

CUSTOMER ORDER (CustName, OrderNo, MotorcylceNo, MotocycleDesc, Quality, Color name, CC
spec, Model ID, Model name, Qty, CustAddress, DateOrdered, Datereleased)
Customer (CustName, CustAddress)
Customer Order (OrderNo, MotorcylceNo, MotocycleDesc, Quality, Color name, CC spec, Model ID,
Model name, Qty, DateOrdered, Datereleased)

2nd Normal Form

Customer (CustName, CustAddress)
Customer Order (OrderNo, Qty, DateOrdered, Datereleased)
Product (MotorcylceNo, MotocycleDesc, Quality, Color name, CC spec, Model ID, Model name,)

3rd Normal Form

Customer (CustName, CustAddress)
Customer Order (OrderNo, Qty, DateOrdered, Datereleased)
Product (MotorcylceNo, MotocycleDesc)
Model (Quality, Color name, CC spec, Model ID, Model name)