Copyright © Ellis Cohen 2002-2008 Consistency & Initialization Theory, Practice & Methodology of Relational Database Design and Programming Copyright © Ellis Cohen 2002-2008 Consistency & Initialization These slides are licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License. For more information on how you may use them, please see http://www.openlineconsult.com/db

Overview of Lecture Consistency Constraints Derivation Constraints Initialization Constraints Initial Default Constraints © Ellis Cohen 2001-2008

Consistency Constraints © Ellis Cohen 2001-2008

Conceptual State Constraint Initial Model works for Employee Dept empno ename city zip state deptno dname Conceptual State Constraint No employee lives in CA Entity Constraint Emps empno ename deptno city zip state Depts deptno dname © Ellis Cohen 2001-2008

Initial Relational Model CREATE TABLE Emps( empno int primary key, ename varchar(30) not null, deptno int references Depts, city varchar(15), zip char(5), state char(2) check (state <> 'CA') ) No CA employees We notice that zip  state and we decide to normalize the model to eliminate the redundancy © Ellis Cohen 2001-2008

Performance of Denormalized Tables If we don't normalize, but leave state in Emps, we need to enforce zip  state, and ensure that any two employees with the same zip have the same state 1 = ALL (SELECT count(DISTINCT state) FROM Emps GROUP BY zip) Enforcing this continuously (when we insert a new employee, or change their zip) can be expensive. It requires finding another employee with the same zip. That can involve scanning through the employees, although performance can be improved if Emps is indexed by zip. © Ellis Cohen 2001-2008

Normalized Conceptual Model works for ZipState lives in Employee Dept deptno dname zip state empno ename city Conceptual State Constraint No employee lives in CA Now a relationship constraint instead of an entity constraint Emps ZipStates empno ename deptno city zip Depts zip state deptno dname © Ellis Cohen 2001-2008

Normalized Relational Model CREATE TABLE Emps( empno int primary key, ename varchar(30) not null, deptno int references Depts, city varchar(15), zip char(5) references ZipStates ) CREATE TABLE ZipStates( zip char(5) primary key, state char(2) ) State Assertion: EACH (Emps NATURAL JOIN ZipStates) SATISFIES state <> 'CA' -- more expensive to enforce Can no longer just check state <> 'CA' Why not just check state <> 'CA' in ZipStates? © Ellis Cohen 2001-2008

Constraint Pre-Enforcement Checking that every employee is in CA requires explicit checking code, which can be done through pre-enforcement AddEmp( :empno, …, :zip ) BEGIN FOR rec IN (SELECT zip FROM ZipStates WHERE zip = :zip AND state = 'CA' ) LOOP RAISE_APPLICATION_ERROR( -20094, 'Cannot hire employees located in CA' ); END LOOP; INSERT INTO Emps VALUES( :empno, …, :zip ); EXCEPTION WHEN OTHERS THEN doerr(); END; © Ellis Cohen 2001-2008

Performance of Normalized Tables If we normalize, we no longer need to enforce zip  state. However, every time we need to query an employee's state insert an employee or change their zip, and check that they're not located in CA we need to look up their state in the ZipStates table, based on the employee's zip Because ZipStates is indexed by zip, this isn't that expensive But, if we do it frequently, it can affect performance © Ellis Cohen 2001-2008

Conceptual Model w Redundancy and Consistency Checking ZipState Employee lives in works for Dept deptno dname zip state empno ename state Redundant Conceptual State Constraints No employee lives in CA If an employee lives in a zipcode, then the employee's state must be the same as the zipcode's state An entity constraint, once again Consistency Constraint © Ellis Cohen 2001-2008

Conceptual & Relational Model with Redundancy ZipState Employee lives in works for Dept deptno dname zip state empno ename state Emps ZipStates empno ename deptno city zip state Depts zip state deptno dname © Ellis Cohen 2001-2008

Redundancy Enforcement Emps ZipStates empno ename deptno city zip state Depts zip state deptno dname This redundancy needs to be constrained by ensuring that every pair of zip/state in Emps is also in ZipStates This is called an inclusion dependency (SELECT DISTINCT zip, state FROM Emps)  (SELECT zip, state FROM ZipStates) © Ellis Cohen 2001-2008

