Data Modeling 101 UC Berkeley Extension Copyright © 2000 Patrick McDermott

The Answer to Every Data Modeling Question IT DEPENDS

The Sour of Babel

Levels of Analysis

1. Initial List of Entities Brainstorming. Grammatical Analysis. Prototyping. Derive from Use Cases. Derive from Workflow diagrams.

Brainstorming Rules 0. Have Fun!!! 1. No Criticism 2. No Self-Censorship 3. Piggyback Quantity not 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 ResponsibilityCollaborator Another ResponsibilityCollaborator A Great ResponsibilityCollaborator 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 form There’s a file There’s a number There are several copies It’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 Name Address Telephone Enroll() Party() Flunk() DropOut() TEACHER Class STUDENT Name Address Telephone 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 11 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 Name Address Telephone GetHired() GetPaid() ChangeJobs() Quit() BlueCollar HourlyRate Union GetPaid() PayUnion() Grieve() WhiteCollar Salary GetStock()

Inheritance Symbology EMPLOYEE WhiteCollarBlueCollar

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.. * 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 WorksCoin Return Works Coin Return, Selection Work No Money Some Money Enough Money 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 CustomerVoyage 1 * 1.. * * * 0..1

:B/L # :Obligation :Customer:Voyage 1 * 1.. * * * 1 B/LInvoice :B/L # :Obligation :Customer:Voyage 1 1 * * 0 1

10. Resolve Many-to-Many 1Stick a Box in the Middle 2Flip the Asterisks (Arrows) In 3Migrate the Keys 4Find a Name 5Add attributes 6See if it’s already there

Order to Product ORDER PRODUCT ORDER PRODUCT ITEM Quantity Price # # # # # # * * * *

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.

Party!