Why functional dependencies guide schema design in DBMS Theory - Performance Analysis

Time Complexity: Why functional dependencies guide schema design

O(n)

Understanding Time Complexity

We want to understand how the time to check or use functional dependencies changes as the data grows.

How does the work needed to keep data consistent grow when the table gets bigger?

Scenario Under Consideration

Analyze the time complexity of checking a functional dependency in a table.

-- Check if attribute B functionally depends on A in table T
SELECT A, COUNT(DISTINCT B) AS distinct_B
FROM T
GROUP BY A
HAVING COUNT(DISTINCT B) > 1;
    

This query finds if any value of A maps to more than one value of B, violating the dependency A -> B.

Identify Repeating Operations

Look at what repeats as the table size grows.

• Primary operation: Scanning all rows in the table to group by A.
• How many times: Once over all rows, but grouping requires comparing and counting values per group.

How Execution Grows With Input

As the number of rows grows, the database must process more data to group and count.

Input Size (n)	Approx. Operations
10	About 10 rows scanned and grouped
100	About 100 rows scanned and grouped
1000	About 1000 rows scanned and grouped

Pattern observation: The work grows roughly in direct proportion to the number of rows.

Final Time Complexity

Time Complexity: O(n)

This means the time to check the functional dependency grows linearly with the number of rows.

Common Mistake

[X] Wrong: "Checking functional dependencies is instant no matter the data size."

[OK] Correct: The database must look at all rows to be sure, so more data means more work.

Interview Connect

Understanding how data size affects dependency checks helps you design efficient databases and explain your reasoning clearly.

Self-Check

"What if the table had an index on attribute A? How would that change the time complexity of checking the 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