1. CPSC 603 Database Systems Lecturer: Laurie Webster II, M.S.S.E., M.S.E.E., M.S.BME, Ph.D., P.E. Lecture 5 Introduction to a First Course in Database Systems

2. Referential Integrity R 1  referencing relation R 2  referenced relation A set of attributes FK  R 1 and PK  R 2 => foreign key of schema R 1 that reference relation R 2 if : dom (FK) = dom (PK), FK = foreign key PK = primary key R1 = EMPLOYEE relation R2 = DEPARTMENT relation

3. Referential Integrity t 1 (DNO) = t 2 (DNUMBER) ==> t 1 [FK] = t 2 [PK] R 1 A 1...... …..................DNO A n t 1 v. t m R 2 A 1..... DNUMBER........... A n t 1 t 2 v. t m

4. Functional Dependencies Informal criteria for good and bad relation schemas Semantics of the attributes Reducing the redundant values in tuples Reducing the null values in tuples Disallowing the possibility of generating spurious tuples Formal criteria for good and bad relation schemas –The single most important concept in relational schema design is the FD (functional dependency) –We will formally define the concept

5. Relation Schema and Database R (A 1, A 2, ….., A n ) ==> relation schema r(R) = {t 1, t 2, …….., t m } ==> instance of a relation ==> database Relational Database Schema => S S = {R 1, R 2, …….., R m } ==> with integrity constraints (IC) A relational Database state(instance) DB DB = {r 1 (R 1 ), r 2 (R 2 ), ……, r m (R m )} = {r 1, r 2, …., r m }

6. Functional Dependencies A functional dependency (FD) is a constraint between two sets of attributes from the database A FD on a relation R is a statement of the form: –“If two tuples of R agree on attributes A 1, A 2, …., A n (I.e, the tuples have same values in their respective components for each of these attributes) then they must also agree on another attribute B.”

7. Functional Dependencies A Functional Dependency (FD), denoted by    between two sets of attributes  and  that are subsets of R specifies a constraint on the possible tuples that can form a relation state r (R). The constraint => any two tuples t 1 and t 2 in r that have t 1 [X] = t 2 [X], we must also have t 1 [Y] = t 2 [Y].

8. Functional Dependencies The constraint => any two tuples t 1 and t 2 in r that have t 1 [X] = t 2 [X], we must also have t 1 [Y] = t 2 [Y] ==> values of the Y component of a tuple in r depend on, or are determined by, the values of the X component; or alternatively, the values of the X of a tuple uniquely (or functionally) determine the values of the Y component.    ==> Functional depedency from X to Y or that Y is functional dependent (FD) on X.

9. Functional Dependencies X functional determines Y in a relation schema R if and only if, whenever two tuples of r(R) agree on their X-value, they must necessarily agree on their Y-value –“If two tuples of R agree on attributes A 1, A 2, …., A n (I.e, the tuples have same values in their respective components for each of these attributes) then they must also agree on another attribute B.” – We write this FD formally as A 1, A 2, …., A n  B and say that A 1, A 2, …., A n functionally determine B

10. Functional Dependencies If a set of attributes A 1, A 2, …., A n functionally determines more than one attribute, say A 1, A 2, …., A n  B 1 A 1, A 2, …., A n  B 2 ……. A 1, A 2, …., A n  B m We can write this set of FD’s as A 1, A 2, …., A n  B 1 B 2 …...Bm

11. Functional Dependencies A functional dependency is a property of the SEMANTICS or MEANING OF THE ATTRIBUTES Whenever the semantics of two sets of attributes in R indicate that a functional dependency should hold, we specify the dependency as a constraint Relation extensions r(R) that satisfy the FD constraints are called legal extensions (or legal relation states) of R, because they obey the FD constraints

12. Functional Dependencies The main use of FDs is to describe further a relation schema R by specifying constraints on its attributes that must hold at all times A FD is a property of the relation schema (intension) R, not of a particular legal relation state (extension) r(R) FD cannot be inferred automatically from a given relation extension r but must be defined explicitly by someone who knows the semantics of the attributes of R

