1

DAMA International Symposium & Wilshire Meta-Data Conference

Conducting

Database Design

Project Meetings

Gordon C. EverestCarlson School of Management

University of Minnesotageverest@csom.umn.edu

GETITLE

---o---

2004 May 2-6 Los Angeles, California

© 2004

2

Outline

• Database Design Project Meetings– Initial Meeting(s) followed by extended series of meetings– Process and Product– Explaining the Objective, Purpose, Principles, and Benefits

of Data Modeling– Based on many actual experiences, but focusing on one– Concluding with Guidelines and Best Practices

Then expand our view:

• Interviews• Accelerated Group Meetings

– Comparative study– Lessons learned

• Advice from others– Simsion, Moody, Moriarty, Barden

DBPROJ

3

Data Modeling Project: The Context

PLANNING&

ANALYSIS

DESIGN(MODELING)

CONSTRUCTION(GENERATION)

OPERATION&

MAINTENANCE

PRIORITIES, SCOPE

"REPOSITORY"

DATAPROCESS / BEHAVIOR

PLATFORM

USER INTERFACE

• Global view• Set Priorities

DBPROJ

EnterpriseData

Model

Carve out a piece:• Understandable• Doable• Priority• Greatest payoff

Feedback To flesh outpiece by piece

DESIGNDATABASE

4

The Process

• Global Architecture– Inventory and set priorities

• Choose a User Application Area

• Obtain User Top Management Support– INITIAL MEETING:

with user area managers and experts, IS Dept representative, and database design expert/facilitator

– Explain the project, process, deliverables, benefits, and expected project time duration (variable!)

– Obtain required commitment of people

• Conduct Kickoff Training Session

• Begin an Extended series of Database Design Project Meetings

DBPROJ

[ ]->

5

Initial Meeting(s)

First with User Top Management, then with User Domain Experts.EXPLAIN THE FOLLOWING:

• Objective of Data Modeling– To accurately and completely model a chosen user domain– Within a defined Scope

• Purpose of Data Modeling– To understand the chosen user domain– Prelude to building a database

• The Benefits of Data Modeling

• The Process– Finding Entities (nouns) and Relationships (verbs)– Adding attributes (roles in relationships), and constraints

• The Product– Design documentation – diagram and supporting narrative– Notational scheme

DBPROJ

6

Modeling

MODEL = Abstract (Re).present.(ation)

Knowledgein the world

Knowledgeexternalized,formalized, shared.

Knowledgein the head(mental models)

Reality MODELMODELINGPROCESS

DMOD

pres

ent

Re.

pres

ent

What drives or guides the process?

7

The Modeling Process

Real WorldUniverse of Discourse

MODELINGPROCESS

MODELING SCHEMEContext

ConstructsCompositionConstraints

MODEL

perception

selection/filtering

DMOD

METHODOLOGY:Steps/Tasks + Milestones + Deliverables +

REPRESENTATIONAL FORMS:Narrative, Graphical Diagram,Formal Language Statements

(the Syntax)

8

Data Modeling Constructs

ENTITY(OBJECT)

ATTRIBUTE(Data Item)

RELATIONSHIP

IDENTIFIER [ FOREIGN KEY ]

characteristics

characteristics

What to look for:Relative emphasis differentiates Data Modeling approaches

e.g. ER modeling focuses on Entities and Relationships,de-emphasizing or hiding Attributes.

DMOD

9

Data Modeling Process

PERCEIVE

EXTERNALIZE

FORMALIZE

IMPLEMENT

MentalModel

ConceptualModel (ORM/ER diagram)

LogicalData Model(relational tables)

Physical Model(define database to a DBMS)

map

DMOD

10

Objective of Data Modeling

(WHAT we are trying to do)

TO ACCURATELY AND COMPLETELY MODEL

SOME PORTION OF THE REAL WORLD UNIVERSE OF DISCOURSE (UoD)

OF INTEREST TO SOME ORGANIZATION OR COMMUNITY OF USERS.

DMOD

11

Purpose of Data Modeling (WHY we do it)

DUAL, CONFLICTING PURPOSES DRIVE THE PROCESS:

• Facilitate Human Communication, Understanding, Validation– capture and present meaning, the semantics of a model– direct representation of only essential model semantics

PRESENTATION CHARACTERISTICS:

– scoping and presenting subparts of a Model– unfolding presentation at different levels of abstraction or detail– visual prominence in proportion to semantic importance

SECONDARY:

