CS4222 Principles of Database System 4/29/2018 CS4222 Principles of Database System 2. Entity-Relationship model Huiping Guo Department of Computer Science California State University, Los Angeles

Outline Overview of Database Design Process 4/29/2018 Outline Overview of Database Design Process Entity-Relationship (ER) modeling Entities Entity sets Relationship sets Constraints on entity sets Constraints on relationship sets 2. ER modeling CS4222_Su17

Overview of Database Design Process 2. ER modeling CS4222_Su17

Overview of Database Design Process Requirement analysis During this step, the database designers interview prospective users to understand and document their data requirements The result of this step is a concisely written set of users’ requirements In addition to data requirements, functional requirements are also specified Operations (retrieval and updates) that will be applied to the database 2. ER modeling CS4222_Su17

Overview of Database Design Process Conceptual design Use a high-level conceptual data model to create a conceptual schema The conceptual schema is a concise description of the data requirements of the users It includes detailed description of entities, relationships and constraints It does not include implementation details Can be used to communication with non-technical users It can also be used as a reference to ensure that all users’ data requirements are met and that the requirements do not conflict. 2. ER modeling CS4222_Su17

Overview of Database Design Process Logical design or data model mappings Translate a conceptual schema into DBMS data model Physical design and tuning The internal storage structures, indexes, access path, and file organizations for the database files are specified Application programs are designed and implemented as database transactions corresponding to the high level transaction specifications 2. ER modeling CS4222_Su17

Entity Relationship modeling Problem ER Diagram Tables Modeling (Conceptual design) Mapping (Logical design) Entity relationship diagram Abstractly describe the data Entities, relationships and attributes Easily mapped to Tables 2. ER modeling CS4222_Su17

ER Model Basics Entity Attributes 4/29/2018 ER Model Basics Entity Real-world object distinguishable from other objects An entity may be an object with a physical existence or an object with conceptual existence Attributes Each entity is described (in DB) using a set of attributes Example For example an EMPLOYEE entity may have the attributes Name, SSN, Address, Sex, BirthDate A particular entity has a value for each of its attributes For example a specific employee entity may have Name='John Smith', SSN='123456789', Address ='731, Fondren, Houston, TX', Sex='M', BirthDate='09-JAN-55‘ 2. ER modeling CS4222_Su17 3

