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

mountain man wrote:

>>
>> "All business rules resolve to database specifications."

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

Short answer: No. Because the "developer" or the person "writing" an application does not manipulate them, this person is interested solely and only in defining tables and columns, with the ability to express automatic values for them.

After that it is repitition and composition. Simple calculations become complex calculations by composition.

Processes, by which I mean the generation or modification of data w/o participation of a human being (or maybe human just pushes "GO" button) can be built up also by composition if you allow for some interesting automations based on foreign keys.

The most tedious processes are those that involve imports or exports to/from special file formats. They are tedious because step-by-step application of transformations until the data is in the right form. This is not implemented yet because, frankly, we don't need it yet.

The most interesting processes are those that cannot be done in 1st order logic, like an ERP allocation process. We have not implemented this one either because we don't need it yet, but it is closely related to the import/export problem.

> Do you have a table to hold the parameters for the creation
> of new columns in new or existing tables?

Do you mean, is the build process table-driven itself? Yes.

There are several tables that define columns. The simplest is the "types" table, which maps our types to the implementation types. This is necessary for things like translating a "datetime" column to its actual SQL DDL fragment, which IIRC is "datetime" in most of the free world and "timestamp" in the MS world.

But that table also allows the definition of constraints on types. So after some trial and error we decided to define a gender type and a "cbool" for "character boolean". These have the constraints defined respectively of "IN ('M','F')" and "IN ('Y','N')". When the builder creates the database it puts code in that enforces these constraints.

Is this what you mean?

>
> 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".

As somebody I once worked for said, "Our systems are fully buzzword-compliant." I have no issue with the term, though it does seem that intelligence is a property of people not machines. But anyway, if pressed I might say that the processes are a part of the production capacity of the enterprise, and the data holds latent insight that can be realized through examination.

>
>
>

>> It all comes down to columns
>> in tables.

An SQL statement is storable as pure atomic data, to be constructed in a millisecond or so when execution is needed, or to be constructed as a view at database build time.

SELECT col1,col2 FROM TABLEX

is the same as this de-normalized table:

query-name table column
----------- --------- ----------

example     tablex    col1
example     tablex    col2

This may seem obvious and irrelevant, but it is crucial, because if you have reduced processes to transform maps, and queries to list of columns (with other stuff like filters and joins also), then your reporting system is now an export system is not an EDI system and a labeling system. One tool to rule them all, one tool to find them, one tool to select them all, and to the wire send them.

>
>
>

>> 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.

>> 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.

Here is the whitepaper that most closely tracks this discussion:

http://www.secdat.com/dev/atomic.html

with this quote that kind of hits the idea well:

"...we begin with the basic premise that the database analyst, in contact with the customer, performs nearly all of the work that requires a human mind, that of taking human experience and turning it into a systematic specification. Our contention is that once that design has been made, the need for human judgement is over." ...and from there a builder should simply create the application for you.

The real nitty-gritty is defined here:

http://www.secdat.com/dev/androspec.html

The final will have a couple of changes (notably the use of semi-colon as terminator instead of the comma as a delimiter), but this mostly describes what you can tell Andromeda to build.

>
>
> Thanks,
>
>
>
>
> Pete Brown
> Falls Creek
> Oz
> www.mountainman.com.au

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