1. Data Modeling and the Entity-Relationship Model
CSCI260
Database Applications
Chapter Four
Data Modeling and the Entity-Relationship Model

2. Chapter Objectives Learn the basic stages of database development
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
Know how to represent 1:1, 1:N, N:M, and binary relationships with the E-R model

3. Chapter Objectives (continued)
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

4. Three Stages of Database Development
Requirements Stage
Design Stage
Implementation Stage

5. The Requirements Stage
Sources of requirements
User Interviews
Forms
Reports
Queries
Use Cases
Business Rules

6. Requirements Become the E-R Data Model
After the requirements have been gathered, they are transformed into an Entity Relationship (E-R) Data Model
E-R Models consist of
Entities
Attributes
Identifiers
Relationships

7. Entities An entity is something that users want to track CUSTOMER
PROJECT
EMPLOYEE
STUDENT

8. Instance versus Classes
An entity class is a description of the structure and format of the occurrences of the entity
An entity instance of a specific occurrence of an entity class

9. Instance versus Classes
CUSTOMER
CustID
CustName
78124
Jackson Co.
12735
Smither, Inc
Two
Entity
Instances
Class

10. Instance versus Classes

11. Attributes
Entities have attributes that describe the entity’s characteristics
ProjectName
StartDate
ProjectType
ProjectDescription
Attributes have a data type and properties

12. Identifiers Entity instances have identifiers
An identifier will identify a particular instance in the entity class
SocialSecurityNumber
StudentID
EmployeeID

13. 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

14. 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

15. Degree 2 Relationship - Binary
LOCKER
EMPLOYEE

16. Degree 3 Relationship - Ternary
DEALER
MODEL
MAKE

17. Example Relationships

18. One-to-One Binary Relationship
A single entity instance in one entity class is related to a single entity instance in another entity class

19. 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

20. One-to-Many Binary Relationship
An employee may only work for one department; and
A department has several employees
DEPARTMENT
EMPLOYEE
1:N

21. 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

22. One-to-Many Unary Relationship
An employee may be managed by one other employee
A employee may manage several employees
EMPLOYEE
1:N

23. Relationship Examples

24. Relationship Examples

25. One-to-Many Unary Relationship
An employee may be managed by one other employee
A employee may manage several employees
EMPLOYEE
1:N

26. 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)

27. 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 |

28. One-to-One Binary Relationship with Minimum Cardinality

29. Weak Entity
A weak entity is an entity that cannot exist in the database without the existence on another entity
For example, an employee’s dependents cannot exist in a database without the employee existing in the database
EMPLOYEE
1:N |
DEPENDENT

30. ID-Dependent Weak Entities
An ID-Dependent weak entity is a weak entity that must include the identifier of its parent entity as part of its composite primary key
BUILDING
1:N |
APARTMENT

31. Weak Entity Identifier: Non-ID-dependent
A non-ID-dependent weak entity may have a single or composite identifier, and the identifier of the parent entity will be a foreign key
PATIENT
1:N |
PERSCRIPTION

32. Weak Entity Identifier: ID-Dependent
An ID-dependent weak entity has a composite identifier
The first part of the identifier is the identifier for the strong entity
The second part of the identifier is the identifier for the weak entity itself
PROJECT
1:N |
ASSIGNMENT

33. 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

34. 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

35. Unified Modeling Language Entities
ENTITY_NAME
List of Attributes
Identifier

36. Unified Modeling Language Relationships
0..1
0..*
1..*
1..1
Mandatory One
Optional One
Optional Many
Mandatory Many

37. 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

38. UML Weak Entity EMPLOYEE DEPENDENT EmployID EmployName Phone
EmployID is identifier
DEPENDENT
DepSSN
DepName
DepAge
DepSSN is identifier 1
0..N

39. UML Example

40. UML Example

41. UML Example

42. Data Modeling and the Entity-Relationship Model
End of Presentation on Chapter Four
Data Modeling and the Entity-Relationship Model