1. CPSC-310 Database Systems
Professor Jianer Chen
Room 315C HRBB
Lecture #23

2. Call-Level-Interface: SQL/CLI
SQL/CLI uses a library of functions (sqlcli.h) and calls them as part of an ordinary C program.
C connects to the database by structs of the following types:
* Environments: represent the DBMS installation.
* Connections: logins to the database.
* Statements: SQL statements to be passed to a connection.
* Descriptions: records about tuples from a query or parameters of a statement.

3. Environment/Connection/Statements
Function SQLAllocHandle(T,I,O) is used to create these structs, which are called environment/connection/statement handles.
* T = type, e.g., SQL_HANDLE_STMT (DBC, ENV).
* I = input handle = struct at next higher level
* O = the created output handle.
Example.
SQLAllocHandle(SQL_HANDLE_STMT, myCon, &myStat);
* myCon is a previously created connection handle.
* myStat is the name of the statement handle that will be created.

4. Preparing and Executing
SQLPrepare(H, S, L) causes the string S, of length L, to be interpreted as an SQL statement and optimized; the executable statement is placed in statement handle H.
SQLExecute(H) causes the SQL statement given by statement handle H to be executed.
If we will execute a statement S only once, we can combine PREPARE and EXECUTE by calling:
SQLExecuteDirect(H, S, L);

5. Accessing Query Results by Fetching
For an SQL query, we need to access the tuples of the result. Thus, a cursor is implied, but it needs not be declared in CLI.

6. Accessing Query Results by Fetching
For an SQL query, we need to access the tuples of the result. Thus, a cursor is implied, but it needs not be declared in CLI.
SQLFetch(H) gets the next tuple from the result of the statement with handle H.

7. Accessing Query Results by Fetching
For an SQL query, we need to access the tuples of the result. Thus, a cursor is implied, but it needs not be declared in CLI.
SQLFetch(H) gets the next tuple from the result of the statement with handle H.
When we fetch a tuple, we need to put the components somewhere. A component is bound to a variable by function SQLBindCol.

8. Accessing Query Results by Fetching
For an SQL query, we need to access the tuples of the result. Thus, a cursor is implied, but it needs not be declared in CLI.
SQLFetch(H) gets the next tuple from the result of the statement with handle H.
When we fetch a tuple, we need to put the components somewhere. A component is bound to a variable by function SQLBindCol.
The function SQLBindCol has 6 arguments, where
The 1st argument = the handle of the query,
The 2nd argument = the column number,
The 4th argument = the address of the variable.

9. Example: Binding and Fetching

10. Example: Binding and Fetching
Suppose we have done SQLExecute(myStat), where myStat is the handle for the query
SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’

11. Example: Binding and Fetching
Suppose we have done SQLExecute(myStat), where myStat is the handle for the query
SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’
Bind the result to theBeer and thePrice:
SQLBindCol(myStat, 1, , &theBeer, , );
SQLBindCol(myStat, 2, , &thePrice, , );

12. Example: Binding and Fetching
Suppose we have done SQLExecute(myStat), where myStat is the handle for the query
SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’
Bind the result to theBeer and thePrice:
SQLBindCol(myStat, 1, , &theBeer, , );
SQLBindCol(myStat, 2, , &thePrice, , );
Now, we can fetch the tuples of the result by:
while ( SQLFetch(myStat) != SQL_NO_DATA) {
/* do something with theBeer and thePrice */ }

13. Example: Binding and Fetching
Suppose we have done SQLExecute(myStat), where myStat is the handle for the query
SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’
Bind the result to theBeer and thePrice:
SQLBindCol(myStat, 1, , &theBeer, , );
SQLBindCol(myStat, 2, , &thePrice, , );
Now, we can fetch the tuples of the result by:
while ( SQLFetch(myStat) != SQL_NO_DATA) {
/* do something with theBeer and thePrice */ }
CLI macro representing
SQLSTATE = = “failed to find a tuple.”

14. Java Database Connectivity (JDBC)

