Re: The MySQL/PHP pair

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message news:cmaqq2$a1h$1_at_news.netins.net...
> If you go back to the original Codd papers and look at the definitions of
> relation and normalization, you can see that, as Codd acknowledges, there
is
> nothing in the mathematics that prohibits relations (or functions, bags,
> sets, ...) as elements of relations.

Agreed.

> The rationale for 1NF was to simplify
> the operations at least at the start of our work with data in relations.
> This was not a mathematical argument, but a pragmatic one.

Agreed.

It's important to realize that, at the time of the 1970 paper, no relational database system had been built.
The atomic values limitation, as a pragmatic one, allowed a simplified version of the equality test to be used:

Compare the representation, bit by bit. If there are any bits that have different values in the two representations, or if the two representations have a different number of bits, then they are different representations. If you take the additional assumption that different representations cannot represent the same value, then you have a simple test for equality that the relational engine can carry out, even without understanding the "meaning" of the underlying type. This means the relational engine can do equijoins, even when it doesn't know what it's joining, except to know the representation and the type.

> Relational
> theorists have now ditched 1NF (by redefining it as being a necessary
> property of a relation and not requiring atomic values in relations). So,
> neither relational theorists nor those who were already working with
non-1NF
> data formats require data in what used to be 1NF form.

I have a quible with this. While Date&Darwen and those who agree with them have done what you describe above, I think it's a stretch to say that "relational theorists" are in general consensus about this.

And, among "relational practitioners" the older definition is still in widespread use. And, among teachers of relational database subject matter, the old definition of 1NF is still taught more often than not.

>

> If this does not prove to you that there is no mathematical basis for the
> old 1NF, start where I did -- with the original definitions and papers --
> and see if you can find such a basis for the old version of 1NF

(I REALLY,
> REALLY WISH THEY HAD NOT CHANGED THE DEF DRASTICALLY, BUT HAD DITCHED IT
> ALTOGETHER AND USED NEW TERMS!).
Strongly Agreed.

> What type of proof would you accept -- I could lay out the original def of
> relation and of 1NF and the original arguement for 1NF and show that while
> the def of "relation" is mathematical, the rational for 1NF is not. I can
> point to the statements in the prior works of Date (BR -- before the
> redefinition) where he makes jumps that are not mathematical in the
> discussion of 1NF. But it would be easier if you would point me to the
> discourse that you think has mathematical rigor and I can show you where
the
> mathematics stops and non-rigorous statements are included.

I think the discussion is stalled at thispoint because people are requiring a formal mathematic proof of two things that are not inherently mathematical: the definition of terms and the history of ideas in relational data modeling.

> Yes, there are practical issues and the issue of the query language is the
> one that holds the most water -- when do we move from 1st to 2nd order
> predicate logic, for example.

I think the one area of near universal agreement among RDM theorists is that a universal data sublanguage is needed, and that SQL isn't it.

This is where my practice diverges from the position of theorists: I worked with SQL, and my attitude towards it is that it was "good enough for practical work" in spite of its flaws. I'll admit that I haven't studied any of the proposed replacements at all, and that I don't intend to until one of them emerges as a clear "lingua franca". That's not to say that I recommend my path to others. Practical people are needed, and theorists are needed.

> Once again, IBM has two such databases in their porfolio -- UniVerse &
> UniData and there are many others out there -- Revelation, jBASE, D3,
> mvBASE, UniVision, mvEnterprise, Reality.

I think the following questions are fair, given your prior posts on this subject:

In what ways are Universe&Unidata similar to Pick? In what ways are they different? Received on Thu Nov 04 2004 - 14:40:24 CET