A transaction is a logical unit of work. To maintain database consistency, transactions must adhere to ACID properties, and concurrent operations must be serializable.

Serial Schedule: Transactions execute one after another without interleaving. Always consistent. · Non-Serial Schedule: Operations interleave. Improves performance but can lead to conflicts. · Conflict Serializable: A schedule that can be transformed into a serial schedule by swapping non-conflicting adjacent operations. · View Serializable: A weaker check than conflict serializability, verifying identical read/write flow states.

1. Recoverable Schedule

   T2 reads a value written by T1. T2 commits only after T1 commits. If T1 aborts, T2 can also safely abort.

2. Cascadeless Schedule

   T2 is only allowed to read values written by T1 after T1 has committed. Prevents cascading rollbacks where one transaction failure forces aborting multiple active ones.

3. Strict Schedule

   A transaction cannot read or write a data item written by another transaction until that transaction has committed or aborted. Prevents dirty writes.