15. Java Database Connectivity (JDBC)
JDBC is a library similar to SQL/CLI, but with Java as the host language.

16. Java Database Connectivity (JDBC)
JDBC is a library similar to SQL/CLI, but with Java as the host language.
JDBC’s differences are often related to the object-oriented style of Java, but also others.

17. Java Database Connectivity (JDBC)
JDBC is a library similar to SQL/CLI, but with Java as the host language.
JDBC’s differences are often related to the object-oriented style of Java, but also others.
CLI progression environment-connection- statement also appears in JDBC.

18. Java Database Connectivity (JDBC)
JDBC is a library similar to SQL/CLI, but with Java as the host language.
JDBC’s differences are often related to the object-oriented style of Java, but also others.
CLI progression environment-connection- statement also appears in JDBC.
A connection object is obtained from the environment in a somewhat implementation- dependent way.

19. Java Database Connectivity (JDBC)
JDBC is a library similar to SQL/CLI, but with Java as the host language.
JDBC’s differences are often related to the object-oriented style of Java, but also others.
CLI progression environment-connection- statement also appears in JDBC.
A connection object is obtained from the environment in a somewhat implementation- dependent way.
We will assuming we have a connection object myCon.

20. Statements
JDBC provides two classes:

21. Statements JDBC provides two classes:
* Statement: an object that can accept a string that is an SQL statement and can execute such a string.
* PreparedStatement: an object that has an associated SQL statement ready to execute.

22. Statements JDBC provides two classes:
* Statement: an object that can accept a string that is an SQL statement and can execute such a string.
* PreparedStatement: an object that has an associated SQL statement ready to execute.
The Connection class has methods to create Statement and PreparedStatement.

23. Statements JDBC provides two classes:
* Statement: an object that can accept a string that is an SQL statement and can execute such a string.
* PreparedStatement: an object that has an associated SQL statement ready to execute.
The Connection class has methods to create Statement and PreparedStatement.
Statement stat1 = myCon.createStatement();
PreparedStatement stat2 = myCon.createStatement(
”SELECT beer, price FROM Sells ” +
”WHERE bar = ’Joe’’s Bar’ ” );

24. Statements JDBC provides two classes:
* Statement: an object that can accept a string that is an SQL statement and can execute such a string.
* PreparedStatement: an object that has an associated SQL statement ready to execute.
The Connection class has methods to create Statement and PreparedStatement.
createStatement with no argument returns
a Statement, and with an argument returns
a PreparedStatement.
Statement stat1 = myCon.createStatement();
PreparedStatement stat2 = myCon.createStatement(
”SELECT beer, price FROM Sells ” +
”WHERE bar = ’Joe’’s Bar’ ” );

25. Statements JDBC provides two classes:
* Statement: an object that can accept a string that is an SQL statement and can execute such a string.
* PreparedStatement: an object that has an associated SQL statement ready to execute.
The Connection class has methods to create Statement and PreparedStatement.
createStatement with no argument returns
a Statement, and with an argument returns
a PreparedStatement.
Statement stat1 = myCon.createStatement();
PreparedStatement stat2 = myCon.createStatement(
”SELECT beer, price FROM Sells ” +
”WHERE bar = ’Joe’’s Bar’ ” );
Java trick: +
concatenates
strings.

26. Executing SQL Statements
JDBC distinguishes queries from modifications, which it calls “updates.”

27. Executing SQL Statements
JDBC distinguishes queries from modifications, which it calls “updates.”
Statement and PreparedStatement each have methods executeQuery and executeUpdate.

28. Executing SQL Statements
JDBC distinguishes queries from modifications, which it calls “updates.”
Statement and PreparedStatement each have methods executeQuery and executeUpdate.
* For Statements, these methods have one argument: the query or modification to be executed.

29. Executing SQL Statements
JDBC distinguishes queries from modifications, which it calls “updates.”
Statement and PreparedStatement each have methods executeQuery and executeUpdate.
* For Statements, these methods have one argument: the query or modification to be executed.
* For PreparedStatements: no argument.

