Entity Relationship Model Database Design Entity Relationship Model

Entity Relationship Model Main Components of the ER Model Entities 개체 Thing about which to collect data e.g., STUDENT, TEACHER Attributes 속성 Characteristics of entities Attribute Domain  set of possible values Relationships 관계 Association between entities Entity Relationship Diagram (ERD) ER model forms the basis of an ER diagram ERD represents the conceptual view 개념 뷰 of the database Main Components of the ER Model Entities 개체 Thing about which to collect data e.g., STUDENT, TEACHER Attributes 속성 Characteristics of entities Attribute Domain  set of possible values Relationships 관계 Association between entities Entity Relationship Diagram (ERD) ER model forms the basis of an ER diagram ERD represents the conceptual view 개념 뷰 of the database STUDENT TEACHER ID Major Name Office GPA email Database Design

E-R Model: Attribute Types Simple attribute 단순 속성 Composite attribute 복합 속성 → cannot be subdivided → can be subdivided into multiple attributes → Replace with multiple simple attributes Age Gender Marital Status Name  First Name Middle Name Last Name 34 Male Single James T. Kirk James Tiberius Kirk Single-valued attribute 일가 속성 Multi-valued attribute 다중값 속성 → can have only one value → can have many values → Avoid if possible Race Gender Birthdate Phone  Home Phone Cell Phone Work Phone Vulcan Male 1945-03-22 070-1234-5678 010-1234-5678 Name First Name Simple Simple Simple Middle Name Composite Last Name Database Design

E-R Model: Multi-valued Attributes 다중값 속성 Avoid Multi-valued attributes (MVA) Replace with multiple single-valued attributes (SVA). Car_Color  Car_TopColor, Car_TrimColor, Car_BodyColor, Car_InteriorColor could be problematic Create a new entity composed of original multi-valued attribute’s components Car_Color  CAR_COLOR (Car_Vin, Col_Section, Col_Color) Database Systems: Design, Implementation, & Management: Rob & Coronel Database Design

E-R Model: Multi-valued Attributes MVA → multiple SVA ID Name HomePhone CellPhone WorkPhone 1234 James Kirk 070-1234-5678 010-1234-5678 053-1234-5678 2345 Spock 010-2345-6789 3456 Khan 010-3456-7890 CellPhone2 CellPhone3 010-4567-7890 010-5678-7890 MVA → Entity ID Name 1234 James Kirk 2345 Spock 3456 Khan ID PhoneType PhoneNumber 1234 home 070-1234-5678 cell 010-1234-5678 work 053-1234-5678 2345 010-2345-6789 3456 010-3456-7890 cell2 010-4567-7890 cell3 010-5678-7890 3456 cell4 010-6789-7890 Database Design

E-R Model: Relationships Association between entities Connectivity & Cardinality are established by business rules Connectivity 관계유형 Type/Classification of Relationships 1:1, 1:M, M:N Cardinality 관계차수 (min, max) = minimum/maximum number of occurrences of the related entity Database Systems: Design, Implementation, & Management: Rob & Coronel Database Design

ERM: Relationship Strength Weak (non-identifying) Relationship PK of related entity does not contain PK component of parent entity 관련된 개체의 PK가 모개체의 PK요소를 포함하지 않음 Strong (identifying) Relationship PK of related entity contains PK component of parent entity 관련된 개체의 PK가 모개체의 PK요소를 포함함 CRS_ID CRS_Name Credit DB Database Design 3 IT Internet Technology WP Web Programming Class_ID CRS_ID Room DB-s15 DB 421 IT-s15 IT 403 DB-s16 IT-s16 CRS_ID CRS_Name Credit DB Database Design 3 IT Internet Technology WP Web Programming CRS_ID Section Room DB s15 421 IT 403 s16 Database Design

ERM: Relationship Strength Relationship strength is determined by table design (PK), but it can be driven by Business rules A student can decide his/her major after 2 years A student must decide his/her major in the beginning Dpt_ID CRS_Name LIS Library & Information Science CS Computer Science HIST History Stud_ID Dpt_ID Name 12345 LIS Kirk 23456 Spock 34567 CS Sulu 45678 Kahn Dpt_ID CRS_Name LIS Library & Information Science CS Computer Science HIST History Dpt_ID Snum Name LIS 15001 Kirk 15002 Spock CS Sulu 16001 Kahn Database Design

