Referential Integrity and Other Table Constraints Ray Lockwood

Size: px

Start display at page:

Download "Referential Integrity and Other Table Constraints Ray Lockwood"

Blake Burns
5 years ago
Views:

1 DDL Referential Integrity and Other Table s Pg 1 Referential Integrity and Other Table s Ray Lockwood Points: Referential Integrity assuring tables remain properly linked by primary and foreign keys. Referential Integrity s are rules governing the interaction between tables that are linked to each other. The Foreign Key is the most important referential integrity constraint. The database can automatically enforce referential integrity constraints. These and other constraints are set in the CREATE TABLE or ALTER TABLE statements. Problem of Broken Links Linking tables together implies limitations. Suppose we try to add a FamilyMember to a non-existent Employee. We can add a row to the FamilyMember table and set the EmployeeNum attribute to some number, but should we? Should the system prevent a FamilyMember s row from being added if the proposed value of the foreign key is not in the Employee table? What happens to an Employee s FamilyMembers if we delete the Employee? Do we permit deleting the row for EmployeeNum 014 in the Employees table if there are rows in the FamilyMember table with the foreign key value 014? Referential Integrity These are questions about referential integrity the coordinated handling of tables linked together by primary and foreign keys. To answer these questions, a database designer must consult the users of the database to see how the real world acts, and to model it accordingly. Referential Integrity means making sure that all the foreign key values in a child table point to valid primary key values in a parent table. There shouldn't be a value in the foreign key attribute of a child row without that same value appearing in the primary key attribute of a row in the parent table. A child row without a parent is an orphan, and is a violation of referential integrity. Referential integrity means making sure that a foreign key always points to a valid primary key value. A table on the many side of a 1:M relationship is the table that has the foreign key. It s called a Child Table. A Referential Integrity Violation is a child row without a parent. An unlinked row that has an invalid value in its foreign key column. Children without parents are called orphans.

2 DDL Referential Integrity and Other Table s Pg 2 A Database Automatically Enforces Referential Integrity It's possible to prevent orphans by carefully using SQL statements and application code. But mistakes happen, so this isn't a sure-fire way to preserve referential integrity. A way to guarantee referential integrity is to let the database server enforce it. All we have to do is to tell the database which attributes are foreign key attributes, and what primary keys they point to. This is done in the CREATE TABLE or ALTER TABLE statements. Referential Integrity s Careful handling of the data is no substitute for establishing referential integrity constraints. Enforcement of referential integrity is a free service that the database does for you behind the scenes. A rule that coordinates the handling of linked tables is a Referential Integrity. This is a type of business rule embedded into the schema (the definition of the tables). The purpose of a referential integrity constraint is to avoid inappropriately linked (or inappropriately unlinked) rows in 1:1 and 1:M relationships. This is vital when a weak entity is involved, such as an Employee s FamilyMembers. Referential Integrity Enforcement Actions Automatic constraint enforcement is in keeping with the declarative, nonprocedural nature of relational databases There are three standard ways to enforce referential integrity. Prevent an action from occurring that would create an orphan. Perform the same action on children as on the parent (cascading). Attach a would-be orphan to a new parent. These actions can be defined to be automatic. Referential Integrity Enforcement Actions 1. Set the foreign key to a default value: When deleting a parent row, replace the foreign key value of any child rows with a default value such as NULL. Also do this when adding a child when no parent exists. 2. Prevent deleting a parent: Prevent deleting a parent row when there are corresponding child rows. 3. Prevent adding a child: Prevent adding a child row when there is no corresponding parent row. 4. Cascading Delete: When deleting a parent row, also delete the corresponding child rows. 5. Cascading Update: When changing the primary key value of a parent row, also change the corresponding foreign key values of the child rows. (The definition of a primary key includes unchangeability, but we can fudge).

3 DDL Referential Integrity and Other Table s Pg 3 You define referential integrity constraints in the CREATE TABLE or the ALTER TABLE statements. All database management systems have features that automatically enforce these constraints. Referential integrity enforcement is automatic once you define the constraints. Referential Integrity Statements You define referential integrity constraints either in The CREATE TABLE statement when you initially create the table. The ALTER TABLE statements after the table exists. Five Types of Referential Integrity s on a Table 1. PRIMARY KEY Defines the primary key attribute 2. UNIQUE Defines candidate key attributes 3. NULL / NOT NULL Allows or disallows an attribute to take the NULL value (NULL is the default) 4. CHECK Defines data constraints 5. Referential Integrity f. FOREIGN KEY (Table form) Referential integrity constraint g. REFERENCES (Column form) Referential integrity constraint FOREIGN KEY and REFERENCES are two variations of the same constraint.

