4 4 Chapter 4 Entity Relationship (E-R) Modeling Database Systems: Design, Implementation, and Management 4th Edition Peter Rob & Carlos Coronel

4 4 Developing an E-R Diagram 4 The process of database design is an iterative rather than a linear or sequential process. 4 It usually begins with a general narrative of the organization’s operations and procedures. 4 The basic E-R model is graphically depicted and presented for review. 4 The process is repeated until the end users and designers agree that the E-R diagram is a fair representation of the organization’s activities and functions.

4 4 4 Tiny College Database (1) u Tiny College (TC) is divided into several schools. Each school is administered by a dean. A 1:1 relationship exists between DEAN and SCHOOL. u Each dean is a member of a group of administrators (ADMINISTRATOR). Deans also hold professorial rank and may teach a class (PROFESSOR). Administrators and professors are also Employees. (Figure 4.38) Developing an E-R Diagram

4 4

4 4 4 Tiny College Database (2) u Each school is composed of several departments. u The smallest number of departments operated by a school is one, and the largest number of departments is indeterminate (N). u Each department belongs to only a single school. Figure 4.40 The First Tiny College ERD Segment

4 4 4 Tiny College Database (3) u Each department offers several courses. Developing an E-R Diagram Figure 4.41 The Second Tiny College ERD Segment

4 4 4 Tiny College Database (4) u A department may offer several sections (classes) of the same course. u A 1:M relationship exists between COURSE and CLASS. u CLASS is optional to COURSE Developing an E-R Diagram Figure 4.42 The Third Tiny College ERD Segment

4 4 4 Tiny College Database (5) u Each department has many professors assigned to it. u One of those professors chairs the department. Only one of the professors can chair the department. u DEPARTMENT is optional to PROFESSOR in the “chairs” relationship. Developing an E-R Diagram Figure 4.43 The Fourth Tiny College ERD Segment

4 4 4 Tiny College Database (6) u Each professor may teach up to four classes, each one a section of a course. u A professor may also be on a research contract and teach no classes. Developing an E-R Diagram Figure 4.44 The Fifth Tiny College ERD Segment

4 4 4 Tiny College Database (7) u A student may enroll in several classes, but (s)he takes each class only once during any given enrollment period. u Each student may enroll in up to six classes and each class may have up to 35 students in it. u STUDENT is optional to CLASS. Developing an E-R Diagram Figure 4.45 The Sixth Tiny College ERD Segment

4 4 4 Tiny College Database (8) u Each department has several students whose major is offered by that department. u Each student has only a single major and associated with a single department. Developing an E-R Diagram Figure 4.46 The Seventh Tiny College ERD Segment

4 4 4 Tiny College Database (9) u Each student has an advisor in his or her department; each advisor counsels several students. u An advisor is also a professor, but not all professors advise students. Developing an E-R Diagram Figure 4.47 The Eighth Tiny College ERD Segment

4 4 Entities for the Tiny College Database 4 SCHOOL 4 DEPARMENT 4 EMPLOYEE 4 PROFESSOR 4 COURSE 4 CLASS 4 ENROLL (Bridge between STUDENT and CLASS) 4 STUDENT Developing an E-R Diagram

4 4 Components of the E-R Model Table 4.2

4 4 Figure 4.48

4 4 4 Converting an E-R Model into a Database Structure u A painter might paint many paintings. The cardinality is (1,N) in the relationship between PAINTER and PAINTING. u Each painting is painted by one (and only one) painter. u A painting might (or might not) be exhibited in a gallery; i.e., the GALLERY is optional to PAINTING. Developing an E-R Diagram

4 4 Figure 4.49

4 4 4 Summary of Table Structures and Special Requirements for the ARTIST database PAINTER(PRT_NUM, PRT_LASTNAME, PRT_FIRSTNAME, PRT_INITIAL, PTR_AREACODE, PRT_PHONE) GALLERY(GAL_NUM, GAL_OWNER, GAL_AREACODE, GAL_PHONE, GAL_RATE) PAINTING(PNTG_NUM, PNTG_TITLE, PNTG_PRICE, PTR_NUM, GAL_NUM) Developing an E-R Diagram

4 4 A Data Dictionary for the ARTIST Database Table 4.3

4 4 SQL Commands to Create the PAINTER Table CREATE TABLE PAINTER ( PTR_NUMCHAR(4)NOT NULLUNIQUE, PRT_LASTNAMECHAR(15)NOT NULL, PTR_FIRSTNAMECHAR(15), PTR_INITIALCHAR(1), PTR_AREACODECHAR(3), PTR_PHONECHAR(8), PRIMARY KEY(PTR_NUM)); Developing an E-R Diagram

