CS4222 Principles of Database System 4/18/2018 CS4222 Principles of Database System 3. Entity-Relationship model 2 Huiping Guo Department of Computer Science California State University, Los Angeles
Outline Weak entity sets Relationships of higher degree 4/18/2018 Outline Alternative (min, max) notation for relationship constraints Weak entity sets Relationships of higher degree Design choices for ER conceptual design Data Modeling Tools In class exercises 3. ER modeling 2 CS4222_Su17
Alternative (min, max) notation for relationship constraints 4/18/2018 Alternative (min, max) notation for relationship constraints Specified on each participation of an entity type E in a relationship type R Specifies that each entity e in E participates in at least min and at most max relationship instances in R Default(no constraint): min=0, max=n (signifying no limit) Must have minmax, min0, max 1 Derived from the knowledge of mini-world constraints 3. ER modeling 2 CS4222_Su17
Alternative (min, max) notation for relationship constraints Examples: A department has exactly one manager and an employee can manage at most one department. Specify (0,1) for participation of EMPLOYEE in MANAGES Specify (1,1) for participation of DEPARTMENT in MANAGES An employee can work for exactly one department but a department can have any number of employees. Specify (1,1) for participation of EMPLOYEE in WORKS_FOR Specify (1,n) for participation of DEPARTMENT in WORKS_FOR 3. ER modeling 2 CS4222_Su17
Alternative (min, max) notation for relationship constraints 4/18/2018 Alternative (min, max) notation for relationship constraints Read the min,max numbers next to the entity type and looking away from the entity type 3. ER modeling 2 CS4222_Su17
Weak Entity Sets What are the weak entity sets? 4/18/2018 Weak Entity Sets What are the weak entity sets? Entities that do not have sufficient attributes to form a key They need to “borrow” the primary key from another entity set to form a key. Partial key of a weak entity set The set of attributes of a weak entity set that uniquely identify a weak entity for a given owner entity The identifying Owner The entity set that “lends” the primary key to a weak entity set Weak Entities are identified by the combination of: A partial key of the weak entity type The particular entity they are related to in the identifying entity type 3. ER modeling 2 CS4222_Su17
Weak Entity Sets The following constraints must hold: Owner entity set and weak entity set must participate in a one-to-many relationship set, which is called identifying relationship set of the weak entity set Weak entity set must have total participation in this identifying relationship set. 3. ER modeling 2 CS4222_Su17
Weak Entity Sets Example: DEPENDENT is a weak entity type A DEPENDENT entity is identified by the dependent’s name, and the specific EMPLOYEE with whom the dependent is related Name of DEPENDENT is the partial key EMPLOYEE is its identifying entity type via the identifying relationship type DEPENDENT_OF 3. ER modeling 2 CS4222_Su17
Weak Entity Sets Rectangle with double lines Broken lines Weak identity sets Identifying relationship set Broken lines Partial key of the weak identity set name ssn name sex birthdate 1 N Employees Dependents_of Dependents Dependents relationship sex 3. ER modeling 2 CS4222_Su17
Refining the COMPANY database schema by introducing relationships By examining the requirements, six relationship types are identified All are binary relationships( degree 2) Listed below with their participating entity types: WORKS_FOR (between EMPLOYEE, DEPARTMENT) MANAGES (also between EMPLOYEE, DEPARTMENT) CONTROLS (between DEPARTMENT, PROJECT) WORKS_ON (between EMPLOYEE, PROJECT) SUPERVISION (between EMPLOYEE (as subordinate), EMPLOYEE (as supervisor)) DEPENDENTS_OF (between EMPLOYEE, DEPENDENT) 3. ER modeling 2 CS4222_Su17
4/18/2018 ER DIAGRAM – Relationship Types are: WORKS_FOR, MANAGES, WORKS_ON, CONTROLS, SUPERVISION, DEPENDENTS_OF 3. ER modeling 2 CS4222_Su17
Discussion on Relationship Types 4/18/2018 Discussion on Relationship Types In the refined design, some attributes from the initial entity types are refined into relationships: Manager of DEPARTMENT -> MANAGES Works_on of EMPLOYEE -> WORKS_ON Department of EMPLOYEE -> WORKS_FOR etc In general, more than one relationship type can exist between the same participating entity types MANAGES and WORKS_FOR are distinct relationship types between EMPLOYEE and DEPARTMENT Different meanings and different relationship instances. 3. ER modeling 2 CS4222_Su17
COMPANY ER Schema Diagram using (min, max) notation 4/18/2018 COMPANY ER Schema Diagram using (min, max) notation 3. ER modeling 2 CS4222_Su17
Relationships of Higher Degree 4/18/2018 Relationships of Higher Degree Relationship types of degree 2 are called binary Relationship types of degree 3 are called ternary and of degree n are called n-ary In general, an n-ary relationship is not equivalent to n binary relationships Constraints are harder to specify for higher-degree relationships (n > 2) than for binary relationships 3. ER modeling 2 CS4222_Su17
Example: a ternary relationship Supplier Supply part for a project 3. ER modeling 2 CS4222_Su17
3. ER modeling 2 CS4222_Su17
Discussion of n-ary relationships (n > 2) In general, 3 binary relationships can represent different information than a single ternary relationship 3. ER modeling 2 CS4222_Su17
Discussion of n-ary relationships (n > 2) Suppose that Can_Supply, includes an instance (s,p) whenever supplier s can supply part p (to any project) Uses includes an instance (j,p) whenever a project j uses part p Supplies includes an instance (s, j) whenever supplier s supplies some part to project j The existence of the 3 relationship instances (s,p), (j,p), and (s,j) does not necessarily imply that an instance (s,j,p) exits in the ternary relationship Supply, because the meaning is different 3. ER modeling 2 CS4222_Su17
Discussion of n-ary relationships (n > 2) If needed, the binary and n-ary relationships can all be included in the schema design If only binary relationship is allowed, a ternary relationship such as Supply must be represented as a weak entity without partial key and with three identifying relationships 3. ER modeling 2 CS4222_Su17
Ternary relationship as a weak entity 3. ER modeling 2 CS4222_Su17
Design choices for ER conceptual design The conceptual design is an iterative refinement process The initial design is created and then iteratively refined until the most suitable design is reached Refinements A concept may be first modeled as an attribute and then refined into a relationship if the attribute is a reference to another entity type An attribute that exists in several entity type may be promoted to an independent entity type Eg. Suppose in the University database, several entity types suchas as Student, Instructor and Course Each has an attribute Department in the initial design An entity type department is created with a single attribute dept_name and is related to the three entity types via appropriate relationships 3. ER modeling 2 CS4222_Su17
Design choices for ER conceptual design Refinements An inverse refinement to the previous case may be applied Eg. If an entity type exists in the initial design with a single attribute Dept_name and is related to only one other entity type, Student In this case, Department may be reduced to an attribute of Student 3. ER modeling 2 CS4222_Su17
Summary of notation for ER diagrams 3. ER modeling 2 CS4222_Su17
4/18/2018 Data Modeling Tools A number of popular tools that cover conceptual modeling and mapping into relational schema design. Examples: ERWin, S- Designer (Enterprise Application Suite), ER- Studio, etc. POSITIVES: Serves as documentation of application requirements, easy user interface - mostly graphics editor support NEGATIVES: Most tools lack a proper distinct notation for relationships with relationship attributes Mostly represent a relational design in a diagrammatic form rather than a conceptual ER-based design 3. ER modeling 2 CS4222_Su17
Some of the Currently Available Automated Database Design Tools 4/18/2018 Some of the Currently Available Automated Database Design Tools COMPANY TOOL FUNCTIONALITY Embarcadero Technologies ER Studio Database Modeling in ER and IDEF1X DB Artisan Database administration, space and security management Oracle Developer 2000/Designer 2000 Database modeling, application development Popkin Software System Architect 2001 Data modeling, object modeling, process modeling, structured analysis/design Platinum (Computer Associates) Enterprise Modeling Suite: Erwin, BPWin, Paradigm Plus Data, process, and business component modeling Persistence Inc. Pwertier Mapping from O-O to relational model Rational (IBM) Rational Rose UML Modeling & application generation in C++/JAVA Resolution Ltd. Xcase Conceptual modeling up to code maintenance Sybase Enterprise Application Suite Data modeling, business logic modeling Visio Visio Enterprise Data modeling, design/reengineering Visual Basic/C++ 3. ER modeling 2 CS4222_Su17
4/18/2018 Exercise 1 Design a DB representing cities, counties, and states in the US: For states, record the name, population, and state capital (a city). For counties, record the name, the population, and the located state. For cities, record the name, the population, the located state and the located county. 3. ER modeling 2 CS4222_Su17 9
Design 1 Problem: County Population is repeated for each city. 1 1 1 Co. Popu. Co. name Popu. 1 cities Located states name Ci. Popu. Ci. name 1 1 capital Problem: County Population is repeated for each city. 3. ER modeling 2 CS4222_Su17
Design 2 Co. Popu. Co. name Popu. name 1 counties Located states 1 Belongs-to 1 1 capitals cities The population of a county is derived from those of its cities. Ci. Popu. Ci. name 3. ER modeling 2 CS4222_Su17
Exercise 2 Consider the following ER diagram. 3. ER modeling 2 CS4222_Su17
Exercise 2 Assume that a course may or may not use a textbook, but that a text by definition is a book that is used in some course. A course may not use more than five books. Instructors teach from two to four courses. Supply (min, max) constraints on this diagram. State clearly any additional assumptions you make. 3. ER modeling 2 CS4222_Su17