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.


4 Responses to “Chapter 3 — Finding functional dependencies”

  1. February 20, 2010 at 9:33 am

    Good Post and I have to admit I am finding that what you were saying the last paragrah about getting things done, no matter if its the wrong way, just get it done. That is the same theroy that I hearing over the last year that people are calling technology debt. So not only are we coing broke in the wallets as so late, but now thechnology in many places is being alter, changed, added to where the core part of the model has a technology debt that needs to be paid.

    One of the attendees last night at the Denver User Group made menion of how designs are like milk, the difference is Milk has printed experiation date. I believe Technology debt is creating experation dates on our design all around the world.

    Good Post,

  2. 3 Dale Lamb
    February 22, 2010 at 3:57 am

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

    Gotta completely agree with this statement. I always find it to be a useful exercise to get thoughts, especially from the business side, on what the “core business entities” are for the company. Usually I force them to discard any existing ERD or other designs for this and lead them through it in plain-english. It’s amazing how much such a simple exercise can help all aspects of the business talk together with the same vocabulary – which reduces risk and makes future application/database designs more usable.

    Nice post,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s


Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join 11 other followers