• Basis for Implementation - defining & creating a Database– complete in all the necessary details– construction/generation able to be fully automated

DMOD

USER

SCHEMA

DATABASE

12

Purpose of Modeling

FIRST STEP in the DESIGN phase of Systems Development (BUILDING)*

• Capture semantics – all relevant, important details

• Document – record and remember

• Understand – learn, raise questions, record answers, refine

• Communicate – shared with all interested parties– Users, stakeholders, management, developers

• Validate – a complete and accurate representation– Internal validation – consistent with the modeling rules– External validation – Who can do this?

• Blueprint to Build

Satzinger2e, SA&D, Fig 5.2, p.149. DMOD

* Some say that Modeling begins in the Analysis phase.

13

Data Model to Database Realization

DATAMODE

L

DATABASE"Schema"

DEFINITION

DatabaseDefinitionLanguage

DATABASE

DataBaseManagementSystem

DataBaseManagementSystem

DATABASEDEFINER

describesdata

input

DDL

stmts

DMOD

14

Data Modeling Principles

• Done at the highest conceptual level

• Done at the schema levelaugmented with sample data populations

• Involve all interested parties(not just one department or application)

• Easier for users to learn data modeling than for IS professionals/data modelers to learn the business

• Capture all possible/expressible semantics

• Users’ (collectively) will always know more

• Be inclusive (within the defined Scope)

DBPROJ

[ ]->

15

Stages of Data Modeling

CONCEPTUAL

DMOD

USER

SCHEMADATABASE

CLUSTERED “LOGICAL”

RELATIONAL

PHYSICAL

DomainKnowledge

ORM• Objects• Obj. ID’s• Roles/Relships• (Fnl. Dep)NO clustering=> NO “attributes”

Attribs in RecordsMultiValued, Nested - - - - - ->

Ternaries - - - - - ->

M:N - - - - - - - - - ->

Normalized (2,3,4)Relationships - - ->

w/attributesSub/SupTypes

Flat (1NF)Binary only1:Many onlyPrimary KeysForeign Keys

• Implementation in/for a DBMS

• Denormalize (for performance)+ triggers, stored procedures

ER

Start at the highest Conceptual Level!

16

Record-Based Data Modeling

• Commonly called Entity Relationship (ER) Modeling

• Attributes clustered into Entity Records (or Tables)• Focus on Entities and Relationships (hence ER)

suppressing attributes in ER Diagrams(hence no explicit representation of identifiers)leaving open the nature of the intra-record structure.

• Most general case allows:– “Nested” Multivalued attributes or repeating groups

Hence not in first normal form (1NF)(should still satisfy other normal forms – 2NF, 3NF, …)

– Direct representation of M:N relationships between entities– Attributed relationships (i.e., with attributes)– Ternary (and higher) relationships– Subtypes and supertypes

• Restricting all of the above gives the Relational Model– Atomic (single-valued) attributes; binary relationships (FKey)

=> Often, ERDiagrams are Relational Table Diagrams

DMOD

17

Choosing a Relationship Notation

Candidate suggestions for ‘one-to-many’ (1:M):DMOD

ENTITY1

ENTITY2

PARENT

CHILD

Bachman1969

ENTITY1

ENTITY2

Everest1976

ENTITYy

ENTITYxNijssen1974

y=f(x)

ENTITY1

ENTITY2

Chen1976

1

M

ENTITY1

ENTITY2

IDEF1X

P

ENTITY1

ENTITY2

SilverRun

M

1

The “Fork”

CRITERIA:

• NOT imply direction,access path, orphysical representation

• Visually intuitive toaid human understanding

• Printable

• international

Everest-DM: p.224.

ENTITY1

ENTITY2

Kroenke

18

Benefits of Data Modeling • Users gain a better understanding of their area.

• Greater system success with user involvement.

• Platform for communication between users and designers.

• Separation of information-oriented specifications from economic / performance / implementation considerations.

• Determines the content of the database.

• Solid base for information systems development.

• Database more viable/stable; Greater evolvability for handling changes in the developed information system.

• A basis for integration• Data modeling is a small part of the total IS development effort, but,

when done “right,” can reduce overall development costs and downstream maintenance costs. When done poorly, the downstream impacts can be disastrous and costly.

DMOD

19

The Chosen User Area

After conducting a survey of existing applications and databases, evaluating them, and setting priorities.

• Department of Transportation, Right of Way Division

• Functions: – Appraisal, Direct Purchase, Leasing, Relocation, Sale,

