3

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?

  • You are assuming that there will always be a table storing data. This is not always the case. It might be XML, it might be graph database or a text file. Object model may guide your database design (assuming you are using relational database), but I wouldn't use it as a rule. – CodeART Apr 22 '14 at 16:25
3

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.

2

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

0

Some reasons the two models may differ:

  • you have to use an existing database
  • a data model directly modeled like the object model may not give the required performance
  • not all classes end up in storage
  • as @CodeART commented, you may need to use a different storage technology then a relational database
0

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.

-1

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

  • this post is rather hard to read (wall of text). Would you mind editing it into a better shape? – gnat Apr 23 '14 at 15:14

protected by Community Apr 23 '14 at 14:47

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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