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

"Eric Kaun" <ekaun_at_yahoo.com> wrote in message news:Wb6Zb.39912$sd3.33831_at_newssvr33.news.prodigy.com...
> "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.

No to mention that using the same language for constraints as for queries further simplifies everything.

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

Even if it is a good idea in some situation, making the conclusion requires knowledge of the basics and effort of thought. Received on Thu Feb 19 2004 - 18:29:49 CET