1. Chapter 2 Entity-Relationship Model Chapter 11 & 12 in Textbook

2. 2 Database Design Steps in building a database for an application: 1. Understand real-world domain being captured. 2. Specify it using a database conceptual model (E/R,OO). 3. Translate specification to model of DBMS (relational). 4. Create schema using DBMS commands (DDL). 5. Load data (DML). Real-world domain Conceptual model DBMS data model Create Schema (DDL) Load data (DML) ER Model

3. 3 Entity-Relationship Model (E/R) A picture is worth a thousand words The Entity-Relationship model (ER) is a high-level description of the structure of the DB. The Entity-Relationship Diagram (ERD) is a graphical model for representing the conceptual model for the data. A E/R models the DB using three element types: - Entities - Attributes - Relationships ER Model

4. ERD Example enroll-in SCHOOL DEPARTMENT COURSECLASS STUDENT PROFESSOR advise offer operate chairs teach belong-to has dean of 1 1 1 1 M 1 M M 1 1 M 1MMN 1 M (0,*) (1,1) (1,*) (1,1)(0,1) (0,4) (1,1) (0,1) (1,1) (0,*) (1,1)(0,*) (1,1) name number DOB hrscode (1,*) (1,1) 1 (1,*) (1,1)

5. 5 Entities & Entity Type Entity is an object that exists and is distinguishable from other objects. e.g. person, company, course, university Entity Type is a set of entities of the same type that share the same properties. e.g. set of all persons, companies, trees, courses COURSESTUDENT ER Model

6. Relationships & Relationship Types A relationship associates 2 or more entities. A relationship type is a set of associations between entity types. COURSE study STUDENT ER Model STUDENT study COURSE S001 r1 CO1 S002 r2 CO2 S003 r3

7. 7 Degree of Relationship Type Degree of relationship refers to number of participating entity types in a relationship. A relationship of degree two (2 entity types) are binary. A relationship of degree three (3 entity types) are ternary. ER Model

8. 8 Degree of Relationship Type A relationship of degree two (2 entity types) are binary. COURSE study STUDENT ER Model

9. 9 Degree of Relationship Type A relationship of degree three (3 entity types) are ternary. e.g. registration of a student in a course by a staff. COURSE register STUDENT STAFF ER Model

10. 10 Recursive Relationship Recursive relationship is a relationship type where the same entity type participates more than once in a different role. It is a unary relationship. COURSE require ER Model STUDENT lead

11. 11 Roles Role indicates the purpose that each participating entity type plays in a relationship. (e.g. prerequisite, requester) COURSE require requesterprerequisite ER Model STUDENT lead leader member

12. 12 Roles Role can be used when two entities are associated through more than one relationship to classify the purpose of each relationship. STAFF allocated Manager Staff member BRANCH Branch office manages ER Model

13. 13Attributes Attributes are descriptive properties for an entity type or a relationship type. All entities in one entity type have the same attributes. STUDENT St_no nameDOB Tel_no ER Model

14. 14 Attributes of Entities COURSE study STUDENT St_no nameDOB Tel_no number name hours ER Model

15. 15 Attributes of Relationships All relationships in one relationship type have the same attributes. Relationships can be distinguished not only by their attributes but also by their participating entities. contract Start End Object ER Model CompanyEmployee

16. 16 Simple & Composite Attributes Simple attribute is an attribute that have a single value with an independent existence. e.g. salary, age, gender,... ER Model

17. 17 Simple & Composite Attributes Composite attribute is an attribute composed of multiple distinct components, each with an independent existence. e.g. address (street, area, city, post code) name (First name, initial, Last name) phone no. (area code, number, exchange no) STUDENT St_no nameDOB Tel_no LName initial FName Area_cd no EX ER Model

18. 18 Single-valued & Multi-valued Attributes Single-valued attribute is an attribute that holds a single value for a single entity. It is not necessarily a simple attribute. e.g. student_no, age, gender,... ER Model

19. 19 Single-valued & Multi-valued Attributes Multi-valued attribute is an attribute that may hold multiple values, of the same type, for a single entity. e.g. tel_no, degrees,… STUDENT St_no nameDOB Tel_no LName initial FName Area_cd no EX ER Model

