Re: The MySQL/PHP pair
Date: Thu, 04 Nov 2004 07:20:46 GMT
Message-ID: <iLkid.797$vM2.633_at_trnddc09>
"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
news:cmaqq2$a1h$1_at_news.netins.net...
> "Dan" <guntermann_at_verizon.com> wrote in message
> news:Kg0id.6107$wP1.5011_at_trnddc09...
>> >> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message >> news:cm93fd$g11$1_at_news.netins.net... >> > "erk" <eric.kaun_at_pnc.com> wrote in message >> > news:1099431388.630616.174500_at_f14g2000cwb.googlegroups.com... >> >> >> [snip] >> > >> > It makes sense to bring it up since I have yet to PROVE all of my >> > concerns. >> > I have proven, I think, that 1NF as currently implemented by most
> software
>> > developers (the old version of 1NF) has no mathematical basis. >> >> What is this proof, pray tell. I've asked for a demonstration already
> where
>> attributes of a relation are anything less than an elements in the >> mathematical or logical sense when operated upon by relational operators. >
> 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.
Oh really?
Codd wrote: "A relational database is a time-varying collection of data, all
of which can be accessed and updated as if they were organized as a
collection of time-varying tabular (nonhierarchic) relations of assorted
degrees defined on a given set of simple domains." (p. 399).
Concerning domains, he wrote:
About the relational model he wrote:
"The relational model consists of
(1) a collection of time-varying tabular relations (with properties cited
above - note especially the keys and domains);
(2) the insert-update-delete rules (Rules 1 and 2 cited above);
(3) the relational algebra describedin Sections 2.2 and 2.3 below.
Closely associated with the relational model are various decomposition concepts which are semantic in nature (being time-invariant properties of time-varying relations). Examples of such concepts are nonloss (natural) joins and functional dependencies [6], multivalued dependencies [10,44], and normal forms. (p. 400)."
References:
Codd, E.F. (1979). Extending the database relational model to capture more
meaning. ACM Transactions on Database Systems (TODS), 4:(4). [Online]
Available at the ACM Digital Library at http://www.acm.org.
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. 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.
Well, perhaps this gives light to your confusion. Since when is a data format have anything to do with normal form? If it is a non-decomposable value at the logical level (irregardless of format) then it is a value from a simple domain.
>
> 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!). There is, nor has there ever been, any
> mathematical rationale for the old 1NF and Codd did not pretend that there
> was such (at least at the outset).
See my quote above.
>
> Those who still keep to it because it is simpler than other models are
> trying to simplify the wrong thing -- they are trying to simplify the
> machine rather than the work of the user..
>
If you are talking about queryable logical elements, I am still convinced that Paul is absolutely right. There is a distinction between the relational model/relational engine and the type system. Types can be as complex as you want, nary the relational engine the wiser. It will still think of any type value as 1NF.
>> Since others >> > have already ditched it, or redefined it to the point where every
> relation
>> > is necessarily in 1NF, that is just a start.
Four people who are chummy in a usenet group doesn't necessarily constitute absolute justification or agreement. Sorry.
[snip]
>
> 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 have not studied that at all, I'll admit,
> but I have something else to counter questions of practicality -- a system
> that works (it would fit the def of "legacy" given by Gene in another
> thread). There is a query language that goes by many different names (one
> for each implementation of the Nelson-Pick model) that successfully
> queries
> nested structures to a depth of n levels (n differs a bit but figure only
> 3)
> and that depth of nesting is just about what the human brain uses when
> forming statements (predicates), I'll claim. So, is it practical to leave
> the property formerly known as 1NF in the dust -- yes, it was practical
> before 1NF was born and it is practical today (dare I mention XML?)
>
Or how about functions, like you've proposed before?
"Q: A data model in which functions play a central role appears to have the advantage of making algorithms and data more interchangeable. Why not replace n-ary relations of the relational model by functions (some or all of which may be set valued)?
A1: If you are trying to convert the relational model into a model for describing the various logical and physical data structures that are now in use, this might be an appropriate step to take. Let us assume, however, that your intent is to presever the dual role of the relational model in data base systems architecture -- in the principal schema the role is to serve as a framework for data control (authorization control, access and update concurrency control, integrity, and recovery); in the user schema the role is to serve as a common, general purpose interface for users of many different types (<underlined> not just programmers</underlined>. In this case a strong argument agains such a step is that either it destrays the symmetric exploitation property of the replaced relations or else it requires an absurdly redundant collection of functions.
To illustrate the problem consider...... (you'll have to read the paper yourself for this section)
....
Finally, a comment on the alleged advantage of a data model based on functions: namely that of making algorithms and data more interchangeable. The virtual data concept is very important, but its application is not at the logical level -- it is at a level that is oriented more to the strategy of storing and processing (i.e. a physical level). The relational model protects its users from concern with the underlying technieques used in materializing data."
References:
Codd, E.F. (July 1974). Understanding Relations (Installment #4). ACM Sigmod Record. 6:(3). [Online]. Available at the ACM Digital Library at http://www.acm.org.
Other questions addressed by Codd in this paper include: * Whether it would be advantageous to to replace every n-ary relationship having a set of domains with functions that maps a surrogate identifier domain into each of the ranges of the domains. * Replacing n-ary relationships entirely with binary relations (something along the lines of Dawn's digraph assertions).
>> A simple model which is conducive to cheap, dynamic optimisation
> algorithms
>> using semantic or logical transformation might no longer be able to
> leverage
>> the same formal framework in terms of query decomposition and
> normalization.
>
> 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.
Then use those as a basis for a data model. If these are sufficient, then use them as a starting point, independent of what most accept as the relational model. Let's see how they stack up when you are done.
I find it somewhat humorous that you call a relational database implementation bloated, complex, and inaccessible. Considering the adaptivity and power of relational optimisers, such systems are pretty complex, but I can't wait to see a system with an optimiser of equal power using the extensions you propose in any one of the implementations you reference above.
> >> The definition of logical and physical independence will in all >> likelyhood >> have to be readdressed to clearly demonstrate and define at what level >> nesting occurs - the base logical level, at the physical level, at an >> external level, etc. This might seem self-evident to some, such as our >> esteemed Java programmers out there, but it isn't clear to me. >
> I care only about the logical, design level where a human being is
> interacting with the model.
>
> As an aside, what language do you prefer be used for production software
> instead of Java?
>
The dreamy, intuitive, blah, blah, blah is snipped here.
>
> I don't have the answer as to what would make software development more
> flexible, agile, productive,... but I am certain that the current RDBMS's
> need significant changes and I would rather start with earlier, more
> productive environments and evolve those to what we need than start with
> the
> rigid, bulky RDBMS's of today.
> >> There is a reason why analog communications and analog switches in >> communications networks are going by the wayside. They are sufficient >> and >> maybe even superior for the application they support, switching and >> conveying analog signals, but they aren't sufficiently general enough to >> scale for multiple applications, nor are they cost-efficient. Moreover, >> they are more complex and error-prone. >> >> In much the same way, I wonder how much benefit gets from adding this >> complexity to the data model. What is this fascination with binding a
> data
>> layer with an application layer, and with such close coupling? >
> It is the RDBMS that added complexity to the model -- requiring 1NF when
> people naturually think in lists and nested structures, for example. I'm
> looking to decouple the data constraints layer from the persistence
> mechanism.
"Numerous authors appear to think of a data model as nothing more than a collection of data structure types. This is like trying to understand the way the human body functions by studying anatomy but omitting phsiology. The operators and integrity rules [..] are essential to understanding how the structures behave. In comparing data models people often ignore the operators and integrity rules altogether. When this occurs, the resulting comparisons run the risk of being meaningless.
....Such models should [..] be regarded as partial or incomplete data models."
References:
Codd, E.F., (June 1980). Data models in database management. Proceedings of the 1980 workshop on data abstraction, databases, and conceptual modeling, pp. 112-114. [Online]. Available at: ACM Digital Library at http://www.acm.org
> Let me know if/where what I've written is unsatisfactory and I'll see if I
> can state it better. Thanks. --dawn
>
>
Received on Thu Nov 04 2004 - 08:20:46 CET