1. 1 © Prentice Hall, 2002 Chapter 3: Modeling Data in the Organization Modern Database Management 7th Edition Jeffrey A. Hoffer, Mary B. Prescott, Fred R. McFadden

2. Chapter 3 © Prentice Hall, 2002 2 SDLC Revisited – Data Modeling is an Analysis Activity (figures 2.4, 2.5) Project Identification and Selection Project Initiation and Planning Analysis Physical Design Implementation Maintenance Logical Design Purpose –thorough analysis Deliverable – functional system specifications Database activity – conceptual data modeling

3. Chapter 3 © Prentice Hall, 2002 3 THE E-R MODEL A logical representation of the data for an organization or for a business area Expressed in terms of entities, relationships among entities, and the attributes of entities and relationships

4. Chapter 3 © Prentice Hall, 2002 4 Sample E-R Diagram Entity Relationship Cardinality

5. Chapter 3 © Prentice Hall, 2002 5 E-R Model Constructs Entity: A person, place, object, event, concept in the user environment about which the organization wishes to maintain data Given a noun name Person: EMPLOYEE, STUDENT, FACULTY Place: STORE, CLASS ROOM, HOSTEL Object: COMPUTER, PROJECTOR, PEN Event: REGISTRATION, RENEWAL, SALE, GRADUATION Concept: MESS ACCOUNT, EXTRAS, PROJECT – Entity Type – collection of entities that share common properties or characteristics Name is singular Described only once in database Ex: STUDENT(IDNO,NAME) – Entity instance – A single occurrence of an entity type Each entity type will have many instances Ex: (200A1PS111,RAVI), (2003B1A1112,KIRAN)

6. Chapter 3 © Prentice Hall, 2002 6 E-R Model Constructs Attribute - property or characteristic of an entity type that is of interest to the organization – Ex: STUDENT (Idno, Name, Hostel, Roo_No, Cgpa) Relationship: an association representing an interaction among the instances of one or more entity types that is of interest to the organization – Given a verb phrase name Relationship type: A meaningful association between entity types – Ex: STUDENT registers COURSE – FACULTY teaches COURSE – STUDENT awarded SCHOLARSHIP Relationship Instance – An association between entity instances – Ex: 2005A1PS111 awarded MCN – 2003A4PS123 awarded Pratibha – 2004B1A2111 not awarded MCN

7. Chapter 3 © Prentice Hall, 2002 7 Figure 3-2 -- Basic E-R Notation Entity symbol s Relationshi p symbols Attribute symbols A special entity that is also a relationship

8. Chapter 3 © Prentice Hall, 2002 8 What Should an Entity Be? Entity: A person, place, object, event, concept in the user environment about which the organization wishes to maintain data SHOULD BE: – An object that will have many instances each with distinguishing characteristic – An object that will be composed of multiple attributes – An object that we are trying to model

9. Chapter 3 © Prentice Hall, 2002 9 What Should an Entity Be? Entity: A person, place, object, event, concept in the user environment about which the organization wishes to maintain data SHOULD NOT BE: – A user of the database system ACCOUNTANT receives DEPOSITS PROFESSOR uploaded GRADES – An output of the database system (e.g. a report) STUDENT receives CGCARD PAYSLIP sent to FACULTY – The names receives, sent to, uploaded refer to activities that transfer or translate data but does not indicate any association between data.

10. Chapter 3 © Prentice Hall, 2002 10 Inappropriate entities System user System output Appropriate entities Figure 3-4

11. Chapter 3 © Prentice Hall, 2002 11 Strong Vs Weak Entity Types Strong Entity Type: An entity that exists independently of other entity types. – It has identifier, attribute or combination of attributes that uniquely distinguish each occurrence of that entity – Ex: COURSE, STUDENT, FACULTY Weak Entity Type: An entity type whose existence depends on some other entity type – It doesn’t have its own identifier – Ex: COURSE and LECTURE SECTION – EMPLOYEE and FAMILY MEMBER Identifying owner: The entity type on which the weak entity type depends – Ex: COURSE and LECTURE SECTION – EMPLOYEE and FAMILY MEMBER

12. Chapter 3 © Prentice Hall, 2002 12 Attributes Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Required versus Optional Attribute Required: An attribute of an entity that must have a value for each entity instance Optional : An attribute of an entity that may not have a value for each entity instance Ex: Idno Vs Room No

13. Chapter 3 © Prentice Hall, 2002 13 Attributes Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Simple versus Composite Attribute Simple: An attribute that cant be broken down into smaller components Composite: An attribute that can be broken down into component parts Ex: CGPA Vs Address

