Download ppt

SQL in a Programming
Environment - Part II
CIS 4301
Lecture Notes
Lecture 23 - 13/4/2006
Application Development

Often important to execute parts of the
application logic directly in process space
of DBMS


Why?
One solution: Programming Language for
DBMS
© CIS 4301 - Spring 2006
Lecture 23
2
DBMS Programming Language


Many DBMS's provide their own miniprogramming language that includes SQL,
variables, control constructs, procedures, etc.
 Simple, general-purpose language
 Smoothes over the discontinuity between the
programming language and SQL
 Runs in the DBMS
Used to create procedures or functions to be
stored with database schema


A.k.a. Persistent Stored Modules PSM (SQL/PSM)
A.k.a. Stored Procedures
© CIS 4301 - Spring 2006
Lecture 23
3
DBMS Programming Languages

E.g., Oracle’s Procedure Language SQL
(PL/SQL)



Primarily used for writing PSM’s and trigger
actions
User can execute PL/SQL interactively
(SQLPlus) or call it from host language
programs
For rest of lecture, use SQL/PSM standard
syntax
© CIS 4301 - Spring 2006
Lecture 23
4
Persistent Stored Modules

In SQL speak, application program is called
module




Collections of functions and procedure
definitions, temp. relation declarations,
optional local variable declarations
Invoked by users or applications
Stored inside DBMS, part of the schema
Modules communicate via parameters or
shared variables
© CIS 4301 - Spring 2006
Lecture 23
5
Persistent Stored Modules

Advantages



Reduces, in some cases even eliminates,
transfer of results to client – Example?
Allows re-use of code (write once – use
multiple times)
Encapsulation of database schema shields
application programmers from knowing details
of how data is stored
© CIS 4301 - Spring 2006
Lecture 23
6
Simple PSM Procedure
CREATE PROCEDURE LucasMovies
SELECT title, year
FROM Movie NATURAL JOIN
MovieExec
WHERE name = ‘Lucas’;
© CIS 4301 - Spring 2006
Lecture 23
7
PSM Procedure with Parameters
CREATE PROCEDURE Move(
IN oldAddr VARCHAR[255],
IN newAddr VARCHAR[255]
)
UPDATE MovieStar
SET address = newAddr
WHERE address = oldAddr;
© CIS 4301 - Spring 2006
Lecture 23
Parameters
Mode may be one of
IN, OUT, INOUT
8
A Few Explanations

INOUT parameter combines properties of
IN and OUT parameter



Pass values into the PSM
PSM can set their return values
PSM enforces strict type conformance

E.g., parameter of type INT cannot be called
with an argument of type VARCHAR
© CIS 4301 - Spring 2006
Lecture 23
9
PSM Functions and Procedures

So far, we have seen two examples of PSM
procedures




PSM function defined in almost same way




Can have IN, OUT, INOUT parameters
Optional local variable declarations
Executable body of code defining the procedure
Use keyword function
Specify return type
Parameters only of type IN (i.e., no side-effects)
When to use procedure/function?

Same reasoning as in programming language applies
– which is?
© CIS 4301 - Spring 2006
Lecture 23
10
PSM Statements

How do we invoke a PSM?

From a host-language program:



Statement of another PSM
As an SQL command issued to SQLPLUS



EXEC SQL CALL Move (:oldA, :newA);
CALL Move (“LA”, “Boston”);
Note, it is not permitted to call a PSM function! You can invoke
functions only as part of expressions
Other statements



DECLARE <name> <type>;
declaration of local variable
SET <variable> = <expression>;
assignment statement
IF <cond> THEN <statement list> ELSEIF <cond> THEN
<statement list> ELSEIF … ELSE <statement list> END IF;
if-then-elseif-else statement
© CIS 4301 - Spring 2006
Lecture 23
11
Miscellaneous


PSM standard has rich syntax
Not shown but covered in textbook:




Return statements for functions
Local variables, assignments, branching,
loops
Exception handling
Check out Oracle Help topic # 5, “Using
Oracle PL/SQL”
© CIS 4301 - Spring 2006
Lecture 23
12
SQL Environment


So far, tacitly assumed that our program
runs on the same server where the
database is installed
Did not worry about explicit connection to
database


Assumed default connection to the server
and the database
In reality, the situation is more complex
© CIS 4301 - Spring 2006
Lecture 23
13
SQL Environment
SQL-agent
(execution of a
module)
SQL Client
SQL Environment
Connection
Session
SQL Server
(SQL operations
that are performed
while connection
is active)

