📚 Basic Database Concepts

🔹 What is Data?
Definition:
Data is a collection of raw facts and figures that alone have no
meaning.
Example:
"Raheem", "CS101", "95" – These are data values.

🔹 What is Information?
Definition:
Information is processed data that is meaningful and useful.
Example:
If we combine the above data:
“Raheem scored 95 marks in course CS101” — this is information.

🔹 What is a Database?
Definition:
A database is an organized collection of data that can be easily accessed,
managed, and updated.
Think of a database as an electronic filing cabinet.

🔸 Examples of Databases:
Application Data Stored
School Management Students, Teachers, Courses
Bank System Accounts, Transactions, Customers
E-commerce Website Products, Orders, Users
🔹 What is a Database Management System (DBMS)?
Definition:
A DBMS is software that interacts with users, applications, and the
database itself to capture and analyze data.
It allows users to create, read, update, and delete data in a database
(CRUD operations).

🔸 Examples of DBMS:
 Microsoft Access

 MySQL

 Oracle

 PostgreSQL

 SQLite

 SQL Server

🔹 Functions of a DBMS:
Function Description
Data Storage Stores data efficiently
Data Retrieval Quickly find data using queries
Data Manipulation Add, update, delete data
Security Control access using permissions and roles
Backup and Recovery Prevent data loss in case of system failure
Concurrency Control Allow multiple users to access data safely

🔹 Advantages of DBMS:
1. Reduced Data Redundancy
2. Improved Data Integrity and Accuracy
3. Data Security
4. Data Consistency
5. Backup and Recovery Features
6. Easier Data Access and Sharing
🔹 Disadvantages of DBMS:
1. High Cost of Software and Hardware
2. Complexity in Setup and Maintenance
3. Requires Trained Personnel
4. Risk of System Failure (if not managed properly)

🔹 Key Components of a Database System:

Component Description
Data The actual values stored
Hardware Physical devices (servers, storage)
Software DBMS and related programs
Users People who interact with the system
Procedures Rules and instructions for using the database

🔹 Types of Users in DBMS:

User Type Role Description
Manages database structure, security,
Database Admin
backups
Application
Writes code to interact with DB
Programmer
End User Uses applications to access database
System Analyst Designs and plans database systems

🔹 Real-Life Analogy
Imagine a library:
 Books = Data

 Bookshelf system = Database

 Librarian = DBMS

 Library members = Users

A DBMS ensures books are organized, retrievable, and protected — just

like your data.
🆚 Database Approach vs. File-Based System

🔹 1. File-Based System

📘 Definition
A file-based system stores data in individual files. Each application
creates and manages its own data files directly, without a centralized
system.
It was commonly used before DBMS became popular.

📁 Example
Imagine a school system:
 students.txt — stores student data

 courses.txt — stores course details

 marks.txt — stores marks

Each file is managed by a separate program.

🔸 Problems in File-Based System

Problem Description
Data Redundancy Same data stored in multiple files
Data
Redundant data may not match across files
Inconsistency
No Data Sharing Each file is isolated; difficult to share data
Lack of Security No centralized control of access and privacy
Must write separate programs to retrieve or update
Difficult Access
data
Integrity Issues No validation or rules across multiple files
🔹 2. Database Approach (DBMS)

📗 Definition
In the database approach, data is stored in a centralized database
managed by a Database Management System (DBMS). Multiple
applications can access the same database in a controlled and efficient
way.
It removes redundancy, ensures consistency, and supports data sharing.

🗂️ Example
In a school DBMS, data for students, courses, and marks are stored in
tables that are related and managed by one software like MySQL or
Oracle.

✅ Features of Database Approach

 Centralized control of data

 Multi-user access

 Improved security

 Efficient querying using SQL

 Data consistency and integrity rules

 Backup and recovery tools

🔄 Key Differences: File-Based System vs. Database Approach

Feature File-Based System Database Approach (DBMS)
Data Storage Separate files for each app Centralized database
Redundancy High Low (data shared centrally)
Data Consistency Low (due to redundancy) High (DBMS enforces consistency)
Strong (user roles,
Security Minimal
authentication)
Backup & Automated tools provided by
Manual
Recovery DBMS
Easy and controlled
Data Sharing Difficult
 Feature File-Based System Database Approach (DBMS)

Concurrency Yes, DBMS handles concurrent

Not available
Control access
Application-specific code
Data Access Simple querying (e.g., using SQL)
needed
Data No (app and data are Yes (logical and physical data
Independence tightly linked) independence)
Integrity Rules No built-in support Enforced by DBMS

📊 Diagram (Visual Representation):

File-Based System:
+-------------+ +-------------+
| Student.txt | | Courses.txt |
+-------------+ +-------------+
| |
+-------------------------------+
| Each file accessed separately |
+-------------------------------+
Database Approach:
+---------------------------+
| DBMS (e.g. MySQL) |
+---------------------------+
| Students | Courses | Marks |
+---------------------------+
| Shared by apps and users

🔍 Example Scenario Comparison

Scenario: You need to update a student's address.
 🔹 In File-Based System:

You update it in student.txt, but may forget to update in another

file where the address is copied → inconsistency.
 🔸 In Database Approach:

