 The purpose of normailization

 Functional Dependencies
 The Process of Normalization
 First Normal Form (1NF)
 Second Normal Form (2NF)
 Third Normal Form (3NF)
 Boyce-Codd Normal Form (BCNF)
 Fourth Normal Form (4NF)
 Fifth Normal Form (5NF)
 Domain Key Normal Form (DKNF)
A properly normalized database
should have the following
characteristics
 Scalar values in each fields
 Absence of redundancy.
 Minimal use of null values.
 Minimal loss of information.
 Database normalization is the process of
removing redundant data from the tables to
improve storage efficiency, data integrity, and
scalability.
 The process of normalization is a formal method
that identifies relations based on their primary
or candidate keys and the functional
dependencies among their attributes.
 Normalization generally involves splitting
existing tables into multiple ones, which must
be re-joined or linked each time a query is
issued.
 Levels of Normalization
 Unnormalized – There are multivalued attributes or
repeating groups
 First Normal Form (1NF) –

No multivalued attributes or repeating groups.

 Second Normal Form (2NF)

1 NF plus no partial dependencies

Redundancy
 Third Normal Form (3NF)-

2 NF plus no transitive dependencies

 Boyce-Codd Normal Form (BCNF)

yti x el p mo C
 Fourth Normal Form (4NF)

ba Tf o r eb mu N
 Fifth Normal Form (5NF)

 Domain Key Normal Form (DKNF)

Levels of Normalization
1NF
2NF
3NF
4NF
5NF
DKNF

Each
Eachhigher
higherlevel
levelisisaasubset
subsetofofthe
thelower
lowerlevel
level
 Edgar F. Codd first proposed the process of
normalization and what came to be known
as the 1st normal form in his paper A
Relational Model of Data for Large Shared
Data Banks Codd stated:
“There is, in fact, a very simple elimination
procedure which we shall call normalization.
Through decomposition non-simple domains
are replaced by ‘domains whose elements
are atomic (non-decomposable) values.’”
 In the relational model, methods exist for
quantifying how efficient a database is. These
classifications are called normal forms (or
NF), and there are algorithms for converting
a given database between them.
 Edgar F. Codd originally established three
normal forms: 1NF, 2NF and 3NF. There are
now others that are generally accepted, but
3NF is widely considered to be sufficient for
most applications. Most tables when reaching
3NF are also in BCNF (Boyce-Codd Normal
Form).
 Repeating group = (propertyNo, pAddress,
rentStart, rentFinish, rent, ownerNo,
oName)
ClientNo cName propertyNo pAddress rentStart rentFinish rent ownerNo oName
CR76 John PG4 6 lawrence 1-Jul-00 31-Aug-01 350 CO40 Tina
kay St,Glasgow Murphy
PG16
5 Novar Dr, 1-Sep-02 1-Sep-02 450 CO93 Tony Shaw
Glasgow

CR56 Aline PG4 6 lawrence 1-Sep-99 10-Jun-00 350 CO40 Tina

Stewart St,Glasgow Murphy

PG36 2 Manor Rd, 10-Oct-00 1-Dec-01 370 CO93 Tony Shaw

Glasgow
Tony Shaw
PG16 5 Novar Dr, 1-Nov-02 1-Aug-03 450 CO93
Glasgow
Title Author1 Author2 ISBN Subject Pages Publisher

Database Abraham Henry F. 0072958863 MySQL, 1168 McGraw-Hill

System Silberschatz Korth Computers
Concepts

Operating Abraham Henry F. 0471694665 Computers 944 McGraw-Hill

System Silberschatz Korth
Concepts
 This table is not very efficient with
storage.

 This design does not protect data

integrity.

 Third, this table does not scale well.

In Table 1, there are two violations of 1NF:

 First, There is more than one author field,

 Second, The subject field contains more
than one piece of information. With more
than one value in a single field, it would
be very difficult to search for all books on
a given subject.
 A table is considered to be in 1NF if all the