Enforcement Using Unique FK's Emps empno ename deptno city zip state Depts deptno dname ZipStates zip state The inclusion dependency can be enforced by a foreign key based on zip + state. This requires declaring zip + state in ZipStates as unique. That may seem unnecessary, since zip is a PK. However, it forces the DB to maintain an index on zip + state, so the foreign key reference can check that every pair of zip + state's in Emps is also in ZipStates © Ellis Cohen 2001-2008

SQL for Unique FK's CREATE TABLE ZipStates( zip char(5) primary key, state char(2), unique( zip, state ) ) CREATE TABLE Emps( empno int primary key, ename varchar(30) not null, deptno int references Depts, city varchar(15), zip char(5), state char(2) check (state <> 'CA'), foreign key( zip, state) references ZipStates( zip, state ) ) Retain & check state © Ellis Cohen 2001-2008

Comparing Performance Denormalized Normalized Redundant Lookup employee's state Trivial Indexed lookup Continuously check state != 'CA' Enforce zip  state Expensive (though could be interval-based) Automatic based on index © Ellis Cohen 2001-2008

Derivation Constraints © Ellis Cohen 2001-2008

Managing Redundancies Redundancy that remains in a system can be managed either by Doing nothing: Assumes inconsistencies are rare, or do not cause significant damage Consistency Checking: Check continuously or at intervals Automatic Derivation: Automatically set derived values (usually continuously, but possibly interval-based) © Ellis Cohen 2001-2008

Conceptual Model w Derivation Constraint ZipState Employee works for Dept deptno dname zip state empno ename city /state /state indicates state is derived Conceptual State Constraint No employee lives in CA Conceptual Transition Constraint When setting an employee's zip, set the state as well, consistent w ZipState Derivation Constraint © Ellis Cohen 2001-2008

Derivation Constraint Enforcement (White Box Enforcement) AddEmployee( :empno, …, :zip ) BEGIN INSERT INTO Emps VALUES( :empno, …, :zip, (SELECT state FROM ZipStates WHERE zip = :zip) ); EXCEPTION WHEN OTHERS THEN doerr(); END; A good example where white box enforcement makes more sense © Ellis Cohen 2001-2008