14. Chapter 3 © Prentice Hall, 2002 14 Figure 3-7 -- A composite attribute An attribute broken into component parts

15. Chapter 3 © Prentice Hall, 2002 15 Attributes Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Single-Valued versus Multivalued Attribute – Multivalued: An attribute that can take more than one value for a given entity instance Ex: STUDENT having multiple skills

16. Chapter 3 © Prentice Hall, 2002 16 Attributes[2] Attribute - property or characteristic of an entity type that is of interest to the organization – Has a noun name – Ex: STUDENT (Idno, Name, Hostel, Room_No, CGPA) Classifications of attributes: – Identifier Attributes An attribute ( or combination of attributes) that uniquely identifies individual instances of an entity type –Ex: COURSE: comp code Identifier attribute is underlined Composite identifier:: An identifier that consists of a composite attribute –Ex: STUDENT Idno

17. Chapter 3 © Prentice Hall, 2002 17 Criteria for selecting Identifiers (keys) Should not change its value over the life of each instance of the entity type – Ex: Idno Versus Record_No Should not take null values – NULL -> no value Avoid intelligent identifiers – e.g. containing locations or classifications that might change – Intelligent identifiers: Idno, course code AAOC C311 Consider substituting single attribute surrogate identifiers for long, composite keys – Ex: comp code for Course_Code, Record_No for Idno

18. Chapter 3 © Prentice Hall, 2002 18 Figure 3-8 -- Entity with a multivalued attribute (Skill) and derived attribute (Years_Employed) Derived from date employed and current date What’s wrong with this? Multivalued: an employee can have more than one skill

19. Chapter 3 © Prentice Hall, 2002 19 Figure 3-9a – Simple key attribute The key is underlined

20. Chapter 3 © Prentice Hall, 2002 20 Figure 3-9b -- Composite key attribute The key is composed of two subparts

21. Chapter 3 © Prentice Hall, 2002 21 Figure 3-19 – an attribute that is both multivalued and composite This is an example of time-stamping

22. Chapter 3 © Prentice Hall, 2002 22 More on Relationships Recap: Relationship: an association representing an interaction among the instances of one or more entity types that is of interest to the organization – Given a verb phrase name – Modeled as diamond with connecting lines Relationship type: A meaningful association between entity types – Ex: STUDENT registers COURSE – FACULTY teaches COURSE – STUDENT awarded SCHOLARSHIP Relationship Instance – An association between entity instances – Ex: 2005A1PS111 awarded MCN – 2003A4PS123 awarded Pratibha – 2004B1A2111 not awarded MCN

23. Chapter 3 © Prentice Hall, 2002 23 More on Relationships Relationships can have attributes – These describe features pertaining to the association between the entities in the relationship – Associated with many-many or one-one relationship – Ex: STUDENT registers COURSE. Which entity is the grade associated with? Two entities can have more than one type of relationship between them (multiple relationships) Associative Entity : An entity type that associates the instances of one or more entity types and contains attributes that are peculiar to the relationship between those entity instances – combination of relationship and entity – More on this later

24. Chapter 3 © Prentice Hall, 2002 24 Figure 3-11a A binary relationship with an attribute Here, the date completed attribute pertains specifically to the employee’s completion of a course…it is an attribute of the relationship

25. Chapter 3 © Prentice Hall, 2002 25 Figure 3-12c -- A ternary relationship with attributes

26. Chapter 3 © Prentice Hall, 2002 26 Figure 3-10a Relationship type 3-10b Entity and Relationship instances

27. Chapter 3 © Prentice Hall, 2002 27 Degree of Relationships Degree of a Relationship is the number of entity types that participate in that relationship Most common relationship degrees are – Unary Relationship Relationship between the instances of a single entity type. They are also called “recursive relationships” Ex: Employee manages employees – Binary Relationship – Ternary Relationship

28. Chapter 3 © Prentice Hall, 2002 28 Degree of Relationships [2] Degree of a Relationship is the number of entity types that participate in that relationship Most common relationship degrees are – Binary Relationship Relationship between the instances of two entity types Most commonly encountered Ex: One-to-one :WARDEN takes care of one HOSTEL One-to-Many: HOSTEL contains many ROOM s Many-to-many: STUDENT graduating in many DEGREE s – Ternary Relationship A simultaneous relationship among the instances of three entity types Ternary relationships is not same as three binary relationships Ex: COURSE or SECTION, INSTRUCTOR, CLASSROOM -> TIMETABLE All ternary relationships are represented as associative entities

