0% found this document useful (0 votes)
20 views14 pages

Database Management System-Unit-5 Notes

The document states that the training data is current up to October 2023. It implies that any information or developments after this date may not be included. This sets a clear temporal boundary for the data's relevance.

Uploaded by

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

Database Management System-Unit-5 Notes

The document states that the training data is current up to October 2023. It implies that any information or developments after this date may not be included. This sets a clear temporal boundary for the data's relevance.

Uploaded by

udccssanthiya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOC, PDF, TXT or read online on Scribd
You are on page 1/ 14

UNIT - V

RELATIONAL DATABASE DESIGN

1. Features of Good Relational Design


A well-structured relational database design improves data organization, integrity, and
performance. Below are 10 key features that contribute to a good relational database design:

1. Eliminate Redundancy
o Data duplication increases storage cost and maintenance effort.

o Solution: Normalize tables using First Normal Form (1NF), Second Normal
Form (2NF), and Third Normal Form (3NF).
2. Ensure Data Integrity
o Use Primary Keys to uniquely identify records.

o Use Foreign Keys to maintain referential integrity between tables.

o Apply constraints like NOT NULL, UNIQUE, and CHECK to ensure data validity.

3. Normalize Data
o Organize data into multiple related tables to avoid update anomalies.

o Example: Splitting an "Employees" table into "Employees" and "Departments"


prevents storing department names repeatedly.
4. Optimize Query Performance
o Use indexes on frequently searched columns.

o Optimize queries with joins, subqueries, and indexing techniques.

o Example: Adding an index to Employee_ID speeds up searches in an


"Employees" table.
5. Ensure Scalability
o The database should support increased data volume without performance issues.

o Design the schema to accommodate new features without major changes.

6. Support Transaction Management


o Use ACID (Atomicity, Consistency, Isolation, Durability) principles for
transactions.
o Ensures no data loss during system failures.

7. Maintain Security and Access Control


o Implement user roles and privileges to restrict unauthorized access.

o Encrypt sensitive information like passwords and financial records.

8. Minimize Data Redundancy with Proper Relationships


o Establish one-to-one (1:1), one-to-many (1:M), and many-to-many (M:N)
relationships properly.
o Example: An "Orders" table should reference a "Customers" table instead of
storing customer details multiple times.
9. Use Consistent Naming Conventions
o Follow clear and meaningful names for tables and columns.

o Example: Use customer_id instead of id to avoid confusion.

10. Backup and Recovery Mechanisms

 Implement regular database backups to prevent data loss.


 Example: Use MySQL’s mysqldump command for periodic backups.

2. Atomic Domains and First Normal Form (1NF)


A table is in 1NF if:

 Each column contains atomic values (no multiple values in one cell).
 Each row is unique (identified by a primary key).
 No repeating groups of columns.

Example Table (Unnormalized Form - UNF)

Student_I Name Courses Phone Numbers


D
101 Alex Math, Science 12345, 67890
102 Emma English, History 54321, 98765

Conversion to 1NF

Student_I Name Course Phone Number


D
101 Alex Math 12345
101 Alex Science 67890
102 Emma English 54321
102 Emma History 98765

CREATE TABLE Student (


Student_ID INT PRIMARY KEY,
Name VARCHAR(50)
);

CREATE TABLE Enrollments (


Student_ID INT,
Course VARCHAR(50),
FOREIGN KEY (Student_ID) REFERENCES Student(Student_ID)
);

CREATE TABLE Contact (


Student_ID INT,
Phone_Number VARCHAR(15),
FOREIGN KEY (Student_ID) REFERENCES Student(Student_ID)
);

3. Decomposition Usingv Functional Dependencies


What is Functional Dependency?

A functional dependency (FD) is a relationship where the value of one attribute uniquely
determines another.

🔹 Example: Student_ID → Name (Each Student_ID maps to a unique Name).

Why Decomposition?

Decomposition is done to remove redundancy and ensure normalization (2NF, 3NF, BCNF).

Example: Decomposing a Table (2NF & 3NF)

🔴 Before Decomposition (Not in 2NF)

This table violates 2NF because Customer_Name depends only on Customer_ID, not Order_ID.

