I develop software, mostly web applications. I generally use a backend framework like Ruby on Rails. I have been relatively successful at modeling business domain structures into code and into database structures with a purely hands-on, intuitive approach for 15 years or more -- i.e. trial and error, and reading articles online (eg how best to store money in a database).

I'm considered a "senior" engineer, and seem to find ways to model business problems in code and data just fine. But as the years go by and I'm exposed to and work with data models that others have created, I realize there are many approaches, and I've never really truly studied this in depth or formally, and "sat at the feet of the masters" so to speak. And I'd like to and I know there's a lot I could learn.

I've read books on programming but never books that focus in depth on the art of architecting database structures to model complex real-world domains. Tonight when I went to look up books on the subject, I searched for "data modeling" thinking that would be what to call it, but all that turned up were results for making diagrams. By complex domains, I mean for example the entire domain of a travel touring company, including, itineraries, guides, tours, equipment, flights, registrations, payments, hotels, fees, etc, etc.

So I'm wondering if what I'm wanting to study is a discipline in its own right, with lots of juicy books and case studies, well known pitfalls, etc, or is it something too general to speak of in those terms.

If this discipline has a name, please let me know, along with any resource/book recommendations.


1 Answer 1


Data modelling is the correct term for this. There are logical data models which represent the entities of the problem domain in abstract terms and physical data models which are optimised for implementing using one particular DBMS, taking account of its strengths and quirks. ERDs are used to document both. Modelling software, such as Erwin, can generate the table definition code from the ER diagram.

The science behind modelling is normalisation. This is a set of techniques for organising attributes (columns) into entities (tables) according to the dependencies between attributes. There are many text books and blogs covering this.

The craft of data modelling lies in defining what are the "things" that are included - the ontology. What level of abstraction is appropriate? Do we separate apples from oranges, consider them both to be fruit, or produce, or simply product. The answer will vary depending on the problem being solved. This skill is acquired as domain expertise. There will always be trade-offs in whatever approach is taken.

A search for "industry data models" will return offerings from many well-known providers. A data model encodes the business rules of the domain it covers. Do these pre-packaged models are, at best, a starting point as they do not reflect the specific custom requirements of any particular implementation.

If you have a specific question, concrete question Database Administrators would be a good place to ask.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.