4 4 SQL Commands to Create the GALLERY Table CREATE TABLE GALLERY ( GAL_NUMCHAR(4)NOT NULLUNIQUE, GAL_OWNERCHAR(35), GAL_AREACODECHAR(3)NOT NULL, GAL_PHONECHAR(8)NOT NULL, GAL_RATENUMBER(4,2), PRIMARY KEY(GAL_NUM)); Developing an E-R Diagram

4 4 SQL Commands to Create the PAINTING Table CREATE TABLE PAINTING ( PNTG_NUMCHAR(4)NOT NULLUNIQUE, PNTG_TITLECHAR(35), PNTG_PRICENUMBER(9,2), PTR_NUMCHAR(4)NOT NULL, GAL_NUMCHAR(4), PRIMARY KEY(PNTG_NUM) FOREIGN KEY(PTR_NUM) RERERENCES PAINTER ON DELETE RESTRICT ON UPDATE CASCADE, FOREIGN KEY(GAL_NUM) REFERENCES GALLERY ON DELETE RESTRICT ON UPDATE CASCADE); Developing an E-R Diagram

4 4 4 General Rules Governing Relationships among Tables 1.All primary keys must be defined as NOT NULL. 2.Define all foreign keys to conform to the following requirements for binary relationships. l 1:M Relationship l Weak Entity l M:N Relationship l 1:1 Relationship Developing an E-R Diagram

:M Relationships u Create the foreign key by putting the primary key of the “one” (parent) in the table of the “many” (dependent). u Foreign Key Rules: Developing an E-R Diagram

4 4 4 Weak Entity u Put the key of the parent table (strong entity) in the weak entity. u The weak entity relationship conforms to the same rules as the 1:M relationship, except foreign key restrictions: NOT NULL ON DELETE CASCADE ON UPDATE CASCADE 4 M:N Relationship u Convert the M:N relationship to a composite (bridge) entity consisting of (at least) the parent tables’ primary keys. Developing an E-R Diagram

:1 Relationships u If both entities are in mandatory participation in the relationship and they do not participate in other relationships, it is most likely that the two entities should be part of the same entity. Developing an E-R Diagram

4 4 4 CASE 1: M:N, Both Sides MANDATORY Developing an E-R Diagram Figure 4.50 Entity Relationships, M:N, Both Sides Mandatory

4 4 4 CASE 2: M:N, Both Sides OPTIONAL Developing an E-R Diagram Figure 4.51 Entity Relationships, M:N, Both Sides Optional

4 4 4 CASE 3: M:N, One Side OPTIONAL Developing an E-R Diagram Figure 4.52 Entity Relationships, M:N, One Side Optional

4 4 4 CASE 4: 1:M, Both Sides MANDATORY Developing an E-R Diagram Figure 4.53 Entity Relationships, 1:M, Both Sides Mandatory

4 4 4 CASE 5: 1:M, Both Sides OPTIONAL Developing an E-R Diagram Figure 4.54 Entity Relationships, 1:M, Both Sides Optional

4 4 4 CASE 6: 1:M, Many Side OPTIONAL, One Side MANDATORY Developing an E-R Diagram Figure 4.55 Entity Relationships, 1:M, Many Side Optional, One Side Mandatory

4 4 4 CASE 7: 1:M, One Side OPTIONAL, One Side MANDATORY Developing an E-R Diagram Figure 4.56 Entity Relationships, 1:M, One Side Optional, Many Side Mandatory

4 4 4 CASE 8: 1:1, Both Sides MANDATORY Developing an E-R Diagram Figure 4.57 Entity Relationships, 1:1, Both Sides Mandatory

4 4 4 CASE 9: 1:1, Both Sides OPTIONAL Developing an E-R Diagram Figure 4.58 Entity Relationships, 1:1, Both Sides Optional

4 4 4 CASE 10: 1:1, One Side OPTIONAL, One Side MANDATORY Developing an E-R Diagram Figure 4.59 Entity Relationships, 1:1, One Side Optional, One Side Mandatory

4 4 4 CASE 11: Weak Entity (Foreign key located in weak entity) Developing an E-R Diagram Figure 4.60 Entity Relationships, Weak Entity

4 4 4 CASE 12: Multivalued Attributes Developing an E-R Diagram Figure 4.61 Entity Relationships, Multivalued Attributes

4 4

4 4 The Chen Representation of the Invoicing Problem Figure 4.63

4 4 The Crow’s Foot Representation of the Invoicing Problem Figure 4.64

4 4 Figure 4.65 The Rein85 Representation of the Invoicing Problem

4 4 The IDEF1X Representation of the Invoicing Problem Figure 4.66

4 4 The Challenge of Database Design: Conflicting Goals 4 Conflicting Goals u Design standards (design elegance) u Processing speed u Information requirements 4 Design Considerations u Logical requirements and design conventions u End user requirements; e.g., performance, security, shared access, data integrity u Processing requirements u Operational requirements u Documentation