Address is stored in one centralized table → Update once →

reflected everywhere.
📌 What is Database Architecture?
Database architecture refers to the design and structure of a database
system. It defines:
 How data is stored

 How users interact with the data

 How applications access data

🎯 Purpose of Database Architecture

 To ensure data abstraction

 To provide data independence

 To support multiple users and applications

 To manage security, performance, and integrity

🔷 Types of Database Architecture

Architecture
Description
Type
1-Tier
All logic (UI + DB) in one system (used in file systems)
Architecture
2-Tier Client (UI) ↔ Server (DBMS); simple client-server
Architecture model
3-Tier Presentation Tier ↔ Logic Tier ↔ Database Tier
Architecture (used in modern web apps)

️ Three-Level Schema Architecture (ANSI/SPARC Model)

📘 Definition
The Three-Level Schema Architecture is a model proposed by
ANSI/SPARC to separate the user's view, the logical structure, and the
physical storage of data.
It enables data abstraction and data independence.
️ Three Levels of the Architecture
+---------------------------+
| External Level |
| (User Views - Multiple) |
+---------------------------+
↓
+---------------------------+
| Conceptual Level |
| (Entire logical structure) |
+---------------------------+
↓
+---------------------------+
| Internal Level |
| (Physical storage format) |
+---------------------------+

🔹 1. Internal Level (Physical Level)

 Describes how the data is physically stored.

 Deals with:

o Data storage (files, indexes)

o Record placement

o Access methods

 Managed by the DBMS and OS

💡 Think of it as the “how” behind data storage.

🔹 2. Conceptual Level (Logical Level)

 Describes the structure of the entire database.

 Independent of physical storage.

 Includes:

o Tables, attributes, relationships

o Constraints (e.g., NOT NULL, UNIQUE)

o Views and mappings

💡 Think of it as the blueprint or design of the database.

🔹 3. External Level (View Level)
 Defines what each user/application sees.

 Users can have different views of the same data.

 Can restrict or hide certain fields for security/privacy.

💡 For example, a student can see their marks; admin can see all.

️ Why Use the Three-Level Architecture?

✅ Advantages
1. Data Abstraction:
Users don’t need to know how data is stored physically.
2. Data Independence:
o Logical Data Independence: You can change the schema at

the conceptual level without affecting user views.

o Physical Data Independence: You can change storage or

indexing without affecting the conceptual schema.

3. Security:
Different users can have different views (e.g., hide salaries from HR
interns).
4. Better Design:
Separation of concerns between developers, users, and DBAs.

🔄 Example: Three-Level View of a University Database

Level Example
External A student views only their name and marks
Conceptual Full design with tables: Students, Courses, Results
Internal Tables stored in B-trees, hashed files, etc.
🔄 1. Data Independence

📘 Definition
Data Independence is the capacity of a database to change the schema
(structure) at one level of the database system without requiring changes
at the next higher level.
It enables easy schema modifications without affecting applications.

🔶 Types of Data Independence

🔹 1. Physical Data Independence

 Ability to change the internal schema (how data is stored) without

changing the conceptual schema.

✅ Examples:
 Changing the file organization (e.g., from heap file to B-tree)

 Moving from magnetic disk to SSD storage

 Changing indexes

� "You can change how data is stored without affecting the tables or
relationships."

🔹 2. Logical Data Independence

 Ability to change the conceptual schema (tables, attributes,

relationships) without changing the external schema (user views).

✅ Examples:
 Adding/removing a column from a table

 Splitting a table into two

 Merging two tables into one

� "You can change the design without affecting how users view or access
the data."
🔸 Why is Data Independence Important?
Reason Explanation
Easier Maintenance Schema changes don't break programs
Security Control what users see without exposing schema
Efficiency Improve performance at internal level anytime

️ Summary Table:
Schema Schema
Type Example
Changed Unaffected
Physical Conceptual, Change index
Internal
Independence External structure
Logical Add a column to a
Conceptual External
Independence table

️ 2. Relational Data Model

📗 Definition
The Relational Data Model is a method of organizing data into tables
(called relations). It was introduced by E.F. Codd in 1970.
Data is stored in rows and columns (like spreadsheets).

🔷 Key Terminology
Term Meaning
Relation A table with rows and columns
Tuple A row in a table (represents one record)
Attribute A column in a table (represents one field)
Domain Set of allowed values for an attribute
Degree Number of attributes (columns) in a relation
Cardinality Number of tuples (rows) in a relation
📊 Example of a Relation (Table)
RollNo Name Department
101 Ali CS
102 Sana IT
103 Raheem SE
 Relation: Student

 Tuples: 3

 Attributes: RollNo, Name, Department

🛠️ Properties of the Relational Model

1. Atomic Values: Each cell contains a single value.
2. Uniqueness: No duplicate rows (tuples).
3. Order Irrelevant: Order of rows and columns doesn’t matter.
4. Unique Table Name: Every table (relation) has a unique name.

🔑 Key Concepts in Relational Model

Key Type Description
Primary Key Uniquely identifies each tuple in a relation
Foreign Key Refers to the primary key of another relation (table)
Candidate Key Possible primary keys (uniquely identify rows)
Super Key One or more attributes that uniquely identify a row

