1. CPSC-608 Database Systems
Fall 2018
Instructor: Jianer Chen
Office: HRBB 315C
Phone:
Notes 9

2. Constraints and Triggers
A constraint is a relationship among data elements that the DBMS is required to enforce.
-- e.g., key constraints.
A trigger is an action only executed when a specified condition occurs, e.g., insertion of a tuple.
-- easier to implement than complex constraints.

3. Constraints and Triggers
A constraint is a relationship among data elements that the DBMS is required to enforce.
-- e.g., key constraints.
A trigger is an action only executed when a specified condition occurs, e.g., insertion of a tuple.
-- easier to implement than complex constraints.

4. Triggers: Motivation

5. Triggers: Motivation
Assertions are powerful, but the DBMS often can’t tell when they need to be checked.

6. 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.

7. 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 a powerful condition.

8. Event-Condition-Action Rules
Another name for trigger is ECA rule, or event-condition-action rule.

9. Event-Condition-Action Rules
Another name for trigger is ECA rule, or event-condition-action rule.
Event: typically a type of database modification, e.g., “insert on Sells.”

10. Event-Condition-Action Rules
Another name for trigger is ECA rule, or event-condition-action rule.
Event: typically a type of database modification, e.g., “insert on Sells.”
Condition: Any SQL boolean-valued expression.

11. Event-Condition-Action Rules
Another name for trigger is ECA rule, or event-condition-action rule.
Event: typically a type of database modification, e.g., “insert on Sells.”
Condition: Any SQL boolean-valued expression.
Action: Any SQL statements.

12. Beers(name, manf)
Sells(bar, beer, price)
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.

13. Beers(name, manf)
Sells(bar, beer, price)
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.
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);

14. Beers(name, manf)
Sells(bar, beer, price)
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.
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);

15. Beers(name, manf)
Sells(bar, beer, price)
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.
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);
the condition

16. Beers(name, manf)
Sells(bar, beer, price)
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.
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);
the condition
the action

17. Trigger: CREATE TRIGGER
CREATE TRIGGER <name>

18. Trigger: CREATE TRIGGER
CREATE TRIGGER <name>
Option:
CREATE OR REPLACE TRIGGER <name>

19. Trigger: CREATE TRIGGER
CREATE TRIGGER <name>
Option:
CREATE OR REPLACE TRIGGER <name>
-- Useful if there is a trigger with that name and you want to modify the trigger.

20. Trigger: The Event

21. Trigger: 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);
Trigger: The Event

22. Trigger: The Event AFTER can be BEFORE. 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);
Trigger: The Event
AFTER can be BEFORE.

23. Trigger: The Event AFTER can be BEFORE.
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);
Trigger: The Event
AFTER can be BEFORE.
-- also, can be INSTEAD OF if the relation is a view (to be discussed later).

24. Trigger: The Event AFTER can be BEFORE.
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);
Trigger: The Event
AFTER can be BEFORE.
-- also, can be INSTEAD OF if the relation is a view (to be discussed later).
INSERT can be DELETE or UPDATE.

25. Trigger: The Event AFTER can be BEFORE.
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);
Trigger: The Event
AFTER can be BEFORE.
-- also, can be INSTEAD OF if the relation is a view (to be discussed later).
INSERT can be DELETE or UPDATE.
-- UPDATE ON <relation> can be UPDATE OF <attribute> ON <relation> for a particular <attribute> of the <relation>.

26. Trigger: Row-Level and Statement-Level
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);
Trigger: Row-Level and Statement-Level

27. Trigger: Row-Level and Statement-Level
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);
Trigger: Row-Level and Statement-Level
Triggers are either “row-level” or “statement- level.”

28. Trigger: Row-Level and Statement-Level
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);
Trigger: Row-Level and Statement-Level
Triggers are either “row-level” or “statement- level.”
FOR EACH ROW indicates row-level; its absence indicates statement-level (can also be FOR EACH STATEMENT).

29. Trigger: Row-Level and Statement-Level
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);
Trigger: Row-Level and Statement-Level
Triggers are either “row-level” or “statement- level.”
FOR EACH ROW indicates row-level; its absence indicates statement-level (can also be FOR EACH STATEMENT).
Row-level triggers: execute once for each modified tuple.

