ER-Diagram:

Schema Diagram:

ER Diagram → Relational Tables Conversion

Below is the relational schema (tables) derived from the ER diagram.

1. Coach Table

Coach(Coach_ID, Coach_name)

* Primary Key: Coach_ID

2. Team Table

Team(Team_ID, Team_name, Coach_ID)

* Primary Key: Team_ID * Foreign Key: Coach_ID → Coach(Coach_ID)

3. Player Table

Player(Player_ID, Player_name, Player_position, Team_ID)

* Primary Key: Player_ID * Foreign Key: Team_ID → Team(Team_ID)

4. Stadium Table

Stadium(Stadium_ID, Stadium_name, Stadium_location)

* Primary Key: Stadium_ID

5. Game Table

Game(Game_no, Game_name, Game_time)

* Primary Key: Game_no

6. Match Table

Match(Match_ID, Match_date, Match_result, Stadium_ID, Game_no)

* Primary Key: Match_ID * Foreign Key:

* Stadium_ID → Stadium(Stadium_ID) * Game_no → Game(Game_no)

Atomicity

• Atomicity means a transaction is treated as a single unit → either fully completed or not executed at all.

Reason:

• All-or-Nothing Execution: In fund transfer, money must be debited and credited together.
• Prevents Data Inconsistency: If debit happens but credit fails → money is lost.
• Error Handling: If any step fails, the system performs rollback to restore original state.
• Maintains Trust: Ensures reliable banking transactions between two banks.
• Avoids Partial Transactions: No situation where one account is updated and the other is not.

Example:

• Transfer 1000 Tk from Account A (Bank 1) to Account B (Bank 2).
• If system crashes after debit but before credit → without atomicity, money is lost
• With atomicity → transaction is rolled back, so no loss

Two-Phase Locking (2PL) Analysis for Concurrent Transactions

Transaction Details:

• T1: Read(X), Write(X), Read(Y), Write(Y)
• T2: Read(Y), Write(Y), Read(X), Write(X)

Standard 2PL Execution

In standard 2PL, each transaction has a growing phase (only acquiring locks) and a shrinking phase (only releasing locks). Both transactions request exclusive locks because they intend to write.

Step-by-Step Interleaving:

Operational State Entered: DEADLOCK

The system enters a deadlock (circular wait). T1 holds X and waits for Y, while T2 holds Y and waits for X. Neither transaction can proceed. The database must detect this using a wait-for graph or timeout and resolve it by aborting one transaction.

Strict 2PL Protocol

• Standard 2PL: Locks may be released after use in the shrinking phase, but here deadlock prevents progress.
• Strict 2PL: All locks are held until commit or abort, preventing exposure of uncommitted data.

Contrast Table:

Key Takeaway: Strict 2PL does not remove deadlock in this schedule but ensures strict isolation by holding locks until termination.

ACID Properties in Database Transactions
ACID properties are a set of rules that ensure reliability, consistency, and integrity of a database during transactions. Each transaction must satisfy these four properties to maintain a correct database state.

1) Atomicity
Atomicity ensures that a transaction is treated as a single unit. Either all operations of the transaction are completed successfully, or none of them are applied. If any part fails, the entire transaction is rolled back, preventing partial updates.

2) Consistency
Consistency ensures that a transaction moves the database from one valid state to another valid state. All integrity constraints, rules, and conditions must be satisfied before and after the transaction.

3) Isolation
Isolation ensures that multiple transactions executed at the same time do not interfere with each other. Each transaction behaves as if it is executed independently, preventing problems like dirty reads or lost updates.

4) Durability
Durability guarantees that once a transaction is committed, its changes are permanently stored in the database. Even if the system crashes, the committed data will not be lost.

Consistency Property in ACID

• Consistency ensures that a database always remains in a valid state before and after a transaction.
• During a bank fund transfer transaction, consistency guarantees that all database rules and constraints are maintained properly.

For example, if money is transferred from one account to another:

• The amount deducted from one account must be added to the other account correctly.
• The total balance in the system must remain consistent.
• No account balance can become invalid or violate database rules.

If any part of the transaction fails, the entire transaction is rolled back to preserve consistency.

SQL Constraint Clause

To ensure that the current_balance column never becomes negative, the following CHECK constraint can be used:

CHECK (current_balance >= 0)

Example in Table Schema

