1 / 28

Lecture 8: SQL Programming and Transactions

Lecture 8: SQL Programming and Transactions. Friday, January 24, 2003. Impedance Mismatch. Example: SQL in C: C uses int, char[..], pointers, etc SQL uses tables Impedance mismatch = incompatible types. The Impedance Mismatch Problem. Why not use only one language?

thomasscott
Download Presentation

Lecture 8: SQL Programming and Transactions

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Lecture 8: SQLProgramming and Transactions Friday, January 24, 2003

  2. Impedance Mismatch • Example: SQL in C: • C uses int, char[..], pointers, etc • SQL uses tables • Impedance mismatch = incompatible types

  3. The Impedance Mismatch Problem Why not use only one language? • Forgetting SQL: “we can quickly dispense with this idea” [textbook, pg. 351]. • SQL cannot do everything that the host language can do. Solution: use cursors

  4. Interface: SQL / Host Language Values get passed through shared variables. Colons precede shared variables when they occur within the SQL statements. EXEC SQL: precedes every SQL statement in the host language. The variable SQLSTATE provides error messages and status reports (e.g., “00000” says that the operation completed with no problem). EXEC SQL BEGIN DECLARE SECTION; char productName[30]; EXEC SQL END DECLARE SECTION;

  5. Example Product (pname, price, quantity, maker) Purchase (buyer, seller, store, pname) Company (cname, city) Person(name, phone, city)

  6. Using Shared Variables Void simpleInsert() { EXEC SQL BEGIN DECLARE SECTION; char n[20], c[30]; /* product-name, company-name */ int p, q; /* price, quantity */ char SQLSTATE[6]; EXEC SQL END DECLARE SECTION; /* get values for name, price and company somehow */ EXEC SQL INSERT INTO Product(pname, price, quantity, maker) VALUES (:n, :p, :q, :c); }

  7. Cursors • Declare the cursor • Open the cursor • Fetch tuples one by one • Close the cursor

  8. Cursors void product2XML() { EXEC SQL BEGIN DECLARE SECTION; char n[20], c[30]; int p, q; char SQLSTATE[6]; EXEC SQL END DECLARE SECTION; EXEC SQL DECLARE crs CURSOR FOR SELECT pname, price, quantity, maker FROM Product; EXEC SQL OPEN crs;

  9. Cursors printf(“<allProducts>\n”); while (1) { EXEC SQL FETCH FROM crs INTO :n, :p, :q, :c; if (NO_MORE_TUPLES) break; printf(“ <product>\n”); printf(“ <name> %s </name>\n”, n); printf(“ <price> %d </price>\n”, p); printf(“ <quantity> %d </quantity>\n”, q); printf(“ <maker> %s </maker>\n”, c); printf(“ </product>\n”); } EXECT SQL CLOSE crs; printf(“</allProducts>\n”); }

  10. What is NO_MORE_TUPLES ? #define NO_MORE_TUPLES !(strcmp(SQLSTATE,”02000”))

  11. More on Cursors • cursors can modify a relation as well as read it. • We can determine the order in which the cursor will get • tuples by the ORDER BY keyword in the SQL query. • Cursors can be protected against changes to the • underlying relations. • The cursor can be a scrolling one: can go forward, backward • +n, -n, Abs(n), Abs(-n).

  12. In JDBC public void doIt(){ try { Class.forName("com.ms.jdbc.odbc.JdbcOdbcDriver"); java.sql.Connection c = DriverManager.getConnection("jdbc:odbc:cse444","cse444","cse444"); java.sql.Statement s= c.createStatement(); java.sql.ResultSet rs; rs = s.executeQuery("Select * from beers"); java.sql.ResultSetMetaData md = rs.getMetaData(); while (rs.next()){ area.append("\nTUPLE: |"); for (int i = 1; i <= md.getColumnCount();i++){ area.append(rs.getString(i) + " | "); } } rs.close(); } catch (Exception e){ e.printStackTrace(); System.out.println("something went wrong in database land"); } }

  13. Transactions Address two issues: • Access by multiple users • Remember the “client-server” architecture: one server with many clients • Protection against crashes

  14. Flight Reservation get values for :flight, :date, :seat EXEC SQL SELECT occupied INTO :occ FROM Flight WHERE fltNum = :flight AND fltdt= :date AND fltSeat=:seat if (!occ) { EXEC SQL UPDATE Flights SET occupied = ‘true’ WHERE fltNum= :flight AND fltdt= :date AND fltSeat=:seat /* more code missing */ } else /* notify customer that seat is not available */

  15. Problem #1 Customer 1 - finds a seat empty Customer 2 - finds the same seat empty Customer 1 - reserves the seat. Customer 2 - reserves the seat. Customer 1 will not be happy. serializability

  16. Bank Transfers Transfer :amount from :account1 to :account2 EXEC SQL SELECT balance INTO :balance1 FROM Accounts WHERE accNo = :account1 if (balance1 >= amount) EXEC SQL UPDATE Accounts SET balance = balance + :amount WHERE acctNo = :account2; EXEC SQL UPDATE Accounts SET balance = balance - :amount WHERE acctNo = :account1; Crash...

  17. Transactions • The user/programmer can group a sequence of commands so that • they are executed atomically and in a serializable fashion: • Transaction commit: all the operations should be done and recorded. • Transaction abort: none of the operations should be done. • In SQL: • EXEC SQL COMMIT; • EXEC SQL ROLLBACK; • Easier said than done...

  18. ACID Properties Atomicity:all actions of a transaction happen, or none happen. Consistency: if a transaction is consistent, and the database starts from a consistent state, then it will end in a consistent state. Isolation: the execution of one transaction is isolated from other transactions. Durability: if a transaction commits, its effects persist in the database.

  19. How Do We Assure ACID? Concurrency control: Guarantees consistency and isolation, given atomicity. Logging and Recovery: Guarantees atomicity and durability. If you are going to be in the logging business, one of the things that you’ll have to do is learn about heavy equipment. -- Robert VanNatta Logging History of Columbia County

  20. Transactions in SQL • In “ad-hoc” SQL: • Default: each statement = one transaction • In “embedded” SQL: BEGIN TRANSACTION [SQL statements] COMMIT or ROLLBACK (=ABORT)

  21. Transactions: Serializability Serializability = the technical term for isolation • An execution is serial if it is completely before or completely after any other transaction’s execution • An execution is serializable if it equivalent to one that is serial • DBMS can offer serializability guarantees

  22. Serializability • Enforced with locks, like in Operating Systems ! • But this is not enough: User 1 User 2 LOCK A [write A=1] UNLOCK A . . .. . .. . .. . . LOCK B [write B=2] UNLOCK B LOCK A [write A=3] UNLOCK A LOCK B [write B=4] UNLOCK B time What is wrong ?

  23. Serializability • Solution: two-phase locking • Lock everything at the beginning • Unlock everything at the end • Read locks: many simultaneous read locks allowed • Write locks: only one write lock allowed • Insert locks: one per table

  24. Isolation Levels in SQL • “Dirty reads” SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED • “Committed reads” SET TRANSACTION ISOLATION LEVEL READ COMMITTED • “Repeatable reads” SET TRANSACTION ISOLATION LEVEL REPEATABLE READ • Serializable transactions (default): SET TRANSACTION ISOLATION LEVEL SERIALIZABLE Reading assignment: chapter 8.6

  25. Database Design Entity Relationship Diagrams

  26. Building an Application with a DBMS • Requirements modeling (conceptual, pictures) • Decide what entities should be part of the application and how they should be linked. • Schema design and implementation • Decide on a set of tables, attributes. • Define the tables in the database system. • Populate database (insert tuples). • Write application programs using the DBMS • way easier now that the data management is taken care of.

  27. Database Design • Why do we need it? • Agree on structure of the database before deciding on a particular implementation. • Consider issues such as: • What entities to model • How entities are related • What constraints exist in the domain • How to achieve good designs

  28. Database Design Formalisms 1. Object Definition Language (ODL): • Closer in spirit to object-oriented models 2. Entity/Relationship model (E/R): • More relational in nature. • Both can be translated (semi-automatically) to relational schemas • ODL to OO-schema: direct transformation (C++ or Smalltalk based system).

More Related