1. 1 R. Ching, Ph.D. MIS California State University, Sacramento Week 9 October 24 Modeling with ERDModeling with ERD

2. 2 R. Ching, Ph.D. MIS California State University, Sacramento Entity Relationship (ER) Model (applies to relational data model) High-level conceptual modelHigh-level conceptual model –Describes the structure of the database, and the associated retrieval and update transactions on the database –Composed of Entity typesEntity types Relationship typesRelationship types AttributesAttributes

3. 3 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Music_categories music_category_code {PK} music_category_title CDs stock_number {PK} CD_titleartistmusic_category_coderecord_label_code Entity type Primary key Attributes Relationship name Classify  1..10..* Relationship type Degree of the Relationship: Binary Multiplicity (constraint)

4. 4 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Alternatively Music_categories Music_category_codeMusic_category_title CDs Stock_numberCD_titleArtistMusic_category_codeRecord_label_code Classify Entity type Primary key (underscored) Attributes Relationship type Relationship name Many (crows feet) Cardinality Zero(circle) Minimum(inside) Maximum(outside)

5. 5 R. Ching, Ph.D. MIS California State University, Sacramento ERD Entity type – A group of objects with the same properties, which are identified by the enterprise as having an independent existenceEntity type – A group of objects with the same properties, which are identified by the enterprise as having an independent existence Relationship type – A set of meaningful associations among entity typesRelationship type – A set of meaningful associations among entity types Attributes – A property of an entity or a relationship typeAttributes – A property of an entity or a relationship type

6. 6 R. Ching, Ph.D. MIS California State University, Sacramento Degree of Relationship Type The number of participating entity types in a relationshipThe number of participating entity types in a relationship Binary (two entity types)Binary (two entity types) Ternary (three entity types)Ternary (three entity types) Employee Employee Awards Receives  1..10..1 EmployeeEmp_Benefits Emp_Tax Net pay Receives Attribute of a relationship type

7. 7 R. Ching, Ph.D. MIS California State University, Sacramento Recursive Relationship A relationship type where the same entity participates more tan once in different rolesA relationship type where the same entity participates more tan once in different roles Employee  Manages Manager Staff A manager is an employee Managers and staff are employees. Staff are managed by managers 1..* 0..* Role name indicates the purpose an entity type plays in a relationship type

8. 8 R. Ching, Ph.D. MIS California State University, Sacramento Attributes Property of an entity or relationship type Attribute domainAttribute domain –Set of values that may be assigned to a single-valued attribute Cust_account Cust_name Cust_address Cust_phone Soc_Sec_Num Customers Cust_account Current_balance Credit_limit Active_date Expire_date Customer_Accounts

9. 9 R. Ching, Ph.D. MIS California State University, Sacramento Attributes of Attributes Simple (atomic attributes) - composed of a single componentSimple (atomic attributes) - composed of a single component Composite - composed of multiple componentsComposite - composed of multiple components Single valued - one value for an entitySingle valued - one value for an entity Multi-valued - one or more values for an entityMulti-valued - one or more values for an entity Derived - value derived from a related attribute or set of attributesDerived - value derived from a related attribute or set of attributes Student_ID Semester Course_ID Student_ID FName MName LName Multi-valued Single-valued More than one semester, more than one course_id

10. 10 R. Ching, Ph.D. MIS California State University, Sacramento Attribute Domain Cust_account Cust_name Cust_address Cust_phone Soc_Sec_Num Customers JohnWilliamAnitaHomerBrownTellBreakeSimpson On an ER model, should customer name be shown as a composite or simple attribute?On an ER model, should customer name be shown as a composite or simple attribute? What is the attribute domain of Cus_name?What is the attribute domain of Cus_name? Cust_first_nameCust_first_name Cust_last_nameCust_last_name Composite

11. 11 R. Ching, Ph.D. MIS California State University, Sacramento Derived Attributes Derived - value derived from a related attribute or set of attributesDerived - value derived from a related attribute or set of attributes Units x Grade = Grade point Student_ID Semester Course_ID Units Grade Grade_point Derived attribute

12. 12 R. Ching, Ph.D. MIS California State University, Sacramento Attributes as Keys Primary key Candidate key Alternate key - candidate that can also be used to access an entityAlternate key - candidate that can also be used to access an entity Composite key - composed of multiple attributes (components)Composite key - composed of multiple attributes (components) Uniquely identifies an entity Keys cannot change their values (good for the life of the entity)Keys cannot change their values (good for the life of the entity) An efficient means for identifying an entityAn efficient means for identifying an entity

