Entity Relationship Model: E-R Modeling

Basic Modeling Concepts “Description or analogy used to visualize something that cannot be directly observed” -Webster’s Dictionary - Data Models Relatively simple representation of complex real-world data structures Facilitate communication Enhance understanding Database System

Degrees of Data Abstraction Conceptual Global view of data identify and describe main data items (e.g. E-R diagram) Hardware and software independent Internal Representation of database as seen by DBMS adapt conceptual model to specific DBMS (e.g. Access tables) Software dependent External Users’ views of data environment group requirements & constraints subsets into functional modules e.g. student registration module, class scheduling module Facilitates development & revalidates the conceptual model Physical Lowest level of abstraction determine of physical storage devices and access methods software and hardware dependent Database System

Data Abstraction Models Database Systems: Design, Implementation, & Management: Rob & Coronel Database System

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

Relationship Strengths Existence Dependence Entity’s existence depends on the existence of related entities. Existence-independent entities can exist apart from related entities. Weak Entities Existence dependent entities Cannot exist without the related entity e.g. EMPLOYEE claims DEPENDENT  DEPENDENT is existence-dependent on EMPLOYEE Strong Entities Can exist apart from all of the related entity Table with a primary key that does not contain the primary key of related table e.g. EMPLOYEE has SPOUSE  EMPLOYEE is existence-independent of SPOUSE Database System

ERM: Relationship Strength Identifying (Strong) Relationship PK of related entity contains PK component of parent entity 관련된 개체의 PK가 모개체의 PK요소를 포함함 Non-identifying (Weak) Relationship PK of related entity does not contain PK component of parent entity 관련된 개체의 PK가 모개체의 PK요소를 포함하지 않음 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 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 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

Relationship: Weak Entities Database Systems: Design, Implementation, & Management: Rob & Coronel Strong vs. Weak entities Strong Entity = existence-independent entity in a strong relationship Weak Entity existence-dependent entity in a strong relationship inherits all or part of its primary key from parent entity entity w/ clipped corners in CF model, double-walled in Chen model Database System

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

M:N to 1:M Conversion STUDENT CLASS CLS_ID STUDENT CLASS ENROLL STU_ID STU_NAME CLS_ID 1234 John Doe 10012 10014 2341 Jane Doe 10013 10023 CLS_ID CRS_NAME CLS_SECT STU_ID 10012 L546 1 1234 10013 2 2341 10014 L548 10023 L571 STU_ID STU_NAME 1234 John Doe 2341 Jane Doe CLS_ID STU_ID ENR_GRD 10012 1234 B 10013 2341 A 10014 C 10023 CLS_ID CRS_NAME CLS_SEC 10012 L546 1 10013 2 10014 L548 10023 L571 STUDENT CLASS ENROLL Move the foreign key columns to create a bridge table & add attributes if needed. Collapse the duplicate records in remaining tables. Database System

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 System

Developing ERD Iterative Process Create detailed narrative of organization’s description of operations Identify business rules based on description of operations Identify main entities and relationships from business rules Develop initial ERD Identify attributes and primary keys that adequately describe entities Revise and review ERD Database System

ERD Example: Narrative Narrative of operational environment Tiny College is divided into several schools Each school is composed of several departments Each school is administered by a dean Each dean is a member of administrators group A dean is also a professor and may teach classes Administrators and professors are employees Each department offers several courses Each course may have several sections (classes) Each department has many professors and students One of the professors chairs the department Each professor may teach up to 4 classes A student may enroll in several classes Each student has an advisor in his/her department Each student belong to only one department Database System

ERD Example: Supertype/Subtype - Each school is administered by a dean - Each dean is a member of administrators group - A dean is also a professor and may teach classes - Administrators and professors are employees Database Systems: Design, Implementation, & Management: Rob & Coronel Professors and administrators have unique characteristics not present in other employees EMPLOYEE supertype, PROFESSOR & ADMINISTRATOR (overlapping) subtypes Professors and administrators have same set of characteristics collapse PROFESSOR and ADMINISTRATOR entities Database System

ERD Example: ERD segment 1 Database Systems: Design, Implementation, & Management: Rob & Coronel Professors are employees A professor may be a dean Each school is administered by a dean Each school is composed of several departments Database System

ERD Example: ERD segment 2 & 3 Database Systems: Design, Implementation, & Management: Rob & Coronel Each department offers several courses Each course may have several sections (classes) Database System

ERD Example: ERD segment 4 & 5 Database Systems: Design, Implementation, & Management: Rob & Coronel Each department has many professors One of the professors chairs the department Each professor may teach up to 4 classes Database System

ERD Example: ERD segment 6 & 7 Database Systems: Design, Implementation, & Management: Rob & Coronel A student may enroll in several classes Each department has many students Each student belong to only one department Database System

ERD Example: ERD segment 8 & 9 Database Systems: Design, Implementation, & Management: Rob & Coronel Each student has an advisor Class is held in class rooms Database System

ERD Example: ERD components Database Systems: Design, Implementation, & Management: Rob & Coronel Database System

ERD Example: Merging ERD segments Database System

ERD Example: Completed ERD Database Systems: Design, Implementation, & Management: Rob & Coronel Database System

Sample Database Database System

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