1. Database Conceptual Design using Entity Relationship Diagram J.G. Zheng Feb 2010 CIS 8040 Database Management Systems

2. 2 Overview Conceptual modeling/design Using Entity Relationship Diagram (ERD) Basic Extended Design/modeling considerations Data dictionary

3. Three Level Database Design Conceptual design Using Entity Relationship Diagram (ERD) to represent the reality and business data requirements Logical design Physical design 3

4. Conceptual design Conceptual modeling/data modeling Usually using diagram to visually represent the model ERD 4

5. 5 Entity-Relationship Model Proposed by Dr. Peter Chen in 1970s http://en.wikipedia.org/wiki/Peter_Chen ERD is a conceptual model Major elements Entity (with attributes and identifier) Relationship

6. 6 Entity and Attribute Entity Entity class (entity set) Entity instance Attribute Identifier

7. 7 Entity Notation in ERD Note: there are several variations of ERD notations. Any one is fine – just be consistent.

8. Modeling Consideration 1 Attribute, attributes or entity? “Person Name” “Transaction Date” “Address” “ZIP” “State” “Department” “Skill” 8

9. Modeling Consideration 2 Attribute or attribute values? How to model the following scenario? Contacts  An sales person can be contacted by “Fax Number”, “Cell Phone Number”, “Home Phone Number”, “Work Phone Number”, “Work Email”, etc. Advising Hours  Faculty members have specific advising hours on 5 week days: “Monday”, “Tuesday”, etc. Entity-attribute-value model http://en.wikipedia.org/wiki/Entity-attribute-value_model 9

10. 10 ERD Exercise 1 Draw a ERD (only entities and attributes) about movies Sample data Movie:Mission Impossible Director:Brian De Palma Release Date:22 May 1996 Genre:Action Production: Paramount Pictures (USA) Actor/ess:Tom Cruise (male), Jon Voight (male)

11. 11 Relationship Degree of relationship How many entities are involved? Binary (two entities) relationship is most common BooksPublishers publishes

12. Unary Relationship Unary (recursive) – only 1 entity EmployeeCustomer Supervises Refers 12 ForumPost replies

13. Ternary Relationship Ternary – 3 entities 13

14. N’ary Relationship 4 entities Physician Operates PatientNurse Supplies 14

15. Modeling Consideration 3 Multiple independent relationships? FacultyStudent Teaches Advises Employee Mentors Supervises 15

16. Modeling Consideration 4 3 binary relationships or a ternary one? Database Modeling and Design: Logical Design, 4th Edition by Toby J. Teorey, Sam S. Lightstone, and Tom Nadeau, 2005 16

17. Modeling Consideration 4 (continued) 3 binary relationships or a ternary one? MovieActor/ess Act in Character hasAct as 17 MovieActor/ess Act as … in … Character

18. 18 Types of Relationship (1) One-to-One (1:1) A single entity instance in one entity class is related to a single entity instance in another entity class ER Notation (Crow’s foot) GovernorState governs

19. 19 Types of Relationship (2) One-to-Many (1:N) A single entity instance in one entity class (parent) is related to multiple entity instances in another entity class (child) ER Notation (Crow’s foot) BooksPublishers publish

20. 20 Types of Relationship (3) Many-to-Many (N:M) Each entity instance in one entity class is related to multiple entity instances in another entity class; and vice versa ER Notation (Crow’s foot) BooksAuthors write

21. 21 Cardinality Describes participation in the relationship Maximum cardinalities (types of relationships) Minimum cardinalities describes the minimum number of instances that must participate in a relationship Optional (zero) or Mandatory (one) CertificatesProgrammers have

22. 22 ERD Exercise 2 Movie data continued … Let’s only consider the following entities and their attributes Perfomers: PerformerID, FirstName, LastName, Gender Movies: MovieID, Title, Maker, Year MovieMakers(companies): MakerID, Name Assumptions (business rules) A movie has at least one actor/actress An actor/actress does not have to be in any movie A company does not have to make any movie A movie does not have to be made by a company

23. Modeling Consideration 5 Attributes of a relationship? 23

24. Relationship as an entity? Modeling Consideration 6 MovieActor/ess Acts in MovieActor/essCast 24

25. ERD Exercise 3 Movie data continued … Now considering this Tom Cruise acts as Ethan Hunt in “Mission Impossible”. Let’s consider more information about “Ethan Hunt” “Ethan Hunt”: male, fiction figure, agent, etc. 25

