1. Team Dosen UMN ER Modelling Connolly Book Chapter 12-13

2. Team Dosen UMN Objectives Fundamental of ER Concept Enhanced ER Concept

3. Team Dosen UMN Fundamental of ER Concept

4. Team Dosen UMN Entities Entity type is a group of objects with the same properties, which are identified by the enterprise as having an independent existence. Object is something that is or is capable of being seen, touched, or otherwise sensed, and about which users store data and associate behavior. Entity has two types of existences: – Object with a physical (real) existence – Example: Customer, Staff, Property – Object with a conceptual (abstract) existence – Example: Sales, Inspection Diagrammatic: – Entity is drawn to be a box. – First letter is Uppercase StaffBranch

5. Team Dosen UMN Entity Occurrences Entity Occurrence or Entity Instance or Entity: a uniquely identifiable object of an entity types Student IDLast NameFirst Name 2144ArnoldBetty 3122TaylorJohn 3843SimmonsLisa 9844MacyBill 2837LeathHeather 2293WrenchTim Entity occurrence Entity: student

6. Team Dosen UMN Relationship Type Relationship type is a set of meaningful associations among entity types Relationship Occurrence: a uniquely identifiable association that includes one occurrence from each participating entity types Diagrammatic: – A relationship is drawn to be a line connecting the associated entity types and labeled with the name of relationship with its direction – A relationship is named as a verb (i.e. has) or phrase with a verb. First letter is Uppercase (i.e. LeasedBy) – Relationship is for one direction only StaffBranch Has >

7. Team Dosen UMN Semantic Net

8. Team Dosen UMN Degree of Relationship Degree of Relationship is the number of participating entity types in a relationship For the degree is two, the relationship is called binary relationship for the degree is three, the relationship is called ternary relationship StaffBranch Has StaffBranch Has Car “Branch has staff” “Branch has staff and car”

9. Team Dosen UMN Degree of Relationship For the degree is four, the relationship is called quaternary relationship StaffCustomer Has Car Branch “Branch has customer, staff, and car”

10. Team Dosen UMN Recursive Relationship Recursive Relationship is a relationship which has more than one different roles in the same entity Example :both Melinda and Rose are employees Melinda’s role is the supervisor, whilst Rose’s role is supervisee Melinda supervises Rose or you can say Rose Supervisees Melinda Q: Can you make more examples of recursive relationships? Employee Supervises> Supervisor Supervisee Role 1 Role 2

11. Team Dosen UMN Role Names Role names are also used when two entities are associated through more than one relationship. StaffBranch Has> <Manages Branch OfficeMember of Staff Branch OfficeManager

12. Team Dosen UMN Attributes Attribute is a property of an entity or a relationship type Example : staffNo, name, position, and salary are the attributes of Staff entity. Attribute Domain is a set allowable values for one or more attributes. Example for attribute room the attribute domain is between 1 to 15. According to their composition, attributes have two types: – A Simple Attribute or Atomic Attribute is an attribute composed of a single component with an independent existence. Example position, salary in the Staff entity – A Composite Attribute is an attributed composed of multiple components, where each component is an independent existence. Example: address attribute in Branch entity is composed of street, city, and postcode attributes.

13. Team Dosen UMN Attributes According their values, attributes have two types: – A single-valued attribute is an attribute that holds a single value for each occurrence of an entity type. Example: branchCode attribute in the Branch Entity as one branch has one code only. – A multi-valued attribute is an attribute that holds multiple values for each occurrence of an entity type. Example: telpNo attribute in the Branch Entity as one branch may have two or more phones. Derived attribute is an attribute that represents a value that derivable from the value of a related attribute of a set of attributes, not necessarily in the same entity type. Example: duration attribute are calculated from rentStart and rentFinish attributes that are in the same Lease entity.

14. Team Dosen UMN Diagrammatic attributes Entity is drawn as a box Inside the Box, the uppercase part is the Entity name and the lowercase parts are attributes. See how to draw simple, composite, single-valued, multi-valued, and derived attributes Tags – {PK} Primary Key – {PPK} a member of Composite Primary Keys – {AK} Alternate key Staff staffNo {PK} name position salary /totalStaff address street city postcode telp{1..3}

