Path: dp-news.maxwell.syr.edu!spool.maxwell.syr.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!postnews.google.com!news4.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nx01.iad01.newshosting.com!newshosting.com!69.28.186.75.MISMATCH!hwmnpeer01.lga!hwmedia!news.highwinds-media.com!news-server.columbus.rr.com!tornado.ohiordc.rr.com.POSTED!53ab2750!not-for-mail From: J M Davitt User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.databases.theory Subject: Re: Lucid statement of the MV vs RM position? References: <1145885301.904160.116960@i40g2000cwc.googlegroups.com> <1145887338.204300.32220@u72g2000cwu.googlegroups.com> <1145888298.098659.30180@g10g2000cwb.googlegroups.com> <1145892098.464497.94120@y43g2000cwc.googlegroups.com> <1145895842.391625.118360@u72g2000cwu.googlegroups.com> <1145986872.850803.226960@j33g2000cwa.googlegroups.com> <1146104086.659006.167480@y43g2000cwc.googlegroups.com> <1146405119.341278.269600@j33g2000cwa.googlegroups.com> <1146427454.405766.140990@e56g2000cwe.googlegroups.com> <1146479320.810243.40510@j33g2000cwa.googlegroups.com> <1146520667.985982.314140@y43g2000cwc.googlegroups.com> <1146525657.263941.305480@v46g2000cwv.googlegroups.com> <9VL5g.106714$WI1.4693@pd7tw2no> <1146764758.428373.53970@e56g2000cwe.googlegroups.com> In-Reply-To: <1146764758.428373.53970@e56g2000cwe.googlegroups.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Lines: 119 Message-ID: Date: Fri, 05 May 2006 03:39:36 GMT NNTP-Posting-Host: 24.123.195.58 X-Complaints-To: abuse@rr.com X-Trace: tornado.ohiordc.rr.com 1146800376 24.123.195.58 (Thu, 04 May 2006 23:39:36 EDT) NNTP-Posting-Date: Thu, 04 May 2006 23:39:36 EDT Organization: Road Runner High Speed Online http://www.rr.com Xref: dp-news.maxwell.syr.edu comp.databases.theory:39199 JOG wrote: > Jon Heggland wrote: > >>GUNF intuitively seems very simple to me; like most NFs, it's just >>formalised common sense. Consider an example of the relvar keys relvar (1): >> >>Relvar|Key >>======+======== >>R1 { A } >>R2 { B } >>R1 { C, D } >> >>---i.e. relvar R1 has two keys, { A } and { C, D }, while R2 has but >>one, { B }. Ungrouping (unnesting) it produces the following relation (2): >> >>Relvar|Key component >>======+============= >>R1 A >>R2 B >>R1 C >>R1 D >> >>---and grouping it again produces this (3): >> >>Relvar|Key (wrong) >>======+----------- >>R1 { A, C, D } >>R2 { B } >> >>(3) is different from (1), hence (1) is in GUNF, and the use of an RVA >>is justified. (Actually, Darwen's GUNF formulation is slightly >>different, but I believe my example captures its intent. The point is (I >>think) that there does not exist any relation of type (2) that when >>grouped produces (1).) > > > These are great examples Jon. GUNF is perhaps a missing piece in my > theoretical understanding as it seems to state formally what I have > been struggling with intuitively for months, when I've commented that > "sets shouldn't just pop into existence from nowhere". I have been > struggling with an example for a while: > > A fish can be gold. > A cow can be brown. > A cow can be black and white. > > Animal | Colour > ----------------- > Fish { Gold } > Cow { Brown } > Cow { Black, White } > > With the PK { Animal, Colour }. If I Ungroup I will generate: > > Animal | Colour > ----------------- > Fish Gold > Cow Brown > Cow Black > Cow White > > But this is now not in GUNF because if I regroup I'll get: > > Animal | Colour > ----------------- > Fish { Gold } > Cow { Brown, Black, White } > > Which is of course nonsense in reference to my original predicate. Now > if my understanding is correct, to model this albeit very rough > information, I can now formally show that I will require an RVA. (I > could use a surrogate but I would rather not materialize artificial new > data just to accomodate what I have.) > > Someone affirm this to me or shoot my naivite down in flames. > I think that an all-key relation { animal string, colour relation { colour string } } is very different from relation { animal string, colour string } This, of course, maybe exactly why D+D suggest that base relations consisting of other than scalar types are of limited usefulness. With TutD, I have GROUPed and UNGROUPed a handful of such things, but a key component was never part of the mix. I think you've both uncovered examples which may provide useful insight; thanks. I'm going to ponder a bit... > > >>In contrast, the Barney/Oscar relvar (1): >> >>Name |Colours >>======+------- >>Barney { green, purple } >>Oscar { green, black } >> >>is *not* in GUNF, because there exists a relation (2) >> >>Name |Colour >>======+====== >>Barney green >>Barney purple >>Oscar green >>Oscar black >> >>that when grouped produces (1). Switching names and colours does not >>help, of course. >> >>Your supplier/parts example is probably equivalent to one of the above; >>I'm not sure which, since you don't give all the necessary details (viz. >>keys/FDs). >>-- >>Jon > >