- Table: where all the information of the real world is stored.
- Database(DB) : comprises of Table(s) .
- Server: where the Database is hosted. A Database might be hosted in USA/Bangladesh etc.
- Transaction: An example might be transferring money from account ‘A’ to account ‘B’. You need to withdraw a specific amount from account ‘A’ and then deposit that definite amount to a destination account ‘B’. The operation has to be successful, right? if any failure occurs in a midway the money will surely be lost and it will make you cry like a baby. So, a proper transfer of the money from account ‘A’ to account ‘B’ is termed as Transaction.
A pictorial depiction of the Database Transaction is given below:
The DB Transactions follow the below points known as ACID properties :
- Atomicity: All the transactions are atomic that means either the transaction will be committed or not. There will be no partial commit. This is managed by DB’s Transaction Manager.
- Consistency: After a Transaction, The database has to be in a constant state. There can be no adverse effect to spoil the transaction. It is maintained by the programmer who is coding to maintain it’s stability. In Big data storage like Facebook, YouTube the consistency is not a mandatory thing. Confusing? Okay let me give you a simple example, Suppose you open the same picture in two different tabs of your browser. You like this picture in one tab and see on the other opened tab that the like is not updated. In big data such as these, consistency is a less priority.
- Isolation: There might be several thousands of request at the same time in your Database. So, your database has to maintain this Isolation concept in order process all the request. It’s kind of ‘Parallel Thread Concept’ where all the requests should be treated as a single request. This is managed by Concurrency Manager.
- Durability: Suppose, your transaction is in progress and a ghost incident occurs. What the hell is a ghost incident? Assume, during a commit/save/persistence in the database, the data is not written in the database’s table due to hardware failure. So that when your database springs back, the uncommitted data has to be updated. This is actually rolling back to the previous consistent state of the DB from where the transaction can begin again. This is managed by DB’s Recovery Manager.