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

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.

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.

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

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

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

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.

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

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

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.

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

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