Declarative Constraints for Complex Business Rules and Improved Performance

Declarative Constraints for Complex
Business Rules and Improved
Performance
Carl Dudley
University of Wolverhampton

Carl Dudley – University of Wolverhampton, UK
1

Performance
Carl Dudley
University of Wolverhampton, UK

UKOUG Director

carl.dudley@wlv.ac.uk


Constraints

 Working with Oracle since 1986
 Oracle DBA - OCP Origins and9, 10
Constraints – Oracle7, 8, Syntax

 Oracle DBA and Foreign Key Constraints
NULLs of the Year – 2002

 Oracle ACE Director
Deferring and Enforcing Constraints
 Regular Presenter at Support
Data Dictionary Oracle Conferences
 Consultant and Trainer
Complex Constraints and Query Transformations
 Technical Editor for a number of Oracle texts
 UK Oracle User Group Director
 Member of IOUC
 Day job – University of Wolverhampton, UK

3

Constraints – a Brief History

 1970 – Ted Codd
— A Relational Model for Large Shared Databanks
 1984 DB2
— Rudimentary support
 SQL 1986
— Initial requirements
 1987 OracleV6
— Documentation support
 SQL 1989
— Referential Integrity
 1992 Oracle7
— Full support

4

Declarative Constraints

 Preserve data integrity through the use of constraints
— Cover rows already present in the table plus any rows which are
subsequently created
 Implement simple business rules such as
‘salaries should not exceed $5000’
— More complex business rules need to be handled by application logic
within transactions or by the use of database triggers

 Not independent objects
— Created and manipulated only via CREATE TABLE and ALTER TABLE

5

Primary Key Constraints

 Constraints can be used to enforce
— Entity Integrity (no duplicate rows?)
— Referential Integrity
 EVERY table should have a primary key (to enforce entity integrity)
