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

DBMS Notes Merged

The document provides a comprehensive guide on databases, focusing on the types of databases, particularly Relational Database Management Systems (RDBMS), and their architecture. It covers essential concepts such as tables, data integrity, SQL commands, and real-life banking use cases for various database languages. Additionally, it includes practical SQL queries and their expected outputs, emphasizing the application of these concepts in banking systems.

Uploaded by

harshdeepg12
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
8 views

DBMS Notes Merged

The document provides a comprehensive guide on databases, focusing on the types of databases, particularly Relational Database Management Systems (RDBMS), and their architecture. It covers essential concepts such as tables, data integrity, SQL commands, and real-life banking use cases for various database languages. Additionally, it includes practical SQL queries and their expected outputs, emphasizing the application of these concepts in banking systems.

Uploaded by

harshdeepg12
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 53

SLASHBYTE

DBMS
Slashbyte: Your guide to mastering
IT concepts and exam strategies.

Prepared By:
SLASHBYTE

@slashbytessc
www.slashbyte.xyz
Databases

Databases
Databases are a systematic collection of data that enables easy access, management, and
updating. They are an essential component in software engineering and data management.
DBMS is the acronym of Data Base Management System. DBMS is a collection of interrelated
data and a set of programs to access this data in a convenient and efficient way. It controls
the organization, storage, retrieval, security and integrity of data in a database.

Types Of Databases:
Type of Description Advantages
Database

1. Relational Stores data in tables ACID properties, Structured data, Easy querying
Database with rows and
columns

2. NoSQL Stores data in various High scalability, Flexible data model, High
Database formats (key-value, productivity
document, graph,
etc.)

3. Distributed Stores data across Modular development, Fault tolerance, Scalability


Database multiple systems

4. Cloud Stores data in a Scalability, Flexibility, Cost-effective


Database virtual environment
on the cloud

5. Centralized Stores data at a Decreased data management risk, Data


Database central location consistency, Better data quality

Relational DBMS

A Relational Database Management System (RDBMS) is a type of database management system


(DBMS) that stores data in a structured format, using rows and columns. Each table (relation) is
identified by a unique name, and data integrity is maintained through the use of constraints.

What are Tables in Relational Model?


Relations are saved in the format of Tables. This format stores the relation among entities. A table
has rows and columns, where rows represents records and columns represent the attributes.
Following are some terms associated with relations:

1. Tuple − A single row of a table, which contains a single record for that relation is called a tuple.
2. Relation instance − A finite set of tuples in the relational database system represents relation
instance.
Relation instances do not have duplicate tuples.

3. Relation schema − A relation schema describes the relation name (table name), attributes, and
their names.
4. Relation key − Each row has one or more attributes, known as relation key, which can identify
the row in
the relation (table) uniquely.
5. Attribute domain − Every attribute has some pre-defined value scope, known as attribute
domain.

Relation Table

Tuple Row, Record

Attribute Column, Field

Domain It consists of
set of legal
values

Cardinality It consists of
number of
rows
Degree It contains
number of
columns

Key Features of RDBMS:


Data Integrity: Ensures accuracy and consistency through constraints.

Data Relationships: Supports relationships between tables through foreign keys.

SQL: Uses Structured Query Language for data manipulation.


Q) What's correct about Views in database from following: (SBI SO 2024)
A) Views are permanent objects
B) Views can be indexed
C) A table doesn't drop if view is dropped
D) Views are always read-only
E) Views can be used for security purposes

Answer c

Uses of RDBMS in Banking


1. Customer Data Management – Stores and manages customer details, account information,
and transaction history securely.

2. Transaction Processing – Ensures real-time deposits, withdrawals, and fund transfers with
ACID compliance.

3. Loan & Credit Management – Maintains loan records, EMI schedules, and credit histories
efficiently.

4. Fraud Detection & Security – Identifies suspicious transactions and enforces data
encryption and access control.

5. Internet & Mobile Banking – Supports secure online banking, API-based transactions, and
multi-user access management.
DBMS Architecture
The DBMS design depends upon its architecture. The basic client/server architecture is used

to deal with a large number of PCs, web servers, database servers and other components
that are connected with networks.

DBMS architecture depends upon how users are connected to the database to get their

request done.

Types of DBMS Architecture


Database architecture can be seen as a single tier or multi-tier. But logically, database architecture
is of two types like: 2-tier architecture and 3-tier architecture.

1-Tier Architecture
The 1-Tier architecture, also known as Single-Tier architecture, directly connects users to the

DBMS, allowing changes to be made directly to the database, typically used for local
applications and development purposes.

2-Tier Architecture
The 2-Tier Architecture, or Client-Server model, connects client-side applications directly to a

server-side database using APIs like ODBC and JDBC for query processing and transaction
management.

Fig: 2-tier Architecture


3-Tier Architecture
The 3-Tier architecture contains another layer between the client and server. In this

architecture, client can't directly communicate with the server.

The application on the client-end interacts with an application server which further

communicates with the database system.

Entity-Relationship Diagram (ER Diagram)


An ER diagram is a visual representation of different entities within a system and their
relationships. It includes the following components:
Entities: Objects or things in the database (e.g., Customer, Order).

Attributes: Properties of entities (e.g., Customer Name, Order Date).

Relationships: Connections between entities (e.g., a customer places an order).

ER model stands for an Entity-Relationship model. It is a high-level data model. This model is

