1. Data Modeling and the Entity-Relationship Model
Database Concepts 1e
Chapter 3 3
Data Modeling and the Entity-Relationship Model
Didimus Rumpak, M.Si.
© 2009 by Prentice Hall

2. 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
© 2009 by Prentice Hall

3. 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
© 2009 by Prentice Hall

4. Three Stages of Database Development
Requirements Stage
Design Stage
Implementation Stage
© 2009 by Prentice Hall

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

6. 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
© 2009 by Prentice Hall

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

8. 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
© 2009 by Prentice Hall

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

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

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

12. 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
© 2009 by Prentice Hall

13. 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
© 2009 by Prentice Hall

14. Degree 2 Relationship
LOCKER
EMPLOYEE
© 2009 by Prentice Hall

15. Degree 3 Relationship
DEALER
MODEL
MAKE
© 2009 by Prentice Hall

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

17. 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
© 2009 by Prentice Hall

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

19. 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
© 2009 by Prentice Hall

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

21. 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)
© 2009 by Prentice Hall

22. 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 |
© 2009 by Prentice Hall

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

24. 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
© 2009 by Prentice Hall

25. 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
© 2009 by Prentice Hall

26. 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
© 2009 by Prentice Hall

27. Unified Modeling Language Entities
ENTITY_NAME
List of Attributes
Identifier
© 2009 by Prentice Hall

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

29. 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
© 2009 by Prentice Hall

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

31. Data Modeling and the Entity-Relationship Model
Database Concepts 1e
Chapter 3 3
Data Modeling and the Entity-Relationship Model
Didimus Rumpak, M.Si.
© 2009 by Prentice Hall