Data Modeling and the Entity-Relationship Model Database Concepts 1e Chapter 4 4 Data Modeling and the Entity-Relationship Model David M. Kroenke © 2002 by Prentice Hall

Chapter Objectives Learn the basic stages of a database development project Understand the purpose and role of a data model Know the principal components of the E-R data model Understand how to interpret both traditional and UML-style E-R diagrams Learn to construct traditional E-R diagrams © 2002 by Prentice Hall

Chapter Objectives (continued) Know how to represent 1:1, 1:N, N:M, and binary relationships with the E-R model Know how to represent recursive relationships with the E-R model Understand two types of weak entities and know how to use them Learn how to create an E-R diagram from source documents © 2002 by Prentice Hall

Three Stages of Database Development Requirements Stage Design Stage Implementation Stage © 2002 by Prentice Hall

The Requirements Stage Sources of requirements User Interviews Forms Reports Queries Use Cases Business Rules © 2002 by Prentice Hall

Requirements Become E-R Data Model After the requirements have been gathered, they are transformed into a Entity Relationship (E-R) Data Model E-R Models consist of Entities Attributes Identifiers Relationships © 2002 by Prentice Hall

Entities An entity is something that users want to track CUSTOMER PROJECT EMPLOYEE STUDENT © 2002 by Prentice Hall

Instance versus Classes An entity class is a collection of entities and is described by the structure and format of the entities An instance of an entity class is the representation of a particular entity © 2002 by Prentice Hall

Instance versus Classes CUSTOMER CustID CustName 78124 Jackson Co. 12735 Smither, Inc Two Entity Instances One Class © 2002 by Prentice Hall

Attributes Entities have attributes that describe the entity’s characteristics ProjectName StartDate ProjectType ProjectDescription Attributes have a data type and properties © 2002 by Prentice Hall

Identifiers Entity instances have identifiers An identifier will identify a particular instance in the entity class SocialSecurityNumber StudentID EmployeeID © 2002 by Prentice Hall

Identifier Types Uniqueness Composite Identifiers may be unique or nonunique If the identifier is unique, the data value for the identifier must be unique for all instances Composite A composite identifier consists of 2 or more attributes E.g., OrderNumber & LineItemNumber are both required © 2002 by Prentice Hall

Relationships Entities can be associated with one another in relationships Relationship degree defines the number of entity classes participating in the relationship Degree 2 is a binary relationship Degree 3 is a ternary relationship © 2002 by Prentice Hall

Degree 2 Relationship LOCKER EMPLOYEE © 2002 by Prentice Hall

Degree 3 Relationship DEALER MODEL MAKE © 2002 by Prentice Hall

One-to-One Binary Relationship A single entity instance in one entity class is related to a single entity instance in another entity class © 2002 by Prentice Hall

One-to-One Binary Relationship An employee may have no more than one locker; and A locker may only be accessible by one employee LOCKER EMPLOYEE 1:1 © 2002 by Prentice Hall

One-to-Many Binary Relationship An employee may only work for one department; and A department has several employees DEPARTMENT EMPLOYEE 1:N © 2002 by Prentice Hall

Many-to-Many Binary Relationship An employee may have several skills; and A particular skill may be held by several employees SKILL EMPLOYEE N:M © 2002 by Prentice Hall

One-to-Many Unary Relationship An employee may be managed by one other employee A employee may manage several employees EMPLOYEE 1:N © 2002 by Prentice Hall

Cardinality Each of the three types of binary relationships shown above have different maximum cardinalities Minimum cardinalities also exist. These values typically assume a value of Mandatory (one) or Optional (zero) © 2002 by Prentice Hall

One-to-One Binary Relationship with Minimum Cardinality An employee must have one locker; and A locker may be accessible by one or zero employees LOCKER EMPLOYEE 1:1 | © 2002 by Prentice Hall

Weak Entity | An employee may have zero or many dependents; and A dependent must have one employee EMPLOYEE 1:N | DEPENDENT © 2002 by Prentice Hall

Weak Entity Identifier A weak entity has a composite identifier First part of the identifier is the identifier for the weak entity itself Second part of the identifier is the identifier for the strong entity © 2002 by Prentice Hall

Weak Entity Relationships The relationship between a strong and weak entity is termed an identifying relationship if the weak entity is ID-dependent The relationship between a strong and weak entity is termed a non-identifying relationship if the weak entity is non-ID-dependent © 2002 by Prentice Hall

Unified Modeling Language Entity-Relationship Diagrams Unified Modeling Language (UML) is a set of structures and techniques for modeling and designing object-oriented programs (OOP) and applications © 2002 by Prentice Hall

Unified Modeling Language Entities ENTITY_NAME List of Attributes Identifier © 2002 by Prentice Hall

Unified Modeling Language Relationships 0..1 0..* 1..* 1..1 Mandatory One Optional One Optional Many Mandatory Many © 2002 by Prentice Hall

UML E-R Diagram Example An employee must report to one department; and A department may have zero or many employees EMPLOYEE EmployID EmployName Phone EmployID is identifier DEPARTMENT DeptID DeptName Location DeptID is identifier 0..* 1..1 © 2002 by Prentice Hall

UML Weak Entity EMPLOYEE DEPENDENT 1 0..N EmployID EmployName Phone EmployID is identifier DEPENDENT DepSSN DepName DepAge DepSSN is identifier 1 0..N © 2002 by Prentice Hall

Data Modeling and the Entity-Relationship Model Database Concepts 1e Chapter 4 4 Data Modeling and the Entity-Relationship Model David M. Kroenke © 2002 by Prentice Hall