used to define the data elements and relationship for a specified system.

Data Models
Relational Data Model: Organizes data into tables (relations) with rows and columns.

Entity-Relationship (ER) Data Model: Represents data as entities, relationships, and

attributes.

Object-based Data Model: Extends ER model with object-oriented concepts (functions,



encapsulation).

Semistructured Data Model: Allows flexible data specifications using XML, for exchanging

data.

Data Independence
Data independence allows modifying database schemas without affecting higher-level schemas.
Two Types:
Logical Data Independence: Changes to conceptual schema don't affect external schema (user
view).
Occurs at user interface level.

Physical Data Independence: Changes to internal schema don't affect conceptual schema.
Occurs at logical interface level.

Database Languages in DBMS
Database languages can be used to read, store and update the data in the database.

Types of Database Languages
1. Data Definition Language (DDL)
DDL is used to define and modify database structures such as tables, schemas, constraints, and
indexes. It deals with metadata storage and does not manipulate actual data.

DDL Commands with Real-Life Banking Use Cases


1.1 CREATE – Creating a Table
Used to define new tables, indexes, or databases.
Example (Creating a Customers Table in a Bank Database)

CREATE TABLE Customers (


CustomerID INT PRIMARY KEY,
Name VARCHAR(100),
Email VARCHAR(100) UNIQUE,
Phone VARCHAR(15),
Balance DECIMAL(10,2)
);

🔹 Use Case: Used when a bank wants to create a new database table for storing customer
details.

1.2 ALTER – Modifying an Existing Table


Used to add, modify, or delete columns in a table.
Example (Adding an Address Column to Customers Table)

ALTER TABLE Customers ADD Address VARCHAR(255);

🔹 Use Case: When a bank decides to store customers' addresses for better communication.
1.3 DROP – Deleting a Table
Used to remove a table permanently along with its data.
Example (Deleting a Transactions Table)

DROP TABLE Transactions;

🔹 Use Case: If a bank migrates to a new database system and wants to remove an old table.
1.4 TRUNCATE – Deleting All Records Without Removing Structure
Used to remove all records from a table but keep the structure.
Example (Clearing Test Transactions Data)

TRUNCATE TABLE Transactions;

🔹 Use Case: If a bank is testing transactions and needs to clear dummy data while retaining the
table structure.

1.5 RENAME – Renaming a Table or Column


Example (Renaming Customers Table to Clients)

ALTER TABLE Customers RENAME TO Clients;

🔹 Use Case: A bank may rename tables to match new business terminology.
1.6 COMMENT – Adding Comments to the Database
Example (Adding a Comment on a Column)

COMMENT ON COLUMN Customers.Balance IS 'Stores the available balance of the customer';

🔹 Use Case: Helps database administrators understand the purpose of columns.


2. Data Manipulation Language (DML)
DML is used to access, modify, and manipulate data stored in tables. These commands are
transactional and can be rolled back.

DML Commands with Real-Life Banking Use Cases


2.1 SELECT – Retrieving Data
Example (Fetching Account Balance for a Customer)

SELECT Name, Balance FROM Customers WHERE CustomerID = 101;

🔹 Use Case: A bank employee checks a customer’s balance.


2.2 INSERT – Adding New Data
Example (Adding a New Customer)
INSERT INTO Customers (CustomerID, Name, Email, Phone, Balance)
VALUES (102, 'Amit Kumar', '[email protected]', '9876543211', 25000.00);

🔹 Use Case: A new customer opens a bank account.


2.3 UPDATE – Modifying Existing Data
Example (Updating Balance After a Deposit)

UPDATE Customers SET Balance = Balance + 5000 WHERE CustomerID = 102;

🔹 Use Case: A customer deposits money into their account.


2.4 DELETE – Removing Specific Data
Example (Deleting a Customer Record Who Closed Their Account)

DELETE FROM Customers WHERE CustomerID = 103;

🔹 Use Case: A customer closes their account, so their record is removed.


2.5 MERGE – Upserting Data
Example (Updating Customer Balance if Exists, Else Insert a New Record)

MERGE INTO Customers USING (SELECT 104 AS CustomerID, 'Raj Sharma' AS Name, 30000 AS Balance) AS NewData
ON Customers.CustomerID = NewData.CustomerID
WHEN MATCHED THEN UPDATE SET Balance = Balance + NewData.Balance
WHEN NOT MATCHED THEN INSERT (CustomerID, Name, Balance) VALUES (NewData.CustomerID, NewData.Name,
NewData.Balance);

🔹 Use Case: Used for batch processing where banks update records automatically.
3. Data Control Language (DCL)
DCL deals with database security and permissions.

DCL Commands with Real-Life Banking Use Cases


3.1 GRANT – Giving Permissions to Users
Example (Granting SELECT Permission to a Clerk)

GRANT SELECT ON Customers TO ClerkUser;

🔹 Use Case: A bank allows clerks to view customer details but not modify them.
3.2 REVOKE – Removing Permissions from Users
Example (Revoking DELETE Permission from an Employee)

REVOKE DELETE ON Transactions FROM EmployeeUser;

🔹 Use Case: Ensures sensitive transaction data cannot be deleted by unauthorized employees.
4. Transaction Control Language (TCL)
TCL manages transactions and ensures data consistency.

TCL Commands with Real-Life Banking Use Cases


4.1 COMMIT – Saving a Transaction Permanently
Example (Committing a Deposit Transaction)

