1. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-1 COS 346 Day 6

2. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-2 Agenda Questions? Assignment Two is Due next class Assignment 3 Posted Due next Monday Feb 16 Assignment 4 will be posted later this week and will be due Feb 23 Quiz 1  Feb 23 –DP Chap 1-6(5?), SQL Chap 1 & 2 Capstone Proposals Due next Monday, Feb 16 –Must be a database related capstone –Capstone Project Description sp 09.htmCapstone Project Description sp 09.htm Begin Discussion on Data Modeling with the Entity- Relationship Model

3. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-3 David M. Kroenke’s Chapter Five: Data Modeling with the Entity-Relationship Model Part One Database Processing: Fundamentals, Design, and Implementation

4. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-4 The Data Model A data model is a plan, or blueprint, for a database design. A data model is more generalized and abstract than a database design. It is easier to change a data model than it is to change a database design, so it is the appropriate place to work through conceptual database problems.

5. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-5 E-R Model Entity-Relationship model is a set of concepts and graphical symbols that can be used to create conceptual schemas. Versions –Original E-R model — Peter Chen (1976). –Extended E-R model — Extensions to the Chen model. –Information Engineering (IE) — James Martin (1990); it uses “crow’s foot” notation, is easier to understand and we will use it. –IDEF1X — A national standard developed by the National Institute of Standards and Technology [see Appendix B] –Unified Modeling Language (UML) — The Object Management Group; it supports object-oriented methodology [see Appendix C]

6. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-6 Entities Something that can be identified and the users want to track –Entity class — a collection of entities of a given type –Entity instance — the occurrence of a particular entity There are usually many instances of an entity in an entity class.

7. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-7 CUSTOMER: The Entity Class and Two Entity Instances

8. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-8 Attributes Attributes describe an entity’s characteristics. All entity instances of a given entity class have the same attributes, but vary in the values of those attributes. Originally shown in data models as ellipses. Data modeling products today commonly show attributes in rectangular form.

9. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-9 EMPLOYEE: Attributes in Ellipses

10. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-10 EMPLOYEE: Attributes in Entity Rectangle

11. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-11 Identifiers Identifiers are attributes that name, or identify, entity instances. The identifier of an entity instance consists of one or more of the entity’s attributes. Composite identifiers: Identifiers that consist of two or more attributes Identifiers in data models become keys in database designs: –Entities have identifiers. –Tables (or relations) have keys.

12. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-12 Entity Attribute Display in Data Models

13. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-13 Relationships Entities can be associated with one another in relationships: –Relationship classes: associations among entity classes –Relationship instances: associations among entity instances In the original E-R model, relationships could have attributes but today this is no longer done. A relationship class can involve two or more entity classes.

14. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-14 Degree of the Relationship The degree of the relationship is the number of entity classes in the relationship: –Two entities have a binary relationship of degree two. –Three entities have a ternary relationship of degree three.

15. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-15 Binary Relationship

16. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-16 Ternary Relationship

17. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-17 Entities and Tables The principle difference between an entity and a table (relation) is that you can express a relationship between entities without using foreign keys. This makes it easier to work with entities in the early design process where the very existence of entities and the relationships between them is uncertain.

18. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-18 Cardinality Cardinality means “count,” and is expressed as a number. Maximum cardinality is the maximum number of entity instances that can participate in a relationship. Minimum cardinality is the minimum number of entity instances that must participate in a relationship.

19. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-19 Maximum Cardinality Maximum cardinality is the maximum number of entity instances that can participate in a relationship. There are three types of maximum cardinality: –One-to-One [1:1] –One-to-Many [1:N] –Many-to-Many [N:M]

20. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-20 The Three Types of Maximum Cardinality

21. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-21 Parent and Child Entities In a one-to-many relationship: –The entity on the one side of the relationship is called the parent entity or just the parent. –The entity on the many side of the relationship is called the child entity or just the child. In the figure below, EMPLOYEE is the parent and COMPUTER is the child:

22. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-22 HAS-A Relationships The relationships we have been discussing are known as HAS-A relationships: –Each entity instance has a relationship with another entity instance: An EMPLOYEE has one or more COMPUTERs. A COMPUTER has an assigned EMPLOYEE.

23. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-23 Minimum Cardinality Minimum cardinality is the minimum number of entity instances that must participate in a relationship. Minimums are generally stated as either zero or one: –IF zero [0] THEN participation in the relationship by the entity is optional, and no entity instance must participate in the relationship. –IF one [1] THEN participation in the relationship by the entity is mandatory, and at least one entity instance must participate in the relationship.

24. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-24 Indicating Minimum Cardinality As shown in the examples in a following slide: –Minimum cardinality of zero [0] indicating optional participation is indicated by placing an oval next to the optional entity. –Minimum cardinality of one [1] indicating mandatory (required) participation is indicated by placing a vertical hash mark next to the required entity.

25. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-25 Reading Minimum Cardinality Look toward the entity in question: –IF you see an oval THEN that entity is optional (minimum cardinality of zero [0]). –IF you see a vertical hash mark THEN that entity is mandatory (required) (minimum cardinality of one [1]).

26. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-26 The Three Types of Minimum Cardinality

27. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-27 Data Modeling Notation

28. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-28 Data Modeling Notation: ERwin

29. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-29 Data Modeling Notation: N:M and O-M Note that: (1) ERwin cannot indicate true minimum cardinalities on N:M relationships (2) Visio introduces the intersection table instead of using a true N:M model

30. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-30 ID-Dependent Entities An ID-dependent entity is an entity (child) whose identifier includes the identifier of another entity (parent). The ID-dependent entity is a logical extension or sub-unit of the parent: –BUILDING : APARTMENT –PAINTING : PRINT The minimum cardinality from the ID-dependent entity to the parent is always one. ID Dependant entity has a identifying relationship with parent (solid line)

31. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-31 ID-Dependent Entities A solid line indicates an identifying relationship

32. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-32 Weak Entities A weak entity is an entity whose existence depends upon another entity. All ID-Dependent entities are considered weak. But there are also non-ID-dependent weak entities. –The identifier of the parent does not appear in the identifier of the weak child entity.

33. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-33 Weak Entities (Continued) A dashed line indicates a nonidentifying relationship Weak entities must be indicated by an accompanying text box in Erwin – There is no specific notation for a nonidentifying but weak entity relationship

34. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-34 ID-Dependent and Weak Entities

35. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-35 Subtype Entities A subtype entity is a special case of a supertype entity: –STUDENT : UNDERGRADUATE or GRADUATE The supertype contains all common attributes, while the subtypes contain specific attributes. The supertype may have a discriminator attribute that indicates the subtype.

36. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-36 Subtypes with a Discriminator

37. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-37 Subtypes: Exclusive or Inclusive If subtypes are exclusive, one supertype relates to at most one subtype. If subtypes are inclusive, one supertype can relate to one or more subtypes.

38. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-38 Subtypes: Exclusive or Inclusive (Continued)

39. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-39 Subtypes: IS-A relationships Relationships connecting supertypes and subtypes are called IS-A relationships, because a subtype IS A supertype. The identifier of the supertype and all of its subtypes must be identical, i.e., the identifier of the supertype becomes the identifier of the related subtype(s). Subtypes are used to avoid value- inappropriate nulls.

40. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-40 ERwin Symbol Summary

41. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-41 ERwin Symbol Summary (Continued)

42. Using CA Erwin Highly recommended for this class Industrial strength modeling tool –~ $3000 for single user license –15 day free trial @ http://www.ca.com/us/trials/collateral.aspx?cid=72121 –Available in N105 only! Tutorials –http://www.isqa.unomaha.edu/wolcott/tutorials/erwin/ERwin.htmlhttp://www.isqa.unomaha.edu/wolcott/tutorials/erwin/ERwin.html –http://www.learndatamodeling.com/erwin2.htmhttp://www.learndatamodeling.com/erwin2.htm Another choice is to use MS Visio –Using Visio 2003 to create ER Diagrams.htmUsing Visio 2003 to create ER Diagrams.htm DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-42

43. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-43

44. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-44 David M. Kroenke’s Database Processing Fundamentals, Design, and Implementation (10 th Edition) End of Presentation: Chapter Five Part One

45. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-45 David M. Kroenke’s Chapter Five: Data Modeling with the Entity-Relationship Model Part Two Database Processing: Fundamentals, Design, and Implementation

46. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-46 Strong Entity Patterns: 1:1 Strong Entity Relationships

47. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-47 Strong Entity Patterns: 1:1 Strong Entity Relationships

48. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-48 Strong Entity Patterns: 1:N Strong Entity Relationships

49. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-49 Strong Entity Patterns: 1:N Strong Entity Relationships

50. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-50 Strong Entity Patterns: N:M Strong Entity Relationships

51. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-51 Strong Entity Patterns: N:M Strong Entity Relationships

52. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-52 Strong Entity Patterns: N:M Strong Entity Relationships

53. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-53 ID-Dependent Relationships: The Association Pattern Note the Price column, which has been added.

54. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-54 ID-Dependent Relationships: The Association Pattern

55. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-55 ID-Dependent Relationships: The Multivaled Attribute Pattern

56. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-56 ID-Dependent Relationships: The Multivaled Attribute Pattern

57. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-57 ID-Dependent Relationships: The Multivaled Attribute Pattern

58. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-58 ID-Dependent Relationships: The Multivaled Attribute Pattern

59. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-59 ID-Dependent Relationships: The Archtype/Instance Pattern The archtype/instance pattern occurs when the ID-dependent child entity is the physical manisfestation (instance) of an abstract or logical parent: –PAINTING : PRINT –CLASS : SECTION –YACHT_DESIGN : YACHT –HOUSE_MODEL: HOUSE

60. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-60 ID-Dependent Relationships: The Archtype/Instance Pattern Note that these are true ID-dependent relationships - the identifier of the parent appears as part of the composite identifier of the ID- dependent child.

61. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-61 ID-Dependent Relationships: The Archtype/Instance Pattern Note the use of weak, but not ID- dependent children.

62. DAVID M. KROENKE’S DATABASE PROCESSING, 10th Edition © 2006 Pearson Prentice Hall 5-62 David M. Kroenke’s Database Processing Fundamentals, Design, and Implementation (10 th Edition) End of Presentation: Chapter Five Part Two