1. Multimedia Laboratory
Chap 1.
What Is It All About?
Kang Young Mo
Multimedia Laboratory
Sogang University

2. Table of Contents 1.1 Goal and Overview 1.2 Application Examples
1.3 System Paradigms
1.4 Virtues of Transactions
1.5 Architecture of Database Servers

3. 1.1 Goal and Overview
Transaction Processing has been a cornerstone of modern information tech.
OLTP(Online-Transaction Processing) : Banking, Stock Trading, Travel Agency, etc.
We must deal with distributed systems of large scale, heterogeneous.
The Key Problem of Transaction :
Keeping data consistent in concurrent data accesses and despite all sorts of failures.
Additional Key Property of Transaction :
Abstract Concept of Transaction – invisible to the application logic.
In other words, application developers are completely freed from burden of the dealing
with system issues.

4. 1.2 Application Examples OLTP Example: Debit/Credit
Embedded SQL in C Program.
Data in the underlying database is shared by all programs.
void main ( ) {
EXEC SQL BEGIN DECLARE SECTION
int b /*balance*/, a /*accountid*/, amount;
EXEC SQL END DECLARE SECTION;
/* read user input */
scanf (“%d %d”, &a, &amount);
/* read account balance */
EXEC SQL Select Balance into :b From Account
Where Account_Id = :a;
/* add amount (positive for debit, negative for credit) */
b = b + amount;
/* write account balance back into database */
EXEC SQL Update Account
Set Balance = :b Where Account_Id = :a;
EXEC SQL Commit Work; }

5. 1.2 Application Examples OLTP Example: Debit/Credit (Cont’d)
A huge number of clients : Need Concurrent Executions.
Concurrency or parallelism may cause inconsistencies,
requires concurrency control for “isolation”
P Time P2
Select Balance Into :b1
From Account
Where Account_Id = :a
/* b1=0, a.Balance=100, b2=0 */
Select Balance Into :b2
2 From Account
/* b1=100, a.Balance=100, b2=100 */
b1 = b
/* b1=50, a.Balance=100, b2=100 */
4 b2 = b2 +100
/* b1=50, a.Balance=100, b2=200 */
Update Account
Set Balance = :b
/* b1=50, a.Balance=50, b2=200 */
6 Set Balance = :b2
/* b1=50, a.Balance=200, b2=200 */
<P1,P2> or <P2,P1> : a.Balance must be 150 for consistency!!!

6. 1.2 Application Examples OLTP Example: Fund Transfer
“All-or-Nothing paradigm” should be applied.
void main ( ) {
/* read user input */
scanf (“%d %d %d”, &sourceid, &targetid, &amount);
/* subtract amount from source account */
EXEC SQL Update Account
Set Balance = Balance - :amount Where Account_Id = :sourceid;
/* add amount to target account */
Set Balance = Balance + :amount Where Account_Id = :targetid;
EXEC SQL Commit Work; }
Hardware or
Software Failure
Failures may cause inconsistencies,require recovery for “atomicity” and “durability”.

7. 1.2 Application Examples E-Commerce Example
Client requests may span multiple databases, and other information sources.
May consist of multiple servers, often with heterogeneous software.
Mutual consistency of all this data is crucial and thus important to maintain.
Shopping at Internet book store:
client connects to the book store's server and starts browsing
and querying the store's catalog.
client fills electronic shopping cart.
upon check-out client makes decision on items to purchase.
client provides information for definitive order
(including credit card or cyber cash info)
merchant's server forwards payment info to customer's bank
credit or card company or cyber cash clearinghouse
when payment is accepted, shipping of ordered items is initiated
by the merchant's server and client is notified.
Distributed, heterogeneous system with general information/document/mail servers and transactional effects on persistent data and messages.

8. 1.2 Application Examples Workflow Example
Workflows are (the computerized part of) business processes, consisting of a set of
(automated or intellectual) activities with specified control and data flow between them.
e.g., specified as a state chart.
In state chart, each oval denotes a state, and each state in turn corresponds to one activity.
When state is entered, invoke a proper application.
In single transaction (travel planning workflow), incorporates all effects on the underlying
information systems.
Workflow should have all-or-nothing(atomic property), can be executed concurrently.
Conference travel planning:
Select a conference, based on subject, program, time, and place.
If no suitable conference is found, then the process is terminated.
Check out the cost of the trip to this conference.
Check out the registration fee for the conference.
Compare total cost of attending the conference to allowed budget,
and decide to attend only if the cost is within the budget.

9. 1.2 Application Examples Workflow Example (Cont’d) Go Select
/ Budget:=1000;
Trials:=1;
CheckConfFee Go
Select
Conference
Select
Tutorials
Compute
Fee
[Cost  Budget]
/ Cost =
ConfFee +
TravelCost
Check
Cost
[ConfFound]
/ Cost:=0
Check
Áirfare
[Cost > Budget
& Trials  3]
[!ConfFound]
Check
Hotel No
CheckTravelCost
[Cost > Budget & Trials < 3] / Trials++

