2. Relational Model & Normalization Relational terminology Anomalies and the need for normalization Normal forms Relation synthesis De-normalization

3. Why the Relational Model? General model DBMS-independent design Widely used in DBMS products But we must deal with anomalies

4. Relational Terminology

5. Relation: schema or structure versus instance EMPLOYEE(Name, Age, Sex, EmployeeNumber)

6. When is a table a relation? Single value cells - no repeating groups or arrays Each attribute has unique name All values in a column are of same kind Order of columns is not significant No identical rows Order of rows is not significant

7. Approaches to Relation Design Analysis –start with table structure and normalize (eliminate anomalies) –Entity Relationship Model (3rd Normal) Synthesis –construct relations from attributes

8. Basic Concepts Functional Dependency –relationship between or among attributes Key –group of one or more attributes that uniquely identifies a row

9. Functional Dependency Y is functionally dependent on X if value of X determines value of Y –if we know the value of X, we can obtain (look up, compute,…) the value for Y –determined by user model and business rules

10. Functional Dependency Example StudentIDStudentName determinant

11. Functional Dependency Notation X  (Y,Z) (X,Y)  Z

12. Keys Single or group attributes Depend on user model Example: why {SID,Activity}? Is there another option?

13. Functional Dependencies, Keys and Uniqueness Key is always unique Key functionally determines entire row Determinant need not be unique, hence is not necessarily a key Example: Activity  Fee

14. Reality check ProjectID  EmployeeName? ProjectID  EmployeeSalary? (ProjectID, EmployeeName)  EmployeeSalary? EmployeeName  EmployeeSalary? EmployeeSalary  ProjectID? EmployeeSalary  (ProjectID, EmployeeName)? What is the key?

15. Normalization Modification Anomalies Referential Integrity Constraint Normal Forms “A relation should have a single theme; if it has more, break it into more relations.” Golden Rule: “A relation should have a single theme; if it has more, break it into more relations.”

16. Modification Anomalies What happens when you want to –add a new book? –change the address of a patron? –delete a patron record?

17. Modification Anomalies Deletion anomaly –deleting one fact about an entity deletes a fact about another entity Insertion anomaly –cannot insert one fact about an entity unless a fact about another entity is also added Update anomaly –changing one fact about an entity requires multiple changes to a table

18. Referential Integrity Constraint When we split a relation, we must pay attention to the references across the newly formed relations E.g., a book must exist before it can be checked out: –CHECKOUT [BookID]  BOOK [BookID] The DBMS or the applications will have to check/enforce constraints

19. Classification of relations All relations

20. Second Normal Form Single attribute key, or all non-key attributes are dependent on the entire key –ACTIVITY(SID, Activity, Fee)

21. Third Normal Form No transitive dependencies –WORKER(Employee, Dept, Location) –WORKER(Employee, Dept) OFFICE(Dept, Location)

22. Quick Quiz Determine if the following relations are in 1NF, 2NF or 3NF Rewrite each relation in 3NF –EMPLOYEE (EmpID, EmpName, JobCode) –EMPLOYEE(EmpID, EmpName, JobCode, JobDesc) –EMPLOYEE(EmpID, EmpName, ProjectID, HrsWorked)

23. Boyce-Codd Normal Form Every determinant is a candidate key –ADVISER(SID,Major,Fname) –STU-ADV(SID,Fname) ADV-SUBJ(Fname,Subject)

24. Multi-valued Dependency Two or more functionally independent multi- valued attributes are dependent on another attribute –EMPLOYEE(Name,Dependent,Project) Data redundancy and modification anomalies 4NF: BCNF & no multi-valued dependencies –EMPLOYEE(Name,Dependent) –EMPLOYEE(Name, Project)

25. Domain/Key Normal Form Every constraint on the relation is a logical consequence of the definitions of keys and domains Constraints: rules, functional and multi- valued dependencies, anything that can be statically ascertained as true or false Enforcing key and domain restrictions causes all of the constraints to be met

26. Summary of Normal Forms

27. De-Normalization Many databases are not normalized or poorly normalized implying bad design We may also want to de-normalize to improve efficiency or ease of use Consider the alternatives: –CUSTOMER(CustNo, CustName, City, State, Zip) –CUSTOMER(CustNo, CustName, Zip) CODES(Zip, City, State)

28. Optimization There may be more than one way to normalize a table –COLLEGE(CollegeName, Dean, AsstDean) »DEAN(CollegeName, Dean) ASSTDEAN(CollegeName, AsstDean) »COLLEGE (CollegeName, Dean, AsstDean1, AsstDean2, AsstDean3) Which is best depends on efficiency considerations

29. Synthesis