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

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.

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.

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);

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.

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.

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.

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.

Example: Binding and Fetching

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’

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, , );

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 */ }

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 = 02000 = “failed to find a tuple.”

Java Database Connectivity (JDBC)

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

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.

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.

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.

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.

Statements JDBC provides two classes:

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.

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.

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’ ” );

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’ ” );

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.

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

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

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.

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.

Examples

Examples For Updates:

Examples For Updates: stat1 is a Statement.

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)” );

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:

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’ ”.

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();

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.

Accessing the ResultSet

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

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.

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.

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,

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.

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

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 */ }

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)

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)

Transaction Processing

Transaction Processing Facts

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.

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.

Example 1: Interacting Processes

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.

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.

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);

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.

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).

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

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!

Example 2: System Failure

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’;

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.

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

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

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.

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.

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.

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.

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).

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.

Transactions in SQL SQL supports transactions

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

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.

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.

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,

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.

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

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.

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

Serializable Transactions

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.

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.

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).

Read-Commited Transactions

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.

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.

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.

Repeatable-Read Transactions

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.

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.

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).

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.

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).

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 3.50 even if Joe later aborts.

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)

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)