Literature Review
Background of Study
What is the Management System?
A database-management system (DBMS) is a collection of interrelated data and a set of programs to access those data. This is a collection of related data with an implicit meaning and hence is a database. The collection of data, usually referred to as the database, contains information relevant to an enterprise. The primary goal of a DBMS is to provide a way to store and retrieve database information that is both convenient and efficient. By data, we mean known facts that can be recorded and that have implicit meaning. The management system is important because without the existence of some kind of rules and regulations it is not possible to maintain the database.
We have to select the particular attributes which should be included in a particular table; the common attributes to create relationship between two tables; if a new record has to be inserted or deleted then which tables should have to be handled etc. These issues must be resolved by having some kind of rules to follow in order to maintain the integrity of the database. Database systems are designed to manage large bodies of information. Management of data involves both defining structures for storage of information and providing mechanisms for the manipulation of information. In addition, the database system must ensure the safety of the information stored, despite system crashes or attempts at unauthorized access. If data are to be shared among several users, the system must avoid possible anomalous results. Because information is so important in most organizations, computer scientists have developed a large body of concepts and techniques for managing data.
Database Management System (DBMS) and Its Applications: A Database management system is a computerized record-keeping system. It is a repository or a container for collection of computerized data files. The overall purpose of DBMS is to allow he users to define, store, retrieve and update the information contained in the database on demand. Information can be anything that is of significance to an individual or organization. Databases touch all aspects of our lives. Some of the major areas of application are as follows:
- Banking
- Airlines
- Universities
- Manufacturing and selling
- Human resources Enterprise Information
◦ Sales: For customer, product, and purchase information.
◦ Accounting: For payments, receipts, account balances, assets and other accounting information.
◦ Human resources: For information about employees, salaries, payroll taxes, and benefits, and for generation of paychecks.
◦ Manufacturing: For management of the supply chain and for tracking production of items in factories, inventories of items in warehouses and stores, and orders for items. Online retailers: For sales data noted above plus online order tracking, generation of recommendation lists, and maintenance of online product evaluations.
Banking and Finance
◦ Banking: For customer information, accounts, loans, and banking transactions.
◦ Credit card transactions: For purchases on credit cards and generation of monthly statements. ◦ Finance: For storing information about holdings, sales, and purchases of financial instruments such as stocks and bonds; also for storing real-time market data to enable online trading by customers and automated trading by the firm.
- Universities: For student information, course registrations, and grades (in addition to standard enterprise information such as human resources and accounting).
- Airlines: For reservations and schedule information. Airlines were among the first to use databases in a geographically distributed manner.
- Telecommunication: For keeping records of calls made, generating monthly bills, maintaining balances on prepaid calling cards, and storing information about the communication networks. Purpose of Database Systems Database systems arose in response to early methods of computerized management of commercial data. As an example of such methods, typical of the 1960s, consider part of a university organization that, among other data, keeps information about all instructors, students, departments, and course offerings. One way to keep the information on a computer is to store it in operating system files. To allow users to manipulate the information, the system has a number of application programs that manipulate the files, including programs to: ü Add new students, instructors, and courses ü Register students for courses and generate class rosters ü Assign grades to students, compute grade point averages (GPA), and generate transcripts
System programmers wrote these application programs to meet the needs of the university. New application programs are added to the system as the need arises. For example, suppose that a university decides to create a new major (say, computer science).As a result, the university creates a new department and creates new permanent files (or adds information to existing files) to record information about all the instructors in the department, students in that major, course offerings, degree requirements, etc. The university may have to write new application programs to deal with rules specific to the new major. New application programs may also have to be written to handle new rules in the university. Thus, as time goes by, the system acquires more files and more application programs. This typical file-processing system is supported by a conventional operating system. The system stores permanent records in various files, and it needs different application programs to extract records from, and add records to, the appropriate files. Before database management systems (DBMSs) were introduced, organizations usually stored information in such systems.
Keeping organizational information in a file processing system has a number of major disadvantages: Data redundancy and inconsistency. Since different programmers create the files and application programs over a long period, the various files are likely to have different structures and the programs may be written in several programming languages. Moreover, the same information may be duplicated in several places (files). For example, if a student has a double major (say, music and mathematics) the address and telephone number of that student may appear in a file that consists of student records of students in the Music department and in a file that consists of student records of students in the Mathematics department. This redundancy leads to higher storage and access cost. In addition, it may lead to data inconsistency; that is, the various copies of the same data may no longer agree. For example, a changed student address may be reflected in the Music department records but not elsewhere in the system. Difficulty in accessing data. Suppose that one of the university clerks needs to find out the names of all students who live within a particular postal-code area.
The clerk asks the data-processing department to generate such a list. Because the designers of the original system did not anticipate this request, there is no application program on hand to meet it. There is, however, an application program to generate the list of all students.
The university clerk has now two choices: either obtain the list of all students and extract the needed information manually or ask a programmer to write the necessary application program. Both alternatives are obviously unsatisfactory. Suppose that such a program is written, and that, several days later, the same clerk needs to trim that list to include only those students who have taken at least 60 credit hours.
As expected, a program to generate such a list does not exist. Again, the clerk has the preceding two options, neither of which is satisfactory. The point here is that conventional file-processing environments do not allow needed data to be retrieved in a convenient and efficient manner. More responsive data-retrieval systems are required for general use. Data isolation. Because data are scattered in various files, and files may be in different formats, writing new application programs to retrieve the appropriate data is difficult. Integrity problems. The data values stored in the database must satisfy certain types of consistency constraints. Suppose the university maintains an account for each department, and records the balance amount in each account.
Suppose also that the university requires that the account balance of a department may never fall below zero. Developers enforce these constraints in the system by adding appropriate code in the various application programs. However, when new constraints are added, it is difficult to change the programs to enforce them. The problem is compounded when constraints involve several data items from different files.
Significance of the Study
Implementation of Atomicity and Durability in DBMS Atomicity and durability are two important concepts in database management systems (DBMS) that ensure consistency and reliability of data. Atomicity: One of the key characteristics of transactions in database management systems (DBMS) is atomicity, which guarantees that every operation within a transaction is handled as a single, indivisible unit of work. Importance:
A key characteristic of transactions in database management systems is atomicity (DBMS). It makes sure that every action taken as part of a transaction is handled as a single, indivisible item of labor that can either be completed in full or not at all. Even in the case of mistakes, failures, or crashes, atomicity ensures that the database maintains consistency. The following are some of the reasons why atomicity is essential in DBMS: ○ Consistency: Atomicity ensures that the database always remains in a consistent state.
All changes made by a transaction are rolled back if it is interrupted or fails for any other reason, returning the database to its initial state. By doing this, the database’s consistency and data integrity are maintained. ○ Recovery: Atomicity guarantees that, in the event of a system failure or crash, the database can be restored to a consistent state. All changes made by a transaction are undone if it is interrupted or fails, and the database is then reset to its initial state using the undo log. This guarantees that, even in the event of failure, the database may be restored to a consistent condition.
○ Concurrency: Atomicity makes assurance that transactions can run simultaneously without affecting one another. Each transaction is carried out independently of the others, and its modifications are kept separate. This guarantees that numerous users can access the database concurrently without resulting in conflicts or inconsistent data.
○ Reliability: Even in the face of mistakes or failures, atomicity makes the guarantee that the database is trustworthy. By ensuring that transactions are atomic, the database remains consistent and reliable, even in the event of system failures, crashes, or errors. Implementation of Atomicity: A number of strategies are used to establish atomicity in DBMS to guarantee that either all operations inside a transaction are correctly done or none of them are executed at all. Techniques to Implement Atomicity in DBMS: Here are some common techniques used to implement atomicity in DBMS:
○ Undo Log: An undo log is a mechanism used to keep track of the changes made by a transaction before it is committed to the database. If a transaction fails, the undo log is used to undo the changes made by the transaction, effectively rolling back the transaction. By doing this, the database is guaranteed to remain in a consistent condition.
○ Redo Log: A redo log is a mechanism used to keep track of the changes made by a transaction after it is committed to the database. If a system failure occurs after a transaction is committed but before its changes are written to disk, the redo log can be used to redo the changes and ensure that the database is consistent.
○ Two-Phase Commit: Two-phase commit is a protocol used to ensure that all nodes in a distributed system commit or abort a transaction together. This ensures that the transaction is executed atomically across all nodes and that the database remains consistent across the entire system.
○ Locking: Locking is a mechanism used to prevent multiple transactions from accessing the same data concurrently. By ensuring that only one transaction can edit a specific piece of data at once, locking helps to avoid conflicts and maintain the consistency of the database. Durability: One of the key characteristics of transactions in database management systems (DBMS) is durability, which guarantees that changes made by a transaction once it has been committed are permanently kept in the database and will not be lost even in the case of a system failure or catastrophe. Importance: Durability is a critical property of transactions in database management systems (DBMS) that ensures that once a transaction is committed, its changes are permanently stored in the database and will not be lost, even in the event of a system failure or crash. The following are some of the reasons why durability is essential in DBMS:
❖ Data Integrity: Durability ensures that the data in the database remains consistent and accurate, even in the event of a system failure or crash. It guarantees that committed transactions are durable and will be recovered without data loss or corruption.
❖ Reliability: Durability guarantees that the database will continue to be dependable despite faults or failures. In the event of system problems, crashes, or failures, the database is kept consistent and trustworthy by making sure that committed transactions are durable.
❖ Recovery: Durability guarantees that, in the event of a system failure or crash, the database can be restored to a consistent state. The database can be restored to a consistent state if a committed transaction is lost due to a system failure or crash since it can be recovered from the redo log or other backup storage.
❖ Availability: Durability ensures that the data in the database is always available for access by users, even in the event of a system failure or crash. It ensures that committed transactions are always retained in the database and are not lost in the event of a system crash.
Recovery and Atomicity in DBMS Introduction Data may be monitored, stored, and changed rapidly and effectively using a DBMS (Database Management System).A database possesses atomicity, consistency, isolation, and durability qualities. The ability of a system to preserve data and changes made to data defines its durability. A database could fail for any of the following reasons:
○ System breakdowns occur as a result of hardware or software issues in the system. ○ Transaction failures arise when a certain process dealing with data updates cannot be completed.
○ Disk crashes may occur as a result of the system’s failure to read the disc.
○ Physical damages include issues such as power outages or natural disasters.
○ The data in the database must be recoverable to the state they were in prior to the system failure, even if the database system fails. In such situations, database recovery procedures in DBMS are employed to retrieve the data. The recovery procedures in DBMS ensure the database’s atomicity and durability. If a system crashes in the middle of a transaction and all of its data is lost, it is not regarded as durable. If just a portion of the data is updated during the transaction, it is not considered atomic. Data recovery procedures in DBMS make sure that the data is always recoverable to protect the durability property and that its state is retained to protect the atomic property. The procedures listed below are used to recover data from a DBMS,
○ Recovery based on logs.
○ Recovery through Deferred Update
○ Immediate Recovery via Immediate Update The atomicity attribute of DBMS safeguards the data state. If a data modification is performed, the operation must be completed entirely, or the data’s state must be maintained as if the manipulation never occurred. This characteristic may be impacted by DBMS failure brought on by transactions, but DBMS recovery methods will protect it.
Log-Based Recovery
● The log is a sequence of records. Log of each transaction is maintained in some stable storage so that if any failure occurs, then it can be recovered from there.
● If any operation is performed on the database, then it will be recorded in the log.
● But the process of storing the logs should be done before the actual transaction is applied in the database. There are two approaches to modify the database: 1. Deferred database modification:
● The deferred modification technique occurs if the transaction does not modify the database until it has committed.
● In this method, all the logs are created and stored in the stable storage, and the database is updated when a transaction commits. Immediate database modification:
● The Immediate modification technique occurs if database modification occurs while the transaction is still active.
● In this technique, the database is modified immediately after every operation. It follows an actual database modification. Recovery using Log records When the system is crashed, then the system consults the log to find which transactions need to be undone and which need to be redone.
1. If the log contains the record and or , then the Transaction Ti needs to be redone.
2. If log contains record but does not contain the record either or , then the Transaction Ti needs to be undone. ***************************************************************************
Recovery with Concurrent Transactions Concurrency control means that multiple transactions can be executed at the same time and then the interleaved logs occur. But there may be changes in transaction results so maintain the order of execution of those transactions. During recovery, it would be very difficult for the recovery system to backtrack all the logs and then start recovering. Recovery with concurrent transactions can be done in the following four ways.
1. Interaction with concurrency control
2. Transaction rollback
3. Checkpoints
4. Restart recovery Interaction with concurrency control : In this scheme, the recovery scheme depends greatly on the concurrency control scheme that is used. So, to rollback a failed transaction, we must undo the updates performed by the transaction. Transaction rollback
Database Management Systems, ACID Properties, and their Implications
Overview
• Database: organized collection of data
• Database Management System (DBMS): a software system that controls the organization, storage, retrieval, security and integrity of data in a database and across multiple databases.
• Database Management System Pipeline:
1. Accept query from user
2. Process query
3. Output result Step 2 – core of DBMS.
• Query Processing Pipeline. Top-to-bottom. 1. Parse SQL into relational algebra tree
2. Figure out the best order of (atomic) operations
3. Figure out the best way to perform each operation 4. Execute each operation
• Query Execution. Each atomic operation have multiple ways of being executed, based on: 1. Size of tables to operate on
2. Availability/desire to use indexes
3. Need/desire to sort data
4. Algorithmic approach (e.g., sorting vs. hashing) Each operation works with data brought to disk. Concerns: 1. Getting data from disk into main memory and back.
The ACID properties, in totality, provide a mechanism to ensure the correctness and consistency of a database in a way such that each transaction is a group of operations that acts as a single unit, produces consistent results, acts in isolation from other operations, and updates that it makes are durably stored.
Advantages of ACID Properties in DBMS:
1. Data Consistency: ACID properties ensure that the data remains consistent and accurate after any transaction execution.
2. Data Integrity: ACID properties maintain the integrity of the data by ensuring that any changes to the database are permanent and cannot be lost.
3. Concurrency Control: ACID properties help to manage multiple transactions occurring concurrently by preventing interference between them.
4. Recovery: ACID properties ensure that in case of any failure or crash, the system can recover the data up to the point of failure or crash.
Disadvantages of ACID Properties in DBMS:
1. Performance: The ACID properties can cause a performance overhead in the system, as they require additional processing to ensure data consistency and integrity.
2. Scalability: The ACID properties may cause scalability issues in large distributed systems where multiple transactions occur concurrently.
3. Complexity: Implementing the ACID properties can increase the complexity of the system and require significant expertise and resources. Overall, the advantages of ACID properties in DBMS outweigh the disadvantages. They provide a reliable and consistent approach to data
4. management, ensuring data integrity, accuracy, and reliability. However, in some cases, the overhead of implementing ACID properties can cause performance and scalability issues. Therefore, it’s important to balance the benefits of ACID properties against the specific needs and requirements of the system.
1 2. Getting more than one query/data management operation executed at the same time. This is were we come to transactions. Transaction (externally) Execution of any user program by a DBMS. Transaction (internally) A series of reads and writes. Informally, a transaction is a sequence (set) operations on the database that serves a single purpose and yields a single outcome. Concurrency in DBMS: Modern DBMS must be able to process multiple transactions at the same time. To do this successfully, DBMS must have certain properties. ACID Properties
(A)tomicitiy: The DBMS executes either all actions of the transaction or none. Incomplete transactions should not result in premanent changes in the database.
(C)onsistency: Each transaction run by itself must preserve the consistency of the database. (I)solation: Each transaction should be protected from effects of other transactions being executed alongside. For each pair of transactions Ti and Tj , it appears to Ti that either Tj has finished execution before Ti started, or that Tj has not commenced yet.
Transaction Concept: Transactions are a set of operations used to perform a logical set of work. It is the bundle of all the instructions of a logical operation. A transaction usually means that the data in the database has changed. One of the major uses of DBMS is to protect the user’s data from system failures. It is done by ensuring that all the data is restored to a consistent state when the computer is restarted after a crash. The transaction is any one execution of the user program in a DBMS. One of the important properties of the transaction is that it contains a finite number of steps. Executing the same program multiple times will generate multiple transactions. Example: Consider the following example of transaction operations to be performed to withdraw cash from an ATM vestibule. Steps for ATM Transaction
- Transaction
- Start.
- Insert your ATM card.
- 3. Select a language for your transaction.
- 4. Select the Savings Account option.
- 5. Enter the amount you want to withdraw.
- 6. Enter your secret pin.
- 7. Wait for some time for processing.
- 8. Collect your Cash.
- 9. Transaction Completed. A transaction can include the following basic database access operation.
● Read/Access data (R): Accessing the database item from disk (where the database stored data) to memory variable.
● Write/Change data (W): Write the data item from the memory variable to the disk.
● Commit: Commit is a transaction control language that is used to permanently save the changes done in a transaction
Example: Transfer of 50₹ from Account A to Account B. Initially A= 500₹, B= 800₹.
This data is brought to RAM from the Hard Disk. R(A) — 500 // Accessed from RAM. A = A-50 // Deducting 50₹ from A. W(A)–450
// Updated in RAM. R(B) — 800 // Accessed from RAM. B=B+50 // 50₹ is added to B’s Account. W(B) –850 // Updated in RAM. commit //
The data in RAM is taken back to the Hard Disk.
Note: The updated value of Account A = 450₹ and Account B = 850₹. All instructions before committing come under a partially committed state and are stored in RAM. When the commit is read the data is fully accepted and is stored on the Hard Disk. If the transaction is failed anywhere before committing we have to go back and start from the beginning. We can’t continue from the same state. This is known as Roll Back.
(D)urability: Once the transaction has successfully completed, its effects must become permanent in the database and shall be able to survive system crashes. Why Atomicity? Transactions are defined as sequences of actions in pursuit of a single goal. As a result of executing the transaction, either the goal is reached and all effects of all actions from the transaction must take hold, or the goal has been abandoned and then no results of any actions should survive.
Why Consistency? This question lies at the core of our course. The short argument for con[sistency is this. Writing software that works with consistent-state databases (as defined by the requirements of the specific application) is easier than writing software that is not allowed to make this assumption. Inconsistent database states that exist for short periods of time might be benign, but any actions performed on the data while the database is in an inconsistent state are dangerous.
2 Why Isolation? Nothing will screw with the data in the database more than simultaneous changes to the same data from multiple not yet completed transactions. Further actions in such transactions may wind up with incorrect assumptions about the stored data, and may be unable to produce correct actions. Why Durability? We need to make sure that changes to the database state persist once the process of making these changes succeeds. Effect of ACID Properties on DBMS Design. What do we need to do to ensure that a DBMS has ACID properties? For Atomicity. To ensure atomicity DBMS must:
• know all actions in each transaction;
• have a roll-back mechanism to undo partial effects of aborted transactions. For Consistency. To ensure consistency DBMS must:
• ensure that all transactions access the correct data at all times; Ensuring consistency is essentially the DB application’s job. For Isolation. To ensure isolation DBMS must:
• have a mechanism for correctly interleaving actions from multiple transactions (concurrency control mechanism);
• ensure that all transactions access the correct data at all times; For Durability. To ensure durability DBMS must:
• have access to persistent storage, i.e., storage that does not get emptied when the DBMS is powered down;
• carefully and appropriately manage exchange of data between persistent storage and volatile storage (RAM);
• be able to recover from systemwide crashes.
Satisfying ACID Properties: Relational DBMS Organization
• Read database access (see Fig. 1) – Data is stored in records on pages on physical storage devices (e.g., hard disks). – Pages are retrieved from physical storage and loaded into main memory buffer. – Records are retrieved from pages in main memory buffer and passed to the transaction program where they are stored as variables.
• Write database access (see Fig. 1) – Data stored in the variables of the transaction program is written into a page in main memory buffer – Pages of main memory buffer are written to physical storage.
Atomicity problems. A computer system, like any other device, is subject to failure. In many applications, it is crucial that, if a failure occurs, the data be restored to the consistent state that existed prior to the failure. Consider a program to transfer $500 from the account balance of department A to the account balance of department B. If a system failure occurs during the execution of the program, it is possible that the $500 was removed from the balance of department A but was not credited to the balance of department B, resulting in an inconsistent database state. Clearly, it is essential to database consistency that either both the credit and debit occur, or that neither occur. That is, the funds transfer must be atomic—it must happen in its entirety or not at all. It is difficult to ensure atomicity in a conventional file-processing system.
DATABASE MANAGEMENT SYSTEMS.pdf
1 Transactions
1.1 Introduction In most situations, many users can query & update a database simultaneously, causing concurrency issues. One user can write to the database while another user reads from the same resource. Or both users may try to write to the same resource. We use transactions to address these problems.
A transaction is a sequence of multiple actions to be executed as a single, logical, atomic unit. From SQL view, a transaction is in the form of:
• Begin transaction
• Sequence of SQL statements
• End transaction
1.2 The Basic Guarantees: ACID Transactions guarantee the ACID properties to avoid the concurrency problems discussed above:
• Atomicity: A transaction ends in two ways: it either commits or aborts. Atomicity means that either all actions in the Xact happen, or none happen
• Consistency: If the DB starts out consistent, it ends up consistent at the end of the Xact
• Isolation: Execution of each Xact is isolated from that of others. In reality, the DBMS will interleave actions of many Xacts and not execute each in the order of one after the other. The DBMS will ensure that each Xact executes as if it ran by itself.
• Durability: If the COMMIT succeeds, all changes from the transaction persist until overwritten by a later transaction
SQL transactions are critical for ensuring data integrity, consistency, and reliability in relational databases. They allow multiple SQL operations to be grouped into a single logical unit of work, ensuring that either all changes are applied or none are, thereby preventing partial updates and maintaining the database’s structural integrity. Here’s why SQL transactions are indispensable:
Data Integrity
Transactions ensure that data remains consistent by preventing partial updates. If any part of a transaction fails, the entire transaction is rolled back, maintaining the database’s original state.
Reliability
In environments where multiple users interact with the database simultaneously, transactions prevent interference between concurrent operations, ensuring each transaction executes independently.
Error Handling
Transactions provide a robust error-handling mechanism. If an error occurs during a transaction, the ROLLBACK command can undo all changes, preventing data corruption.
ACID Properties of Transactions
SQL transactions adhere to the ACID properties, which are fundamental for ensuring the reliability and consistency of database operations:
Atomicity
Ensures that all operations within a transaction are treated as a single, indivisible unit. If any operation fails, the entire transaction is aborted, and all changes are rolled back.
Consistency
Guarantees that the database remains in a valid state before and after the transaction. This means that transactions must follow the rules defined by the database, such as constraints and triggers.
Isolation
Prevents interference between concurrent transactions, ensuring they execute independently. This property ensures that the outcome of a transaction is not affected by other transactions running at the same time.
Durability
Ensures that once a transaction is committed, its effects are permanent and survive even in the event of a system failure.
These properties make SQL transactions reliable for handling complex operations in multi-user environments.
SQL Transaction Commands
SQL transaction commands are essential for managing and controlling the execution of operations within a database. They ensure data integrity, consistency, and reliability by grouping multiple SQL statements into a single logical unit of work.
These commands allow developers to start, commit, or roll back transactions based on the success or failure of operations. Below is an overview of the key SQL transaction commands, their syntax, and examples.
BEGIN TRANSACTION
Starts a new transaction. All subsequent operations are part of this transaction until a COMMIT or ROLLBACK is executed.
COMMIT
Saves all changes made during the transaction permanently to the database. Once committed, changes cannot be rolled back.
ROLLBACK
Undoes all changes made during the transaction since the last BEGIN TRANSACTION. This command is used when an error occurs or if the transaction needs to be aborted.
SAVEPOINT
Creates a point within a transaction to which you can later roll back. This allows partial rollback of a transaction without affecting earlier changes.
ROLLBACK TO SAVEPOINT
Rolls back the transaction to a specific savepoint without affecting earlier changes.
Example of a SQL Transaction
Bank Transfer Example
Consider transferring $500 from Account A to Account B in a banking system:
Understanding SQL Transactions: Concepts and Examples
Transaction Concept: Transactions are a set of operations used to perform a logical set of work. It is the bundle of all the instructions of a logical operation. A transaction usually means that the data in the database has changed. One of the major uses of DBMS is to protect the user’s data from system failures. It is done by ensuring that all the data is restored to a consistent state when the computer is restarted after a crash. The transaction is any one execution of the user program in a DBMS. One of the important properties of the transaction is that it contains a finite number of steps. Executing the same program multiple times will generate multiple transactions. Example: Consider the following example of transaction operations to be performed to withdraw cash from an ATM vestibule. Steps for ATM Transaction
- Transaction
- Start. 2. Insert your ATM card.
- 3. Select a language for your transaction.
- 4. Select the Savings Account option.
- 5. Enter the amount you want to withdraw.
- Enter your secret pin.
7. Wait for some time for processing.
8. Collect your Cash.
9. Transaction Completed.
A transaction can include the following basic database access operation.
● Read/Access data (R): Accessing the database item from disk (where the database stored data) to memory variable.
● Write/Change data (W): Write the data item from the memory variable to the disk.
● Commit: Commit is a transaction control language that is used to permanently save the changes done in a transaction
Understanding SQL Transactions: Concepts and Examples
******************************************************************************