️ Advantages of Relational Model

 Simple and easy to understand

 Data independence (supports schema change)

 Uses SQL (standard query language)

 Strong data integrity and constraints

⚠️ Disadvantages
 Performance overhead for complex joins

 Not suitable for semi-structured or unstructured data

 Rigid schema (difficult to model hierarchical/nested data)

️ 1. Attributes

📘 Definition
An attribute is a column in a database table that represents a specific
property or characteristic of the entity represented by the table.
💡 In simple words, an attribute = a field = a column in the table.

📊 Example
For a Student table:
RollNo Name Department Age
101 Ali CS 20
 RollNo, Name, Department, and Age are attributes.

🔸 Types of Attributes in ER Model (optional detail)

 Simple: Cannot be broken further (Age)

 Composite: Can be divided (Name = First + Last)

 Derived: Computed from other data (Age from DOB)

 Multivalued: Can have multiple values (e.g., PhoneNumbers)

📂 2. Schemas

📘 Definition
A schema defines the structure of a database, including table names,
attributes, and their data types.
Think of schema as the blueprint of a database.

🔸 Types of Schemas
Schema Type Description
Database Schema Structure of the entire database
Table Schema Structure of one table (relation)
View Schema Structure of a view (virtual table)
️ Example: Table Schema
CREATE TABLE Student (
RollNo INT PRIMARY KEY,
Name VARCHAR(50),
Department VARCHAR(10),
Age INT
);
Here, Student is the schema of the table that defines:
 Table name

 Attributes

 Data types

 Constraints

️ 3. Tuples

📘 Definition
A tuple is a row in a table. It represents a single record or instance of
an entity.
One row = one tuple = one record

📊 Example
In the Student table:
RollNo Name Department Age
101 Ali CS 20
102 Sana IT 19
Each row is a tuple:
 Tuple 1 = (101, Ali, CS, 20)

 Tuple 2 = (102, Sana, IT, 19)

🔹 Additional Terms
 The degree of a relation = number of attributes

 The cardinality of a relation = number of tuples

Example:
If a table has 4 columns and 10 rows → degree = 4, cardinality = 10
🎯 4. Domains

📘 Definition
A domain is the set of valid values that an attribute can take.
Every attribute in a table is defined over a domain.

✅ Example Domains
Attribute Domain
Age Integers from 10 to 100
Gender {‘Male’, ‘Female’, ‘Other’}
Email Any valid email format
RollNo Positive integers only

🔸 Why Are Domains Important?

 Enforce data validity

 Prevent invalid entries (e.g., name as number)

 Improve data integrity

️ Summary Table
Concept Description Example
Attribute Column in a table Name, Age
Tuple Row in a table (record) (101, Ali, CS, 20)
Table definition with CREATE TABLE Student
Schema (...)
structure
Set of valid values for an
Domain Age: integers 10–100
attribute
🔁 1. Relation Instances

📘 Definition
A relation instance refers to the actual set of rows (tuples) present in a
relation (table) at a particular point in time.
It is the current snapshot of the data in the table.

🏛️ Relation vs. Relation Instance

Term Description
Relation The structure/schema of a table
Relation Instance The actual data (tuples) in the table

📊 Example: Student Table

Relation (schema):
Student(RollNo, Name, Department)
Relation Instance (data):
RollNo Name Department
101 Ali CS
102 Sana IT
103 Raheem SE
 Each row is a tuple

 The table as it exists right now is the relation instance

 A relation may have many different instances over time as data

changes

🔒 Properties of a Relation Instance

 No duplicate tuples

 Each tuple is unique (often enforced by keys)

 Attributes have atomic (indivisible) values

 Order of tuples and attributes does not matter

🗝️ 2. Keys of Relations

📘 Definition
Keys are attributes (or sets of attributes) that are used to identify tuples
(rows) uniquely in a relation.
Keys enforce uniqueness, integrity, and help in data retrieval and
relationships.

🔑 Types of Keys in DBMS

🔹 1. Super Key
 A set of one or more attributes that can uniquely identify a tuple

 May contain extra attributes

Example:
In Student(RollNo, Name, Email),
{RollNo}, {RollNo, Name}, {RollNo, Email} — all are
super keys

🔹 2. Candidate Key
 A minimal super key — no extra attribute

 Uniquely identifies a tuple

 There can be multiple candidate keys

Example:
In Student(RollNo, CNIC, Name):
 {RollNo} and {CNIC} could both be candidate keys

🔹 3. Primary Key
 One chosen candidate key to uniquely identify each row

 Cannot have NULL values

 Every relation must have one primary key

Example:
If both RollNo and CNIC are candidate keys, we choose RollNo as
the primary key
🔹 4. Foreign Key
 An attribute that refers to the primary key of another table

 Used to establish relationships between tables

Example:
Student(RollNo, Name, DeptID)
Department(DeptID, DeptName)

→ Student.DeptID is a **foreign key** referencing

Department.DeptID

️ Comparison Table of Key Types

