Why functional dependencies guide schema design in DBMS Theory - Test Your Understanding

Practice - 5 Tasks

1fill in blank

easy

Complete the SQL query to select the attribute that functionally determines others.

DBMS Theory

SELECT [1] FROM Employees;

Drag options to blanks, or click blank then click option'

ADepartment

BSalary

CEmployeeID

DAge

Attempts:

3 left

💡 Hint

Common Mistakes

Choosing an attribute that is not unique, like Salary or Department.

The EmployeeID uniquely identifies each employee, so it functionally determines other attributes.

2fill in blank

medium

Complete the SQL query to find rows where the functional dependency might be violated.

DBMS Theory

SELECT EmployeeID, Department FROM Employees WHERE Department [1] 'Sales';

Drag options to blanks, or click blank then click option'

A<>

B=

C>

D<

Attempts:

3 left

💡 Hint

Common Mistakes

Using '=' which selects only Sales department employees.

We want to find employees not in the Sales department to check if the dependency holds, so we use <> (not equal).

3fill in blank

hard

Fix the error in the SQL query that checks functional dependency violations.

DBMS Theory

SELECT [1], COUNT(*) FROM Employees GROUP BY [1] HAVING COUNT(*) > 1;

Drag options to blanks, or click blank then click option'

ASalary

BEmployeeID

CDepartment

DAge

Attempts:

3 left

💡 Hint

Common Mistakes

Grouping by non-unique attributes like Department or Salary.

Grouping by EmployeeID helps find duplicates violating uniqueness, which breaks functional dependency.

4fill in blank

hard

Fill both blanks to create a query that finds attributes functionally dependent on EmployeeID.

DBMS Theory

SELECT EmployeeID, [1] FROM Employees WHERE [2] = 'HR';

Drag options to blanks, or click blank then click option'

ASalary

BDepartment

CEmployeeID

DAge

Attempts:

3 left

💡 Hint

Common Mistakes

Using EmployeeID in the WHERE clause instead of Department.

Salary depends on EmployeeID, and we filter by Department = 'HR' to check functional dependency within HR.

5fill in blank

hard

Fill all three blanks to create a query that checks for functional dependency violations by counting duplicates.

DBMS Theory

SELECT [1], [2], COUNT(*) FROM Employees GROUP BY [3] HAVING COUNT(*) > 1;

Drag options to blanks, or click blank then click option'

AEmployeeID

BDepartment

CEmployeeID, Department

DSalary

Attempts:

3 left

💡 Hint

Common Mistakes

Grouping by only one attribute when two are needed.

Select EmployeeID and Department, group by both to find duplicates violating functional dependency.

Practice

1. What is the main reason functional dependencies are important in database schema design?

easy

A. They replace the need for primary keys

B. They speed up database queries automatically

C. They allow storing data in a single large table

D. They help organize data to avoid duplication and errors

Solution

1. Step 1: Understand functional dependencies

   Functional dependencies show how one attribute or set of attributes determines another attribute in a table.

2. Step 2: Connect to schema design

   Using these dependencies helps split tables to reduce duplication and avoid data inconsistencies.

3. Final Answer:

   They help organize data to avoid duplication and errors -> Option D

4. Quick Check:

   Functional dependencies guide clean design = They help organize data to avoid duplication and errors [OK]

Hint: Functional dependencies prevent data repetition and errors [OK]

Common Mistakes:

• Thinking functional dependencies speed up queries directly
• Believing all data should be in one table
• Confusing functional dependencies with keys

2. Which of the following is the correct way to express a functional dependency?

easy

A. A + B means A and B are combined

B. A -> B means A functionally determines B

C. A = B means A equals B

D. A * B means A multiplies B

Solution

1. Step 1: Recall functional dependency notation

   Functional dependency is written as A -> B, meaning A determines B.

2. Step 2: Check other options

   Other options show arithmetic or equality, not functional dependencies.

3. Final Answer:

   <code>A -> B</code> means A functionally determines B -> Option B

4. Quick Check:

   Functional dependency symbol = -> [OK]

Hint: Look for arrow (->) to show functional dependency [OK]

Common Mistakes:

• Confusing functional dependency with equality
• Using arithmetic symbols instead of ->
• Misreading notation as assignment

3. Given a table with attributes StudentID, CourseID, Instructor and the functional dependency CourseID -> Instructor, what does this imply?

medium

A. Each CourseID is taught by exactly one Instructor

B. Each Instructor teaches multiple CourseIDs

C. StudentID determines Instructor

D. Instructor determines CourseID

Solution

1. Step 1: Interpret the functional dependency

   CourseID -> Instructor means for each CourseID, there is one Instructor assigned.

2. Step 2: Understand implication

   This means each course has exactly one instructor, but an instructor can teach many courses.

3. Final Answer:

   Each CourseID is taught by exactly one Instructor -> Option A

4. Quick Check:

   CourseID determines Instructor = Each CourseID is taught by exactly one Instructor [OK]

Hint: Left side determines right side in functional dependency [OK]

Common Mistakes:

• Assuming Instructor determines CourseID
• Confusing StudentID with CourseID
• Thinking one instructor per student

4. A table has attributes OrderID, ProductID, Quantity, Price with functional dependencies OrderID, ProductID -> Quantity and ProductID -> Price. Which of the following is a problem in this design?

medium

A. Price depends only on ProductID, causing redundancy if repeated for each order

B. Quantity depends on OrderID only, which is incorrect

C. OrderID determines Price, which violates functional dependency rules

D. ProductID and Quantity together determine OrderID, which is wrong

Solution

1. Step 1: Analyze functional dependencies

   OrderID, ProductID -> Quantity means quantity depends on both order and product, which is correct.

2. Step 2: Identify redundancy issue

   ProductID -> Price means price depends only on product, so storing price in the order table repeats it many times.

3. Final Answer:

   Price depends only on ProductID, causing redundancy if repeated for each order -> Option A

4. Quick Check:

   Price repeated per order causes redundancy = Price depends only on ProductID, causing redundancy if repeated for each order [OK]

Hint: Check if attribute depends on full key or causes repetition [OK]

Common Mistakes:

• Ignoring redundancy caused by partial dependencies
• Mixing up which attribute depends on what
• Assuming all dependencies are correct

5. You have a table Employee(ID, Name, Dept, DeptHead) with functional dependencies ID -> Name, Dept and Dept -> DeptHead. How should you redesign the schema to avoid redundancy?

hard

A. Remove DeptHead from the schema entirely

B. Keep one table but add DeptHead as a primary key

C. Split into two tables: Employee(ID, Name, Dept) and Department(Dept, DeptHead)

D. Combine Dept and DeptHead into one attribute in Employee table

Solution

1. Step 1: Identify functional dependencies

   ID -> Name, Dept means employee ID determines name and department; Dept -> DeptHead means department determines its head.

2. Step 2: Apply normalization

   To avoid repeating DeptHead for every employee in the same department, split into two tables: one for employees and one for departments with heads.

3. Final Answer:

   Split into two tables: Employee(ID, Name, Dept) and Department(Dept, DeptHead) -> Option C

4. Quick Check:

   Separate tables for dependent attributes = Split into two tables: Employee(ID, Name, Dept) and Department(Dept, DeptHead) [OK]

Hint: Split tables where one attribute depends on another non-key attribute [OK]

Common Mistakes:

• Trying to keep all data in one table causing redundancy
• Misusing primary keys for dependent attributes
• Removing important data like DeptHead