Order_ID Product Customer_ID Customer_Name


1 Laptop 1001 John
2 Phone 1002 Sarah
3 Keyboard 1001 John
✅ After Decomposition (2NF & 3NF Applied)

🔹 Orders Table (Order_ID → Product, Customer_ID)

Order_ID Product Customer_ID


1 Laptop 1001
2 Phone 1002
3 Keyboard 1001

🔹 Customers Table (Customer_ID → Customer_Name)

Customer_ID Customer_Name
1001 John
1002 Sarah

SQL Implementation
CREATE TABLE Customers (
Customer_ID INT PRIMARY KEY,
Customer_Name VARCHAR(50)
);

CREATE TABLE Orders (


Order_ID INT PRIMARY KEY,
Product VARCHAR(50),
Customer_ID INT,
FOREIGN KEY (Customer_ID) REFERENCES Customers(Customer_ID)
);

Benefits of Decomposition

✅ Reduces Redundancy – Customer names are stored only once.


✅ Ensures Data Integrity – Changes in Customer_Name don’t require updates in multiple
places.
✅ Improves Query Performance – Joins are more efficient on smaller tables.

This decomposition ensures the database is in Third Normal Form (3NF) and follows good
relational design

4. Functional Dependency Theory


What is Functional Dependency (FD)?

Functional Dependency (FD) defines a relationship between attributes in a table where the value
of one attribute uniquely determines another.

Example:

 Student_ID → Name (Each Student_ID determines a unique Name).

FDs are crucial for database normalization, helping remove redundancy and ensuring data
integrity.

Types of Functional Dependencies

1. Trivial Functional Dependency

📌 Definition: A dependency is trivial if the dependent attribute is a subset of the determinant.

🔹 Example:

 A → A (Always true).
 {Student_ID, Name} → Name (Since Name is already part of {Student_ID, Name}, it is
trivial).

✅ Does not help in database design, as it holds by definition.

2.Non-Trivial Functional Dependency

📌 Definition: A dependency is non-trivial if the dependent attribute is not a subset of the


determinant.

🔹 Example:

 Student_ID → Name (Each Student_ID uniquely determines Name).


 Order_ID → Order_Date (Order_ID determines the date of the order).

✅ Useful for database design to ensure consistency.

3. Transitive Dependency

📌 Definition: If A → B and B → C, then A → C is a transitive dependency.

🔹 Example (Bad Design - Not in 3NF):


Employee_ID Department_ID Department_Name
101 D1 HR
102 D2 Finance
 Employee_ID → Department_ID
 Department_ID → Department_Name

 Therefore, Employee_ID → Department_Name (Transitive Dependency)

✅ To achieve 3NF, separate the Department into a new table.

Importance of Functional Dependency in Normalization

✔ Helps in eliminating redundancy


✔ Reduces data anomalies (update, insert, delete anomalies)
✔ Ensures efficient storage and data integrity

5. Decomposition Using Multivalued Dependencies (MVDs)


What is a Multivalued Dependency (MVD)?

A Multivalued Dependency (MVD) exists when one attribute determines multiple


independent values of another, without a direct relationship between them.

🔹 Example:

 A student can enroll in multiple courses.


 A student can also have multiple phone numbers.

 Courses and phone numbers are independent of each other, leading to an MVD.

📌 Notation: If A →→ B, then for each value of A, there exist multiple values of B, independent of
other attributes.

Why is MVD a Problem?

🔴 Before 4NF (Single Table - Redundancy Present)

Student_ID Course Phone Number


101 Math 12345
101 Science 67890
101 Math 55555

👉 Here, Student_ID →→ Course and Student_ID →→ Phone Number exist independently,


causing redundancy.
👉 If a student changes their phone number, we must update multiple rows, leading to update
anomalies.

Solution: Decomposition Using 4NF

🔹 4NF (Separate Tables for Each Independent MVD)

✅ Student_Courses Table (Student_ID →→ Course)

Student_ID Course
101 Math
101 Science

✅ Student_Contacts Table (Student_ID →→ Phone Number)

Student_ID Phone Number


101 12345
101 67890
101 55555

👉 Now, courses and phone numbers are stored independently, preventing redundancy and
anomalies.