Key Type Purpose Uniqueness Nullable Example
Uniquely identifies RollNo +
Super Key ✔� ✔�
tuples Name
Candidate RollNo or
Minimal super key ✔� ❌
Key CNIC
Primary Key Chosen candidate key ✔� ❌ RollNo
References primary key DeptID in
Foreign Key ❌ ✔�
in another table Student

🎯 Important Rules
 A primary key must be:

o Unique

o Not NULL
 A foreign key must:

o Match a primary key value in the referenced table

o Or be NULL (optional relationship)

📘 Example: With Keys
Table 1: Department
DeptID DeptName
1 CS
2 IT
Primary Key: DeptID

Table 2: Student
RollNo Name DeptID
101 Ali 1
102 Sana 2
Primary Key: RollNo
Foreign Key: DeptID references Department.DeptID

️ Summary Table
Term Meaning
Relation Instance The actual table data (rows/tuples)
Super Key Any set of attributes that uniquely identify a tuple
Candidate Key Minimal super key
Primary Key Main unique identifier for the table
Foreign Key Links one table to another
✅ 1. Integrity Constraints in DBMS

📘 Definition
Integrity Constraints are rules that ensure the correctness, validity,
and consistency of data in a relational database.
Constraints prevent invalid data from being inserted or updated.

🔒 Types of Integrity Constraints

🔹 A. Domain Constraint
 Ensures that attribute values fall within a predefined domain (set

of valid values).
📌 Example:
Age INT CHECK (Age >= 18 AND Age <= 60)
Only values between 18 and 60 are allowed in the Age column.

🔹 B. Entity Integrity Constraint

 Ensures that the primary key of a table:

o Is unique

o Cannot be NULL

📌 Example:
CREATE TABLE Student (
RollNo INT PRIMARY KEY,
Name VARCHAR(50)
);
You cannot insert NULL or duplicate RollNo values.
🔹 C. Referential Integrity Constraint
 Ensures that a foreign key value must either:

o Match a primary key in the referenced table

o Or be NULL

📌 Example:
CREATE TABLE Department (
DeptID INT PRIMARY KEY
);

CREATE TABLE Student (

RollNo INT PRIMARY KEY,
DeptID INT,
FOREIGN KEY (DeptID) REFERENCES
Department(DeptID)
);
Now, DeptID in Student must exist in Department.

🔹 D. Unique Constraint
 Ensures that the column values are all different (like Primary Key,

but can have NULL).

📌 Example:
Email VARCHAR(100) UNIQUE

🔹 E. Not Null Constraint

 Ensures that an attribute must have a value (cannot be NULL).

📌 Example:
Name VARCHAR(50) NOT NULL
➕ 2. Relational Algebra in DBMS

📘 Definition
Relational Algebra is a procedural query language used to retrieve
and manipulate data from a relational database using mathematical
operations.
It forms the theoretical foundation of SQL.

️ Why Use Relational Algebra?

 Used for query optimization in DBMS internals

 Helps understand how SQL queries work internally

 Based on set theory and logic

🔧 Basic Operations in Relational Algebra

🔹 A. Selection (σ)
 Retrieves rows that satisfy a condition

📌 Notation:
σ<condition>(Relation)
📌 Example:
σDept = 'CS'(Student)
→ selects students in CS department

🔹 B. Projection (π)
 Retrieves specific columns

📌 Notation:
π<columns>(Relation)
📌 Example:
πName,Dept(Student)
→ displays only Name and Department
🔹 C. Union ( ∪ )
 Combines two relations with same attributes

 Removes duplicates

📌 Example:
Student ∪ Alumni

🔹 D. Set Difference ( − )
 Returns tuples in one relation but not in the other

📌 Example:
Student − Alumni

🔹 E. Cartesian Product ( × )
 Combines every tuple of one relation with every tuple of another

📌 Example:
Student × Department
(Not commonly used alone — used in joins)

🔹 F. Rename (ρ)
 Renames a relation or attributes for clarity

📌 Example:
ρ(S ← Student)

🔄 Join Operations (Advanced)

🔹 G. Natural Join (⨝)

 Joins two relations on common attributes (removes duplicate

columns)
📌 Example:
Student ⨝ Department
🔹 H. Theta Join (⨝ condition)
 Joins based on a given condition (can use =, <, >, etc.)

📌 Example:
Student ⨝ Student.DeptID = Department.DeptID
🎓 Example Dataset
Student Table:
RollNo Name DeptID
1 Ali 101
2 Sana 102
Department Table:
DeptID DeptName
101 CS
102 IT

🔍 Sample Queries
1. Get names of students in CS department:
σDeptName = 'CS'(Student ⨝ Department)
2. List all department names:
πDeptName(Department)
3. Students not in IT department:
σDeptName ≠ 'IT'(Student ⨝ Department)

✅ Summary Table
Operator Symbol Description
Selection σ Filters rows
Projection π Filters columns
Union ∪ Combines relations (no duplicates)
Difference − Rows in A but not in B
Product × Combines all tuples
Rename ρ Renames attributes/tables
Join ⨝ Combines related rows
🔍 1. Selection (σ)

📘 Definition:
Selection is a relational algebra operation that selects rows (tuples) from
a relation based on a condition.
Think of it as applying a WHERE clause in SQL.

️ Notation:
σ<condition>(Relation)