CREATE TABLE Savings_Accounts (
    account_id INT PRIMARY KEY,
    customer_name VARCHAR(100),
    current_balance DECIMAL(10,2),
    
    CHECK (current_balance >= 0)
);

ACID Properties in Database Transactions
ACID properties are a set of rules that ensure reliability, consistency, and integrity of a database during transactions. Each transaction must satisfy these four properties to maintain a correct database state.

1) Atomicity
Atomicity ensures that a transaction is treated as a single unit. Either all operations of the transaction are completed successfully, or none of them are applied. If any part fails, the entire transaction is rolled back, preventing partial updates.

2) Consistency
Consistency ensures that a transaction moves the database from one valid state to another valid state. All integrity constraints, rules, and conditions must be satisfied before and after the transaction.

3) Isolation
Isolation ensures that multiple transactions executed at the same time do not interfere with each other. Each transaction behaves as if it is executed independently, preventing problems like dirty reads or lost updates.

4) Durability
Durability guarantees that once a transaction is committed, its changes are permanently stored in the database. Even if the system crashes, the committed data will not be lost.

Normalization in Database:
Normalization is the process of organizing data in a database to reduce redundancy and improve data integrity. It divides large tables into smaller related tables and defines relationships between them.

Goals of Normalization:

• Eliminate duplicate data
• Ensure data consistency
• Improve database structure

Common Normal Forms:

• 1NF → Remove repeating groups
• 2NF → Remove partial dependency
• 3NF → Remove transitive dependency

Before Normalization (Unnormalized ER/Table):

Problem:

• Data redundancy (same student & course repeated)
• Update anomaly
• Insertion/deletion problem

After Normalization (ER Diagram):

• STUDENT and COURSE are separate tables (normalized)
• ENROLLMENT table removes redundancy and maintains relationship
• No redundancy
• Better structure
• Easy update, insert, delete

Normalization is the process of organizing data in a database to reduce redundancy and improve data integrity. It involves dividing large tables into smaller ones and defining relationships between them. The main goal is to eliminate duplicate data and ensure that data dependencies make sense. Normalization follows a set of rules called normal forms, such as 1NF, 2NF, 3NF, and so on.

1NF (First Normal Form)

1NF is the first step in normalization. A table is in 1NF when it follows these rules:

• Atomic values: Each table cell must contain only a single value, not multiple values or lists.
• Same data type: Each column should hold values of the same type.
• Unique rows: Every row must be different from others. No repeating groups are allowed.
• Unique column names: Each column must have a distinct name.

Example of 1NF:

Before (Not in 1NF):

The "Subjects" column has two values in one cell, which breaks the atomic rule.

After (In 1NF):

Now each cell holds a single value, and the table follows 1NF rules.

2NF (Second Normal Form)

A table is in 2NF when it is already in 1NF and has no partial dependency. This means a non-key column must depend on the entire primary key, not just a part of it. 2NF is especially important when the primary key is made of two or more columns (composite key).

Must be in 1NF first.

• No partial dependency: Every non-key attribute must depend on the whole primary key.

Example of 2NF:

Before (Not in 2NF):

Primary key = (StudentID + SubjectID).
Problem: StudentName depends only on StudentID, not on the full key. This is partial dependency.

After (In 2NF):

Student Table:

Subject Table:

Enrollment Table:

Now each non-key attribute depends on the full primary key of its own table, and partial dependency is removed.

RAID (Redundant Array of Independent Disks) is a technology that combines multiple physical disks into a single logical unit to improve performance, reliability, and data availability.

• Techniques: Uses striping, mirroring, and parity.
• Goal: Faster data access and protection against disk failure

Relevance in Database

RAID is highly important in database systems because databases require high speed and data reliability.

• Ensures continuous database availability.
• Prevents data loss due to disk failure.
• Improves read/write performance.

Uses in Database

• RAID 1: Used for critical data (mirroring for safety).
• RAID 5: Used for balance of performance and storage efficiency.
• RAID 10: Used for high-performance databases.
• Backup Systems: Ensures data redundancy.

Is it Possible?

Yes, RAID is widely used in database systems.

• Implemented using hardware RAID controllers or software RAID.
• Common in servers, data centers, and enterprise systems.
• Essential for systems like banking, e-commerce, and cloud databases.

DBMS (Database Management System)

A DBMS is software that is used to create, store, manage, and retrieve data efficiently from a database. It provides an interface between users/applications and the database.