BEGIN TRANSACTION;
UPDATE Customers SET Balance = Balance + 10000 WHERE CustomerID = 101;
COMMIT;

🔹 Use Case: Ensures deposit transactions are saved permanently.


4.2 ROLLBACK – Undoing an Uncommitted Transaction
Example (Rolling Back a Failed Money Transfer)

BEGIN TRANSACTION;
UPDATE Customers SET Balance = Balance - 5000 WHERE CustomerID = 101;
UPDATE Customers SET Balance = Balance + 5000 WHERE CustomerID = 102;
ROLLBACK; -- If an error occurs

🔹 Use Case: If money is debited from one account but cannot be credited to another, rollback
restores the original state.

4.3 SAVEPOINT – Creating a Savepoint Within a Transaction


Example (Creating a Savepoint Before Updating Balance)

BEGIN TRANSACTION;
UPDATE Customers SET Balance = Balance - 5000 WHERE CustomerID = 101;
SAVEPOINT BeforeCredit;
UPDATE Customers SET Balance = Balance + 5000 WHERE CustomerID = 102;
ROLLBACK TO BeforeCredit;
COMMIT;

🔹 Use Case: A bank may use SAVEPOINT to revert only specific operations within a transaction.
SQL Queries for Banking System
1. Create a Customers Table
CREATE TABLE Customers (
CustomerID INT PRIMARY KEY,
Name VARCHAR(100),
Email VARCHAR(100) UNIQUE,
Phone VARCHAR(15),
Balance DECIMAL(10,2)
);
2. Insert Data into Customers Table
INSERT INTO Customers (CustomerID, Name, Email, Phone, Balance)
VALUES (101, 'Rahul Sharma', '[email protected]', '9876543210', 50000.00);

3. Fetch All Customers


SELECT * FROM Customers;

4. Retrieve Customers with Balance Above ₹10,000


SELECT Name, Balance FROM Customers WHERE Balance > 10000;

5. Update Account Balance


UPDATE Customers SET Balance = Balance + 5000 WHERE CustomerID = 101;

6. Delete a Customer Record


DELETE FROM Customers WHERE CustomerID = 101;

7. Create a Transactions Table


CREATE TABLE Transactions (
TransactionID INT PRIMARY KEY,
CustomerID INT,
Amount DECIMAL(10,2),
TransactionType VARCHAR(10), -- 'Credit' or 'Debit'
Date TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
);

8. Insert a Transaction Record


INSERT INTO Transactions (TransactionID, CustomerID, Amount, TransactionType)
VALUES (201, 101, 10000, 'Credit');

9. Fetch All Transactions of a Customer


SELECT * FROM Transactions WHERE CustomerID = 101 ORDER BY Date DESC;

10. Calculate Total Deposits for a Customer


SELECT SUM(Amount) AS TotalDeposits FROM Transactions WHERE CustomerID = 101 AND TransactionType =
'Credit';

11. Count the Number of Customers


SELECT COUNT(*) AS TotalCustomers FROM Customers;

12. Find the Customer with the Highest Balance


SELECT Name, Balance FROM Customers ORDER BY Balance DESC LIMIT 1;

13. Retrieve Transactions in the Last 30 Days


SELECT * FROM Transactions WHERE Date >= NOW() - INTERVAL 30 DAY;
14. Join Customers and Transactions Table
SELECT c.Name, t.Amount, t.TransactionType, t.Date
FROM Customers c
JOIN Transactions t ON c.CustomerID = t.CustomerID;

15. Group Transactions by Type


SELECT TransactionType, COUNT(*) AS TotalTransactions
FROM Transactions
GROUP BY TransactionType;

SQL Query Output Questions(IMPORTANT)


1. What will be the output of the following query?
SELECT COUNT(*) AS TotalCustomers FROM Customers;

| (Assume there are 5 records in the Customers table) |


Options:
(a) 0
(b) 5
(c) NULL
(d) Error
✅ Correct Answer: (b) 5
2. What will the following query return?
SELECT Name, Balance FROM Customers WHERE Balance > 10000;

| Customers Table (Sample Data) |

CustomerID Name Balance

101 Rahul 50000.00

102 Sneha 9000.00

103 Aman 20000.00

Options:
(a) Rahul - 50000, Sneha - 9000, Aman - 20000
(b) Rahul - 50000, Aman - 20000
(c) Sneha - 9000
(d) Error
✅ Correct Answer: (b) Rahul - 50000, Aman - 20000
3. What will be the result of this query?
SELECT SUM(Amount) AS TotalDeposits FROM Transactions WHERE TransactionType = 'Credit';

| Transactions Table (Sample Data) |

TransactionID CustomerID Amount TransactionType

201 101 10000.00 Credit

202 102 5000.00 Debit

203 101 8000.00 Credit

Options:
(a) 18000
(b) 15000
(c) 13000
(d) 10000
✅ Correct Answer: (a) 18000
4. What will the following query return?
SELECT Name FROM Customers WHERE CustomerID IN (SELECT CustomerID FROM Transactions WHERE Amount > 5000);

Customers Transactions
Table Table

CustomerID Name

101 Rahul

102 Sneha

103 Aman

Options:
(a) Rahul, Aman
(b) Rahul, Sneha
(c) Aman
(d) No Output
✅ Correct Answer: (a) Rahul, Aman
5. What will be the output of this query?
SELECT Name, Balance FROM Customers ORDER BY Balance DESC LIMIT 1;