Types of Attributes (1) Simple Composite Multi-valued 4/29/2018 Types of Attributes (1) Simple Each entity has a single atomic value for the attribute. For example, SSN or Sex. Composite The attribute may be composed of several components. For example: Address(Apt#, House#, Street, City, State, ZipCode, Country), or Name(FirstName, MiddleName, LastName). Composition may form a hierarchy where some components are themselves composite. Multi-valued An entity may have multiple values for that attribute. For example, Color of a CAR or PreviousDegrees of a STUDENT. Denoted as {Color} or {PreviousDegrees}. 2. ER modeling CS4222_Su17

4/29/2018 Types of Attributes (3) In general, composite and multi-valued attributes may be nested arbitrarily to any number of levels, although this is rare. For example PreviousDegrees of a STUDENT is a composite multi-valued attribute denoted by {PreviousDegrees (College, Year, Degree, Field)} Multiple PreviousDegrees values can exist Each has four subcomponent attributes: College, Year, Degree, Field 2. ER modeling CS4222_Su17

Example of a composite attribute 2. ER modeling CS4222_Su17

Types of Attributes (2) Derived attributes NULL values In some cases, two (or more) attributes are related Eg. Age and Birth_date of a person The age can be derived from Birth_date Age: derived attribute Birth_date: stored attribute NULL values In some cases, a particular entity may not have an applicable value for an attribute Eg. Aprtment_number attribute of an address A special value called NULL is created for such situations 2. ER modeling CS4222_Su17

Entity Types and Key Attributes (1) 4/29/2018 Entity Types and Key Attributes (1) Entities with the same basic attributes are grouped or typed into an entity type. For example, the entity type EMPLOYEE and PROJECT. An attribute of an entity type for which each entity must have a unique value is called a key attribute of the entity type. For example, SSN of EMPLOYEE. 2. ER modeling CS4222_Su17

Entity Types and Key Attributes (2) 4/29/2018 Entity Types and Key Attributes (2) A key attribute may be composite. VehicleTagNumber is a key of the CAR entity type with components (Number, State). An entity type may have more than one key. The CAR entity type may have two keys: VehicleIdentificationNumber (popularly called VIN) VehicleTagNumber (Number, State), a license plate number. Each key is underlined 2. ER modeling CS4222_Su17

Displaying an Entity type In ER diagrams, an entity type is displayed in a rectangular box Attributes are displayed in ovals Each attribute is connected to its entity type Components of a composite attribute are connected to the oval representing the composite attribute Each key attribute is underlined Multivalued attributes displayed in double ovals Derived attributes displayed in dashed ovals See CAR example on next slide 2. ER modeling CS4222_Su17

Entity Type CAR with two keys 2. ER modeling CS4222_Su17

Entity Set Each entity type will have a collection of entities stored in the database Called the entity set The Same name (CAR) is used to refer to both the entity type and the entity set The two terms will be used interchangeably Entity set is the current state of the entities of that type that are stored in the database 2. ER modeling CS4222_Su17

Car Entity Set 2. ER modeling CS4222_Su17

Example COMPANY Database 4/29/2018 Example COMPANY Database We need to create a database schema design based on the following (simplified) requirements of the COMPANY Database: The company is organized into DEPARTMENTs. Each department has a name, number and an employee who manages the department. We keep track of the start date of the department manager. A department may have several locations. Each department controls a number of PROJECTs. Each project has a unique name, unique number and is located at a single location. 2. ER modeling CS4222_Su17

Example COMPANY Database (Contd.) 4/29/2018 Example COMPANY Database (Contd.) We store each EMPLOYEE’s social security number, address, salary, sex, and birthdate. Each employee works for one department but may work on several projects. We keep track of the number of hours per week that an employee currently works on each project. We also keep track of the direct supervisor of each employee. Each employee may have a number of DEPENDENTs. For each dependent, we keep track of their name, sex, birthdate, and relationship to the employee. 2. ER modeling CS4222_Su17

Initial Design of Entity Types for the COMPANY Database Schema Based on the requirements, we can identify four initial entity types in the COMPANY database: DEPARTMENT PROJECT EMPLOYEE DEPENDENT Their initial design is shown on the following slide The initial attributes shown are derived from the requirements description 2. ER modeling CS4222_Su17

Initial Design of Entity Types 2. ER modeling CS4222_Su17

Refining the initial design by introducing relationships The initial design is typically not complete Some aspects in the requirements will be represented as relationships ER model has three main concepts: Entities (and their entity types and entity sets) Attributes (simple, composite, multivalued) Relationships (and their relationship types and relationship sets) We introduce relationship concepts next 2. ER modeling CS4222_Su17

Relationships and Relationship Types (1) 4/29/2018 Relationships and Relationship Types (1) A relationship relates two or more distinct entities with a specific meaning. For example, EMPLOYEE John Smith works on the ProductX PROJECT, or EMPLOYEE Franklin Wong manages the Research DEPARTMENT. Relationships of the same type are grouped or typed into a relationship type. For example, the WORKS_ON relationship type in which EMPLOYEEs and PROJECTs participate, or the MANAGES relationship type in which EMPLOYEEs and DEPARTMENTs participate. The degree of a relationship type is the number of participating entity types. Both MANAGES and WORKS_ON are binary relationships. 2. ER modeling CS4222_Su17

Relationship type vs. relationship set Is the schema description of a relationship Identifies the relationship name and the participating entity types Also identifies certain relationship constraints Relationship Set: The current set of relationship instances represented in the database The current state of a relationship type The two terms will be used interchangeably 2. ER modeling CS4222_Su17

4/29/2018 Relationship instances of the M:N WORKS_ON relationship between EMPLOYEE and PROJECT 2. ER modeling CS4222_Su17

Relationship type vs. relationship set Previous figures displayed the relationship sets Each instance in the set relates individual participating entities – one from each participating entity type In ER diagrams, we represent the relationship type as follows: Diamond-shaped box is used to display a relationship type Connected to the participating entity types via straight lines 2. ER modeling CS4222_Su17

Example Works_For Employee Department Works_On Employee Project The same entity type may be involved in different relationship sets Eg. Employee is involved in 2 relationship types: Works_For and Works_On 2. ER modeling CS4222_Su17

Attributes of Relationship types 4/29/2018 Attributes of Relationship types A relationship type can have attributes: For example, HoursPerWeek of WORKS_ON Its value for each relationship instance describes the number of hours per week that an EMPLOYEE works on a PROJECT. A value of HoursPerWeek depends on a particular (employee, project) combination Hours Works_On Employee Project 2. ER modeling CS4222_Su17

Recursive Relationship Type 4/29/2018 Recursive Relationship Type An relationship type with the same participating entity type in distinct roles Example: the SUPERVISION relationship EMPLOYEE participates twice in two distinct roles: supervisor (or boss) role supervisee (or subordinate) role Each relationship instance relates two distinct EMPLOYEE entities: One employee in supervisor role One employee in supervisee role 2. ER modeling CS4222_Su17

Displaying a recursive relationship 4/29/2018 Displaying a recursive relationship In a recursive relationship type. Both participations are same entity type in different roles. For example, SUPERVISION relationships between EMPLOYEE (in role of supervisor or boss) and (another) EMPLOYEE (in role of subordinate or worker). In ER diagram, need to display role names to distinguish participations. Supervision supervisor subordinate Employees 2. ER modeling CS4222_Su17

Constraints on Entity Sets Domain Constraints on Entity Sets Cardinality constrains on relationship sets Participation Constraints 2. ER modeling CS4222_Su17

Domain Constraints on Entity Sets An attribute is associated with a domain. The value of the attribute for each entity is constrained to be in the domain only. Example: Gender: “F” or “M” Age: “> 20” 2. ER modeling CS4222_Su17

Cardinality constrains on relationship sets Many-to-Many Relationship (M:N) By default One-to-Many Relationship(1:N) Many-to-One Relationship (N:1) One-to-One Relationship (1:1) In ER diagram, cardinality ratio(1:1, 1:N, N:1, or M:N) is shown by placing appropriate numbers on the relationship edges 2. ER modeling CS4222_Su17

Many-to-Many Relationship in ER diagram An entity in A is associated to multiple entities in B An entity in B is associated to multiple entities in A A B 2. ER modeling CS4222_Su17

Many-to-Many Relationship Example: Multiple students can take the same course One student can take multiple courses M N Students Take Courses 2. ER modeling CS4222_Su17

One-to-Many Relationship An entity in A is associated to many entities in B Or an entity in B is associated to at most one entity in A A B 2. ER modeling CS4222_Su17

One-to-Many Relationship Example A supervisor can supervise multiple students A student has at most one supervisor 1 N Supervisor Supervise Students 2. ER modeling CS4222_Su17

One-to-One Relationship An entity in A is associated to at most one entity in B And an entity in B is associated to at most one entity in A Example A woman is married to at most one man A man is married to at most one woman Is_Married_to 1 1 Women Men 2. ER modeling CS4222_Su17

Participation Constraints Two kinds of participation constraints Total participation Each department must have a manager The participation of the Departments in the relationship set Manages is said to be total Indicated in ER diagram by double lines Partial participation A participation that is not total Indicated in ER diagram by single lines 2. ER modeling CS4222_Su17

Participation Constraints 4/29/2018 Participation Constraints Each department must have a manager Manages Employee Department Employee Department Manages 2. ER modeling CS4222_Su17

Exercise Each customer can have multiple accounts customers custacct accounts opendate Each customer can have multiple accounts Several customers can share the same accounts 2. ER modeling CS4222_Su17

Exercise (cont.) Each customer has at most one account 1 customers custacct accounts opendate Each customer has at most one account Each account is owned by at least one customer 2. ER modeling CS4222_Su17

Exercise (cont.) Each customer has at least one account 1 N customers custacct accounts opendate Each customer has at least one account Each accounts is owned by exactly one customer 2. ER modeling CS4222_Su17