Why functional dependencies guide schema design in DBMS Theory - See It in Action

Understanding Functional Dependencies in Schema Design

📖 Scenario: You are designing a simple database for a small bookstore. You want to organize the data so that it is easy to manage and avoids mistakes like duplicate or inconsistent information.

🎯 Goal: Build a small database table and use functional dependencies to understand how to organize the data properly.

📋 What You'll Learn

Create a table with columns for BookID, Title, Author, and Publisher

Define a functional dependency that BookID determines Title and Author

Add a configuration variable to represent the primary key

Write a query to check the uniqueness of BookID

💡 Why This Matters

🌍 Real World

Functional dependencies help organize data so that each piece of information is stored only once, avoiding mistakes and making updates easier.

💼 Career

Understanding functional dependencies is key for database design roles, ensuring data integrity and efficient storage in real-world applications.

1

Create the Books table

Create a table called Books with columns BookID (integer), Title (text), Author (text), and Publisher (text).

DBMS Theory

-- Your code here to create the Books table

Hint

Use the CREATE TABLE statement with the specified columns and data types.

2

Define the primary key

Add a primary key constraint on the BookID column in the Books table to represent the functional dependency that BookID determines Title and Author.

DBMS Theory

CREATE TABLE Books (
    BookID INT,
    Title TEXT,
    Author TEXT,
    Publisher TEXT,
    -- Add primary key constraint on BookID
);

Hint

Add PRIMARY KEY after the BookID INT declaration.

3

Insert sample data

Insert three rows into the Books table with these exact values: (1, 'The Great Gatsby', 'F. Scott Fitzgerald', 'Scribner'), (2, '1984', 'George Orwell', 'Secker & Warburg'), and (3, 'To Kill a Mockingbird', 'Harper Lee', 'J.B. Lippincott & Co.').

DBMS Theory

CREATE TABLE Books (
    BookID INT PRIMARY KEY,
    Title TEXT,
    Author TEXT,
    Publisher TEXT
);
-- Insert sample data here

Hint

Use INSERT INTO Books (BookID, Title, Author, Publisher) VALUES (...), (...), (...); with the exact values.

4

Query to check uniqueness of BookID

Write a SQL query to select BookID and count how many times each BookID appears in the Books table, grouping by BookID. This helps verify the functional dependency that BookID is unique.

DBMS Theory

CREATE TABLE Books (
    BookID INT PRIMARY KEY,
    Title TEXT,
    Author TEXT,
    Publisher TEXT
);

INSERT INTO Books (BookID, Title, Author, Publisher) VALUES
(1, 'The Great Gatsby', 'F. Scott Fitzgerald', 'Scribner'),
(2, '1984', 'George Orwell', 'Secker & Warburg'),
(3, 'To Kill a Mockingbird', 'Harper Lee', 'J.B. Lippincott & Co.');

-- Write query to count BookID occurrences

Hint

Use SELECT BookID, COUNT(*) AS Count FROM Books GROUP BY BookID; to check uniqueness.

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