| Customers Table |

CustomerID Name Balance

101 Rahul 50000.00

102 Sneha 9000.00

103 Aman 20000.00

Options:
(a) Rahul - 50000
(b) Sneha - 9000
(c) Aman - 20000
(d) No Output
✅ Correct Answer: (a) Rahul - 50000

ACID Properties in DBMS


ACID (Atomicity, Consistency, Isolation, Durability) is a set of database transaction properties that
ensure data integrity and reliability:

ACID Properties
The expansion of the term ACID defines for:

Property Definition Key Point Example


Atomicity Ensures that a Partial execution A customer transfers ₹5,000 from
transaction is is not allowed; their SBI account to another. If the
either executed all operations debit happens but the credit fails
fully or not at all. must succeed due to a network issue, atomicity is
together. violated.

Consistency Guarantees that Ensures data During loan approval, if the EMI
the database integrity and schedule is updated in one record
remains in a valid correctness. but not reflected in the customer's
state before and loan account summary, consistency
after a is violated.
transaction.

Isolation Ensures that Changes in one Two SBI customers withdraw cash
concurrent transaction simultaneously from the same
transactions do should not be ATM. Isolation ensures that neither
not interfere with visible to others transaction interferes, and account
each other and until committed. balances are updated correctly.
appear to execute
sequentially.

Durability Ensures that once Committed data After a fixed deposit is created, the
a transaction is is preserved; transaction details are permanently
committed, its recovery saved in the SBI database, even if
changes are manager the system crashes after issuing
permanent, even ensures the confirmation receipt.
in the event of a durability after
system failure. crashes.

Q) If a partial-transaction is not roll-backed in a database it violates


(SBI SO 2024 , IBPS SO 2024)
A) durability
B) consistency
C) atomicity
D) integrity
E) vitality
Ans)(atomicity)

ER (Entity Relationship) Diagram in DBMS


ER model stands for an Entity-Relationship model. It is a high-level data model. This model is

used to define the data elements and relationship for a specified system.

Components of ER Model:

1. Entity:
An entity may be any object, class, person or place. In the ER diagram, an entity can be
represented as rectangles.
Consider an organization as an example- manager, product, employee, department etc. can be
taken as an entity.
There are two main types of entities:
1. Strong Entity (Independent): Exists independently (e.g., Student, Employee).
2. Weak Entity (Dependent): Exists only with a strong entity (e.g., Address, Order Item).

2. Attribute
The attribute is used to describe the property of an entity. Eclipse is used to represent an
attribute.
For example, id, age, contact number, name, etc. can be attributes of a student.

a. Key Attribute
The key attribute is used to represent the main characteristics of an entity. It represents a primary
key. The key attribute is represented by an ellipse with the text underlined.

b. Composite Attribute
An attribute that composed of many other attributes is known as a composite attribute. The
composite attribute is represented by an ellipse, and those ellipses are connected with an ellipse.

c. Multivalued Attribute
An attribute can have more than one value. These attributes are known as a multivalued attribute.
The double oval is used to represent multivalued attribute.
For example, a student can have more than one phone number.

d. Derived Attribute
An attribute that can be derived from other attribute is known as a derived attribute. It can be
represented by a dashed ellipse.
For example, A person's age changes over time and can be derived from another attribute like
Date of birth.

3. Relationship
A relationship is used to describe the relation between entities. Diamond or rhombus is used to
represent the relationship.

Types of relationship are as follows:


a. One-to-One Relationship
When only one instance of an entity is associated with the relationship, then it is known as one to
one relationship.
For example, A female can marry to one male, and a male can marry to one female.

b. One-to-many relationship
When only one instance of the entity on the left, and more than one instance of an entity on the
right associates with the relationship then this is known as a one-to-many relationship.
For example, Scientist can invent many inventions, but the invention is done by the only specific
scientist.

c. Many-to-one relationship
When more than one instance of the entity on the left, and only one instance of an entity on the
right associates with the relationship then it is known as a many-to-one relationship.
For example, Student enrolls for only one course, but a course can have many students.

d. Many-to-many relationship
When more than one instance of the entity on the left, and more than one instance of an entity on
the right associates with the relationship then it is known as a many-to-many relationship.
For example, Employee can assign by many projects and project can have many employees.

Direct: Directly linked entities.



Indirect: Linked via an intermediate entity.

Composite: A relationship with multiple components or attributes.

Associative: Many-to-many relationship represented by a new entity.

Notations for ER Diagram:
Keys
Keys play an important role in the relational database.

It is used to uniquely identify any record or row of data from the table. It is also used to

establish and identify relationships between tables.
For example, ID is used as a key in the Student table because it is unique for each student. In the
PERSON table, passport_number, license_number, SSN are keys since they are unique for each
person.
Types of keys:

1. Primary key
It is the first key used to identify one and only one instance of an entity uniquely. An entity

can contain multiple keys, as we saw in the PERSON table. The key which is most suitable
from those lists becomes a primary key.

In the EMPLOYEE table, ID can be the primary key since it is unique for each employee. In the

EMPLOYEE table, we can even select License_Number and Passport_Number as primary keys
since they are also unique.

For each entity, the primary key selection is based on requirements and developers.

2. Candidate key
A candidate key is an attribute or set of attributes that can uniquely identify a tuple.

