The document discusses 5 common physical data modeling mistakes that can negatively impact performance, development timelines, and cause bugs. These include: 1) Assuming that numbers will always be numeric, 2) Choosing the wrong primary key, 3) Incorrectly applying surrogate keys, 4) Turning off referential integrity for development, and 5) Relying on default settings rather than customizing the physical model. The presentation provides tips on how to identify and avoid these mistakes such as establishing primary key standards, using the correct data types, and testing physical models in a separate database before implementing.

1. Physical Data Modeling Blunders
And How to Avoid Them
Karen Lopez
Sr. Project Manager

2. Abstract
What’s going on in your physical data model? How many people can
or will update it to match the reality of what’s going on in your
databases? Who decides what goes into the physical model? In this
presentation we discuss 5 physical data modeling mistakes that cost
you dearly: performance snags, development delays, bugs and
professional respect. Data Architects are often tasked to prepare
first-cut physical data models, yet these skills usually overlap those of
DBAs and Developers and this overlap can lead to contention,
confusion, and complacency.
With this presentation, you’ll learn about the 5 blunders, how to find
them, plus many tips on how to avoid them.
PAGE 2

3. Speaker Bio
Karen López is a principal
consultant at InfoAdvisors. She
specializes in the practical
application of data management
principles. Karen is also the
ListMistress and moderator of
the InfoAdvisors Discussion
Groups at www.infoadvisors.com
and other online communities.
PAGE 3

4. Agenda
The Problem
Blunders, FAILs, D’Oh’s, Faults and WTHs?
10 Tips
PAGE 4

5. POLL: Who Are You?

6. POLL: Physical Model Much?

7. The Problem
PAGE 7

8. Confirmation
Number
Assuming Numbers are Numbers
PAGE 8

9. D’OH!
•Leading Zeros
•Non-Numeric
•Special Characters
•Sorting Issues
•Externally Managed Numbers
PAGE 9

10. Avoid it
1. Use a numeric-ish datatype when
there’s math involved.
2. Do your research
3. If it’s externally managed data, its
format or composition could change at
any time. Anticipate that.
4. Anticipate leading zeros.
5. Anticipate significant formatting,
characters & other tricks.
PAGE 10

11. Choosing the Wrong Primary Key
PAGE 11

12. 32 + 8 + 32 + 32 + (0 to 22) = A really big key
that only a Data Architect could love
PAGE 12

13. Avoid it
• Establish Primary Key standards and styles
• Smaller PKs lead to smaller indexes and
smaller databases. Take advantage of that
• Choose PKs that do not change when data
changes
• Understand how Identity columns work
PAGE 13

14. Applying Surrogate Keys Incorrectly
PAGE 14

15. Applying a Surrogate Key
PAGE 15

16. WTH?
PAGE 16

17. Alternate Key
PAGE 17

18. Avoid it
• Establish Primary Key standards and styles
• Smaller PKs lead to smaller indexes and
smaller databases. Take advantage of that.
• Don’t forget the Business Key
• Choose PKs that do not change when data
changes
• Understand how Identity columns work
PAGE 18

19. Turning off RI for Development
PAGE 19

20. Blunder
PAGE 20

21. RI = FK
PAGE 21

22. Avoid it
• Educate team on the risks & nearly universal outcome of turning
off RI
• Generate RI in every script
• Develop test data
• Develop scripts for loading data
• Ensure team has easy access to Data Models
PAGE 22

23. Using the Defaults
PAGE 23

24. Defaults
• Defaults <> Best Practices
• Product Defaults aren’t YOUR defaults
• Defaults might even be…faulty.
PAGE 24

25. Defaulting
Faults
PAGE 25

26. Avoid it
• Create a DA Test database…and use it.
• Test Generation Options to Test DB with
Data
• Generate Test Scripts, Varying Options
• Review options with DBAs and
Developers.
• Choose Defaults, don’t default them
• Save your Default Set
PAGE 26

27. Other Blunders
• Using the wrong tool • Hand generating scripts
• Too much Subtyping • Failing to report issues
• Logical Flexible hierarchies • Denormalizing too soon
• Wrong Datatypes • Failing to use constraints
• Dual updates • Making performance more
• Forgetting to manage the data important than integrity
• Duplicate Indexes • Completely separate logical
• Ignoring Clustering model
• Using overly generic design • Failing to take into account
patterns whole environment.
• Column order • Applying surrogate keys where
they have no business
• Silly Long Names • Not testing your design
• Failing to compare • Ignoring reference data design
PAGE 27

28. 10 Tips for Avoiding Physical Modeling Blunders
1. Understand cost, benefit and risk
2. Get formal training on target technologies
3. Work near your DBAs and Developers
4. Ask DBAs about trade-offs, not just
solutions
5. Build portfolio of performance vs. integrity
trade-offs
PAGE 28

29. 10 Tips for Avoiding Physical Modeling Blunders
6. Profile Source Data
7. Build Test Databases, with Data
8. Test Scripts
9. Compare, Compare, Compare…then
Compare some More.
10.Get More Training.
PAGE 29

30. Summary 1.Don’t assume that
numbers are….numbers
2.Choose the right primary
key
3.Apply surrogate keys
correctly
4.Keep RI turned on
5.Architect, don’t default
PAGE 30

31. Questions?
Feedback, questions,
comments are always Karen@InfoAdvisors.com
appreciated.
http://www.speakerrate.com/karenlopez
PAGE 31