Normalization Consolidated 2003

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.