30. Examples

31. Examples
For Updates:

32. Examples
For Updates: stat1 is a Statement.

33. Examples For Updates: stat1 is a Statement.
We can use it to insert a tuple as:
stat1.executeUpdate(
”INSERT INTO Sells ” +
”VALUES(’Brass Rail’, ’Bud’, 3.00)” );

34. Examples For Updates: stat1 is a Statement.
We can use it to insert a tuple as:
stat1.executeUpdate(
”INSERT INTO Sells ” +
”VALUES(’Brass Rail’, ’Bud’, 3.00)” );
For Queries:

35. Examples For Updates: stat1 is a Statement.
We can use it to insert a tuple as:
stat1.executeUpdate(
”INSERT INTO Sells ” +
”VALUES(’Brass Rail’, ’Bud’, 3.00)” );
For Queries: stat2 is a PreparedStatement holding the query ”SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’ ”.

36. Examples For Updates: stat1 is a Statement.
We can use it to insert a tuple as:
stat1.executeUpdate(
”INSERT INTO Sells ” +
”VALUES(’Brass Rail’, ’Bud’, 3.00)” );
For Queries: stat2 is a PreparedStatement holding the query ”SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’ ”.
ResultSet Menu = stat2.executeQuery();

37. Examples For Updates: stat1 is a Statement.
We can use it to insert a tuple as:
stat1.executeUpdate(
”INSERT INTO Sells ” +
”VALUES(’Brass Rail’, ’Bud’, 3.00)” );
For Queries: stat2 is a PreparedStatement holding the query ”SELECT beer, price FROM Sells WHERE bar = ’Joe’’s Bar’ ”.
ResultSet Menu = stat2.executeQuery();
executeQuery returns an object of class ResultSet, which will be examined next.

38. Accessing the ResultSet

39. Accessing the ResultSet
An object of the class ResultSet is something like a cursor.

40. Accessing the ResultSet
An object of the class ResultSet is something like a cursor.
The method Next() to ResultSet advances the “cursor” to the next tuple.

41. Accessing the ResultSet
An object of the class ResultSet is something like a cursor.
The method Next() to ResultSet advances the “cursor” to the next tuple.
* The first time Next() is applied, it gets the first tuple.
* If there are no more tuples, Next() returns value FALSE.

42. Accessing the ResultSet
An object of the class ResultSet is something like a cursor.
The method Next() to ResultSet advances the “cursor” to the next tuple.
* The first time Next() is applied, it gets the first tuple.
* If there are no more tuples, Next() returns value FALSE.
When ResultSet is referring to a tuple, we can get the components of the tuple by applying methods getX(k) to ResultSet,

43. Accessing the ResultSet
An object of the class ResultSet is something like a cursor.
The method Next() to ResultSet advances the “cursor” to the next tuple.
* The first time Next() is applied, it gets the first tuple.
* If there are no more tuples, Next() returns value FALSE.
When ResultSet is referring to a tuple, we can get the components of the tuple by applying methods getX(k) to ResultSet, where X is some type, and k is the component number, returning the value of that component, which has the type X.

44. Example. accessing ResultSet
Menu is the ResultSet for the query “SELECT beer, price FROM Sells
WHERE bar = ‘Joe’’s Bar’ ”.

45. Example. accessing ResultSet
Menu is the ResultSet for the query “SELECT beer, price FROM Sells
WHERE bar = ‘Joe’’s Bar’ ”.
Access the beer and price from each tuple by:
while ( Menu.Next() ) {
theBeer = Menu.getString(1);
thePrice = Menu.getFloat(2);
/* do something with theBeer and thePrice */ }

46. Outline of Course A Related Question: How can SQL be
Executed with conventional
Programming languages?
Representing things by tables
E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch.3)
Basic operations on relations
Relational Algebra (Chs. 2,5)
Storage management
(Chs. 13,14)
SQL languages in DDL/DML
(Ch. 6)
How does SQL get executed
(Chs. 9,15,16)
More on SQL
(Chs. 7,8)
Transaction processing
(Chs. 6,18,19)

47. Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch.3)
Basic operations on relations
Relational Algebra (Chs. 2,5)
Storage management
(Chs. 13,14)
SQL languages in DDL/DML
(Ch. 6)
How does SQL get executed
(Chs. 9,15,16)
More on SQL
(Chs. 7,8)
Transaction processing
(Chs. 6,18,19)

48. Transaction Processing

49. Transaction Processing
Facts

50. Transaction Processing
Facts
Database systems are normally being accessed by many users or processes (doing queries and modifications) at the same time, where troublesome interactions may occur.

51. Transaction Processing
Facts
Database systems are normally being accessed by many users or processes (doing queries and modifications) at the same time, where troublesome interactions may occur.
Operations on database may take time, and may need to make changes in the database, while the system may fail during the execution of the operations.

52. Example 1: Interacting Processes

53. Example 1: Interacting Processes
Assume the Sells(bar, beer, price) relation, and suppose that Joe’s Bar sells only Bud for $2.50 and Bud Lite for $3.00.

54. Example 1: Interacting Processes
Assume the Sells(bar, beer, price) relation, and suppose that Joe’s Bar sells only Bud for $2.50 and Bud Lite for $3.00.
Sally is querying Sells for the highest and lowest price Joe charges.
Joe decides to stop selling Bud and Bud Lite, but to sell only Michelob at $3.50.

55. Example 1: Interacting Processes
Sally is querying Sells(bar, beer, price) for the highest and lowest prices Joe charges, by executing the SQL statements:
(max) SELECT MAX(price) FROM Sells
WHERE bar = ’Joe’’s Bar’;
(min) SELECT MIN(price) FROM Sells
Joe decides to stop selling Bud and But Lite, but to sell only Michelob at $3.50, by executing the SQL statements:
(del) DELETE FROM Sells
WHERE price = ’Joe’’s Bar’;
(ins) INSERT INTO Sells
VALUES(’Joe’’s Bar’, ’Michelob’, 3.50);

56. Example 1: Interacting Processes
Although (max) must come before (min), and (del) must come before (ins), there are no other constraints on the order of these statements.

57. Example 1: Interacting Processes
Although (max) must come before (min), and (del) must come before (ins), there are no other constraints on the order of these statements.
Suppose the steps execute in the order (max), (del), (ins), (min).

58. Example 1: Interacting Processes
Although (max) must come before (min), and (del) must come before (ins), there are no other constraints on the order of these statements.
Suppose the steps execute in the order (max), (del), (ins), (min).
Joe’s Prices
2.50, 3.00
3.50
Statement
Sally (max)
Joe (del)
Joe (ins)
Sally (min)
Result
3.00

59. Example 1: Interacting Processes
Although (max) must come before (min), and (del) must come before (ins), there are no other constraints on the order of these statements.
Suppose the steps execute in the order (max), (del), (ins), (min).
Joe’s Prices
2.50, 3.00
3.50
Statement
Sally (max)
Joe (del)
Joe (ins)
Sally (min)
Result
3.00
Sally sees MAX < MIN!

60. Example 2: System Failure

61. Example 2: System Failure
Joe decides to increase the prices by 20% for all beers in his bar, by executing the SQL statements:
UPDATE Sells SET price = price * 1.2
WHERE store = ’Joe’’s Bar’;

62. Example 2: System Failure
Joe decides to increase the prices by 20% for all beers in his bar, by executing the SQL statements:
UPDATE Sells SET price = price * 1.2
WHERE store = ’Joe’’s Bar’;
If the system fails at middle of the execution of this statement, then some of the prices got increased, while some did not.

63. ACID Transactions
These problems can be fixed by using transactions, which are logic “basic” unit of operations.

64. ACID Transactions
These problems can be fixed by using transactions, which are logic “basic” unit of operations.
An ACID transaction is:

