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

"Kenneth Downs" <knode.wants.this_at_see.sigblock> wrote in message news:rkdui2-vbo.ln1_at_pluto.downsfam.net...
> mountain man wrote:
>
>> This thread concerns the relationship between data objects
>> and program objects and the model used to conceptualise
>> the totality of relationships within and between the objects.
>
> OK.
>
>>
>> Cursory study of the ecology of all computer database systems
>> reveal the existence of a number of different species of objects,
>> data objects and program objects being two.
>
> Perhaps we can proceed with this simple distinction:
>
> 1) Data is inert.
> 2) Programs are active.
>
> From this point of view, then the subject of the thread, "...the totality
> of
> relationships ... between the objects" can be understand as seeking a
> relationship between data and actions upon that data.

Certainly, because the only real reason one actually stores data in a database is to perform action upon it, so that the relationship between the two (data and actions) is somehow already predefined in any one instance of (unchinging) time.

However one should note that in real terms the change-management of data and application code (ie: programs) will see that everything is in a state of flux, driven by change in the environment.

> Or, to further rephrase, we are seeking the vocabulary for the meta-data
> that would completely describe both inert data and actions upon data.
>
> A really nifty database product would implement that enriched meta-data.

This is IMO an extremely important conceptual milestone. That "actions" (ie: programs) are regarded a form of meta-data.

>> The relational model of the data is a very good reference for the
>> management of data and its integrity within the RDBMS, but it
>> is totally useless for program objects, and thus is restricted in
>> issues involving the coordination of both data and program
>> objects.
>
> The relational model is permanently hobbled by normalization.
> Normalization
> provides an astoundingly simple and powerful way to pursue conformance,
> but
> it has nothing to offer in the area of *completeness*. A normalized
> database is required to be incomplete, to be missing data that is valuable
> to the computer's human masters, data that would serve them well by its
> existence and which causes confusion and expense by its absence.

How is this term "normalization" best summarised?

>> Since the emergence of addressable stored procedure objects
>> within the RDBMS vendor software at the end of the 1990's
>> program objects have lived within the RDBMS.
>
> Yes! Returning again to your first paragraph, the database server can now
> store inert data and also perform actions upon that data, much more than
> simply playing Schoolyard Crossing Guard and saying what can go in and
> what
> can't.
>
> So, if we had a model that spoke to both structure (data table layouts)
> and
> actions (triggers, sprocs), etc., we'd have the Grand Unified Theory, no?

Yes, I saw that post late last year about relativity and quantum theory. Essentially you have hit the nail on the head, IMO. However, it may be in fact that any unification of database systems theory will require changes in the way people think about the basics of IT management, and even more importantly, IT change management.

>> Given that such an environment exists whereby both data objects
>> and program objects are physically stored within the RDBMS
>> has anyone seen recently any emergent models that address both
>> these objects in a consistent manner?
>
> If the question can be phrased as, has somebody unified a picture of inert
> data and active code, I will say no, though of course that assertion will
> be disputed.

Who would dispute that assertion?

Are there borderline instances of theories out thar? ;-)

> Most attempts to do so seek to stuff one species into the
> mold of the other, or vice versa, without asking the fundamental questions
> about how they are different and how they are alike.

Also, as you point out further below, in many situations there are in fact a cast of thousands involved in IT. Rarely will someone speak from a generalist perspective, and more often than not how people will present a model is to enhance their own perspective rather to to engender the generalist approach.

There are a distinct set of role-types associated with any one organisation that runs a database system, starting with the general internal users, the DBA, perhaps an IT manager, perhaps internal programmers, or development teams, through to management, executive and the business owners.

Externally there can be software houses, contractors, suppliers of software and hardware, etc, etc, etc, and when everything ir reduced to bare basics, each of the afore-mentioned role-types will approach the total model of things from a different perspective, and as a different "relativistic observer".

Thus, many of the aforementioned groups are not in a position to be able to perceive the full picture, let alone model it.

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

