1. Copyright © Ellis Cohen 2002-2008 Consistency & Initialization
Theory, Practice & Methodology of Relational Database Design and Programming
Copyright © Ellis Cohen
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

2. Overview of Lecture Consistency Constraints Derivation Constraints
Initialization Constraints
Initial Default Constraints
© Ellis Cohen

3. Consistency Constraints
© Ellis Cohen

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

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

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

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

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

9. 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( , 'Cannot hire employees located in CA' ); END LOOP;
INSERT INTO Emps VALUES( :empno, …, :zip );
EXCEPTION WHEN OTHERS THEN doerr();
END;
© Ellis Cohen

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

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

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

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

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

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

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

17. Derivation Constraints
© Ellis Cohen

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

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

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

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

22. 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
= :zip AND
= (SELECT state FROM ZipStates&& WHERE = :empno)
The assertion can also be written so it is generalized
© Ellis Cohen

23. 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' AND
= (SELECT state FROM ZipStates&& WHERE = 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

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

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

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

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

28. Initialization Constraints
© Ellis Cohen

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

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

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

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

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

34. Relational Initialization Constraint
ANY ACTION RESULTS IN
EACH Entries&& e WHERE e.invid" IS NULL AND e.invid' IS NOT NULL
SATISFIES
= (SELECT FROM Products&& p WHERE =
© Ellis Cohen

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

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

37. Initial Default Constraints
© Ellis Cohen

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

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

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

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

42. 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
= (SELECT FROM Products&& p WHERE =
© Ellis Cohen

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

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

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