Re: the relational model of data objects *and* program objects

From: Kenneth Downs <knode.wants.this_at_see.sigblock>
Date: Thu, 14 Apr 2005 11:13:48 -0400
Message-Id: <b0e2j2-ilq.ln1@pluto.downsfam.net>

erk wrote:

>
> What is derived and what is data depends on the application, doesn't
> it?

Yes. A complete description of an application includes two things really, a specification for user-entered data and a specification of automations (or actions).

> In that case, something in the specification needs to state which
> is "extended" and which is "real data." I fail to grasp the need for
> and nature of some "transformation" from "extended" to "data."

We denote extended data as "automated". We have no special term for other data, but it is anything that comes in from the outside.

In our data dictionary, the difference is based on the "automation code", which makes it explicit and obvious. Is this what you mean?

table order_details {

   column line_sequence { primary_key: Y; automation_id: SEQUENCE; }

   foreign-key { table_par: orders; }
   foreign-key { table_par: items;  }
   columns { qty,price_manual }
   column price { 
      automation_id: FETCH; 
      automation_formula: items.price }
   column extended { 
      automation_id: EXTEND; 
      automation_formula: price * qty; }

   }
}

>

>> The idea is that the extended values are actually more true than

> their

>> antecedents.  A seller and a buyer haggle over the price of widgets,

> which

>> are 1.00 each.  The seller offers 10 widgets at 90 cents each, they
>> eventually settle on 15 widgets for 13.00, at which point the

> per-widget

>> price is of only historical interest.

>
> Again, given that reports can be run against data of purely "historical
> interest," how is storing this any different than storing
> "non-historical data"?

Not sure what you mean.

>
> Also, if history is important (and it is), why bother storing values
> when you can store the history of the functions/calculations? And
> you'll still need a way of specifying which data should be updated when
> the function changes, versus those which are "first-rate" values that
> are just stored (and thus indistinguishable in my mind from "data" as
> such).
>

>> Two points here.  The "caching" idea is very strong, perhaps that is

> the

>> bumper-sticker slogan?
>>
>> Second: "theory".  Why do we allow a body of abstract mathematics to

> hold

>> the lofty title "theory" when it does not exist to serve human needs?

>
>
> Of course it does. And what theory are you talking about? To quote
> Inigo Montoya from "The Princess Bride": "I do not think that word
> means what you think it means."

The theory of normalization, which keeps out stored values in the name of its own purity, instead of human need. It doesn't mean the body of work is wrong, it just means it should be described more with words like "candidate" or "contributing idea", such elements which are controlled by the real "theory" which seeks to promote human ends.

>
> - erk

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

Received on Thu Apr 14 2005 - 10:13:48 CDT