6. More Normal Forms (2NF, 3NF, BCNF, 4NF, 5NF)


Normalization is a process that removes data redundancy and anomalies by organizing tables
into normal forms.

1st Normal Form (1NF) - Basic Table Structure


📌 Rules:
✔ Ensure atomic values (each cell contains a single value).
✔ Remove repeating groups (no multiple values in a single column).

🔹 Example (Before 1NF - Not Atomic)

Order_ID Product Customer_ID


1 Laptop, Mouse 1001
2 Phone 1002

🔹 After 1NF (Atomic Values - Separate Rows)

Order_ID Product Customer_ID


1 Laptop 1001
1 Mouse 1001
2 Phone 1002

2nd Normal Form (2NF) - Remove Partial Dependencies


📌 Rules:
✔ Must be in 1NF.
✔ No partial dependencies (Every column should depend on the entire primary key).

🔹 Example (Before 2NF - Partial Dependency)

Order_ID Product Customer_ID Customer_Name


1 Laptop 1001 John
2 Phone 1002 Sarah

🔴 Issue: Customer_Name depends on Customer_ID, not Order_ID.


✅ Fix: Separate Customers table.

🔹 After 2NF (Decomposed Tables)


✔ Orders Table:

Order_ID Product Customer_ID


1 Laptop 1001
2 Phone 1002

✔ Customers Table:

Customer_ID Customer_Name
1001 John
1002 Sarah

3rd Normal Form (3NF) - Remove Transitive Dependencies


📌 Rules:
✔ Must be in 2NF.
✔ No transitive dependencies (Non-key attributes should depend only on the primary key).

🔹 Example (Before 3NF - Transitive Dependency)

Employee_ID Department_ID Department_Name


101 D1 HR
102 D2 Finance
🔴 Issue:

 Employee_ID → Department_ID
 Department_ID → Department_Name

 Transitive Dependency: Employee_ID → Department_Name

✅ Fix: Create a Departments table.

🔹 After 3NF (Decomposed Tables)


✔ Employees Table:

Employee_ID Department_ID
101 D1
102 D2

✔ Departments Table:

Department_ID Department_Name
D1 HR
D2 Finance

Boyce-Codd Normal Form (BCNF) - Stronger than 3NF


📌 Rules:
✔ Must be in 3NF.
✔ Every determinant must be a candidate key.

🔹 Example (Before BCNF - Multiple Candidate Keys)

Student_I Course Instructor


D
101 Math Prof. A
101 Science Prof. B

🔴 Issue:

 Course → Instructor but Course is not a candidate key.


 Fix: Split into two tables.

🔹 After BCNF (Decomposed Tables)


✔ Student_Courses Table:
Student_I Course
D
101 Math
101 Science

✔ Course_Instructor Table:

Course Instructor
Math Prof. A
Science Prof. B

4th Normal Form (4NF) - Remove Multivalued


Dependencies
📌 Rules:
✔ Must be in BCNF.
✔ No Multivalued Dependencies (MVDs).

🔹 Example (Before 4NF - MVD Present)

Student_I Course Phone Number


D
101 Math 12345
101 Science 67890
101 Math 55555

🔴 Issue:

 Student_ID →→ Course
 Student_ID →→ Phone Number

 Courses and Phone Numbers are independent but stored together.

✅ Fix: Split into separate tables.

✔ Student_Courses Table:

Student_I Course
D
101 Math
101 Science

✔ Student_Contacts Table:
Student_I Phone Number
D
101 12345
101 67890
101 55555

5th Normal Form (5NF) - Remove Join Dependencies


📌 Rules:
✔ Must be in 4NF.
✔ Eliminates unnecessary joins while preserving data integrity.

🔹 Example (Before 5NF - Join Dependency Exists)

Project_ID Employee_ID Role


P1 E1 Developer
P1 E2 Tester
P2 E1 Manager

🔴 Issue: If new roles or assignments exist, the table can become hard to maintain.

✅ Fix: Break into multiple tables.

✔ Projects Table:

Project_ID Employee_ID
P1 E1
P1 E2
P2 E1

✔ Roles Table:

Employee_ID Role
E1 Developer
E2 Tester
E1 Manager

