0% found this document useful (0 votes)
13 views

Databases (24303) Group 01: Physical Model: Transactions and DBMS Structure

The document discusses transactions and the structure of databases in a DBMS. It defines a transaction as a set of operations that execute as a single indivisible unit. It describes how transactions support concurrency and ensure data consistency when multiple users access the same data simultaneously. It also explains how databases are organized into catalogs and schemas to differentiate objects within a DBMS managing multiple databases.

Uploaded by

Leo Barcino
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
13 views

Databases (24303) Group 01: Physical Model: Transactions and DBMS Structure

The document discusses transactions and the structure of databases in a DBMS. It defines a transaction as a set of operations that execute as a single indivisible unit. It describes how transactions support concurrency and ensure data consistency when multiple users access the same data simultaneously. It also explains how databases are organized into catalogs and schemas to differentiate objects within a DBMS managing multiple databases.

Uploaded by

Leo Barcino
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 29

Databases (24303)

Group 01
Physical Model: Transactions and DBMS Structure
Objectives
• Learn what a transaction is and how does it support concurrency
• Learn how databases are organized in catalogs and schemas

2
Transactions
Transactions
• How are bank accounts managed when two people have access to the
same account?

4
Transactions
• Often different users and/or applications will access the same data
simultaneously
• The DBMS will need to be able to handle these situations by ensuring
that the recovered data is true and consistent
• It will be part of the DBMS’s tasks to maintain referential integrity in
cases of concurrent access and simultaneous modification of
information

A transaction is a set of operations on a database that are executed as


a single indivisible unit

5
Transactions
• In real-world applications such as banking transactions, ticket or seat
reservations at airlines, etc., multiple users may be accessing the
same row and table in the database at the same time
• These types of situations can generate a response with inconsistent
data and/or uncertain data
• The use of transactions will allow us to protect data and applications
from anomalies caused by concurrent access to data

6
Example (I)
• Consider the following data from an airline’s DB:
• We want (FlightNum, Date, SeatNum, State)
• Check the availability of a given seat(Q1)
SELECT SeatNum, State
FROM Flights
WHERE FlightNum = 123
AND Date = ‘2016-10-20’;
• Update the reservation for seat 23 (U1)
UPDATE Flights
SET State = 1
WHERE FlightNum = 123
AND Date = ‘2016-10-20’
AND SeatNum = 23
LIMIT 1;

7
Example (I)
Joan Anna

Q1 Q1

DB

U1 U1

Both users think they’ve reserved seat 23

8
Transactions
•Selection and reservation operations should be performed
together and consecutively
•Even if serial execution is guaranteed, we face other
potential problems:
a. Connexion loss
b. Corrupt tables
c. Broken referential integrity
d. Table lock

9
Example (II)
• We consider the transfer of 1000€ from account 200 to 300 following the following algorithm:
• Transfer 1000€ to account 300
UPDATE Account
SET Balance = Balance + 1000
WHERE AccountNum = 300;
• Charge 1000€ to account 200
UPDATE Account
SET Balance = Balance – 1000
WHERE AccountNum = 200;

• A drop in connectivity after the sum and prior to the deduction would cause the bank to have €
1000 which could not justify
• The solution is for the updates to run either TWO or NONE of them so that the DB is in a consistent
state

10
Transactions
• SQL allows you to group several BD operations into one transaction
START TRANSACTION
<SQL queries>
• A transaction is finished by:
a. COMMIT: all changes are applied to the DB
b. ROLLBACK: no changes are applied to the DB
• Data changes that occur during the execution of the transaction's SQL
operations may or may not be "visible" to other users of the Database

11
Running Transactions
• Problems with "serialization" and grouping queries are solved with
transactions
• MySQL allows autocommit configuration, so as soon as an update is
run on a table, it becomes permanent
SET autocommit = {0 | 1}
• Once the transaction is activated, the autocommit will be deactivated
and subsequent operations will be part of it until its completion is
explicitly indicated
• Transactions are not closed blocks of code, the beginning and end of
the set of operations will be marked as part of the transaction
12
MySQL transactions
• By default MySQL executes a COMMIT at the end of each of the SQL statements so that
each statement is atomic; as if delimited by START TRANSACTION and COMMIT
• A ROLLBACK cannot be executed to undo the changes; but if an error occurs during the
execution of the order, the changes made will be discarded
• In order to allow control over a series of orders, we will explicitly indicate the start of a
transaction
START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;
• Once a COMMIT or ROLLBACK happen, it will return to autocommit mode
13
Transaction types
• Transaction types
• READ ONLY
• READ WRITE
• READ ONLY transactions do not modify the database, it allows its execution
in parallel with other transactions that consult the same data
• By default the transactions are READ WRITE
• To declare the type of a transaction we will use the syntax:
SET TRANSACTION {READ ONLY | READ WRITE}
• A transaction type cannot be declared if one is already in progress

