Tuesday, July 25, 2006

Today I give an Enterprise Architect some advice...

Greg Fullard is starting a series of articles about 'Business Objects" (conceptual ones, not the BI software) in Object Orientation at the IT Toolbox blogs,and he is a good writer. See:

http://blogs.ittoolbox.com/cio/modeling/archives/how-to-design-beautiful-business-objects-part-1-10718#

But he has a question I felt I could answer:
"Aren't these business objects that I keep talking about just the same as the Entities that my grandpa used to tell me about?"

The simple answer is... No.

Object Orientation has always been about producing better software, easier to maintain and primed for re-use. Entities, Relationships and Data Modeling in general has always been about producing better databases, usually (if not always) relational databases that eliminate data redundancy and are accessible without physical limitations (like old hierarchical DBMS's).

Where OO and Data Modeling look the same is their focus on key items of interest to the domain (business, government, non-profit, etc.), so good models will likely have the same-named things in them, like Customer. So what's the difference?

1) A Customer Class in OO is usually focused on one occurrence (Object) at a time, and the behaviors associated with it. A working OO system instantiates at object at some point, some methods (behaviors) are exercised, and then the object is gone. The only wrinkle on this is OO's recognition that some Objects are persistent, that they may be stored somehow and be used again.

2) A Customer Entity in a Data Model is usually focused on defining all the data attributes that need to be stored for any and all occurrences of Customer for the domain. As a blueprint for a relational table, the focus here is on managing many occurrences of Customer, as many as the domain needs to keep track of.

So, two different models, because they are two different things. The interrelationship between them occurs when a persistent Object needs to be instantiated; where do OO systems get that data? Far and way it is from relational databases, since I have not seen a (commercially) viable OO database yet.

So, two different models, and don't believe anyone who says a Class Model and a Data Model are equivalent, they are not... but you can derive a Class from an existing data model. Does anyone want to know how?

1 comment:

Anonymous said...

Interesting site. Useful information. Bookmarked.
»

About Me

Ontario, Canada
I have been an IT Business Analyst for 25 years, so I must have learned something. Also been on a lot of projects, which I have distilled into the book "Cascade": follow the link to the right to see more.