30. Trigger: Row-Level and Statement-Level
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);
Trigger: Row-Level and Statement-Level
Triggers are either “row-level” or “statement- level.”
FOR EACH ROW indicates row-level; its absence indicates statement-level (can also be FOR EACH STATEMENT).
Row-level triggers: execute once for each modified tuple.
Statement-level triggers: execute once for an SQL statement (many tuples can be modified)

31. Trigger: 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);
Trigger: REFERENCING

32. 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);
Trigger: REFERENCING
INSERT implies a new row (tuple) (for row- level) or a new table (for statement-level).

33. 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);
Trigger: REFERENCING
INSERT implies a new row (tuple) (for row- level) or a new table (for statement-level).
DELETE implies an old tuple or table.

34. 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);
Trigger: REFERENCING
INSERT implies a new row (tuple) (for row- level) or a new table (for statement-level).
DELETE implies an old tuple or table.
UPDATE implies both.

35. 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);
Trigger: REFERENCING
INSERT implies a new row (tuple) (for row- level) or a new table (for statement-level).
DELETE implies an old tuple or table.
UPDATE implies both.
Refer to these by
REFERENCING [NEW OLD] [ROW TABLE] AS <name>

36. 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);
Trigger: REFERENCING
INSERT implies a new row (tuple) (for row- level) or a new table (for statement-level).
DELETE implies an old tuple or table.
UPDATE implies both.
Refer to these by
REFERENCING [NEW OLD] [ROW TABLE] AS <name>
For statement-level trigger, the <name> above is used as a relation (table)

37. Trigger: 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);
Trigger: The Condition

38. Trigger: 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);
Trigger: The Condition
Any boolean-valued condition is appropriate.

39. Trigger: 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);
Trigger: The Condition
Any boolean-valued condition is appropriate.
It is evaluated before or after the triggering event, depending on whether BEFORE or AFTER is used in the event.

40. Trigger: 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);
Trigger: The Condition
Any boolean-valued condition is appropriate.
It is evaluated before or after the triggering event, depending on whether BEFORE or AFTER is used in the event.
Access the new/old tuple or set of tuples (i.e., the table) through the names declared in the REFERENCING clause.

41. Trigger: 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);
Trigger: The Action

42. 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);
Trigger: The Action
There can be more than one SQL statement in the action (surround by BEGIN END if there are more than one statements).

43. 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);
Trigger: The Action
There can be more than one SQL statement in the action (surround by BEGIN END if there are more than one statements).
But queries make no sense in an action, so we are really limited to modifications.

44. Another Example
Using Sells(bar, beer, price) and a unary relation RipoffBars(bar) created for the purpose, maintain a list of bars that raise the price of any beer by more than $1.

45. Another Example
Using Sells(bar, beer, price) and a unary relation RipoffBars(bar) created for the purpose, maintain a list of bars that raise the price of any beer by more than $1.
CREATE TRIGGER PriceTrig
AFTER UPDATE OF price ON Sells
REFERENCING
OLD ROW AS ooo
NEW ROW AS nnn
FOR EACH ROW
WHEN (nnn.price > ooo.price )
INSERT INTO RipoffBars
VALUES (nnn.bar);

46. Another Example
Using Sells(bar, beer, price) and a unary relation RipoffBars(bar) created for the purpose, maintain a list of bars that raise the price of any beer by more than $1.
event: only when price is changed
CREATE TRIGGER PriceTrig
AFTER UPDATE OF price ON Sells
REFERENCING
OLD ROW AS ooo
NEW ROW AS nnn
FOR EACH ROW
WHEN (nnn.price > ooo.price )
INSERT INTO RipoffBars
VALUES (nnn.bar);

47. Another Example
Using Sells(bar, beer, price) and a unary relation RipoffBars(bar) created for the purpose, maintain a list of bars that raise the price of any beer by more than $1.
event: only when price is changed
CREATE TRIGGER PriceTrig
AFTER UPDATE OF price ON Sells
REFERENCING
OLD ROW AS ooo
NEW ROW AS nnn
FOR EACH ROW
WHEN (nnn.price > ooo.price )
INSERT INTO RipoffBars
VALUES (nnn.bar);
UPDATE lets us to talk about new and old tuples (rows).