fields contain only scalar values (as opposed
to list of values).
How to Decompose?
1. Place all items that appear in the repeating
group in a new table
2. Designate a primary key for each new table
produced.
3. Duplicate in the new table the primary key
of the table from which the repeating group
was extracted or vice versa.
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Option 1: Make a determinant of the
repeating group (or the multivalued
attribute) a part of the primary key.
Composite
Primary Key
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Option 2: Remove the entire repeating group
from the relation. Create another relation which
would contain all the attributes of the repeating
group, plus the primary key from the first
relation. In this new relation, the primary key
from the original relation and the determinant
of the repeating group will comprise a primary
key.
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 STUDENT

Stud_ID Name
101 Lennon
125 Jonson

STUDENT_COURSE

Stud_ID Course Units

101 MSI 250 3
101 MSI 415 3
125 MSI 331 3
  Table 2

Title Author ISBN Subject Pages Publisher

Database System Abraham 0072958863 MySQL 1168 McGraw-Hill

Concepts Silberschatz
Database System Henry F. Korth 0072958863 Computers 1168 McGraw-Hill
Concepts

Operating System Henry F. Korth 0471694665 Computers 944 McGraw-Hill

Concepts

Operating System Abraham 0471694665 Computers 944 McGraw-Hill

Concepts Silberschatz
 Now there are two rows for a single book.
Additionally, violating the Second Normal
Form…
 A better solution to the problem would be
to separate the data into separate tables-
an Author table and a Subject table to
store the information, removing that
information from the Book table:
ClientNo propertyN cName pAddress rentStart rentFinish rent ownerNo oName
o
CR76 PG4 John 6 lawrence 1-Jul-00 31-Aug-01 350 CO40 Tina
Kay St,Glasgow Murphy
CR76 PG16 John 5 Novar Dr, 1-Sep-02 1-Sep-02 450 CO93 Tony Shaw
Kay Glasgow
CR56 PG4 Aline 6 lawrence 1-Sep-99 10-Jun-00 350 CO40 Tina
Stewart St,Glasgow Murphy
CR56 PG36 Aline 2 Manor Rd, 10-Oct-00 1-Dec-01 370 CO93 Tony Shaw
Stewart Glasgow

CR56 PG16 Aline 5 Novar Dr, 1-Nov-02 1-Aug-03 450 CO93 Tony Shaw
Stewart Glasgow
 ClientN propertyN pAddress rentStart rentFinis rent ownerNo oName
o o h
ClientNo cName CR76 PG4 6 lawrence 1-Jul-00 31-Aug-01 350 CO40 Tina
St,Glasgow Murphy
CR76 John Kay
CR56 Aline Stewart CR76 PG16 5 Novar Dr, 1-Sep-02 1-Sep-02 450 CO93 Tony
Glasgow Shaw

CR56 PG4 6 lawrence 1-Sep-99 10-Jun-00 350 CO40 Tina

St,Glasgow Murphy

CR56 PG36 2 Manor Rd, 10-Oct-00 1-Dec-01 370 CO93 Tony

Glasgow Shaw

CR56 PG16 5 Novar Dr, 1-Nov-02 1-Aug-03 450 CO93 Tony

Glasgow Shaw

1NF ClientRental relation with the second approach

 With the second approach, the repeating
group (property rented details) is
removed by placing the repeating data
along with a copy of the original key
attribute (clientNo) in a separte relation.
 Client (clientNo,cName)
PropertyRentalOwner (clientNo,
propertyNo, pAddress, rentStart,
rentFinish, rent, ownerNo, oName)
 Subject Table
Subject_ID Subject

1 MySQL

2 Computers

Author Table
Author_ID Last Name First Name
Book Table
1 Silberschat Abraham
ISBN Title Pages Publisher z
007295886 Database System 1168 McGraw-Hill 2 Korth Henry
3 Concepts

047169466 Operating System 944 McGraw-Hill

5 Concepts
 Each table has a primary key, used for
joining tables together when querying the
data. A primary key value must be unique
with in the table (no two books can have
the same ISBN number), and a primary
key is also an index, which speeds up
data retrieval based on the primary key.
 Now to define relationships between the
