Merge pull request #746 from Vipullakum007/dbms-docs-sec-3-4-5

Dbms docs sec 3 4 5 added

Author: ajay-dhangar

docs/DBMS/Relational Database Design/_category.json

@@ -0,0 +1,8 @@
+{
+    "label": "Relational Database Design",
+    "position": 3,
+    "link": {
+        "type": "generated-index",
+        "description": "Explore relational database design concepts, including the Relational Model, ER modeling, normalization, and more."
+    }
+}

docs/DBMS/Relational Database Design/dbms-joins.md

@@ -0,0 +1,123 @@
+---
+id: dbms-joins
+title: DBMS - Joins
+sidebar_label: DBMS Joins
+sidebar_position: 2
+description: Explore different types of joins in database management systems and their applications.
+---
+
+DBMS - Joins
+---
+
+Joins in database management systems allow us to combine data from multiple tables based on specified conditions. Let's explore various types of joins:
+
+Theta (θ) Join
+---
+
+Theta join combines tuples from different relations based on a given theta condition denoted by the symbol θ. It can use various comparison operators.
+
+```mermaid
+graph TD;
+    A[Student] -->|Std| B[Subjects]
+    B -->|Class| C[Student_Detail]
+```
+
+Example of Theta Join:
+```plaintext
+Student
+SID   Name    Std
+101   Alex    10
+102   Maria   11
+
+Subjects
+Class  Subject
+10     Math
+10     English
+11     Music
+11     Sports
+
+Student_Detail
+SID   Name    Std   Class  Subject
+101   Alex    10    10     Math
+101   Alex    10    10     English
+102   Maria   11    11     Music
+102   Maria   11    11     Sports
+```
+
+Equijoin
+---
+
+Equijoin is a type of theta join where only equality comparison operators are used. It matches tuples based on equal values of attributes.
+
+Natural Join (⋈)
+---
+
+Natural join combines tuples from two relations based on common attributes with the same name and domain. It does not use any comparison operator.
+
+Example of Natural Join:
+```mermaid
+graph TD;
+    A[Courses] -->|Dept| B[HoD]
+```
+
+Result of Natural Join:
+```plaintext
+Courses ⋈ HoD
+Dept  CID    Course      Head
+CS    CS01   Database    Alex
+ME    ME01   Mechanics   Maya
+EE    EE01   Electronics Mira
+```
+
+Outer Joins
+---
+
+Outer joins include all tuples from participating relations, even if there are no matching tuples.
+
+Left Outer Join (R Left Outer Join S)
+---
+
+```plaintext
+Left
+A    B
+100  Database
+101  Mechanics
+102  Electronics
+
+Right
+A    B
+100  Alex
+102  Maya
+104  Mira
+
+Courses Left Outer Join HoD
+A    B          C    D
+100  Database   100  Alex
+101  Mechanics  ---  ---
+102  Electronics 102  Maya
+```
+
+Right Outer Join (R Right Outer Join S)
+---
+
+```plaintext
+Courses Right Outer Join HoD
+A    B          C    D
+100  Database   100  Alex
+102  Electronics 102 Maya
+---  ---        104  Mira
+```
+
+Full Outer Join (R Full Outer Join S)
+---
+
+```plaintext
+Courses Full Outer Join HoD
+A    B          C    D
+100  Database   100  Alex
+101  Mechanics  ---  ---
+102  Electronics 102  Maya
+---  ---        104  Mira
+```
+
+These joins are crucial for combining data effectively from multiple tables in database systems.

docs/DBMS/Relational Database Design/dbms-normalization.md

@@ -0,0 +1,115 @@
+---
+id: dbms-normalization
+title: DBMS - Normalization
+sidebar_label: Normalization
+sidebar_position: 1
+description: Learn about Functional Dependency, Normalization, and different Normal Forms in Database Management Systems (DBMS).
+---
+
+# DBMS - Normalization
+
+## Functional Dependency
+
+Functional dependency (FD) is a set of constraints between two attributes in a relation. Functional dependency says that if two tuples have the same values for attributes A1, A2,..., An, then those two tuples must have the same values for attributes B1, B2, ..., Bn.
+
+Functional dependency is represented by an arrow sign (→) that is, $X \rightarrow Y$, where X functionally determines Y. The left-hand side attributes determine the values of attributes on the right-hand side.
+
+### Armstrong's Axioms
+
+If F is a set of functional dependencies then the closure of F, denoted as F+, is the set of all functional dependencies logically implied by F. Armstrong's Axioms are a set of rules, that when applied repeatedly, generates a closure of functional dependencies.
+
+```mermaid
+graph TD;
+    A["alpha"] -->|is_subset_of| B["beta"]
+    B -->|alpha holds beta| C["alpha holds beta"]
+    A -->|augmentation rule| D["ay → by also holds"]
+    C -->|transitivity rule| E["a → c also holds"]
+```
+
+## Trivial Functional Dependency
+
+- **Trivial:** If a functional dependency (FD) X → Y holds, where Y is a subset of X, then it is called a trivial FD. Trivial FDs always hold.
+
+- **Non-trivial:**  If an FD X → Y holds, where Y is not a subset of X, then it is called a non-trivial FD.
+
+- **Completely non-trivial:**  If an FD X → Y holds, where x intersect Y = Φ, it is said to be a completely non-trivial FD.
+
+## Normalization
+
+If a database design is not perfect, it may contain anomalies, which are like a bad dream for any database administrator. Managing a database with anomalies is next to impossible.
+
+- **Update anomalies** − If data items are scattered and are not linked to each other properly, then it could lead to strange situations. For example, when we try to update one data item having its copies scattered over several places, a few instances get updated properly while a few others are left with old values. Such instances leave the database in an inconsistent state.
+
+- **Deletion anomalies** − We tried to delete a record, but parts of it was left undeleted because of unawareness, the data is also saved somewhere else.
+
+- **Insert anomalies** − We tried to insert data in a record that does not exist at all.
+
+Normalization is a method to remove all these anomalies and bring the database to a consistent state.
+
+```mermaid
+graph TD;
+    A[Update anomalies] -->|Inconsistent state| B[Database]
+    C[Deletion anomalies] -->|Left undeleted parts| B
+    D[Insert anomalies] -->|Insert data in non-existing record| B
+```
+
+## First Normal Form (1NF)
+
+First Normal Form is defined in the definition of relations (tables) itself. This rule defines that all the attributes in a relation must have atomic domains. The values in an atomic domain are indivisible units.
+
+unorganized relation
+
+```mermaid
+graph TD;
+    A["Relation"] -->|Unorganized| B["1NF"]
+```
+
+Each attribute must contain only a single value from its pre-defined domain.
+
+## Second Normal Form (2NF)
+
+Before we learn about the second normal form, we need to understand the following −
+
+- **Prime attribute :** An attribute, which is a part of the candidate-key, is known as a prime attribute.
+
+- **Non-prime attribute :** An attribute, which is not a part of the prime-key, is said to be a non-prime attribute.
+
+```mermaid
+graph TD;
+    A["Candidate Key"] -->|Part of| B["Prime Attribute"]
+    C["Non-Prime Attribute"] -->|Not part of| A
+    D["X → A holds"] -->|No subset Y → A| E["Second Normal Form"]
+```
+
+## Third Normal Form (3NF)
+
+For a relation to be in Third Normal Form, it must be in Second Normal form and the following must satisfy −
+
+No non-prime attribute is transitively dependent on the prime key attribute.
+
+```mermaid
+graph TD;
+    A["X → A"] -->|Superkey or A is prime| B["Third Normal Form"]
+    C["Transitive Dependency"] -->|Stu_ID → Zip → City| D["Relation not in 3NF"]
+```
+
+## Boyce-Codd Normal Form (BCNF)
+
+BCNF is an extension of Third Normal Form on strict terms. BCNF states that −
+
+For any non-trivial functional dependency, X → A, X must be a super-key.
+
+```mermaid
+graph TD;
+    A["X → A"] -->|X is super-key| B["BCNF"]
+```
+
+In the above image, Stu_ID is the super-key in the relation Student_Detail and Zip is the super-key in the relation ZipCodes. So,
+```
+Stu_ID → Stu_Name, Zip
+```
+and
+```
+Zip → City
+```
+Which confirms that both the relations are in BCNF.

docs/DBMS/Relational-Model/_category.json

@@ -0,0 +1,9 @@
+{
+    "label": "Relational Model",
+    "position": 2,
+    "link": {
+      "type": "generated-index",
+      "description": "Explore the Relational Model in DBMS, its concepts, and its applications."
+    }
+  }
+  

docs/DBMS/Relational-Model/codd's-rule.md