Except for the primary key, the remaining attributes are considered a candidate key. The

candidate keys are as strong as the primary key.
For example: In the EMPLOYEE table, id is best suited for the primary key. The rest of the
attributes, like SSN, Passport_Number, License_Number, etc., are considered a candidate key.

3. Super Key
Super key is an attribute set that can uniquely identify a tuple. A super key is a superset of a
candidate key.
For example: In the above EMPLOYEE table, for(EMPLOEE_ID, EMPLOYEE_NAME), the name of two
employees can be the same, but their EMPLYEE_ID can't be the same. Hence, this combination
can also be a key.
The super key would be EMPLOYEE-ID (EMPLOYEE_ID, EMPLOYEE-NAME), etc.

4. Foreign key
Foreign keys are the column of the table used to point to the primary key of another table.

Every employee works in a specific department in a company, and employee and

department are two different entities. So we can't store the department's information in the
employee table. That's why we link these two tables through the primary key of one table.

We add the primary key of the DEPARTMENT table, Department_Id, as a new attribute in the

EMPLOYEE table.

In the EMPLOYEE table, Department_Id is the foreign key, and both the tables are related.

5. Alternate key
There may be one or more attributes or a combination of attributes that uniquely identify each
tuple in a relation. These attributes or combinations of the attributes are called the candidate
keys. One key is chosen as the primary key from these candidate keys, and the remaining
candidate key, if it exists, is termed the alternate key. In other words, the total number of the
alternate keys is the total number of candidate keys minus the primary key. The alternate key may
or may not exist. If there is only one candidate key in a relation, it does not have an alternate key.
For example, employee relation has two attributes, Employee_Id and PAN_No, that act as
candidate keys. In this relation, Employee_Id is chosen as the primary key, so the other candidate
key, PAN_No, acts as the Alternate key.

6. Composite key
Whenever a primary key consists of more than one attribute, it is known as a composite key. This
key is also known as Concatenated Key.

For example, in employee relations, we assume that an employee may be assigned multiple
roles, and an employee may work on multiple projects simultaneously. So the primary key will be
composed of all three attributes, namely Emp_ID, Emp_role, and Proj_ID in combination. So these
attributes act as a composite key since the primary key comprises more than one attribute.
7. Artificial key
The key created using arbitrarily assigned data are known as artificial keys. These keys are created
when a primary key is large and complex and has no relationship with many other relations. The
data values of the artificial keys are usually numbered in a serial order.

For example, the primary key, which is composed of Emp_ID, Emp_role, and Proj_ID, is large in
employee relations. So it would be better to add a new virtual attribute to identify each tuple in
the relation uniquely.

Relational Algebra
Relational algebra is a procedural query language. It gives a step by step process to obtain the
result of the query. It uses operators to perform queries.

Types of Relational operation


1. Select Operation:
The select operation selects tuples that satisfy a given predicate.

It is denoted by sigma (σ).

1. Notation: σ p(r)
Where:
σ is used for selection prediction
r is used for relation
p is used as a propositional logic formula which may use connectors like: AND OR and NOT. These
relational can use as relational operators like =, ≠, ≥, <, >, ≤.
For example: LOAN Relation

BRANCH_NAME LOAN_NO AMOUNT

Downtown L-17 1000

Redwood L-23 2000

Perryride L-15 1500

Downtown L-14 1500

Mianus L-13 500

Roundhill L-11 900

Perryride L-16 1300

Input:
1. σ BRANCH_NAME="perryride" (LOAN)
Output:

BRANCH_NAME LOAN_NO AMOUNT

Perryride L-15 1500

Perryride L-16 1300

2. Project Operation:
This operation shows the list of those attributes that we wish to appear in the result. Rest of

the attributes are eliminated from the table.

It is denoted by ∏.

1. Notation: ∏ A1, A2, An (r)
Where
A1, A2, A3 is used as an attribute name of relation r.
Example: CUSTOMER RELATION

NAME STREET CITY

Jones Main Harrison

Smith North Rye

Hays Main Harrison

Curry North Rye

Johnson Alma Brooklyn

Brooks Senator Brooklyn

Input:
1. ∏ NAME, CITY (CUSTOMER)
Output:

NAME CITY

Jones Harrison

Smith Rye

Hays Harrison

Curry Rye

Johnson Brooklyn

Brooks Brooklyn

3. Union Operation:
Suppose there are two tuples R and S. The union operation contains all the tuples that are

either in R or S or both in R & S.

It eliminates the duplicate tuples. It is denoted by ∪.



1. Notation: R ∪ S
A union operation must hold the following condition:
R and S must have the attribute of the same number.

Duplicate tuples are eliminated automatically.

Example:
DEPOSITOR RELATION

CUSTOMER_NAME ACCOUNT_NO

Johnson A-101

Smith A-121

Mayes A-321

Turner A-176

Johnson A-273

Jones A-472

Lindsay A-284

BORROW RELATION

CUSTOMER_NAME LOAN_NO

Jones L-17

Smith L-23

Hayes L-15

Jackson L-14

Curry L-93

Smith L-11

Williams L-17

Input:
1. ∏ CUSTOMER_NAME (BORROW) ∪ ∏ CUSTOMER_NAME (DEPOSITOR)
Output:
CUSTOMER_NAME
Johnson
Smith
Hayes
Turner
Jones
Lindsay
Jackson
Curry
Williams
Mayes

