Upload
kanagavalli-narayanan
View
45
Download
0
Embed Size (px)
Citation preview
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.
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 Third Normal Form (3NF)- 2 NF plus no transitive dependencies Boyce-Codd Normal Form (BCNF) Fourth Normal Form (4NF) Fifth Normal Form (5NF) Domain Key Normal Form (DKNF)
Levels of Normalization R
edundancy
Num
ber
of T
able
s
Com
plex
ity
Levels of Normalization
Each higher level is a subset of the lower level Each higher level is a subset of the lower level
DKNF
1NF
2NF
3NF
4NF
5NF
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).
ClientNo cName propertyNo pAddress rentStart rentFinish rent ownerNo oName
CR76John
kay
PG4
PG16
6 lawrence
St,Glasgow
5 Novar Dr,
Glasgow
1-Jul-00
1-Sep-02
31-Aug-01
1-Sep-02
350
450
CO40
CO93
Tina Murphy
Tony Shaw
CR56Aline
Stewart
PG4
PG36
PG16
6 lawrence
St,Glasgow
2 Manor Rd,
Glasgow
5 Novar Dr,
Glasgow
1-Sep-99
10-Oct-00
1-Nov-02
10-Jun-00
1-Dec-01
1-Aug-03
350
370
450
CO40
CO93
CO93
Tina Murphy
Tony Shaw
Tony Shaw
Repeating group = (propertyNo, pAddress, rentStart, rentFinish, rent, ownerNo, oName)
TitleTitle Author1Author1 AuthorAuthor22
ISBNISBN SubjectSubject PagesPages PublisherPublisher
Database Database System System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
Henry Henry F. KorthF. Korth
00729588630072958863 MySQL, MySQL, ComputersComputers
11681168 McGraw-HillMcGraw-Hill
Operating Operating System System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
Henry Henry F. KorthF. Korth
04716946650471694665 ComputersComputers 944944 McGraw-HillMcGraw-Hill
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 table2. 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.
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
Composite Primary Key
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_COURSE
Stud_ID Course Units
101 MSI 250 3
101 MSI 415 3
125 MSI 331 3
STUDENT
Stud_ID Name
101 Lennon
125 Jonson
Table 2
TitleTitle AuthorAuthor ISBNISBN SubjectSubject PagesPages PublisherPublisher
Database System Database System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
00729588630072958863 MySQLMySQL 11681168 McGraw-HillMcGraw-Hill
Database System Database System ConceptsConcepts
Henry F. KorthHenry F. Korth 00729588630072958863 ComputersComputers 11681168 McGraw-HillMcGraw-Hill
Operating System Operating System ConceptsConcepts
Henry F. KorthHenry F. Korth 04716946650471694665 ComputersComputers 944944 McGraw-HillMcGraw-Hill
Operating System Operating System ConceptsConcepts
Abraham Abraham SilberschatzSilberschatz
04716946650471694665 ComputersComputers 944944 McGraw-HillMcGraw-Hill
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:
ClientNopropertyNo
cNamepAddress
rentStart rentFinish rent ownerNo oName
CR76 PG4John
Kay
6 lawrence
St,Glasgow1-Jul-00 31-Aug-01 350 CO40
Tina Murphy
CR76 PG16John
Kay
5 Novar Dr,
Glasgow1-Sep-02 1-Sep-02 450 CO93
Tony Shaw
CR56 PG4Aline
Stewart
6 lawrence
St,Glasgow1-Sep-99 10-Jun-00 350 CO40
Tina Murphy
CR56 PG36Aline
Stewart
2 Manor Rd,
Glasgow10-Oct-00 1-Dec-01 370 CO93
Tony Shaw
CR56 PG16Aline
Stewart
5 Novar Dr,
Glasgow1-Nov-02 1-Aug-03 450 CO93
Tony Shaw
ClientNo
cName
CR76 John Kay
CR56Aline Stewart
ClientNo
propertyNo
pAddress
rentStart
rentFinish
rent
ownerNo
oName
CR76 PG4
6 lawrence
St,Glasgow
1-Jul-0031-Aug-01
350
CO40Tina Murphy
CR76 PG165 Novar Dr,
Glasgow
1-Sep-02
1-Sep-02450
CO93Tony Shaw
CR56 PG4
6 lawrence
St,Glasgow
1-Sep-99
10-Jun-00
350
CO40Tina Murphy
CR56 PG362 Manor Rd,
Glasgow
10-Oct-00
1-Dec-01370
CO93Tony Shaw
CR56 PG165 Novar Dr,
Glasgow
1-Nov-02
1-Aug-03450
CO93Tony 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_IDSubject_ID SubjectSubject
11 MySQLMySQL
22 ComputersComputers
Author_IDAuthor_ID Last Last NameName
First First NameName
11 SilberschSilberschatzatz
AbrahamAbraham
22 KorthKorth HenryHenry
ISBNISBN TitleTitle PagesPages PublisherPublisher
00729588007295886363
Database Database System System ConceptsConcepts
11681168 McGraw-HillMcGraw-Hill
04716946047169466565
Operating Operating System System ConceptsConcepts
944944 McGraw-HillMcGraw-Hill
Subject Table
Author Table
Book Table
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
ISBNISBN Author_IDAuthor_ID
00729588630072958863 11
00729588630072958863 22
04716946650471694665 11
04716946650471694665 22
ISBNISBN Subject_IDSubject_ID
00729588630072958863 11
00729588630072958863 22
04716946650471694665 22
Book_Author Table
Book_Subject Table
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 AB 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.
CUSTOMER
Cust_ID Name Order_ID
101 AT&T 1234
101 AT&T 156
125 Cisco 1250
Partial Dependency
Transitive Dependency – when a non-key attribute determines another non-key attribute.
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Transitive Dependency
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.
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 key5. AuAddress functionally depends on AuId which is a
subset of a key
Second Normal Form (2NF)
Example 2 (Not 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
Second Normal Form (2NF)
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}
2NF - Decomposition
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_IDPublisher_ID Publisher NamePublisher Name
11 McGraw-HillMcGraw-Hill
ISBNISBN TitleTitle PagesPages Publisher_IDPublisher_ID
00729588630072958863 Database System Database System ConceptsConcepts
11681168 11
04716946650471694665 Operating System Operating System ConceptsConcepts
944944 11
Publisher Table
Book Table
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
Composite Primary Key
Goal: Remove Partial Dependencies
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
Composite Primary Key
Partial Dependencies
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
CUSTOMER
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_COURSE
Stud_ID Course_ID
101 MSI 250
101 MSI 415
125 MSI 331
COURSE
Course_ID Units
MSI 250 3.00
MSI 415 3.00
MSI 331 3.00
STUDENT
Stud_ID Name
101 Lennon
101 Lennon
125 Johnson
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.
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
Transitive Dependency
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
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID
111 Mary Jones 1
122 Sarah Smith 2
EMPLOYEE
Emp_ID F_Name L_Name Dept_ID Dept_Name
111 Mary Jones 1 Acct
122 Sarah Smith 2 Mktg
DEPARTMENT
Dept_ID Dept_Name
1 Acct
2 Mktg
The functional dependencies for the Client, Rental and PropertyOwner relations are as follows:
Clientfd2 clientNo cName (Primary Key)
Rentalfd1 clientNo, propertyNo rentStart, rentFinish (Primary Key)fd5 clientNo, rentStart propertyNo, rentFinish (Candidate key)fd6 propertyNo, rentStart clientNo, rentFinish (Candidate key)
PropertyOwnerfd3 propertyNo pAddress, rent, ownerNo, oName (Primary Key)fd4 ownerNo oName (Transitive Dependency)
The resulting 3NF relations have the forms:
Client (clientNo, cName)Rental (clientNo, propertyNo, rentStart, rentFinish)PropertyOwner (propertyNo, pAddress, rent, ownerNo)Owner (ownerNo, oName)
ClientNo cNameCR76 John Kay
CR56 Aline Stewart
ClientClientNo propertyNo rentStart rentFinishCR76 PG4 1-Jul-00 31-Aug-01
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
Rental
propertyNo pAddress rent ownerNo
PG4 6 lawrence St,Glasgow 350 CO40
PG16 5 Novar Dr, Glasgow 450 CO93
PG36 2 Manor Rd, Glasgow 370 CO93
PropertyOwner
ownerNo oName
CO40 Tina Murphy
CO93 Tony Shaw
Owner
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.
ClientNo interviewDate interviewTime staffNo roomNoCR76 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
ClientInterview
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)
ClientNo interviewDate interviewTime staffNoCR76 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
staffNo interviewDate roomNoSG5 13-May-02 G101
SG37 13-May-02 G102
SG5 1-Jul-02 G102
Interview
StaffRoom
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• A U B = R
A MVD is defined as being nontrivial if neither of the above twoconditions is satisfied.
Fourth normal form (4NF) A relation that is in Boyce-Codd normal form and containsno 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 dependencyA property of decomposition, which ensures that no spurious tuples are generated when relations are reunited through a natural join operation.
Join dependencyDescribes 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.
The relation is in DKNF when there can be no insertion or deletion anomalies in the database.
Domain Key Normal Form (DKNF)
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
ClientNo cNameCR76 John Kay
CR56 Aline Stewart
ClientClientNo propertyNo rentStart rentFinishCR76 PG4 1-Jul-00 31-Aug-01CR76 PG16 1-Sep-02 1-Sep-02CR56 PG4 1-Sep-99 10-Jun-00CR56 PG36 10-Oct-00 1-Dec-01CR56 PG16 1-Nov-02 1-Aug-03
Rental
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
PropertyOwner
Client (clientNo, cName)Rental (clientNo, propertyNo, rentStart, rentFinish)PropertyOwner (propertyNo, pAddress, rent, ownerNo, oName)
2NF ClientRental relation
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
All attributes are directly or indirectly determined
by the primary key; therefore, the relation is
at least in 1 NF
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
The relation is at least in 1NF. There is no COMPOSITE
primary key, therefore there can’t be partial dependencies.
Therefore, the relation is at least in 2NF
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
Publisher is a non-key attribute, and it determines Address, another non-key attribute.
Therefore, there is a transitive dependency, which means that
the relation is NOT in 3 NF.
ISBN Title ISBN Publisher Publisher Address
BOOK
ISBN Title Publisher Address
We know that the relation is at least in 2NF, and it is not in 3 NF. Therefore, we conclude that the relation is in 2NF.
ISBN Title ISBN Publisher Publisher
Address
BOOK
ISBN Title Publisher Address
In your solution you will write the following justification:
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 3NFConclusion: The relation is in 2NF
Product_ID Description
ORDER
Order_No Product_ID Description
All attributes are directly or indirectly determined by the
primary key; therefore, the relation is at least in 1 NF
Product_ID Description
ORDER
Order_No 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!
Product_ID Description
ORDER
Order_No 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.
Product_ID Description
ORDER
Order_No 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 2NFConclusion: The relation is in 1NF
PART
Part_ID Descr Price Comp_ID No
Part_ID Description Part_ID Price Part_ID, Comp_ID No
Comp_ID and No are not determined by the primary key; therefore, the relation is NOT in 1 NF. No sense
in looking at partial or transitive dependencies.
Part_ID Description Part_ID Price Part_ID, Comp_ID No
PART
Part_ID Descr Price Comp_ID No
In your solution you will write the following justification:
1) There are M/V attributes; therefore, not 1NF
Conclusion: The relation is not normalized.