15. Team Dosen UMN Diagrammatic attributes

16. Team Dosen UMN Strong and Weak Entity Strong Entity is an entity type that is not existence-dependent on some other entity types Example: Customer Weak Entity is an entity hat is existence-dependent on some other entity type Example: CustomerFamily Strong Entities are called parent, owner, or dominant entities whilst Weak Entities are called child, dependent, or subordinate entities. Strong Entity is drawn as a single border-lined box and Weak Entity is drawn as a double border-lined box Customer name fname lname telp {1..3} eMail CustomerFamily name fname lname relation has

17. Team Dosen UMN Multiplicity Multiplicity is the number of possible occurrences of an entity type that may relate to a single occurrence of an associate entity type through a particular relationship

18. Team Dosen UMN Staff Manages Branch Staff staffNo Branch branchCode Manages> 0..1 A member of staff can manage zero or one branch ?

19. Team Dosen UMN Find Multiplicity of Staff Oversees PropertyForRent

20. Team Dosen UMN Staff Oversees PropertyForRent

21. Team Dosen UMN Find Multiplicity for Newspaper Advertises PropertyForRent

22. Team Dosen UMN Newspaper Advertises PropertyForRent

23. Team Dosen UMN Cardinality and Participation Constraints Cardinality 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 relationship. There two type of participation which are mandatory participation (minimum value=1) and optional participation (minimum value=0)

24. Team Dosen UMN Cardinality and Participation

25. Team Dosen UMN Multiplicity Constraints Multiplicity 0..1 1..1 (or simply 1) 0..* (or just *) 1..* 5..10 0,3,6-8 Meaning Zero or one entity occurrence Exactly one entity occurrence Zero or many entity occurrence One or many entity occurrence Minimum of 5 up to a maximum of 10 entity occurrences Zero or three or six, seven, or eight entity occurrences Cardinality ? Participation ?

26. Team Dosen UMN Multiplicity in Complex Relationship Multiplicity (for complex relationship) is the number or range of possible occurrences of an entity type in an n-ary relationship when the other (n-1) values are fixed. Example multiplicity for ternary relationship represents the potential range of entity occurrences of a particular entity in the relationship when the other two values represent in the other two entities are fixed.

27. Team Dosen UMN Example of Multiplicity for Complex Relationship

28. Team Dosen UMN Multiplicity for Complex Relationship 0..*

29. Team Dosen UMN Multiplicity for Complex Relationship CR56/B003 CR57/B003 CR62/B003 CR84/B003 CR91/B003 r1 r2 r3 r4 r5 SG37 SG5 SG14 Registered by Client/BranchStaff 1..1

30. Team Dosen UMN Multiplicity for Complex Relationship CR56/SG37 CR74/SG37 CR62/SG14 CR84/SG14 CR91/SG14 Client/Staff Register at B003 Branch 1..1

31. Team Dosen UMN Multiplicity for Complex Relationship

32. Team Dosen UMN Problems with ER models There are two main problems, which are Fan Traps and Chasm Traps. Fan Traps happen where a model represents a relationship between entity types, but the pathway between certain entity occurrence is ambiguous. StudentFacultyStudyProgram <Has Operates> 1..*1..1 1..* StudentStudyProgram ?? ?

33. Team Dosen UMN Fan Traps Solution 1 Draw semantic net of original ER model Ali Bryan Calvin Dee Eddy Students entity Economy ICT Faculty entity Mgmt SK TI SI StudyProgram entity Has relationship Operates relationship

34. Team Dosen UMN Fan Traps Solution 2 Examine occurrences of the relationships Ali Bryan Calvin Dee Eddy Students entity Economy ICT Faculty entity Mgmt SK TI SI StudyProgram entity Operates relationship Has relationship

35. Team Dosen UMN Fan Traps Solution Result Restructure the ER model FacultyStudyProgramStudent Operates> Has> 1..*1..1 1..*

36. Team Dosen UMN Chasm Traps Chasm Traps happen where a model suggests the existence of a relationship between entity types, but the pathway does not exist certain entity occurrences It may occur when one or more relationships with optional participations (minimum multiplicity=0) BranchStaffProperty Has> Oversees> 0..*0..11..*1..1 BranchProperty ? ??

