Database Systems I
SQL Constraints and Triggers
Ensuring business rules are met.
222
INTEGRITY CONSTRAINTS An integrity constraint (IC) describes
conditions that every legal instance of a relation must satisfy. Inserts/deletes/updates that violate IC’s are
disallowed. Can be used to ensure application semantics
(e.g., sid is a key), or prevent inconsistencies (e.g., sname has to be a string, age must be < 200).
Types of IC’s: domain constraints and NOT NULL constraints, primary key constraints and foreign key
constraints, general constraints.
333
NOT-NULL CONSTRAINTS The IC NOT NULL disallows NULL values for a
specified attribute.CREATE TABLE Students
(sid CHAR(20) PRIMARY KEY, name CHAR(20) NOT NULL, login CHAR(10) NOT NULL, age INTEGER, gpa REAL);
Primary key attributes are implicitly NOT NULL.
444
GENERAL CONSTRAINTS Attribute-based CHECK
defined in the declaration of an attribute, activated on insertion to the corresponding table
or update of attribute.
Tuple-based CHECK defined in the declaration of a table, activated on insertion to the corresponding table
or update of tuple.
Assertion defined independently from any table, activated on any modification of any table
mentioned in the assertion.
555
ATTRIBUTE-BASED CHECK Attribute-based CHECK constraint is part of an
attribute definition. Is checked whenever a tuple gets a new value
for that attribute (INSERT or UPDATE) Violating modifications are rejected CHECK constraint can contain an SQL query
referencing other attributes (of the same or other tables), if their relations are mentioned in the FROM clause
CHECK constraint is not activated if other attributes mentioned get new values
666
ATTRIBUTE-BASED CHECK Ex: not null constraint
Ex: sex char(1) CHECK (sex IN (‘F’, ‘M’))
domain constraint Ex: Create domain gender-domain CHAR (1)
CHECK (VALUE IN (‘F’, ‘M’)) define sex in schema definition to be of type
gender-domain
777
ATTRIBUTE-BASED CHECK Attribute-based CHECK constraints are most
often used to restrict allowable attribute values.
CREATE TABLE Sailors( sid INTEGER PRIMARY KEY,sname CHAR(10),rating INTEGER
CHECK ( rating >= 1 AND rating <= 10),
age REAL);
888
TUPLE-BASED CHECK Tuple-based CHECK constraints can be used
to constrain multiple attribute values within a table.
Condition can be anything that can appear in a WHERE clause.
Same activation and enforcement rules as for attribute-based CHECK.
CREATE TABLE Sailors( sid INTEGER PRIMARY KEY,sname CHAR(10),previousRating INTEGER,currentRating INTEGER,age REAL,
CHECK (currentRating >= previousRating) );
999
TUPLE-BASED CHECK Tuple Based CHECK contraint:
CREATE TABLE Emp (name CHAR(30) UNIQUEgender CHAR(1) CHECK (gender in (‘F’, ‘M’)age intdno intCHECK (age < 100 AND age > 20)CHECK (dno IN (SELECT dno FROM dept)))
these are checked on insertion to relation or tuple update
101010
TUPLE-BASED CHECK CHECK constraint that refers to other table:
CREATE TABLE Reserves( sname CHAR(10),bid INTEGER,day DATE,PRIMARY KEY (bid,day),CHECK (‘Interlake’ <>
( SELECT B.bnameFROM Boats BWHERE B.bid=bid)));
But: these constraints are invisible to other tables, i.e. are not checked upon modification of other tables.
Interlake boats cannot be reserved
111111
TUPLE-BASED CHECKCREATE TABLE dept (mgrname CHAR(30)dno intdname CHAR(20)check (mgrname NOT IN (SELECT name
FROM emp WHERE emp.sal < 50000))
)
If someone made a manager whose salary is less than 50K that insertion/update to dept table will be rejected.
However, if manager’s salary reduced to less than 50K, the corresponding update to emp table will NOT be rejected.
121212
ASSERTIONS Number of boats plus number of sailors is <
100.
CREATE TABLE Sailors( sid INTEGER,sname CHAR(10),rating INTEGER,age REAL,PRIMARY KEY (sid),CHECK ( (SELECT COUNT (S.sid) FROM Sailors S)+ (SELECT COUNT (B.bid) FROM Boats B) < 100 )
);
Tuple-based CHECK awkward and wrong! If Sailors is empty, the number of Boats tuples can be
anything! ASSERTION is the right solution; not associated with
either table.
131313
ASSERTIONS
Assertions are constraints over a table as a whole or multiple tables.
General form: CREATE ASSERTION <name> CHECK <cond>
An assertion must always be true at transaction boundaries. Any modification that causes it to become false is rejected.
Similar to tables, assertions can be dropped by a DROP command.
141414
ASSERTIONS Condition can be anything allowed in a
WHERE clause. Constraint is tested whenever any (!) of the
referenced tables is modified. Different from CHECK constraints, ICs
expressed as assertion are always enforced (unless they are deferred until the end of the transaction).
CHECK constraints are more efficient to implement than ASSERTIONs.
151515
ASSERTIONS Number of boats plus number of sailors is < 100.
CREATE ASSERTION smallClubCHECK ( (SELECT COUNT (S.sid) FROM Sailors S)+ (SELECT COUNT (B.bid) FROM Boats B) < 100 );
All relations are checked to comply with above.
Number of reservations per sailor is < 10.CREATE ASSERTION notTooManyReservationsCHECK ( 10 > ALL
(SELECT COUNT (*) FROM Reserves GROUP BY sid)
);
161616
EXAMPLE ASSERTION
CREATE ASSERTION RichMGR CHECK(NOT EXISTS
(SELECT *FROM dept, empWHERE emp.name = dept.mgrname AND
emp.salary < 50000))
This assertion correctly guarantees that each manager makes more than 50000.
If someone made a manager whose salary is less than 50K that insertion/update to dept table will be rejected.
Furthermore, if manager’s salary reduced to less than 50K, the corresponding update to emp table will be rejected.
171717
Type Where Declared When activated Guaranteed to hold?
Attribute with attribute on insertion not if containsCHECK or update subquery
Tuple relation schema insertion or not if containsCHECK update to subquery relation
Assertion database schema on change to Yes any relation mentioned
DIFFERENT CONSTRAINT TYPES
181818
ALTERING CONSTRAINTSALTER TABLE Product DROP CONSTRAINT positivePrice
ALTER TABLE Product ADD CONSTRAINT positivePrice CHECK (price >= 0)
ALTER DOMAIN ssn ADD CONSTRAINT no-leading-1s CHECK (value >= 200000000)
DROP ASSERTION assert1.
TRIGGERS
202020
TRIGGERS Trigger: procedure that starts automatically if
specified changes occur to the DB.
Three parts of a trigger: Event (activates the trigger)
insert, delete or update of the database Condition (tests whether the trigger should run)
a Boolean statement or a query (nonempty answer set = true, empty answer set = false)
Action (what happens if the trigger runs)wide variety of options
The action can refer to both the old and new state of the database.
212121
TRIGGERS Synchronization of the Trigger with the activating
statement (DB modification) Before After Instead of Deferred (at end of transaction).
Update events may specify a particular column or set of columns.
A condition is specified with a WHEN clause.
Number of Activations of the Trigger Once per modified tuple
(FOR EACH ROW) Once per activating statement
(default).
222222
TRIGGERS Options for the REFERENCING clause:
NEW TABLE: the set (!) of tuples newly inserted (INSERT).
OLD TABLE: the set (!) of deleted or old versions of tuples (DELETE / UPDATE).
OLD ROW: the old version of the tuple (FOR EACH ROW UPDATE).
NEW ROW: the new version of the tuple (FOR EACH ROW UPDATE).
The action of a trigger can consist of multiple SQL statements, surrounded by BEGIN . . . END.
232323
TRIGGERS
CREATE TRIGGER youngSailorUpdate AFTER INSERT ON SAILORS /* Event */ REFERENCING NEW TABLE NewSailors FOR EACH STATEMENT
INSERT /* Action */INTO YoungSailors(sid, name, age, rating)SELECT sid, name, age, ratingFROM NewSailors NWHERE N.age <= 18;
This trigger inserts young sailors into a separate table. It has no (i.e., an empty, always true) condition.
242424
EXAMPLE: ROW LEVEL TRIGGERCREATE TRIGGER NoLowerPrices
AFTER UPDATE OF price ON Product
REFERENCING OLD AS OldTuple NEW AS NewTuple
WHEN (OldTuple.price > NewTuple.price) UPDATE Product SET price = OldTuple.price WHERE name = NewTuple.name
FOR EACH ROW
252525
TRIGGERSCREATE TRIGGER notTooManyReservations AFTER INSERT ON Reserves /* Event */ REFERENCING NEW ROW NewReservation FOR EACH ROW WHEN (10 <= (SELECT COUNT(*) FROM Reserves
WHERE sid =NewReservation.sid)) /* Condition */ DELETE FROM Reserves R WHERE R.sid= NewReservation.sid /* Action */
AND day=(SELECT MIN(day) FROM Reserves R2 WHERE
R2.sid=R.sid);
This trigger makes sure that a sailor has less than 10 reservations, deleting the oldest reservation of a given sailor, if neccesary.
It has a non- empty condition (WHEN).
262626
TRIGGERS VS. GENERAL CONSTRAINTS
Triggers can be harder to understand. Several triggers can be activated by one SQL
statement (arbitrary order!). A trigger may activate other triggers (chain
activation). Triggers are procedural.
Assertions react on any database modification, trigger only only specified event.
Trigger execution cannot be optimized by DBMS. Triggers have more applications than
constraints. monitor integrity constraints, construct a log, gather database statistics, etc.
272727
SUMMARY SQL allows specification of rich integrity
constraints (ICs): attribute-based, tuple-based CHECK and assertions (table-independent).
CHECK constraints are activated only by modifications of the table they are based on, ASSERTIONs are activated by any modification that can possibly violate them.
Choice of the most appropriate method for a particular IC is up to the DBA.
Triggers respond to changes in the database. Can also be used to represent ICs.
Database Systems I
SQL Stored Procedures
292929
EXAMPLE PROCEDURE
303030
STORED PROCEDURES
What is a stored procedure: Program executed through a single SQL
statement Executed in the process space of the server
Advantages: Can encapsulate application logic while staying
“close” to the data Reuse of application logic by different users Avoid tuple-at-a-time return of records through
cursors
313131
STORED PROCEDURES: EXAMPLES
CREATE PROCEDURE ShowNumReservationsSELECT S.sid, S.sname, COUNT(*)FROM Sailors S, Reserves RWHERE S.sid = R.sidGROUP BY S.sid, S.sname
Stored procedures can have parameters: Three different modes: IN, OUT, INOUT
CREATE PROCEDURE IncreaseRating(IN sailor_sid INTEGER, IN increase INTEGER)
UPDATE SailorsSET rating = rating + increaseWHERE sid = sailor_sid
323232
STORED PROCEDURES
Stored procedure do not have to be written in SQL:
CREATE PROCEDURE TopSailors(IN num INTEGER)
LANGUAGE JAVAEXTERNAL NAME “file:///c:/storedProcs/rank.jar”
333333
CALLING STORED PROCEDURES
EXEC SQL BEGIN DECLARE SECTIONInt sid;Int rating;EXEC SQL END DECLARE SECTION
// now increase the rating of this sailorEXEC CALL IncreaseRating(:sid,:rating);
Database Systems I
SQL TransactionsEnsuring database consistency one query at a time.
353535
TRANSACTIONS So far, we have implicitly assumed that
there is only one DB user who executes one SQL statement at a time.
In reality, a DBS may have many concurrent users.
Each user may issue a sequence of SQL statements that form a logical unit (transaction).
The DBS is in charge of ordering the SQL statements from different users in a way (serializable) that produces the same results as if the statements would have been executed in a single user scenario.
363636
SERIALIZABILITY Consider two users who simultaneously want
to book a seat on a certain flight: they first find an empty seat and then book it (set it occupied).
In an unconstrained system, their operations might be executed in the following order:
In the end, who gets seat 22A?
T1: find empty book seat 22A seat 22A, T2: find empty book seat 22A
seat 22A, time
373737
SERIALIZABILITY To avoid such a problem, we need to
consider the sequence of statements of a user transaction as a unit.
Statements from two different user transactions must be ordered in a way that is equivalent to both transactions being performed serially in either order
transaction 1 before transaction 2 transaction 2 before transaction 1
In our example, either user 1 or user 2 would get seat 22A. The other user would see 22A as occupied and would have to find another seat.
383838
ATOMICITY So far, we have also assumed that all SQL
statements are executed correctly. In reality, various types of system errors can
occur during the execution of a user transaction.
At the time of a system crash, transactions can be incomplete: some, but not all of their SQL statements have been executed.
393939
ATOMICITY Consider a bank transaction T:
T is transferring $100 from B’s account to A’s account.
What if the system crashes right after the first statement of T has been executed, i.e. the second statement is not executed?
The DBS has to ensure that every transaction is treated as an atomic unit, i.e. either all or none of its SQL statements are executed.
T: A=A+100, B=B-100time
404040
TRANSACTIONS A user’s program may carry out many
operations on the data retrieved from the database, but the DBMS is only concerned about what data is read/written from/to the database.
A transaction is the DBMS’s abstract view of a user program: a sequence of DB reads (R) and writes (W).
T: A=A+100, B=B-100
T: R(A), W(A), R(B), W(B)
User’s view
System’s view
time
414141
SERIALIZABILITY Serial schedule: Schedule that does not
interleave the SQL statements of different transactions.
Equivalent schedules: For any database state, the effect of executing the first schedule is identical to the effect of executing the second schedule: The resulting DB instance / state. The result of read operations, i.e. what the user
sees. Serializable schedule: A schedule that is
equivalent to some serial schedule.
424242
SERIALIZABILITY Serializability is normally ensured by locking
the DB objects read or written. Before reading or writing a DB object (table
or tuple), the transaction needs to obtain the appropriate lock: Shared locks for reading, Exclusive locks for writing, View locks to prevent new tuples from being
returned by a repeated reading. Locks are normally released only at the end
of a transaction. If a transaction cannot get the lock it has
requested, it needs to wait until it is realeased by the other transaction currently holding it.
434343
TRANSACTIONS IN SQL By default, each SQL statement (any query
or modification of the database or its schema) is treated as a separate transaction. Transaction includes the effects of triggers.
Transactions can also be defined explicitly. START TRANSACTION;
<sequence of SQL statements>COMMIT;or ROLLBACK;
COMMIT makes all modifications of the transaction permanent, ROLLBACK undoes all DB modifications made.
444444
READ-ONLY TRANSACTIONS A transaction that reads only (and does not
write the DB) is easy to serialize with other read-only transactions.
Only shared locks need to be set. This means that read-only transactions do
not need to wait for each other, and the throughput of the DBS can be maximized.
To specify the next transaction as read-only:SET TRANSACTION READ ONLY;
454545
DIRTY READS Dirty data is data that has been modified by
a transaction that has not yet committed. If that transaction is rolled back after
another transaction has read its dirty data, a non-serializable schedule results.
Consider T1 who wants to book two seats and T2 who wants to book one seat.
T2 does not get his favorite seat or maybe not even any seat on his favorite flight, although he could have if he had waited for the end of T1.
T1: R(A), W(A), R(B), W(B), RollbackT2: R(A), W(A), Commit
464646
ISOLATION LEVELS Control the degree of locking which occurs
when selecting data
SQL allows you to specify four different isolation levels for a transaction. SET TRANSACTION ISOLATION LEVEL . . . ;
The isolation level of a transaction defines what data that transaction may see
Note that other, concurrent transactions may be executed at different isolation levels
474747
ISOLATION LEVELS SERIALIZABLE
This isolation level specifies that all transactions occur in a completely isolated fashion
i.e., as if all transactions in the system had executed serially, one after the other
The DBMS may execute two or more transactions at the same time only if the illusion of serial execution can be maintained
REPEATABLE READ All data records read by a SELECT statement cannot be changed if the SELECT statement contains any ranged WHERE clauses,
phantom reads can occur
Phantom Read: 3rd query returns identical results as 1st query.
484848
ISOLATION LEVELS READ COMMITTED
Data records retrieved by a query are not prevented from modification by some other transactions
Non-repeatable reads may occur data retrieved in a SELECT statement may be modified
by some other transaction when it commits READ UNCOMMITTED
dirty reads are allowed One transaction may see uncommitted changes made
by some other transaction
Default isolation level varies quite widely
494949
ISOLATION LEVELS The semantics of the four different isolation
levels is defined as follows:
YesYesYesSerializableNoYesYesRepeatable
Reads
NoNoYesRead CommittedNoNoNoRead
Uncommitted
Viewlocks
Readlocks
Writelocks
Isolation Level
505050
TRANSACTIONS Requirements for transactions:
Atomicity: “all or nothing”, Consistency: transforms consistent DB state into
another consistent DB state, Independence: from all other transactions
(serializability), Durability: survives any system crashes.
These requirements are called ACID properties of transactions.
515151
SUMMARY A transaction consists of a sequence of
read / write operations. The DBMS guarantees the atomicity,
consistency, independence and durability of transactions.
Serializability guarantees independence of transactions.
Lower isolation levels can be specified. They may be acceptable and more efficient in certain scenarios.