✅ Summary of Normal Forms

Normal Form Fixes


1NF Atomic values, no repeating groups
2NF No partial dependencies
3NF No transitive dependencies
BCNF Every determinant must be a candidate key
4NF No multivalued dependencies
5NF No unnecessary join dependencies

Database-Design Process
The database design process consists of several steps to create an efficient and well-structured
database. It ensures data integrity, minimizes redundancy, and optimizes performance. The key
steps are:

1. Requirements Analysis

📌 Objective: Gather and analyze data requirements from stakeholders.


✔ Identify the purpose of the database (e.g., banking, e-commerce, healthcare).
✔ Collect information on entities, attributes, and relationships.
✔ Define functional requirements (queries, reports, constraints).

💡 Example:
A university database requires details about students, courses, and enrollments.

2. Conceptual Design (ER Model)

📌 Objective: Create an Entity-Relationship (ER) Model to visually represent the database.


✔ Identify entities (Students, Courses, Professors).
✔ Define relationships (Students enroll in Courses).
✔ Draw an ER diagram with primary keys and cardinality constraints.

💡 Example ER Diagram:

 Student (Student_ID, Name, Age)


 Course (Course_ID, Course_Name, Credits)
 Enrollment (Student_ID, Course_ID, Semester)

3. Logical Design (Relational Model)

📌 Objective: Convert the ER model into a relational schema.


✔ Define tables, attributes, primary keys, and foreign keys.
✔ Apply Normalization (1NF, 2NF, 3NF, BCNF, etc.) to avoid redundancy.

💡 Example (Relational Schema):

CREATE TABLE Student (


Student_ID INT PRIMARY KEY,
Name VARCHAR(100),
Age INT
);

CREATE TABLE Course (


Course_ID INT PRIMARY KEY,
Course_Name VARCHAR(100),
Credits INT
);

CREATE TABLE Enrollment (


Student_ID INT,
Course_ID INT,
Semester VARCHAR(10),
PRIMARY KEY (Student_ID, Course_ID),
FOREIGN KEY (Student_ID) REFERENCES Student(Student_ID),
FOREIGN KEY (Course_ID) REFERENCES Course(Course_ID)
);

4. Physical Design

📌 Objective: Optimize storage, indexing, and security for the database.


✔ Choose a database management system (DBMS) (MySQL, PostgreSQL, Oracle).
✔ Define indexes for faster query performance.
✔ Implement data storage, security policies, and backup strategies.

💡 Example:
Creating an index for faster lookup on Student_ID:

CREATE INDEX idx_student ON Student(Student_ID);

5. Implementation

📌 Objective: Develop and populate the database in the chosen DBMS.


✔ Create tables based on the relational schema.
✔ Insert data into tables using SQL queries.
✔ Write stored procedures, triggers, and views for business logic.

💡 Example (Inserting Data):

INSERT INTO Student (Student_ID, Name, Age) VALUES (101, 'Alice', 20);
INSERT INTO Course (Course_ID, Course_Name, Credits) VALUES (C1, 'Database
Systems', 3);
INSERT INTO Enrollment (Student_ID, Course_ID, Semester) VALUES (101, C1,
'Spring 2025');

6. Testing & Refinement


📌 Objective: Test database functionality and optimize performance.
✔ Run sample queries to ensure correct results.
✔ Check for data integrity constraints violations.
✔ Improve performance by tuning indexes and queries.

💡 Example (Query for Students Enrolled in ‘Database Systems’):

SELECT Student.Name
FROM Student
JOIN Enrollment ON Student.Student_ID = Enrollment.Student_ID
JOIN Course ON Enrollment.Course_ID = Course.Course_ID
WHERE Course.Course_Name = 'Database Systems';

7. Maintenance & Security

📌 Objective: Ensure the database remains secure, updated, and optimized.


✔ Implement user access controls and permissions.
✔ Set up regular backups to prevent data loss.
✔ Monitor performance and security threats.

💡 Example (Creating a Read-Only User):

CREATE USER 'readonly_user'@'localhost' IDENTIFIED BY 'password';


GRANT SELECT ON UniversityDB.* TO 'readonly_user'@'localhost';

You might also like