X-Received: by 10.224.59.205 with SMTP id m13mr25814956qah.7.1367710081848; Sat, 04 May 2013 16:28:01 -0700 (PDT) X-Received: by 10.182.96.67 with SMTP id dq3mr200333obb.30.1367710081516; Sat, 04 May 2013 16:28:01 -0700 (PDT) Path: news.cambrium.nl!textnews.cambrium.nl!feeder3.cambriumusenet.nl!feed.tweaknews.nl!209.85.216.88.MISMATCH!m7no2192107qam.0!news-out.google.com!y6ni0qax.0!nntp.google.com!m7no2192102qam.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.databases.theory Date: Sat, 4 May 2013 16:28:01 -0700 (PDT) In-Reply-To: <54934075-6dd1-4f96-9c6f-50db406a7586@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=205.250.214.154; posting-account=FUDi7AoAAACOn42BTSjw9ZlWNiwGl2Nx NNTP-Posting-Host: 205.250.214.154 References: <992824d5-5a8a-4a63-906b-7d3eff2a0b47@googlegroups.com> <51445299$0$582$e4fe514c@dreader34.news.xs4all.nl> <3bd262e6-f9b2-4861-8327-fe31af438cd3@googlegroups.com> <51803a2d$0$6337$e4fe514c@dreader35.news.xs4all.nl> <279c7cc9-3e6f-490f-a692-af98fc134fc3@googlegroups.com> <36bb212d-47ae-4cb0-bf2b-a926ff2173d4@googlegroups.com> <54934075-6dd1-4f96-9c6f-50db406a7586@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: How to normalize this? From: compdb@hotmail.com Injection-Date: Sat, 04 May 2013 23:28:01 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.cambrium.nl On Thursday, May 2, 2013 3:40:28 AM UTC-7, Erwin wrote: > > > It's often bothered me that normalization theory/procedure seems to q= uietly ignore the notion of "nullability or not" of any of the attributes i= n the "initial table design" ... > > > Iow, that normalization theory per se doesn't actually allow to deter= mine when and when not the phenomenon is "an artifact of the iniital table = design". > However, I'd argue that there is indeed "a phenomenon", and it's exactly = the phenomenon you described as the "...a...b...c...d...some e..." vs. "...= a...b...c...d..." confusion. You have changed the meaning of "phenomenon" from some alleged constraint i= mposed by an original single-relation schema to certain difficulties with c= ertain design processes or their presentation. (Presumably you were concern= ed with the latter but hypothesized the former as the cause.) > Jan observes that in practice most of the time, making this "mistake" lea= ds people to "discovering" the correct predicates for the business problem = at hand, and seems to be on the side that therefore it must be a good thing= , I personally am rather bothered with the fact that a theory would be usef= ul because misunderstanding it or only partially understanding it, in pract= ice mostly leads to correct designs being derived from less correct ones ..= . I agree with you that most (all?) presentations of db design and of normali= zation and the role of the latter in the former are poor. But you seem to c= onfuse the latter with the former. Eg normalization addresses replacing some relations with others but doesn't= generally address information equivalence and constraint preservation, whi= ch is different from non-loss decomposition or FD preservation. Eg when you normalize a relation variable based on FDs you have have to kno= w its FDs so you have to know its predicate. (If you didn't have have a pre= dicate in mind, why would you even have a relation variable?) So normalizat= ion cannot be expected to generate proper predicates. I agree a design proc= ess, incorporating normalization, should. Eg if your only predicate/variable on attributes A1,..,An is p(A1,...,An) t= hen the only predicates you can express on a subset of Ai,... involve "exis= ts Ai,... p(A1,...,An)". For any tuple to be in its value there has to be c= orresponding supertuple(s) in p. So if you find that you want to express pr= edicates when there *doesn't* have to be all n values (or corresponding thi= ngs) then this predicate is inadequate. If you don't bother to think about = what predicates you are interested in ie queries you want to pose and only = bump into it when normalization presents you with predicates on attribute s= ubsets (what did you expect it to present you with?) then that is not a fau= lt of normalization. philip