Re: In an RDBMS, what does "Data" mean?
Date: Wed, 09 Jun 2004 19:58:29 GMT
Message-ID: <FZJxc.388$Pt.151_at_newssvr19.news.prodigy.com>
"Anthony W. Youngman" <wol_at_thewolery.demon.co.uk> wrote in message
news:UXeCeOK16OxAFwRR_at_thewolery.demon.co.uk...
> >So what mathematical axioms do you know of that "map to reality"? I
didn't
> >realize that was the fundamental aspect of an axiom's value. And if it
is,
> >then again, what data axioms do you propose as a good start? They needn't
be
> >formal, but have to have more meaning than "data comes in tuples".
>
> e=mc^2 ?
>
> Yep. I know it's bl**dy difficult. But if you're not prepared to attempt
> it, then you're admitting your theory is irrelevant to the real world
> (and cannot be used to solve real-world problems).
That's silly. The following have all been used to solve real-world problems:
- Pick - SQL - Relational (assuming Dataphor has at least one real-world solution inplace somewhere)
- Flat files
- XML I don't know the "axioms" of the flat-file solution, and don't think that Unix's "everything is a file" is really an axiom. What they're saying is that we have a useful model that treats all data as files.
Besides, who is attempting it? What attempt has MV made? I don't understand what you're looking for here - do you want science, math, or neither? In whatever category you want, what does Pick/MV offer? You seem unwilling to pick up your own gauntlet.
> Let's take the evolution of that theory I keep on throwing out as an
> example.
>
> Copernicus : orbit == circle
> Kepler : obit == ellipse
> Newton : F=ma; E=1/2mv^2 where m is constant
> Einstein : e=mc^2
>
> Each change may only subtly modify the previous axioms, but the result
> is theory/model that is a closer fit to reality.
I don't think the above are axioms in the mathematical sense, though I could be wrong.
> Going back to relational theory. Does the THEORY distinguish between a
> "join" and a "join with a cascading delete"?
Cascading deletes are useful for implementations, not part of the theory - a cascading delete is simply nice shorthand for an implicit multi-update (as advocated by Date in recent writings), and roughly corresponds to the usefulness of the "foreign key" concept in place of a longer-winded constraint definition.
> Or a "join" and a "join with a foreign key that must exist (cannot be
null)".
In relational, all foreign keys must exist, and no attribute value can be null.
> Because if relational theory cannot cope with that, then the Pick model
can.
"Cannot cope with that" implies that there is some objective reality that's presenting X, and that a model that doesn't "cope with" X is a poor match to reality. While I agree with the implication overall, the premise is false - there's no objective reality "presenting" cascading deletes or nulls. Those are both aspects of modeling data. There's no objective reality with which those correspond. At best, you're pitting Data Model A against Data Model B, and claiming B is lacking in attribute C, when C doesn't even enter into Data Model A.
> And surely, a relational table who's rows are meaningful in their
> own right MUST be different from a table who's rows are meaningless
> without another table to relate to?
"Meaningful in their own right" is rhetorical - every relation has a meaning (the external predicate). To turn the question on its ear, surely a Pick file which requires applications to enforce the correspondence between values in several distinct attributes MUST be different from a file whose attributes refer to the IDs of other files?
- erk