37. Team Dosen UMN Chasm Traps Solution Identify the missing relationship, and make a new relationship BranchStaffProperty Has> Oversees> 0..*0..11..*1..1 Offers> 1..1 1..*

38. Team Dosen UMN Enhanced ER Modeling

39. Team Dosen UMN Entity Types Superclass is an entity type that includes one or more distinct subgroupings of its occurrences, which must be represented in a data model. Subclass is a distinct subgrouping of occurrences of an entity type, which must be represented in a data model. Example: Staff entity may be classified as Manager, SalesPersonnel, Secretary. In other words: – Staff entity is the superclass of Manager, SalesPersonnel, Secretary. – Manager, SalesPersonnel, Secretary is the subclasses of Staff entity.

40. Team Dosen UMN Superclass/Subclass Relationship Each member of subclass is also a member of superclass The relationship between a superclass and subclass is one-to-one (1:1). Not every member of superclass is necessarily a member of a subclass. Example Staff entity has overlapping subclasses Manager, SalesPersonel, and Secretary. Attributes appropriate for all staff Attributes appropriate for managers Attributes appropriate for Sales Personnel Attributes appropriate for Secretary

41. Team Dosen UMN Attribute Inheritance One subclass may have one or more subclasses. An entity and its subclasses and their subclasses is called a type hierarchy. Type hierarchy that accords to specialization of the entity is called specialization hierarchy. Example: Manager is specialization of Staff. Type hierarchy that accords to generalization of the entity is called generalization hierarchy. Example: Staff is generalization of Manager Type hierarchy that accords to a member of the entity is called IS-A hierarchy. Example: Manager is a member of staff A subclasses with more than two superclasses is called shared subclasses. Attributes of the superclasses are inherited by the shared subclass. This process is called multiple inhertance.

42. Team Dosen UMN Specialization Process Specialization process is the process of maximizing the differences between members of an entity by identifying their distinguishing characteristics. Steps: – 1. Identify a set of subclasses of an Entity – 2. Associate attributes specific to each subclass (if applicable) – 3. Identify any relationship between each subclass and other entity types or sub classes (if applicable).

43. Team Dosen UMN Example of Specialization of the Staff into subclasses representing job roles Staff staffNo {PK} name position salary Manager mgrStartDate bonus SalesPersonnel salesArea carAllowence Secretary typingSpeed subclasses superclass Specialization/ generalization {Optional, And} participation constraint disjoint constraint

44. Team Dosen UMN Example of Specialization of the Staff into subclasses representing contract of employment Staff staffNo {PK} name position salary FulltimePermanent salaryScale holidayAllowance PartTimeTemporary hourlyRate subclasses superclass Specialization/ generalization {Mandatory, Or} participation constraint disjoint constraint

45. Team Dosen UMN Example of Specialization Manager mgrStartDate bonus SalesPersonnel salesArea carAllowence Secretary typingSpeed SalesManager salesTarget AssistantScretary startDate {Optional} Shared subclasses Participation constraints

46. Team Dosen UMN Constraints of Specialization/Generalization Participation Constraint determines whether every member in the superclass must participate as a member of a subclass Disjoint Constraints describes the relationship between members of the subclasses and indicates whether it is possible for a member of a superclass to be a member of one or more subclasses.

47. Team Dosen UMN Aggregation Aggregation represents a has-a or is-part-of relationship between entity types, where one represents the whole and the other the part. Example: Has relationship from Branch entity (the whole) to the Staff entity (the part). Branch branchNo Staff staffNo Has> 1..11..* aggregation The Entity representing part in Has relationship The Entity representing whole in Has relationship

48. Team Dosen UMN Composition Composition is a specific form of aggregation that represents an association between entities, where there is a strong ownership and coincidental lifetime between the whole and the part. (Booch et al, 1998). In a composite the whole is responsible for disposition of the parts meanings it manages the creation and destruction of its parts. NewspaperAdvert Displays> 1..11..* composition The Entity representing part in Display relationship The Entity representing whole in Display relationship

49. Team Dosen UMN Workshop We have a guest describing his/her point of view about one new database system requirement. Use your interview techniques to ask her as necessary and make: 1. Mission Statement 2. Mission Objectives 3. Project Scope & Boundaries 4. E-R Diagram