tables
Book_Author Table
Book_Subject Table
ISBN Author_ID

0072958863 1 ISBN Subject_ID

0072958863 2 0072958863 1

0471694665 1 0072958863 2

0471694665 2 0471694665 2
Full functional dependency indicates that if A
and B are attributes of a relation, B is fully
functionally dependent on A if B is
functionally dependent on A, but not on any
proper subset of A.

A functional dependency AB is partially

dependent if there is some attributes that can be
removed from A and the dependency still holds.
 Multivalued Attributes (or repeating groups):
non-key attributes or groups of non-key
attributes the values of which are not
uniquely identified by (directly or indirectly)
(not functionally dependent on) the value of
the Primary Key (or its part).
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Partial Dependency – when an non-key attribute is
determined by a part, but not the whole, of a
COMPOSITE primary key.

Partial
CUSTOMER Dependency

Cust_ID Name Order_ID

101 AT&T 1234
101 AT&T 156
125 Cisco 1250
  Transitive Dependency – when a non-
key attribute determines another non-
key attribute.
Transitive
Dependency
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
If one set of attributes in a table
determines another set of attributes in
the table, then the second set of
attributes is said to be functionally
dependent on the first set of attributes.
Main characteristics of functional dependencies in normalization

• Have a one-to-one relationship between attribute(s)

on the left- and right- hand side of a dependency;

• hold for all time;

• are nontrivial.
 Second Normal Form
(2NF)
For a table to be in 2NF, there are two requirements
 The database is in first normal form
 All nonkey attributes in the table must be functionally
dependent on the entire primary key
Note: Remember that we are dealing with non-key attributes

Example 1 (Not 2NF)

Scheme  {Title, PubId, AuId, Price, AuAddress}
1. Key  {Title, PubId, AuId}
2. {Title, PubId, AuID}  {Price}
3. {AuID}  {AuAddress}
4. AuAddress does not belong to a key
5. AuAddress functionally depends on AuId which is a
subset of a key
 Second Normal Form
Example 2 (Not 2NF)
(2NF)
Scheme  {City, Street, HouseNumber, HouseColor, CityPopulation}
1. key  {City, Street, HouseNumber}
2. {City, Street, HouseNumber}  {HouseColor}
3. {City}  {CityPopulation}
4. CityPopulation does not belong to any key.
5. CityPopulation is functionally dependent on the City which is a
proper subset of the key

Example 3 (Not 2NF)

Scheme  {studio, movie, budget, studio_city}
1. Key  {studio, movie}
2. {studio, movie}  {budget}
3. {studio}  {studio_city}
4. studio_city is not a part of a key
5. studio_city functionally depends on studio which is a proper subset
of the key
 2NF - Decomposition
1. If a data item is fully functionally dependent on only a
part of the primary key, move that data item and that
part of the primary key to a new table.
2. If other data items are functionally dependent on the
same part of the key, place them in the new table also
3. Make the partial primary key copied from the original
table the primary key for the new table. Place all items
that appear in the repeating group in a new table
Example 1 (Convert to 2NF)
Old Scheme  {Title, PubId, AuId, Price, AuAddress}
New Scheme  {Title, PubId, AuId, Price}
New Scheme  {AuId, AuAddress}
 2NF - Decomposition
Example 2 (Convert to 2NF)
Old Scheme  {Studio, Movie, Budget, StudioCity}
New Scheme  {Movie, Studio, Budget}
New Scheme  {Studio, City}

Example 3 (Convert to 2NF)

Old Scheme  {City, Street, HouseNumber, HouseColor,
CityPopulation}
New Scheme  {City, Street, HouseNumber, HouseColor}
New Scheme  {City, CityPopulation}
Second normal form (2NF) is a relation that
is in first normal form and every non-
primary-key attribute is fully functionally
dependent on the primary key.

The normalization of 1NF relations to 2NF

