Database Design Done Right! Presented By: Rick Nunn

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

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

What happens when business wants to add functionality?

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

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)

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

Average percentage of time spent in each phase

But what if we follow the right methodology?

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

Doing it Right

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

Normalization in two minutes (or less)

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

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? .

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”.

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?

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

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

It Depends…

Exercise the requirements

Question, Question, and Question more.

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

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

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.

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

Emphasis on Analysis and Design

Comparative timelines

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.

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.

Any More Questions?