hello my name is Nicholas and today we're going to talk about transactions in a relational database management system more specifically we're going to talk about the acid acronym what it stands for and what it actually means so fundamentally a transaction is a unit of work executed to retrieve insert remove and/or update data and this unit of work typically consists of running one or more statements or queries against some kind of database in a relational database management systems transactions comes with specific properties that service guarantees of sorts so we can rely on the fact that all transactions in a relational database management system will be atomic they will be consistent they will be isolated and they will be durable or acid for short it's worth mentioning that while all relational database management systems have these guarantees not all database management systems do so so some have base properties instead of acid but we won't go into this in in this video a common example used to illustrate a transaction is a bank transfer so in this use case we want to transfer money from one bank account into another and for this example we're going to assume that that all the bank account data is being persisted in a single database and so in order to do this we'll first need to make sure that there's sufficient funds on the payers account then we need to subtract that amount from the payers account add it to the receivers account and finally we want to mark the transaction as successful and we can do this by executing four queries against the database so first we're going to make a select to check the funds followed by three updates update statements for the rest of the logics abstraction adding and and finally marking the transfer as successful how to group the queries into into different transactions is up to the application programmer so we could perform each query in its own transaction but for reasons that will soon see this is probably a bad idea in our example and it would probably make more sense to think of all the four queries as being part of one logical transaction and then implement the application logic accordingly so let's go back to the acid properties in the context of this example with the a for atomic simply put atomicity in the context of a transaction means that either all the queries and operations are run or none of them are this guarantees that if there is a failure at any point during the transaction none of the statements are actually committed going back to our example it's evident why this guarantee by the database management system is so useful for us so imagine that we run into an error during the transaction the first two queries have run successfully here and the money has been deducted from the payers account however we have failed to add the money to the receivers account or mark the transfer as successful so if the successful queries were actually to be committed to the database regardless we would be in a worrying situation the status of the transfer would not change and it would appear the money had just vanished into thin air since we have the guarantee of atomicity of transactions however we can indeed group all the statements under one transaction and rely on the database management system to ensure that if anything goes wrong during the transaction none of the changes are committed so the in this case the money wouldn't be taken from the payers account next we have see for consistency and by consistency we mean that after each or after transaction is performed all of the data is still in valid States so in the context of our example we could set a constraint for example in the on the account balance field to make sure that it never goes below zero so after that we could rely on the database management system not to commit the transaction that would leave the database in a state with negative numbers in the account balance field or in other words transfer of money that that that isn't there for the third property I for isolated means that the statements are executed in a seemingly consecutive or second sequential way so at the highest isolation level as far as the application programmer knows each transaction is run after the previous one is fully completed and so in practice database management system might execute transactions concurrently but they do make the guarantee that the result is the same as it would be in a more consecutive approach lowering the isolation level means that transactions which are being run concurrently by the but the database management system might actually affect each other and and see see each other at different steps of the way there is always a trade-off between the guarantees of a sequential approach at a higher isolation level compared to the performance gains that we get if we lower the isolation level but then then we're going to lose some of the guarantees guarantees of isolation and finally the last property of an asset transaction is durability and durability means that once commitment has been a glorious by the database management system we have a guarantee that the changes have been committed permanently and will will persist in the event of a power outage or or any other catastrophic failure so in practice this means that changes that that have always been flushed from any potential buffers in memory and have been written to disk when the application is informed that the transaction has been committed and that was my quick run-through of acid transactions I hope the video was of some use to you and thanks for listening until next time