Virtual Memory

Virtual memory is a memory management technique that uses a part of secondary storage (hard disk) as an extension of main memory (RAM). It allows programs to run even if the physical memory is insufficient.

Cache Memory

Cache memory is a small, high-speed memory located between the CPU and main memory. It stores frequently accessed data and instructions to improve system performance.

Classification of Database Failures

A Database Failure occurs when the database system cannot continue its normal operation or when committed data may be lost. Database failures can be classified into the following types:

1. Transaction Failure:
A transaction may fail because of logical errors, invalid data, constraint violations, or deadlock. The failed transaction is usually rolled back.

2. System Failure:
A system crash caused by power failure, hardware failure, or operating system failure may cause the contents of main memory to be lost. However, data stored on secondary storage generally remains safe.

3. Disk Failure:
Failure of a hard disk or other storage device can cause loss or corruption of database data stored on that device.

4. Media Failure:
Damage or corruption of storage media, such as disk crashes or bad sectors, can make database files inaccessible or permanently lost.

5. Communication Failure:
In a distributed database system, network failure or communication problems may prevent transactions from completing correctly between different sites.

6. Catastrophic Failure:
Events such as fire, flood, earthquake, or major hardware destruction can damage the entire database system and its storage.

Conclusion:

The major database failures are Transaction Failure, System Failure, Disk/Media Failure, Communication Failure, and Catastrophic Failure. Backup, logging, recovery mechanisms, and fault-tolerant systems are used to recover from these failures.

Distributed Database

A distributed database is a database in which data is stored across multiple physical locations (different computers or servers) that are connected through a network. Although the data is distributed, it appears to users as a single unified database.

Each site in a distributed database system can process local queries independently and also participate in global queries.

Example: A bank database where customer data is stored in different branch servers located in different cities.

Role of a Database Administrator (DBA)

A Database Administrator (DBA) is responsible for managing, maintaining, and securing the database system to ensure data availability, integrity, and performance.

• Database Installation & Configuration: Installs, configures, and upgrades database software.
• Data Security: Controls user access, permissions, and ensures data protection.
• Backup & Recovery: Performs regular backups and restores data during failures.
• Performance Monitoring: Optimizes database performance and handles tuning.
• Data Integrity: Ensures accuracy and consistency of stored data.

Primary Key, Foreign Key, and Indexing in Relational Databases

Primary Key: A primary key is a column (or a set of columns) that uniquely identifies each row in a table.

Example: Student Table

• Stu_Id can be the primary key because it is unique for each student.
• Stu_Name alone cannot be a primary key, as multiple students can have the same name.
• Stu_Age alone cannot be a primary key, as multiple students can have the same age.

Foreign Key: A foreign key is a column in one table that references the primary key of another table. It establishes relationships between tables.

Example: Course Enrollment Table

• In this table, Stu_Id is a foreign key as it references the primary key (Stu_Id) from the Student table.

Indexing: Indexing improves the speed of data retrieval in a database.

• Advantages: Indexing speeds up search queries, improves performance, and reduces load time.
• Disadvantages: Indexes require extra storage and may slow down insert, update, and delete operations.

Does Indexing Always Make Applications Faster?

• Yes, for read-heavy databases where fast searches are needed.
• No, for write-heavy databases where frequent inserts and updates happen, as indexing can slow them down.

Primary Key, Candidate Key, and Super Key (with Example)

In a relational database, keys are used to uniquely identify each record (tuple) in a relation.

Example Relation: STUDENT

STUDENT(StudentID, Name, Email, Phone)

• Super Key: A super key is a set of one or more attributes that can uniquely identify a record in a table.

Super Key Examples:
{StudentID}, {Email}, {StudentID, Name}, {StudentID, Phone}

• Candidate Key: A candidate key is a minimal super key. It uniquely identifies a record and has no unnecessary attributes.

Candidate Key Examples:
{StudentID}, {Email}

• Primary Key: A primary key is one candidate key chosen to uniquely identify records in the relation.

Primary Key Example:
StudentID

Given: R(w,x,y,z)

Functional Dependencies: F = { wx→yz, y→w, z→x }

Goal: Find all candidate keys (minimal superkeys).

Key idea: Find attribute sets whose closure gives {w,x,y,z} and are minimal.

Closures:

