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

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:0pe7k2-3ac.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>> "Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote
>> in message news:oqevi2-9q7.ln1_at_pluto.downsfam.net...
>>
>>> A useful database will contain data that goes beyond normalization into
>>> automation. What interested me in the OP was my own question: what
>>> theory guides the definition, generation, and protection of automated
>>> data?
>>
>>
>> It would have to be a theory
>> not of "organisational data"
>> but of "organisational intelligence"
>> whereby the processes
>> (ie: programs, automations, etc)
>> associated with the data
>> are also conceptual objects
>> within the theory.
>
> "All business rules resolve to database specifications."

Agreed.

> In Ken's world, the One True Theory would in fact be a theory of
> "organizational data", not "intelligence".

Are all processes (or the parameters thereof) stored in tables? Do you have a table to hold the parameters for the creation of new columns in new or existing tables?

How might you define "the intelligence" of an organisation [in relation to its computer and database systems] if not by the sophistication of the (automated) processes handled by the computer and database systems.

Some folk have an aversion to the term "OI".

> It all comes down to columns
> in tables.

And SQL to query those tables? If the SQL is resident as stored procedure objects, which are not data tables, by what name do you recognise them, if not by simple components of process-intelligence.

> Programs should be managed as commoditized entitites. For instance,
> nobody
> except a very very few apache users want to go digging around in the
> source
> code to change the behavior of the product, they want to be able make a
> config setting. Nobody wants to dig around in Postgres, except a very
> very
> few of the users, to change the code, they want configs and commands.

An interesting approach.
I will think about this.

> Those two examples, apache and postgres, along with their competitors,
> have
> commoditized their domains. But database applications themselves are not
> yet commoditized.

> Secure Data Software, with our theory of db management, and our Andromeda
> tool, seeks to achieve this level of commoditization with application
> software, that you would never consider tweaking the code of the
> application itself, you would tweak the "config" of the program, which is
> its data dictionary, and let the system handle the details for you.

Point me at your website again.

Thanks,

Pete Brown
Falls Creek
Oz
www.mountainman.com.au   Received on Fri Apr 29 2005 - 05:50:48 CEST