THE SQL Server Blog Spot on the Web

Welcome to SQLblog.com - The SQL Server blog spot on the web Sign in | |
in Search

Louis Davidson

Perspective in Modeling

Your task, model a database that represents a suburban block.  You survey the area, and see the following houses (pictures culled from Wikipedia here)

and

So you look at the houses, start modeling roofs, windows, lawn, driveway, mail boxes, porches, etc etc. You get done, and with your 30+ tables you are feeling great, right? I know I would be. “I knocked this out of the park! We can capture everything about these houses.  I…am…a…superhero database modeler,” I think, “I will get a big promotion or a raise for sure! Shoot, I will get both!”

So you show this model to the client and they say, “you’re fired. Do you even know what business we are in?” Well, no, I suppose not.  That is the lesson for the day.  Perspective.  Unless you realize the perspective of the client, understand the problems they want to solve, you are missing the point.

One of my “mind exercises” I play when travelling in a car, or at a theme park, or at a doctor’s office, etc is to think about how I could make the place better with database technology. During my family’s excessive trips to Disney World, when I am the slightest bit mentally bored I think about how I could fix things. (RFID in every ticket tracking and predicting next moves, stored in a database for reevaluating how to herd people like the lunch crowd at Tech Ed, for example.)  But driving through a neighborhood the other day, it really hit me.  There are many different ways to look at a block of houses, apartments, flats, etc and model them for usage (in addition to basic locator information like address and perhaps longitude/latitude).

  • Fire Department – hydrant to home to occupant ratio
  • Sales – Number of windows, roof style, lawn, age of home
  • Law Enforcement – Name of occupants, previous law enforcement “contact”
  • Sanitation Department – Number of trash cans (including serial number for tracking), average amount of trash

And so on, but then I thought, what about the Sanitation Department. Take a side loading trash truck (http://vehiclestoys.guidestobuy.com/mack-granite-side-loading-garbage-truck):

`

What if they weighed the trash as the loaded it, then kept records of how they weight varied. They could predict how much trash they could pick up and change routes accordingly. How else might this information be used? The information might also be interesting to law enforcement. This single family dwelling makes 80% more trash that all of their neighbors.  Is this suspicious? Does it hurt to check it out? Is this getting too big brother? Maybe, depending on how the information was used, but it certainly might be used as evidence in addition to an actual complaint.

Privacy concerns aside (not that you have any privacy in your trash, right?) It will be centuries before two government organizations work together that smoothly. It can take 2 change of address forms per government agency to move from one house to another.

In the end of this technically rather soft blog, the point is that requirements govern the design. Unless you know why the user wants you to model something, you cannot do a good job of building a database to meet their needs.  Sure you can build a cool database that stores everything that you can possibly ever desire about a subject, but does it meet the needs of the user? The only way to know the needs of the user is to study them, understand them, and put yourself in their shoes. Figure out their job and build from there. Adding a few extra bells and whistles to delight the user isn’t horrible sometimes, but missing the point is.

Published Tuesday, June 08, 2010 9:54 PM by drsql

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

James Luetkehoelter said:

This is a great post Louis! While on the surface database design is an ontological (yes, I went philosophy on ya!) representation of what is "there", but in practical purposes that can be useless. I still like the idea of starting at that point, but a finished model almost never resembles the abstract logical model. Without knowing how the data is used, or what the data actually means (i.e., what's the business process involved), that kind of blind modeling is just as bad as modeling a database based on a UI design only...

June 9, 2010 12:47 PM
 

drsql said:

Can't disagree with a comment that uses words I have to look up (like ontological, for example) to understand... Well, at least not a positive one :)

June 10, 2010 11:05 AM
 

Hostess milano said:

Privacy concerns aside (not that you have any privacy in your trash, right?) It will be centuries before two government organizations work together that smoothly. It can take 2 change of address forms per government agency to move from one house to another

June 17, 2010 8:19 AM

Leave a Comment

(required) 
(required) 
Submit

This Blog

Syndication

Links to my other sites

Powered by Community Server (Commercial Edition), by Telligent Systems
  Privacy Statement