involves the removal of partial
dependencies. If a partial dependency exists,
we remove the function dependent attributes
from the relation by placing them in a new
relation along with a copy of their
determinant.
 As the First Normal Form deals with
redundancy of data across a horizontal
row, Second Normal Form (or 2NF) deals
with redundancy of data in vertical
columns.
 Publisher Table
Publisher_ID Publisher Name

1 McGraw-Hill

Book Table
ISBN Title Pages Publisher_ID

0072958863 Database System 1168 1

Concepts

0471694665 Operating System 944 1

Concepts
 Composite
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Goal: Remove Partial Dependencies
Partial
Composite Dependencies
Primary Key

STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
 Remove attributes that are dependent from the
part but not the whole of the primary key from the
original relation. For each partial dependency,
create a new relation, with the corresponding part
of the primary key from the original as the primary
key.
STUDENT

Stud_ID Name Course_ID Units

101 Lennon MSI 250 3.00
101 Lennon MSI 415 3.00
125 Johnson MSI 331 3.00
CUS TO M ER
STUDENT_COURSE
S tud_ID Na m e Course _ID Units
101 Lennon M S I 250 3.00
101 Lennon M S I 415 3.00
125 Johns on M S I 331 3.00
Stud_ID Course_ID
101 MSI 250
101 MSI 415
125 MSI 331

STUDENT COURSE

Stud_ID Name
Course_ID Units
101 Lennon
101 Lennon MSI 250 3.00
125 Johnson MSI 415 3.00
MSI 331 3.00
 In this example there exists a one-to-many
relationship between the book table and the
publisher. A book has only one publisher, and
a publisher will publish many books. When
there is a one-to-many relationship, a foreign
key is placed in the Book Table, pointing to
the primary key of the Publisher Table.
 The other requirement for Second Normal
Form is that there cannot be any data in a
table with a composite key that does not
relate to all portions of the composite key.
 Third normal form (3NF) requires that
there are no functional dependencies of
non-key attributes on something other
than a candidate key.
 A table is in 3NF if all of the non-primary
key attributes are mutually independent
 There should not be transitive
dependencies
  Goal: Get rid of transitive dependencies.

Transitive
Dependency
EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
 Remove the attributes, which are dependent on a
non-key attribute, from the original relation. For
each transitive dependency, create a new relation
with the non-key attribute which is a determinant in
the transitive dependency as a primary key, and the
dependent non-key attribute as a dependent.

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID Dept_Name

111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
EM P L O YEE

Em p _ID F _Na m e L _Na m e De pt_ID De p t_Na m e

111 M ary Jones 1 Acct
122 S arah S m ith 2 M ktg

EMPLOYEE

Emp_ID F_Name L_Name Dept_ID

111 Mary Jones 1
122 Sarah Smith 2

DEPARTMENT

De pt_ID De pt_Name
1 Acct
2 Mktg
The functional dependencies for the Client, Rental and
PropertyOwner relations are as follows:

Client
fd2 clientNo  cName
(Primary Key)

Rental
fd1 clientNo, propertyNo  rentStart, rentFinish (Primary Key)
fd5 clientNo, rentStart  propertyNo, rentFinish (Candidate
key)
fd6 propertyNo, rentStart  clientNo, rentFinish (Candidate
key)

