1. Database Design Done Right!
Presented By: Rick Nunn

2. “What is expected from every successful project, regardless of methodology?”

3. The Expectation
An application which is fully functional, and seamless.
More precisely, an application which gives the business what they asked for…

5. What happens when business wants to add functionality?

8. Weakness of the current approach
Inability to adapt to changes over time and the ever increasing associated maintenance costs.

9. Take time during analysis to get the business requirements correct
Take time during analysis to get the business requirements correct. If you find errors, fix them immediately. The cost to fix an error in the early stages of the SDLC is relatively small. In later stages, the cost is huge.
(Management Information Systems for the Information Age: Haag and Cummings; McGraw-Hill 2012)

10. Increased complexity Increased time to make changes Increased costs
The long term result
Increased complexity
Increased time to make changes
Increased costs

11. Average percentage of time spent in each phase

12. But what if we follow the right methodology?

13. Methodologies do not guarantee good system design…
They all follow the System Development Life Cycle (SDLC)
They all provide roadmaps for documentation! Nothing more.

14. Doing it Right

15. Designs should be appropriately flexible and extensible.
Can’t design a database without considering normalization

16. Normalization in two minutes (or less)

17. Remove repeating groups into their own table.
First Normal Form:
Remove repeating groups into their own table.

18. Second Normal Form:
No non-prime attribute in the table is functionally dependent on a proper subset of any candidate key .
– Wikipedia.
What does this mean? .

19. Second Normal Form (Continued):
All attributes in the entity are dependent on primary and/or alternate key, “the whole key, and nothing but the key, so help me Codd”.

20. Third Normal Form
Every non-prime attribute is non- transitively dependent on every candidate key in the table. The attributes that do not contribute to the description of primary key are removed from the table. In other words, no transitivity dependency is allowed. – Wikipedia
What does that mean?

21. Children must have parents. No orphans.
Third Normal Form (Cont.)
Children must have parents.
No orphans.

22. OK, So When do you normalize and to what degree is normalization necessary?

23. It Depends…

24. Exercise the requirements

25. Question, Question, and Question more.

26. Always seek business, architectural, and technical understanding to enable you to provide the best designs and warn the team\business of risks.

27. Designing and Modeling the Database
Describe the object before naming
Name all objects appropriately (single name, single purpose)

28. Living with legacy systems and planning for the future.
Never integrate legacy structures into newer structures.
Create a transition staging layer which allows the data to migrate from the legacy (flatter) structure to a modern (flexible, extensible) more normalized structure.

29. Emphasis should be placed more on analysis and design
The result will be fewer downstream changes, lower costs, and shorter timelines.

30. Emphasis on Analysis and Design

31. Comparative timelines

32. Development maturity - Don’t take it personal - Be patient
In the end, the solution is not always in your control.
If you have done your due diligence and communicated foreseen risks, you will have done it right.
Often, some months later, you will have the opportunity to implement an improved solution.

33. What is the result when done right?
The result is a structure which can change over time without affecting the core structures already in place.
Timelines are shortened.
Development and maintenance costs are significantly reduced.
Changes are supported by either adding domain data or by extending the structure to support new requirements, just like the expanding balloon.

34. Any More Questions?