4. Set Intersection:
Suppose there are two tuples R and S. The set intersection operation contains all tuples that

are in both R & S.

It is denoted by intersection ∩.

1. Notation: R ∩ S
Example: Using the above DEPOSITOR table and BORROW table
Input:
1. ∏ CUSTOMER_NAME (BORROW) ∩ ∏ CUSTOMER_NAME (DEPOSITOR)
Output:
CUSTOMER_NAME
Smith
Jones

5. Set Difference:
Suppose there are two tuples R and S. The set intersection operation contains all tuples that

are in R but not in S.

It is denoted by intersection minus (-).



1. Notation: R - S
Example: Using the above DEPOSITOR table and BORROW table
Input:
1. ∏ CUSTOMER_NAME (BORROW) - ∏ CUSTOMER_NAME (DEPOSITOR)
Output:
CUSTOMER_NAME
Jackson
Hayes
Willians
Curry

6. Cartesian product
The Cartesian product is used to combine each row in one table with each row in the other

table. It is also known as a cross product.

It is denoted by X.

1. Notation: E X D

Example:
EMPLOYEE

EMP_ID EMP_NAME EMP_DEPT

1 Smith A

2 Harry C

3 John B

DEPARTMENT

DEPT_NO DEPT_NAME

A Marketing

B Sales

C Legal

Input:
1. EMPLOYEE X DEPARTMENT
Output:

EMP_ID EMP_NAME EMP_DEPT DEPT_NO DEPT_NAME

1 Smith A A Marketing

1 Smith A B Sales

1 Smith A C Legal

2 Harry C A Marketing

2 Harry C B Sales
2 Harry C C Legal

3 John B A Marketing

3 John B B Sales

3 John B C Legal

7. Rename Operation:
The rename operation is used to rename the output relation. It is denoted by rho (ρ).
Example: We can use the rename operator to rename STUDENT relation to STUDENT1.
1. ρ(STUDENT1, STUDENT)

Join Operations:
A Join operation combines related tuples from different relations, if and only if a given join
condition is satisfied. It is denoted by ⋈.

Example:
EMPLOYEE

EMP_CODE EMP_NAME

101 Stephan

102 Jack

103 Harry

SALARY

EMP_CODE SALARY

101 50000

102 30000

103 25000

1. Operation: (EMPLOYEE ⋈ SALARY)


Result:

EMP_CODE EMP_NAME SALARY

101 Stephan 50000


102 Jack 30000

103 Harry 25000

Types of Join operations:

1. Natural Join:
A natural join is the set of tuples of all combinations in R and S that are equal on their

common attribute names.

It is denoted by ⋈.

Example: Let's use the above EMPLOYEE table and SALARY table:
Input:
1. ∏EMP_NAME, SALARY (EMPLOYEE ⋈ SALARY)
Output:

EMP_NAME SALARY

Stephan 50000

Jack 30000
Harry 25000

2. Outer Join:
The outer join operation is an extension of the join operation. It is used to deal with missing
information.
Example:
EMPLOYEE

EMP_NAME STREET CITY

Ram Civil line Mumbai

Shyam Park street Kolkata

Ravi M.G. Street Delhi

Hari Nehru nagar Hyderabad

FACT_WORKERS

EMP_NAME BRANCH SALARY

Ram Infosys 10000

Shyam Wipro 20000

Kuber HCL 30000

Hari TCS 50000

Input:
1. (EMPLOYEE ⋈ FACT_WORKERS)
Output:

EMP_NAME STREET CITY BRANCH SALARY

Ram Civil line Mumbai Infosys 10000

Shyam Park street Kolkata Wipro 20000

Hari Nehru nagar Hyderabad TCS 50000

An outer join is basically of three types:


1. Left outer join
2. Right outer join

3. Full outer join

a. Left outer join:


Left outer join contains the set of tuples of all combinations in R and S that are equal on their

common attribute names.

In the left outer join, tuples in R have no matching tuples in S.



It is denoted by ⟕.

Example: Using the above EMPLOYEE table and FACT_WORKERS table
Input:
1. EMPLOYEE ⟕ FACT_WORKERS

EMP_NAME STREET CITY BRANCH SALARY

Ram Civil line Mumbai Infosys 10000

Shyam Park street Kolkata Wipro 20000

Hari Nehru street Hyderabad TCS 50000

Ravi M.G. Street Delhi NULL NULL

b. Right outer join:


Right outer join contains the set of tuples of all combinations in R and S that are equal on

their common attribute names.

In right outer join, tuples in S have no matching tuples in R.



It is denoted by ⟖.

Example: Using the above EMPLOYEE table and FACT_WORKERS Relation
Input:
1. EMPLOYEE ⟖ FACT_WORKERS
Output:

EMP_NAME BRANCH SALARY STREET CITY

Ram Infosys 10000 Civil line Mumbai

Shyam Wipro 20000 Park street Kolkata

Hari TCS 50000 Nehru street Hyderabad


Kuber HCL 30000 NULL NULL

c. Full outer join:


Full outer join is like a left or right join except that it contains all rows from both tables.

In full outer join, tuples in R that have no matching tuples in S and tuples in S that have no

matching tuples in R in their common attribute name.

It is denoted by ⟗.

Example: Using the above EMPLOYEE table and FACT_WORKERS table
Input:
1. EMPLOYEE ⟗ FACT_WORKERS
Output:

EMP_NAME STREET CITY BRANCH SALARY

