A database transaction comprises a unit of work performed within a database management system (or similar system) against a database, and treated in a coherent and reliable way independent of other transactions. Transactions in a database environment have two main purposes:

1. To provide reliable units of work that allow correct recovery from failures and keep a database consistent even in cases of system failure, when execution stops (completely or partially) and many operations upon a database remain uncompleted, with unclear status.
2. To provide isolation between programs accessing a database concurrently. Without isolation the programs' outcomes are possibly erroneous.

A database transaction, by definition, must be atomic, consistent, isolated and durable.[1] Database practitioners often refer to these properties of database transactions using the acronym ACID.

Transactions provide an "all-or-nothing" proposition, stating that each work-unit performed in a database must either complete in its entirety or have no effect whatsoever. Further, the system must isolate each transaction from other transactions, results must conform to existing constraints in the database, and transactions that complete successfully must get written to durable storage.

A COMMIT statement in SQL ends a transaction
A ROLLBACK is an operation which returns the database to some previous state

A database transaction is a logical unit of database operations which are executed as a whole to process user requests for retrieving data or updating the database.

Commit/Rollback - Normally transactions are auto commit/Rollback depending on the successful completion of operations or failure in half way respectively. But you can control it by executing 'Begin Tran' statement followed by the set of SQL Statements/Operations you have and then decide execute 'Commit' to write the change in database or execute 'Rollback' if you don't want the change to be reflected in database.

Mostly aLL RDBMS follow the ACID model (Atomicity, consistency, Isolation and durability). Of these 4, Atomicity states "all or none". Means when the user is trying to save records into multiple table under one shot, then in that case either everything is saved to the db or in case of error anything that was stored before the error occured needs to be removed. To handle such scenarios, the SQL transaction comes into picture. The entire saving process is clubbed under one transaction. All the CRUD statements are performed one after the other. In case during the execution of CRUD statements, an error occurs, then the transaction is rolledback (using "ROLLBack Tran"), which will undo all the changes that have been made from the start of the transaction till the error occured. In case the error does not occurs during the execution of the CRUD statements, then all the data is actually physically saved to the db using the Commit statement.

In short,
A Commit statement is issued to save the changes that were made to the db during a transacation

A Rollback statement is issued to undo all the changes (in case of occurence of an error) that were made to the db during a transacation