26. ERD: Extended More on entity Strong vs. weak entity More on relationship Generalization 26

27. Weak Entity The existence of such entity has no real business (logical) meaning without another entity (owning entity) Requires the participation from the owning entity (minimum cardinality is 1) 27 Employee has Dependent Building has Room

28. ID Dependency Weak entity’s identifier relies on its owning entity (or indentifying entity)’s identifier 28 Building Id has Building Id Room Number Building Room

29. Modeling Consideration 7 Weak entity or not? Many argues that weak entity is not important in database modeling 29 Building Id has Building Id Room Number Building Room Building Id has Room Number Building Room

30. Super and Sub Types A Sub-type is a special case, or a category, of a Super-type Student : Graduates, Undergraduates Employee : full-time, part-time, contractor Customer : individual, company, non-profit 30

31. Sub-Type Completeness Completeness Do all super type instances appear in any sub-type entities? 31 Participant OrganizationIndividual Employee Student Employee

32. Sub-Type Disjointness Disjointness: does any instance appear in multiple subtype entities? Yes:Overlap (Inclusive) No:Disjoint (Exclusive) 32

33. Modeling Consideration 8 When to use sub-type (specification)? There are attributes that apply to some (but not all) of the instances of an entity type 33

34. Modeling Consideration 8 (continued) When to use (specification)? The instances of a subtype participate in a relationship unique to that subtype 34

35. Modeling Consideration 9 When to use super-type (generalization)? When several entities have same major attributes, see if they are constantly treated together.  Faculty, staff, student assistant  Employee, customer, business partner (or, supplier) Multiple entities participate in the same relationship with the same entity (also see modeling trap 3) 35 DonationOrganization Made by Individual Made by

36. ERD Exercise 4 Type of people in GSU Student: full time, part time, graduate, undergraduate, current, prospective, etc. Student employee: student assistant, GRA, GTA, etc. Faculty: tenured, tenure track, visiting, PTI, non-teaching Staff: full time, part time, admin Alumni Other: parents, family member, emergency contact, etc. 36

37. Modeling Trap 1 Avoid the Fan Trap Ambiguous (broken) relationship between Department and Staff 37

38. Modeling Trap 2 Avoid the Chasm Trap See modeling consideration 3 Ambiguous (broken) relationship between Branch and Property 38

39. Modeling Consideration 10 Redundant relationship? A relationship is redundant if it is represented by alternate transitive relationships DepartmentStudent admits Program offersadmits 39

40. Modeling Consideration 10 (continued) From: Database Modeling and Design: Logical Design, 4th Edition by Toby J. Teorey, Sam S. Lightstone, and Tom Nadeau, 2005 40

41. Modeling Trap 3* Avoid the same (identical) relationship with multiple entities See modeling consideration 10 41 DonationOrganization Made by Individual Made by

42. Analysis and Modeling Tips Modeling is an iterative refinement process Start with basic and obvious facts or concepts; then let entities, attributes, and relationships eventually emerge. Identify binary relationships and maximum cardinality first. Identify minimum cardinality and check for common modeling traps; consider n’ery relationships if necessary; check for redundant relationships and missing relationships. Add, combine, or split entities and attributes as needed. Check relationships and constraints after changes. Start with specific function areas (user views) and integrate them later View integration Ensure the consistency between requirements, ERD and the data dictionary 42

43. Data Dictionary A document that records detailed descriptions of data requirements and all ERD elements Practically, it should include: Definitions (detailed description) for entities, attributes and relationships Business rules (constraints, assumptions or other requirements) and justifications that support the design of entities, attributes and relationships  Data type, domain values, etc. – see database project deliverable #1 43

44. Key Concepts ERD Entity Strong vs. weak entity Attribute and identifier Relationship 1:1, 1:N, N:M Degree  Unary, binary, ternary, etc. Cardinality Super- and sub-types  Completeness and disjointness Data dictionary 44

45. Summary of Modeling Guidelines Modeling considerations 1. Attribute(s) or entity? 2. Attributes or attribute values? 3. Multiple independent relationships? 4. Ternary or multiple binary relationships? 5. Attributes of a relationship? 6. Relationship or entity? 7. Weak entity or not? 8. Sub-type or not? 9. Super-type or not? 10. Redundant relationships? Modeling traps 1. Fan trap 2. Chasm trap 3. Same relationship with other multiple entities 45