How to define difference between business model and a data model?

Question

I see the term often used as if there is a concrete distinction between the two when discussing MVC for OO languages. From what I get from context it is that business models perform an action to mutate the data models. Is that a correct way to express the difference.

I guess what confuses me though is that most examples of models mix both of these roles and on the surface it feels natural to do. Often the methods that change objects states are inside of those objects themselves. I guess I have trouble coming up with an example of how this works in the real world. It seems more natural that methods to change an object be inside that object. Can any one explain this a little more clearly?

Densimeter

Business Model and Data model have nothing to do with MVC. It does not matter what the front end is (MVC, Silverlight, ...), it should be separated from your Business Layer and Data Layer. – Carner

When you say that "often the methods that change objects states are inside of those objects themselves" you are (probably) speaking of the Active Record pattern. Please see my answer below. – Hawkie

Its interesting that all of the answers, thus far, assume the utilization of a database. I don't know that the data model pertains necessarily to databases. Some programs, even large ones with great architectures don't use a database at all, some don't even persist data. So does this mean they have not data model. I don't mean this to be taken rudely, but it makes me wonder how this applies to applications in general and not just ones that work utilize a database... – Densimeter

this question is about MVC - so it implies that there is a data model. But it does not implies the existence of a database, only that at least a data source exist (it could be a xml file, for example, just like I said on my answer below). – Hawkie

Answer 1

Business models consist of how the flow of data moves within functions of a business. This does not take the data model into consideration, but helps guide how the data will be stored.

Data models are built with the data in mind - where the logic of the business model is based on processes/procedures/just the flow of how things are done, the data model is designed to structure the data in the most normalized way possible that will reflect the needs of the business model.

Buttons

Answer 2

"Business Model" and "Data Model" can both be seen as sub-tiers of the "M" tier, in a MVC application. They both relate to saving and loading data. The difference is that the first is closer to the way the requirements and functionalities are seen by the end-user, and the second is closer to low-level database manipulation.

The Data Model tier is always more dependent of the concrete way that the data is persisted across an application. Starting from the database (or whatever is your concrete way of persisting data - it could be flat files, or XML), it is the first, least abstract software tier. For instance, if you are using the Oracle RDBMS on a application, the data model is where you would place any Oracle particularity, like specific SQL statements, connection etc. That's also the place to implement atomic data manipulation (CRUD SQL statements, for instance). Of course, there are ways to make this tier less dependent of a given RDBMS, like using some kind of ORM library like Hibernate (Java), NHibernate (.NET) or Doctrine (PHP).

Being so "low level", the data model should NOT be used directly by the rest of the application. This is the role of the Business Model.

The Business Model is placed in a upper abstract level. It implements the services that encapsulates all functional requirements needed by the application.

The Business Model should not be dependent of a particular RDBMS - it should use the Data Model to do this job. Another difference is that it exposes less granular methods - not CRUD stuff, but more complex, business dependent functionality. Of course, it should also not be dependent of the presentation layer (views and controllers).

For example, a method that changes the salary of a single employee, based on a literal value, probably belongs to the data model (considering that such functionality is not allowed to the end-user). But a method to increase all salaries on a given percentage would certainly belong to the business model (and it could iterate over all employees, and use that first, "single employee update", data-model method to implement this rule, for instance).

But keep in mind this is a "by-the-book" description - real world scenarios are different. And sometimes we may have no need of two distinct data tiers - the ActiveRecord pattern, for instance, may be used both as a Data Model class and as a Business class. In this case you would mix both tiers into a single one - but I definitely would not recommend taking this approach on more complex scenarios.

Hawkie

Answer 3

The model in a MVC implementation is or should be the business model.

The business model describes the behaviour and attributes of the entities of the business that are relevant to the application. When you code this out, the entities become classes and the behaviour and the attributes will end up as methods and properties of those classes respectively.

The application needs somewhere to store its information. If memory were limitless, we would never have power outages and our OS's would never require restarts, the business model would be sufficient. In the real world however, we need to store the properties of the classes somewhere where they can survive application and/or computer shutdown.

And so the business model needs and uses a data store of some type. The way this data store is organised is the data model. As in most cases a relational database is the data store of choice, the data model is usually the design of the relational database.

While a data model can be at a logical level and then resembles an OO business model more closely, in this context we are usually talking about a technical implementation of the logical model. (One key difference: logical models allow M-N relations between tables, the normalized technical model will have a link table which has a N-1 relation with the two original tables).

The OO nature of the business model doesn't map directly to a normalized table and column design. ORM (Object - Relational - Mapping) libraries are often used to map the classes' attributes to the tables and columns in the relational database.

As the business model uses a data store and thus a data model, and together they comprise the Model in an MVC implementation, the distinction between them often gets blurred. I think it is very much worth keeping their separate roles clear in your mind. It helps in deciding where logic should go.

For example, contrary to rsenna's answer, I would content that changing the salary for a single employee is still a function of the business model, even when changing it to a literal value, because the business model may define all kinds of checks and balances, validation and other business rules to changing an employee's salary. For examply the business could have rules that no salary may change by more than x percent, may never exceed the CEO's salary, be compliant with Union rules, etc.

Though database centered developers and many dba's will disagree, these kind of rules belong in the business model, not in the data model. DBa's prefer them in the data model, possibly because the business model is usually implemented in some kind of programming language and the data model in the database and dba's like to keep their databases nice and valid and consistent.

I would say the rules are still part of the business model, not the data model, but you can of course always choose to implement them in the in triggers and stored procedures (as well). Where the rules of the business model are implemented is a matter of..., well implementation, detail.

Hardly

I said 'probably belongs' - if a developer needs to allow a single-employee salary update functionality, it should be exposed on the business model, of course. But I was considering an application where such functionality is not allowed to the end-user - I guess it was clear enough, but maybe I was wrong. – Hawkie

@rsenna: I understand, but... if an end-user isn't allowed to update salaries on an individual basis, developers most certainly shouldn't be allowed to do so. If you are thinking solving catastrophic stupidity failures, even then no developer should be able to update a production database on his/her own. They may be the ones doing the work, but on a production database it should preferably done by a script, validated by a non-developer to produce the desired results and exected under the account/authorisation of a manager (for example the human resource manager in the case of salaries) – Hardly

@rsenna: maybe I read your comment wrong "a developers allows an end-user", got me thinking in a specific direction. But still, if single employee salary updates are not allowed to any end-user, they should not be possible at all. And failure recovery should be surrounded with proper procedures and not left to any single developer/dba. – Hardly

ah... The "database-should-be-protected-on-all-costs" mantra. :) OK, fair enough. Just remember that this advice, admirable as it may sound, has no direct relation with MVC. In fact, sometimes I may use MVC (and have lots of advantages at doing so) but at same time have a completely unprotected DB layer - many web applications do that way. That's because MVC has nothing to do directly with security - it is about improving maintainability, code decoupling and TDD practices. – Hawkie

@rsenna: of course it has nothing to do with MVC. Actually, I use a relational db as nothing more but a "dumb" datastore... (I do know that this is cursing in front of the dba crowd). Security and authorisation are part of the business model and often times I do not even code referential integrity into the database, it stays in the business layer... Despite that approach, I still make sure the production db is locked down, because that is important (especially for salary and other financial applications) to make fraud and theft as difficult as possible. – Hardly