I have heard/read mixed things on whether to start with an object model or a data model. And more people say to starting with an object model as it will ease your data modelling.
My question is, Shouldn't an object model always drive the design of data model? Why and When would a data model design be different than an object model?
If we have a good object model, shouldn't the classes we come up with translate into tables? And class associations as table relationships?
The question is, does your app serve the database or does the database serve the app?
If you can describe your app/website as a "skin" on a database, you can start with the database structure/schema and code the CRUD because the behavior of the app is to manage data on the disk. You may hit a few bumps in the road.
If this isn't the case, you need to address the behavior of the app besides just the CRUD. There will be information held in the app that never makes it to the database. Much of the logic can be coded without the database. This can help with unit testing or maybe as a guide to keep your code organized and separate the data storage needs.
Who knows. Your app may not need a database at all or something as simple as a text file.
The question is not very rich in practical facts. And practical facts would definitely drive which model might be better to begin with. With that said:
if you start with a relational model and derive the object model, your object model will be conceptually more divergent (and thus almost certainly less useful) from what it is intended to represent than if you began with the object model
if you start with the object model(s) then you will always be able to physically model relationally. however, if your object model is complex, you may need some moderate to expert relational modeling skills to make the "translation", something many (most?) object oriented developers are deficient in
Some reasons the two models may differ:
I've found it best to always start by sketching out a logical domain model. This sort of model is independent of the implementation and focuses on identifying key concepts and their relationships. Eric Evan's "Domain Driven Design" is a great reference for this.
The next step is to design the implementation model. For this, a good rule of thumb is to determine the interface that clients will be using to interact with your model and start there.
For example, if you're building a new OLTP system using an ORM-based framework (such as Rails or Grails), your services and controllers will interact with the model using the ORM interface. Because of this, you'll want to start with designing the object model and let the data model follow from that. ORM frameworks each have their own preferred ways to model object-oriented concepts at the database level and following the framework's preferred way will be faster and less buggy. If you design the data model first and then map it to the ORM framework, you may end up having to jump through hoops to get it to work properly.
On the other hand, if you're building an OLAP system backed by a Kimball-style data warehouse, there will likely be a variety of clients accessing it, such as custom apps and BI tools. A common interface to use in this case is direct SQL access. It provides great flexibility and allows clients to leverage the full power of the database. So in this case, you'd want to focus on the database design first.
Or you may want to start with a behavior model. It depends on the problem at hand. One of the key goals of modeling is to assist the discussions with your nontechnical stakeholders. From this point if view it is useful to frame the model in the context that us most intuitive to those stakeholders. If those stakeholders are deeply immersed in process flows, it might be better to start there, figure out what data is needed to support the behavior and think about how to group behaviors and data into objects a bit later. Admittedly heresy in the "Objects are the Answer to Every Problem" world...but it might get you a better level of communication with your stakeholders, and hence a product with a higher level of user satisfaction.
David Hetherington
