implicitly defines a whole set of screens, reports and processes needed to capture, update, retrieve and delete the specified data.
…
The data modeling process can similarly take us more directly to the heart of the business requirements

When I first read this quote it was like a light going off in my head. I always felt that a good understanding of the data model was 90% of the battle to understanding an application, a business process or even possibly an enterprise.

On reflection, this really shouldn’t be much of a surprise. I think at our heart we are conceptual beings more than task oriented beings. We are often finding new and supposedly better ways of doing things but basically we are still living in a world of people, places and things and the relationships between them. Email, Facebook and Twitter may have changed the way we meet, keep up with and relate to people but it’s still essentially about relationships.

Get the concepts right. The code will follow.

If this sounds a bit on the philosophical side, I suppose that can be forgiven as apparently I’m not the only one who sees data modeling as being a primarily conceptual activity. With this article I also had that feeling of everything falling into place. People have sometimes asked me if my philosophy training was useful and I would say that it really did seem to have a positive impact on my career as a database professional but I never really had the time to sit down and think about why this was.