• (wx)+ = wx → yz ⇒ {w,x,y,z} ⇒ wx is a candidate key.
• (yz)+: y→w ⇒ add w, z→x ⇒ add x ⇒ {w,x,y,z} ⇒ yz is a candidate key.
• (wz)+: z→x ⇒ get x, now wx→yz ⇒ get y,z ⇒ {w,x,y,z} ⇒ wz is a candidate key.
• (xy)+: y→w ⇒ get w, now wx→yz ⇒ get y,z ⇒ {w,x,y,z} ⇒ xy is a candidate key.

Answer (Candidate Keys): {wx}, {xy}, {wz}, {yz}

Relationship between Book and Borrower Tables

In a library database, the relationship between the Book table and the Borrower table is typically Many-to-Many.

Justification

• A single book can be borrowed by many borrowers over time.
• A single borrower can borrow many books at the same time or over different periods.

Because both tables can have multiple associations with each other, the relationship is many-to-many. In practice, this relationship is implemented using an intermediate table (such as Borrow or Loan) that stores information like borrow date, return date, and IDs of both book and borrower.

Relationship in Relational Database

A relationship in a relational database defines how tables are connected with each other using keys such as primary keys and foreign keys.

Relationships help organize data efficiently and reduce data redundancy.

Main Types of Relationships

1. One-to-One (1:1)
2. One-to-Many (1:M)
3. Many-to-Many (M:N)

1. One-to-One Relationship (1:1)

In a one-to-one relationship, one record in one table is related to only one record in another table.

Example:

A person can have only one passport, and one passport belongs to only one person.

Use Case:

• Employee and Locker
• Person and Passport

2. One-to-Many Relationship (1:M)

In a one-to-many relationship, one record in one table can be related to many records in another table.

However, each record in the second table belongs to only one record in the first table.

Example:

One department can have many employees, but each employee belongs to only one department.

Use Case:

• Department and Employees
• Customer and Orders

3. Many-to-Many Relationship (M:N)

In a many-to-many relationship, many records in one table can relate to many records in another table.

This relationship is usually implemented using a junction table or bridge table.

Example:

A student can enroll in many courses, and a course can have many students.

Use Case:

• Students and Courses
• Doctors and Patients

Summary of Relationships

Relationships in relational databases help connect tables logically and efficiently. Proper relationships improve data integrity, reduce redundancy, and simplify database management.

In Database Management Systems (DBMS), relationships define how data in different tables are connected. There are three main types of relationships in a relational database:

1. One-to-One (1:1) Relationship:
Each record in Table A is linked to only one record in Table B, and vice versa.

Example:

• A person and their passport (One person has only one passport, and one passport belongs to one person).

2. One-to-Many (1:M) Relationship:
A record in Table A can be linked to multiple records in Table B, but each record in Table B is linked to only one record in Table A.

Example:

• A customer can place multiple orders, but each order belongs to only one customer.

3. Many-to-Many (M:N) Relationship:
Each record in Table A can be linked to multiple records in Table B, and vice versa.

Example:

• A doctor can treat multiple patients, and a patient can have multiple doctors.

Given:
Relation R(A, B, C) is decomposed into:
R1(A, B) and R2(B, C)

Is the decomposition lossless?

Yes, this decomposition is lossless join if attribute B is a key (or common key condition holds).

Explanation:

The common attribute between R1 and R2 is B.
When joining R1 and R2 on B, we can perfectly reconstruct the original relation R(A, B, C) without losing or adding extra tuples, provided B functionally determines either R1 or R2.

Lossless Join Condition:

A decomposition of R into R1 and R2 is lossless if:

(R1 ∩ R2) → R1 OR (R1 ∩ R2) → R2

For this case:
R1 ∩ R2 = {B}

So the condition becomes:

• B → A (then lossless), OR
• B → C (then lossless)

Distributed DBMS: A Distributed Database Management System (DDBMS) manages a logically related database whose data is stored across multiple network-connected locations. To users and applications, the distributed data can appear as a coordinated database, even though the data is physically stored at different sites.

Example: A bank may maintain databases at different branches or data centers. A DDBMS can coordinate access to the distributed data while applying appropriate transaction and consistency rules.

Important Concepts:

1. Data Distribution: Data may be divided into fragments and stored at different sites.

2. Replication: Copies of data may be stored at multiple sites to improve availability and read performance, although replication requires mechanisms to keep copies consistent.

3. Distributed Query Processing: The system coordinates queries that require data from more than one location.

