Data Modeling and theEntity-Relationship Model
Chapter Four
DAVID M. KROENKE’S
DATABASE CONCEPTS, 2nd Edition
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-4
Three Stages of Database Development
• Requirements Stage
• Design Stage
• Implementation Stage
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-5
The Requirements Stage
• Sources of requirements– User Interviews– Forms– Reports– Queries– Use Cases– Business Rules
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-6
Requirements Become theE-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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-7
Entities
• An entity is something that users want to track– CUSTOMER– PROJECT– EMPLOYEE– STUDENT
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-9
Instance versus Classes
CUSTOMERCustID
CustName
78124Jackson Co.
12735Smither, Inc
Two EntityInstances
EntityClass
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-10
Attributes
• Entities have attributes that describe the entity’s characteristics– ProjectName– StartDate– ProjectType– ProjectDescription
• Attributes have a data type and properties
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-11
Identifiers
• Entity instances have identifiers
• An identifier will identify a particular instance in the entity class– SocialSecurityNumber– StudentID– EmployeeID
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-12
Identifier Types
• Uniqueness– 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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-14
Degree 2 Relationship - Binary
LOCKER EMPLOYEE
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-15
Degree 3 Relationship - Ternary
DEALER MODEL
MAKE
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-16
One-to-OneBinary Relationship
• 1:1 (one-to-one)– A single entity instance in one entity
class is related to a single entity instance in another entity class
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-17
One-to-OneBinary Relationship
• An employee may have no more than one locker; and
• A locker may only be accessible by one employee
LOCKER EMPLOYEE1:1
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-18
One-to-ManyBinary Relationship
• An employee may only work for one department; and
• A department has several employees
DEPARTMENT EMPLOYEE1:N
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-19
Many-to-ManyBinary Relationship
• An employee may have several skills; and• A particular skill may be held by several
employees
SKILL EMPLOYEEN:M
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-20
One-to-ManyUnary Relationship
• An employee may be managed by one other employee
• A employee may manage several employees
EMPLOYEE 1:N
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-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)
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-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 EMPLOYEE1:1 0|
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-23
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 0| DEPENDENT
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-24
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 0| APARTMENT
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-25
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 0| PERSCRIPTION
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-26
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 0| ASSIGNMENT
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-27
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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-28
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
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-29
Unified Modeling Language Entities
ENTITY_NAME
List of Attributes
Identifier
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-30
Unified Modeling Language Relationships
0..1
0..*
1..*
1..1 Mandatory One
Optional One
Optional Many
Mandatory Many
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-31
UML E-R Diagram Example
• An employee must report to one department; and
• A department may have zero or many employees
EMPLOYEE
EmployIDEmployNamePhone
EmployID is identifier
DEPARTMENT
DeptIDDeptNameLocation
DeptID is identifier
0..* 1..1
DAVID M. KROENKE’S DATABASE CONCEPTS, 2nd Edition © 2005 Pearson Prentice Hall
4-32
UML Weak Entity
EMPLOYEE
EmployIDEmployNamePhone
EmployID is identifier
DEPENDENT
DepSSNDepNameDepAge
DepSSN is identifier
10..N
Data Modeling and theEntity-Relationship Model
End of Presentation on Chapter Four
DAVID M. KROENKE’S
DATABASE CONCEPTS, 2nd Edition
Top Related