48. Another Example
Using Sells(bar, beer, price) and a unary relation RipoffBars(bar) created for the purpose, maintain a list of bars that raise the price of any beer by more than $1.
event: only when price is changed
CREATE TRIGGER PriceTrig
AFTER UPDATE OF price ON Sells
REFERENCING
OLD ROW AS ooo
NEW ROW AS nnn
FOR EACH ROW
WHEN (nnn.price > ooo.price )
INSERT INTO RipoffBars
VALUES (nnn.bar);
UPDATE lets us to talk about new and old tuples (rows).
row-level trigger:
process whenever price for a tuple in Sells is updated

49. Another Example
Using Sells(bar, beer, price) and a unary relation RipoffBars(bar) created for the purpose, maintain a list of bars that raise the price of any beer by more than $1.
event: only when price is changed
CREATE TRIGGER PriceTrig
AFTER UPDATE OF price ON Sells
REFERENCING
OLD ROW AS ooo
NEW ROW AS nnn
FOR EACH ROW
WHEN (nnn.price > ooo.price )
INSERT INTO RipoffBars
VALUES (nnn.bar);
UPDATE lets us to talk about new and old tuples (rows).
row-level trigger:
process whenever price for a tuple in Sells is updated
condition: price is raised by > $1

50. Another Example
Using Sells(bar, beer, price) and a unary relation RipoffBars(bar) created for the purpose, maintain a list of bars that raise the price of any beer by more than $1.
event: only when price is changed
CREATE TRIGGER PriceTrig
AFTER UPDATE OF price ON Sells
REFERENCING
OLD ROW AS ooo
NEW ROW AS nnn
FOR EACH ROW
WHEN (nnn.price > ooo.price )
INSERT INTO RipoffBars
VALUES (nnn.bar);
UPDATE lets us to talk about new and old tuples (rows).
row-level trigger:
process whenever price for a tuple in Sells is updated
condition: price is raised by > $1
action: record the bar in RipoffBars.

51. Views

52. Views
A view is a “virtual table” = a relation defined in terms of other tables and views.

53. Views
A view is a “virtual table” = a relation defined in terms of other tables and views.
Declare by:
CREATE VIEW <name> AS <subquery>;

54. Views
A view is a “virtual table” = a relation defined in terms of other tables and views.
Declare by:
CREATE VIEW <name> AS <subquery>;
Example:
CanDrink(drinker, beer) is a view made from relations Sells(bar, beer, price) and Frequents(drinker, bar) that “contains” the drinker-beer pairs such that the drinker frequents at least one bar that serves the beer:

55. Views
A view is a “virtual table” = a relation defined in terms of other tables and views.
Declare by:
CREATE VIEW <name> AS <subquery>;
Example:
CanDrink(drinker, beer) is a view made from relations Sells(bar, beer, price) and Frequents(drinker, bar) that “contains” the drinker-beer pairs such that the drinker frequents at least one bar that serves the beer:
CREATE VIEW CanDrink AS
SELECT drinker, beer
FROM Frequents, Sells
WHERE Frequents.bar = Sells.bar;

56. Triggers on Views Sells(bar, beer, price) Likes(drinker, beer)
Frequents(drinker, bar)
Triggers on Views

57. Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Triggers on Views
In general, it is impossible to modify a view, because it doesn’t exist.

58. Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Triggers on Views
In general, it is impossible to modify a view, because it doesn’t exist.
But an INSTEAD OF trigger let us interpret view modifications in a way that makes sense.

59. Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Triggers on Views
In general, it is impossible to modify a view, because it doesn’t exist.
But an INSTEAD OF trigger let us interpret view modifications in a way that makes sense.
Example: we design a view Synergy with tuples (drinker, beer, bar) such that the bar serves the beer, the drinker frequents the bar and likes the beer.

60. Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Triggers on Views
In general, it is impossible to modify a view, because it doesn’t exist.
But an INSTEAD OF trigger let us interpret view modifications in a way that makes sense.
Example: we design a view Synergy with tuples (drinker, beer, bar) such that the bar serves the beer, the drinker frequents the bar and likes the beer.
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

61. Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Triggers on Views
In general, it is impossible to modify a view, because it doesn’t exist.
But an INSTEAD OF trigger let us interpret view modifications in a way that makes sense.
Example: we design a view Synergy with tuples (drinker, beer, bar) such that the bar serves the beer, the drinker frequents the bar and likes the beer.
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;
Actually, a natural join of Likes, Sells, and Frequents

62. Inserting on a View