4. Transaction Coordination: The DDBMS coordinates transactions involving multiple sites and aims to preserve required consistency and transaction properties.

Advantages of a Distributed DBMS: Improved availability, local access to data, potential scalability, and the ability to distribute processing across locations.

Challenges: Network delays, communication failures, distributed transaction coordination, consistency management, security, and increased administrative complexity.

Features of a DBMS:

1. Data Storage, Retrieval, and Updating: A DBMS provides mechanisms to insert, read, modify, and delete data efficiently.

2. Reduced Data Redundancy: Proper database design helps reduce unnecessary duplication of data.

3. Data Consistency: Constraints and transaction controls help maintain consistent data across operations.

4. Data Security: Authentication, authorization, and access controls help prevent unauthorized data access.

5. Data Integrity: Constraints, such as primary keys, foreign keys, and validation rules, help keep data accurate and valid.

6. Backup and Recovery: Backup and recovery mechanisms help restore data after failures or accidental loss.

7. Concurrency Control: The DBMS manages simultaneous access by multiple users or transactions to reduce conflicts.

8. Transaction Management: Transaction mechanisms help ensure reliable operations. Relational DBMSs commonly use the ACID properties: Atomicity, Consistency, Isolation, and Durability.

9. Data Independence: Changes to physical storage or parts of the database structure can often be made without requiring corresponding changes to every application.

10. Query Processing: The DBMS interprets queries and selects an execution plan to retrieve or modify data.

11. Data Sharing: Authorized users and applications can access a shared database according to permissions and concurrency rules.

A key person responsible for Database Management System (DBMS) is generally known as a Database Administrator (DBA). His/her main duties are:

1. Database Design: Designing and organizing the database according to the company's requirements.

2. Data Security: Protecting the database from unauthorized access and ensuring data confidentiality.

3. Backup and Recovery: Taking regular database backups and recovering data in case of system failure or data loss.

4. Performance Monitoring: Monitoring and optimizing database performance to ensure efficient data processing.

5. User Management: Creating user accounts and assigning appropriate access permissions.

6. Data Integrity: Ensuring data accuracy, consistency, and reliability.

7. Database Maintenance: Installing updates, managing storage, and troubleshooting database problems.

8. Availability: Ensuring that the database remains available and operates reliably.

Original Schema:

The original schema had attributes like Branch_name, Acc_name, Balance, Branch_city, and Assets.

Initially, everything was in a single table, but it had some issues because Branch_name was part of the key for identifying branch info, while Acc_no was the key for account info.

After Decomposition:

1. Account Table:

• Primary Key: Acc_no (Each account has a unique identifier).
• Foreign Key: Branch_name (This links each account to a branch).
• Non-key attributes (Acc_name, Balance) fully depend on Acc_no.

2. Branch Table:

• Primary Key: Branch_name (Each branch has a unique name).
• Non-key attributes (Branch_city, Assets) fully depend on Branch_name.

Why 2NF?

2NF (Second Normal Form) means:

• There are no partial dependencies (where attributes depend on part of the key).
• In each table, all non-key attributes depend entirely on the full primary key.

So, by breaking up the data into two tables, we've removed partial dependencies and made the schema 2NF.

Explanation:

১. প্রথমে একক টেবিলের স্কিমা:

আমাদের কাছে প্রথমে ছিল একটি টেবিল, এই টেবিলটির মধ্যে অ্যাট্রিবিউটগুলো হলো:

(Branch_name, Acc_name, Balance, Branch_city, Assets)

এই টেবিলটি ছিল একক টেবিল, কিন্তু এতে কিছু সমস্যা ছিল—বিশেষত partial dependency। এর মানে হলো, কিছু অ্যাট্রিবিউট (যেমন Branch_city এবং Assets) Branch_name এর উপর নির্ভরশীল, যেটি এই টেবিলের একটি অংশ। যাতে নরমালাইজেশন ছিলো না।

২. ডিকম্পোজিশন (Decomposition):

এখন, এই সমস্যা সমাধান করতে আমরা টেবিলটিকে দুটি আলাদা টেবিলে ভাগ করি:

Account Table:

(Account_no, Acc_name, Balance, Branch_name)

