Hastar_Rdbms
Hastar_Rdbms
Occurs when you cannot insert data into a table without including unrelated data.
Example:
|------------|---------------|-----------|-------------|
*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.
**Delete Anomaly:**
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):**
**Example:**
|------------|---------------|--------|
What is 2NF?
**Second Normal Form (2NF):**
- It is in 1NF.
- All non-key attributes are fully functionally dependent on the primary key.
**Example:**
|------------|-----------|-------------|------------|
1. **Student Table:**
| Student_ID | Course_ID |
|------------|-----------|
| 101 | CSE101 |
2. **Course Table:**
|-----------|-------------|------------|
5. Better Data Organization: Makes database structure more logical and easier to
understand.
**Notation:**
X→Y
This means: If two rows have the same value for X, they must also have the same value for Y.
**Example:**
|------------|------------|------------|
**Functional Dependencies:**
|-----------------------|------------------------------------------------------|--------------------------------------
-------------------|
| 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. |
| Complexity | Less strict than BCNF. | More strict than 3NF, leading to
further decomposition. |
| 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.
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:**
- Condition: For a decomposition to be lossless, at least one of the common attributes in the
decomposed tables should be a superkey.
**Example:**
|--------|-------|---------|-----------|
| 101 | Alice | D1 | HR |
1. Employee_Info:
| 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:**
**Example:**
|------------|------------|------------|
|1 | CSE101 | Prof. A |
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.