13. 13 R. Ching, Ph.D. MIS California State University, Sacramento Attribute Diagrammatic Representation Composite attribute Customers Cust_account {PK} Cust_name First_name First_name Middle_name Middle_name Last_name Last_nameCust_address Street_number Street_number Zip_code (fk) Zip_code (fk)Cust_phoneSoc_sec_numCustomers Cust_account {PK} Cust_name First_name First_name Middle_name Middle_name Last_name Last_nameCust_address Street_number Street_number Zip_code (fk) Zip_code (fk)Cust_phoneSoc_sec_num Composite attribute Key Foreign key

14. 14 R. Ching, Ph.D. MIS California State University, Sacramento Attribute Diagrammatic Representation Composite key Customer_Purchases Cust_account {PK} Transaction_number {PK} DateStore_numberPayment_typeCustomer_Purchases Cust_account {PK} Transaction_number {PK} DateStore_numberPayment_type Foreign key A customer may have more than one purchase Foreign key

15. 15 R. Ching, Ph.D. MIS California State University, Sacramento Strong vs. Weak Entity Types Strong Entity Type – An entity type that is not existence- dependent on some other entity typeStrong Entity Type – An entity type that is not existence- dependent on some other entity type –Often referred to as parent, owner or dominant entities Weak Entity Type – An entity type that is existence- dependent on some other entity type.Weak Entity Type – An entity type that is existence- dependent on some other entity type. –Often referred to as child, dependent or subordinate entities

16. 16 R. Ching, Ph.D. MIS California State University, Sacramento Definition of a Weak Entity Type “An entity type that borrows all or part of its primary key. Identifying relationships indicate the entity types that supply components of the borrowed primary key.” “An entity type that borrows all or part of its primary key. Identifying relationships indicate the entity types that supply components of the borrowed primary key.” Mannino, 1999

17. 17 R. Ching, Ph.D. MIS California State University, Sacramento Strong vs. Weak Entity Types Customer_accounts AccountNumber {PK} FirstNameMiddleNameLastNameAddressZipCodeMembershipDateCustomer_Purchases StoreNumber {PK} TransactionDate {PK} TransactionNumber {PK} PaymentType Purchase  1..10..* Which is the strong and weak entity type? How can you tell?

18. 18 R. Ching, Ph.D. MIS California State University, Sacramento Strong vs. Weak Entity Types Customer_accounts AccountNumber {PK} FirstNameMiddleNameLastNameAddressZipCodeMembershipDateCustomer_Purchases StoreNumber {PK} TransactionDate {PK} TransactionNumber {PK} PaymentType Purchase  1..10..* Which is the strong and weak entity type? How can you tell? Existent-dependence Also a FK

19. 19 R. Ching, Ph.D. MIS California State University, Sacramento Attributes of Relationship Types Attributes produced through relationship types (i.e., not retained in the entity types)Attributes produced through relationship types (i.e., not retained in the entity types) CustomerAccountsAccountNumber…CustomerFlights AccountNumber {PK} TransactionDate {PK} IntineraryNumber {PK} … Reserve  1..10..* NumberOfItineraries Derived attribute

20. 20 R. Ching, Ph.D. MIS California State University, Sacramento Structural Constraints Multiplicity – Number of possible occurences of an entity type that may relate to a single occurrence of an associated entity type through a particular relationship typeMultiplicity – Number of possible occurences of an entity type that may relate to a single occurrence of an associated entity type through a particular relationship type –One to one (1:1) –One to many (1:*) –Many to many (*:*) Cardinality and participation constraintsCardinality and participation constraints –Cardinality – Describes the maximum number of possible relationship occurrences for an entity participating in a given relationship type Defined by business rules

21. 21 R. Ching, Ph.D. MIS California State University, Sacramento Cardinality and Participation Constraints Cardinality – Describes the maximum number of possible relationship occurrences for an entity participating in a given relationship typeCardinality – Describes the maximum number of possible relationship occurrences for an entity participating in a given relationship type Participation – Determines whether all or only some entity occurrences participate in a relationshipParticipation – Determines whether all or only some entity occurrences participate in a relationship –1:1 (1..1) minimum is one – mandatory participation –0:1 (0..1) minimum is zero – optional participation

22. 22 R. Ching, Ph.D. MIS California State University, Sacramento Cardinality 1:1 (one to one)1:1 (one to one) –Each entity in X is associated with at most one entity in Y and conversely each entity in Y is associated with at most one entity in X 1:* (one to many)1:* (one to many) –Each entity in X can be associated with many entities in Y but each entity in Y is associated with at most one entity in X. *:* (many to many)*:* (many to many) –Each entity in X can be associated with many entities in Y and each entity in Y can be associated with many entities in X.