63. Inserting on a View
We cannot insert into Synergy: it is a view made from Sells, Likes, Frequents.

64. Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Inserting on a View
We cannot insert into Synergy: it is a view made from Sells, Likes, Frequents.
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

65. Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Inserting on a View
We cannot insert into Synergy: it is a view made from Sells, Likes, Frequents.
But we can use an INSTEAD OF trigger to turn a (drinker, beer, bar) triple into three insertions of projected pairs, one for each of Likes, Sells, and Frequents.
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

66. Inserting on a View CREATE VIEW Synergy AS
Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Inserting on a View
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

67. Inserting on a View CREATE TRIGGER ViewTrig
Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Inserting on a View
CREATE TRIGGER ViewTrig
INSTEAD OF INSERT ON Synergy
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
INSERT INTO Likes VALUES (n.drinker, n.beer);
INSERT INTO Sells(bar, beer) VALUES(n.bar, n.beer);
INSERT INTO Frequents VALUES(n.drinker, n.bar);
END;
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

68. Inserting on a View CREATE TRIGGER ViewTrig
Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
specifically
for views
Inserting on a View
CREATE TRIGGER ViewTrig
INSTEAD OF INSERT ON Synergy
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
INSERT INTO Likes VALUES (n.drinker, n.beer);
INSERT INTO Sells(bar, beer) VALUES(n.bar, n.beer);
INSERT INTO Frequents VALUES(n.drinker, n.bar);
END;
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

69. Inserting on a View CREATE TRIGGER ViewTrig
Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
specifically
for views
Inserting on a View
CREATE TRIGGER ViewTrig
INSTEAD OF INSERT ON Synergy
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
INSERT INTO Likes VALUES (n.drinker, n.beer);
INSERT INTO Sells(bar, beer) VALUES(n.bar, n.beer);
INSERT INTO Frequents VALUES(n.drinker, n.bar);
END;
The value for
Sells.price will
be the default
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

70. Inserting on a View CREATE TRIGGER ViewTrig
Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Inserting on a View
CREATE TRIGGER ViewTrig
INSTEAD OF INSERT ON Synergy
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
INSERT INTO Likes VALUES (n.drinker, n.beer);
INSERT INTO Sells(bar, beer) VALUES(n.bar, n.beer);
INSERT INTO Frequents VALUES(n.drinker, n.bar);
END;
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;

71. Inserting on a View CREATE VIEW Synergy AS
Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Inserting on a View
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;
CREATE TRIGGER ViewTrig
INSTEAD OF INSERT ON Synergy
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
INSERT INTO Likes VALUES (n.drinker, n.beer);
INSERT INTO Sells(bar, beer) VALUES(n.bar, n.beer);
INSERT INTO Frequents VALUES(n.drinker, n.bar);
END; ……

72. Inserting on a View In the same database schema CREATE VIEW Synergy AS
Sells(bar, beer, price)
Likes(drinker, beer)
Frequents(drinker, bar)
Inserting on a View
CREATE VIEW Synergy AS
SELECT Likes.drinker, Likes.beer, Sells.bar
FROM Likes, Sells, Frequents
WHERE Likes.drinker = Frequents.drinker
AND Likes.beer = Sells.beer
AND Sells.bar = Frequents.bar;
In the same
database schema
CREATE TRIGGER ViewTrig
INSTEAD OF INSERT ON Synergy
REFERENCING NEW ROW AS n
FOR EACH ROW
BEGIN
INSERT INTO Likes VALUES (n.drinker, n.beer);
INSERT INTO Sells(bar, beer) VALUES(n.bar, n.beer);
INSERT INTO Frequents VALUES(n.drinker, n.bar);
END; ……

73. Database is just another model of information processing
(in disks)
Then why study DB?
Much more data, regular data techs would be very inefficient: How should data be stored?
Operations are simpler & more specific: How do we take advantage of it?
New programming languages for the above.
(ACID) Reliability, security, consistency, currency
π, σ, ρ,
∩, ⋃, \,
╳, ⋈, ⋈C
SQL

74. Database is just another model of information processing
(in disks)
Then why study DB?
Much more data, regular data techs would be very inefficient: How should data be stored?
Operations are simpler & more specific: How do we take advantage of it?
New programming languages for the above.
(ACID) Reliability, security, consistency, currency
π, σ, ρ,
∩, ⋃, \,
╳, ⋈, ⋈C
SQL

