Re: Codd provided appropriate mathematics ... (was Re: Relational and MV (response to "foundations of relational theory"))

"Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote in message news:c12ia2$p0l$1_at_news.netins.net...
> "mountain man" <hobbit_at_southern_seaweed.com.op> wrote in message
> news:r3%Yb.66336$Wa.13812_at_news-server.bigpond.net.au...
> > "Neo" <neo55592_at_hotmail.com> wrote in message
> > news:4b45d3ad.0402181740.42d42bc2_at_posting.google.com...

> I have found at least one area where Codd takes a jump mathematically.
I'm
> not taking the time right now to get his exact wording, but a summary is
> this:
> [...]
> 3. There is no mathematical foundation for putting the data into 1NF
except
> for what Codd and his followers indicate is that the model should be as
> simple as possible but not simpler and they indicate that without
resorting
> to nested relations, the model is as simple as is needed. This is NOT a
> mathematical conclusion. Even if we were to accept the non-mathematical
> statement that a model should be as simple as possible but no simpler,
there
> is no proof that for the user of a data model, it is simpler to have flat
> relations. I would suggest that there are tradeoffs and it is not at all
> clear that flat relations are a "simple" way to think about data.

Regarding simplicity and "usability", there can't really be mathematical arguments. Occam's Razor is hardly mathematical. There's simply a more direct correlation between relations and logic than between any other "data model" and logic.

In fact, the more indirect those mappings (logic to your data structures), the worse programming gets. Objects are fine to a limited degree (to the degree they correlate to types in classical type theory), but inheritance causes problems unless it's disciplined and rooted in type and set theory (e.g. The Third Manifesto). XML and other hierarchies order and nest the data in a very specific way, and that's fine as long as all you're doing is navigating in that same way. Come time to flex the order of traversal, and you're in trouble, doing much more work than you need to.

Here's the real rub: relations allow you to reason soundly, and in arbitrarily complex ways, in terms of atomic propositions (which means it takes more work to develop them, due to the fact that you have to think about what those propositions are!) That means your application can grow "linearly" with respect to functionality and query complexity - hard questions are hard, easy questions are easy. With a hierarchy, a single brand of complex question is easy, and other things are murder; plus you have to write those other things in baroque hierarchy-scanning procedural code.

Oh, and besides all that, a decent constraint language lets you enforce all that, and even generate the corresponding client-side pieces (see Dataphor). The constraints and relations SAY something meaningful and specific.

This all suggests to me that the "egalitatian" view of relations, that all predicates are created equal, has benefits to both correctness and productivity. Sorting them according to importance (when that's unnecessary to correctness, and only necessary to productivity if you make a good guess) is highly error-prone and subjective.

But again, if you only ever need to show a screen of data, let the user type stuff, save it, and then query the same thing later, then the fixed hierarchy that corresponds to that screen may be suitable. I have severe doubts, but maybe. I just would never do it - even in Pick, I'd do something normalized.

• Eric