CMPT 354 Database Systems I Chapter 8 Database Application Programming
Introduction Executing SQL queries: Interactive SQL interface uncommon. Application written in a host language with SQL abstraction layer typical use of databases. SQL does not provide power to write arbitrary applications, even with vendor specific extensions (e.g. TransactSQL) which are Turing complete. But can t write a full DBMS in host language for each application. Application needs to execute SQL queries to access data. Client-Server model, the DBMS is server, app. is client.
Client-Server Handshaking Connection Request Client Program Connection Granted Insert command (SQL) Retrieve command (SQL) Result returned Disconnect DBMS
Impedance Mismatch Relational model is very different from a programming language model. What are the differences? The problem of integrating computer languages from different models is called an impedance mismatch. Two solutions: Embedded SQL Call level API The call level API can be vendor specific host language API, but normally a DBMS independent API is used. The call level API used depends on the application requirements for compatibility and easy programming.
Embedded SQL SQL statements are inserted directly in host language code, with preprocessor directives. Preprocessor converts SQL to SQL API calls. Converted code is compiled as a regular program in the host language. Uses SQL standard so DMBS independent. But bad coding style. Host Language + Embedded SQL Host Language + SQL API Calls Preprocessor Compiler Object Code SQL API Library
Embedded SQL Syntax All commands are embedded with EXEC SQL. To connect to a database: EXEC SQL CONNECT To declare shared variables: EXEC SQL BEGIN DECLARE SECTION int sid; char * student_name; EXEC SQL BEGIN DECLARE SECTION Statements without a return table: EXEC SQL INSERT INTO Students VALUES (:sid, :student_name); Queries returning tables need to be executed with cursors: EXEC SQL DECLARE <name> CURSOR FOR <query>;
Call level API Function calls passing SQL queries to database, may or may not quote SQL syntax. Different levels of API abstraction. Why? Embedded SQL typically produces code linked to a single DBMS. SQL API typically independent of DBMS (ODBC, JDBC). Accomplished through Middleware. A library that translates SQL calls appropriately to the desired DBMS. Some API is host language independent as well, but platform specific (OLEDB, ADO.NET).
Database Architecture A database application usually comprises of three layers: Presentation Application (business) logic Database Database architecture is the arrangement of these layers in terms of hardware and network. Database Middleware shields the details of database architecture from the database developer.
Architecture Example Presentation Layer Login Choose service Display class roster Input attendance Display grading scheme Input grade Deliver grade Application Logic Layer Authenticate Create grading scheme Get class roster Analyze grades Database Layer Record attendance Store grading scheme Store grade Database
2-tiered Architectures Network separation is possible, not required.
2-tiered Architecture Benefits Benefits: works well in departmental-scale applications (< 100 users) Straight forward design and implementation. most tools automatically generate 2-tiered applications (4 th Generation Languages 4GL). Disadvantages: Database connection for each active client. Security does not extend well outside the trusted LAN network protocol could be insecure. Reuse of application logic is difficult as it is tightly bound to specific DB systems and table formats.
2.5-tiered Architecture Client Presentation Presentation Network Stored procedures Application Logic Data and Resources Application Logic Data Database
Stored Procedures Stored procedures are predefined routines stored within the DBMS itself. Can be executed inside SQL queries as well as by direct procedure calls. Can pass parameters in to, and retrieve results out of the procedures. Written in a specialized database language extending SQL syntax. Can be vendor specific language or SQL/PSM (Persistent, Stored Modules PSM-96) standard. Are precompiled by the DBMS and optimized for execution.
Pros and Cons Benefits: Can compute results that SQL queries cannot. Faster execution. Reuse of application logic. Improved security. Reduced network traffic. Disadvantages: Must connect to the database with a specific interface. Limited security and transaction properties. Languages specific to the DBMS. One active client per database connection.
Stored Procedure Example To create a stored procedure that will return the names of all students from some input city CREATE PROCEDURE sp_getstudentnames @city VARCHAR(50) = % Vancouver% AS SELECT Name FROM Students WHERE Address LIKE @city ORDER BY Name The procedure can be called from a program, SQL statement or interactively: EXEC sp_getstudentnames % Burnaby% or EXECUTE sp_getstudentnames @city= % Burnaby%
3-tiered Architecture Network separations are possible, not required.
Benefits of 3-Tiered Abstract interface Application data access component connects to any database. Defined protocol for running application logic from clients. Reuse of application logic Different presentation layer clients can execute the same application logic. Scalability A multiplexing solution to clients-servers mapping. Manageability Rich clients are harder to manage than thin clients. Security Both DBMS and application server security contexts apply.
Multiplexing Client Client Client Client Client Middle Tier DBMS DBMS DBMS
Application Server Different clients can connect to the same application instance, reusing database connections. Client applications have user interface and send data to the application server. Application server defines interface and can be part of a web-server. Client DBMS Application Server Client DBMS
Downsides of 3-tiered Upfront costs in software, hardware, technical expertise in order to achieve the scalability and flexibility of 3-tiered architecture. Infrastructure development cost is higher. Additional development costs: Building different client components. Designing interface protocol. Interface and application logic potentially on different platforms. Network traffic cost: More separation between client and DBMS.
Database Middleware Database connection Data sources are abstracted various data sources can be accessed in a common way. Data conversion Data sent from client to server converted into SQL. Data returned from server to client through variables. Process exceptions from server Process result set in client Cursors allow processing result tables as if they reside in the client. Handles client data modification
Database Middleware Example Call Level Interface is SQL Working Group effort for a standard API for each programming language (but mostly defined for C). ODBC (Open DataBase Connectivity) Call Level Interface implementation (initially Microsoft 92) supporting any database through a driver. JDBC (Java DataBase Connectivity) A Java language API for accessing any databases. OLEDB Microsoft COM based data access API, extending data connection to any data source (not necessarily a DBMS). ADO.NET (ActiveX Data Objects) Further COM abstraction of database access commands.
Cursors Retrieving table data from a DBMS is traditionally done using cursors. A cursor may be defined on any query result set. A cursor points to the current tuple of the result set. Need to open a cursor, continuously fetch data, and close the cursor. Can modify or delete the current tuple. Two different types of cursors: Server-side : the query result set is stored on the server and fetched by the client one record at a time. Client-side : the query results are copied to the client.
Cursor Types Cursors can have many types of access: Dynamic cursor: can move to any tuple location, and modify data, as well as see modified data. Static cursor: a static copy of the data. Can move to any tuple location, cannot see modifications by other users. Keyset cursor: can move to any tuple location, and modify data and see modified data, however cannot see new tuples inserted by other users or deleted. Forward only: can move forward through a table only, has improved efficiency. Can also request a locking level: Read only: the cursor data can only be read. Record Update: update each record. Can have every record locked immediately upon record modification, or can be optimistic and lock only at an update command. Why is it optimistic?
ADO.NET Architecture Server Client
ADO.NET Objects Component objects: Connection: connects to the database. Command: process SQL commands. DataReader: Provides a high-performance stream of data from the Database. DataAdapter: Data access between a the Database source and the DataSet. Loading the DataSet is executed using SQL commands in the Command object. DataSet: A data object that runs in the client machine, provides a local cache of the database. Why is it necessary? ADO.NET connection could be established through other middleware, normally OLEDB, but also ODBC, or simply dedicated API for SQL Server or Oracle database.
DataSet DataSet is an object that caches the result of an SQL query for processing on the client side. A DataSet is a client-side, memory-resident database within the.net framework It can be disconnected from the database in the server, freeing up database connections. The data set can be manipulated by the client. Data in XML format under the.net framework may be read into a DataSet or written. XML data can be returned by an application/web server.
DataReader DataSet in the.net framework does not have to originate from a DBMS. ADO.NET provides DBMS operations on DataSet object on the local machine Integrity constraints on tables. Cursors, sort, filter and search. Create, update and delete. DataReader reads data from the database in forward-only, read-only fashion. DB connection must be kept alive for DataReader. Not established merely to fill DataSet object. DataSet is less efficient than DataReader. Why?
ADO.NET example #using <system.data.dll> using namespace System::Data; using namespace System::Data::SqlClient; SqlConnection * SQLCon = new SqlConnection("Server=\\cypress; Database= zinovi ; Integrated Security=true"); SQLCon->Open(); SqlCommand * SQLCmd = new SqlCommand( "SELECT * FROM Students",SQLCon); SqlDataReader * SQLReader = SQLCmd->ExecuteReader(); while (SQLReader->Read()) { SqlInt32 SIN = SQLReader->GetSQLint(0); Sqlstring name = SQLReader->GetSQLstring(1); } SQLCon->Close();
SqlClient Data Types Structure SqlBinary SqlBoolean SqlByte SqlDateTime SqlDecimal SqlDouble SqlGuid SqlInt16 SqlInt32 SqlInt64 SqlMoney SqlFloat SqlString Description Represents a variable-length stream of binary data to be stored in or retrieved from a database. Represents an integer value that is either 1 or 0 to be stored in or retrieved from a database. Represents an 8-bit unsigned integer, in the range of 0 through 255, to be stored in or retrieved from a database. Represents the date and time data ranging in value from January 1, 1753 to December 31, 9999 to an accuracy of 3.33 milliseconds to be stored in or retrieved from a database. Represents a fixed precision and scale numeric value between -10 38-1 and 10 38-1 to be stored in or retrieved from a database. Represents a floating-point number within the range of -1.79E +308 through 1.79E +308 to be stored in or retrieved from a database. Represents a globally unique identifier to be stored in or retrieved from a database. Represents a 16-bit signed integer to be stored in or retrieved from a database. Represents a 32-bit signed integer to be stored in or retrieved from a database. Represents a 64-bit signed integer to be stored in or retrieved from a database. Represents a currency value ranging from -2 63 (or -922,337,203,685,477.5808) to 2 63-1 (or +922,337,203,685,477.5807) with an accuracy to a ten-thousandth of currency unit to be stored in or retrieved from a database. Represents a floating point number within the range of -3.40E +38 through 3.40E +38 to be stored in or retrieved from a database. Represents a variable-length stream of characters to be stored in or retrieved from the database.
Transactions A database transaction groups specified database operations into one logical unit. Transactions maintain the following properties: Atomicity: Either all transaction operations executed completely or none. Consistency: The transaction operations must result in a consistent database state. Independence: Transaction results must seem to be independent from other concurrent transactions. Durability: Recovering from system crashes must keep the database in a consistent state.
A DBMS supports concurrent transactions. Why? Efficient use of computer resources. User wants interactive system. Time critical applications. The DBMS interleaves actions of various transactions in order to achieve concurrency. Consider the two transactions T1 and T2 T1: Acct1 = Acct1-$1000, Acct2 = Acct+$1000 T2: Acct1 = Acct1*1.04, Acct2 = Acct2*1.04 T1 transfers $1000 from Acc1 to Acc2, while T2 credits interest on daily closing balance to both accounts. When T1 and T2 are submitted together, can t guarantee which transaction executes first. However, must appear that these two transactions run serially in some order. Concurrent Transactions
Transaction Schedule Examples What if T1 and T2 are scheduled as follows: T1: 1.Acct1=Acct1-$1000, 3.Acct2=Acct+$1000 T2: 2.Acct1=Acct1*1.04, 4.Acct2=Acct2*1.04 Database is consistent! What if T1 and T2 are scheduled as follows: T1: 1.Acct1=Acct1-$1000, 4.Acct2=Acct+$1000 T2: 2.Acct1=Acct1*1.04,3.Acct2=Acct2*1.04 Bank kept some of our interest! What if the database crushed after operation 1 in T1?
Transaction Schedule Serial schedule is a schedule that does not interleave different transactions. Equivalent schedules are schedules which execution of result in the database objects states affected in an identical way. Serializable schedule is a a schedule equivalent to some serial execution of transactions. DBMS must find a serializable schedule. This avoids concurrency problems. DBMS must also ensure durability of Transactions.
Transactions in SQL In SQL by default every statement is a separate transaction. Includes all constraints and triggers. Can define as set of database operations that must be serialized as a transaction explicitly by declaring a SQL transaction. Start a transaction using the keywords START TRANSACTION (or BEGIN TRANSACTION in MS- SQL Server). After defining some operations to perform in the transaction, the changes of the operations can be stored in the database or erased all together using either COMMIT or ROLLBACK. An operation failing integrity rules makes the transaction rollback.
Isolation Levels Concurrency in transactions is handled using Locks and schedules. An isolation level is the set of rules for determining when access to data is allowed. Serializable isolation level assures transaction correctness in all cases, but has to delay other dependent transactions. Read only transactions cannot create an inconsistent database and could be allowed, and are faster. Read Uncommitted Isolation level allows reading of uncommitted data (dirty reads). Should it be allowed? Other isolation levels are Read Committed and Repeatable Reads. Default level is serializable.
Database Security Data access must be secured, with different privileges given depending on need and trust. The DBMS has an Access Control component which is responsible for security. Users can be associated with groups and assume the group security and access level. Users and groups have authorization IDs, and associated authentication codes (i.e. password): SQL Server built-in security information. Host system security information of the database operator. A user or group are can be granted privileges for any particular task: Select, Insert, Update, Delete, References, Trigger, Grant, Revoke, and so on.
Database Privileges Database/Schema owner automatically gains all access privileges to the database. Database/Schema owner only allowed to modify schema. Privileges can be granted by a user with Grant privilege permissions, as well as revoked. Different groups typically have different permissions, user assumes permissions of associated group. Each database operation must be executed within some security context - user id, application id, etc.
Granting Privileges In order to grant privileges to users/groups GRANT <privilege list> ON <database object> TO <user list> [WITH GRANT OPTION] Privilege list is a set of operations allowed, or could be ALL PRIVILAGES. DB object is normally a table, but can be domain or any other object. User list can be either set of users or group authorization IDs. Grant options allows the users to grant privileges.
Revoking Privileges Privileges can also be revoked from users/groups REVOKE <privilege list> ON <database object> FROM <user list> (CASCADE RESTRICT) Only revokes specified privileges. Cascade specifies that privileges inherited from only the revoked privilege are to be revoked as well Cascading revoke. Restrict specifies that revoking a privilege is allowed only if the privilege was not given to another user (avoiding cascading revoke).
Privileges for groups on views is very useful for security. To create a view for CMPT-354 students to see their grades: CREATE VIEW Cmpt354Students(SID, Grade) AS SELECT S.SID, CourseID, Grade FROM Student S NATURAL JOIN Registered R WHERE CourseID = CMPT-354 Now can grant just Select privilege to CMPT-354 students, or all privileges. GRANT SELECT ON Cmpt354Students TO Cmpt354 or View Privileges
Suppose a student created the table: CREATE TABLE FindNames (SID INT CHECK (SID IS IN (SELECT SID FROM Students WHERE Name LIKE Mike% ))); Can a student find the grade of another student? Given a name for another student, we can check all the SIDs for the course and associated grades, and attempt to insert them one by one. Hence, SQL requires that a CHECK constraint reference only tables on which the user has a SELECT privilege. Constraints Privileges