Modules
 Generic SQL Interface
 Embedded SQL
 PSM modules
© CIS 4301 - Spring 2006
Lecture 23

Connection: Want to run
program involving SQL at
a host where SQL client is
running, need to open
connection between client
and server
14
Call-Level Interfaces

A more modern approach to the hostlanguage/SQL connection is a call-level
interface (CLI)



C (or other language) program creates SQL
statements as character strings and passes them to
functions that are part of a library
Similar to what really happens in embedded
SQL implementations
Two major approaches:


SQL/CLI (standard of ODBC = open database
connectivity)
JDBC (Java database connectivity), links Java
programs to DB in an O-O style
© CIS 4301 - Spring 2006
Lecture 23
15
Introduction to JDBC
1. Load a driver for the database system we will use
(creates an object called DriverManager)
Installation-dependent, see Oracle help pages for details
2. Establish connection to database: applying method
getConnection to DriverManager creates variable
of type Connection
Java Statement:
Connection myCon =
DriverManager.getConnection(<URL>,
name,password);
© CIS 4301 - Spring 2006
Lecture 23
16
Intuition





By applying the appropriate methods to a
connection like myCon, we can create
statement objects
Place SQL statements “in” objects
Bind values to SQL statement parameters
Execute SQL statements
Examine results a tuple at a time
© CIS 4301 - Spring 2006
Lecture 23
17
Executing a SELECT Query in JDBC
Query: SELECT netWorth FROM MovieExec;
1. Create statement object and execute directly
Statement execStat=myCon.createStatement();
ResultSet Worths=execStat.executeQuery(
“SELECT netWorth FROM MovieExec”);
OR
2. Prepare query and execute later
PreparedStatement
execStat=myCon.createStatement(“SELECT
netWorth FROM MovieExec”);
ResultSet Worths = execStat.executeQuery();
© CIS 4301 - Spring 2006
Lecture 23
18
Executing a Parameter-less Update
Update: Insert new fact into StarsIn table
1. Create statement object and execute directly
Statement starStat=myCon.createStatement();
starStat.executeUpdate(“INSERT INTO StarsIn
VALUES (‘Remember the Titans’, 2000,
‘Denzel Washington’)” );
OR
2. Prepare update and execute later
PreparedStatement
starStat=myCon.createStatement(“INSERT
INTO StarsIn VALUES (‘Remember the
Titans’, 2000, ‘Denzel Washington’)”);
starStat.executeUpdate();
© CIS 4301 - Spring 2006
Lecture 23
19
Cursor Operations


When we obtain result set object, we may
run cursor through tuples of result
ResultSet class provides useful methods


Next(), returns FALSE if there is no next tuple
getString(i), getInt(i), getFloat(i),
etc.
Returns the ith component of the tuple currently
indicated by cursor
While(Worths.next()) {
Worth = Worths.getInt(1);
/* process this net worth */
}

© CIS 4301 - Spring 2006
Lecture 23
20
Accessing the Result Set


JDBC offers a number of methods to find out where you are in the
result set using getRow, isFirst, isBeforeFirst, isLast, isAfterLast
Means to make scroll-able cursors allow free access of any row in the
result set


Default, cursors scroll forward only and are read only
When creating a Statement for a Connection, you can change the type of
ResultSet to a more flexible scrolling or updatable model:
Statement stmt = MyCon.createStatement(
ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_READ_ONLY);
ResultSet rs = stmt.executeQuery("SELECT * FROM MovieExec");
© CIS 4301 - Spring 2006
Lecture 23
21
Accessing the Result Set

The different options for types are




You can choose whether the cursor is read-only or updatable using
the options




TYPE_FORWARD_ONLY
TYPE_SCROLL_INSENSITIVE
TYPE_SCROLL_SENSITIVE
CONCUR_READ_ONLY
CONCUR_UPDATABLE
With default cursor, you can scroll forward using rs.next()
With scroll-able cursors you have more options:




rs.absolute(3); // moves to the third tuple
rs.previous(); // moves back one tuple (tuple 2)
rs.relative(2); // moves forward two tuples (tuple 4)
rs.relative(-3); // moves back three tuples (tuple 1)
© CIS 4301 - Spring 2006
Lecture 23
22
Parameter Passing




How do we pass parameters into query?
Use question mark in place of portion of query, then
bind values to those parameters
Need to create prepared statement
Need to apply to statement objects methods such as