Demolition, Reconveyance, Legal Owners, Condemnation

• Manageable Scope; Not too Complex

• Great Need; Potentially High Payoff

• 100 People; Mostly Manual Operations

• One Large COBOL file (1971) on Magnetic Tape

• 110,000 parcels of land; 250 attributes (Data Items)

• Several Manual Files on Floating Carts

DBPROJ

20

The Data Modeling Process

GATHERING INFORMATION

• Once the SCOPE and OBJECTIVES are set

• and understanding the modeling constructs to use

How to determine the INFORMATION REQUIREMENTS?

• Where would you go?

• Where would you look?

• What would you look for?

• Who would you talk to?

• What would you ask?

DMOD

N

21

Database Design Process – Two Approaches BOTTOM-UP: TOP-DOWN:

LISTof data items

CLUSTER

DATA ITEMS

REALITYUser Domain of interest

Look,Listen

Perceive,Filter

DFDs, Sample forms, reports, files, ...

FIND

ENTITIES

ADD

RELATIONSHIPS

“Conceptual Model Diagram”

“Data Dictionary”

USER-DOMAINEXPERT

DATABASEDESIGNER

Ask questions

Talk

echo

validate

DMOD

The pivotal construct inData Modeling

22

Different Kinds of Entity (Types)

• Independent / Base / Reference– Exists / is of interest… for some duration of time– Frequently the starting point; most important to users

• Dependent– Depends on some other entity(s) for existence, and– Perhaps for identification (Watson notation: )

• Association (“Intersection”)– Represents a Many:Many binary (or more) relationship– May be something meaningful in the users world

• Event or “Transaction”– A happening at a point in time– Number of instances grows endlessly

• Summary – to contain summary (derived) information

• Generalization (“Aggregate”, Supertype) or

• Specialization (“Subordinate”, Subtype)

DMOD WATSON2-ch.7, p.176-9.

23

The Processing Continuum – Choosing Entities

Transaction Standing AGGREGATIONS

EVENTS ENTITIES DERIVATIONS

FLOW data LEVEL/STATUS SUMMARY datae.g.: hire, fire Employee workforce growth

sales Product Inventory stockouts

• DESIGN ISSUE: calculating derived information– at input/update time - when transaction event captured & recorded

– at output/retrieval time - when output data is requested

• Sometimes we don’t record event transactions at all– of no interest– just record the effect of the event transaction, e.g. marriage

• We don’t usually store summary data– calculated at retrieval request time– except in Data Warehousing/OLAP for better response time

ISUSE

24

Steps in the Modeling Process

The A B C D E F G procedure:

• Ask & Analyze

• Bounce Back & Forth with/among user domain experts

• Comprehend what they are saying; Verbalize

• Design - Diagram & Document in Dictionary with narrative

• Evaluate against rules of construction & user experts

• Formalize in a Data Model (mapping for implementation)

• Generate a definition for implementation in a DBMS

DMOD

25

List of Data Items (Bottom-up Design)

• UNORGANIZED, UNSTRUCTUREDe.g. the “Data Dictionary” derived from DFDs

Customer NumberCustomer NameBilling AddressCustomer PhoneShipping AddressCredit LimitSalesperson IDSalesperson NameSalesperson AddressSalesperson PhoneCommission RateOrder NumberOrder DateShip DateTermsGross Amount of OrderInventory Item NumberItem DescriptionPriceBin LocationQuantity Ordered

ATTRIBUTES ... of … ENTITIES:

• ORGANIZED, CLUSTERED

CUSTOMER

SALESPERSON

ORDER

ITEM

ORDER LINE ITEM

Add

RELATIONSHIPS

calls on

places

contains

ISDATADDMOD

26

The ProductDocumentation

– produced according to a set of Guidelines (See Appendix to Everest paper)

– structured to facilitate incremental updates Hierarchical organization, dated, modular sections

