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?

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.

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.

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.