Review Three things managed by a DBMS 1.Data organization E/R
Model Relational Model 2.Data Retrieval Relational Algebra
Relational Calculus SQL 3.Data Integrity and Database Design
Integrity Constraints Functional Dependencies Normalization
Slide 3
Integrity Constraints Purpose: prevent semantic inconsistencies
in data e.g.: 4 kinds of ICs: 1. Key Constraints 2. Attribute
Constraints 3. Referential Integrity Constraints 4. Global
Constraints e.g.: No entry for Kenmore... ???
Slide 4
ICs What are they? predicates on the database must always be
true (:, checked whenever db gets updated) There are the following
4 types of ICs: Key constraints (1 table) e.g., 2 accts cant share
the same acct_no Attribute constraints (1 table) e.g., 2 accts must
have nonnegative balance Referential Integrity constraints ( 2
tables) E.g. bnames associated w/ loans must be names of real
branches
Slide 5
Key Constraints Idea: specifies that a relation is a set, not a
bag SQL examples: 1. Primary Key: CREATE TABLE branch( bname
CHAR(15) PRIMARY KEY, bcity CHAR(20), assets INT); or CREATE TABLE
depositor( cname CHAR(15), acct_no CHAR(5), PRIMARY KEY(cname,
acct_no)); 2. Candidate Keys: CREATE TABLE customer ( ssn CHAR(9)
PRIMARY KEY, cname CHAR(15), address CHAR(30), city CHAR(10),
UNIQUE (cname, address, city);
Slide 6
Key Constraints Effect of SQL Key declarations PRIMARY (A1,
A2,.., An) or UNIQUE (A1, A2,..., An) Insertions: check if any
tuple has same values for A1, A2,.., An as any inserted tuple. If
found, reject insertion Updates to any of A1, A2,..., An: treat as
insertion of entire tuple Primary vs Unique (candidate) 1.1 primary
key per table, several unique keys allowed. 2.Only primary key can
be referenced by foreign key (ref integrity) 3.DBMS may treat
primary key differently (e.g.: implicitly create an index on PK) 4.
NULL values permitted in UNIQUE keys but not in PRIMARY KEY
Slide 7
Attribute Constraints Idea: Attach constraints to values of
attributes Enhances types system (e.g.: >= 0 rather than
integer) In SQL: 1. NOT NULL e.g.: CREATE TABLE branch( bname
CHAR(15) NOT NULL,.... ) Note: declaring bname as primary key also
prevents null values 2. CHECK e.g.: CREATE TABLE depositor(....
balance int NOT NULL, CHECK( balance >= 0),.... ) affect
insertions, update in affected columns
Slide 8
CHECK constraint in Oracle CHECK cond where cond is: Boolean
expression evaluated using the values in the row being inserted or
updated, and Does not contain subqueries; sequences; the SQL
functions SYSDATE, UID, USER, or USERENV; or the pseudocolumns
LEVEL or ROWNUM Multiple CHECK constraints No limit on the number
of CHECK constraints you can define on a column CREATE TABLE
credit_card(.... balance int NOT NULL, CHECK( balance >= 0),
CHECK (balance < limit),.... )
Slide 9
Referential Integrity Constraints Idea: prevent dangling tuples
(e.g.: a loan with a bname of Kenmore when no Kenmore tuple is not
in branch table) Referencing Relation (e.g. loan) Referenced
Relation (e.g. branch) foreign key bname primary key bname Ref
Integrity: ensure that: foreign key value primary key value (note:
need not to ensure , i.e., not all branches have to have
loans)
Slide 10
Referential Integrity Constraints Referencing Relation (e.g.
loan) Referenced Relation (e.g. branch) bname x x x In SQL: CREATE
TABLE branch( bname CHAR(15) PRIMARY KEY....) CREATE TABLE loan
(......... FOREIGN KEY bname REFERENCES branch); Affects: 1)
Insertions, updates of referencing relation 2) Deletions, updates
of referenced relation parent child
Slide 11
Referential Integrity Constraints c c x x x A B what happens
when we try to delete this tuple? titi tjtj Ans: Oracle allows the
following possibilities No action RESTRICT: reject deletion/ update
SET TO NULL: set t i [c], t j [c] = NULL SET TO DEFAULT: set ti
[c], tj[c] = default_val CASCADE: propagate deletion/update DELETE:
delete ti, tj UPDATE: set ti[c], tj[c] to updated values parent
child
Slide 12
Referential Integrity Constraints c c x x x Emp Dept what
happens when we try to delete this tuple? titi tjtj ALTER TABLE
Dept ADD Primary Key (deptno); ALTER TABLE Emp ADD FOREIGN KEY
(Deptno) REFERENCES Dept(Deptno) [ACTION]; Action: 1) ON DELETE NO
ACTION left blank (deletion/update rejected) 2) ON DELETE SET NULL/
ON UPDATE SET NULL sets ti[c] = NULL, tj[c] = NULL 3) ON DELETE
CASCADE deletes ti, tj ON UPDATE CASCADE sets ti[c], tj[c] to new
key values
Slide 13
Global Constraints Idea: two kinds 1) single relation
(constraints spans multiple columns) E.g.: CHECK (total = svngs +
check) declared in the CREATE TABLE Example: All Bkln branches must
have assets > 5M CREATE TABLE branch (.......... bcity CHAR(15),
assets INT, CHECK (NOT(bcity = Bkln) OR assets > 5M)) Affects:
insertions into branch updates of bcity or assets in branch 2)
Multiple Relations: NOT supported in Oracle Need to be implemented
as a Trigger
Slide 14
Global Constraints (NOT in Oracle) SQL example: 2) Multiple
relations: every loan has a borrower with a savings account CHECK
(NOT EXISTS ( SELECT * FROM loan AS L WHERE NOT EXISTS( SELECT *
FROM borrower B, depositor D, account A WHERE B.cname = D.cname AND
D.acct_no = A.acct_no AND L.lno = B.lno))) Problem: Where to put
this constraint? At depositor? Loan?.... Ans: None of the above:
CREATE ASSERTION loan-constraint CHECK(..... ) Checked with EVERY
DB update! very expensive.....
Slide 15
Global Constraints Issues: 1) How does one decide what global
constraint to impose? 2) How does one minimize the cost of checking
the global constraints? Ans: Functional dependencies. but before we
go there
Slide 16
Deferring the constraint checking SET ALL CONSTRAINTS DEFERRED;
Defers all constraint checks till the end of the transaction
Especially useful in enforcing Referential integrity Insert new
rows into Child table but referred key is not yet in Parent Insert
corresponding row in Parent table Constraint checking done at the
end of the transaction Can also defer individual constraint
checking by specifying the constraint name Finding the constraint
information in Oracle SELECT * FROM USER_CONSTRAINTS; SELECT * FROM
USER_CONS_COLS;
Slide 17
Summary: Integrity Constraints Constraint TypeWhere
declaredAffects...In Oracle ? Key Constraints CREATE TABLE (PRIMARY
KEY, UNIQUE) Insertions, UpdatesYes Attribute Constraints CREATE
TABLE CREATE DOMAIN (Not NULL, CHECK) Insertions, Updates Yes
CREATE DOMAIN not supported in Oracle Referential Integrity Table
Tag (FOREIGN KEY.... REFERENCES....) 1.Insertions into referencing
reln 2. Updates of referencing reln of relevant attrs 3. Deletions
from referenced reln 4. Update of referenced reln Yes Possible
Actions: -- Update/delete no aciton -- delete CASCADE -- delete SET
NULL, SET DEFAULT, Global ConsraintsTable Tag (CHECK) or outside
table (CREATE ASSERTION) 1. For single reln constraint, with
insertion, deletion of relevant attrs 2. For assesrtions w/ every
db modification Assertions, domains not supported in Oracle.
Slide 18
Review Three things managed by a DBMS 1.Data organization E/R
Model Relational Model 2.Data Retrieval Relational Algebra
Relational Calculus SQL 3.Data Integrity and Database Design
Integrity Constraints Functional Dependencies Constraints that hold
for legal instance of the database Example: Every customer should
have a single credit card Normalization
Slide 19
Functional Dependencies A B C AB determines C two tuples with
the same values for A and B will also have the same value for C
Constraints that will hold on all legal instances of the database
for the specific business application. In most cases, specified by
a database designer/business architect
Slide 20
Functional Dependencies Shorthand: C BD same as C B C D Be
careful! AB C not the same as A C B C Not true
Slide 21
Functional Dependencies Example: suppose R = { A, B, C, D, E,
H} and we determine that: F = { A BC, B CE, A E, AC H, D B} Then we
determine the canonical cover of F: Fc = { A BH, B CE, D B}
ensuring that F and Fc are equivalent Note: F requires 5 assertions
Fc requires 3 assertions Canonical cover (or minimal cover)
algorithm: In the book (not covered here).
Slide 22
Functional Dependencies Equivalence of FD sets: FD sets F and G
are equivalent if the imply the same set of FDs e.g. A B and B C :
implies A C equivalence usually expressed in terms of closures
Closures: For any FD set, F, F + is the set of all FDs implied by
F. can calculate in 2 ways: (1) Attribute Closure (2) Armstrongs
axioms Both techniques tedious-- will do only for toy examples F
equivalent to G iff F + = G +
Slide 23
Armstrongs Axioms A. Fundamental Rules (W, X, Y, Z: sets of
attributes) 1. Reflexivity If Y X then X Y 2. Augmentation If X Y
then WX WY 3. Transitivity If X Y and Y Z then X Z B. Additional
rules (can be proved from A) 4. UNION: If X Y and X Z then X YZ 5.
Decomposition: If X YZ then X Y, X Z 6. Pseudotransitivity: If X Y
and WY Z then WX Z Proving 4.(sketch): X Y => XX XY =>X XY XY
YZ => X YZ For every step we used the rules from A. 2 3
Slide 24
FD Closures Using Armstrongs Axioms Given; F = { A BC, (1) B
CE, (2) A E, (3) AC H, (4) D B} (5) Exhaustively apply Armstrongs
axioms to generate F + F+ = F 1. { A B, A C}: decomposition on (1)
2. { A CE}: transitivity to 1.1 and (2) 3. { B C, B E}: decomp to
(2) 4. { A C, A E} decomp to 2 5. { A H} pseudotransitivity to 1.2
and (4)
Slide 25
Attribute Closures Given; R = { A, B, C, D, E, H,I} and: F = {
A BC, C D, C E, AH I} What is the closure of A (A + ) ? Algorithm
att-closure (X: set of Attributes) Result X repeat until stable for
each FD in F, Y Z, do if Y Result then Result Result Z Attribute
closure A Iteration Result ----------------------------------- 0 A
1 A B C 2 A B C D 3 A B C D E Better to determine if a set of
attributes is a key
Slide 26
Functional dependencies Our goal: given a set of FD set, F,
find an alternative FD set, G that is: smaller equivalent Bad news:
Testing F=G (F+ = G+) is computationally expensive Good news:
Canonical Cover algorithm: given a set of FD, F, finds minimal FD
set equivalent to F Minimal: cant find another equivalent FD set w/
fewer FDs
Slide 27
FD so far... 1. Canonical Cover algorithm result (Fc)
guaranteed to be the minimal FD set equivalent to F 2. Closure
Algorithms a. Armstrongs Axioms: more common use: test for
extraneous attributes in C.C. algorithm b. Attribute closure: more
common use: test for superkeys 3. Purposes a. minimize the cost of
global integrity constraints so far: min gics = |Fc| In fact....
Min gics = 0 (FDs for normalization)
Slide 28
Another use of FDs: Schema Design Example: R = R: Universal
relation tuple meaning: Jones has a loan (L-17) for $1000 taken out
at the Downtown branch in Bkln which has assets of $9M Design: + :
fast queries (no need for joins!) - : redudancy: update anomalies
examples? deletion anomalies