29. Chapter 3 © Prentice Hall, 2002 29 Degree of relationships – from figure 3-2 One entity related to another of the same entity type Entities of two different types related to each other Entities of three different types related to each other

30. Chapter 3 © Prentice Hall, 2002 30 Unary relationships -- figure 3-12a

31. Chapter 3 © Prentice Hall, 2002 31 Binary relationships – figure 3-12b

32. Chapter 3 © Prentice Hall, 2002 32 Ternary relationships –figure 3-12c

33. Chapter 3 © Prentice Hall, 2002 33 Attribute or Relationship? Should skills be an attribute of STUDENT or Should there be relationship between STUDENT and SKILL? So when should be an attribute be linked to an entity type via a relationship? – When the attribute has to be shared by multiple instances of that entity type we can represent that attribute as entity type

34. Chapter 3 © Prentice Hall, 2002 34 Cardinality of Relationships Cardinality specifies the number of instances of entity B that can (or must) be associated with each instance of entity A. One – to – One – Each entity instance in the relationship will have exactly one related entity instance One – to – Many – An entity instance on one side of the relationship can have many related entity instances, but an entity instance on the other side will have a maximum of one related entity instance Many – to – Many – Entity instances on both sides of the relationship can have many related entity instances on the other side

35. Chapter 3 © Prentice Hall, 2002 35 Cardinality Constraints Minimum Cardinality – If zero, then optional – If one or more, then mandatory Maximum Cardinality – The maximum number

36. Chapter 3 © Prentice Hall, 2002 36 Sample E-R Diagram Entity Relationship Cardinality

37. Chapter 3 © Prentice Hall, 2002 37 Basic relationship with only maximum cardinalities showing – figure 3-16a Mandatory minimum cardinalities – figure 3-17a

38. Chapter 3 © Prentice Hall, 2002 38 Figure 3-17c Optional cardinalities with unary degree, one-to-one relationship

39. Chapter 3 © Prentice Hall, 2002 39 Figure 3-21b -- Professors and courses (fixed upon constraint) Here,max cardinality constraint is 4

40. Chapter 3 © Prentice Hall, 2002 40 Representing a bill-of -materials structure Figure 3-13a A unary relationship with an attribute. This has a many-to-many relationship

41. Chapter 3 © Prentice Hall, 2002 41 Examples of multiple relationships – entities can be related to one another in more than one way Figure 3-21a Employees and departments

42. Chapter 3 © Prentice Hall, 2002 42 Figure 3-15: Multivalued attribute vs. relationship. Alternative approaches

43. Chapter 3 © Prentice Hall, 2002 43 Figure 3-5: Strong and weak entities Strong entity Weak entity Identifying relationship

44. Chapter 3 © Prentice Hall, 2002 44 Associative Entities It’s an entity – it has attributes AND it’s a relationship – it links entities together When should a relationship with attributes instead be an associative entity ? – All relationships for the associative entity should be many-to- many – The associative entity could have meaning independent of the other entities – The associative entity preferably has a unique identifier, and should also have other attributes – The associative may be participating in other relationships other than the entities of the associated relationship – Ternary relationships should be converted to associative entities (p102)

45. Chapter 3 © Prentice Hall, 2002 45 Figure 3-11b: An associative entity (CERTIFICATE) Associative entity involves a rectangle with a diamond inside. Note that the many-to-many cardinality symbols face toward the associative entity and not toward the other entities

46. Chapter 3 © Prentice Hall, 2002 46 Figure 3-13c -- an associative entity – bill of materials structure This could just be a relationship with attributes…it’s a judgment call

47. Chapter 3 © Prentice Hall, 2002 47 Figure 3.18 -- Ternary relationship as an associative entity

48. Chapter 3 © Prentice Hall, 2002 48 Figure 3-22 E-R diagram for Pine Valley Furniture

49. Chapter 3 © Prentice Hall, 2002 49 CASE 1 A company has a number of employees. The attributes of EMPLOYEE include Employee_ID, Name, Address, and Birthdate. The company also has several projects. Attributes of PROJECT include Project_Id, Project_Name, and Start_Date. Each employee may be assigned to one or more projects, or may not be assigned to a project. A project must have at least one employee assigned, and may have any number of employees assigned. An employee’s billing rate may vary by project and the company wishes to record the applicable billing rate for each employee when assigned to a particular project.

50. Chapter 3 © Prentice Hall, 2002 50 CASE 1