Ram Civil line Mumbai Infosys 10000

Shyam Park street Kolkata Wipro 20000

Hari Nehru street Hyderabad TCS 50000

Ravi M.G. Street Delhi NULL NULL

Kuber NULL NULL HCL 30000

3. Equi join:
It is also known as an inner join. It is the most common join. It is based on matched data as per
the equality condition. The equi join uses the comparison operator(=).

Integrity Constraints:
Type Definition Example SQL Example

Domain Limit attribute values Age must be CHECK (Age >= 0 AND
Constraints to a specific set/type. between 0 Age <= 120)
and 120.

Entity Primary key cannot CustomerID in PRIMARY KEY


Integrity be null (must be Customers (CustomerID)
unique). table must
be non-null.

Referential Foreign key must CustomerID in FOREIGN KEY


Integrity refer to a valid Orders must (CustomerID)
primary key. exist in REFERENCES
Customers . Customers(CustomerID)

Key Ensure uniqueness Composite PRIMARY KEY


Constraints of key key of (ProductID,
attributes/identifiers. ProductID WarehouseID)
and
WarehouseID .

Relational Calculus
Relational Calculus is a non-procedural query language in databases that specifies what to
retrieve rather than how to retrieve it, using mathematical predicates and conditions
Types of Relational calculus: The two types of relational calculus are Tuple Relational Calculus
(TRC), which uses tuples to express queries, and Domain Relational Calculus (DRC), which uses
domain variables to specify conditions.

Normalization
Functional Dependency
The functional dependency is a relationship that exists between two attributes. It typically exists
between the primary key and non-key attribute within a table.
1. X → Y
The left side of FD is known as a determinant, the right side of the production is known as a
dependent.
For example:
Functional dependency can be written as:
1. Emp_Id → Emp_Name
We can say that Emp_Name is functionally dependent on Emp_Id.

Types of Functional dependency


1. Trivial functional dependency
A → B has trivial functional dependency if B is a subset of A.

The following dependencies are also trivial like: A → A, B → B

2. Non-trivial functional dependency
A → B has a non-trivial functional dependency if B is not a subset of A.

When A intersection B is NULL, then A → B is called as complete non-trivial.

Example:
1. ID → Name,

2. Name → DOB

Inference Rules
Normalization
A large database defined as a single relation may result in data duplication. This repetition of data
may result in:
Wastage and poor utilization of disk space and resources.

The likelihood of errors and inconsistencies increases.

What is Normalization?
Normalization is the process of organizing the data in the database.

Normalization is used to minimize the redundancy from a relation or set of relations. It is

also used to eliminate undesirable characteristics like Insertion, Update, and Deletion
Anomalies.

Normalization divides the larger table into smaller and links them using relationships.

Why do we need Normalization?
The main reason for normalizing the relations is removing these anomalies. Failure to eliminate
anomalies leads to data redundancy and can cause data integrity and other problems as the
database grows.
Data modification anomalies can be categorized into three types:
Insertion Anomaly: Insertion Anomaly refers to when one cannot insert a new tuple into a

relationship due to lack of data.

Deletion Anomaly: The delete anomaly refers to the situation where the deletion of data

results in the unintended loss of some other important data.

Updation Anomaly: The update anomaly is when an update of a single data value requires

multiple rows of data to be updated.

Types of Normal Forms:


Normalization works through a series of stages called Normal forms. The normal forms apply to
individual relations. The relation is said to be in particular normal form if it satisfies constraints.
Following are the various types of Normal forms:

Normal Description
Form

1NF First Normal Form: Ensures atomic values and no


repeating groups.

2NF Second Normal Form: Eliminates partial dependencies.

3NF Third Normal Form: Eliminates transitive dependencies.


BCNF Boyce-Codd Normal Form: Every determinant must be a
candidate key.

4NF Fourth Normal Form: Eliminates multi-valued


dependencies.

5NF Fifth Normal Form: Eliminates join dependencies and


redundancy in join operations.

3NF Property

BCNF is also known as (SBI SO 2024)


A) 1.5NF
B) 3.5NF
C) 4.5NF
D) 2.5NF
Answer(3.5)

Normalization Questions Based on Functional Dependencies

1. Given the Following Functional Dependencies, Identify the Highest


Normal Form
Functional Dependencies:
1. A → B, C

2. B → D

3. C → E
🔹 Options:
(a) 1NF
(b) 2NF
(c) 3NF
(d) BCNF
✅ Correct Answer: (b) 2NF
👉 Reason: Partial dependency exists (A → B, C, but B → D and C → E cause redundancy).
2. Identify the Normal Form for This Relation
Functional Dependencies:
1. StudentID → StudentName, CourseID, CourseName

2. CourseID → CourseName
🔹 Options:
(a) 1NF
(b) 2NF
(c) 3NF
(d) BCNF
✅ Correct Answer: (c) 3NF
👉 Reason: There is a transitive dependency (StudentID → CourseID → CourseName), which
needs to be removed for BCNF.

3. What is the Normal Form of the Following Dependencies?


Functional Dependencies:
1. EmpID → EmpName, DeptID

2. DeptID → DeptName, ManagerID

3. ManagerID → ManagerName
🔹 Options:
(a) 1NF
(b) 2NF
(c) 3NF
(d) BCNF
✅ Correct Answer: (c) 3NF
👉 Reason: There is a transitive dependency (EmpID → DeptID → DeptName), which means the
relation is in 3NF but not BCNF.