23. 23 R. Ching, Ph.D. MIS California State University, Sacramento Cardinality Customers Customer_ID {PK} Customer_nameCustomer_addressZip_code Own  A customer owns a minimum and maximum of one account Accounts Account_number {PK} Customer_ID {FK} Account_typeCurrent_balance An account is owned by a minimum and maximum of one customer 1:1 Relationships Strong entity type Weak entity type Mandatory participation Note. This would be avoided in the logical design, but could be implemented in the physical. 1..11..1

24. 24 R. Ching, Ph.D. MIS California State University, Sacramento Cardinality Customers Customer_ID {PK} Customer_nameCustomer_addressZip_code Own  A customer owns a minimum one and maximum of many accounts Accounts Account_number {PK} Customer_ID {FK} Account_typeCurrent_balance 1:M Relationships Strong entity type Weak entity type Mandatory participation An account is own by a minimum and maximum of one customer 1..11..*

25. 25 R. Ching, Ph.D. MIS California State University, Sacramento Cardinality *:* (many-to-many) relationship if a customer can own more than one account (e.g., revolving, long-term), and one account can have more than one owner (e.g., joint account).*:* (many-to-many) relationship if a customer can own more than one account (e.g., revolving, long-term), and one account can have more than one owner (e.g., joint account). Customers Customer_ID {PK} Customer_nameCustomer_addressZip_code Own  A customer owns a minimum one and maximum of many accounts Accounts Account_number {PK} Customer_ID {FK} Account_typeCurrent_balance An account is own by a minimum of one customer and maximum of many customers 1..*1..*

26. 26 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Video_categories Category_code {PK} Category_title Videos Stock_number {PK} Video_title… Category_code {FK} Distributor_code {FK} Classify Entity type Primary key Attributes Relationship type Relationship name Many Cardinality Zero Minimum Maximum 1..10..* For an occurrence of videos, there may exist one and only one video category. For an occurrence of video categories, there may exist zero to many videos.

27. 27 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Video_categories Category_code {PK} Category_title Videos Stock_number {PK} Video_title… Category_code {FK} Distributor_code {FK} Classify  1..10..* Distributors Distributor_code {PK} Distributor_name 0..* 1..1  Release Video categories classify videos Distributors release videos For an occurrence of distributors, there are zero to many videos

28. 28 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Video_categories Category_code {PK} Category_title Videos Stock_number {PK} Video_title… Category_code {FK} Distributor_code {FK} Classify  1..10..* Distributors Distributor_code {PK} Distributor_name 0..* 1..1  Release Video categories classify videos Distributors release videos For an occurrence of videos, there is one and only one video category

29. 29 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Video_categories Category_code {PK} Category_title Videos Stock_number {PK} Video_title… Category_code {FK} Distributor_code {FK} Classify  1..10..* Distributors Distributor_code {PK} Distributor_name 0..* 1..1  Release Attribute of the relationship type Number_of_videos_ released

30. 30 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Alternate Notation Music_categories Music_category_codeMusic_category_title CDs Stock_numberCD_titleArtistMusic_category_codeRecord_label_code Classify Entity type Primary key (underscored) Attributes Relationship type Relationship name Many (crows feet) Cardinality Zero(circle) Minimum(inside) Maximum(outside)

31. 31 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Alternate Notation Music_categories Music_category_codeMusic_category_title CDs Stock_numberCD_titleArtistMusic_category_codeRecord_label_code Classify Entity type Weak entity type (all four corners) Minimum cardinality of one (a music category has to have at least one CD)

32. 32 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Alternative Notation Music_categories Music_category_codeMusic_category_title CDs Stock_numberCD_titleArtistMusic_category_codeRecord_label_code Classify Record_label_codeRecord_label Record_labels Produce A record label is related to a minimum of zero and maximum of many CDs

33. 33 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Alternative Notation Music_categories Music_category_codeMusic_category_title CDs Stock_numberCD_titleArtistMusic_category_codeRecord_label_code Classify Record_label_codeRecord_label Record_labels Produce A CD is related to a minimum and maximum of one record label

34. 34 R. Ching, Ph.D. MIS California State University, Sacramento ERD Notation Alternative Notation Music_categories Music_category_codeMusic_category_title CDs Stock_numberCD_titleArtistMusic_category_codeRecord_label_code Classify Record_label_codeRecord_label Record_labels ProduceQuantity_produced Attribute of a relationship

35. 35 R. Ching, Ph.D. MIS California State University, Sacramento