10. 1.3 System Paradigms 3-Tier System Architectures Clients
- Presentation (GUI, Internet browser).
- Send business-oriented and concrete requests. E.g. e-Commerce shopping session.
Application server :
- Have a repository of executable application programs (Java applets, servlets)
- Abstract Business Object : Encapsulated Object like accounts, customers, shopping catalogs.
- Each object have a number of methods that can be invoked on own object.
- E.g. ERP(Enterprise Resource Planning) like SAP R/3.
- Request Brokering : Manage the application programs or business objects.
Spawn execution threads on behalf of client requests.
Monitor executions and handle various exceptions.
Manage creating, monitoring, terminating of sessions.
Based on middleware (CORBA, DCOM, EJB, SOAP, etc.).

11. 1.3 System Paradigms 3-Tier System Architectures (Cont’d)
Data server :
- Database : most prominent type.
- Document Servers(semistructured) : text or multimedia.
- Mail Servers
Specialization to 2-Tier Client-Server Architecture
Client-server with “fat” clients (app on client + ODBC).
Application Programs reside on the clients.
Can maintain large number of sessions. Good comparability.
Client-server with “thin” clients (app on server, e.g., stored proc).
Have rich object encapsulation capability.
Less scalable, but useful for low-end and midsized applications.

12. 1.3 System Paradigms 3-Tier System Architectures Stored Data (Pages)
Server
Application
Clients
Users
. . .
Program 1
Program 2
...
Objects
encapsulated
data
exposed
Request
Reply

13. . . . ... 1.3 System Paradigms Federation of Servers
Large distributed database servers should
be viewed like as the same database.
E.g. Enterprise have worldwide branches.
Each server may use different products,
in other words, they are heterogeneous.
The infrastructure of Federated system
architecture is referred to as middleware.
Place between the application programming
level and computer operating systems.
Key purpose : provide high-level communication mechanism between clients and servers.
E.g. Heterogeneous software : DCOM, CORBA, JAVA RMI, etc.
Data
Servers
Application
Clients
Users
. . .
...

14. 1.4 Virtues of Transaction
ACID Properties of Transactions
Atomicity : all-or-nothing effect, simple (but not completely transparent) failure handling.
Consistency-preservation : transaction abort upon consistency violation.
Isolation : only consistent data visible as if single-user mode, concurrency is masked
to app developers.
Durability (persistence) : committed effects are failure-resilient.
Transaction programming interface (“ACID contract”)
Begin transaction.
Commit transaction (“commit work” in SQL).
Rollback transaction (“rollback work” in SQL).

15. 1.4 Virtues of Transaction
Requirements on Transactional Servers
Server Components :
Concurrency Control : guarantees isolation.
Recovery : guarantees atomicity and durability.
Performance : high throughput (committed transactions per second), short response time.
Reliability: (almost) never lose data despite failures.
Availability: very short downtime, almost continuous, 24x7, service.

16. 1.5 Architecture of Database Server
Database System Layers
Language & Interface Layer :
Application programming interface,
SQL by using ODBC.
Query Decomposition & Optimization Layer :
Represent tree of a request. In case of complex
query predicate, makes a choice among different
execution plans that are equivalent in terms of
execution efficiency.
Query Execution Layer :
Each operator in a tree is mapped to a piece of server code. E.g. sorting code, join algorithm.
Access Layer : Index structure and capability for data manipulation are provided.
Storage Layer : manage the pages of a database and optimize caching.

17. 1.5 Architecture of Database Server
Storage Structure
Data records reside on disk in page. Typical page size is on the order of 16KB.
Pages are the minimum unit of data transfer between a dusk and main memory.
A fixed number of pages called a block can be read or written together on disk.
Page header (typically less than a hundred bytes) :
contains administrative information for free space management.
Slot Array : have pointers(RID, Record ID) of each records in a page.
Extent : a range of pages that contiguous on disk.
When search a page on the disk, look up an entry extent table and adding a relative offset.

18. 1.5 Architecture of Database Server
Storage Structure
Database
Extent
Table
Page
Page Header
Slot Array
Ben 55
Las Vegas
...
Sue 23
Seattle
Joe 29
San Antonio
free space
forwarding
RID
---
Extents

19. 1.5 Architecture of Database Server
Access Structure
Desirable for an I/O cost that is at
most logarithmic.
Use an index structure for resolving
search space problem.
Search tree interface :
lookup <index> where <indexed field> = <search key>
lookup <index> where <indexed field> between <lower bound> and <higher bound>
e.g. B+ tree for index.
- Leaf nodes : all values of the indexed field.
- Non-leaf nodes : pairs of values, pointers to next lower level. These values is used for
guide a top-down search for a given key value.

20. 1.5 Architecture of Database Server
Query Execution Plan
When translate SQL into operator tree, take consideration into optimization.
Estimated execution cost must be minimum.
Each operator correspond to a code in the database system.
Select Name, City, Zipcode, Street
From Person
Where Age < 30
And City = "Austin"
Various Execution Plans are exist.

21. References
Gerhard Weikum and Gottfried Vossen, “Transactional Information Systems”, 2002.