Data Modeling 101

UC BerkeleyExtension

Copyright © 2000 Patrick McDermott pmcdermott@msn.com

The Answer toEvery

Data Modeling Question

ITDEPENDS

The Sour of Babel

Camp Category Thing 2 Things Fact Behavior InheritanceCRC Cards Class N/A Collaboration (Attribute) Responsibility Superclass/SubclassERD Entity Type Entity Relationship Attribute N/A Supertype/SubtypeRelational Relation Tuple Foreign Key Attribute N/A N/ADatabase Table Row Database Key Column Service, Procedure 3 VariationsProgrammer Layout Record Pointer Variable Function Base/DerivedUML Class Object Association Property Method Generalization Etc., etc., etc…

Type, Structure

Occurrence, Instance

Pairing Field, Item Message, Operation, Algorithm, Trigger

Parent/Child, is-a, Root/Branch/Leaf

Levels of AnalysisConceptual Logical Physical

Purpose Requirements Specification ImplementationActivity Analysis Design CodingNeed Business Need Programmer’s Need User’s Need

Relationships Plain Old Relationships Generalizations AggregationsMultiplicity Cardinality Optionality ImplementationalMany-to-Many Many-to-Many Okay Many-to-Many Suspect Many-to-Many Forbidden

Attributes Attributes not detailed Attributes Detailed Variables DetailedAttributive Classes

No Attributive Classes Detail De-Normalize

Normalization Only Major Subjects Normalize De-Normalize

Use Cases Diagram Sunny Day Scenarios Test CasesMethods Major Responsibilities Use Cases Detailed Functions written

IF… What if I wonder if No ifsConcern What happens to be vs.

what must be What is vs. what could be

What you need vs. what you want

House Analogy Artifact Architect’s Drawing Blueprint The House Need Builder Contractor Homeowner

1. Initial List of Entities

• Brainstorming.• Grammatical Analysis.• Prototyping.• Derive from Use Cases.• Derive from Workflow diagrams.

Brainstorming Rules

0. Have Fun!!!1. No Criticism2. No Self-Censorship3. Piggyback

Quantitynot

Quality

Brainstorming

• 1. Brainstorm• 2. Reward• 3. Reality Check• 4. Fuse & Fission• 5. Combine

– Categorize

• 6. Select– Consensus– Multi-Vote

• Most Fun• Most Ideas• Most Bizarre,

Strange or Ridiculous

• NOT: the Best idea.

RewardSteps

Grammatical Analysis

• Classes are Nouns• Relationships are Verbs• Attributes are Adjectives• Methods are Phrases

– Including an action and a C,R,A

2. CRC Cards

A Responsibility Collaborator

Another Responsibility Collaborator

A Great Responsibility Collaborator

NAME

Entity Class

• A Business Object• A Thing the Business needs to know about.• At this stage, a business person should be

able to understand every one of them.

• “Class” is best defined by examples…

Examples of Classes

• People• Places• Things• Events• Roles• Organizations• Other Systems

• Tangible• Intangible• Collections of Other Objects• Conceptual: Cost Center, Account• Interface: Screen• Infrastructure: Date, Money, Address• Persistence: Database• Control

There must be a Class if…

There’s a formThere’s a fileThere’s a numberThere are several copiesIt’s Important

NOTE—– Sections and boxes on Forms– The name might not be obvious

Classes have Responsibilities

• Know Things– Invoice: Know the Customer

• Do Things– Invoice: Compute Total

• Obligation or Contract

A Responsibility might need a Collaborator

• Another class that assists in performing the Responsibility– Has information (knows)– Helps Do It

• No need to List Both Directions• Personification, or messaging, can help

3. Make a Rough Diagram• Only Major Classes or Subject Areas and major

relationships need to be detailed at this stage.• Show Plain Old Relationships

– Just draw a line from each class to its collaborators without trying to discriminate types of relationships or multiplicity.

– Give relationships names that are verbs. You may list any key attributes or methods (responsibilities) identified.

• After playing, transfer to paper or tool.

STUDENT

NameAddressTelephoneEnroll()Party()Flunk()DropOut()

TEACHER

Class

STUDENT

