BIT360 - Database Administration with MySQL

• Lesson 7 Creating, designing and use of MySQL

stored programs

UNIT IV 1
General Introduction
• There are several different ways to protect a database from
corruption:
• Datatypes for the individual columns
• Primary key and other uniqueness constraints
• Referential integrity constraints:
• Implement relationships between tables
• Ensure that enumerated values are valid
• Implementing reference data
• Database code that implements complex (non declarative) constraints
• One major benefit to doing all of this in the database is that there
is no way to “back door” the database.
• The other benefit is that the stored procedure/function/trigger runs
on the server, which saves on network traffic.
Triggers: Motivation
• Assertions are powerful, but the DBMS often can’t tell
when they need to be checked.
• Attribute- and tuple-based CHECKs are checked at known
times, but are not powerful.
• Triggers let the user decide when to check for any
condition.
 Event-Condition-Action
Rules
• Another name for “trigger” is ECA rule, or event-condition-
action rule.

• Event : Typically a database modification, e.g., “insert on

Sells.”
• Condition : Any SQL Boolean-valued expression.
• Action : Any SQL statements.
Preliminary Example: A Trigger

• Instead of using a foreign-key constraint and rejecting

insertions into Sells(bar, beer, price) with unknown beers, a
trigger can add that beer to Beers, with a NULL
manufacturer.
Example: Trigger Definition
CREATE TRIGGER BeerTrig The event
AFTER INSERT ON Sells
REFERENCING NEW ROW AS NewTuple
FOR EACH ROW
WHEN (NewTuple.beer NOT IN The
(SELECT name FROM Beers)) condition

INSERT INTO Beers(name)

The action
VALUES(NewTuple.beer);
Options: CREATE
TRIGGER
• CREATE TRIGGER <name>
• Or:
CREATE OR REPLACE TRIGGER <name>
• Useful if there is a trigger with that name and you want to
modify the trigger.
Options: The Event
CREATE TRIGGER BeerTrig
AFTER INSERT ON Sells
REFERENCING NEW ROW AS NewTuple
FOR EACH ROW
WHEN (NewTuple.beer NOT IN
(SELECT name FROM Beers))
INSERT INTO Beers(name)
VALUES(NewTuple.beer);
Options: The
• AFTER can be BEFORE.
Event
• BEFORE indicates that the check of the condition and the
action are done before the triggering event is executed.
• AFTER indicates that the check of the condition and the
action are done after the triggering event is executed.
• Also, INSTEAD OF, if the relation is a view.
• A clever way to execute view modifications: Have triggers
translate them to appropriate modifications on the base tables.
• INSERT can be DELETE or UPDATE.
• And UPDATE can be
UPDATE OF . . . ON . . .
a particular attribute.
Options: FOR EACH ROW
CREATE TRIGGER BeerTrig
AFTER INSERT ON Sells
REFERENCING NEW ROW AS NewTuple
FOR EACH ROW
WHEN (NewTuple.beer NOT IN
(SELECT name FROM Beers))
INSERT INTO Beers(name)
VALUES(NewTuple.beer);
Options: FOR EACH ROW
• Triggers are either “row-level” or “statement-level.”
• FOR EACH ROW indicates row-level
• Its absence indicates statement-level.
• Can also explicitly use FOR EACH STATEMENT
• Row level triggers : executed once for each modified tuple.
• Statement-level triggers : executed once for an operation,
regardless of how many tuples are modified.
Options: REFERENCING
CREATE TRIGGER BeerTrig
AFTER INSERT ON Sells
REFERENCING NEW ROW AS NewTuple
FOR EACH ROW
WHEN (NewTuple.beer NOT IN
(SELECT name FROM Beers))
INSERT INTO Beers(name)
VALUES(NewTuple.beer);
 Options: REFERENCING
• The REFERENCING clause allows the condition and the
action of the trigger to refer to the tuple being modified.
• For an update, this clause lets users give names to the tuple
both before and after the change
Options: REFERENCING
• INSERT statements imply a new tuple (for row-level) or
new table (for statement-level).
• The “table” is the set of inserted tuples.
• DELETE implies an old tuple or table.
• UPDATE implies both.
• Refer to these by
[NEW OLD] [ROW TABLE] AS <name>
Options: The Condition
CREATE TRIGGER BeerTrig
AFTER INSERT ON Sells
REFERENCING NEW ROW AS NewTuple
FOR EACH ROW
WHEN (NewTuple.beer NOT IN
(SELECT name FROM Beers))
INSERT INTO Beers(name)
VALUES(NewTuple.beer);
Options: The Condition
• The condition part can be omitted.
• Then the trigger is executed whenever awakened.
• Uses the keyword WHEN, followed by any Boolean-valued
condition.
• Evaluated on the database as it would exist before or after
the triggering event, depending on whether BEFORE or
AFTER is used.
• Access the new/old tuple/table through the names in the
REFERENCING clause.
Options: The Action
CREATE TRIGGER BeerTrig
AFTER INSERT ON Sells
REFERENCING NEW ROW AS NewTuple
FOR EACH ROW
WHEN (NewTuple.beer NOT IN
(SELECT name FROM Beers))
INSERT INTO Beers(name)
VALUES(NewTuple.beer);
 Options: The Action
• There can be more than one SQL statement in the action.
• Surround by BEGIN . . . END if there is more than one.
• But queries make no sense in an action, so we are really
limited to modifications.
Another Example
• Using Sells(bar, beer, price) and a unary relation
RipoffBars(bar), maintain a list of bars that raise the price
of any beer by more than $1.
 The Trigger The event –
only changes
CREATE TRIGGER PriceTrig to prices

AFTER UPDATE OF price ON Sells

REFERENCING Updates let us
OLD ROW AS ooo talk about old
and new tuples Condition:
NEW ROW AS nnn a raise in
We need to consider
FOR EACH ROW each price change price > $1
WHEN(nnn.price > ooo.price + 1.00)
INSERT INTO RipoffBars When the price
VALUES(nnn.bar); change
is great enough, add
the bar to RipoffBars