65. ACID Transactions
These problems can be fixed by using transactions, which are logic “basic” unit of operations.
An ACID transaction is:
Atomic: Either the whole process is done or none is.

66. ACID Transactions
These problems can be fixed by using transactions, which are logic “basic” unit of operations.
An ACID transaction is:
Atomic: Either the whole process is done or none is.
Consistent: Database constraints are preserved.

67. ACID Transactions
These problems can be fixed by using transactions, which are logic “basic” unit of operations.
An ACID transaction is:
Atomic: Either the whole process is done or none is.
Consistent: Database constraints are preserved.
Isolated: It appears to the user as if only one process executes at a time.

68. ACID Transactions
These problems can be fixed by using transactions, which are logic “basic” unit of operations.
An ACID transaction is:
Atomic: Either the whole process is done or none is.
Consistent: Database constraints are preserved.
Isolated: It appears to the user as if only one process executes at a time.
Durable: Effects of a process do not get lost if the system crashes.

69. ACID Transactions
In Example 1, with Sally (max)(min), and Joe (del)(ins), if we group Sally’s statements (max)(min) into an ACID transaction, then by the isolation rule, Sally cannot see the inconsistency shown in the example (she sees Joe’s prices at some fixed time -- either before or after Joe makes the changes).

70. ACID Transactions
In Example 1, with Sally (max)(min), and Joe (del)(ins), if we group Sally’s statements (max)(min) into an ACID transaction, then by the isolation rule, Sally cannot see the inconsistency shown in the example (she sees Joe’s prices at some fixed time -- either before or after Joe makes the changes).
In Example 2, where Joe changes prices, if we make Joe’s statement an ACID transaction, then even with system failure, we will not have the troubles as shown: with the atomicity rule, either all prices are changed or none.

71. Transactions in SQL
SQL supports transactions

72. Transactions in SQL SQL supports transactions
* Each statement issued at the generic query interface is a transaction by itself.

73. Transactions in SQL SQL supports transactions
* Each statement issued at the generic query interface is a transaction by itself.
* In embedded SQL and PSM, a transaction begins and ends with the procedure/function execution.

74. Transactions in SQL SQL supports transactions
* Each statement issued at the generic query interface is a transaction by itself.
* In embedded SQL and PSM, a transaction begins and ends with the procedure/function execution.
SQL can also mark the beginning of a transaction by START TRANSACTION.

75. Transactions in SQL SQL supports transactions
* Each statement issued at the generic query interface is a transaction by itself.
* In embedded SQL and PSM, a transaction begins and ends with the procedure/function execution.
SQL can also mark the beginning of a transaction by START TRANSACTION.
SQL uses COMMIT to cause a transaction to complete, with its database modifications becoming permanent in database,

76. Transactions in SQL SQL supports transactions
* Each statement issued at the generic query interface is a transaction by itself.
* In embedded SQL and PSM, a transaction begins and ends with the procedure/function execution.
SQL can also mark the beginning of a transaction by START TRANSACTION.
SQL uses COMMIT to cause a transaction to complete, with its database modifications becoming permanent in database, or uses ROLLBACK to end (abort) a transaction with no effects on the database.

77. Isolation Levels
SQL defines four isolation levels (choices about what interactions are allowed by transactions that execute at the same time).

78. Isolation Levels
SQL defines four isolation levels (choices about what interactions are allowed by transactions that execute at the same time).
How a DBMS implements these isolation levels is highly complex, and a typical DBMS provides its own options.

79. Isolation Levels
SQL defines four isolation levels (choices about what interactions are allowed by transactions that execute at the same time).
How a DBMS implements these isolation levels is highly complex, and a typical DBMS provides its own options.
Within a transaction, we can say:
SET TRANSACTION ISOLATION LEVEL X
where X = SERIALIZABLE or
REPEATABLE READ or
READ COMMITTED or
READ UNCOMMITTED

80. Serializable Transactions

81. Serializable Transactions
If Sally (max)(min) and Joe (del)(ins) are each transactions, and Sally runs with isolation level SERIALIZABLE, then she will see the database either before or after Joe runs, but not in the middle.