13. Functional Dependencies titleyearfilmType Relation Movies with star Information lengthstudioNamestarName Star Wars 1977 124 color Fox Carrie Fisher Star Wars 1977 124 color Fox Mark Hamilton Star Wars 1977 124 color Fox Harrison Ford Mighty D. 1991 104 color Disney Emilio Estevez Wayne’s W. 1992 95 color Paramount Dana Carvey Wayne’s W. 1992 95 color Paramount Mike Meyers

14. Functional Dependencies Let us consider the relation Movies from the previous slide: Movies(title, year, length, filmType, studioName, starName) There are several FD’s that we can reasonably assert about the Movies relation: title year  length title year  filmType title year  studioName

16. Functional Dependencies Relation Movies with star Information Star Wars 1977 124 color Fox Carrie Fisher Star Wars 1977 124 color Fox Mark Hamilton Star Wars 1977 124 color Fox Harrison Ford Mighty D. 1991 104 color Disney Emilio Estevez Wayne’s W. 1992 95 color Paramount Dana Carvey Wayne’s W. 1992 95 color Paramount Mike Meyers titleyearlength filmTypestudioNamestarName

17. Functional Dependencies Informal Guideline 1: Design R i so that it is easy to explain its meaning. Do not combine attributes from multiple entity types and relationship types into a single relation. Intuitively, if R i corresponds to one entity type are one relationship type, the meaning (semantics) tends to be clear. Otherwise, R i corresponds to a mixture of multiple entities and relationships and hence becomes semantically unclear.

18. Functional Dependencies Informal Guideline 2: Design the base relation schemas sot that no insertion, deletion, or modification anomalies are present in the relations. If any anomalies are present, note them clearly and make sure that the programs that update the database will operate correctly.

19. Functional Dependencies Informal Guideline 3: As far as possible, avoid placing attributes in a base relation whose values may frequently be null. If nulls are unavoidable, make sure that they apply in exceptional cases only and do not apply to a majority of tuples in the relation.

20. Functional Dependencies Informal Guideline 4: Design R i ’s so that they can be JOINed with equality conditions on attributes that are either primary keys or foreign keys in a way that guarantees that no spurious tuples are generated. Do not have relations that contain matching attributes other than foreign key-primary key combinations. If such relations are unavoidable, do not join them on such attributes, because the join may produce spurious tuples.

21. Normalization Having studied functional dependencies and some of their properties, we are now ready to use them as information about the semantics of R i s. We assume that a set of FDs is given for each R i, and that each R i has a designated primary key THIS INFORMATION COMBINED WITH THE TESTS (CONDITIONS) FOR NORMAL FORMS DRIVES THE NORMALIZATION PROCESS

22. Introduction to Normalization Historically: The normalization process, as first proposed by Dr. Codd (1972a), takes R i through a series of tests to “certify” whether it satisfies a certain normal form (?NF). Relational Design by Analysis!! ==> proceeds in a top-down fashion evaluating each against the criteria for normal forms and decomposing relations as necessary.

23. Normalization Initially, Codd proposed three normal forms, which he called: a) first normal form (1NF) b) second normal form (2NF) c) third (3NF) Later: A stronger definition of 3NF (Boyce-Codd normal form (BCNF) was proposed All are based on FDs among the attributes of R i

24. Normalization Even later: 4NF and 5NF was proposed based on the concepts of : a)multivalued dependencies b)join dependencies, respectively Normalization of data => process of analyzing the given R i based on their FDs and PKs to achieve the desirable properties of : 1)minimizing redundancy 2)minimizing the insertion, deletion, and update anomalies

25. Normalization Unsatisfactory R i s that do not meet certain conditions - the normal form tests - are decomposed into smaller R i s that meet the tests and hence possess the desirable properties as guaranteed by the normalization test. Normalization procedure provides the database designers with: *A formal framework for analyzing based on their keys and on the FDs among their attributes *A series of NF test tha can be carried out on individual so that the relational database can be normalized to any desired degree

26. Next Lecture Functional Dependencies Closing Sets Normalization Keys of Relations Normalization