📊 Example:
Consider the table Student:
RollNo Name Dept Age
1 Ali CS 19
2 Sana IT 21
3 Amir CS 20
Query:
σDept = 'CS'(Student)
Result:
RollNo Name Dept Age
1 Ali CS 19
3 Amir CS 20

📋 2. Projection (π)

📘 Definition:
Projection retrieves specific columns (attributes) from a relation. It
removes duplicates automatically.
Equivalent to SELECT column1, column2 in SQL.
️ Notation:
π<attribute1, attribute2, ...>(Relation)

📊 Example:
πName, Dept(Student)
Result:
Name Dept
Ali CS
Sana IT
Amir CS

✖️ 3. Cartesian Product (×)

📘 Definition:
Cartesian Product returns a combination of every tuple in one relation
with every tuple in another.
Also called the cross join in SQL.

️ Notation:
Relation1 × Relation2

⚠️ Result Size:
If R has m rows and S has n rows, then R × S has m × n rows.

📊 Example:
Student
RollNo Name
1 Ali
2
Sana
Department
DeptID DeptName
CS
101

102 IT
Query:
Student × Department
Result:
RollNo Name DeptID DeptName
1 Ali 101 CS
1 Ali 102 IT
2 Sana 101 CS
2 Sana 102 IT
� Used in joins — often followed by a selection to match keys.

🔗 4. Types of Joins in Relational Algebra

Joins are used to combine rows from two relations based on a related
column (usually foreign key = primary key).

📁 A. Theta Join (⨝)

 Joins based on a custom condition

 Can use =, ≠, <, >, etc.

📘 Notation:
R ⨝<condition> S
📊 Example:
Student ⨝ Student.DeptID = Department.DeptID

️ B. Equi Join
 A special case of Theta Join where condition is only equality ( = )

 May include duplicate columns

🌿 C. Natural Join (⨝)
 Automatically joins on all attributes with the same name

 Removes duplicate columns

📘 Notation:
R ⨝ S
📊 Example:
Student Department
RollNo, Name, DeptID DeptID, DeptName
Student ⨝ Department
Result:
RollNo Name DeptID DeptName
1 Ali 101 CS

🌊 D. Outer Joins (Not native in basic algebra, but used in SQL):

📌 Left Outer Join
 All rows from the left table + matched rows from right

 If no match → NULL

📌 Right Outer Join

 All rows from the right table + matched from left

📌 Full Outer Join

 All rows from both tables; unmatched → NULLs

️ Summary Table
Operation Symbol Description
Selection σ Filters rows based on condition
Projection π Selects specific columns
Cartesian Product × Combines all tuples from two tables
Theta Join ⨝ Join using condition
Equi Join ⨝ (a = b) Theta join using = only
Natural Join ⨝ Join on same-named attributes
✅ 1. Normalization in DBMS

📘 Definition:
Normalization is the process of organizing data in a database to:
 Eliminate redundancy

 Avoid anomalies (insertion, deletion, update issues)

 Ensure data integrity

🎯 Goal of Normalization:
 Minimize duplicate data

 Break large tables into smaller ones

 Establish relationships using foreign keys

🔥 Types of Anomalies Solved by Normalization:

Type of
Description
Anomaly
Insertion
Cannot add data because other data is missing
Anomaly
Deletion Deleting one piece of data unintentionally removes
Anomaly other important data
Update
Data becomes inconsistent after updates
Anomaly

🔗 2. Functional Dependencies (FDs)

📘 Definition:
A Functional Dependency (FD) is a relationship between attributes such
that:
If two tuples (rows) have the same value for attribute X, then they must
have the same value for attribute Y.
Notation:
X → Y
This means: X functionally determines Y
📊 Example:
In a Student table:
RollNo → Name, Department
If you know RollNo, you can find Name and Department.

🔁 Types of Functional Dependencies:

Type Description
Trivial X → Y, where Y ⊆ X
Non-Trivial X → Y, where Y ⊄ X
Fully Y is functionally dependent on X, but not on any proper
Functional subset of X
Transitive If A → B and B → C, then A → C

️ FD Rules (Armstrong’s Axioms):

1. Reflexivity: If Y ⊆ X → X → Y
2. Augmentation: If X → Y, then XZ → YZ
3. Transitivity: If X → Y and Y → Z, then X → Z

️ 3. Normal Forms (1NF to BCNF)

Normalization is done in steps called normal forms (NF).

🔹 First Normal Form (1NF)

✅ Rule:
 Every attribute must contain atomic (indivisible) values

 No repeating groups or arrays

📊 Example – Not in 1NF:

RollNo Name Courses
101 Ali CS101, CS102
🚫 Courses has multiple values.
✅ Convert to 1NF:
RollNo Name Course
101 Ali CS101
101 Ali CS102

🔹 Second Normal Form (2NF)

✅ Rules:
 Must be in 1NF

 No partial dependency (non-prime attribute depending only on part

of a composite key)

📊 Example:
Relation:
Enrollment(RollNo, CourseCode, StudentName,
CourseName)
FDs:
 RollNo → StudentName

 CourseCode → CourseName