Blind Freddy should be able to see that this may represent the next logical step in the unification of database systems theory.

After all, the database dictionary already contains the contraints for the valid terms (ie: database names, table names, columns names) for the base statement that would be used in SELECT, UPDATE,etc.

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

Sophisticated automations all resolve
to a series of simple steps.

>>
>> Do you think it is important to address the issue that a model
>> of both the data objects and the program objects is required?
>> [As distinct from a model only of the data side of the picture]
>
> Me? Yes. That's why I wrote this:
>
> http://www.secdat.com/dev/atomic.html
>
> But it is not a model of unifying code and data, rather it is an expansion
> of the data model to re-organize code and data.

Interesting presentation which I have scanned but not totally assimilated. It looks like a code generator based on a schema garnered by consultative-specification. What programming language is behind it?

>> What obstacles face the conception of such a model?
>> Thanks for any references, articles, etc.
>>
>>
>
> The obstacles are largely inherent within the technology, which gives rise
> to various mindsets and organizations based upon that technology.
>
> Programmers have an action-based mentality. They think in terms of doing
> things. They solve all problems by writing code. They *like* to write
> code. They are also convinced of the existence of mythical beasts known
> as
> *UNIQUE* *CASES* whose terrors can only be vanquished by their gallant
> services. They cannot provide a unified vision because of the personal
> prediliction to code code code code.
>
> Database theorists on the other hand have discovered an island of perfect
> purity, which they have obtained by excluding anything unpleasant or
> untidy, and as Edward Gibbon put it (roughly) "they would not suffer the
> pleasing dream to be interrupted..." In this world, there *is* no
> problem,
> so there is nothing to be solved. Because they cannot fit "redundant"
> data
> into the model (such as the extended=price*qty), they throw away the data!
> Problem solved!!
>
> Then, in a weird converse of Conway's Law, we get shops organized around
> the
> tiers of the system, with skills concentrated in the db camp, the web code
> camp, the HTML camp, and so forth, and the technological divisions become
> organizational divisions and baby that's all she wrote.

These are the role-types surrounding the database systems enviornment that I referred to above. Hence the diversity of POV, and the future requirement to produce a unified database systems theory for which the relation model of the data is but one aspect.

> Those who have valiantly attempted to reconcile the two usually accept
> each
> whole and unchanged and then build an Appollo-Soyuz kind of docking module
> to plug them into each other. These result in very powerful tools,
> indeed,
> but they are still a "handshake in space" in the sense that they do not
> bring any real change to either model, just a space shot does not bring
> real change to the societies on Earth.

A very interesting and unique perspective, thanks very much for your response

>> NOTE:
>> I am aware that there are those here who prefer to classify
>> the modern DBMS software of Oracle, IBM and Microsoft
>> as non-relational. However I do not share this assertion and
>> suggest that these ppls simply ignore the R before the DBMS
>> above.
>
> What does it tell us when every single implementor of the relational model
> chooses not to implement it, and they all choose the same [fixes|mistakes
> compromises]? It should awaken in us a suspicion that the model is
> something like "Pointland" from the Flatland book, a place of perfect
> union, precision, harmony, and completeness, but only if it remains
> isolated in its own world. The Relational Model has never survived
> contact
> with reality. It may be because the relational model is a *mathematical*
> *model* and not an *engineering* *diagram*.

It may be that it is nothing more than a pedagogic device used to fund further replicated editions of itself. We will know this to be fact if one of the further sequels becomes some form of "manifesto" ;-)

>You do not build bridges with
> Newtons law of gravity, though the law sits behind the guiding principles
> of bridge-making, augmented by others and always kept in its proper
> perspective.

Database systems theory today should be out there trying to make valid and worthwhile contributions to the future of information technology --- and inification of data-objects and "data-manipulation-objects" (in some realistic and evolved model) would make an extremely important goal IMO.

Thanks for the dialogue.

Pete Brown
Falls Creek
Australia
www.mountainman.com.au Received on Wed Apr 13 2005 - 11:38:20 CEST