ERM: Relationship Participation Optional Participation 선택관계 (Child) Entity is not required to participate in a relationship Minimum cardinality of the optional entity is 0  CLASS is optional to Course - i.e., Course does not have to generate a class COURSE CLASS CRS_ID CRS_Name Credit DB Database Design 3 IT Internet Technology WP Web Programming CRS_ID Section Room DB s15 421 IT 403 s16 Database Design

ERM: Relationship Participation Mandatory Participation 필수관계 Entities must participate in a relationship Minimum cardinality of the mandatory entity is 1  CLASS is mandatory to Course - i.e., Course has to generate a class COURSE CLASS CRS_ID CRS_Name Credit DB Database Design 3 IT Internet Technology WP Web Programming CRS_ID CRS_Name Credit DB Database Design 3 IT Internet Technology Class_ID CRS_ID Room DBs15 DB 421 ITs15 IT 403 DBs16 Database Design

ERM: Relationship Strength vs. Participation Participation & Strength do not determine each other Relationship strength is determined by the composition of the related table’s PK Relationship participation is based on business rules EMPLOYEE and DEPENDENT Strong & Optional relationship An employee has many dependent. An employee may not have any dependent DEPENDENT is optional to EMPLOYEE A dependent belong to one employee. A dependent must belong to an employee PK of DEPENDENT must contain PK of EMPLOYEE Strong relationship DEPENDENT (weak) Dpd_ID Emp_ID Name 123s1 123 Kirk 234s1 234 Spock 345s2 Sulu 123s2 Kahn DEPENDENT (strong) Dseq Emp_ID Name s1 123 Kirk 234 Spock s2 Kahn Sulu 1 M EMPLOYEE has DEPENDENT (0,M) (1,1) Database Design

ERM: Relationship Strength vs. Participation Participation & Strength do not determine each other Relationship strength is determined by the composition of the related table’s PK Relationship participation is based on business rules PHD_STUD and CLASS Weak & Mandatory relationship A doctoral student can teach many classes. A doctoral student must teach a class CLASS is mandatory to PHD_STUD A class is taught by one doctoral student. A class can be taught by a professor PK of CLASS does not contain PK of PHD_STUD Weak relationship CLASS (weak) Class_ID CRS_ID st_ID pf_ID Room DBs15a DB g123 403 DBs15b kiyang ITs15a IT 421 ITs16a CLASS (strong) CRS_ID Section st_ID pf_ID Room DB s15 g123 403 kiyang IT 421 S15 1 M PHD_STUD teaches CLASS (1,M) (1,1) Database Design

ERM: Relationship Degree Relationship Degree indicates the number of associated entities. Unary Relationship Relationship exists between occurrences of same entity set e.g., Recursive relationship Binary Relationship Two entities associated Most common higher-order relationships are often decomposed into binary relationships Ternary Three entities associated e.g., DOCTOR, PATIENT, DRUG CRS_ID CRSname Prereq DB1 Database Design DB2 Web Database DB3 Database Projects Unary - a course is a prerequisite for another course (M:N) Ternary - CONTRIBUTOR donate money to research FUND (M:N) - RECIPIENT researchers are funded $ from FUND (M:N) PRS_ID Dr_ID Pat_ID Drug_ID expireDate 160101-121 Frnknstein55 4567 hrn21pr 16/06/25 100415-001 Strangelove21 thc16ts 20/04/15 160101-122 DrWho6 1234 trs10by 16/12/31 Database Design

ERM: Composite Entities Composite Entity (i.e., Bridge Entity) Transforms a M:N relationship into two 1:M relationships Contains primary keys of the “bridged” entities May also contain additional attributes that play no role in connective process Typically has strong relationships with the “bridged” entities M N STUDENT enrolls in CLASS A student doesn’t have to enroll in a class A class has to have minimum 10 students (0,M) (10,M) Class_ID Stud_ID Grade DB-s15 1234 A IT-s15 DB-s16 2345 B IT-s16 3456 C 1 M M 1 STUDENT ENROLL CLASS (0,M) (1,1) (1,1) (10,M) Database Design