🚫 Partial dependencies:
 StudentName depends on part of key (RollNo)

 CourseName depends on CourseCode

✅ Convert to 2NF:
1. Student(RollNo, StudentName)
2. Course(CourseCode, CourseName)
3. Enrollment(RollNo, CourseCode)

🔹 Third Normal Form (3NF)

✅ Rules:
 Must be in 2NF

 No transitive dependency (non-prime attribute depends on another

non-prime attribute)
📊 Example:
Relation:
Student(RollNo, Name, DeptID, DeptName)
FDs:
 RollNo → Name, DeptID

 DeptID → DeptName

🚫 Transitive dependency:
 DeptName depends on DeptID, which depends on RollNo

✅ Convert to 3NF:
1. Student(RollNo, Name, DeptID)
2. Department(DeptID, DeptName)

🔹 Boyce-Codd Normal Form (BCNF)

✅ Rules:
 Must be in 3NF

 For every non-trivial FD X → Y, X must be a super key

💡 BCNF is stricter than 3NF.

📊 Example (Violation):
Relation:
R(A, B, C)
FDs:
 A → B

 B → A

 C → A

If neither A nor B is a super key, BCNF is not satisfied.

️ Quick Recap
 Normalization improves efficiency and data integrity

 Functional Dependencies are the foundation of normalization

 Normal Forms (1NF → BCNF) are stepwise rules for designing

better schemas
📐 1. Entity-Relationship (ER) Model

✅ Definition:
The Entity-Relationship (ER) Model is a high-level data model used
in database design to visually represent the entities, relationships, and
attributes in a system.
💡 It provides a blueprint of the data structure using diagrams (ER
diagrams).

🎯 Purpose:
 To model real-world objects and relationships in a database.

 To help in logical design before physical implementation.

📊 Key Components of ER Model:

Component Description Example
Entity Real-world object or concept Student, Course
Attribute Property of an entity Name, Age, CourseCode
Relationship Association between two or more entities Enrolls, Teaches

🖼️ Example ER Diagram (Text Format):

[Student] ----enrolls----> [Course]
| |
(RollNo, Name, Age) (CourseID, Title)

️ 2. Entity Sets

✅ Definition:
An Entity Set is a collection of similar entities that share the same
attributes.
💡 Think of it as a table, where each row is an entity, and columns are
attributes.
📘 Types of Entities:
Type Description Example
Strong Entity Exists independently Student, Employee
Weak Entity Depends on another entity (no primary key) Dependent, OrderItem

🔐 Key Attribute:
 Every entity set has a key attribute that uniquely identifies each

entity.
Example: RollNo in Student entity set

️ Example: Entity Set - Student

RollNo Name Age
101 Ali 20
102 Sana 19
Here, the Student is an entity set containing multiple Student entities.

🔹 Weak Entity Set Example:

Entity Set: Dependent
 Attributes: Name, Age

 Does not have a primary key

 Identified via relationship with Employee

→ Needs the primary key of Employee + own attributes to be uniquely

identified.

️ 3. Attributes in ER Model

✅ Definition:
Attributes are the properties or characteristics of an entity or
relationship.
💡 Attributes become columns when the ER model is converted into a
relational model.
🔍 Types of Attributes:

🔸 A. Simple (Atomic) Attribute

 Cannot be divided further.

 Example: Age, RollNo, Gender

🔸 B. Composite Attribute
 Can be divided into smaller sub-parts.

 Example: Name → FirstName, LastName

🔸 C. Derived Attribute
 Value is calculated from other attributes.

 Example: Age can be derived from DOB

🔸 D. Multivalued Attribute
 Can have more than one value for a single entity.

 Example: PhoneNumbers, EmailAddresses

→ Represented as double oval in ER diagram.

🔸 E. Key Attribute
 Uniquely identifies an entity.

 Underlined in ER diagram.

 Example: RollNo, EmployeeID

📊 Example Table: Types of Attributes

Attribute Type Description Example
Simple Atomic, cannot be split Age, Gender
Composite Can be divided Name → First, Last
Derived Calculated from other data Age from DOB
Multivalued Multiple values possible Phone Numbers
Key Unique identifier RollNo
🖼️ ER Diagram Components (Text Form)
Shape Meaning
Rectangle Entity Set
Oval Attribute
Diamond Relationship
Double Oval Multivalued Attribute
Dashed Oval Derived Attribute
Double Rectangle Weak Entity Set
Underlined Attribute Key Attribute

📘 Sample ER Diagram – Text Version

+-----------+ +-----------+
| Student | | Course |
+-----------+ +-----------+
| RollNo | | CourseID |
| Name | | Title |
| Age | +-----------+
+-----------+
|
| enrolls
▼
+--------+
|Enrolls |
+--------+
| Grade |
+--------+

.
🔗 1. Relationships in ER Model

✅ Definition:
A relationship in an ER model represents an association among two or
more entity sets.
💡 It answers: "How are entities connected?"

📊 Example:
A Student enrolls in a Course.
 Entities: Student, Course

 Relationship: Enrolls

🔹 Degree of a Relationship
The number of entity sets that participate in a relationship.
Degree Type Example
Binary Two entities Student — Enrolls — Course
Ternary Three entities Doctor — Treats — Patient — Disease

