Re: what data models cant do

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Mon, 16 May 2005 09:27:37 -0400
Message-Id: <lqjml2-ks4.ln1@pluto.downsfam.net>

mountain man wrote:

> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote elsewhere:
>

>> IMHO the unified theory describes data organized into tables but which
>> contains system-managed columns and tables.  Because all business rules
>> resolve to database specifications, we are not so much seeking a model
>> that
>> allows management of human-created code, but rather a model that fully
>> supports the generation of automated values.  The normal toy example is
>> an automated column extended = price * qty, but if you systematize that
>> and add some other nifty stuff, you can create a database that can do
>> anything that procedural code can do, and organize the entire process
>> flawlessly from analysis to real-world use.

>
>
> I have been looking around for an article in which I had seen a similar
> treatment of "derivations" since you posted the above, and this evening
> found it again. You may already have seen this one:
>
> What data models cant do --- David Hay
> http://www.essentialstrategies.com/publications/businessrules/brules.htm
>
> In summary, the article details at least four categories of things not
> adequately described in data models:

I'll have to mark my calendar, because on this day I agree with something Alfredo says, though I'm sure he'll argue with me over it anyway.

I found the article a good read, though as Alfredo says it may be only that flavor of model that is lacking.

This raises for me the entire question of data modelling and Kens First Law, "People Understand Tables Just Fine". Because people understand tables just fine, you do not need another layer of abstraction between people and tables. "Models" such as those in the article are only useful because a picture is worth a thousand words.

>
> 1) implied assumptions

Well, here i'd have to say it is the analyst's role to dig all of those out and shed light on them. Unstated assumptions are always bad when human beings endeavor to accomplish some goal.

> 2) when optional relationships are activated

This can be cleared up easily with more tables and more columns. If a database lacks the detail to be fully transparent, then the answer is to put the detail in.

> 3) how to keep multiple paths between entities

Actually cannot speak to this. I have somehow managed to avoid the scenarios he describes.

> 4) derivations [derived data --- see above]
>

At any rate, most of what he could not accomplish with his pictures was tied to the fact that he was not specifying columns or that he needed more tables. This is especially true for derived data.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)

Received on Mon May 16 2005 - 08:27:37 CDT