82. Serializable Transactions
If Sally (max)(min) and Joe (del)(ins) are each transactions, and Sally runs with isolation level SERIALIZABLE, then she will see the database either before or after Joe runs, but not in the middle.
Isolation Level Is Personal Choice: e.g., running serializable, affects only how you see the database, not how others see it.

83. Serializable Transactions
If Sally (max)(min) and Joe (del)(ins) are each transactions, and Sally runs with isolation level SERIALIZABLE, then she will see the database either before or after Joe runs, but not in the middle.
Isolation Level Is Personal Choice: e.g., running serializable, affects only how you see the database, not how others see it.
Example: If Joe runs serializable, but Sally does not, then Sally might see no prices for Joe’s Bar (e.g., she ran in the middle of Joe’s transaction).

84. Read-Commited Transactions

85. Read-Commited Transactions
If Sally runs with isolation level READ COMMITTED, then she can see only committed data, but not necessarily the same data each time.

86. Read-Commited Transactions
If Sally runs with isolation level READ COMMITTED, then she can see only committed data, but not necessarily the same data each time.
Example: Under READ COMMITTED, the interleaving (max)(del)(ins)(min) is allowed, as long as Joe commits.

87. Read-Commited Transactions
If Sally runs with isolation level READ COMMITTED, then she can see only committed data, but not necessarily the same data each time.
Example: Under READ COMMITTED, the interleaving (max)(del)(ins)(min) is allowed, as long as Joe commits.
* so Sally could see MAX < MIN.

88. Repeatable-Read Transactions

89. Repeatable-Read Transactions
Repeatable-Read is like read-committed, plus if data is read again, then everything seen the first time will be seen the second time.

90. Repeatable-Read Transactions
Repeatable-Read is like read-committed, plus if data is read again, then everything seen the first time will be seen the second time.
But the second and subsequent reads may see more tuples as well.

91. Repeatable-Read Transactions
Repeatable-Read is like read-committed, plus if data is read again, then everything seen the first time will be seen the second time.
But the second and subsequent reads may see more tuples as well.
Suppose Sally runs under REPEATABLE READ, the execution order is (max)(del)(ins)(min).

92. Repeatable-Read Transactions
Repeatable-Read is like read-committed, plus if data is read again, then everything seen the first time will be seen the second time.
But the second and subsequent reads may see more tuples as well.
Suppose Sally runs under REPEATABLE READ, the execution order is (max)(del)(ins)(min).
(max) sees prices 2.50 and 3.00.

93. Repeatable-Read Transactions
Repeatable-Read is like read-committed, plus if data is read again, then everything seen the first time will be seen the second time.
But the second and subsequent reads may see more tuples as well.
Suppose Sally runs under REPEATABLE READ, the execution order is (max)(del)(ins)(min).
(max) sees prices 2.50 and 3.00.
(min) can see 3.50, but must also see 2.50 and 3.00, because they were seen on the earlier read by (max).

94. Read Uncommitted
A transaction running under READ UNCOMMITTED can see data in the database, even if it was written by a transaction that has not committed (and may never).
Example: If Sally runs under READ UNCOMMITTED, she could see a price even if Joe later aborts.

95. Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch.3)
Basic operations on relations
Relational Algebra (Chs. 2,5)
Storage management
(Chs. 13,14)
SQL languages in DDL/DML
(Ch. 6)
How does SQL get executed
(Chs. 9,15,16)
More on SQL
(Chs. 7,8)
Transaction processing
(Chs. 6,18,19)

96. Outline of Course Representing things by tables E-R model (Ch. 4)
Good table structures
Functional Dependencies (Ch.3)
Basic operations on relations
Relational Algebra (Chs. 2,5)
Storage management
(Chs. 13,14)
SQL languages in DDL/DML
(Ch. 6)
How does SQL get executed
(Chs. 9,15,16)
More on SQL
(Chs. 7,8)
Transaction processing
(Chs. 6,18,19)