🔢 Cardinality (Mapping Constraints)

Defines the number of entity instances that can participate in the
relationship.
Type Description Example
1:1 One entity in A ↔ one in B Person ↔ Passport
1:N One entity in A ↔ many in B Department ↔ Employees
M:N Many in A ↔ many in B Student ↔ Course

📘 Example Table:
Student(StuID, Name)
Course(CourseID, Title)
Enrolls(StuID, CourseID, Grade)
️ Participation Constraints
Constraint Description
Total Every entity in the set must participate in the
Participation relationship (shown with double line)
Partial Some entities may not participate (shown with single
Participation line)

🔐 Key Constraints
Ensures that a relationship is properly defined with primary/foreign keys.

🖼️ 2. Entity-Relationship (ER) Diagrams

✅ Definition:
An ER Diagram is a graphical representation of entities, attributes,
and relationships.
It helps visualize how data is connected in the system.

🎨 ER Diagram Symbols
Component Symbol Description
Entity Rectangle Represents an entity set
Weak Entity Double Rectangle Depends on another entity
Attribute Oval Property of entity or relationship
Key Attribute Underlined Oval Uniquely identifies entity
Relationship Diamond Association between entities
Multivalued Attr Double Oval Attribute with multiple values
Derived Attr Dashed Oval Computed attribute (e.g., Age)
️ Example: ER Diagram (Text Representation)
+---------+ +-----------+
| Student | | Course |
+---------+ +-----------+
| StuID | | CourseID |
| Name | | Title |
+---------+ +-----------+
\ /
\ /
\ +--------+ /
-->|Enrolls |<--
+--------+
| Grade |
+--------+
 Enrolls is a relationship with an attribute Grade.

 Student and Course are entity sets.

 StuID and CourseID are key attributes.

️ Steps to Draw ER Diagram:

1. Identify entities (nouns like Student, Course)
2. Determine relationships (verbs like Enrolls, Teaches)
3. Add attributes to entities and relationships
4. Mark primary keys (underline)
5. Specify cardinality (1:1, 1:N, M:N)
6. Add weak entities and their identifying relationships (if any)
7. Indicate total/partial participation

✅ Summary Table
Concept Description
Relationship Link between two or more entities
Cardinality 1:1, 1:N, M:N (number of entity associations)
Participation Total (double line), Partial (single line)
ER Diagram Visual tool to design database structure
Symbols Rectangle (Entity), Diamond (Relation), Oval (Attribute)
️ 1. Structured Query Language (SQL)

✅ Definition:
SQL (Structured Query Language) is a standard programming
language used to manage and manipulate relational databases.
It allows creation, modification, retrieval, and control of data.

🔧 SQL Categories:
Type Purpose Examples
DDL Data Definition Language CREATE, ALTER, DROP
SELECT, INSERT, UPDATE,
DML Data Manipulation Language
DELETE
DCL Data Control Language GRANT, REVOKE
Transaction Control
TCL COMMIT, ROLLBACK, SAVEPOINT
Language

📘 Examples:
Create Table:
CREATE TABLE Student (
RollNo INT PRIMARY KEY,
Name VARCHAR(50),
Age INT
);
Insert Data:
INSERT INTO Student VALUES (1, 'Ali', 20);
Select Data:
SELECT * FROM Student;
🔗 2. Joins in SQL

✅ Definition:
JOIN is used to combine rows from two or more tables based on a
related column.

🔀 Types of Joins:
Join Type Description
INNER JOIN Returns matching rows in both tables
LEFT JOIN All rows from left table + matching from right
RIGHT JOIN All rows from right table + matching from left
FULL OUTER JOIN All rows from both tables, unmatched = NULL
CROSS JOIN Cartesian product (every combination)
SELF JOIN Join table with itself

📊 Example Tables:
Student:
RollNo Name DeptID
1 Ali 10
2 Sana 11
Department:
DeptID DeptName
10 CS
11 IT
📘 INNER JOIN:
SELECT Name, DeptName
FROM Student
INNER JOIN Department ON Student.DeptID =
Department.DeptID;
Result:
Name DeptName
Ali CS
Sana IT

️ 3. Subqueries in SQL

✅ Definition:
A subquery is a query inside another query, often used for filtering,
comparison, or as derived data.

🔄 Types of Subqueries:
Type Description
Scalar Returns a single value
Row Returns a row of values
Table Returns multiple rows & columns
Correlated Refers to outer query’s column
Nested in SELECT, FROM, WHERE Common usage areas

📘 Example: Subquery in WHERE clause

SELECT Name
FROM Student
WHERE DeptID = (SELECT DeptID FROM Department
WHERE DeptName = 'CS');
📊 4. Grouping and Aggregation in SQL

✅ Definition:
Grouping allows you to organize data into groups.
Aggregate functions perform calculations on groups of rows.

️ Aggregate Functions:
Function Purpose
SUM() Total value
AVG() Average
MIN() Minimum
MAX() Maximum
COUNT() Row count

📘 GROUP BY Example:
SELECT DeptID, COUNT(*) AS TotalStudents
FROM Student
GROUP BY DeptID;
Result:
DeptID TotalStudents
10 1
11 1

