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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Q & A Questions?