Re: Notes on three Models: Data, Business, Document

[Tim McGrath <tmcgrath@tedis.com.au>]

Don't you find that one of the difficulties with dealing with abstractions and
the real world is remembering where you are?

I think the concepts described below are derivative..

Business model (abstract world) gives us the Database model (real world), and
Business model (abstract world) gives us the Document model (real world)

In the real world the Database model  interacts with the Document model

An example which is possibly clearer than the Purchase Order (where the business
object has an ambiguous name) is in transportation of goods.

The 'consignment' business object covers all details of a single shipment of
goods between one party and another (maybe started by one of those pesky
Purchase Orders) .

The 'consignment' document does not exist in the 'real world'.  The 'document'
objects are called "Consignment Note", "Shipment Advice", "Bill of Lading",
etc..

As Brian noted, the parties buying and selling the goods may view these
'documents' differently from the parties involved in handling the goods during
transit.

- hope this is useful.


Brian Hayes wrote:

> 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

--
regards
tim mcgrath
TEDIS   fremantle  western australia 6160
phone: +618 93352228  fax: +618 93352142

begin:vcard 
n:McGrath;Tim
tel;pager:+61(0)299633829
tel;cell:+61 (0)438352228
tel;fax:+61(0)893352142
tel;work:+61(0)893352228
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:tmcgrath@tedis.com.au 
x-mozilla-cpt:;-19376
fn:tim mcgrath
end:vcard