20. 20 Derived Attributes Derived attribute is an attribute that represents a value that is derived from the value of a related attribute,not necessarily in the same entity type. e.g. age is derived from date_of_birth total_cost is derived from quantity*unit_price STUDENT St_no nameDOB Tel_no age ER Model

21. 21Keys Candidate key (CK) is the minimal set of attributes that uniquely identifies an entity. It cannot contain null. e.g. student_no, social_security_no, branch_no… Primary Key (PK) is a candidate key that is selected to uniquely identify each entity. Alternate Key (AK) is a candidate key that is NOT selected to be the primary key. ER Model

22. 22 Keys Example ELEMENT(symbol, name, atomic_no) ER Model

23. 23 Keys Example ELEMENT(symbol, name, atomic_no) Primary Key Alternate Keys Candidate Key ER Model

24. 24 Choice of PK Choice of Primary Key (PK) is based on: Attribute length Number of attributes required Certainty of uniqueness ER Model

25. 25 Primary Key in ERD age STUDENT St_no nameDOB Tel_no LName initial FName Area_cd no EX ER Model

26. 26Keys A key can be: - simple key is a candidate key of one attribute. e.g. student_no, branch_no… - composite key is a candidate key that consists of two or more attributes. e.g. STUDENT (Lname, Fname, Init) CLASS (crs_code, section_no) ADVERT (property_no, newspaperName, dateAdvert) ER Model

27. 27 Composite Key in ERD CLASS crs_code Section_no name hours ER Model

28. 28 Strong & Weak Entity Types A strong entity type is NOT existence-dependent on some other entity type. It has a PK. A weak entity type is an entity type that is existence- dependent on some other entity type. It does not have a PK. ER Model

29. 29 Weak Entity Type The existence of a weak entity type depends on the existence of a strong entity set; it must relate to the strong entity type via a relationship type called identifying relationship. The PK of a weak entity set is formed by the PK of its strong entity type, plus a weak entity type discriminator attribute. EMPLOYEE emp_no LNameFName DOB dep_no FName DEPENDENT has ER Model

30. 30Cardinalities Cardinality ratio expresses the number of relationships an entity can participate in. Most useful in describing binary relationship types. For a binary relationship type the mapping cardinality must be one of the following types: – One to one (1:1) – One to many(1:M) – Many to one (M:1) – Many to many (M:N) ER Model

31. 31 One-To-One Relationship A professor chairs at most one department; and a department is chaired by only one professor. DEPARTMENT chairs PROFESSOR 1 1 PROFESSOR chair DEPARTMENT P1 r1 D002 P2 P3 r2 D001 ER Model

32. 32 One-To-Many Relationship A course is taught by at most one professor; a professor teaches many courses. COURSE teach PROFESSOR 1 M PROFESSOR teach COURSE P1r1 C01 r2C02 P2r3C03 P3 C04 ER Model

33. 33 Many-To-One Relationship A class requires one room; while a room can be scheduled for many classes. ROOM require CLASS M1 CLASS require ROOM C1 r1 R001 C2 r2 R002 C3 r3 R003 R004 ER Model

34. 34 Many-To-Many Relationship A class enrolls many students; and each student is enrolled in many classes. STUDENT enroll CLASS MN CLASS enroll STUDENT C1 r1 S1 C2 r2 S3 C3 r3 S4 r5 S5 ER Model

