0% found this document useful (0 votes)
3 views

Hastar_Rdbms

Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
3 views

Hastar_Rdbms

Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

What is normalization?

Normalization is the process of organizing data in a database to reduce redundancy and


improve data integrity. It involves dividing a large table into smaller, related tables and
defining relationships between them. The main goals of normalization are:

- Eliminating redundant data

- Ensuring data dependencies make sense

Explain insert, update, and delete anomalies with examples


**Insert Anomaly:**

Occurs when you cannot insert data into a table without including unrelated data.

Example:

A table storing student and course information:

| Student_ID | Student_Name | Course_ID | Course_Name |

|------------|---------------|-----------|-------------|

| 101 | Alice | CSE101 | DBMS |

| 102 | Bob | NULL | NULL |

*Problem:* If a new course is introduced but no students are enrolled yet, you cannot insert
it without assigning a student.

**Update Anomaly:**

Occurs when data duplication requires multiple rows to be updated when a single piece of
information changes.

Example:

In the same table, if the course name "DBMS" is changed to "Database Systems," all rows
containing "DBMS" need to be updated.

*Problem:* High chance of inconsistencies if one row is missed during an update.

**Delete Anomaly:**

Occurs when deleting a row causes unintended loss of data.


Example:

If a student drops out and their record is deleted, the course information may also be lost if
it’s the only record for that course.

What is 1NF?
**First Normal Form (1NF):**

A table is in 1NF if:

- Each column contains atomic (indivisible) values.

- Each column contains values of a single type.

- Each row is unique.

**Example:**

| Student_ID | Student_Name | Course |

|------------|---------------|--------|

| 101 | Alice | DBMS |

| 102 | Bob | Math |

What is 2NF?
**Second Normal Form (2NF):**

A table is in 2NF if:

- It is in 1NF.

- All non-key attributes are fully functionally dependent on the primary key.

**Example:**

Consider a table with partial dependency:

| Student_ID | Course_ID | Course_Name | Instructor |

|------------|-----------|-------------|------------|

| 101 | CSE101 | DBMS | Prof. A |


*Solution:* Split into two tables:

1. **Student Table:**

| Student_ID | Course_ID |

|------------|-----------|

| 101 | CSE101 |

2. **Course Table:**

| Course_ID | Course_Name | Instructor |

|-----------|-------------|------------|

| CSE101 | DBMS | Prof. A |

What is the need for normalization?


**Need for Normalization:**

1. Eliminates Data Redundancy: Reduces the storage of duplicate data.

2. Improves Data Integrity: Ensures data consistency and accuracy.

3. Facilitates Easy Data Maintenance: Simplifies updates and deletion processes.

4. Reduces Anomalies: Prevents insert, update, and delete anomalies.

5. Better Data Organization: Makes database structure more logical and easier to
understand.

What is functional dependency?


**Functional Dependency (FD):**

A functional dependency (FD) is a relationship between attributes in a relational database.


It specifies that the value of one attribute (or a group of attributes) uniquely determines the
value of another attribute.

**Notation:**

If an attribute Y is functionally dependent on attribute X, it is denoted as:

X→Y

This means: If two rows have the same value for X, they must also have the same value for Y.
**Example:**

| Student_ID | Course_ID | Instructor |

|------------|------------|------------|

| 101 | CSE101 | Prof. A |

**Functional Dependencies:**

- Student_ID → Student_Name: Knowing a student's ID uniquely identifies their name.

- Course_ID → Instructor: Each course is taught by one instructor.

**Types of Functional Dependencies:**

1. **Trivial Functional Dependency:** When the dependent attribute is a subset of the


determinant.

2. **Non-Trivial Functional Dependency:** When the dependent attribute is not a subset of


the determinant.

3. **Composite Functional Dependency:** When a set of attributes together determines


another attribute.

Difference between 3NF and BCNF


**Difference between 3rd Normal Form (3NF) and Boyce-Codd Normal Form (BCNF):**

| Aspect | 3rd Normal Form (3NF) | Boyce-Codd Normal Form


(BCNF) |

|-----------------------|------------------------------------------------------|--------------------------------------
-------------------|

| Definition | A table is in 3NF if it is in 2NF and all non-prime attributes are fully
functionally dependent on the primary key. | A table is in BCNF if it is in 3NF and, for every
functional dependency X → Y, X is a superkey. |

| Dependency Condition | Allows functional dependencies where the determinant is a non-


prime attribute as long as no transitive dependency exists. | Does not allow any functional
dependency where the determinant is not a superkey. |
| Focus | Eliminates transitive dependencies. | Eliminates all anomalies
caused by functional dependencies. |

| Complexity | Less strict than BCNF. | More strict than 3NF, leading to
further decomposition. |

| Handling Redundancy | Redundancy might still exist in some cases. | Guarantees


minimal redundancy by enforcing stricter rules. |

| Dependency Example | Table may have X → Y where X is not a superkey, but it's okay if Y
is a non-prime attribute. | Table must have X → Y only if X is a superkey. |

| Use Case | Commonly used in practical scenarios due to easier application. | Used
when 3NF does not remove all redundancies or anomalies.

What is lossy and lossless join?


**Lossless Join:**

A lossless join ensures that no data is lost or altered when tables are decomposed and then
recombined (joined). After the join, you get back the original table with all its data intact.

**Key Points:**

- Data Integrity: Preserves the original data.

- Condition: For a decomposition to be lossless, at least one of the common attributes in the
decomposed tables should be a superkey.

**Example:**

Given a table Employee:

| Emp_ID | Name | Dept_ID | Dept_Name |

|--------|-------|---------|-----------|

| 101 | Alice | D1 | HR |

Decompose it into two tables:

1. Employee_Info:

| Emp_ID | Name | Dept_ID |


|--------|-------|---------|

| 101 | Alice | D1 |

2. Department:

| Dept_ID | Dept_Name |

|---------|-----------|

| D1 | HR |

Joining on Dept_ID will reconstruct the original table. This is a lossless join.

**Lossy Join:**

A lossy join results in the loss of information or the introduction of spurious (incorrect) data
when tables are joined.

**Key Points:**

- Data Integrity: Compromised, as some data is lost or incorrect data appears.

**Example:**

Given a table Course_Info:

| Student_ID | Course_ID | Instructor |

|------------|------------|------------|

|1 | CSE101 | Prof. A |

Decompose into two tables:

1. Student_Course:

| Student_ID | Course_ID |

|------------|------------|
|1 | CSE101 |

2. Instructor_Course:

| Course_ID | Instructor |

|-----------|------------|

| CSE101 | Prof. A |

If you join these tables without considering constraints, multiple incorrect combinations of
students and instructors could appear, leading to a lossy join.

You might also like