setString(i, v)
setInt(i, v)
Bind value v, which must be of appropriate type, to
the ith parameter in the query
© CIS 4301 - Spring 2006
Lecture 23
23
Parameter Passing
PreparedStatement
studioStat=myCon.createStatement(“INSERT
INTO Studio(name, address) VALUES (?,?)”);
/* get values for variables studioName and studioAddress
from user */
studioStat.setString(1, studioName);
studioStat.setString(2, studioAddr);
studioStat.executeUpdate();
© CIS 4301 - Spring 2006
Lecture 23
24
More Info…

For more info on how to use JDBC with
CISE’s Oracle installation see:
www.cise.ufl.edu/~jhammer/classes/Oracle/Intro_JDBC.htm
© CIS 4301 - Spring 2006
Lecture 23
25
Transactions in SQL
Multi-User Database Access

In many applications, database may need
to perform 100’s of ops/sec





Initiated at different sites
Perhaps involving same part of database at
the same time
Operations may interact in strange ways
E.g., banking, airline reservation
Let’s look at two specific problems
© CIS 4301 - Spring 2006
Lecture 23
27
Example: Order of Operations
void chooseSeat() { /* C code for obtaining flight date and seat, store in three
variables */
EXEC SQL SELECT occupied INTO :occ
FROM Flights
WHERE fltNum = :flight AND fltDate = :date AND
fltSeat = :seat;
if (!occ){
EXEC SQL UPDATE FLights
SET occupied = TRUE
WHERE fltNum = :flight AND fltDate = :date AND
fltSeat = :seat;
/* Code to record seat assignments and to inform user of
assignment */
}
else /* C code to notify user of unavailability and
ask for another seat selection. */
}
© CIS 4301 - Spring 2006
Lecture 23
28
What Could Go Wrong?
time
User 1 finds
seat empty
User 2 finds
seat empty
User 1 sets seat
to occupied
User 2 sets seat
to occupied




Possible to execute chooseSeat function correctly, yet have global result
not be correct
Problem can be solved by SQL mechanism that serves to serialize the
execution of the two function executions
Execution of functions is serial if one function executes completely
before any other function begins
Execution is serializable if they behave as if they were run serially, even
though execution may overlap in time
© CIS 4301 - Spring 2006
Lecture 23
29
Example: Execution of Operations as
Unity




Example: Transfer Money
Function transfer() that reads two accounts and an amount of
money
Checks that the first has at least that much money
If so, transfers money from first account to second
EXEC SQL BEGIN DECLARE SECTION;
int acct1, acct2; /* the two accounts */
int balance1; /* amount of money in the first account*/
int amount; /* transfer amount
EXEC SQL END DECLARE SECTION;
© CIS 4301 - Spring 2006
Lecture 23
30
Cont’d
void transfer() { /* C code for obtaining account info and transfer
amount */
EXEC SQL SELECT balance INTO :balance1
FROM Accounts
WHERE acctNo = :acct1;
if (balance1 >= amount){
EXEC SQL UPDATE Accounts
SET balance = balance + :amount;
WHERE acctNo = :acct2;
EXEC SQL Update Accounts
SET balance = balance - :amount;
WHERE acctNo = :acct1;
}
else /* C code to print message that there were insufficient funds to
make transfer. */
}
© CIS 4301 - Spring 2006
Lecture 23
31
What Could Go Wrong?


If failure occurs between two updates,database will be left in
inconsistent state
See that certain operations needs to be done atomically


Either all operations complete or none goes through
Simple solution: make changes in local workspace and commit to
database only after all work is done correctly
© CIS 4301 - Spring 2006
Lecture 23
32
Solution: Transactions

Solution to previous two problems is to group database operations
into transactions



Collection of one or more operations on the database that must be
executed atomically
In addition, SQL requires that transactions are executed in serializable
manner
How to control transactions in embedded SQL or CLI?



Transaction begins as soon as SQL statement begins
Optionally: START TRANSACTION
Two ways to end transaction:



COMMIT causes transaction to end successfully (exception: deferred
constraints)
ROLLBACK causes transaction to abort; any changes made to database are
undone (rolled back)
Transactions in generic SQL interface start and end with SQL
statement (exception: triggers)
© CIS 4301 - Spring 2006
Lecture 23
33
Transfer() with Transactions
void transfer() { /* C code for obtaining account info and transfer amount */
EXEC SQL SELECT balance INTO :balance1
FROM Accounts
transaction
WHERE acctNo = :acct1;
starts here
if (balance1 >= amount){
EXEC SQL UPDATE Accounts
SET balance = balance + :amount;
WHERE acctNo = :acct2;
EXEC SQL Update Accounts
SET balance = balance - :amount;
WHERE acctNo = :acct1;
EXEC
}
else { /*
transfer.
EXEC
SQL COMMIT;
C code to print message that there were insufficient funds to make
*/
SQL ROLLBACK;}
}
© CIS 4301 - Spring 2006
Lecture 23
34
Transaction Properties

