Date post: | 30-Dec-2015 |
Category: |
Documents |
Upload: | joshua-gallagher |
View: | 218 times |
Download: | 2 times |
1
DAMA International Symposium & Wilshire Meta-Data Conference
Conducting
Database Design
Project Meetings
Gordon C. EverestCarlson School of Management
University of [email protected]
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