1. Unit 3: Entity-Relationship Modeling
IT238: Data Modeling and Database Design
Unit 3: Entity-Relationship Modeling
Instructor: Qing Yan, M.D., Ph.D.

2. Unit 3 Objectives
Demonstrate how to develop a Presentation Layer ER model
Demonstrate how to progress from the Presentation layer to the Design-specific ER Model
Chapter 1 – Database Systems: Architecture and Components

3. Unit 3 To-Do List Complete the reading Textbook and Web
Participate in the discussion board 30 points
Attend the introductory seminar or complete FLA quiz 20 points
Complete the unit assignment 50 points
Chapter 1 – Database Systems: Architecture and Components

4. Assignment rubric 1. specified unique identifiers 10
2. specified relationship types that exist among various entity types 20
3. captured business rules within ERD 15
4. list semantic integrity constraints where business rule could not be captured in the ERD 5
Total (Sum of all points) 50
Chapter 3 – Entity-Relationship Modeling

5. The storyline The factory has several departments.
A department may have many employees, but at least three. Every employee works for one and only one department. Every department has a manager – only one manager per department. Clearly, a manager is an employee of the company; but, all employees are not managers.
Chapter 3 – Entity-Relationship Modeling

6. The storyline
A department may have many machines, and every machine is assigned to a specific department.
A machine may go for maintenance numerous times.
Maintenance is done on a machine only once on a given day.
Some machines are so new that they may not have gone for maintenance yet.
Chapter 3 – Entity-Relationship Modeling

7. The storyline
Products are produced on machines. A product can be an assembly of several different components or a single piece.
Every product/component goes through one or more machines for appropriate production operations.
Likewise, several products may go through a particular machine for some standard process.
Chapter 3 – Entity-Relationship Modeling

8. The storyline Designers design the products. Some well qualified
designers may design more than one product. All designers are employees of the factory.
Operators, who are also employees of the factory, operate these machines. Due to multiple shifts, several operators operate the same machine. All operators are routinely assigned to work on only one machine and no operator is kept idle.
A machine is never kept idle either, except when it is out for maintenance.
Chapter 3 – Entity-Relationship Modeling

9. The requirements
The database should capture an employee’s name, which would include first name, last name, and middle initial. It must also capture gender, address, and salary. An employee’s salary cannot exceed his/her manager’s salary. Social Security number (SSN) uniquely identifies an employee.
Likewise, department number, department name, type, and location, must be captured. The department number and department name are both unique identifiers of a department.
Chapter 3 – Entity-Relationship Modeling

10. The requirements
Every machine will have a unique machine number. It will also consist of other details like name of machine, type, and vendor’s name. When a machine goes for maintenance, maintenance date for that machine needs to be captured.
A product is identified by its component ID. Component name and description must also be recorded. It should be possible to compute the number of components in a product.
Chapter 3 – Entity-Relationship Modeling

11. The requirements
When a component goes through machining, the starting time, completion time, and hours of machining for each product on every machine must be captured.
The information about a designer includes his/her qualification, specialization field, and experience in years.
Operators, who are responsible for operating the machines, belong to a labor union and have certain skill sets associated with them.
Chapter 3 – Entity-Relationship Modeling

12. Notation for drawing the ER diagram
Figure 3.2 Summary of Presentation Layer ER diagram notation
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

13. Notation (continued)
Figure 3.2 Summary of Presentation Layer ER diagram notation (continued)
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

14. Key Concepts Entity-relationship (ER) diagram (ERD)
The part of an ER model that portrays entity types, attributes for each entity types, and relationships among the entity types.
 Presentation Layer ER model/schema
An entity-relationship modeling tool that serves as a communications device between the analyst and the end-user community; consists of a Presentation Layer ER diagram and semantic integrity constraints  
Chapter 1 – Database Systems: Architecture and Components

15. Key Concepts Synthesis approach
A bottom-up approach for developing an ER diagram where attributes are grouped into entity types based on apparent commonalities among the attributes.
  Analysis approach
A top-down approach for developing an ER diagram that begins by identifying entity types and then focuses on gathering attributes that appear to belong to individual entity types.
Chapter 3 – Entity-Relationship Modeling

16. Vocabulary
Exclusive arc-Indicates that two or more relationship types are mandatorily exclusive
Inclusive arc-Indicates that two or more relationship types are mandatorily inclusive
Noninclusive arc-Indicates that two or more relationship types are optionally inclusive
Chapter 3 – Entity-Relationship Modeling

17. Vocabulary
Restrict rule-A deletion rule where the deletion of a parent entity in a relationship is restricted if all child entities related to the parent in the relationship should not be deleted.
Cascade rule-A deletion rule where the deletion of a parent entity in a relationship also causes all child entities related to the parent in the relationship to be deleted.
Chapter 3 – Entity-Relationship Modeling

18. Vocabulary
Superclass (SC)-A generic class of entity that includes one or more entity type occurrences.
Subclass (sc)-An entity type that is a member of a superclass.
Chapter 3 – Entity-Relationship Modeling

19. Vocabulary
Generalization-A process that crystallizes the common properties (attributes) shared by a set of entity types into a generic entity type (SC).
Defining attribute-The attribute in the superclass used to define the predicate in an attribute defined specialization.
Chapter 3 – Entity-Relationship Modeling

