MIS 3053 Database Design And Applications The University Of Tulsa Professor: Akhilesh Bajaj Normal Forms Lecture 1 © Akhilesh Bajaj, 2000, 2002, All Rights Reserved.

Goals Today Learn about integrity constraints - domain constraints - referential integrity Learn about functional dependencies - Definition - Armstrong’s axioms - 3 additional rules - Closure of an attribute set (useful in computing super keys and candidate keys)

Integrity Constraints Rules that ensure that the data in the database faithfully represents the real world. Information in the real world follows rules that make it consistent. Data should follow these rules also. Examples of Rules A class A employee cannot make less than a class B employee All salaries must be over the minimum wage An employee has one and only one manager.

Integrity Constraints One way of ensuring data integrity is to trust the end-users to always input correct data. E.g., The data operator will make sure when they input data, that everyone makes minimum wage at least, and that every employee has one and only one manager. This is a bad idea! All it needs is a few bad data items to mess up queries & reports. All database management systems provide some support for managing automated checking of integrity constraints. The basic idea is that the database designer puts checks and balances into the design, so as to ensure, as far as possible, the integrity of the data at any point in time.

Integrity Constraints Domain Constraints: The CHECK clause in SQL-92 allows the designer to specify that the values (of each row) in a column of a table need to follow certain conditions. E.g.,..... CONSTRAINT wage-value-test CHECK(VALUE>=5.25)..... CONSTRAINT account-type-test CHECK(VALUE IN (‘Checking’, ‘Saving’)).

Integrity Constraints Referential Integrity This type of constraint ensures that a value that appears in one column must also appear in another column (of another table). Used when there are common columns across tables. E.g., An r_ssn value cannot show up in the area_edits table, unless it already exists in the researchers table. This implies that the r_ssn column in the area_edits table is referentially dependent on the column in the researchers table.

Integrity Constraints Referential Integrity Consider the referential integrity of r_ssn in area_edits table and researchers table. We say that the r_ssn in the area_edits table is a foreign key, dependent on the r_ssn in the researchers table. Foreign keys are usually dependent on columns that are primary keys in the other table. Note that the foreign key can also be the primary key (or part of the primary key) in its own table. This is the case with r_ssn in area_edits.

Integrity Constraints Referential Integrity What happens if we insert a new row in the area_edits table? What happens if we delete a row in the researchers table? What happens if we delete a row in the area_edits table? What happens if we update a value of r_ssn in the area_edits table?

Integrity Constraints Support in SQL: The PRIMARY KEY clause in SQL tells the DBMS to treat a column (or maybe many columns) as the primary key for that table. Note that the primary key is always unique and non-null. The FOREIGN KEY clause in SQL tells the DBMS to treat the column as a foreign key, referencing another table. In addition, there is a UNIQUE clause that tells the DBMS that all values in a column must be unique. The NOT NULL clause tells the system that NULL values are not allowed in the column.

Functional Dependencies If the values in a column, or columns, functionally determine the values in another column, or columns, then a functional dependency exists between the first set of columns and the second. We use the --> operator to indicate that the Right Hand Side (RHS) is functionally dependent on the Left Hand Side (LHS). Example: r_ssn --> r_name, r_address, r_phone, r_institution is a FD on the researchers table. Functional dependencies exist ON a table (NOT ACROSS TABLES).

Functional Dependencies Functional dependency implies that if the same values occur on the LHS, then the same value will occur on the RHS. Note: If this sounds confusing, review the mathematical definition of a function. r_ssn --> r_name, r_address, r_phone, r_institution A superkey of a table is a column, or columns, such that the entire table (all columns) are functionally dependent on this column, or columns. Thus, the following holds on all tables: Superkey --> ALL columns of table. Recall that, for each table, candidate keys are a subset of all the superkeys of that table. Also, the primary key is an element of the set of candidate keys for the table. What does this say about candidate and primary keys?

Functional Dependencies Some examples of FDs in the POP schema:

Functional Dependencies Armstrong’s Axioms Reflexivity rule If RHS is a subset of LHS, then always LHS--> RHS. E.g., r_name, r_address --> r_name Augmentation Rule Adding the same columns to both sides is allowed. E.g.,r_ssn, art_num --> r_name, r_institution,art_num Transitivity Rule If A--> B and B--> C then A--> C. E.g., r_ssn-->r_name and r_name-->r_phone implies that r_ssn --> r_phone

Functional Dependencies Some theorems that come out of the Axioms Union Rule: If A --> B and A--> C, then A --> BC. Proof: Decomposition Rule: IF A --> BC then A --> B and A --> C. Proof:

Functional Dependencies Some theorems that come out of the Axioms Pseudotransitivity Rule: If A-->B and BC-->D then AC-->D. Proof: Notes: 1. AB --> CD DOES NOT IMPLY that A-->CD OR that B-->CD So we can split the RHS, but not the LHS. 2. A superkey functionally determines all the attributes of a table.

Functional Dependencies Closure of Attribute Sets: Used to test whether a set of columns is a superkey or not, for a table. The closure of a column, or columns, is all the columns in the table that are functionally determined by that column or columns. The closure of a superkey is all the columns of the table. Simple algorithm to find the closure, for, say, attributes A and B (“attributes” is the same as “columns”): result := AB WHILE(changes to result) DO FOR EACH FD on the table IF LHS in result, then result := result + RHS ENDFOR ENDWHILE

Functional Dependencies Examples from the POP schema: