Auto saved by Logseq
This commit is contained in:
parent
e6c9ac81ab
commit
459829ff4a
|
@ -1088,7 +1088,7 @@
|
|||
- First Normal Form (1NF): :-> This is the most basic level of
|
||||
id:: 648974ba-7334-4e73-a0ae-6b8fc6ec99ab
|
||||
normalization. In 1NF, each table cell should contain _only a single value, and each column should have a unique name_. The first normal form helps to eliminate duplicate data and simplify queries.
|
||||
- Second Normal Form (2NF): :-> 2NF eliminates redundant data by requiring that each _non-key attribute_ be dependent on the primary key. This means that _each column should be directly related to the primary key_, and not to other
|
||||
- Second Normal Form (2NF): :-> 2NF eliminates redundant data by requiring that each _non-key attribute_ be ==dependent on the primary key==. This means that _each column should be directly related to the primary key_, and not to other
|
||||
id:: 648974ba-cc9e-4cdf-a312-3af1bcab23f2
|
||||
columns.
|
||||
- Third Normal Form (3NF): :-> 3NF builds on 2NF by requiring
|
||||
|
@ -1099,7 +1099,7 @@
|
|||
- Fourth Normal Form (4NF): 4NF is a further refinement of BCNF that ensures that _a table does not contain any multi-valued dependencies._
|
||||
- Fifth Normal Form (5NF): 5NF is the highest level of normalization and involves decomposing a table into smaller tables to _remove data redundancy and improve data integrity._
|
||||
- Anomaly
|
||||
- Update Anomalies
|
||||
- Update Anomalies #flashcard
|
||||
- Insertion anomalies
|
||||
- If there is a new row inserted in the table and it creates the
|
||||
inconsistency in the table then it is called the insertion anomaly. For
|
||||
|
@ -1107,7 +1107,20 @@
|
|||
it is not allocated to any department then we cannot insert it in the
|
||||
table so, it will create an insertion anomaly.
|
||||
- Deletion anomalies
|
||||
- If we delete some rows from the table and if any other information or
|
||||
data which is required is also deleted from the database, this is called
|
||||
the deletion anomaly in the database. For example, in the above table,
|
||||
if we want to delete the department number ECT669 then the details of
|
||||
Rajesh will also be deleted since Rajesh's details are dependent on the
|
||||
row of ECT669. So, there will be deletion anomalies in the table.
|
||||
- Modification anomalies
|
||||
- When we update some rows in the table, and if it leads to the
|
||||
inconsistency of the table then this anomaly occurs. This type of
|
||||
anomaly is known as an updation anomaly. In the above table, if we want
|
||||
to update the address of Ramesh then we will have to update all the rows
|
||||
where Ramesh is present. If during the update we miss any single row,
|
||||
then there will be two addresses of Ramesh, which will lead to
|
||||
inconsistent and wrong databases.
|
||||
- LATER Block 4
|
||||
- DONE Distributed DBMS
|
||||
- DONE client server arch #flashcard
|
||||
|
|
Loading…
Reference in a new issue