• Scope and Objectives– Use Cases; Major Processes (Setup, Retrieval & Reporting,

Update/Maintenance/Transaction processing, Archival

• Global Data Model Diagram– Top-down unfolding presentation

• Narrative Description of:– Entities– Relationships– Attributes

• Formal Definition in a Data Dictionary / Repository– Preferably using a CASE Tool

• Generated Schema (DDL Script) for a target DBMS

DBPROJ

27

User Experiences and Activities

• Users get excited

• Learning and Self-Confidence grew

• Relationship with central IS support unit

• One user forged ahead early

• Anxious to buy equipment and install systems

• The Product: Documentation - 40 entities, 400 pages

• Used a CASE Tool to support data modeling

DBPROJ

28

Sample Data Model (Excelerator 1.9)

MAINTDIST Maintenance

District

COMMISSIONCommissioner

COMMWORKCommissionerHours Worked

COMREPORT Commissioners

Report

PETITIONPetition &

Lis Pendens

TRIALSETL Trial and

Settlement

IMPROVEMENT Improvementson R/W Parcel

OTHERBIDS Other Bids

SALESACTSales Action

EMDOMACTEm Domain Action: St vs.

COMASSIGN Commissioner Assignment

LEASE Lease

EDPARCTRK EmDom Parcel

Tracking

LESSEE Lessee

CONTRACTORContractor

REMOVCONT Removal Contract

FINALCERT Final

Certificate

COUNTYCounty

Num | Code... AGREEMENT Agreement

AUTHMAP Authorization

Map

CHARGEIDCharge

Identifier

RWPROJR/W PROJECT

900's or Dash # FEDPROJ Federal Project

PMSSPROJPMSS Project

PROJECTSProject Actions

COMORDACT CommissionersOrders Action

COMMORDER Commissioners

Order

PARTY NAD Party Name & Address

PARTY INT Party toInterest

INTHOLDER InterestHolder

APPRAISER Appraiser

APPRAISAL Appraisal

APPACTION Appraisal

Action & Cert

OCCATTRNY Occupant

Attorney NAD

MEMBERS Household Members

OCCUPANTOccupant

Relocation

RELOCPMTS Relocation

Payments & Appls

DIRPURCH Direct

Purchase

SUPHOUSINGSupplemental

Housing

3-5 1-4

5/yr

rare

rare10%

10%

rare

20%

rare

usually 1

rare <99

3%

0-2

?

ROADSECTRoad Section

Cty# |RS#

<.01

<- last

latest

V

<3

3%

2 if EG m if 88

Minnesota DOT Right of Way

Database Structure

Gordon C. Everest

LEGENDOne )----------E

Dependent -- --D -- --Orphan -- -- -- -- F -- --Foreign ID -- -- -- -- -->

DMODPRE

PARCEL

Interest in aLand Parcel