35. 35Multiplicity Multiplicity is the number (range) of possible entities that may relate to a single association through a particular relationship. It is best determined using sample data. Takes the form (min#, max#) ER Model

36. 36Multiplicity BRANCH manage STAFF 11 (0,1)(1,1) STAFF manageBRANCH SG1 r1 B002 SG2 SG3 r2 B001 ER Model

37. 37Multiplicity PROPERTY oversee STAFF 1M (0,10) (0,*) (0,1) STAFF overseePROPERTY SG1 r1 P1 r2 P2 SG2 r3 P14 SG3 P6 ER Model

38. 38Multiplicity PROPERTY advertise NEWSPAPER MN (0,*) Newspaper advertisePROPERTY Al-Riyadh r1 P1 r2 P13 Al-Bilad r3 Al-Madinah r4 P6 Al-Sharq P4 ER Model

39. 39 Participation Constraints Participation constraints determine whether all or only some entities participate in a relationship. Two types of participation: - Mandatory (total) - Optional (partial) ER Model

40. 40 Participation Constraints Mandatory (total) (1:*): if an entity’s existence requires the existence of an associated entity in a particular relationship (existence-dependent). e.g. CLASS taught-by PROFESSOR i.e. CLASS is a total participator in the relation. A weak entity always has a mandatory participation constraints but the opposite not always true. ER Model

41. 41 Participation Constraints Optional (partial) (0:*): if an entity’s existence does not require a corresponding entity in a particular relationship. (Not existence-dependent). e.g. PROFESSOR teach CLASS i.e. PROFESSOR is a partial participator in the relation. ER Model

42. ER Case Study  Each bank has a unique name.  Each branch has a number, name, address (number, street, city), and set of phones.  Customer includes their name, set of address (P.O. Box, city, zip code, country), set of phones, and social security number.  Accounts have numbers, types (e.g. saving, checking) and balance. Other branches might use the same designation for accounts. So to name an account uniquely, we need to give both the branch number to which this account belongs to and the account number.  Not all bank customers must own accounts and a customer may have at most 5 accounts in the bank.  An account must have only one customer.  A customer may have many accounts in different branches. Class exercise: Banks Database

43. Customer Account Branch Bank has allocate has own name Bno address phone street city num Acct_notypebalance name SSN address phone P.O.box city zip country 1 M M 1 1 N MM (1,1) (1,*) (0,*) (0,5)

44. ER Case Study Homework: Television Series Database A Television network wishes to create a database to keep track of its TV series. A television series has one or more episode. Television series identified by name and season number, and includes their production company name and Num_of_Episodes ( i.e. total number of episodes in a specific season of a series ). Episode of a specific season of a series is identified by episode number and has a title and a length. No episode can exist without a corresponding television series. Also each episode has only one writer. A writer is identified by name, and also has birth date and a literary agency that represents him or her. An actor appears as a performer in a television series or a guest star on an episode. An actor is identified by name and also has a nationality and birth date. An actor plays a particular character in a television series or episode.

45. 45 Problems with ER Model Connection Traps Connection traps are problems that occur due to misinterpretation of the meaning of certain relationships. Types of connection traps: –Fan Trap –Chasm Trap ER Model

46. 46 Fan Trap has operate DIVISION STAFF BRANCH 1 M 1 M STAFF has DIVISION operate BRANCH SG1 r1 D1 r4 B002 SG3 r2 r5 B003 SG2 r3 D2 r6 B004 ER Model

47. 47 Fan Trap operate has BRANCH DIVISION STAFF M M 1 1 DIVISION operate BRANCH has STAFF D1 r1 B002 r4 SG1 r2 B003 r5 SG3 D2 r3 B004 r6 SG2 ER Model

48. 48 Fan Trap Fan trap where a model represents a relationship between entity types, but the pathway between certain entity occurrence is ambiguous. Exists where 2 or more 1:M relationships fan out from the same entity. ER Model

49. 49 Chasm Trap has oversee STAFF BRANCH PROPERTY M M 1 1 BRANCH has STAFF oversee PROPERTY B001 r1 SG1 r4 P1 B003 r2 SG2 P14 B002 r3 SG3 r6 P5 (1:*) (1:1)(0:*) (0:1) ER Model

50. 50 Chasm Trap has oversee STAFF BRANCHPROPERTY M M 1 1 BRANCH has STAFF oversee PROPERTY B001 r1 SG1 r4 P1 B003 r2 SG2 P14 B002 r3 SG3 r5 P5 offer r6 r7 r8 offer 1M (0:*) (0:1) (1:1) (1:*) ER Model

51. 51 Chasm Trap Chasm trap where a model suggests the existence of a relationship between entity types, but the pathway does not exist between certain entities. Exists when partial participating entity is part of the pathway between related entities. ER Model

52. 52 What makes a good DB design? Faithfulness. Entity types, attributes & relationship types should reflect reality. BRANCH Hourly-rate EMPLOYEE managers-in BRANCH 1 1 (a) (b) ER Model

53. 53 What makes a good DB design? Avoid Redundancy. Say everything only once. Biz-name PERSON own BUSINESS M N name ER Model

54. 54 What makes a good DB design? Simplicity. Avoid introducing more elements into your design than is absolutely necessary. PERSON represent OWNER 11 own BUSINESS 1 M Example 1 ER Model

55. 55 What makes a good DB design? PERSON own run BUSINESS Example 2 ER Model

56. 56 What makes a good DB design? EMPLOYEE work COMPANY M1 own PERSON M 1 Example 3 contract 1 1 ER Model

57. 57 What makes a good DB design? Pick the right kind of element. STUDENT allocate DEPARTMENT M 1 STUDENT degrees dpt_name degreesdpt_name Example 1 ER Model

58. 58 What makes a good DB design? BUSINESS contract SUPPLIER 1M LAWYER 1 Example 2 CONTRACT Sup-makeBiz-make Law-make BUSINESS LAWYER SUPPLIER 1M M 1 M 1 (business, lawyer, supplier) Biz-make (business, contract) Sup-make (supplier, contract) Law-make (lawyer, contract) (a) (b)

59. 59 Enhanced Entity-Relationship Model (EER) EER is an ER model supported with additional semantic concepts. Semantic concepts supported: - Specialization - Generalization - Aggregation ER Model

60. 60Specialization Top-down design process; we designate sub-groupings within an entity type that are distinctive from other entities in the set. These sub-groupings (subclasses) become lower-level entity types that have attributes or participate in relationships that do not apply to the higher-level entity set (superclass). ER Model

61. 61Specialization/Generalization STAFF MANAGERSECRETARY SALES PERSONNEL Subclass Superclass IS_A relationship 1:1 ER Model

62. 62Generalization A bottom-up design process – combine a number of entity types that share the same features into a higher-level (superclass) entity type. Specialization and generalization are simple inversions of each other; they are represented in an EER diagram in the same way. ER Model

63. 63Inheritance A subclass entity type inherits all the attributes and relationship participation of the superclass entity type to which it is linked. ER Model

64. 64Inheritance STAFF SALES PERSONNEL Unshared attributes Superclass addressDOBname Sales area Car allowance shared attributes Subclass require CAR Unshared relationship contract COMPANY Shared relationship ER Model

65. 65 Constraints on Specialization/Generalization Participation constraint determines whether every member in the superclass must participate as a member of a subclass. Two types of participation constraints: - Mandatory (total) - Optional (partial) ER Model

66. 66 Participation Constraints Mandatory (total) participation where every member in the superclass must also be a member of a subclass. STAFF FULL-TIME STAFF PART-TIME STAFF salary Hourly-rate ER Model

67. 67 Participation Constraints Optional (partial) participation where a member in the superclass need not belong to any of its subclasses. STAFF MANAGERSECRETARY SALES PERSONNEL ER Model

68. 68 Constraints on Specialization/Generalization Disjoint constraint describes the relationship between members of the subclasses & indicates whether it is possible for a member of a subclass to be a member of one or more subclasses. Two types of disjoint constraints: - Disjoint - Non-Disjoint ER Model

69. 69 Disjoint Constraints Disjoint constraint when an entity can be a member of only one of the subclasses of the specialization. STAFF FULL-TIME STAFF PART-TIME STAFF salary Hourly-rate d ER Model

70. 70 Disjoint Constraints Non-disjoint constraints: a subclass is a member of more than one subclass of specialization. Entity types may overlap. STAFF MANAGERSECRETARY SALES PERSONNEL o ER Model

71. 71Aggregation Represents a “part-of” relationship between entity types, where one represents the ‘whole’ and the other the ‘part’. No inherited attributes; each entity has its own unique set of attributes. ER Model

72. 72Aggregation TEAM MEMBER ER Model

73. 73 Summary of ERD notations (1) ENTITY WEAK ENTITY RELATIONSHIP IDENTIFYING RELATIONSHIP ATTRIBUTE KEY ATTRIBUTE MULTI-VALUED COMPOSITE DERIVED ER Model

74. 74 Summary of ERD notations (2) CARDINALITY RATION PARTICIPATION CONSTRAINTS 1 M (min,max) ER Model

75. 75 Summary of EERD notations (3) Disjoint constraint d o Non-Disjoint constraint Total Participation Optional Participation ER Model