📘 HAVING Clause:
Used to filter groups (like WHERE but for aggregated data):
SELECT DeptID, COUNT(*) AS Total
FROM Student
GROUP BY DeptID
HAVING COUNT(*) > 1;
🔒 5. Concurrency Control in DBMS

✅ Definition:
Concurrency control ensures correct execution of transactions when
multiple users access the database simultaneously.
Prevents data inconsistency, lost updates, and deadlocks.

🎯 Goals of Concurrency Control:

 Maintain data integrity

 Ensure ACID properties (Atomicity, Consistency, Isolation,

Durability)

🔄 Common Problems Without Control:

Problem Description
Lost Update Two transactions overwrite each other
Dirty Read Reading uncommitted data
Unrepeatable Read Same query returns different results
Phantom Read Rows appear/disappear during a transaction

⚙️ Techniques of Concurrency Control:

1. Locking Protocols:
o Shared Lock: Read only

o Exclusive Lock: Write only

o 2-Phase Locking (2PL): Growing + shrinking phases

2. Timestamp Ordering:
o Assigns timestamps to transactions

o Ensures serializable execution order

3. Optimistic Concurrency Control:

o No locking; validates data before commit
📌 ACID Properties Recap:
Property Description
Atomicity All or nothing (full success/fail)
Consistency DB remains valid after transaction
Isolation Transactions do not interfere
Durability Once committed, changes persist

🛡️ 1. Database Backup and Recovery

✅ Definition:
Backup is the process of copying and saving database data to protect
against loss.
Recovery is the process of restoring the database to a consistent state
after failure.
Backup & recovery ensure data availability, reliability, and durability.

🔄 Types of Failures:
Type Description
System crash Power failure, OS crash
Transaction failure Incomplete or aborted transaction
Media failure Disk or hardware damage
Application error Logical bugs or wrong queries

📦 Types of Backups:
Type Description
Full Backup Copies the entire database
Incremental Backs up only data changed since last backup
Differential Backs up all data changed since the last full backup
Logical Backup Backs up data as SQL statements (e.g., mysqldump)
Physical Backup Backs up data files (binary copy of data blocks)
️
Backup Example in SQL Server:
BACKUP DATABASE University
TO DISK = 'C:\Backups\University.bak';

🔁 Recovery Techniques:
1. Rollback: Undo a transaction (using logs)
2. Rollforward: Apply logs to bring DB to latest state
3. Checkpoints: Save consistent state periodically
4. Shadow Paging: Keeps a copy of unchanged pages
5. Log-Based Recovery:
o Maintain transaction logs

o Use UNDO and REDO operations

🔐 Example Log Entry:

<START T1>
<WRITE T1, X, old_value, new_value>
<COMMIT T1>

🔍 2. Indexes in DBMS

✅ Definition:
An index is a data structure that speeds up data retrieval from a table
without scanning every row.
Similar to an index in a book — quick lookup of contents.

🔧 Why Use Indexes?

 Improves query performance

 Especially useful for large tables

 Reduces disk I/O

📦 Types of Indexes:
Type Description
Primary Index Built on primary key (unique & sorted)
Secondary Index Built on non-primary attributes
Unique Index Ensures all values in the column are unique
Clustered Index Data is stored in the same order as the index
Non-Clustered Index Separate structure, points to actual rows
Multilevel Index Index built on top of another index
Bitmap Index Uses bitmaps (for attributes with few values)
Hash Index Uses hash tables (fast exact-match lookup)

⚙️ Index Example in SQL:

CREATE INDEX idx_student_name ON Student(Name);

� Query Optimization Example:

SELECT * FROM Student WHERE Name = 'Ali';
🔍 Without index → full table scan
⚡ With index → direct jump to matching row

⚠️ Index Drawbacks:
 Takes extra storage space

 Slightly slows inserts/updates (index must be updated)

🌐 3. NoSQL Systems

✅ Definition:
NoSQL stands for "Not Only SQL". It refers to non-relational
databases designed for:
 High scalability

 Flexible schema
 Big data and real-time apps

Useful for systems where relational models don't fit well

🚀 Characteristics:
Feature Description
Schema-less No fixed table schema (can store different fields)
Scalable Designed for horizontal scaling (across servers)
Distributed Built for cloud and distributed environments
Flexible Handles structured, semi-structured, or unstructured data

📂 Types of NoSQL Databases:

Type Description Examples
Document-based Stores data in JSON-like documents MongoDB, CouchDB
Key-Value Simple key-value pairs Redis, DynamoDB
Column-family Stores data in column format Cassandra, HBase
Graph-based Stores nodes and edges Neo4j, ArangoDB

📘 Document Example (MongoDB):

{
"student_id": 1,
"name": "Ali",
"courses": ["CS101", "CS102"]
}

🔄 SQL vs NoSQL Comparison:

Feature SQL (Relational) NoSQL
Data Model Tables and rows Key-Value, JSON, Graph
Schema Fixed Dynamic/Flexible
Transactions Strong ACID support Eventual consistency (some)
Scaling Vertical (scale-up) Horizontal (scale-out)
Use Cases Structured, normalized data Big data, real-time apps