Transactions obey the "ACID properties“





Atomicity
Consistency
Isolation
Durability
How are ACID properties achieved?

Take COP 4720
© CIS 4301 - Spring 2006
Lecture 23
35
Read-Only Transactions

Reading and writing may lead to
serialization problems


Enforcement of serializability may result in
lower transaction throughput
When transaction only reads data, DBMS
has more freedom to let transactions
execute in parallel


EXEC SQL SET TRANSACTION READ ONLY
Must be executed before transaction begins
© CIS 4301 - Spring 2006
Lecture 23
36
Weaker Properties



There's a lot of overhead to guaranteeing
the ACID properties
Sometimes full isolation (i.e., full
serializability) is not required
Following is a discussion of some of the
ways we can use transactions with less
overhead
© CIS 4301 - Spring 2006
Lecture 23
37
Dirty Reads

Dirty data is a common term for data written by
transaction that has not yet committed


Dirty read is read of dirty data
Risk in reading dirty data is that transaction that wrote
may abort


Dirty data removed from database to roll back to clean state
But: What happens to transaction that has read dirty data and
then committed?


Sometimes dirty read matters, sometimes doesn’t
Sometimes makes sense to take risk to avoid:


© CIS 4301 - Spring 2006
Time-consuming work by DBMS to avoid dirty reads
Loss of parallelism that results from waiting until there isno possibility
of dirty read
Lecture 23
38
Example 1: New Money Transfer
Program P
P
(1) Add money to account 2
(2) Test if account 1 has enough money
 If false, remove money from account 2 and abort
 If true, subtract money from account 1 and commit




Strange but ok if executed serializably
What if dirty reads are possible?
Imagine three accounts A1 ($100), A2 ($200), and A3 ($300)
T1 executes P to transfer $150 from A1 to A2 while T2 runs P to
transfer $250 from A2 to A3
© CIS 4301 - Spring 2006
Lecture 23
39
Possible Scenario






T2 adds $250 to A3, now has $550
T1 adds $150 to A2, now has $350
T2 executes test on A2 ($350) and allows
transfer from A2 to A3 to occur
T1 executes test of on A1 ($150) which has not
enough funds
T2 subtracts $250 from A2 and commits; A2
($100)
T1 subtracts $150 from A2 which now has -$50;
T1 commits
© CIS 4301 - Spring 2006
Lecture 23
40
Example 2: New Seat Selection
Program S
(1)
S
Find available seat; reserve it by setting occupied flag to 1; if none,
abort
(2) Ask customer for approval

If yes, commit

If no, release seat and set occupied flag to 0; repeat step 1 to
get other seat



Problem: If two transactions execute at roughly the same
time, one might reserve seat S, which is later rejected by
customer; second transaction may not get option to chose
seat for that point in time; may need retry
Dirty read has occurred
Not as serious as in previous scenario; re-running transaction
will give seat to second traveler
© CIS 4301 - Spring 2006
Lecture 23
41
Isolation Level: Allowing Dirty Reads
SET TRANSACTION READ WRITE
ISOLATION LEVEL READ UNCOMMITTED;
© CIS 4301 - Spring 2006
Lecture 23
Must specify,
ow assumed to be
Read-only
42
Other Isolation Levels

Total of four isolation levels






SERIALIZABLE (default)
REPEATABLE READ
READ COMMITTED
READ UNCOMMITTED (Dirty Read)
SET TRANSACTION ISOLATION LEVEL ...
Subtle point: the isolation level of a
transaction affects only what data that
transaction may see

Does not affect what any other transaction sees
© CIS 4301 - Spring 2006
Lecture 23
43
Isolation Level: Read Committed


Let’s run seat choosing function with
isolation level “read committed”
What happens when other transactions
run in parallel?
© CIS 4301 - Spring 2006
Lecture 23
44
Isolation Level: Repeatable Read





If tuple is retrieved first time, then we can be sure it is
retrieved again if query is repeated
However, new tuples may be visible as well during
subsequent executions (phantom tuples)
Example:
If we execute seat-choosing problem under repeatable
read isolation, if a seat is available on the first query,
then it is available under subsequent queries
In addition, if more seats become available (e.g.,
bigger plane), additional seats also visible during
subsequent queries
© CIS 4301 - Spring 2006
Lecture 23
45