20. Vocabulary
Aggregation-A construct that allows modeling a “whole/part” association as an “Is-a-part-of” relationship between a superclass and a subclass.
Chapter 3 – Entity-Relationship Modeling

21. Application of ER Modeling Grammar to the Conceptual Modeling Process
The ER model for conceptual modeling serves two major purposes
As a communication/presentation device used by an analyst to interact with the end-user community (i.e., the Presentation Layer ER Model/Schema)
As a design tool at the highest level of abstraction to convey a deeper level of understanding to the database designer (i.e., the Design-Specific ER Model/Schema)
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

22. The ER Model The ER model includes:
An ER diagram (ERD) portraying entity types, attributes for each entity type, and relationships among entity types
Semantic integrity constraints that reflect the business rules about data not captured in the ER diagram.
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

23. The ER Model (continued)
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

24. Notation Figure 3.2 Summary of Presentation Layer ER diagram notation
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

25. Notation (continued)
Figure 3.2 Summary of Presentation Layer ER diagram notation (continued)
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

26. Presentation Layer ER Model (An End-User Communication/Presentation Device)
Not a Science !
Art? Engineering? - Artistic engineering or Engineered art !
Heuristic (Intuitive), iterative process
Recursive incremental refinement
Target Audience: End-user community
Technology-independent
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

27. The Synthesis Approach to Generate an Initial Set of Entity Types and Attributes
List all discernable data elements and treat them as attributes
Group these attributes based on apparent commonalities
Designate each cluster of attributes as an entity type
Review leftover data elements and investigate the possibility that some of them serve as links among the entity types previously identified
Designate these links as relationship types
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

28. The Analysis Approach to Generate an Initial Set of Entity Types and Attributes
Begin by searching for things that can be labeled by singular nouns and call these things entity types
Gather properties that appear to belong to individual entity types and label them as attributes of a particular entity type
Be sensitive throughout the process to the identification of relationships among the various entity types
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

29. Bearcat, Incorporated Initial Set of Entity Types
Read through the vignette on pages 75-77
Identify entity types
Plant Company ?
Project - Manager ?
Employee - Supervisor ?
Dependent
Credit Union Account
Hobby
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

30. Bearcat, Incorporated Revised Set of Entity Types
Read through the vignette on pages 75-77
Identify entity types
Plant Company x
Project - Manager x
Employee - Supervisor x
Dependent
Credit Union Account
Hobby
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

31. Development of Presentation Layer ER Model
Divide story into meaningful “chunks” and identify relationship(s) among entity types
Version 0 of ER diagram results: a punctuated equilibrium
Go back and read the story (strike out story lines already captured if need be) and refine entity types and relationship types of the ER diagram based on additional facts discerned
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

32. Development of Presentation Layer ER Model
Gather business rules that can’t be captured in the ERD into a list of Semantic Integrity Constraints, a supplement to the ERD
Repeat last two steps (as many times as necessary) until all aspects of the story (i.e., the business rules) have been accounted for in the ER model
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

33. Development of Presentation Layer ER Model (continued)
Note: The relationship shown models the italicized text
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

34. Development of Presentation Layer ER Model (continued)
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

35. Presentation Layer ER Diagram
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

36. Presentation Layer Semantic Integrity Constraints
Semantic integrity constraints are grouped into the following categories:
Attribute level business rules
Entity level business rules
Business rules governing entity deletion
Miscellaneous business rules
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

37. Design-Specific ER Model (Technology-Independent Design Tool)
Not a Science !
Art? Engineering?
Not an Art anymore; more of an Engineering
Systematic process
Target Audience: Database Designer/Administrator
Coarse granularity
Fine granularity
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

38. Coarse-granular Design-Specific ER Model
Tasks
Collect additional attribute characteristics relevant to design/implementation (e.g., data type, size) and prepare an updated list of Semantic Integrity Constraints
Introduce a technically more precise notation, viz., (min, max) notation, for expressing the structural constraints of a relationship type
Map deletion rules to the ER diagram
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

39. Deletion Constraints
Restrict Rule (R): If a parent entity in a relationship is deleted and if all child entities related to this parent in this relationship should not be deleted, then the deletion of the parent should be disallowed
Cascade Rule (C): If a parent entity in a relationship is deleted and if all child entities related to this parent in this relationship should also be deleted, the cascade rule applies
Note: Conventionally, when a deletion constraint is not specified, the restrict rule is implied by default
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

40. Deletion Constraints (continued)
Set Null Rule (N): If a parent entity in a relationship is deleted and if all child entities related to this parent in this relationship should be retained but no longer referenced to this parent, the ‘set null’ rule applies
Set Default Rule (D): If a parent entity in a relationship is deleted and if all child entities related to this parent in this relationship should be retained but no longer referenced to this parent but should be referenced to a predefined default parent, the ‘set default’ rule applies
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

41. Fine-granular Design-Specific ER Model
Tasks
Map the additional attribute characteristics to the ER diagram
Decompose ER constructs preparatory to logical model mapping
Decomposition of multi-valued attribute
Decomposition of m:n cardinality constraint (ratio)
Generate an updated list of Semantic Integrity Constraints
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

42. Summary Presentation Layer ER Model
Diagram + Integrity Constraints
Coarse-Granular ER Model Fine-Granular ER Model
From: Umanath, N.S., & Scamell, R. (2007). Data Modeling and Database Design. Boston: Thomson Course Technology.
Chapter 3 – Entity-Relationship Modeling

43. Q & A
Questions?