Chapter 3 the normalization chapter

Chapter 3  the Last Chapter to the first section of database Design and Architecture of the Deep Dives book, is a focus on the normalization of your data and where the attributes of your data should reside.   Author Hugo Kornelis jumps into the subject matter by explaining what we need to look at by using a real world example. The example that Hugo uses points to a Domain Expert or what I refer to as a subject matter expert.  He then points all his examples to a common database or data structure that many of us understand, therefore using one of the methods that he is trying to teach in the chapter, by using a concrete example.

I should let you know that if this is a new subject to you or if you are reviewing the subject and really want to focus on the topic you may want to consider turning down all the music and moving yourself into a quiet location.  Distractions in early parts of the chapter are only going to lead you in the direction of not understand the whole chapter, and well to be frank about it, many people need to read and understand this.

There is a lot to be said for instruction materials where not only does it share the information that they are trying to get across but they continue to relate it back to the “real world”. It is obvious that Hugo is teaching from his real world experience. 

Well all 3 chapters so far have given me a lot of information and the book is very well written and organized into major sections.  This section was the design and architecture section and well it could have been the whole book.  I have to admit that I wish there was more information but maybe that is what the next book is for.  There is so much information at this point that I am not sure how more information could fit in here. 

It is Important to understand that this book is not like many of the other technical books out there.  This is individual chapters that are organized into subject areas.  These are not all encompassing, they are meant to be exactly what the title says,  a deep dive into the topic.

Chapter 3, Section 1- Functional Dependencies

Functional Dependencies…The author breaks down how he is able to find the functional dependencies and present different scenarios to the “domain expert” as he calls it. While reading this chapter, my thought was that he is building something, presenting it to the owner/customer and they (owner/customer) are giving feedback to you (builder) saying yes, no, change this, change that, etc… That was my interpretation of the chapter.  Is it a right interpretation of the chapter? Maybe. I was little confused, I must admit, but by putting it into my own “picture” I was able to understand it more.

Finding dependencies is important so that the final outcome on the front-end is correct. As this ties into the other two chapters in this section, it is very important to get the setup correct in the beginning so that you are not retro-fitting down the road or pushing out a crazy amount of hot fixes.

Apologies for the short post, my ADD is kicking in. oohh look, it’s snowing.

Chapter 3 — Finding functional dependencies

Chapter three is a very logical extension of the first two chapters.  Chapter 1 can be found here and chapter two, here.  The first two chapters talked about the importance of database design, best practices, tools for maintaining the design put into place and ensuring the accuracy of the data.  This chapter talks about HOW to get there.  In my experience, one thing that’s often missed in the database environment’s that I see is the value, importance and lack of critical thinking around UNDERSTANDING what the business is asking for. 

Over the past several years there has been a tidal wave of change around how to gather these important artifacts and then how and when to develop against them.  I’m referring to agile development and the departure, in large part, of the old waterfall methodology.  The reason that I bring this up in the context of finding functional dependencies in your data modeling is that it’s often difficult for the database modeller to grasp the importance and more important the scope around this excercise.  When developing in an agile manner there exists the opportunity to significantly short-cut or otherwise be short-sighted about other related dependencies that exist on the horizon and stories that have yet to be dreamt of yet alone discussed and thought though. 

The methodologies that are discussed in this chapter by Hugo Kornelis are excellent.  They deviate from how I *used* to do this… That statement is made in past tense because I’m going to change how I go about this process based on what I learned in this chapter.  More specifically, I’m going to adopt the concept of utilizing more concrete examples early on rather than abstract concepts.  This is something that I’ve missed early on in my interviewing process in the past and it has come back to bite me. 

This chapter focused on an example around the sales order model.  It’s a commonly understood model and I believe that it helped drive home the important aspects covered in the chapter while not getting lost in the model itself.  The reason that I’m pointing out the obvious is to make the broader point that this is also incredibly relevant in the BI (Business Intelligence) space.  While the data elements are often known and understood by everyone in their domain and perhaps even the data modeller, the abstraction and concepts around shared data elements having multiple truths based on the perspective, is often missed.  If you find yourself in the process of building out a data mart / data warehouse / set of cubes; this information is as critical to that process as it is to a transactional sales order type of process. 

Last week I made this statement: “While there appears to be a loss of expertise in “normal form” or “data modeling”, I disagree, I believe that there is a tremendous amount of expertise in these areas but the distinction is that I believe a great deal of it is thought of as unnecessary in today’s computing environment.“  While this statement still holds true in my opinion, the statement does not hold true when it comes to this subject around functional dependencies.  No hardware in the world can fix a missing or incorrect data attribute. 

In closing, this chapter was AWESOME and I thought it tied together the first two chapters very, very well.  For it’s one thing to understand what hardware is required to build a bird house.  It’s also pretty simple to find a “blue-print” of how to build that bird-house.  But do you ever stop and think to yourself… “What does the bird really want / need” out of this house that I’m building FOR them?  That’s a compelling question that often goes un-answered because it’s easier to just get-ir-done than it is to do it right.