4. Given This Functional Dependency Set, Find the Normal Form


Functional Dependencies:
1. OrderID → CustomerID, CustomerName, ProductID, ProductName

2. ProductID → ProductName
🔹 Options:
(a) 1NF
(b) 2NF
(c) 3NF
(d) BCNF
✅ Correct Answer: (c) 3NF
👉 Reason: There is a transitive dependency (OrderID → ProductID → ProductName), which
needs to be removed for BCNF.

5. What Normal Form is This Table In?


Functional Dependencies:
1. A, B → C, D

2. C → E
🔹 Options:
(a) 1NF
(b) 2NF
(c) 3NF
(d) BCNF
✅ Correct Answer: (b) 2NF
👉 Reason: C → E introduces a partial dependency, meaning the table is in 2NF but not 3NF.

Indexing
What is Indexing?
Indexing in SQL is a technique used to speed up data retrieval operations on a database table.
An index is similar to the index of a book—it helps the database quickly locate the required
records without scanning the entire table.

Types of Indexing
1. Primary Index (Clustered Index)
Definition: A primary index is automatically created on the primary key column of a table.

Storage: The rows in the table are physically sorted based on the indexed column.

Use in Banking:

Faster retrieval of customer details based on CustomerID .

Efficient account number-based searches.

✅ Example (Primary Index in Customer Table)
CREATE TABLE Customers (
CustomerID INT PRIMARY KEY,
Name VARCHAR(100),
Email VARCHAR(100) UNIQUE,
Phone VARCHAR(15),
Balance DECIMAL(10,2)
);

🔹 Here, CustomerID is a clustered index since it is the primary key.

2. Secondary Index (Non-Clustered Index)


Definition: A secondary index is created on non-primary key columns to improve query

performance.

Storage: It stores a pointer to the actual row, unlike a clustered index.



Use in Banking:

Searching customers by email or phone number.

Retrieving transactions using date and time.

✅ Example (Non-Clustered Index on Email Column)
CREATE INDEX idx_email ON Customers(Email);

🔹 This allows faster searches when querying by email.


3. Unique Index
Definition: Ensures that a column contains unique values (prevents duplicates).

Use in Banking:

Ensuring unique account numbers.

Avoiding duplicate customer emails.

✅ Example (Unique Index on Account Number)
CREATE UNIQUE INDEX idx_account_number ON Accounts(AccountNumber);
🔹 This prevents duplicate account numbers.
4. Composite Index (Multi-Column Index)
Definition: Indexes multiple columns together to speed up queries with multiple WHERE

conditions.

Use in Banking:

Searching transactions based on AccountID and Date.

Fetching customer records using Name and City.

✅ Example (Composite Index for Faster Searches)
CREATE INDEX idx_transaction ON Transactions(AccountID, TransactionDate);

🔹 This improves query performance for searches on both AccountID and TransactionDate .

5. Full-Text Index
Definition: Used for fast text-based searches in large text fields.

Use in Banking:

Searching logs or descriptions in fraud detection systems.

Retrieving customer complaints and feedback using keywords.

✅ Example (Full-Text Index on Complaint Table)
CREATE FULLTEXT INDEX idx_complaint ON Complaints(ComplaintDetails);

🔹 Allows efficient searches on customer complaints.


6. Bitmap Index
Definition: Uses bitmaps (binary values) instead of B-Trees to index columns with low-

cardinality values (few unique values).

Use in Banking:

Indexing loan status (Approved, Pending, Rejected).

Faster retrieval of account types (Savings, Current, Fixed Deposit).

✅ Example (Bitmap Index on Loan Status)
CREATE BITMAP INDEX idx_loan_status ON Loans(Status);

🔹 Improves query performance when searching for loans based on status.


Index Type Summary :
Index Type Description

Primary Index Automatically created with a primary key,


clustered, ensures unique values.

Secondary Index Non-clustered index, speeds up queries on non-


primary key columns.

Unique Index Ensures unique values in a column, created for


UNIQUE constraints.

Composite Index Index on multiple columns, improves queries


with multiple conditions.

Clustered Index Data stored in order of index, only one per table.

Non-clustered Index Index stored separately, allows multiple indexes


per table.

Locks:
Type of Description Example Effect on Other Transactions
Lock Operations

Shared Lock Allows multiple SELECT Others can read, but no updates
(S) transactions to read or deletes are allowed.
data but prevents
writes.

Exclusive Prevents other INSERT , No other transaction can access


Lock (X) transactions from UPDATE , the table until the lock is
reading or writing. DELETE released.

Intent Indicates intention to Preparing for Other transactions can acquire IS


Shared (IS) place shared locks on SELECT or IX but not X locks.
specific rows.

Intent Indicates intention to Preparing for Others can acquire IS locks but
Exclusive place exclusive locks on UPDATE no shared or exclusive locks.
(IX) specific rows.
Shared Allows shared reads but SELECT with Other transactions can read but
Intent restricts others from row update not modify.
Exclusive acquiring exclusive prep
locks.

Row Locks Locks specific rows UPDATE WHERE Other transactions can access
(Row-Level) while allowing table- id=1 rows not locked but respect table
level intent locks for intents.
broader access.

Table Lock Locks the entire table ALTER TABLE No access (read/write) by others
(Full) for read or write until the operation completes.
operations.

You might also like