Notes on three Models: Data, Business, Document

[Brian Hayes <Brian.Hayes@Commerceone.com>]

I've taken the time to dig up my notes on the three information models --
data model, business [object] model, and document model.

*	There are three types of data models.  These are the database
schema, the document schema, and the domain/business model.  Each can vary
independent of the other; although, there will usually be a good matching.
*	The database model is often optimized for faster access.  As a
result, the physical model can be different than the initial logical model
(which may have had a good maping to the business model).
*	The business model encapsulates the data according to how it is
understand in the business domain by domain experts.
*	The document model encapsulates the data as it is represented in a
business document.
*	The models are not necessarily identical.  For example, a purchase
order business object may have references to the requisition that was used
to create the purchase order.  The requisition references, however, do not
appear in the purchase order document. Furthermore, many of the business
documents are transactions even though we often think of them more as
business objects (unless, of course, we are treating the transactions as
business objects).  For example, a purchase order can be consider a
transaction (a request for the supplier to fulfill an order).  The
corresponding business object in the buyer's purchasing system is not
necessarily "purchase order."
*	It makes sense to have a unified toolset that generates mapping code
between the three models.  The mapping should be efficient and allow a data
instance to document instance direct mapping.
*	It is desirable to have an access tier(s) in the applicaiton
architecture. The work for accessing a database or document must be done
somewhere.  Ideally it should be encapsulated and packaged appropriately.  A
good choice will increase maintainability and provide a framework for change
from which the system can grow to meet future needs. 

I hope this is helpful,

Brian Hayes