vault backup: 2024-01-30 17:38:22
This commit is contained in:
4
.obsidian/workspace.json
vendored
4
.obsidian/workspace.json
vendored
@@ -6,7 +6,7 @@
|
||||
{
|
||||
"id": "f52c29341d47e672",
|
||||
"type": "tabs",
|
||||
"dimension": 85.46511627906976,
|
||||
"dimension": 50.872093023255815,
|
||||
"children": [
|
||||
{
|
||||
"id": "d9a3d1a4a3f2cc4d",
|
||||
@@ -25,7 +25,7 @@
|
||||
{
|
||||
"id": "7b5e68cfd661dd0d",
|
||||
"type": "tabs",
|
||||
"dimension": 14.534883720930234,
|
||||
"dimension": 49.127906976744185,
|
||||
"children": [
|
||||
{
|
||||
"id": "505b4bbc8a7e15f6",
|
||||
|
@@ -35,12 +35,99 @@ However, if they withdraw at the same time, the final balance would be £300 OR
|
||||
Although the AQL code is written correctly, the database may be in an inconsistent state after processing transactions due to failures of hard / software / multiple users accessing the db.
|
||||
A consistent state of the database means it satisfied all the constraints specified in the schema ( overall description of the database: pk, fk, referential integrity, etc. ), and any other constraints on the database that should hold ( eg. semantic constraints. )
|
||||
|
||||
# Transaction
|
||||
# Transaction
|
||||
|
||||
An action / series of actions, carried out by a single user or application program that reads or updates the contents of the database.
|
||||
- A transaction is treated as a logical unit of work on the database. This may be
|
||||
An action / series of actions, carried out by a single user or application program that reads or updates the contents of the database.
|
||||
|
||||
- A transaction is treated as a logical unit of work on the database. This may be
|
||||
- An entire program
|
||||
- Part of a program
|
||||
- A single statement
|
||||
- A single statement
|
||||
|
||||
## Simple Transaction Language
|
||||
|
||||
read(X) transfers the data item X from the database on secondary storage to a variable, also called X, in a buffer (on primary storage) belonging to the transaction that executed the read operation.
|
||||
write(X) transfers the value in the variable X in the buffer(on primary storage) of the transaction that executed the write to the data item X in the database (on secondary storage).
|
||||
|
||||
## ACID Properties
|
||||
|
||||
### Atomicity
|
||||
|
||||
- Must run to completion or have no effect at all
|
||||
|
||||
### Consistency
|
||||
|
||||
- Should correctly transform the database from one consistent state or another
|
||||
|
||||
### Isolation
|
||||
|
||||
- Should appear as though it is being executing in isolation from other transactions
|
||||
- Other transactions executing concurrently should not interfere with the execution
|
||||
|
||||
### Durability
|
||||
|
||||
- Changes applied must persist
|
||||
|
||||
## Basic Ideas
|
||||
|
||||
- Can have 2 outcomes.
|
||||
- Success: transaction commits and database is consistent
|
||||
- Failure: transaction aborts, must be restored to consistent state.
|
||||
- Committed transactions cannot be aborted.
|
||||
|
||||
# Schedules
|
||||
|
||||
## Serial Schedules
|
||||
|
||||
Operations of each transaction are executed consecutively without interleaved operations from other transactions.
|
||||
|
||||
No interference between transactions: only one at a time.
|
||||
No matter which is chosen, serial execution never leaves the database in an incorrect state, assuming the transaction is correct, hence we can assume every serial execution is correct.
|
||||
|
||||
## Simple Bank Application
|
||||
|
||||
3 Bank Accounts: A, B, C
|
||||
Each account has initial balance of £500
|
||||
2 transactions to be performed
|
||||
Transaction T1: A -> £100 -> B
|
||||
Transaction T2: A -> £100 -> C
|
||||
|
||||
No matter the order of these transactions, the total balance of all accounts, £1500, should stay the same. Additionally, the balance of A should decrease by £200, and the others increase by £100.
|
||||
|
||||
## Benefits of Concurrency
|
||||
|
||||
### Improved throughput & resource utilisation
|
||||
CPU and I/O can operate in parallel
|
||||
When disk is not used, a second transaction can be utilising CPU, improving resource utilisation and decreasing waiting times.
|
||||
|
||||
# Tutorial: Transactions and Security
|
||||
|
||||
1. A major objective in developing a database is to enable many users to access shared data concurrently. Explain why concurrent access is relatively easy if all users are only reading data. Illustrate your answer using the example of an on-line railway timetable.
|
||||
|
||||
Since the DBMS does not have to update any data in the database, and only has to access it. There is no processing involved, only retrieval. Transactions cannot interfere.
|
||||
|
||||
2. Explain the following statement. “A transaction is a logical unit of work.”
|
||||
|
||||
Each transaction is a sequence of logically related commands that accomplish one task and transform the database from one consistent state into another. It must be completed or not completed, no intermediate state is allowed.
|
||||
|
||||
3. The DBMS does not guarantee that the semantic meaning of the transaction truly represents the real-world event. Who does have responsibility for the semantic meaning? What are the possible consequences of this limitation? Illustrate your answer using a transaction that is intended to transfer money from one bank account to another.
|
||||
|
||||
The DBMS just checks a transaction has correct syntax. The input, and how the database is created defines the semantic context. The database engineer and front end UX designer has the responsibility to define the semantic meaning of the data. If the online banking page does not define the meaning of an input box to transfer funds, it is not the DBMS' fault.
|
||||
|
||||
4. Name the four properties of database transactions which make up the acronym ACID. Describe each of the ACID properties.
|
||||
|
||||
Atomicity: Must run to completion or have no effect at all
|
||||
Consistency: Should correctly transform the database from one consistent state or another
|
||||
Isolation: Should appear as though it is being executing in isolation from other transactions & Other transactions executing concurrently should not interfere with the execution
|
||||
Durability: Changes applied must persist
|
||||
|
||||
5. Explain why the DBMS alone cannot be expected to uphold the responsibility for the consistency property. Illustrate your answer using a transaction that is intended to transfer money from one bank account to another.
|
||||
|
||||
Can enforce all constrains that have been specified on the database schema such as integrity constraints. This is insufficient. If the programmer makes a logic error, it will be left inconsistent. The DBMS does not have the ability to correct or detect this.
|
||||
|
||||
6. Why do database systems support concurrent execution of transactions, in spite of the extra programming effort needed to ensure that concurrent execution does not cause any problems?
|
||||
|
||||
Having the ability to support concurrent transactions is beneficial to the operation of the database. It improves the waiting time and resource allocation.
|
||||
|
||||
7. Justify the following statement. “Executing transactions concurrently is more important when data must be fetched from secondary storage or when transactions are long, and is less important when data is in primary storage and transactions are very short.”
|
||||
|
||||
|
Reference in New Issue
Block a user