PropertyOwner
fd3 propertyNo  pAddress, rent, ownerNo, oName
(Primary Key)
fd4 ownerNo  oName (Transitive
The resulting 3NF relations have the forms:

Client (clientNo, cName)

Rental (clientNo, propertyNo, rentStart, rentFinish)
PropertyOwner (propertyNo, pAddress, rent, ownerNo)
Owner (ownerNo, oName)
Client Rental
ClientNo cName ClientNo propertyNo rentStart rentFinish
CR76 PG4 1-Jul-00 31-Aug-01
CR76 John Kay
CR56 Aline Stewart CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
CR56 PG16 1-Nov-02 1-Aug-03

PropertyOwner Owner
propertyNo pAddress rent ownerNo ownerNo oName

PG4 6 lawrence St,Glasgow 350 CO40 CO40 Tina Murphy

PG16 5 Novar Dr, Glasgow 450 CO93 CO93 Tony Shaw

PG36 2 Manor Rd, Glasgow 370 CO93

Figure 7 2NF ClientRental relation

Boyce-Codd normal form (BCNF)
A relation is in BCNF, if and only if, every
determinant is a candidate key.

The difference between 3NF and BCNF is that for a

functional dependency A  B, 3NF allows this
dependency in a relation if B is a primary-key attribute
and A is not a candidate key, whereas BCNF insists
that for this dependency to remain in a relation, A must
be a candidate key.
fd1 clientNo, interviewDate  interviewTime, staffNo, roomNo (Primary
Key)
fd2 staffNo, interviewDate, interviewTime clientNo (Candidate key)
fd3 roomNo, interviewDate, interviewTime  clientNo, staffNo
(Candidate key)
fd4 staffNo, interviewDate  roomNo (not a candidate key)

As a consequece the ClientInterview relation may suffer from update anmalies.

For example, two tuples have to be updated if the roomNo need be changed for
staffNo SG5 on the 13-May-02.
ClientInterview
ClientNo interviewDate interviewTime staffNo roomNo
CR76 13-May-02 10.30 SG5 G101
CR76 13-May-02 12.00 SG5 G101
CR74 13-May-02 12.00 SG37 G102
CR56 1-Jul-02 10.30 SG5 G102

Figure 8 ClientInterview relation

To transform the ClientInterview relation to BCNF, we must remove
the violating functional dependency by creating two new relations
called Interview and SatffRoom as shown below,

Interview (clientNo, interviewDate, interviewTime, staffNo)

StaffRoom(staffNo, interviewDate, roomNo)

Interview
ClientNo interviewDate interviewTime staffNo
CR76 13-May-02 10.30 SG5
CR76 13-May-02 12.00 SG5
CR74 13-May-02 12.00 SG37
CR56 1-Jul-02 10.30 SG5

StaffRoom
staffNo interviewDate roomNo
SG5 13-May-02 G101
SG37 13-May-02 G102
SG5 1-Jul-02 G102

Figure 9 BCNF Interview and StaffRoom relations

Multi-valued dependency (MVD)
represents a dependency between attributes (for example, A,
B and C) in a relation, such that for each value of A there is a
set of values for B and a set of value for C. However, the set of
values for B and C are independent of each other.
A multi-valued dependency can be further defined as
being
trivial or nontrivial. A MVD A > B in relation R is
defined
as being trivial if
• B is a subset of A
or
•AUB=R
A MVD is defined as being nontrivial if neither of the above
Fourth normal form (4NF)
A relation that is in Boyce-Codd normal form and contains
no nontrivial multi-valued dependencies.
Fifth normal form (5NF)
A relation that has no join dependency.
Fifth normal form is satisfied when all
tables are broken into as many tables
as possible in order to avoid
redundancy. Once it is in fifth normal
form it cannot be broken into smaller
relations without changing the facts or
the meaning. 
 Lossless-join dependency
A property of decomposition, which ensures that
no spurious tuples are generated when relations
are reunited through a natural join operation.

 Join dependency
Describes a type of dependency. For example, for
a relation R with subsets of the attributes of R
denoted as A, B, …, Z, a relation R satisfies a join
dependency if, and only if, every legal value of R
is equal to the join of its projections on A, B, …,
Z.
 Domain Key Normal Form
(DKNF)
   The relation is in DKNF when there can be no
insertion or deletion anomalies in the
database.
The ClientRental relation has the following functional
dependencies:

fd1 clientNo, propertyNo  rentStart, rentFinish (Primary Key)

fd2 clientNo  cName (Partial dependency)
fd3 propertyNo  pAddress, rent, ownerNo, oName
(Partial dependency)
fd4 ownerNo  oName (Transitive
Dependency)
fd5 clientNo, rentStart  propertyNo, pAddress, rentFinish, rent,
ownerNo, oName (Candidate key)
fd6 propertyNo, rentStart  clientNo, cName, rentFinish (Candidate
key)
 After removing the partial dependencies, the creation of the
three new relations called Client, Rental, and PropertyOwner
Client (clientNo, cName)
Rental (clientNo, propertyNo, rentStart, rentFinish)
PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)

