CPSC-608 Database Systems Fall 2018 Instructor: Jianer Chen Office: HRBB 315C Phone: 845-4259 Email: chen@cse.tamu.edu Notes 9

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.

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.

Triggers: Motivation

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

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

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

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

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.

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.

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.

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);

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);

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

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

Trigger: CREATE TRIGGER CREATE TRIGGER <name>

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

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.

Trigger: The Event

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

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.

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

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.

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

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

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

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

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.

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)

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

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

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.

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.

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>

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)

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

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.

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.

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.

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

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

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.

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.

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 + 1.00) INSERT INTO RipoffBars VALUES (nnn.bar);

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 + 1.00) INSERT INTO RipoffBars VALUES (nnn.bar);

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 + 1.00) INSERT INTO RipoffBars VALUES (nnn.bar); UPDATE lets us to talk about new and old tuples (rows).

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 + 1.00) 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

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 + 1.00) 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

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 + 1.00) 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.

Views

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

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

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:

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;

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

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.

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.

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.

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;

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

Inserting on a View

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

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;

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;

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;

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;

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;

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;

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;

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; ……

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; ……

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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