12 Week Review
5 April 2006
Adina Cr ăiniceanu www.cs.usna.edu/~adina
1

 SQL
 SQL Views
 SQL Triggers
 SQL Stored Procedures
 PHP/MySQL
 Database Administrator tasks
 Manage database structure
 Concurrency control
Kroenke, Database Processing 2

 SQL view is a virtual table that is constructed from other tables or views
 It has no data of its own, but obtains data from tables or other views
 It only has a definition
 SELECT statements are used to define views
 A view definition may not include an ORDER BY clause
 Views can be used as regular tables in SELECT statements
Kroenke, Database Processing 3

 CREATE VIEW command:
CREATE VIEW CustomerNameView
AS
SELECT CustName AS
CustomerName
FROM CUSTOMER;
 To see the view use:
SELECT *
FROM CustomerNameView
ORDER BY CustomerName;
Kroenke, Database Processing 4

 Security: hide columns and rows
 Display results of computations
 Hide complicated SQL syntax
 Provide a level of isolation between actual data and the user’s view of data
 three-tier architecture
 Assign different processing permissions to different views on same table
 Assign different triggers to different views on same table
Kroenke, Database Processing 5

 Views based on a single table
 No computed columns
 All non-null columns present in view
 Views with INSTEAD OF triggers defined on them
 Views based on a single table, primary key in view, some non-null columns missing from view
 Updates for non-computed columns ok
 Deletes ok
 Inserts not ok
Kroenke, Database Processing 6

 Trigger: stored program that is executed by the DBMS whenever a specified event occurs
 Associated with a table or view
 Three trigger types: BEFORE, INSTEAD
OF , and AFTER
 Each type can be declared for INSERT,
UPDATE, and/or DELETE
 Resulting in a total of nine trigger types
Kroenke, Database Processing 7

 CREATE TRIGGER trigger_name
ON table_or_view_name
AFTER | BEFORE | INSTEAD OF
INSERT | UPDATE | DELETE
AS trigger_code
Kroenke, Database Processing 8

 A stored procedure is a program that is stored within the database and is compiled when used
 In Oracle, it can be written in PL/SQL or Java
 In SQL Server, it can be written in TRANSACT-SQL
 Stored procedures can receive input parameters and they can return results
 Stored procedures can be called from:
 Programs written in standard languages, e.g., Java, C#
 Scripting languages, e.g., JavaScript, VBScript
 SQL command prompt, e.g., SQL*Plus, Query Analyzer
Kroenke, Database Processing 9

 Greater security as store procedures are always stored on the database server
 SQL can be optimized by the DBMS compiler
 Code sharing resulting in:
 Less work
 Standardized processing
 Specialization among developers
Kroenke, Database Processing 10

 CREATE PROCEDURE proc_name
AS proc_code
 exec proc_name [@param1 = ]value1, …
Kroenke, Database Processing 11

 Managing database structure
 Controlling concurrent processing
 Managing processing rights and responsibilities
 Developing database security
 Providing for database recovery
 Managing the DBMS
 Maintaining the data repository
Kroenke, Database Processing 12

 Participate in database and application development
 Assist in requirements stage and data model creation
 Play an active role in database design and creation
 Facilitate changes to database structure
 Seek community-wide solutions
 Assess impact on all users
 Provide configuration control forum
 Be prepared for problems after changes are made
 Maintain documentation
Kroenke, Database Processing 13

 Concurrency control: ensure that one user’s work does not inappropriately influence another user’s work
 No single concurrency control technique is ideal for all circumstances
 Trade-offs need to be made between level of protection and throughput
Kroenke, Database Processing 14

 A transaction , or logical unit of work (LUW) , is a series of actions taken against the database that occurs as an atomic unit
 Either all actions in a transaction occur - COMMIT
 Or none of them do - ABORT
Kroenke, Database Processing 15

 Concurrent transactions: transactions that appear to users as they are being processed at the same time
 In reality, CPU can execute only one instruction at a time
 Transactions are interleaved
 Concurrency problems
 Lost updates
 Inconsistent reads
Kroenke, Database Processing 16

 T1: R(item) W(item) Commit
 T2: R(item) W(item) Commit
Kroenke, Database Processing 17

 Dirty reads – read uncommitted data
 T1: R(A), W(A),
 T2:
R(B), W(B), Abort
R(A), W(A), Commit
 Unrepeatable reads
 T1: R(A),
 T2:
R(A), W(A), Commit
R(A), W(A), Commit
Kroenke, Database Processing 18

 Serializable transactions:
 Run concurrently
 Results like when they run separately
 Strict two-phase locking – locking technique to achieve serializability
Kroenke, Database Processing 19

 Deadlock : two transactions are each waiting on a resource that the other transaction holds
 Preventing deadlock
 Allow users to issue all lock requests at one time
 Require all application programs to lock resources in the same order
 Breaking deadlock
 Almost every DBMS has algorithms for detecting deadlock
 When deadlock occurs, DBMS aborts one of the transactions and rollbacks partially completed work
Kroenke, Database Processing 20

 Optimistic locking assumes that no transaction conflict will occur:
 DBMS processes a transaction; checks whether conflict occurred:
 If not, the transaction is finished
 If yes, the transaction is repeated until there is no conflict
 Pessimistic locking assumes that conflict will occur:
 Locks are issued before a transaction is processed, and then the locks are released
Kroenke, Database Processing 21

 Most application programs do not explicitly declare locks due to its complication
 Mark transaction boundaries and declare locking behavior they want the DBMS to use
 Transaction boundary markers: BEGIN, COMMIT, and
ROLLBACK TRANSACTION
 Advantage
 If the locking behavior needs to be changed, only the lock declaration need be changed, not the application program
Kroenke, Database Processing 22

 Transaction properties:
 A tomic - all or nothing
 C onsistent
 I solated
 D urable – changes made by commited transactions are permanent
Kroenke, Database Processing 23

 Consistency means either statement level or transaction level consistency
 Statement level consistency : each statement independently processes rows consistently
 Transaction level consistency : all rows impacted by either of the SQL statements are protected from changes during the entire transaction
 With transaction level consistency, a transaction may not see its own changes
Kroenke, Database Processing 24


 T1: R(A), W(A),
 T2: R(A), W(A), Commit
R(B), W(B), Abort

 T1: R(A),
 T2: R(A), W(A), Commit
R(A), W(A), Commit

 Re-read data and find new rows
Kroenke, Database Processing 25

Kroenke, Database Processing 26