• Primary Key: Acc_noAcc_no একটি ইউনিক আইডেন্টিফায়ার, যা প্রতিটি অ্যাকাউন্টকে ইউনিক করে।
• Foreign Key: Branch_nameBranch_name একটি ফরেন কী হিসেবে কাজ করে, যা Branch টেবিলের শাখার নামের সাথে সম্পর্কিত।

Branch Table:

• Primary Key: Branch_nameBranch_name শাখার ইউনিক আইডেন্টিফায়ার।
• Foreign Key: এখানে কোনো ফরেন কী নেই।

৩. ২NF (Second Normal Form):

Partial Dependency:

প্রথম স্কিমাতে Branch_name ছিল একটি অংশ, যা Branch_city এবং Assets এর মতো শাখার তথ্য ধারণ করছিল। তবে, অ্যাকাউন্টের জন্য প্রাথমিক কী Acc_no পুরোপুরি অ্যাকাউন্টের তথ্য (Acc_name, Balance) নির্ধারণ করতে ব্যবহৃত হয়।

ডিকম্পোজিশন করার পর, Account টেবিলের সমস্ত অ-প্রাথমিক অ্যাট্রিবিউট Acc_no এর উপর নির্ভরশীল হয়েছে, আর Branch টেবিলের সমস্ত অ-প্রাথমিক অ্যাট্রিবিউট Branch_name এর উপর নির্ভরশীল।

এটি partial dependency দূর করেছে, যেখানে কোনো অ্যাট্রিবিউট প্রাথমিক কীর একটি অংশের উপর নির্ভরশীল ছিল না।

২NF অর্জিত হয়েছে কারণ:

• Account টেবিলের সকল Non-key Attribute Acc_no এর উপর নির্ভরশীল।
• Branch টেবিলের সকল Non-key Attribute Branch_name এর উপর নির্ভরশীল

এই ডিকম্পোজিশনটি নিশ্চিত করেছে যে, আমরা partial dependency দূর করেছি এবং প্রতিটি টেবিলের Non-key Attribute তাদের পুরো primary keyএর উপর নির্ভরশীল। এর ফলে আমরা ২NF (Second Normal Form) অর্জন করেছি।

Techniques to Prevent Deadlock in DBMS

A Deadlock occurs when two or more transactions wait indefinitely for resources held by each other. The following techniques can be used to prevent or handle deadlocks in a DBMS:

1. Wait-Die and Wound-Wait Schemes:
These schemes decide whether a transaction should wait or be aborted when a resource is requested. In the Wait-Die scheme, an older transaction may wait, while a younger transaction requesting a resource held by an older transaction is aborted. In the Wound-Wait scheme, an older transaction can preempt (abort) a younger transaction.

2. Timeout Mechanism:
A transaction is automatically aborted if it waits for a lock longer than a specified time. This prevents transactions from waiting indefinitely and helps reduce deadlocks.

3. Resource Ordering:
All transactions are required to request resources in a predefined order. This prevents the Circular Wait condition, which is one of the necessary conditions for deadlock.

4. Preemptive Resource Allocation:
If necessary, a resource can be released from a transaction that can safely be aborted. The resource is then allocated to another transaction, helping to avoid deadlock.

5. Deadlock Detection Algorithms:
The DBMS can periodically check for deadlocks using a Wait-for Graph. If a cycle is detected in the graph, one of the transactions involved in the cycle can be aborted or rolled back to resolve the deadlock.

Conclusion:

Deadlocks can be prevented or resolved using Wait-Die/Wound-Wait schemes, Timeout, Resource Ordering, Preemptive Resource Allocation, and Deadlock Detection. These techniques help maintain efficient and reliable database transaction processing.

A Trigger is a special type of Stored Procedure in a Database Management System (DBMS) that automatically executes (fires) when a specified event occurs on a table or view. These events are typically INSERT, UPDATE, or DELETE operations.

When is a Trigger Used?

Triggers are used when certain actions need to be performed automatically after or before changes are made to database data.

Common uses of Triggers include:
• Automatically maintaining Audit Logs.
• Enforcing Business Rules and data integrity.
• Validating data before insertion or update.
• Automatically updating related tables.
• Preventing unauthorized or invalid data modifications.

Advantages of Trigger

• Executes automatically without user intervention.
• Maintains data consistency and integrity.
• Reduces repetitive application code.
• Helps implement complex business rules.
• Keeps an audit trail of database changes.
• Improves database security by controlling data modifications.

Example

A Trigger can automatically store the old employee salary in an Audit Table whenever the salary is updated.