1. The Relational Model Chapter Two

2. 2 Chapter Objectives Learn the conceptual foundation of the relational model Learn the conceptual foundation of the relational model Understand how relations differ from nonrelational tables Understand how relations differ from nonrelational tables Learn basic relational terminology Learn basic relational terminology Learn the meaning and importance of keys, foreign keys, and related terminology Learn the meaning and importance of keys, foreign keys, and related terminology Understand how foreign keys represent relationships Understand how foreign keys represent relationships

3. 3 Chapter Objectives (continued) Learn the purpose and use of surrogate keys Learn the purpose and use of surrogate keys Learn the meaning of functional dependencies Learn the meaning of functional dependencies Learn to apply a process for normalizing relations Learn to apply a process for normalizing relations

4. 4 Entity An entity is something of importance to a user that needs to be represented in a database An entity is something of importance to a user that needs to be represented in a database An entity represents one theme or topic An entity represents one theme or topic In an entity-relationship model (discussed in Chapter 4), entities are restricted to things that can be represented by a single table In an entity-relationship model (discussed in Chapter 4), entities are restricted to things that can be represented by a single table

5. 5 Relation A relation is a two-dimensional table that has specific characteristics A relation is a two-dimensional table that has specific characteristics The table dimensions, like a matrix, consist of rows and columns The table dimensions, like a matrix, consist of rows and columns

6. 6 Characteristics of a Relation Rows contain data about an entity Rows contain data about an entity Columns contain data about attributes of the entity Columns contain data about attributes of the entity Cells of the table hold a single value Cells of the table hold a single value All entries in a column are of the same kind All entries in a column are of the same kind Each column has a unique name Each column has a unique name The order of the columns is unimportant The order of the columns is unimportant The order of the rows is unimportant The order of the rows is unimportant No two rows may be identical No two rows may be identical

7. 7 A Sample Relation EmployeeNumberFirstNameLastName 100MaryAbermany 101JerryCaldera 104AleaCopley 107MuruganJacksoni

8. 8 A Nonrelation Example EmployeeNumberPhoneLastName 100335-6421,454-9744Abermany 101215-7789Caldera 104610-9850Copley 107299-9090Jacksoni Cells of the table hold multiple values

9. 9 EmployeeNumberPhoneLastName 100335-6421Abermany 101215-7789Caldera 104610-9850Copley 100335-6421Abermany 107299-9090Jacksoni No two rows may be identical A Nonrelation Example

10. 10 A Sample Relation

11. 11 A Nonrelation Example

12. 12 A Nonrelation Example

13. 13 A Sample Relation

14. 14 Terminology TableRowColumn File or Datafile RecordField RelationTupleAttribute Synonyms…

15. 15 A Key A key is one (or more) columns of a relation that is (are) used to identify a row A key is one (or more) columns of a relation that is (are) used to identify a row

16. 16 Uniqueness of Keys Unique Key Nonunique Key Data value is unique for each row. Consequently, the key will uniquely identify a row. Data value may be shared among several rows. Consequently, the key will identify a set of rows.

17. 17 A Composite Key A composite key is a key that contains two or more attributes A composite key is a key that contains two or more attributes For a key to be unique, often it must become a composite key For a key to be unique, often it must become a composite key

18. 18 Composite Key Example To identify a family member, you need to know a FamilyID, a FirstName, and a Suffix (e.g., Jr.) To identify a family member, you need to know a FamilyID, a FirstName, and a Suffix (e.g., Jr.) The composite key is: The composite key is: (FamilyID, FirstName, Suffix) (FamilyID, FirstName, Suffix) One needs to know the value of all three columns to uniquely identify an individual One needs to know the value of all three columns to uniquely identify an individual

19. 19 A Candidate Key A candidate key is called “candidate” because it is a candidate to become the primary key A candidate key is called “candidate” because it is a candidate to become the primary key A candidate key is a unique key A candidate key is a unique key

20. 20 A Primary Key A primary key is a candidate key chosen to be the main key for the relation A primary key is a candidate key chosen to be the main key for the relation If you know the value of the primary key, you will be able to uniquely identify a single row If you know the value of the primary key, you will be able to uniquely identify a single row

21. 21 Relationship Notation EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone) DEPARTMENT (DeptName, BudgetCode, OfficeNumber)

22. 22 Specifying Primary Keys EMPLOYEE (EmployeeNumber, FirstName, LastName, Department, Email, Phone) DEPARTMENT (DeptName, BudgetCode, OfficeNumber)

