Module_3 Notes

Informal Design Guidelines for Relation Schemas

These guidelines help in designing a clean, logical, and efficient relational schema.

1. Avoiding Redundancy

Redundancy in relation schemas leads to data anomalies and wastage of storage space. There
are three types of anomalies that occur due to redundancy:

 Insertion Anomaly: Difficulty in inserting data without additional unrelated

information.
 Deletion Anomaly: Deleting one piece of information unintentionally removes other
important data.
 Update Anomaly: Updating multiple occurrences of the same data becomes
inconsistent.

Example of Redundancy Issue:

Consider the relation:

2. Ensuring Minimal Data Loss (Lossless Decomposition)

When decomposing a relation into smaller relations, ensure that the original data can be
reconstructed without loss.

 Bad Decomposition Example:

If we split Employee(Employee_ID, Employee_Name, Department,
Dept_Location) into:
1. Employee(Employee_ID, Employee_Name)
2. Department(Department, Dept_Location)

❌ This decomposition loses the relationship between Employee_ID and Department.

 Good Decomposition Example:

1. Employee(Employee_ID, Employee_Name, Department)
2. Department(Department, Dept_Location)

❌ This preserves all necessary information and relationships.

3. Avoiding Null Values

Schemas should be designed to minimize the presence of NULL values, as they can:

 Cause difficulty in query processing.

 Lead to ambiguous interpretations.
  Waste storage space.

Example:

Employee_ID Name Phone_Number Office_Location

101 Alice 9876543210 New York
102 Bob NULL NULL

🔹 Solution:

 Separate optional attributes into another relation.

 Example:
1. Employee(Employee_ID, Name)
2. Employee_Details(Employee_ID, Phone_Number, Office_Location)

4. Ensuring Meaningful Attribute Names

Attribute names should be clear, meaningful, and self-explanatory to avoid confusion.

 Bad Example: A1, B2, C3

 Good Example: Employee_ID, Employee_Name, Department_Name

Using meaningful names improves database readability and maintainability.

Functional Dependency (FD) in ADBMS

1. Introduction to Functional Dependency:

Functional Dependency (FD) is a constraint between two sets of attributes in a relation from a
database.

If X → Y, it means that the value of attribute X uniquely determines the value of attribute Y.

Example:
If we know a student's ID, we can find their name:

Student_ID → Student_Name

This means that for each Student_ID, there is exactly one corresponding Student_Name.
2. Why is Functional Dependency Important?

Functional dependencies are critical for database design and normalization. They help:

❌ Reduce redundancy
❌ Maintain data accuracy
❌ Avoid anomalies (update, insert, delete)
❌ Design normalized, efficient tables

3. Types of Functional Dependencies

3.1 Trivial Functional Dependency

A dependency is trivial if the dependent attribute is already included in the
determinant.

If Y ⊆ X, then X → Y is trivial.

Example:
{Employee_ID, Employee_Name} → Employee_ID

3.2 Non-Trivial Functional Dependency

A dependency is non-trivial if the dependent attribute is not a part of the
determinant.

If Y is not a subset of X, then X → Y is non-trivial.

Example:
Employee_ID → Employee_Name

3.3 Multivalued Dependency

A multivalued dependency occurs when one attribute determines a set of multiple
values of another attribute, independently of other attributes.

Written as: X →→ Y

Example:
Student_ID →→ Course

This means a student can be enrolled in multiple courses independently of other attributes.

3.4 Transitive Dependency

 A transitive dependency occurs when:

 X→Y
 Y→Z
 Then X → Z is also true.

Example:
Employee_ID → Department_ID
Department_ID → Department_Name
⇒ Employee_ID → Department_Name

Transitive dependencies should be removed in 3NF.

3.5 Partial Dependency

A partial dependency exists when:

 A non-key attribute depends on only part of a composite key.

Example:
Table: {Student_ID, Course_ID} → Student_Name

 Course_ID alone does not determine Student_Name

 But Student_ID does ⇒ partial dependency

Partial dependencies are removed in 2NF.

Functional Dependency in Normalization

Functional Dependencies are core to the process of normalization, which is the restructuring of
tables to reduce data redundancy and improve integrity.