( many

29

Data Modeling

GUIDELINES for GATHERING & RECORDING Information:

1. PERCEPTIONS IN MINDS OF KEY USERS

2. EXISTING FILES/SCREENS/FORMS/REPORTS ONLY CLUES

3. DOCUMENTATION GUIDELINES Parts and organization

Diagramming conventions

4. GROWING THE DOCUMENTATION: ENTITIES FIRST

5. DISCOVERING ENTITIES What is a file?

6. NAMING AND DESCRIBING ENTITIES

7. FOLLOWING THE RULES FOR LOGICAL DATABASE DESIGN

8. UNCONSTRAINED BY IMPLEMENTATION/SYSTEM LIMITATIONS

9. LOOKING FOR THE EXTREMES; NOT THE TYPICAL

10. SEEKING CONSENSUS AMONG THE USERS

DMOD

30

Conducting Data Modeling Project Meetings

BEST PRACTICES:• Get user top management support & commitment• Don’t limit to a fixed deadline• Get the “right” people to the table; ask what they ‘do’• Set and agree on the project scope early• Be inclusive in the design• Break expectation that it will all be implemented• Biweekly, ½ day meetings• Focus on finding entities, relationships, & characteristics• Grow the documentation (not meeting minutes)

following guidelines, modeling scheme, and notation• Facilitator – an “outsider” (know the process, not the domain)

• Scribe – an “insider” (so organization takes ownership) CAUTION: must be open, balanced, willing to record all viewpoints

• Use a data modeling CASE toolto iterate on revisions to diagrams and documentation

DBPROJ

31

Gathering Business User Requirements

from user domain experts (not IS people):

• Interviews + everyone gets heard

° one at a time + requires less interviewee time

° small group (homogeneous) + interaction stimulates ideas

• Facilitated Group Sessions° Accelerated + less elapsed time (intensive 1-3 days)

+ creative brainstorming + raise issues

+ set priorities (voting) ? build consensus? resolve issues?

° Extended + to achieve common, accepted design

DBPROJ

+ advantage

32

ACCELERATED(“JAD” session)

for brainstorming,straw votes, andsetting priorities

Interviews vs. Group MeetingsDBPROJ

Many

5-10

2-3

1

# MEETINGS

1 2 (Follow-up) Many

EXTENDEDfor Database

Design

ManagersExecutives Interviews Visionaries#

PA

RT

ICIP

AN

TS

The “sweet” spots:

33

Interviews: Preparation

• Understand Background– the business - its strategic direction– the industry - trends, competition– the organization - formal and real organization charts– the history - any prior initiatives––> still IS people/interviewers DO NOT presume to know everything,

and DO pretend to know nothing (to ask the “dumb” questions).

• Select Interviewees– horizontal and vertical cross section– the visionaries; the thorns in the side; the power users

• Project Kick-Off Meeting– with impacted users and their management– introduced by user management sponsor– convey commitment, scope, expectations, required user involvement

• Pre-Interview Letter– from project sponsor: internal respected authority– logistics and what to bring

• Plan a Structured Interview

DBPROJ

34

Conducting the Interview

• Think through what you need to discover

• Prompting single sheet of topics/questions

• Lead Interviewer + Scribe + Observers

• REVIEW Project Purpose and Scope• Let USERS TALK about what they DO, what they know

(stay within their comfort zone… initially)

• then LISTEN carefully for expressions of:– vision, strategies, priorities, strengths, problems,

suggestions for improvement, …

• ASK the classic questions:– why, how (much), who, where, when, what if, what then.

• FLAG the nouns and verbs– Nouns become entities– Verbs become relationships

DBPROJ

35

Accelerated vs. ExtendedDesign Approaches

• DATA PLANNING

• Division-wide data model

• Entity-Relationship Modeling

• Accelerated Workshop

• 5 consecutive days

• 76 participants from

• Forestry + 10 other agencies

• 2 facilitators (also as scribes)

• DETAILED DESIGN

• Forest inventory database

• Extended E-R Modeling

• Extended Project Meetings

• Biweekly 1/2 day - 6 months

• 11 participants from

• Forestry, Fish & Wildlife

• 1 facilitator (also as scribe)

TASK

SCOPE

SCHEME

APPROACH

DURATION

PEOPLE

ORGS

LEADER/S

DBPROJ

36

Results: Accelerated Approach for Data Planning & Modeling

TIME (days)

TASK: Planned Actual

• Intro / Kickoff / Training 1 1

• Define ENTITIES 1 2 1/2*

• Define ATTRIBUTES 1 3/4

• Define RELATIONSHIPS 1 3/4

• Partition and Prioritize 1 0

*Difficult and contentious, so facilitators decided arbitrarily to move on. Entity definitions were incomplete, missing, or poorly stated, with no consensus reached -- which hindered definition of attributes and relationships in remainder of workshop.

A global data model not produced, nor detailed design projects defined and prioritized. The contractor promised to develop these later in the final report of the workshop.

DBPROJ

37

User Surveys

• Data planning workshop unsatisfactory, final report omitted "where used" matrix and global data model was useless. Contractor released. No user validation.

• Comparison of user survey results confounded by contractor's apparent lack of experience, preparation, organization and management of the workshop. Novice facilitators in both approaches.

• Extended bi-weekly meetings: participants willing to do it on another project, felt this project was completed but uncomfortable stating that a good data model had been produced.

DBPROJ

38

Lessons Learned

• Accelerated approach may be good for eliciting information requirements and setting priorities, not for database design.

• Difficult to reach consensus with a broad scope ... necessitating 76 participants.

• Experienced, prepared facilitator is critical... the accelerated approach is unforgiving for the novice.

• Clearly define and communicate organizational goals, expectations, and outcomes / deliverables.

• User domain experts: get the best; use as needed.

• Top management support to ensure good participation.

• Facilitator: expert in the process, but not the domain.

• Dedicated scribe from within orgn… to take ownership.

• Select the first design project with a manageable scope to ensure success, and increase future mgmt and user buy-in.

• Consider using a blend of the two approaches.

DBPROJ

39

Advice from Others

• Terry Moriarty

• Dan Moody

• Graeme Simsion

• Dick Barden

DBPROJ

40

Conflicting Objectives in IS Development

• User Domain / Subject Matter Experts (SME’s)

Application Systems• (Business) Process Analysis• Process Models (DFD’s)

Object-Oriented Development• Implement in OO Programming Languages• Object Models; Use Cases• (UML) Class Diagrams• State Transition Diagrams

Data Warehousing / Data Marts• Multi-dimensional models

Data Modeling• Focus on Data• Singular Objective

(NOT implementation)• Precise Thinking• Rich Semantics

-probe for hidden meaning• (Shared) (Integrated)

“Enterprise” Models• Normalized ER Diagrams

RELATIONALDATA MODELS

• Implementationin RDBMS

What do Data Modelers bring to the table?– Strengths and Perceived Disadvantages

How to get invited to the table, to be involved in IS Development?

T. Moriarty, “… Data Modelers!” Intelligent Enterprise (3:1), 2000 Jan.

/ /

DBPROJ

41

Dan Moody’s “Seven Habits”

• IMMERSE yourself in the client/user environment– See it for yourself

• CHALLENGE– Generate alternatives, test the boundaries, find the exceptions

• GENERALIZE, discern the underlying similarities of entities– Keep it simple, reduce the number of entities

• TEST out the model; have users validate the model– Examine every relationship … in both directions

• LIMIT the Time and set the Scope up front– Know when to stop

• INTEGRATE with existing systems and databases– Keep an eye on the big picture

• COMPLETE – resolve ambiguities; handle the exceptions– Follow the job through to completion

Daniel MOODY, “The Seven Habits of Highly Successful Data Modelers,” Database Programming and Design (9:10), 1996 October, pages 57 – 64.Summarized in: Richard Watson, Data Management, 2nd ed, Wiley, 1999, p.185.

DBPROJ

42

Simsion’s Foundation Principles

• Data Modeling is about Design– Different designers may produce different solutions

there is no single correct model for a given situation;thus need quality criteria to make an objective choice.

• Data Modeling is Important… and NOT Optional– Data modelers believe it; problem is persuading other stakeholders

• Data Modeling is a Discipline… requiring expertise– Requiring Training, Practice, Experience. … Users can’t model! But..

NOT just knowing and applying some rules and conventions;witness the difficulty in using data modeling CASE tools

• Data Modelers use Patterns … DW is a dimensional model– e.g., hierarchies, M:N, assemblies (ring fact), orders/warehouses

• Subtypes help… Level of Generalization is critical

• Logical DB Design is the Data Modeler’s Responsibility– DBA’s for physical design, implementation in a DBMS, performance

• Corporate (Enterprise) Data Modeling is different– Purpose – understand global architecture; integrate; set priorities

G. Simsion, Database Programming & Design (9:2), 1996 Feb.DBPROJ

[ ]->

43

Data Modeling as Design• “Data Modeling is a Design activity” – Graeme Simsion• Analysis seeks to discover the (one) truth, represented in a model• Our perceptions of reality differ; Modeling Schemes are imperfect• Design involves Choice – e.g., Entity/Object Types; Sub/Supertypes• Need Criteria

DBPROJ

44

Criteria for Choosing a Quality Design

• Follows the rules of construction (“grammar”) of the data modeling scheme.

• Accurate model of the users real world domain of interest

• Complete… within the defined scope• Enables enforcement of (business) rules• Non-redundant• Stable• Flexible• Extensible• Understandable• Simple• Unambiguous• Basis for an efficient, workable implementationSOME OF THESE IN CONFLICT and INVOLVE TRADEOFFS.

DBPROJ

45

“Baloney Detection Kit” – Dick BardenDBPROJ

1. Seek out independent confirmation of the ‘facts’

2. Encourage substantive debate on the evidence

3. Be fair to the process; treat each expert equally

4. Spin more than one way of looking at your UoD

5. Seek out others for critical feedback – challenge

6. Populate – gather example data for the facts

7. Everything in a chain of argument must fit

8. Use the simpler one when two equally model the data

9. Ask how the examples can be falsified

10.Can others understand and accept the model

Adapted from Carl Sagan, “The Fine Art of Baloney Detection,” The Demon-Haunted World: Science as a Candle in the Dark, 1996.

46

ReferencesDBPROJ

• Matthew H. Pelkki, Gordon C. Everest, Dietmar W. Rose, “Using Accelerated and Extended Approaches for Data Planning and Design,” The Compiler (13:3), 1995 Fall.

• Terry Moriarty, “Data Modeling is Dead! Long Live Data Modelers!” Intelligent Enterprise (3:1), 2000 Jan 1.

• Daniel Moody, “Seven Habits of Highly Effective Data Modelers,” Database Programming and Design, 1996 October.

• Graeme Simsion, “Data Modeling: Testing the Foundations,” Database Programming & Design (9:2), 1996 February.

• Dick Barden, “Baloney Detection Kit,” Journal of Conceptual Modeling (10), 1999 August. www.inconcept.com/jcm