14
ACID properties
• Atomicity:
• The set of operations of a transaction is a unit of atomic and indivisible execution
• If not all operations are performed, the pre-start state must be restored
• Consistency:
• Execution will preserve the consistency and coherence of the database, maintaining referential
integrity, domain integrity, etc
• Isolation:
• It will be executed without interference from any other action that can be performed concurrently
• Durability:
• The result of a transaction will be final
• The tables and data involved will be modified only after the COMMIT

15
Concurrency level
• With transaction isolation, blocking tables and data can affect the
performance of applications that access it
• The DBMS must be able to detect possible overlaps in order to
optimize the use of available resources and favor the speed of
execution of operations

The concurrency level will indicate how the available resources will be
used, depending on the overlapping of certain operations within
different transactions.

16
Transaction isolation
• To declare the level of concurrence of a transaction we will use the syntax:
SET TRANSACTION ISOLATION LEVEL <nivel>;
• The level types will be:
• READ UNCOMMITTED: allows you to read data that has not been confirmed by
other transactions
• READ COMMITTED: only data that has been confirmed is read, waiting for the other
transactions to complete
• REPEATABLE READ: specifies that the same tables could be read in the transaction
(the table is locked until the end)
• SERIALIZABLE: blocks a range of values in a table to simulate serial execution

17
Responsibilities
• Properly planning the order of operations that will be executed within a
transaction will be important
• It will be necessary:
• Determine if an operation is essential as part of a transaction
• Determine whether a transaction can be subdivided to ensure concurrency is maintained
• The developer must ensure that the transactions will have a minimum duration,
ensuring the coherence and consistency of the data
• The DBMS must guarantee an optimal plan for executing write and read requests:
• Respecting the rules of integrity.
• Enabling a return to a previous state.

18
DBMS Structure
Relational DBMS structure
• A database management system (DBMS) can manage more than one database
• In a relational database, data is stored in table objects
• The names of the DB objects (tables, views, columns, procedures, triggers,
functions, etc.) can be repeated from one database to another
• Objects need to be organized within an DBMS in order to differentiate them from
objects in other databases

20
Relational c structure
• An DBMS that supports SQL will consist
of a series of hierarchically structured
elements:
• Server: computer system that will manage
the different data catalogs
• Catalog: A component that contains a set of
database schemas
• Schema: A component that allows you to
group a set of tables, views, and other
objects in a user-owned logical model

21
Relational DBMS structure: example
• Consider a company with two different development teams:
a. Warehouse management
b. Sales and marketing management
• Each team has its own database, independent of the other
• The IT operations team stores the two databases in a single server
• A catalog is created for each development team:
• 'warehouse'
• 'sales'
• Each team organizes their tables by theme in different schemas
• Coincidentally, the two teams store the accounting data in a schema called “accounting”
• Using the same schema name is not a problem because catalogs have their own
namespace
22
Catalog
The catalog is the place where all the schemas (external, conceptual, internal) and
all the corresponding assignments (external / conceptual, conceptual / internal)
are maintained. We may picture a catalog as a database

• The catalog contains detailed information (descriptor information or metadata)


for various objects of interest to the system itself
• The optimizer uses the catalog information about indexes and other physical storage
structures to implement user requests
• The security subsystem uses the catalog information about users and security restrictions to
grant or deny such requests

23
Schema
A schema is a DB object that belongs to a specific database and contains several
database objects that will allow us to define its structure and behavior. A database
can contain one or more schemas

• In MySQL, physically, a schema is synonymous with a database


• The CREATE SCHEMA and CREATE DATABASE commands will be the
same
• For example, in Oracle, a schema represents only a part of a
database: tables and other objects owned by a single user

24
System catalog (I)
• The catalog, in addition to user-defined schemas, contains its own
schema called INFORMATION_SCHEMA
• This schema provides information on:
• Database metadata
• Name, creation script and details of all BD objects in the catalog
• Detail of the defined integrity rules
• Access privileges
• This schema is also called a data dictionary or system catalog

25
System catalog (II)
• MySQL offers a series of commands to know the structure of our database:
• SHOW TABLES;
• DESCRIBE <table>;
• SHOW CREATE TABLE <table>;
• SHOW INDEX {IN|FROM} <table>;

• From the INFORMATION_SCHEMA:


• USE information_schema;
• SHOW TABLES;
• SELECT TABLE_NAME FROM TABLES WHERE TABLE_SCHEMA LIKE
'world';
• SELECT COLUMN_NAME, COLUMN_TYPE
FROM COLUMNS
WHERE TABLE_SCHEMA LIKE
'world' AND COLUMN_TYPE LIKE 'int%';
26
Example
• https://demo.phpmyadmin.net/STABLE/index.php

USE WORLD;
CREATE VIEW citymap AS SELECT * FROM City;

USE INFORMATION_SCHEMA;

SELECT *
FROM VIEWS
WHERE table_name LIKE '%citymap%';

27
Summary
Summary
• We've seen what transactions are and how to manage concurrency in
access to information
• We've seen the structure of a database
• We have seen how the metadata of a database is managed in a
schema specific to each catalog

29

You might also like