Data Modeling: A Balancing Act of Conflicting Objectives

It is a largely forgotten film now, but “The Magic Christian” once had cult status. 

In one scene, Ringo Starr is in a car reading instructions about facial isometric exercises while trying to follow along.  He reads, “number 7, the silent scream…” which involves stretching the facial muscles and making your face as large as possible. Next comes, “making it as tiny as you can, try and make your face disappear.”  Moments later, per instructions, he engages in an effort to perform both silent scream and tiny face concurrently. 

While these exercises were intended to be absurd, metaphorically they relate to tasks often asked of a data modeler. Data modelers must look at the big picture of an organization’s data ecosystem to ensure additions and changes fit in properly.  Simultaneously, each data modeler must be focused on the minute details, adhering to naming standards, domain rules, data type practices, still remaining ever vigilant for instilling consistency across everything they do.  And while focused on all of the above, their efforts must culminate in a practical model that serves the individual project’s requirements while also being implementable, maintainable, and extensible.

Sometimes data modelers end up trapped on one side of the spectrum or the other.  Those who forget the small stuff, focusing only on the big picture, are said to have lost touch.   They may design wonderful gems of database models providing everything asked for and more; but the models incorporate aspects based on data that cannot be sourced, or processing and business rules so very complex that development efforts would be phenomenal, or worse, impossible.  On the other hand, those data modelers focused on minutia are often considered short-sighted. 

The resultant database models from these short-sighted folks may work well as one-off solutions, but still be at odds or counter to the rest of the organization’s IT portfolio.  These designs would be candidates for the title of “does not play well with others.”  One of the advantages of having good data management, administration and architecture practices is the increased reuse, expansion of understanding, and a short-hand in many facets of implementing solutions across the enterprise, by having a high level of consistency.  When out-of-touch or short-sighted, the resultant database models may be lacking in overall quality.

Ganesh comes to mind as a great choice for the patron Hindu god of data modeling.  Ganesh is the one with the elephant head; he is often seen hanging out with his buddy, a mouse.  Ganesh is an accredited problem solver, and a patron of writers.  When facing an obstacle like a wall, he can batter it down using his head, literally. Alternately, he can jump onto his mouse and ride through tiny cracks to get to the other side, much like a data modeler must overcome various conflicting goals, needs, and circumstances.  A data Nirvana, where database models are perfect, is not a realistic goal; but it is possible to establish a healthy environment where data models are good enough for now, where things are not only allowed to grow, but expected to evolve and change so they continue to be good enough as the future unfolds.

Too many IT shops today think of completed projects as one-and-done efforts; and for tiny solutions, that may be fine.  These solutions will live their short lives and simply be replaced in whole, later.  Substantial initiatives require a little more supporting them, more forward thinking, more hooks holding the right things in place, more flexibility allowing the right things to evolve without breaking down.  Among others, those modeling the database are in the front lines setting a foundation for success.