NameAddressTelephone

Enroll()Party()Flunk()DropOut()

Name

Attributes

Methods

Collaboration

4. Defining Details

• Descriptions for Entities• Names for Relationships• Count Entities & Relationships• Define Primary Keys

• Attributes need not be detailed yet, but the major, defining or forgettable attributes can be recorded.

5. Add Cardinality

• 1-to-1• 1-to-Many• M2M

– Many-to-Many relationships are okay at this point.

Cardinality

1 to 1

1 to Many

Many to Many

1 1

1

**

*

6. Distinguish Generalizations

• For each relationship, ask, – “Is this a kind-of relationship?”

• If necessary, distinguish Aggregations,– And if so inclined, compositions.– Bill of Materials

Types of Relationship

• USES: Association– Default; those that aren’t one of the others

• IS-A: Generalization• HAS-A: Aggregation• IS-Made-From: Composition

– “A form of aggregation with strong ownership and coincident lifetime of parts by the whole.”– Rumbaugh, Reference, p. 226

– I don’t bother distinguishing from Aggregation

Employee

EMPLOYEE

NameAddressTelephoneGetHired()GetPaid()ChangeJobs()Quit()

BlueCollar

HourlyRateUnionGetPaid()PayUnion()Grieve()

WhiteCollar

Salary

GetStock()

Inheritance Symbology

EMPLOYEE

WhiteCollar BlueCollar

7. Add Optionality

• For each relationship ask: • “Is this mandatory?” • Many-to-Many relationships are suspect at

this point and most of them should be resolved.

Multiplicity

• Is it Mandatory or Optional• Is zero a number???

• Hottentots: 1, 2, Many• Programmers: 1, • Analysts: 0, 1, Many• UML: Exact Count

– Car has 4 wheels, triplets 3; 2 areas for Tennessee IS degree

Optionality

Optional 1 to Mandatory 1

Mandatory 1 to Optional Many

Optional Many to Mandatory Many

0 ..1

0 .. *

1 .. 1

1 .. 1

1 .. *0 .. * O

O

O

8. List all Attributes

• Class by class, in excruciating detail, you must discover all attributes. Use brainstorming, forms analysis, interviews, whatever. Detail any Attributive Classes, and any look-up tables.

• Attributes are facts about classes

9. State or Object Diagrams

• Consider State Diagrams for critical classes that have important or confusing transitions or structural aspects.

• Consider Interaction Diagrams (sequence and/or collaboration) if the structural construction of classes is complex or confusing.

Coke Machine

Nothing Works Coin Return Works Coin Return,Selection Work

NoMoney

SomeMoney

EnoughMoney

I Feel Coke!

B/L vs Invoice

• Customer– B/L 2– Invoice 1

• Vessel– B/L Yes– Invoice No

• Multiple #– B/L Yes– Invoice No

B/L #

Obligation

Customer Voyage

1

*

1..*

* *

0..1

:B/L #

:Obligation

:Customer :Voyage

1

*

1..*

* *

1

B/L Invoice

:B/L #

:Obligation

:Customer :Voyage

1

1

* *

0

1

10. Resolve Many-to-Many

1 Stick a Box in the Middle2 Flip the Asterisks (Arrows) In3 Migrate the Keys4 Find a Name5 Add attributes6 See if it’s already there

Order to Product

ORDER

PRODUCT

ORDER

PRODUCT

ITEM

QuantityPrice

#

#

#

#

#

#*

*

*

*

11. Painstaking Review

• Normalize: The Key, the Whole Key and Nothing but the Key, so help me Codd.

• Actually, just a means to a painstakingly careful review.

12. Define all Variables

• Class by class, in excruciating detail, you must fully define all variables needed to support your attributes.– Data type– Valid values– Required or optional

13. Define all Methods

• Using use cases or sequence diagrams.• Class by class, in excruciating detail, you

must fully define all methods. – Return type– Parameters– Required or optional

14. De-Normalize

• Determine Implementational Multiplicity. – You might have to modify your ideals for

practical reasons.– You might have to modify your ideals for

performance reasons.• BUT, force proof of the necessity

• You usually go too far before you’ve gone far enough.

15-100. Party!