Client
ClientNo propertyNo rentStart rentFinish
ClientNo cName Rental
CR76 John Kay CR76 PG4 1-Jul-00 31-Aug-01
CR56 Aline Stewart CR76 PG16 1-Sep-02 1-Sep-02
CR56 PG4 1-Sep-99 10-Jun-00
CR56 PG36 10-Oct-00 1-Dec-01
PropertyOwner CR56 PG16 1-Nov-02 1-Aug-03

propertyNo pAddress rent ownerNo oName

PG4 6 lawrence St,Glasgow 350 CO40 Tina Murphy

PG16 5 Novar Dr, Glasgow 450 CO93 Tony Shaw

PG36 2 Manor Rd, Glasgow 370 CO93 Tony Shaw

2NF ClientRental relation

 All attributes are directly
 ISBN  Title or indirectly determined
 ISBN  Publisher by the primary key;
therefore, the relation is
 Publisher  Address at least in 1 NF

BOOK

ISBN Title Publisher Address

 The relation is at least in 1NF.
 ISBN  Title There is no COMPOSITE
 ISBN  Publisher primary key, therefore there
 Publisher  Address can’t be partial dependencies.
Therefore, the relation is at
least in 2NF
BOOK

ISBN Title Publisher Address

 Publisher is a non-key attribute,
 ISBN  Title and it determines Address,
another non-key attribute.
 ISBN  Publisher
Therefore, there is a transitive
 Publisher  Address dependency, which means that
the relation is NOT in 3 NF.
BOOK

ISBN Title Publisher Address

 We know that the relation is at
 ISBN  Title least in 2NF, and it is not in 3
 ISBN  Publisher NF. Therefore, we conclude
that the relation is in 2NF.
 Publisher  Address

BOOK

ISBN Title Publisher Address

 ISBN  Title In your solution you will write the
 ISBN  Publisher following justification:
 Publisher  Address 1) No M/V attributes, therefore at
least 1NF
2) No partial dependencies,
therefore at least 2NF
3) There is a transitive dependency
(Publisher  Address), therefore,
not 3NF
Conclusion: The relation is in 2NF

BOOK

ISBN Title Publisher Address

 Product_ID  Description

All attributes are directly or

indirectly determined by the
primary key; therefore, the relation
is at least in 1 NF
ORDER

Order_No Product_ID Description

 Product_ID  Description
The relation is at least in 1NF.
There is a COMPOSITE Primary Key (PK)
(Order_No, Product_ID), therefore there can be
partial dependencies. Product_ID, which is a part
of PK, determines Description; hence, there is a
partial dependency. Therefore, the relation is not
2NF. No sense to check for transitive
dependencies!

ORDER

Order_No Product_ID Description

 Product_ID  Description

We know that the relation is at least

in 1NF, and it is not in 2 NF.
Therefore, we conclude that the
relation is in 1 NF.

ORDER

Order_No Product_ID Description

 Product_ID  Description

In your solution you will write the

following justification:
1) No M/V attributes, therefore at least
1NF
2) There is a partial dependency
(Product_ID  Description), therefore
not in 2NF
Conclusion: The relation is in 1NF
ORDER

Order_No Product_ID Description

 Part_ID  Description Comp_ID and No are not
 Part_ID  Price determined by the primary
key; therefore, the relation
 Part_ID, Comp_ID  No is NOT in 1 NF. No sense
in looking at partial or
transitive dependencies.

PART

Part_ID Descr Price Comp_ID No

 In your solution you will write
 Part_ID  Description the following justification:
 Part_ID  Price 1) There are M/V attributes;
therefore, not 1NF
 Part_ID, Comp_ID  NoConclusion: The relation is not
normalized.

PART

Part_ID Descr Price Comp_ID No