0% found this document useful (0 votes)
277 views3 pages

Normalization Practice Questions & Solutions

The document discusses normalization of relations into first, second, and third normal forms (1NF, 2NF, 3NF). It provides answers to three questions that involve normalizing relations based on functional dependencies. For each question, it identifies the normal form the relation is initially in, explains any partial or transitive dependencies present, and shows how to normalize the relation to higher normal forms by decomposing tables to remove dependencies.

Uploaded by

LHK
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
277 views3 pages

Normalization Practice Questions & Solutions

The document discusses normalization of relations into first, second, and third normal forms (1NF, 2NF, 3NF). It provides answers to three questions that involve normalizing relations based on functional dependencies. For each question, it identifies the normal form the relation is initially in, explains any partial or transitive dependencies present, and shows how to normalize the relation to higher normal forms by decomposing tables to remove dependencies.

Uploaded by

LHK
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
  • Normalization Q2
  • Normalization Q1
  • Normalization Q3

Questions on Normalization

Q.1.

Answer:a. Its in 1 NF because no multi valued/composite attribute and no nested relations.

b. not in 2NF because partial dependency due to the FD, salesman#--> commission%, so
commission% is partially dependent on the primary key {car#, salesman#}

Normalizing to 2NF:

Car_Sale

car# salesman# date_sold discount_amt

Salesman

salesman# commission%

c. Still not in 3NF as there is transitive dependency, {car#, salesman#}-->


date_solddiscount_amount.

Normalizing to 3NF:

Salesman

salesman# commission%

Car_Sale

car# salesman# date_sold

Discount_Info

date_sold discount_amt
Q.2. (Book_Title is primary key)

Answer:

a. Its in 2NF. It is already in 1 NF because because no multi valued/composite attribute and no


nested relations. Also it satisfies the conditions for 2NF as there are no partial dependency on
primary key.

b. Applying 3NF because there is transitive dependency due to 2nd and 3rd FD.

Book(Book_title, Authorname, Book_type, Publisher)

Book_price_info(Book_type, List_price)

Authos (Author_name, Author_affil)

** Note: Table names are up to you, you can give any name you want, but it is preferrable to
give meaningful names as I have done above.

Q. 3.

Consider the following relational schema for a library database:

Book (Title, Author, Catalog_no, Publisher, Year, Price, bookCoverType, contractDate)


Collection (Title, Author, Catalog_no)

Assume {Author, Title} is the key for both relations

Additional functional dependencies are


I. Title,Author --> Catalog_no
II. Catalog_no --> Publisher, Year, bookCoverType
III. Publisher, bookCoverType --> Price
IV. Author --> contractDate

a. Explain what normal form the relation is in.


b. Apply normalization until the 3rd NF. State reasons behind each normalization

Answer:

a. It's in 1 NF, because no multi valued/composite attribute and no nested relations.

b. It is not in 2NF as there is partial dependency due to FD IV. Therefore normalizing to 2NF:

Collection(Title,Author,Catalog_no)
Book(Title, Author, Catalog_no, Publisher, Year, Price, bookCoverType)
Author_Info(Author, ContractDate)

Now normalizing to 3NF as there is still transitive dependency in “Book” table due to Fd II and
III.

Collection(Title,Author,Catalog_no)
Author_Info(Author, ContractDate)
Book(Title, Author, Catalog_no)
Catalog(Catalog_no, Publisher, year, bookcovertype)
Price_info(Publisher, bookcovertype, price)

**Important Note: If any attribute is not mentioned in any FD, then by default they will be
dependent on the whole primary key and therefore they should be placed in the original
[Link] given below:

Project_Grade (Project_id, Student_id, student_name, project_title, grade, submission_date,


bonus)

FD1: student_id--> student_name


FD2: project_id-->project_title
FD3: submission_date--> bonus marks

So, it is not mentioned what submission_date or grade depends on, so by default they should
be considered to be fully dependent on entire primary key {project_id, student_id}

Solution:
a. In 1NF, not multivalued/composite attribute or nested relations.
b. FD1 and FD2 cause partial dependencies so not in 2NF. Normalizing to 2NF:

Project_Grade(Project_id, Student_id, grade, submission_date, bonus)


Student(Student_id ,student_name)
Project(Project_id, project_title)

c. FD3 causes transitive dependency, so normalizing to 3NF.


Student(Student_id ,student_name)
Project(Project_id, project_title)
Project_Grade(Project_id, Student_id, grade, submission_date)
Bonus_Info(submission_date, bonus)

Common questions

Powered by AI

A partial dependency exists when a non-prime attribute is functionally dependent on part of a composite primary key rather than the whole key, preventing the table from reaching 2NF. For example, in a relation where {car#, salesman#} is a composite primary key, the dependency salesman# --> commission% is partial because commission% depends only on salesman# and not the whole key {car#, salesman#} .

When an attribute is not specified in any known functional dependency, it should be considered entirely dependent on the whole primary key. This approach is essential to maintain the integrity and consistency of the database schema, as it ensures that no part of the data is left 'floating' without clear dependency, leading to potential redundancy or inconsistencies .

Without normalization, databases often experience significant redundancy and inconsistency, leading to complex, inefficient queries that require unnecessary data processing to manage these anomalies. Over time, it impacts query performance and can lead to difficulties in data maintenance and scalability, ultimately degrading data integrity and the efficiency of data management systems .

First Normal Form (1NF) is a state of database normalization where a table has no multi-valued, composite attributes, and no nested relations . Ensuring a table is in 1NF simplifies its data structure by requiring each column to contain atomic, indivisible values.

To ensure proper documentation of functional dependencies during normalization, it's essential to systematically analyze and document all attribute relationships, leveraging tools like dependency diagrams or conceptual schema diagrams. Regularly updating this documentation as schema changes occur and engaging in peer reviews can further ensure accuracy and completeness .

To normalize a table to Third Normal Form (3NF), you must first ensure it is in 2NF and then eliminate transitive dependencies, where a non-prime attribute depends on another non-prime attribute instead of a primary key. For instance, in a table with the primary key {Title, Author} and functional dependencies Catalog_no --> Publisher, Year, bookCoverType and Publisher, bookCoverType --> Price, moving Publisher, Year, bookCoverType to a Catalog table and Publisher, bookCoverType, Price to a Price_info table eliminates these transitive dependencies, achieving 3NF .

Choosing an appropriate primary key is crucial for achieving proper normalization, as it determines the structure of functional dependencies. A well-chosen primary key minimizes partial and transitive dependencies, simplifying the normalization process. For example, in a table where both 'Title' and 'Author' are used as a composite primary key, dependencies on either attribute alone should be minimized to achieve 2NF and 3NF, fostering a clear dependency structure .

Transforming a relation from 1NF to 2NF involves ensuring that all non-prime attributes are fully functionally dependent on the primary key, eliminating any partial dependencies. This process typically requires splitting the original table into separate tables that isolate partial dependencies, associating them with only the portion of the composite key they depend on .

A table in 2NF is free of partial dependencies; all non-prime attributes are fully functionally dependent on the full primary key. However, a table in 2NF might still have transitive dependencies, where non-prime attributes depend on other non-prime attributes, risking redundancy and anomalies. Achieving 3NF eliminates transitive dependencies, ensuring all non-prime attributes depend directly on the primary key, thus reducing redundancy and potential anomalies .

Transitive dependencies lead to redundancy and update anomalies, where modifying an attribute in one tuple could necessitate multiple updates in other rows, ultimately causing data inconsistencies. Removing transitive dependencies during normalization (to 3NF) enhances data integrity and reduces redundancy by ensuring that each non-prime attribute depends directly only on the primary key .

Questions on Normalization
Q.1.
Answer:a. Its in 1 NF because no multi valued/composite attribute and no nested relations.
b.
Q.2. (Book_Title is primary key)
Answer: 
a. Its in 2NF. It is already in 1 NF because  because no multi valued/composite att
b.
Apply normalization until the 3rd NF. State reasons behind each normalization
Answer:
a. It's in 1 NF,  because no multi v

You might also like