23. 23 Relationships Between Tables A table may be related to other tables A table may be related to other tables For example For example An Employee works in a Department An Employee works in a Department A Manager controls a Project A Manager controls a Project

24. 24 A Foreign Key To preserve relationships, you may need to create a foreign key To preserve relationships, you may need to create a foreign key A foreign key is a primary key from one table placed into another table A foreign key is a primary key from one table placed into another table The key is called a foreign key in the table that received the key The key is called a foreign key in the table that received the key

25. 25 Foreign Key Example PROJECT ProjID ProjName MgrIDMANAGERMgrID MgrName Foreign Key Primary Key PROJECT (ProjID, ProjName, MgrID)MANAGER (MgrID, MgrName)

26. 26 DEPARTMENT DeptID DeptName LocationEMPLOYEEEmpID DeptID EmpName Foreign Key Primary Key Foreign Key Example DEPARTMENT (DeptID, DeptName, Location) EMPLOYEE (EmpID, DeptID, EmpName)

27. 27 Referential Integrity Referential integrity states that every value of a foreign key must match a value of an existing primary key Referential integrity states that every value of a foreign key must match a value of an existing primary key For example (see previous slide) For example (see previous slide) If EmpID = 4 in EMPLOYEE has a DeptID = 7 (a foreign key), a Department with DeptID = 7 must exist in DEPARTMENT If EmpID = 4 in EMPLOYEE has a DeptID = 7 (a foreign key), a Department with DeptID = 7 must exist in DEPARTMENT The primary key value must exist before the foreign key value is entered The primary key value must exist before the foreign key value is entered

28. 28 Referential Integrity EQUIPMENT (SerialNumber, Type, AcquisitionCost)

29. 29 EQUIPMENT (SerialNumber, Type, AcquisitionCost, EmployeeNumber) Suppose Equipment can be assigned to Employees. Primary key of EMPLOYEE is EmployeeNumber. Constraint: EmployeeNumber in EQUIPMENT must exist in EmployeeNumber in EMPLOYEE

30. 30 A Surrogate Key A Surrogate Key is a unique, numeric value that is added to a relation to serve as the Primary Key A Surrogate Key is a unique, numeric value that is added to a relation to serve as the Primary Key Surrogate Key values have no meaning to users and are usually hidden on forms, queries and reports Surrogate Key values have no meaning to users and are usually hidden on forms, queries and reports A Surrogate Key is often used in place of a composite primary key A Surrogate Key is often used in place of a composite primary key

31. 31 Surrogate Key Example If the Family Member Primary Key is FamilyID, FirstName, Suffix, it would be easier to append and use a surrogate key of FamMemberID If the Family Member Primary Key is FamilyID, FirstName, Suffix, it would be easier to append and use a surrogate key of FamMemberID FamilyID, FirstName and Suffix remain in the relation FamilyID, FirstName and Suffix remain in the relation Referential Integrity: Referential Integrity:Use… (FamMemberID) in School must exist in (FamMemberID) in School must exist in (FamMemberID) in FamilyMember Instead of: (FamilyID, FirstName, Suffix) in School must exist in (FamilyID, FirstName, Suffix) in FamilyMember

32. 32 Surrogate Key Example Landscaping company – has tables: PROPERTY (Street, City, State, Zip) PLANT (ItemNumber, VarietyName, Price) SERVICE (InvoiceNumber, Date, TotalHours)

33. 33

34. 34

35. 35 The Relationships A plant is sold for a particular property. A plant is sold for a particular property. A service is rendered for a particular property. A service is rendered for a particular property. PROPERTY (Street, City, State, Zip) PLANT (ItemNumber, VarietyName, Price, Street, City, State, Zip) SERVICE (InvoiceNumber, Date, TotalHours, Street, City, State, Zip)

36. 36 The Constraints (Street, City, State, Zip) in PLANT must exist in (Street, City, State, Zip) in PROPERTY (Street, City, State, Zip) in SERVICE must exist in (Street, City, State, Zip) in PROPERTY

37. 37 Fixing the Mess That’s a lot of duplication in each table. Let’s add surrogate keys to the tables. PROPERTY (PropertyID, Street, City, State, Zip) PLANT (ItemNumber, VarietyName, Price, PropertyID) SERVICE (InvoiceNumber, Date, TotalHours, PropertyID)

38. 38 The New Constraints PropertyID in PLANT must exist in PropertyID in PROPERTY PropertyID in SERVICE must exist in PropertyID in PROPERTY

39. 39

40. 40