stephen c. hayne data modeling zmethod yidentify/describe data entities znotation yway to illustrate...

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