@@ -0,0 +1,116 @@
+---
+id: codd-s-12-rules
+title: Codd's 12 Rules
+sidebar_label: Codd's 12 Rules
+sidebar_position: 1
+description: Explore Dr. Edgar F. Codd's 12 Rules for true relational databases with examples and diagrams.
+---
+
+# DBMS - Codd's 12 Rules
+
+Dr. Edgar F. Codd, after his extensive research on the Relational Model of database systems, came up with twelve rules of his own, which according to him, a database must obey in order to be regarded as a true relational database.
+
+## Rule 1: Information Rule
+
+The data stored in a database, may it be user data or metadata, must be a value of some table cell. Everything in a database must be stored in a table format.
+
+### Example:
+
+Consider a database for a library. The Information Rule ensures that every piece of data, like the title of a book or the name of an author, is stored within a specific table cell, such as the 'Book Title' attribute in the 'Books' table.
+
+## Rule 2: Guaranteed Access Rule
+
+Every single data element (value) is guaranteed to be accessible logically with a combination of table-name, primary-key (row value), and attribute-name (column value). No other means, such as pointers, can be used to access data.
+
+### Example:
+
+In a customer database, the Guaranteed Access Rule ensures that you can access a specific customer's details using their unique customer ID, such as querying "SELECT \* FROM Customers WHERE CustomerID = '123'".
+
+## Rule 3: Systematic Treatment of NULL Values
+
+The NULL values in a database must be given a systematic and uniform treatment. This is a very important rule because a NULL can be interpreted as one of the following − data is missing, data is not known, or data is not applicable.
+
+### Example:
+
+In an employee database, the Systematic Treatment of NULL Values ensures that if an employee's middle name is unknown or not applicable, it's represented as NULL in the database rather than an empty string or a placeholder.
+
+## Rule 4: Active Online Catalog
+
+The structure description of the entire database must be stored in an online catalog, known as data dictionary, which can be accessed by authorized users. Users can use the same query language to access the catalog which they use to access the database itself.
+
+### Example:
+
+An Active Online Catalog provides metadata about the database schema. For instance, it includes information about tables, columns, data types, and relationships, allowing users to understand and query the database structure.
+
+```mermaid
+erDiagram
+    CAT_TABLE ||--o{ DB_TABLE : has
+    CAT_TABLE ||--o{ COLUMN : has
+    DB_TABLE ||--o{ COLUMN : contains
+    DB_TABLE }|..|{ DATA : stores
+```
+
+## Rule 5: Comprehensive Data Sub-Language Rule
+
+A database can only be accessed using a language having linear syntax that supports data definition, data manipulation, and transaction management operations. This language can be used directly or by means of some application. If the database allows access to data without any help of this language, then it is considered as a violation.
+
+### Example:
+
+SQL (Structured Query Language) is a comprehensive data sub-language that fulfills the requirements of data definition, manipulation, and transaction management. It allows users to interact with the database through standard commands like SELECT, INSERT, UPDATE, DELETE, and COMMIT.
+
+## Rule 6: View Updating Rule
+
+All the views of a database, which can theoretically be updated, must also be updatable by the system.
+
+### Example:
+
+Consider a view that combines data from multiple tables for reporting purposes. The View Updating Rule ensures that if the view includes columns from a single base table, those columns can be updated through the view.
+
+## Rule 7: High-Level Insert, Update, and Delete Rule
+
+A database must support high-level insertion, updation, and deletion. This must not be limited to a single row, that is, it must also support union, intersection and minus operations to yield sets of data records.
+
+### Example:
+
+The High-Level Insert, Update, and Delete Rule allows you to insert, update, or delete multiple rows at once. For instance, you can use an SQL statement like "DELETE FROM Employees WHERE Salary < 50000" to delete all employees with a salary below $50,000.
+
+## Rule 8: Physical Data Independence
+
+The data stored in a database must be independent of the applications that access the database. Any change in the physical structure of a database must not have any impact on how the data is being accessed by external applications.
+
+### Example:
+
+Physical Data Independence allows you to modify the storage structures (like changing indexes or file organization) without affecting how users and applications interact with the data. This ensures that applications remain functional even if the database undergoes structural changes.
+
+## Rule 9: Logical Data Independence
+
+The logical data in a database must be independent of its user’s view (application). Any change in logical data must not affect the applications using it. For example, if two tables are merged or one is split into two different tables, there should be no impact or change on the user application. This is one of the most difficult rules to apply.
+
+### Example:
+
+Imagine merging two tables 'Customers' and 'Suppliers' into a single table 'Partners'. Logical Data Independence ensures that existing applications accessing 'Customers' or 'Suppliers' continue to function seamlessly after the merge.
+
+## Rule 10: Integrity Independence
+
+A database must be independent of the application that uses it. All its integrity constraints can be independently modified without the need of any change in the application. This rule makes a database independent of the front-end application and its interface.
+
+### Example:
+
+Integrity constraints like primary keys, foreign keys, and unique constraints can be modified or added without affecting how applications interact with the database. This allows for changes in data validation rules without altering application logic.
+
+## Rule 11: Distribution Independence
+
+The end-user must not be able to see that the data is distributed over various locations. Users should always get the impression that the data is located at one site only. This rule has been regarded as the foundation of distributed database systems.
+
+### Example:
+
+In a distributed database, data may be stored across multiple physical locations. Distribution Independence ensures that users perceive and interact with the data as if it's stored in a single location, regardless of its actual distribution.
+
+## Rule 12: Non-Subversion Rule
+
+If a system has an interface that provides access to low-level records, then the interface must not be able to subvert the system and bypass security and integrity constraints.
+
+### Example:
+
+The Non-Subversion Rule prevents unauthorized access to low-level records or system components that could compromise security or integrity. It ensures that access controls and security measures are enforced, even through direct interfaces.
+