Uses:
 Identify and remove partial dependencies (2NF)
 Eliminate transitive dependencies (3NF)
 Ensure all determinants are keys (BCNF)

By analyzing functional dependencies, we decide how to break up large, redundant tables into
smaller, more efficient ones.

Normal Forms Based on Primary Keys

(With detailed explanation and examples for 1NF, 2NF, 3NF, and BCNF)
🔷 What are Normal Forms?

Normalization is the process of organizing data in a relational database to:

 Remove redundancy (repeated data)

 Eliminate anomalies (insert, update, delete problems)
 Ensure data integrity and efficiency

Each Normal Form (NF) builds upon the previous one and is based on the concept of functional
dependencies and primary keys.

1 First Normal Form (1NF):

A relation is in 1NF if:

 All attributes (columns) contain only atomic (indivisible) values

 There are no repeating groups or arrays

Example – Not in 1NF:

 The Subjects column contains multiple values → violates 1NF

Converted to 1NF:
Now each attribute contains only one value per row → in 1NF

Characteristics:

 All attributes must have atomic (indivisible) values.

 Each column contains only one value per row (no repeating groups or arrays).
 Each record is unique, and each field contains only scalar values.
2. Second Normal Form (2NF):

A relation is in 2NF if:

 It is already in 1NF, and

 Every non-prime attribute is fully functionally dependent on the whole primary key

A partial dependency exists if a non-key attribute depends on only part of a composite key.

Example – Not in 2NF:

 Composite Primary Key: (SSN, Pnumber)

 Ename depends only on SSN, not the full key → Partial dependency → violates 2NF
 Pname and Plocation depends only on Pnumber, not the full key → Partial dependency →
violates 2NF

Converted to 2NF:

Now, all non-key attributes depend on the whole key, not part of it → in 2NF

Characteristics:

 No partial dependency: All non-prime attributes (not part of a candidate key) must
be fully functionally dependent on the entire primary key.
 Applies mainly to tables with composite primary keys.
3. Third Normal Form (3NF):

A relation is in 3NF if:

 It is in 2NF, and
 It has no transitive dependencies

A transitive dependency is when non-prime attribute A depends on another non-prime attribute

B, and B depends on the primary key.

Example – Not in 3NF:

Dependencies:

 Dname, Dmgr_ssn → Dnumber

 Dnumber → Ssn
 So, Dname, , Dmgr_ssn → Ssn→ Transitive dependency → violates 3NF

Converted to 3NF:

Characteristics:

 No transitive dependencies: A non-prime attribute should not depend on another

non-prime attribute.
 Every non-prime attribute must depend only on the primary key.

4. Boyce-Codd Normal Form (BCNF):

A relation is in BCNF if:

 For every functional dependency X → Y, X is a super key.

Stronger version of 3NF.
If a relation is in 3NF but has multiple overlapping candidate keys, it might still violate BCNF.

Example – Not in BCNF:

Dependencies:

 Area → Property_id
 County_name → Area

Here, County_name → Area , but Area is not a candidate key → violates BCNF

Converted to BCNF:

Now, all FDs have determinants as super keys → in BCNF

Transaction Processing & ACID Properties in DBMS

What is a Transaction?:

A transaction in a database is a sequence of one or more SQL operations (like SELECT, INSERT,
UPDATE, DELETE) that are executed as a single unit of work.

Either all operations in a transaction succeed (COMMIT), or none do (ROLLBACK).

Examples of Transactions:
 Transferring money between two bank accounts
 Registering a student for a course
 Updating a student's marks
ACID Properties

ACID stands for:

 Atomicity
 Consistency
 Isolation
 Durability

These are the key principles that ensure a transaction is processed reliably.

Atomicity: Transactions are "all or nothing." If any part fails, the whole transaction is rolled
back.

Example: Bank transfer: If debiting fails, crediting is canceled.

Consistency: The Database must be consistent before and after the transaction.

Example: If a transaction deducts money from an account, the total balance across all other
accounts should remain unchanged.

Isolation: Transactions run independently, without interfering with each other.

Example:Two users can't purchase the same last item in stock.

Durability: Once a transaction is committed, changes are permanent, even after a system
crash.

Example:After payment, the transaction's effect (e.g., funds transfer) is saved permanently.