Many real operations require several changes that must all succeed together or not at all. Transferring a player between teams might update two tables; if one update succeeds and the other fails, the data is left inconsistent. A transaction groups multiple statements into a single all-or-nothing unit, so either every change is applied together or none is, keeping the database always in a valid state.
Transactions are bounded by BEGIN, which starts them, and COMMIT, which makes their changes permanent, or ROLLBACK, which discards them entirely. Within a transaction you can run many statements, and only at COMMIT do they become visible and durable. This gives you a safety net: if anything goes wrong partway through, ROLLBACK restores the state as if nothing happened.
The guarantees transactions provide are summarised by ACID: Atomicity, Consistency, Isolation, and Durability. These four properties are why databases can be trusted with money, bookings, and any data where partial or conflicting changes would be catastrophic. Understanding ACID turns transactions from a vague safety feature into a precise tool for reasoning about correctness under failure and concurrency.