4 DDL Referential Integrity and Other Table s Pg 4 Table Form of Table name Attributes & Data types Indexes s Table Form of Primary Key constraint (preferred) Table name Attributes & Data types s Table Form of Foreign Key constraint (preferred) CREATE TABLE Employee( employeeid fname lname hiredate login INDEX INDEX int NOT NULL, date, char(8) NOT NULL UNIQUE, (lname), (login), CONSTRAINT EmployeePK PRIMARY KEY (EmployeeID), CONSTRAINT logincheck CHECK (length(login)=8) ); CHECK limits the domain of an attribute. The length of login must be eight characters. CREATE TABLE FamilyMember( empid depid fname lname int NOT NULL, int NOT NULL AUTO_INCREMENT, CONSTRAINT deppk PRIMARY KEY (empid,depid), CONSTRAINT depfk FOREIGN KEY (empid) ); name name ON DELETE CASCADE ON UPDATE CASCADE type Primary keys are always NOT NULL String function Primary keys are always NOT NULL type Column names Actions to take if primary key is changed. Primary key attribute The UNIQUE constraint creates an Alternate (i.e. Candidate) Key. If we know we ll be searching or printing in order by a column, then we can keep an index for it. MySQL-specific keyword to implement a surrogate key. empid isn't needed to make this key unique. depid is unique by itself because it's an autoincrement. I wanted this example to be in keeping with our previous ID-dependent examples. Name of the foreign key attribute Name of the primary key the parent table. Both a key and an index are a binary tree of column values, with pointers to the corresponding rows in the table. The Table form is preferred because it: 1. Improves documentation. 2. Gives the constraints names so we can change them later. You must create the parent table before defining child tables. Otherwise you will get an error on the Foreign Key constraint. Column Form of Table name Attributes, Data types, & s Column Form of Foreign Key constraint (shorter, but not preferred) CREATE TABLE DocumentCheckOut( Column form of Primary Key docchkoutid int NOT NULL PRIMARY KEY, empid int NOT NULL, documented int NOT NULL REFERENCES Document(documentID) ); s made using the Column Form can't be named, so there is no way to drop and re-add them later.

5 DDL Referential Integrity and Other Table s Pg 5 Enforcement There are two automatic enforcements that a foreign key constraint can perform: Cascade a change Prevent a change. Cascade Changes Here is the CONSTRAINT line from the above CREATE statement. It creates a foreign key constraint named depfk: name type Foreign key column Cascading changes lets you cheat on the rule that primary keys are unchangeable. Keywords CONSTRAINT depfk FOREIGN KEY (empid) ON DELETE CASCADE ON UPDATE CASCADE Enforcement Actions Parent table Parent key referred to ON DELETE CASCADE automatically deletes the child row if the parent row is deleted. ON UPDATE CASCADE automatically changes the value of the foreign key in the child if the primary key value in the parent is changed. Both of these actions prevent orphans. The CASCADE actions are performed on the child table. Prevent Changes (No Action) We can also prevent changes from being made to the key of a parent row if children are linked by a foreign key: CONSTRAINT depfk FOREIGN KEY (empid) ON DELETE NO ACTION ON UPDATE NO ACTION ON DELETE NO ACTION disallows deleting a parent row if children exist. ON UPDATE NO ACTION disallows changing the key value of a parent row if children exist. The NO ACTION mandate is directed at the parent table. NO ACTION is the default NO ACTION doesn t mean don t do anything. It means Don t let the key of the parent row change if there are children.

6 DDL Referential Integrity and Other Table s Pg 6 Changing Existing s Why is the table form of constraint preferred over the column form? When using the table form, we give the constraint a name so we can change it later. We can t actually change a constraint; we have to drop it and add a new one back again. ALTER TABLE FamilyMember DROP CONSTRAINT depfk; ALTER TABLE FamilyMember ADD CONSTRAINT depfk FOREIGN KEY (empid) ON DELETE NO ACTION ON UPDATE NO ACTION; s must have unique names. We had to DROP and then ADD the whole constraint to change CASCADE to NO ACTION. You can t ALTER a constraint. You ALTER the table to DROP the constraint, then re-add it.

Fundamentals, Design, and Implementation, 9/e Copyright 2004 Database Processing: Fundamentals, Design, and Implementation, 9/e by David M.

Chapter 5 Database Design Elements of Database Design Fundamentals, Design, and Implementation, 9/e Chapter 5/2 The Database Design Process Create tables and columns from entities and attributes Select