Re: Multiple-Attribute Keys and 1NF

On Sep 1, 5:21 am, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Sep 1, 2:31 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>
>
>
>
>
> > "David Cressey" <cresse..._at_verizon.net> wrote in message
>
> >news:UfUBi.12075$Eh5.9962_at_trndny06...
>
> > > "JOG" <j..._at_cs.nott.ac.uk> wrote in message
> > >news:1188556656.192653.305160_at_r23g2000prd.googlegroups.com...
>
> > >> Well I've never suggested multiple values contained in a collection.
> > >> But yes as I said, multiple roles does break the guaranteed access
> > >> rule. My question is now (in the continuuing hunt for the theory
> > >> behind 1NF) is why on earth would that be a problem? I don't see any
> > >> affect on the relational algebra.
>
> > > I honestly think that the impetus behind "normalization" in the Codd 1970
> > > paper is more of a stopgap than a theory. (I'm not familiar with the
> > > 1969
> > > paper, and I only read the 1970 paper after I began participating in the
> > > discussions in c.d.t.) In the 1970 paper, Codd suggests that it may be
> > > worthwhile to consider the subset of schemas that contain only atomic
> > > attributes. (He didn't use the word "schemas", but I hope I can use it
> > > without introducing confusion.)
>
> > The whole point of 1NF boils down to the following two sentences from the
> > June, 1970 article: "The adoption of a relational model of data, as
> > described above, permits the defelopment of a universal data sublanguage
> > based on an applied predicate calculus. A first-order predicate calculus
> > suffices if the collection of relations is in normal form." Therefore, the
> > impetus behind "normalization" is to model the universal data sublanguage
> > after a first-order logic rather than some higher order logic.
>
> That's a great quote - probably the best reasoning i've seen for 1NF.
> Thanks.

I've suggested that I can do much simpler things in my code if the user will put up with fewer features before. Sometimes they go for that. There are trade-offs. That might make the code more reliable, faster, more maintainable, less costly to write, or this or that, but users don't just say "sure, whatever is easiest within the code, the machine, or the theory, that is all I need."

In fact, most of us would not suggest that users roll over and play dead in their efforts to improve their jobs just because of some complexity in providing them the features they desire. Similarly, users of data models should not just accept first-order logic as the end of the story. Those users are working to get a job done, with requirements to do such things as ripple deletes, ordering data, blending multiple propositions into one in various ways, handling many- -many relationships, etc.

So, even if it were the beginning of the story, the ability to employ first order logic is not the end of the story on this one, I would hope. Don't give up. The industry needs you. Cheers! --dawn (going back to lurking, not to worry).

<snip> Received on Sun Sep 02 2007 - 22:36:14 CEST