1. Information Resources Management February 13, 2001

2. Agenda n Administrivia n Ternary Cardinality (revisited) n The Relational Model n Converting an E-R Model to a DB n Exam Review

3. Administrivia n Homework #3 n Exam #1, next week 2/20

4. Ternary Relationships - Cardinality n For the entity in question, n For each unique pair of the other entities, n How many of the entity can there be? n One n More than one (many)

5. Ternary Cardinality AB C Has For each unique B/C pair, how many A’s?

6. Ternary Cardinality AB C Has For each unique B/C pair, how many A’s?

7. Example (one-to-one-to-one): Employee is assigned a phone number for a project. A phone number is used only for that employee and project.

8. Example ( one-to-one-to-one): EmployeeProject Phone Number Has Employee is assigned a phone number for a project. A phone number is used only for that employee and project. For each project/phone# pair, how many employees?

9. Example ( one-to-one-to-one): EmployeeProject Phone Number Has Employee is assigned a phone number for a project. A phone number is used only for that employee and project. For each project/employee pair, how many phone numbers?

10. Example ( one-to-one-to-one): EmployeeProject Phone Number Has Employee is assigned a phone number for a project. A phone number is used only for that employee and project. For each employee/phone# pair, how many projects?

11. Example ( one-to-one-to-one): EmployeeProject Phone Number Has Employee is assigned a phone number for a project. A phone number is used only for that employee and project.

12. Example (one-to-one-to-many): Employee assigned to a project works at one location for that project but can work at different locations for different projects. At a location an employee only works on one project, but there can be many employees working on that same project.

13. Example (one-to-one-to-many): EmployeeProject Location Has

14. Example (one-to-many-to-many): Employee on a project has one manager. Manager can manage several projects. Each project has one manager. Manager can manage the same employee on different projects.

15. Example (one-to-many-to-many): EmployeeProject Manager Has

16. Example (many-to-many-to-many): Employees use many skills on many projects and each project has many employees with varying skills.

17. Example (many-to-many-to-many): EmployeeProject Skill Has

18. The Relational Data Model n Components n E-R Models to Relations

19. Relational Data Model Components n Data structure n Data manipulation n Data integrity

20. Data Structure n Tables with rows and columns n Two-dimensional n Column – Attribute n Row – single instance of an entity – each is unique n Sequence is immaterial (rows or columns)

21. Data Structure – Alternative Table-Relation Row-Tuple Column-Attribute (domain – all possible values)

22. Database Schema – Definition n For each table/relation: Name = (attribute, attribute, attribute, …) n Example: Employee = (employee_ID, name, dept#, phone#) Department = (dept#, dept_name)

23. Keys n Attributes can be either identifiers or descriptors. n Identifier uniquely determines an instance of an entity. n Identifier is a key.

24. Types of Keys n Superkey - any combination of attributes that uniquely determines each instance of the entities in an entity set n Candidate Key - superkey for which no proper subset is also a superkey n Primary Key - selected candidate key used to identify each row (tuple)

25. Types of Keys Superkeys  Candidate Keys  Primary Key Primary key Candidate keys Superkeys

26. Composite Key n Key that consists of more than one attribute. n Example: first name and last name

27. Example: Course (course#, name, dept#, location, time) Superkeys? Candidate Keys? Primary Key?

28. Database Schema (Updated) n Underline primary key(s) Name = (key, attribute, attribute, attribute, …) n Example: Employee = (employee_ID, name, dept#, phone#) Department (dept#, dept_name)

29. Foreign Keys n Attribute in a relation that serves as the primary key of another relation in the same database. n Used to maintain database integrity – can’t sell a product that isn’t in the inventory, etc.

30. Database Schema (Updated) n Dashed underline foreign key(s) Name = (key, attribute, attribute (FK), attribute, …) n Example: Employee = (employee_ID, name, dept#, phone#) Department (dept#, dept_name) n Could also use double underline (PK)

31. Multivalued Attributes n Attributes that repeat (once or more) for a single entity. n Enclosed in braces {} Name = (key, attribute, attribute (FK), {attribute, attribute}, …) n Example: Employee = (employee_ID, name, dept#, {phone#, type}) Department (dept#, dept_name)

32. Converting an E-R Model to a Database Schema 1.Strong Entities become Relations n Identify the primary key from the superkeys and candidate keys.

33. Converting an E-R Model to a Database Schema 2. Weak Entities become Relations n The primary key of a weak entity will usually have to include the primary key of the relation on which the weak entity depends along with additional identifying information for the weak entity.

34. Converting an E-R Model to a Database Schema 3. Binary, Ternary, and n-ary Relationships n one-to-one or one-to-many Identify foreign keys n many-to-many or associative entities Build a “bridge” relationship whose primary key is a composite key composed of all the relationship’s entities primary keys. These are also foreign keys.

35. Converting an E-R Model to a Database Schema 4. Unary Relationships n one-to-one or one-to-many Identify “recursive” foreign key n many-to-many Build a “bridge” relationship whose primary key is a composite key composed of two copies of the entity’s primary key.

36. Converting an E-R Model to a Database Schema 5. Supertype/Subtype - Option 1 n Create separate relations for the supertype and each subtype n Supertype contains all common attributes and the primary key n Subtypes have the same primary key as the supertype and only those attributes specific to that subtype n Add to the supertype a subtype indicator. Only one indicator is needed for disjoint. More that one is needed if overlapping. If there is no completeness constraint, allow the indicator to be null.

37. Converting an E-R Model to a Database Schema 5. Supertype/Subtype - Option 2 n Create a separate relation for each subtype only n Subtypes have overlapping attributes (those that are common and would have been put in the relation for the supertype if it was created) n If the primary key of the supertype is used as a foreign key in other relations beyond the subtypes, a primary key only relation for the supertype will need to be created.

38. Converting an E-R Model to a Database Schema 5. Supertype/Subtype - Option 3 n Create one relation n Attributes in this relation are a superset created from the attributes for the supertype and all subtypes. (Null values must be permitted for the subtype attributes as only a few are used for any given tuple.)

39. Example n Banking

40. Exercise: n Real Estate Office

41. Homework #4 n Convert E-R Diagram to Schema n Identify n Primary keys (may be composite) n Foreign keys n Dashed underline (not in PK) n Double underline (in PK)

42. Exam Review n DBMS - usage & alternatives n Methodologies and people n E-R Modeling n Entity (strong, weak, associative) n Relationships (degree, cardinality, connectivity, existence) n Gen/Spec