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

Kenneth Downs wrote:
> Perhaps we can proceed with this simple distinction:
>
> 1) Data is inert.
> 2) Programs are active.

It may be simple, but it's also wrong from at least one point of view: programs are mathematical entities, and amenable (more or less depending on the language) to analysis and formal reasoning. Data isn't; its value or perhaps "truth" depends on requirements and context (e.g. the state and nature of the "real world" it seeks to represent), which is precisely why a formal or semi-formal model is important.

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

Isn't this the realm of semantics?

> A really nifty database product would implement that enriched
meta-data.

It would be more than a database product - it would be a model of computation.

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

I take it you don't mean complete in a formal sense? What do you mean?

> A normalized
> database is required to be incomplete, to be missing data that is
valuable
> to the computer's human masters,

A judgement call which can be made and for which corrective action can be taken (e.g. defining more data structures).

> data that would serve them well by its
> existence and which causes confusion and expense by its absence.

Then it's important. And thus worth modeling, right?

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

Databases don't perform actions on data, and if "program objects" in the DBMS do, how are they any different in nature than "external" programs? Their "physical location" is irrelevant.

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

Write String++ and let us know how it goes. :-)

> The normal toy example is an
> automated column extended = price * qty, but if you systematize that
and
> add some other nifty stuff,

"Systematize" - what does that mean? What other nifty stuff? I think this came from a Gary Larson cartoon, where some scientists peruse a blackboard filled with formulas and the words "AND THEN A MIRACLE HAPPENS" in the middle of the derivation.

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

This is an amazingly vague assertion - is there anything behind it? Organize what process?

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

Yes, I entirely agree.

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

Anything I've ever read on relational addresses such things as queries - "extended" is a function, and such things aren't foreign to relational. I don't know what you mean here.

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

Apparently you equate "market success" with "reality"?

> It may be because the relational model is a *mathematical*
> *model* and not an *engineering* *diagram*.

Yes, possibly.

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

And programs are nothing like bridges (judging only from descriptions of bridge-building, since I've never done it). There is no "construction" of any importance in software anymore. Computers offer us an engine for implementing logic. In our field we have far fewer impediments to actually doing theory as practice.

• erk