CREATE TABLE emp
(empno NUMBER(4) CONSTRAINT emp_pk PRIMARY KEY,
:
— The primary key column(s) will be
• UNIQUE and NOT NULL
• Automatically indexed (use can be made of an existing index)

6

Primary Key Constraints

 Unique and not null data values
— Should not contain ‘meaningful’ data and should not be updated
• Usually numeric columns and as short as possible
— Can be composite - but usually single columns
• Composite keys can be big and require complex join criteria
• Cannot be assigned simple sequence numbers
 Often named using primary key column or table name(s) with a ‘_pk’ suffix

 Use ALTER TABLE to place a primary key on an existing table

ALTER TABLE dept
ADD CONSTRAINT dept_pk PRIMARY KEY(deptno);

7

Unique and NOT NULL Constraints

 Unique Constraints are like primary keys but allow NULL values
— Unlimited as all are considered unique!
— Any number allowed on a table
— Often named with unique key column name(s) plus a ‘_uk’ suffix

ALTER TABLE emp
ADD CONSTRAINT ename_deptno_uk
UNIQUE (ename,deptno);

 NOT NULL constraints do not allow NULLs in a column
— Not named and usually defined when a table is created
CREATE TABLE emp (
empno NUMBER(4) NOT NULL,
ename VARCHAR2(20),
sal NUMBER(7,2) NOT NULL,
comm NUMBER(7,2),
deptno NUMBER(2) NOT NULL);

8

CHECK Constraints

 Simple business rules can be enforced
— Based on constants and column values of only the row being updated
— References to data in other tables via subqueries is not possible
• sysdate and user are not allowed due to implicit subquery
— A common naming convention is to use a ‘_ck’ suffix

 Optimised beneath the SQL layer

 Not violated if evaluate to unknown
ALTER TABLE emp
ADD CONSTRAINT sal_ck
CHECK (sal > 0 OR comm >= 0);

— A NULL sal will allow a negative comm to pass the check
— In this case, it may be advisable to declare both columns as NOT NULL

9

CHECK Constraint Examples

 Ensure gender values are always uppercase ‘m’ or ‘f’
CREATE TABLE emp (
gender VARCHAR2(1) CONSTRAINT gender_ck
CHECK (gender IN UPPERCASE(‘m’,’f’));

 Ensure that commission is never more than ¼ of an employee’s salary
ALTER TABLE emp (
ADD CONSTRAINT comm_ck
CHECK (comm < sal*0.25);

 Ensure that hiredate is not later than the current date

ALTER TABLE emp (
ADD CONSTRAINT hiredate_ck
CHECK (hiredate <= sysdate);

— Error because sysdate implies a subquery

10

Referential Integrity

 Maintains integrity of master-detail relationships
— Operations on the primary key of the parent table are constrained if
dependent rows exist in the child table
— Operations on the foreign key in the child table are prevented if they result in
values which do not exist in the parent (referenced) table
• In Oracle, foreign keys may be set to NULL regardless of any referential
constraint

deptno dname empno ename mgr deptno
------ ---------- ----- -------- ---- ------
10 ACCOUNTING
20 RESEARCH
7369 SMITH 7566 20 Foreign
7499 ALLEN 7698 10
30 SALES
7521 WARD 7698 30
keys
40 OPERATIONS
7566 JONES 7521 10
7654 MARTIN 7521 10
7698 BLAKE 30

Emp Dept

11

Foreign Key (Referential) Constraints

 May be single or composite columns
 Must match data type of the referenced column(s)
 No limit to number of foreign keys
 Referenced columns must already be PRIMARY KEY or UNIQUE columns
— Referenced columns may be in the same table
 Foreign key columns may be NULL or partly NULL (regardless of any
Foreign Key constraint)

 Indexes are not automatically created on the foreign key columns

12

In-line and Out-of-line Constraints
 An in-line constraint is specified on the same line as the column definition
— Also known as a column-level constraint
— Datatype definition is not actually required for foreign key
CREATE TABLE ...
:
deptno NUMBER(4) CONSTRAINT emp_dept_fk
REFERENCES dept(deptno);

 An out-of-line constraint is specified in a separate clause
— Also known as a table-level constraint
— Suppose dept has a composite key of divno and deptno
CREATE TABLE ...
:
divno NUMBER(3),
deptno NUMBER(4),
:
CONSTRAINT emp_dept_fk FOREIGN KEY (divno,deptno)
REFERENCES dept(divno,deptno);

13

General Foreign Key Constraint Actions

 Four options are generally recognised for actions performed by
foreign key constraints
RESTRICT SET NULL SET DEFAULT CASCADE

 Oracle supports : Restriction of UPDATEs to referenced columns
Restriction of DELETEs to referenced columns
DELETE CASCADE (deletion of dependent rows)
DELETE SET NULL
 No support for UPDATE CASCADE
— Must be performed via triggers or application logic
 The SQL standard proposes a ‘PENDANT’ facility
— When the last remaining employee in a department is deleted, the
department record must also be deleted

14

The DELETE CASCADE Action

 Syntax for DELETE CASCADE :

ALTER TABLE emp
ADD CONSTRAINT emp_dept_fk FOREIGN KEY (deptno)
REFERENCES dept(deptno)
ON DELETE CASCADE;

 Oracle will report only on rows which are deleted from dept when
this referential action occurs

DELETE FROM dept WHERE deptno IN (10,20);

2 rows deleted

15

Conterminous Paths

TableA
Delete Cascade
Delete Cascade

TableB TableC

Delete Delete Restrict
Cascade TableD

 Each table has one row with the value ‘x’
 What would be the effect of? :
DELETE FROM a WHERE col = ‘x’;

16

Enabling/Disabling Constraints

ALTER TABLE emp DISABLE CONSTRAINT emp_pk;
— Relaxes the constraint
— Often done to increase speed of DML (e.g. bulk data loads)
— Drops any associated UNIQUE index by default

ALTER TABLE emp ENABLE CONSTRAINT emp_pk;
— Enforces the constraint
— Checks rows for violations
— Any violations prevent the constraint being enabled
— Locks out activity on the table
— Builds any associated index (may take some time)
 Constraints are enabled by default on creation

17

Foreign Key Indexes and Locking

 Most foreign keys should be indexed
— If the unique or primary key is updated or deleted
• Indexes are even more important for ON DELETE CASCADE
— If there are many joins between parent and child
 When a foreign key is unindexed :
— DML on the parent primary key results in a table level lock on the child
preventing DML on it
— The child table lock is obtained and released immediately for each update of
row in parent
— Lock exists for short period, but can cause significant contention on child
 When a foreign key is indexed :
— DML on parent primary key results in a row share table lock on child table
— Prevents other transactions gaining table locks on the child table, but does
not block DML on either the parent or the child table
— Only rows relating to the parent primary key are locked in the child table

18

Indexes on Foreign Keys

 Foreign keys are not indexed by default
— Very significant locking implications
— MONITORING USAGE does not detect use of indexes for concurrency
— 11gR2 invisible indexes on FKs are also 'invisible' for concurrency
 Support document 1019527.6 has a script that generates advice/report
— Not accurate if foreign key columns present in an index in different order
• Interprets this as unusable index
Changing data in table DEPT will lock table EMP
Create an index on table EMP with the following columns to
remove lock problem
Column = DEPTNO (1)
Changing data in table ITEM_CATEGORIES will lock table ITEMS
Create an index on table ITEMS with the following columns to
remove lock problem
Column = ITEM_CAT (1)
Column = ITEM_BUS_UNIT (2)
Changing data in table EMP will lock table EMP
Create an index on table EMP with the following columns to
remove lock problem
Column = MGR (1)
19

Constraints and Entity Models

 No constraints (other than referential) on the foreign key

X Y

 Additional NOT NULL constraint on the foreign key

X Y

 Additional UNIQUE constraint on the foreign key
X Y

 Additional UNIQUE and NOT NULL constraints on the foreign key
X Y

20

Constraints

Constraints – Origins and Syntax

NULLs and Foreign Key Constraints


Data Dictionary Support


21

Foreign Keys and Nulls

 Single column foreign key values must match primary key or be NULL
 Composite foreign key values must match primary key or be wholly or
partly NULL
 Partly NULL keys are not checked for the integrity of the NOT NULL part
Newemp
Newdept
PK = Divno Deptno Ename FK =
Divno Deptno Desc ----- ------ ------
----- ------ ---------- divno,deptno 2 1 Smith divno,deptno
1 1 Finance 1 2 Adams
1 2 Sales 2 1 Carter
2 1 Operations 2 NULL Best
2 2 Design NULL NULL Cox
2 3 Chemicals NULL 9 Scott
1 NULL King
2 5 Ford

 Scott passes the integrity check, but Scott’s NULL can not be updated
— The row for Ford will be checked out

22

Matching Nulls
 A composite foreign key may be (i) all NULL
(ii) all non-NULL
(iii) partially NULL

— There are three possible matching rules for such keys

1. Match Full All columns must be NULL or all columns must
have matching values in the primary key
2. Match Partial All columns must be NULL or
Some of the columns may be NULL and the
remainder must match values in their respective
primary key columns
— Match none All columns must be NULL or one or more columns are
NULL and the remainder may take any value

 Oracle by default uses the Match None rule

23

Matching Partial NULLs

 Partial NULLs are allowed in foreign keys (ANSI standard)
 To prevent partial NULLs – use a CHECK constraint

CONSTRAINT divno_deptno_ck
CHECK (
((divno IS NOT NULL) AND (deptno IS NOT NULL))
OR
(((divno IS NULL) AND (deptno IS NULL)))
— This will force the ‘Match Full’ rule for NULLs
— The ‘Match Partial’ rule can not be properly implemented using
declarative integrity constraints – database triggers must be used

24

Constraints






25

Handling Exceptions

 To deal with rows which are violating (and preventing) a constraint
s Construct an exceptions table using the UTLEXCPT script
Issue a statement to create a constraint – for example :
ALTER TABLE emp ADD CONSTRAINT emp_pk
PRIMARY KEY (empno)
EXCEPTIONS INTO exceptions;
This will place the ROWIDs of any offending rows in the
exceptions table so that the rows can be identified and dealt with
ROW_ID OWNER TABLE_NAME CONSTRAINT
------------------ ---------- ----------- ----------
AAABFJAACAAAFA3AAN SCOTT EMP EMP_PK
AAABFJAACAAAFA4AAN SCOTT EMP EMP_PK

3. Optionally remove all rows causing violations (could be dangerous)
DELETE FROM emp WHERE ROWID IN
(SELECT row_id FROM exceptions
WHERE constraint = <constraint_name>);

26

Deferred Constraints

 Constraint checking can be deferred until end of transaction at commit time
— If the constraint is violated, the entire transaction is rolled back
ALTER TABLE table_name ADD CONSTRAINT ...
:
[INITIALLY DEFERRED | INITIALLY IMMEDIATE]
[DEFERRABLE | NOT DEFERRABLE];
 INITIALLY DEFERRED
— On creation, constraint is not checked until commit
 INITIALLY IMMEDIATE
— On creation, constraint is checked after each DML statement (default)
 DEFERRABLE, NOT DEFERRABLE
— Governs whether behaviour of constraint can be subsequently changed to
DEFERRED or IMMEDIATE

27

Deferred Constraint Example

 Scenario (hypothetical example for illustration only):
— The dept table has a primary key on deptno

ALTER TABLE dept
ADD CONSTRAINT dept_pk PRIMARY KEY(deptno)

— The emp table has a deferrable foreign key on deptno referencing
dept, initially set to ‘IMMEDIATE’
ALTER TABLE emp ADD CONSTRAINT emp_dept_fk
FOREIGN KEY (deptno) REFERENCES dept(deptno)
INITIALLY IMMEDIATE DEFERRABLE;

28

Deferred Constraint Example (continued)

 It is required to update a department number from 10 to 99

 Changes will need to be made by separate update statements as follows
1. UPDATE dept SET deptno = 99 WHERE deptno = 10;
2. UPDATE emp SET deptno = 99 WHERE deptno = 10;

 The first update fails with the following error message

ORA-02292: integrity constraint (SCOTT.EMP_DEPT_FK)
violated - child record found

— The constraint is checked ‘immediately’ and therefore too early
• Reversing the updates does not help
— Maybe we can change the constraint mode

29

Changing the Constraint Mode

 Two methods available to toggle constraint modes
 SET CONSTRAINT
— Used to change the mode for a single transaction

SET CONSTRAINT constraint_name,...,constraint_name
IMMEDIATE | DEFERRED;

SET CONSTRAINTS ALL IMMEDIATE | DEFERRED;
 ALTER SESSION
— Changes mode for all deferrable constraints for an entire session
ALTER SESSION SET CONSTRAINTS = IMMEDIATE | DEFERRED;
— Reset to default (initial) validation using the keyword DEFAULT

ALTER SESSION SET CONSTRAINTS = DEFAULT;

30

Processing the Update Transaction

1. Set the constraint to be deferred until the end of the transaction
— Constraint checked when commit occurs
SET CONSTRAINT emp_dept_pk DEFERRED;

 Execute both updates
— These both succeed in changing deptno values in emp and dept from 10
to 99

3. Issue the commit
— The entire transaction will succeed as all the data is now consistent at time
of commit

31

Index Support for Deferred Constraints

 Index must be non-unique for deferred constraints
— Index uniqueness could be violated DURING the transaction
 Dropping a deferrable constraint does not drop the index (by default)
 Creating a deferred constraint will use an existing non-unique index on the
intended primary key column
— Uniqueness will now be enforced
— Index name will not be changed to constraint name
 Any constraint built on an MV should be deferrable
— The refresh process requires this

32

Enforced Constraints

 Existing data is not checked
— Checks made only on changes after enabling the constraint

 Used when constraints do not apply to historical data or when it is
known that existing data already complies with the constraint

 Example : No new employees can have a salary > $3000
ALTER TABLE emp ADD CONSTRAINT sal_ck
CHECK (sal <=3000) ENABLE NOVALIDATE;
— Constraint is created even though existing rows violate it

 Attempt to insert a new row which violates the constraint
INSERT INTO emp (empno,ename,sal,deptno)
VALUES (8888,’COX’,5500,10);

— Rejected with the following error message
ORA-02290: check constraint (SCOTT.EMP_CK) violated

33

Validating Enforced Constraints

 After eliminating all violations, the constraint can be validated so that it
acts upon all rows in the table

ALTER TABLE emp ENABLE VALIDATE CONSTRAINT sal_ck;

 If King’s salary of $5000 is still present the following error message is
generated
ORA-02293: cannot enable (SCOTT.EMP_CK) - check
constraint violated

34

Setting up Primary Keys with NOVALIDATE

 Suppose you have a table of historical data that could already have
duplicate rows which are of no immediate consequence
 You want to restrict any new data to be unique

r Create a non-unique index on the 'primary key' column(s)

q Create a primary key constraint in NOVALIDATE state

 The normal instigation of a primary key builds a unique index even in
NOVALIDATE state
— Any duplicate rows already present will foul the creation of the index
— If no duplicates, there will still be a delay before the constraint is enforced
due to creation of the unique index

35

Non_unique Indexes for Primary Keys

 Build a table with duplicate data already present
CREATE TABLE empn AS SELECT * FROM emp;

INSERT INTO empn SELECT * FROM empn WHERE empno = 7369;

 Try to enforce a (non-DEFERRABLE) primary key with a unique index
ALTER TABLE empn ADD CONSTRAINT empn_pk PRIMARY KEY(empno) NOVALIDATE;
ORA-02437: cannot validate (SCOTT.EMPNOVAL_PK) - primary key violated

 Enforce primary key with non-unique index
ALTER TABLE empn ADD CONSTRAINT empn_pk PRIMARY KEY(EMPNO)
USING INDEX (CREATE INDEX empn_pk ON empn(empno)) NOVALIDATE;

Table altered. --succeeds because non-unique index can be built

INSERT INTO empn SELECT * FROM empn;
ORA-00001: unique constraint (SCOTT.EMPN_PK) violated

36

RELY

 Tells Oracle that it should rely on the data complying with the constraint
 Basically you are asking the optimizer to trust you to guarantee the data
 RELY allows the optimizer to 'use' a NOVALIDATE constraint
— Main relevance is for materialized views
ALTER TABLE emp ADD CONSTRAINT sal_ck
CHECK (comm = sal) ENABLE NOVALIDATE RELY;

37

Constraints and Indexes

 Constraints are logical entities
 Indexes are physical structures
 Primary key and unique constraints do not theoretically require indexes
— An index is used (and built if needed) to enhance performance
• Full table scan could be used to check for duplicate values
 A non-unique index can support a constraint
— Must be used for deferred constraints
— May be used if it already exists and has the chosen primary key column(s)
as the leading edge
— Remains live if the constraint is dropped, unless DROP INDEX is used
— Can be selected from the set of suitable indexes with USING INDEX
• Or built on creation of the constraint with CREATE INDEX

38

Support for Legal SQL Statements

UPDATE emp SET empno = empno + 5;
before after
Empno Empno
1 1 6^
2 2 7^
3 3 8^
4 4 9
5 5 10
6 6 11
7 7 12
8 8 13

 Yet another reason why you should not attempt to substitute constraints
with your own code
— Non-unique index support tends to generate more redo

39

Non-Unique Indexes - Examples of Use

ALTER TABLE emp ADD CONSTRAINT pk_emp PRIMARY KEY(empno)
USING INDEX(CREATE UNIQUE INDEX twocol
ON emp(empno,ename));
Presence of additional columns
works only for Non-unique indexes
ORA-14196: Specified index cannot be used to enforce the
constraint.

ALTER TABLE emp ADD CONSTRAINT pk_emp PRIMARY KEY(empno)
USING INDEX(CREATE INDEX empno_ename ON emp(empno,ename));

ALTER TABLE emp DROP PRIMARY KEY [KEEP | DROP INDEX]; KEEP
allows Nulls
Default : KEEP for non-unique indexes
DROP for unique indexes
 Existing indexes can be used
— Could help minimize number of required indexes
— Can overload unique index with extra columns to avoid table access

40

Efficient Use of Integrity Constraints: A Procedure

 Using states of integrity constraints in the following order can ensure the
best benefits:
i Place constraint in disable state
Perform the DML operation (load, export, import).
o Enable the constraint in novalidate state
r Fully enable the constraint (validate)
 Some benefits of using constraints in this order are:
— No locks are held
— All constraints can go to enable state concurrently
• Constraint enabling is done in parallel
— Concurrent activity on table is permitted

41

Constraints






42

Constraints in the Data Dictionary

 Details of constraints can be found in user_constraints
TABLE_NAME CONSTRAINT_NAME CONSTRAINT_TYPE R_CONSTRAINT_NAME STATUS
-------------- ---------------- --------------- ----------------- --------
DEPT DEPT_PK P ENABLED
EMP EMP_PK P ENABLED
EMP EMP_JOB_CK C DISABLED
EMP SYS_C001415 C ENABLED
EMP EMP_DEPT_FK R DEPT_PK ENABLED
EMP SYS_C011791 ?

The constraint_type column can have the following values

C : Check constraint (tables only)
P : Primary key constraint
R : Foreign key constraint
U : Unique key constraint
V : WITH CHECK OPTION constraint on a view
O : Read only view (not table)
F : Constraint involving a REF column
S : Supplemental Logging
H : Hash expression

43

Constraints in the Data Dictionary (continued)

 Columns suffering constraints are found in user_cons_columns
SELECT constraint_name
,table_name
,column_name
,position
FROM user_cons_columns;

CONSTRAINT_NAME TABLE_NAME COLUMN_NAME POSITION
----------------- ------------ ------------ --------
EMP_JOB$DEPTNO_UK EMP JOB 1
EMP_JOB$DEPTNO_UK EMP DEPTNO 2
DEPT_PK DEPT DEPTNO 1
EMP_PK EMP EMPNO 1

44

Constraints in the Data Dictionary (continued)

CREATE VIEW v2 AS SELECT * FROM emp;

ALTER VIEW v2 ADD PRIMARY key(empno) DISABLE NOVALIDATE;

ALTER TABLE emp DROP PRIMARY KEY;

SELECT constraint_name
,constraint_type
,table_name Example of INVALID constraint
,status
,validated
,rely
,invalid
,view_related
FROM user_constraints
WHERE invalid IS NOT NULL;
CONSTRAINT_NAME C TABLE_NAME STATUS VALIDATED RELY INVALID VIEW_RELATED
--------------- - ---------- -------- ------------- ---- ------- --------------
SYS_C0011765 P V2 DISABLED NOT VALIDATED INVALID DEPEND ON VIEW

45

Constraints in the data Dictionary (continued)

 Supplemental logging shows up in user_constraints
— Log groups are not shown
— The constraint_type is shown as ‘?’ (NOT ‘S’)
ALTER TABLE emp ADD PRIMARY key(empno);
ALTER TABLE emp ADD SUPPLEMENTAL LOG DATA(PRIMARY KEY) COLUMNS;
ALTER TABLE emp ADD SUPPLEMENTAL LOG DATA(ALL) COLUMNS;
ALTER TABLE emp ADD SUPPLEMENTAL LOG GROUP sal_comm(sal,comm);

SELECT constraint_name, constraint_type, table_name
FROM user_constraints WHERE table_name = 'EMP';

CONSTRAINT_NAME C TABLE_NAME
------------------------------ - ------------------------------
SYS_C0011794 P EMP
SYS_C0011795 ? EMP
SYS_C0011796 ? EMP

46

Types of Constraints in the Dictionary

 Definition of dba_constraints shows some of the types as ‘?’ or not at all
— type# can have a value of 1-17 in cdef$

decode(c.type#, 1, 'C', 2, 'P', 3, 'U',
4, 'R', 5, 'V', 6, 'O', 7, 'C', '?'),
:
:
and c.type# != 8 /* don't include hash expressions */
and c.type# != 12 /* don't include log groups */

47

dbms_metadata Support

SELECT dbms_metadata.get_dependent_ddl (
'REF_CONSTRAINT', 'EMP' ) fks_on_emp
FROM dual;
FKS_ON_EMP
------------------------------------------------------------
ALTER TABLE "SCOTT"."EMP" ADD FOREIGN KEY ("DEPTNO")
REFERENCES "SCOTT"."DEPT”(“DEPTNO”) ENABLE
ALTER TABLE "SCOTT"."EMP" ADD CONSTRAINT “MGR_FK” FOREIGN
KEY (“MGR")REFERENCES "SCOTT".“EMP”(“EMPNO”) ENABLE

 Script showing unindexed foreign key columns
SELECT * FROM (
SELECT c.table_name, cc.column_name, cc.position column_position
FROM user_constraints c, user_cons_columns cc
WHERE c.constraint_name = cc.constraint_name
AND c.constraint_type = 'R'
MINUS
SELECT i.table_name, ic.column_name, ic.column_position
FROM user_indexes i, user_ind_columns ic
WHERE i.index_name = ic.index_name
)
ORDER BY table_name, column_position;
48

Constraints






49

Foreign Keys Referencing Non-unique Columns

 Problem :
 Need to enforce a foreign key constraint on the occupation column in the
empdep table based on data in the emp table
— Requires a reference to a non-unique column (job) in the emp table
 Reference a materialized view carrying only unique values of job
EMPDEP
EMP ENAME OCCUPATION
EMPNO JOB EMP_V1 -------- ----------
----- -------- JOB WOODS CLERK
7366 SALESMAN -------- JOHNSON MANAGER
7500 MANAGER SALESMAN COX CLERK
7902 MANAGER MANAGER PITT CLERK
7566 CLERK CLERK SPINK SALESMAN
7934 SALESMAN DRAPER MANAGER
primary key
foreign key

50

Enforcing Foreign Keys Without Primary keys

CREATE MATERIALIZED VIEW LOG ON emp
job is not
WITH ROWID,PRIMARY KEY,SEQUENCE(job) unique in emp
INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW emp_v1
REFRESH FAST ON COMMIT
ENABLE QUERY REWRITE
AS SELECT job FROM emp GROUP BY job; job is unique in MV

ALTER MATERIALIZED VIEW emp_v1 ADD PRIMARY KEY (job);

ALTER TABLE empdep ADD CONSTRAINT empdep_emp_v1
FOREIGN KEY (occupation) REFERENCES emp_v1;
empdep must have only
UPDATE empdep SET occupation = 'X'; jobs in the emp table
ORA-02291: integrity constraint (SCOTT.EMPDEP_EMP_V1)
violated - parent key not found

51

Enforcing Complex Constraints with Materialized
Views

 Limit the total amount_sold of a single product sold through a single
channel to 563000000
 Create a materialized view, prod_chan_mv, which returns the maximum
amount sold for any product on any channel

CREATE MATERIALIZED VIEW prod_chan_mv
BUILD IMMEDIATE
AS
SELECT prod_id, channel_id, SUM(amount_sold) sum_amount_sold
FROM sales
GROUP BY prod_id, channel_id;

— REFRESH FAST ON COMMIT is necessary
• The constraint must be checked each time a change to the sales table
is committed

52

Enforcing Complex Constraints with Materialized
Views (continued)

 Find the maximum amount sold across all products within channels
SELECT prod_id, channel_id, sum_amount_sold
FROM prod_chan_mv
WHERE sum_amount_sold = (SELECT MAX(sum_amount_sold)
FROM prod_chan_mv);
PROD_ID CHANNEL_ID SUM_AMOUNT_SOLD
---------- ---------- ---------------
18 3 562565473

 As the maximum amount sold was 562565473 it is sensible to make the
constraint on the sum_amount_sold column 563000000
ALTER TABLE prod_chan_mv
ADD CONSTRAINT amount_sold_check
CHECK (sum_amount_sold < 563000000)
DEFERRABLE;

— Constraint is checked on commit rather than on update

53

Testing Complex Constraint Checking with
Materialized Views

 Insert a row with an amount_sold value of 8000000 which causes the
constraint on the MV to be violated
INSERT INTO sales
VALUES(18, 1, '01-jan-2002', 3, 999, 1, 8000000);

 Constraint is not enforced until the commit (and refresh) takes place
SQL> COMMIT;
COMMIT
ERROR at line 1:
ORA-12048: error encountered while refreshing materialized
View "SH"."PROD_CHAN_MV"
ORA-02290: check constraint (SH.AMOUNT_SOLD_CHECK) violated

 Could lead to large numbers of rows in the MV when constraint is
repeatedly NOT violated

54

Attempt to Avoid Storage Overheads when
Enforcing Constraints with Materialized Views

 A HAVING clause makes it possible to collect into the MV only those rows
that have amount_sold greater than 563000000

CREATE MATERIALIZED VIEW prod_chan_mv
BUILD IMMEDIATE
AS
SELECT prod_id
,channel_id
,SUM(amount_sold) sum_amount_sold
FROM sales
GROUP BY prod_id, channel_id
HAVING SUM(amount_sold) > 563000000;
 BUT there is a limitation
— The presence of HAVING makes the view a ‘complex MV’ which is not able
to be refreshed on commit
• Still the case in Oracle11g

55

Enforcing Complex Constraints with
Materialized View Joins

 Problem – employees are assigned to projects
 Assignment period must be contained within the duration of the project
 Tables :
CREATE TABLE proj (
projno NUMBER PRIMARY KEY
,start_date DATE NOT NULL
,end_date DATE NOT NULL);

CREATE TABLE proj_asst (
empno NUMBER NOT NULL
,projno NUMBER NOT NULL
,start_date DATE NOT NULL
,end_date DATE NOT NULL
,PRIMARY KEY (empno, projno, start_date));

56

Sample Input Data

proj

PROJNO START_DATE END_DATE
------ ---------- ---------
1 01-AUG-09 31-AUG-09
2 22-JUL-09 29-SEP-09
3 01-MAR-08 30-APR-08

proj_asst

EMPNO PROJNO START_DATE END_DATE
----- ------ ---------- ---------
7369 1 12-AUG-09 19-AUG-09
7369 2 21-AUG-09 28-AUG-09
7369 2 18-AUG-09 25-SEP-09
7369 1 01-AUG-09 31-AUG-09
7369 1 02-JAN-08 31-MAY-08 Bad rows
7369 3 23-SEP-09 30-SEP-09

57

The Materialized View

CREATE MATERIALIZED VIEW LOG ON proj WITH
ROWID(projno,start_date,end_date) INCLUDING NEW VALUES;

CREATE MATERIALIZED VIEW LOG ON proj_asst WITH
ROWID(empno,projno,start_date,end_date) INCLUDING NEW
VALUES;

CREATE MATERIALIZED VIEW proj_asst_mv
REFRESH FAST ON COMMIT AS
SELECT pa.projno
,pa.start_date pa_start_date
,pa.end_date pa_end_date
,p.start_date p_start_date View designed to collect
,p.end_date p_end_date only the 'bad' rows
,pa.rowid pa_rowid
,p.rowid p_rowid
FROM proj_asst pa
,proj p
WHERE pa.projno = p.projno
AND NOT (pa.start_date >= p.start_date
AND pa.end_date <= p.end_date);
58

The Constraint to Avoid Storage Overhaead

 MV is designed to capture as part of the transaction, only the invalid rows
 The CHECK constraint prevents these rows being inserted into the view
— Thus causing the initiating transaction to fail
• Valid rows are not considered for the MV – no storage overhead

ALTER TABLE proj_asst_mv
ADD CONSTRAINT proj_asst_mv_ckdates
CHECK (pa_start_date >= p_start_date
AND pa_end_date <= p_end_date)
DEFERRABLE;

 The MV will always be empty
— On 11g Release2 with DEFERRED_SEGMENT_CREATION it may never be
built!

59

Complex 'Constraints' with Unique Indexes

 Suppose we can have a maximum of only one manager in each department
CREATE UNIQUE INDEX emp_ind ON emp
(CASE WHEN job = 'MANAGER'
THEN TO_CHAR(deptno)||job
ELSE NULL
END);

 Ensures unique combinations of job and deptno columns only for managers
UPDATE emp SET job = 'MANAGER' WHERE ename = 'SMITH';
ORA-00001: unique constraint (SCOTT.EMP_IND) violated

— But ---Index can be dropped
— Need to think about Null values
UPDATE emp SET job = 'CLERK';
14 rows updated.

60

NOT NULL Constraints Effects on Queries

 Specify NOT NULL constraints wherever possible
— Cuts down tests for, and coping with, possibility of NULLs
— Could allow greater use of indexes
• Query transformations
• Fast Full Index scans
• Indexes are 'skinny'
• Could eliminate sorts
 Inserting nulls into NOT NULL columns
ORA-01400: cannot insert NULL into ("SCOTT"."EMP"."DEPTNO")

 Inserting nulls into NOT NULL DEFERRABLE columns
ORA-02290: check constraint (SCOTT.SYS_C0012066) violated

61

Behaviour with NOT NULL Constraints

 Table empn has ~ 60000 rows
— job column does not contain any nulls and is not indexed

SELECT * FROM empn WHERE job IS NULL;
Constraint type No NOT NULL NOT NULL NOT NULL
constraint NOVALIDATE DEFERRED
Consistent gets 397 0 397 397

 NOT NULL constraint has prevented an entire table access for this query
 NULL IS NOT NULL is added to the query as a filter
— If in NOVALIDATE or DEFERRED state, the optimization is lost
• Think carefully before using these states
— Does not seem to apply to virtual columns --??
 Enforcing not null via CHECK syntax does not have this optimization effect
— null$ in col$ remains set to 0
62

NOT NULL Constraints and the Optimizer

 Wide 1m row emp table with 500 extra characters in each row
— Five different jobs in an indexed job column
— Two queries under test

SELECT DISTINCT job FROM emp; --Q1
SELECT job,COUNT(*) FROM emp GROUP BY job; --Q2

Q1 No constraint on job NOT NULL constraint on job

Query Plan HASH UNIQUE HASH UNIQUE
TABLE ACCESS FULL EMP INDEX FAST FULL SCAN EMP$JOB
Disk Reads 70805 2419
CPU Time 0.87s 0.46s
Elapsed 12.19s 0.85s
Time
fat table skinny index

63

NOT NULL Constraints and the Optimizer
(continued)

SELECT job,COUNT(*) FROM emp GROUP BY job; --Q2

Q2 No constraint on job NOT NULL constraint on job

Query Plan HASH GROUP BY HASH GROUP BY
TABLE ACCESS FULL EMP INDEX FAST FULL SCAN EMP$JOB
Disk Reads 70805 2419
CPU Time 0.95s 0.65s
Time

 If OPTIMIZER_MODE = FIRST_ROWS_1, Q1 with job as NOT NULL
gives :
SORT GROUP BY NOSORT
INDEX FULL SCAN EMP$JOB

64

NOT IN subqueries

SELECT * FROM dept WHERE deptno NOT IN (SELECT deptno FROM emp);

No constraint on deptno NOT NULL constraint on deptno
Query HASH JOIN ANTI NA HASH JOIN ANTI SNA
Plan TABLE ACCESS FULL EMP TABLE ACCESS FULL DEPT
TABLE ACCESS FULL DEPT INDEX FAST FULL SCAN EMP$DEPTNO
Disk 70811 1801
Reads
CPU 0.84s 0.53s
Time
Time
— NA : NULL Aware anti-join
Both are 11g features
— SNA : Single NULL Aware anti-join
 10g does : FILTER
TABLE ACCESS FULL DEPT
TABLE ACCESS FULL EMP

65

Counting the Rows in a Table

 NULL values not stored in Btree indexes
— Oracle cannot guarantee that the count of index entries is equal to number
of rows in table
— Full table scan must be executed - slow

SELECT COUNT(*) FROM s;
COUNT(*)
--------
918843

Elapsed: 00:00:03.17

-------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 5250 (1)| 00:01:03 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | TABLE ACCESS FULL| S | 918K| 5250 (1)| 00:01:03 |
-------------------------------------------------------------------

Statistics
----------------------------------------------------------
19214 consistent gets

66

Counting the Rows in a Table (continued)

 Inform Oracle that there cannot be any NULLs in seqid via a constraint
ALTER TABLE s MODIFY seqid NOT NULL;

 Index will now be used to count the rows – fast
— Oracle knows that scanning the index will definitely give the right answer
SELECT COUNT(*) FROM s;
COUNT(*)
--------
918843
Elapsed: 00:00:00.07
-------------------------------------------------------------------------
| Id | Operation | Name | Rows | Cost (%CPU)| Time |
-------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 562 (2)| 00:00:07 |
| 1 | SORT AGGREGATE | | 1 | | |
| 2 | INDEX FAST FULL SCAN| S$SEQID | 918K| 562 (2)| 00:00:07 |
-------------------------------------------------------------------------
Statistics CHECK (sal IS NOT NULL)
----------------------------------------------------------
2062 consistent gets does not work in this way

67

Constraints and Query Transformation

 Constrain jobs in a top_jobs table
SELECT * FROM top_jobs; ALTER TABLE top_jobs
ADD CONSTRAINT ck_top_jobs
JOB_ID JOB MAXSAL CHECK (job IN
------ --------- ------ ('PRESIDENT','MANAGER','ANALYST'));
1 PRESIDENT 6000
2 MANAGER 4000
3 ANALYST 3500

 Index the job column in the emp table
CREATE INDEX emp$job ON emp(job);

 Join top_jobs to emp
SELECT ename,job,sal,t.maxsal
FROM emp e,top_jobs t
WHERE t.job = e.job AND e.deptno = 10;

68

Constraints and Query Transformation (continued)

 Query transformation takes place
HASH JOIN
INLIST ITERATOR
TABLE ACCESS BY INDEX ROWID EMP
INDEX RANGE SCAN EMP$JOB
TABLE ACCESS FULL TOP_JOBS
access("T"."JOB"="E"."JOB")
filter("E"."DEPTNO"=10)
access("E"."JOB"='ANALYST' OR "E"."JOB"='MANAGER'
OR "E"."JOB"='PRESIDENT')

 If the constraint is removed a very different plan is obtained
NESTED LOOPS
NESTED LOOPS
TABLE ACCESS FULL TOP_JOBS
INDEX RANGE SCAN EMP$JOB
TABLE ACCESS BY INDEX ROWID EMP
access("T"."JOB"="E"."JOB")
filter("E"."DEPTNO"10)

69

Conditional Constraints using DECODE or CASE

CREATE TABLE project (
project_ID NUMBER PRIMARY KEY
,teamid NUMBER
,job VARCHAR2(100)
,status NUMBER(1));
 An active project has status = 1, otherwise it is archived
 The job has to be unique in the same teamid for the active projects
— Means teamid and job have to be unique while status = 1
 Solved with a function based index (FBI) using DECODE or CASE
CREATE UNIQUE INDEX project_idx ON project (
DECODE(status, 1, teamid, NULL ),
DECODE(status, 1, job, NULL ));

CREATE UNIQUE INDEX project_idx ON project (
CASE WHEN status = 1 THEN teamid ELSE NULL END,
CASE WHEN status = 1 THEN job ELSE NULL END);

70

Join Elimination

 emp table has deptno column as a foreign key referencing dept
SELECT e,empno, e.ename
FROM emp e, dept d — Join to dept table
WHERE e.deptno = d.deptno; is eliminated in 10.2

---------------------------------
|Operation | Name |Rows |
---------------------------------
|SELECT STATEMENT | | 14|
| TABLE ACCESS FULL| EMP | 14| Predicate added by Oracle
---------------------------------
Predicate Information
-----------------------------
1 - filter("EMP"."DEPTNO" IS NOT NULL)
SELECT e.empno, e.ename
FROM emp e
WHERE NOT EXISTS (SELECT 1 FROM dept d
WHERE d.deptno = e.deptno)
— Anti-Join to dept table is eliminated in 11.1

71

Outer Join Elimination

 Can occur even without PK-FK constraints
— dept table simply has a unique constraint on deptno
 Find employees whether or not in a department
SELECT e.empno, e.ename
FROM emp e, dept d — Join to dept table
WHERE e.deptno = d.deptno(+); is eliminated in 11.1

---------------------------------
|Operation | Name |Rows |
---------------------------------
|SELECT STATEMENT | | 14|
| TABLE ACCESS FULL| EMP | 14|
---------------------------------

— EVERY row in emp is guaranteed to appear ONCE in output
• Unique constraint on dept.deptno ensures this

72

Updatable Views
 Views on more than one table (join-views) have restrictions for updates
— Columns which are updatable must be in key-preserved tables
— known 1:1 mapping of rows in the view to rows in the underlying base table
CREATE OR REPLACE VIEW deptemp AS
SELECT empno
,ename
,job
,mgr
,hiredate
,sal
,comm
,dept.deptno
,dname
,loc
FROM emp
,dept
WHERE dept.deptno = emp.deptno
 If dept has primary key on deptno column, emp is key-preserved
— Columns derived from emp become key-preserved
• 14 rows in the view and 14 rows in the emp table

74

Primary Keys and Key-Preserved Tables

 Example scenario with no primary key on dept table
— Duplicate rows are possible
dept emp
deptno dname loc empno ename ... deptno
------ ------- ----- ------ ----- --- ------
30 SALES LEEDS 2561 COOK 30
50 FINANCE YORK 4590 BROWN 30
50 DESIGN BATH 1695 GREEN 50

 Result of the equi-join on emp and dept
— Note that no table is key-preserved, so no columns are updatable
• deptno values in emp map to more than one row in dept table
empno ename ... deptno dname loc
------ ----- --- ------ ------- -----
2561 COOK 30 SALES LEEDS
4590 BROWN 30 SALES LEEDS
1695 GREEN 50 FINANCE YORK
1695 GREEN 50 DESIGN BATH

75

Updates on Views

 The dept table has a primary key on deptno
 deptno, dname and loc (columns from dept) are non-updatable
 Rows can be deleted but not inserted
SQL> SELECT * FROM deptemp;

EMPNO ENAME JOB MGR HIREDATE SAL COMM DEPTNO DNAME LOC
----- ------ --------- ---- --------- ---- ---- ------ ---------- --------
7934 MILLER CLERK 7782 23-JAN-82 1300 10 ACCOUNTING NEW YORK
7782 CLARK MANAGER 7839 09-JUN-81 2450 10 ACCOUNTING NEW YORK
7839 KING PRESIDENT 17-NOV-81 5000 10 ACCOUNTING NEW YORK
7369 SMITH CLERK 7902 17-DEC-80 800 20 RESEARCH DALLAS
7566 JONES MANAGER 7839 02-APR-81 2975 20 RESEARCH DALLAS
7788 SCOTT ANALYST 7566 19-APR-87 3000 20 RESEARCH DALLAS
7876 ADAMS CLERK 7788 23-MAY-87 1100 20 RESEARCH DALLAS
7902 FORD ANALYST 7566 03-DEC-81 3000 20 RESEARCH DALLAS
7499 ALLEN SALESMAN 7698 20-FEB-81 1600 300 30 SALES CHICAGO
7521 WARD SALESMAN 7698 22-FEB-81 1250 500 30 SALES CHICAGO
7654 MARTIN SALESMAN 7698 28-SEP-81 1250 1400 30 SALES CHICAGO
7698 BLAKE MANAGER 7839 01-MAY-81 2850 30 SALES CHICAGO
7844 TURNER SALESMAN 7698 08-SEP-81 1500 0 30 SALES CHICAGO
7900 JAMES CLERK 7698 03-DEC-81 950 30 SALES CHICAGO

76

Updates on Views (continued)

DELETE FROM deptemp
WHERE deptno = 10;
3 rows deleted.
UPDATE deptemp SET job = 'CLERK’
WHERE ename = 'FORD';
1 row updated.
UPDATE deptemp SET dname = 'ACCOUNTING' WHERE ename = 'FORD';

ERROR at line 1:
ORA-01779: cannot modify a column which maps to a
non key-preserved table

 Primary key is necessary on the non key-preserved table (dept)
— Otherwise no updates or deletes are possible

77

Summary

 Constraints
— Are never circumvented
— Apply to all rows and all applications
— Simple to specify - ‘Once only’ definition
— Efficient
— Cannot be used for complex business rules
— Are not checked until data is written to the database
— Do not implement all referential actions
— Are often incompatible with database triggers
— Can be used by the optimizer to eliminate unnecessary operations
• Join elimination
• SET operator elimination
• Eliminate entire table access(es)
• Maximize the use of Materialized Views

78

Performance
Carl Dudley
University of Wolverhampton, UK

UKOUG SIG Director

carl.dudley@wlv.ac.uk


Performance
Please Fill Out Your Evaluations

Carl Dudley
University of Wolverhampton

80

Declarative Constraints for Complex Business Rules and Improved Performance

Recommandé

Recommandé

Contenu connexe

Similaire à Declarative Constraints for Complex Business Rules and Improved Performance

Similaire à Declarative Constraints for Complex Business Rules and Improved Performance (20)

Dernier

Dernier (20)

Declarative Constraints for Complex Business Rules and Improved Performance

Notes de l'éditeur