75. Database is just another model of information processing
(in disks)
Then why study DB?
Much more data, regular data techs would be very inefficient: How should data be stored?
Operations are simpler & more specific: How do we take advantage of it?
New programming languages for the above.
(ACID) Reliability, security, consistency, currency
π, σ, ρ,
∩, ⋃, \,
╳, ⋈, ⋈C
SQL
Will be studied in graduate database

76. database system undergraduate database in tables (relations) DDL
administrator
database system
DDL
language
database
programmer
DML (query)
language
secondary
storage
(disks)
undergraduate database

77. database management system
in tables
(relations)
database
administrator
database management system
DDL
language
database
programmer
DML (query)
language
simply translate
database programs
into machine programs
secondary
storage
(disks)
undergraduate database

78. database management system
in tables
(relations)
database
administrator
database management system
DDL
language
database
programmer
DML (query)
language
simply translate
database programs
into machine programs
secondary
storage
(disks)
then what is the difference between DBMS
and a programming language compiler?
undergraduate database

79. DBMS 1. it has to deal with data stored in
hierarchical memory structures
in tables
(relations)
database
administrator
DDL
language
file
manager
database
programmer
buffer
manager
DML (query)
language
main
memory
buffers
secondary
storage
(disks)
DBMS
then what is the difference between DBMS
and a programming language compiler?
undergraduate database

80. DBMS 2. it has to support efficient manipulations
of data in hierarchical memory structures
in tables
(relations)
database
administrator
DDL
language
file
manager
database
programmer
index/file
manager
buffer
manager
DML (query)
language
main
memory
buffers
secondary
storage
(disks)
DBMS
then what is the difference between DBMS
and a programming language compiler?
undergraduate database

81. DBMS 3. it needs to translate the input database
program into an internal representation
in tables
(relations)
database
administrator
DDL
complier
DDL
language
file
manager
database
programmer
index/file
manager
buffer
manager
DML (query)
language
DML
complier
main
memory
buffers
secondary
storage
(disks)
DBMS
then what is the difference between DBMS
and a programming language compiler?
undergraduate database

82. DBMS 4. it needs to produce efficient internal codes
dealing with data in hierarchical memory structure
in tables
(relations)
database
administrator
DDL
complier
DDL
language
file
manager
database
programmer
index/file
manager
buffer
manager
DML (query)
language
query
execution
engine
DML
complier
main
memory
buffers
secondary
storage
(disks)
DBMS
then what is the difference between DBMS
and a programming language compiler?
undergraduate database

83. DBMS 5. it needs to be consistent undergraduate database
in tables
(relations)
5. it needs to be consistent
database
administrator
DDL
complier
lock table
DDL
language
file
manager
concurrency
control
transaction
manager
database
programmer
index/file
manager
buffer
manager
DML (query)
language
query
execution
engine
DML
complier
main
memory
buffers
secondary
storage
(disks)
DBMS
then what is the difference between DBMS
and a programming language compiler?
undergraduate database

84. DBMS 6. it needs to be reliable undergraduate database
in tables
(relations)
6. it needs to be reliable
database
administrator
DDL
complier
lock table
DDL
language
file
manager
logging &
recovery
concurrency
control
transaction
manager
database
programmer
index/file
manager
buffer
manager
DML (query)
language
query
execution
engine
DML
complier
main
memory
buffers
secondary
storage
(disks)
DBMS
then what is the difference between DBMS
and a programming language compiler?
undergraduate database

85. DBMS undergraduate database in tables (relations) lock table DDL
administrator
DDL
complier
lock table
DDL
language
file
manager
logging &
recovery
concurrency
control
transaction
manager
database
programmer
index/file
manager
buffer
manager
DML (query)
language
query
execution
engine
DML
complier
main
memory
buffers
secondary
storage
(disks)
DBMS
undergraduate database

86. DBMS graduate database in tables (relations) lock table DDL language
administrator
DDL
complier
lock table
DDL
language
file
manager
logging &
recovery
concurrency
control
transaction
manager
database
programmer
index/file
manager
buffer
manager
DML (query)
language
query
execution
engine
DML
complier
main
memory
buffers
secondary
storage
(disks)
DBMS
graduate database

87. Remark. Project #1 has been handed out.
The project is due October 10, 2018.