Stephen C. Hayne Data Modeling Method identify/describe data entities Notation way to illustrate findings Approaches Normalization Entity Relationship
Mar 26, 2015
Stephen C. Hayne
Data Modeling
Method identify/describe data entities
Notation way to illustrate findings
Approaches Normalization Entity Relationship
Entity Relationship Model
Strong and weak entity typesAttributesBinary relationshipsDesign problemsRecursion and generalization
Stephen C. Hayne
Basic concepts
Entity identifiable object or concept
Attribute property of an entity or relationship
Relationship an association among entities
Identifier one or more attributes identifying an
instance of an entity
Stephen C. Hayne
Entity (or entity class) vs. entity instance
Stephen C. Hayne
Entity types
Strong existence does not depend on the existence
of another entity
Weak existence is dependent on the existence of
another entity business rules vs. logical dependence ID-dependence (physical dependence)
Stephen C. Hayne
Entity-Relationship Model
Relationship
Identifying Relationship
Entity
Weak Entity
Stephen C. Hayne
Entity examples
Staff
Branch
Nextof Kin
Room
Which are strong, weak, ID-dependent entities?
Stephen C. Hayne
Attributes or properties
DORMITORY
Location
DormName
Number of Rooms
DORMITORYDormNameLocationNumber of Rooms
Stephen C. Hayne
Identifiers
Non-unique LastName
Unique (key) SSN
Composite {AreaCode, LocalNumber} (is this unique?)
Stephen C. Hayne
Binary relationships: HAS-A
IsAssigned
Occupies
BelongsTo
Stephen C. Hayne
Binary Relationship
Student Class0:N 0:35IsEnrolledIn
PartialParticipation
Stephen C. Hayne
Binary Relationship
Student Class1:N 1:NIsEnrolledIn
TotalParticipation
Stephen C. Hayne
Ternary relationships
Can often (always) split one relationship of degree 3 into two (three) relationships of degree 2; are these independent?...
Stephen C. Hayne
More on relationships
Relationship classes vs. instancesRelationships can have attributes
(equivalent to degree=3)Crow’s feet representation of cardinality
Rent
Stephen C. Hayne
Cardinality
Number of elements allowed on each side of a relationship (participants)
Maximum Cardinality Maximum number of entities that can be involved
in relationship: typically 1 or many
Minimum Cardinality Minimum number of entities that MUST be involved
in relationship : typically 0 or 1 Also called participation constraints: total or partial
Stephen C. Hayne
Cardinality constraints
PROPERTYOWNER 1:N
Owns
AUTOEMPLOYEE 1:1
Assigned
CLUBSTUDENT N:M
Joins
Stephen C. Hayne
Fan trapsMultiple 1:N relationships from the same entity
where a relationship between child entities is required
Solve it!
Stephen C. Hayne
Fan traps
Solution
Stephen C. Hayne
Chasm traps
Missing a required pathway between entitiesSingle line: partial participationSolve it!
Stephen C. Hayne
Chasm traps
Solution
Stephen C. Hayne
Recursive relationships
Participants are instances of same class
Stephen C. Hayne
Recursive Relationship
VolunteerSupervisor
Supervisee
Supervises
Role Name
0:N
1:1
Stephen C. Hayne
Weak relationship
Relationships involving weak entities Logical dependency
ID-dependency
Stephen C. Hayne
A full E-R diagram example
Properties can be shown in the diagram or listed separately
Stephen C. Hayne
Supertype & subtype entities
Exclusive vs. non-exclusive subtypesRequired vs. optional subtypes
Stephen C. Hayne
Generalization hierarchy
Represented by supertypes & subtypes
Also called: type hierarchy IS-A relationships
Inheritance subtype entities inherit
attributes of supertype entity
Stephen C. Hayne
Putting it together
Add business rules Constraints, restrictions, protocols Document the rules
Evaluate your data model! What queries can you pose? Are there any connection traps? Does it model the users’ model of the business
world?
Stephen C. Hayne
•Form pairs•Find:
•1 business rule•1 query
•Share