Derivation Constraint Enforcement (Black Box Enforcement) AddEmployee( :empno, …, :zip ) BEGIN INSERT INTO Emps VALUES( :empno, …, :zip, NULL ) UPDATE Emps e SET state = (SELECT state FROM ZipStates WHERE zip = e.zip) WHERE empno = :empno; EXCEPTION WHEN OTHERS THEN doerr(); END; Black Box Enforcement sets the state initially to NULL (that's the base code) It then separately enforces the derivation constraint by filling in the state based on the zip © Ellis Cohen 2001-2008

Relational Derivation Constraint Derivation constraints can be specified formally using Full Transition Assertions AddEmployee( :empno, …, :zip ) RESULTS IN EACH Emps&& e WHERE e.empno' = :empno SATISFIES e.zip@ = :zip AND e.state@ = (SELECT state FROM ZipStates&& WHERE zip@ = :empno) The assertion can also be written so it is generalized © Ellis Cohen 2001-2008

Generalized Derivation Constraint ANY ACTION RESULTS IN EACH Emps&& e WHERE e.zip" != e.zip' OR (e.zip" IS NULL AND e.zip' IS NOT NULL) SATISFIES e.zip@ = e.zip' AND e.state@ = (SELECT state FROM ZipStates&& WHERE zip@ = e.zip') Any operation whose base code changes an employee's zip must also change the employee's state to be consistent with it © Ellis Cohen 2001-2008

Tuple Derivation Constraints Tuple Derivation Constraint derives value of an attribute based upon values of other attributes in the same tuple Order orderno subtotal shipCost /total / indicates total is derived Conceptual Transition Constraint Derive an Order's total as subtotal + shipCost Tuple Derivation Constraint © Ellis Cohen 2001-2008

Relational Tuple Derivation Constraints CREATE TABLE Orders( orderid int primary key, subtotal number(8,2) not null, shipCost number(5,2) not null, total number(9,2) AS subtotal + shipCost ) Supported directly in SQL Server only In Oracle, it would have to be enforced using the approach described previously © Ellis Cohen 2001-2008

Tuple Derivation Assertion EACH Orders&& r SATISFIES r IS UNCHANGED AT subtotal, shipcost AND r.total@ = r.subtotal@ + r.shipcost@ In a full transition assertion, r IS UNCHANGED still compares r.a' and r.a@ so it only refers to the fact that enforcement doesn't change these attributes © Ellis Cohen 2001-2008

Consistency vs Derivation Consistency Constraint State constraint which indicates that the value of some attribute of a tuple is equal to a computation involving attributes of related tuples Derivation Constraint Transition constraint which indicates how to derive based on © Ellis Cohen 2001-2008

Initialization Constraints © Ellis Cohen 2001-2008

Referenced Attribute Problem part of sale of Invoice Entry Product invid customer date linenum quantity productid productnam price description Entries typically have a price attribute. Rather than putting price under entry (where it needs to be repeated for every single entry), why not just include it as part of price (where it can be looked up with a join)? © Ellis Cohen 2001-2008

Current vs Historic State part of sale of Invoice Entry Product invid customer date linenum quantity price productid productnam curprice description Maintain historic state Product's price represents today's price! Entry's price represents the price when the entry was added to the invoice. It MUST be honored, even if the price changes before shipping, and provides historic information! We can't use a derivation constraint; changing curprice can't change price. Conceptual Transition Constraint A new entry's price is set to the current price of the product the entry is associated with Initialization Constraint © Ellis Cohen 2001-2008

Relational Model with Initialization Constraint CREATE TABLE Products( productid int primary key, productnam varchar(30) not null, curprice number(8,2), description varchar(255) ) CREATE TABLE Entries( invid int references Invoices, linenum int, productid int references Products, quantity int, price number(8,2), primary key( invid, linenum ) ) Enforce the initialization constraint by automatically filling in the price of a newly inserted Entries tuple based on its productid by looking up the corresponding curprice in the Products table © Ellis Cohen 2001-2008

Initialization Constraint Enforcement (White Box Enforcement) AddEntry( :invid, :prodid, :qty ) Gets 1 more than highest linenum for the invoice; 1 if the first entry DECLARE nxtlin int; BEGIN SELECT 1 + nvl(max(linenum),0) INTO nxtlin FROM Entries WHERE invid = :invid; INSERT INTO Entries VALUES( :invid, nxtlin, :prodid, :qty, (SELECT curprice FROM Products WHERE productid = :prodid) ); EXCEPTION WHEN OTHERS THEN doerr(); END; What's the uglier black box enforcement code? © Ellis Cohen 2001-2008

Initialization Constraint Enforcement (Black Box Enforcement) AddEntry( :invid, :prodid, :qty ) DECLARE nxtlin int; BEGIN SELECT 1 + nvl(max(linenum),0) INTO nxtlin FROM Entries WHERE invid = :invid; INSERT INTO Entries VALUES( :invid, nxtlin, :prodid, :qty, NULL ); UPDATE Entries SET price = (SELECT curprice FROM Products WHERE productid = :prodid) WHERE invid = :invid AND linenum = nxtlin; EXCEPTION WHEN OTHERS THEN doerr(); END; © Ellis Cohen 2001-2008

Relational Initialization Constraint ANY ACTION RESULTS IN EACH Entries&& e WHERE e.invid" IS NULL AND e.invid' IS NOT NULL SATISFIES e.price@ = (SELECT curprice@ FROM Products&& p WHERE e.productid@ = p.productid@) © Ellis Cohen 2001-2008

Derivation vs. Initialization Derivation Constraint Defines value of an attribute based on other attribute values (in the same or other tables). Whenever the constituent values are changed, the derived value is automatically changed. So this also induces an invariant state constraint between the attribute value and the constituent values from which it is derived. Initialization Constraint Defines required initial value of the attribute based on constants and/or other attribute values (in the same or other tables) immediately after a transaction in which the tuple is inserted. Subsequent changes to the constituent values will NOT affect the initialized attribute value. Does NOT induce a state constraint. © Ellis Cohen 2001-2008

Retaining State Changes part of sale of Invoice Entry Product invid customer date linenum quantity /price {const} productid productnam curprice description For each product, maintain its previous product prices. Now the price of an entry can be derived an invoice has a date, and each previous product price indicates the last date it was valid, so it is possible to determine the price of a product on the date of the invoice, and therefore the price for an entry. But the derivation is complicated, and {const} indicates its value will not change once initialized. So, treat as an initialization constraint instead of a derivation constraint Previous Product Price lastValidDate price © Ellis Cohen 2001-2008

Initial Default Constraints © Ellis Cohen 2001-2008

Limits of Initialization Constraints The initialization constraint requires that the entry price must always initially be set to the product's current price. What if a salesman can give a customer a special price different from the current product price? Use an Initial Default transition constraint! Conceptual Transition Constraint A new entry's price is set to the current price of the product the entry is associated with, if a price for the entry was not specified Initial Default Constraint © Ellis Cohen 2001-2008

Relational Model with Initial Default Constraint CREATE TABLE Products( productid int primary key, productnam varchar(30) not null, curprice number(8,2), description varchar(255) ) CREATE TABLE Entries( invid int references Invoices, linenum int, productid int references Products, quantity int, price number(8,2), primary key( invid, linenum ) ) Enforce the initial default constraint by automatically filling in the price of a newly inserted Entries tuple based on its productid by looking up the corresponding curprice in the Products table, but only if no price has been explicitly provided © Ellis Cohen 2001-2008

Initial Default Enforcement (White Box Enforcement) AddEntry( :invid, :prodid, :qty, :price ) DECLARE nxtlin int; BEGIN SELECT 1 + nvl(max(linenum),0) INTO nxtlin FROM Entries WHERE invid = :invid; INSERT INTO Entries VALUES( :invid, nxtlin, :prodid, :qty, nvl( :price, (SELECT curprice FROM Products WHERE productid = :prodid) ) ); EXCEPTION WHEN OTHERS THEN doerr(); END; What's the black box enforcement code? © Ellis Cohen 2001-2008

Initial Default Enforcement (Black Box Enforcement) AddEntry( :invid, :prodid, :qty, :price ) DECLARE nxtlin int; BEGIN SELECT 1 + nvl(max(linenum),0) INTO nxtlin FROM Entries WHERE invid = :invid; INSERT INTO Entries VALUES( :invid, nxtlin, :prodid, :qty, :price ); UPDATE Entries SET price = (SELECT curprice FROM Products WHERE productid = :prodid) WHERE invid = :invid AND linenum = nxtlin AND price IS NULL; EXCEPTION WHEN OTHERS THEN doerr(); END; © Ellis Cohen 2001-2008

Relational Initial Default Constraint ANY ACTION RESULTS IN EACH Entries&& e WHERE e.invid" IS NULL AND e.invid' IS NOT NULL AND e.price' IS NULL SATISFIES e.price@ = (SELECT curprice@ FROM Products&& p WHERE e.productid@ = p.productid@) © Ellis Cohen 2001-2008

Initialization w and w/o Defaults Initialization Constraint Defines required initial value of the attribute based on constants and/or other attribute values (in the same or other tables) immediately after an action in which the tuple is inserted. Initial Default Constraint Defines initial value of the attribute based on constants and/or other attribute values (in the same or other tables) unless a different value was explicitly provided. © Ellis Cohen 2001-2008

Constant Initial Defaults Employee empno ename sal Conceptual Transition Constraint A new employee's sal is set to 1000 if a sal was not specified Initial Default Constraint © Ellis Cohen 2001-2008

Relational Model with Constant Initial Default Constraint Constant Initial Default Constraints are supported directly by the relational model CREATE TABLE Emps( empno int primary key, ename varchar(30) not null, sal number(8,2) DEFAULT 1000 ) © Ellis Cohen 2001-2008