ERM: Entity Supertype & Subtype Problem Unshared characteristics of certain entity subtypes (e.g. EMPLOYEE & PILOT) Solution Supertype (parent) & lower-level Subtype (child) entities Subtypes inherit the attributes and relationships of the supertype 1:1 relationship Shared attributes EMP_ID Name email Phone 1234 Kirk jtkiri@trek.org 010-1111-1111 2345 Spock spock@logic.vulcan 010-2222-2222 3456 Sulu sulu@star.ac.jp 070-1212-3456 0007 Pike cpike@trek.org 011-0001-0007 EMPLOYEE (Supertype) 1 is 1 Unique attributes PILOT (Subtype) EMP_ID Pilot_License FlightHR 1234 enpr-sc213g 1923 0007 enpr-cg123k 355 Database Design

Subtypes: Overlapping vs. Non-overlapping Non-overlapping (Disjoint) Overlapping Database Systems: Design, Implementation, & Management: Rob & Coronel Database Design

Exercises

Database Design: University Database Construct a data model of a typical university. To keep track of class & advising information by department (double-major allowed) Database Objectives Generate a course listing by semester (e.g., professor, department, class time & place) For each professor, generate the classes taught & student grades for each class. For each student, generate the complete listing of advising sessions (e.g, date, time, advisor) For each school, generate a list of all employees by department. For each department, generate a listing of all double-major students. Database Objectives Generate a course listing by semester (e.g., professor, department, class time & place) For each professor, generate the classes taught & student grades for each class. For each student, generate the complete listing of advising sessions (e.g, date, time, advisor) For each school, generate a list of all employees by department. For each department, generate a listing of all double-major students. Business Rules A school can have many departments. Each department belongs to one school. A department has many employees. An employee works in one departments. An employee can be a professor or a staff. A course generates many classes. Each class belongs to a course. A professor teaches many classes. A class is taught by one professor. A student can take many classes. A class has many students. A student belongs to one department. A department has many students. A student can double-major in a department. A department can have many double-major students. Database Design

Database Design: University Database Construct a data model of a typical university. To keep track of class & advising information by department (double-major allowed) Business Rules A school can have many departments. Each department belongs to one school. A department has many employees. An employee works in one departments. An employee can be a professor or a staff. A course generates many classes. Each class belongs to a course. A professor teaches many classes. A class is taught by one professor. A student can take many classes. A class has many students. A student belongs to one department. A department has many students. A student can double-major in a department. A department can have many double-major students. Business Rules A school can have many departments. Each department belongs to one school. A department has many employees. An employee works in one departments. An employee can be a professor or a staff. A course generates many classes. Each class belongs to a course. A professor teaches many classes. A class is taught by one professor A student can take many classes. A class has many students. A student belongs to one department. A department has many students. A student can double-major in a department. A department can have many double-major students. M 1 M DEPARTMENT has STUDENT 1 1 M 1 major2 M has ENROLL has M 1 M 1 SCHOOL EMPLOYEE 1 1 1 M M 1 is PROFESSOR CLASS COURSE Database Design

Database Design: University Database Convert the data model of a university to a relational schema. Sample DB Database Design

Database Design: University Database One of the database objective is to generate a list of students advised for a given year & dates of advising sessions for each students for each professor. Modify the ERD to support this DB objective. Business Rules A professor can meet many times with an advisee. A student can meet many times with a professor Sample DB M 1 M DEPARTMENT has STUDENT 1 M 1 1 1 major2 M M has has ENROLL ADVISING M M 1 M 1 1 1 1 1 M M 1 SCHOOL EMPLOYEE is PROFESSOR CLASS COURSE Database Design

Database Design: University Database Data model below corrects the following problems with the previous data model. The departmental advisor information is missing -- A student may consult with a professor who is not his/her departmental advisor A professor can advise many students. A student is advised by one professor. The department designation for courses is missing -- A professor may teach courses outside of his/her department. A department offers many courses. A course is offered by one department. Sample DB 1 offers M 1 M DEPARTMENT has STUDENT 1 M 1 1 1 major2 M M M has has ENROLL advises ADVISING M M 1 M 1 M 1 1 1 1 1 M M 1 SCHOOL EMPLOYEE is PROFESSOR CLASS COURSE Database Design