Re: 1 NF
From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sat, 03 Mar 2007 01:01:17 GMT
Message-ID: <xN3Gh.4814$PV3.45728_at_ursa-nb00s0.nbnet.nb.ca>
>>On Mar 2, 12:34 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>>
>>
>>
>>
>>>On Mar 2, 4:45 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>>
>>>>On Mar 2, 6:54 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>>
>>>>>On Mar 2, 10:40 am, Stefan Nobis <sno..._at_gmx.de> wrote:
>>
>>>>>>Gene Wirchenko <g..._at_ocis.net> writes:
>>>>>>
>>>>>>>"Alfredo Novoa" <alfred..._at_gmail.com> wrote:
>>>>
>>>><snip>
>>
>>>>>N.B. That if the domain is {1, 2, 3, 4, 5} the value "{1, 2}" is not
>>>>>in this domain . This is why an MV approach /using sets/ makes no
>>>>>sense to myself.
>>
>>>>But the domain of an attribute could include sets, right? The domain
>>>>could be a sets with elements from the domain of colors, for example.
>>>>So, if you have {yellow, blue, green} as valid colors, then the domain
>>>>of an attribute could be all subsets of this set or even all lists
>>>>composed of elements from this set.
>>
>>>Yes. And of course then, to be consistent, every element would have to
>>>be a set,
>>
>>Why? Because if we have one element that is a number, all have to
>>be?
>>Of course not! But if you like it to be tidy, you could model
>>each as a set where values might be the null set {}, a set with on
>>element {"j..._at_aol.com"} a set with multiple elements, or even a list,
>>perhaps also modeled as a set {("j..._at_aol.com",0),("j..._at_gmail.com",
>>1)}
>>
>>In any case, each attribute may have its own domain. If one has a
>>domain of sets, others need not. You chide me often,
>>so this time
>>around I'm gonna suggest you could be more careful than you were with
>>that last statement, doncha think?
>>>right? Oh, and anothe for lists. An on and on ad infinitum.
>>
>>Yes, there is an infinite variety of possible domains. I don't find
>>this very disturbing in practice, nor in theory, although I do
>>understand models like pick and mumps opting for all values to be
>>strings or sets/lists/bags of strings, which can then be cast to
>>numbers, dates, etc. It simplies some things, while eliminating all
>>attribute values that are sets, bags or lists simplies other things.
>>There are pros and cons to these things (along with beliefts, of
>>course ;-)
>>
>>
>>>I'll stick
>>>to a nice neat algebra with one type thank you very much.
>>
>>I just cleaned up my bedroom and now the guest room is a mess! You
>>can make one little thing tidy, but when trying to optimize the whole,
>>it might make sense to complicate something, such as within a DBMS
>>engine, in order to simplify application software maintenance, for
>>example.
>>
>>
>>>>>I have swung wildly in my understanding of 1NF and whether or not it
>>>>>made sense to me. I've come out the other side with the belief
>>
>>>>It's all religion, brother ;-)
>>
>>>It's bloody well not for me. It's an engineering problem.
>>
>>That would be my take. I wondered why you brought those "beliefs"
>>into it.
>>
>>
>>>>>that
>>>>>1NF is absolutely essential for good data modelling. However I also
>>>>>believe that being in 1NF does not necessarily preclude propositions
>>>>>with multiple-values (you just couldn't use relations to store them).
>>
>>>>Why not use relations to model these propositions?
>>>>Here is one tuple (add quotes as desired)
>>
>>>>Person(John,Doe,[blue, green, blue, yellow],23,4/6/1956)
>>>>where [...] is a list
>>
>>>>>It is very hard to debate this though because many often assume that
>>>>>1NF => relations
>>
>>>>which is surely not the case with the old def of 1NF and the
>>>>mathematical def of relation
>>
>>>>>and MV => NFNF, both of which are wrong. Rather
>>
>>>>MV is NF2 by the def of NF2. Non-first normal form means that at
>>>>least nested sets are possible because NF2 takes its queues from the
>>>>old (still most commonly-used) definition(s) of 1NF. Deciding that 1NF
>>>>means something different just means that we have overloaded the term
>>
>>>I was not born in 1969, so care little about the origins of the term
>>>1NF. I just care that in my sphere of work there is general consensus
>>>that 1NF means that for any element in a tuple, I pick one value from
>>>one domain. (i.e attribute-value pairs form a binary mathematical
>>>relation - a finite partial mapping in the RM)
>>
>>Most of us can adjust to the term "bad" being a good thing as long as
>>there is still a term we can use for "bad" that doesn't mean "good."
>>Please provide me with a term for the form-formerly-known-as-1NF that
>>will be generally understood in our profession so I don't have to
>>refer to it that way again.
Date: Sat, 03 Mar 2007 01:01:17 GMT
Message-ID: <xN3Gh.4814$PV3.45728_at_ursa-nb00s0.nbnet.nb.ca>
JOG wrote:
> On Mar 2, 10:28 pm, "dawn" <dawnwolth..._at_gmail.com> wrote: >
>>On Mar 2, 12:34 pm, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>>
>>
>>
>>
>>>On Mar 2, 4:45 pm, "dawn" <dawnwolth..._at_gmail.com> wrote:
>>
>>>>On Mar 2, 6:54 am, "JOG" <j..._at_cs.nott.ac.uk> wrote:
>>
>>>>>On Mar 2, 10:40 am, Stefan Nobis <sno..._at_gmx.de> wrote:
>>
>>>>>>Gene Wirchenko <g..._at_ocis.net> writes:
>>>>>>
>>>>>>>"Alfredo Novoa" <alfred..._at_gmail.com> wrote:
>>>>
>>>><snip>
>>
>>>>>N.B. That if the domain is {1, 2, 3, 4, 5} the value "{1, 2}" is not
>>>>>in this domain . This is why an MV approach /using sets/ makes no
>>>>>sense to myself.
>>
>>>>But the domain of an attribute could include sets, right? The domain
>>>>could be a sets with elements from the domain of colors, for example.
>>>>So, if you have {yellow, blue, green} as valid colors, then the domain
>>>>of an attribute could be all subsets of this set or even all lists
>>>>composed of elements from this set.
>>
>>>Yes. And of course then, to be consistent, every element would have to
>>>be a set,
>>
>>Why? Because if we have one element that is a number, all have to
>>be?
> > > No, you have made a mistake that I am sure you will realise on > rereading. You said, and I quote you exactly on this: > > "if you have {yellow, blue, green} as valid colors, then the domain of > an attribute could be all subsets of this set". > > I encourage you to reread that sentence again. In maths this is called > a powerset, and every member of a powerset is itself a set. That, as I > said, then would mean that "every element would have to be a set". > > If you cannot agree with this simple sort of maths then what on earth > can I do? However I give you the chance to retract your pointed > comments. Maybe you read something that wasn't there. > >
>>Of course not! But if you like it to be tidy, you could model
>>each as a set where values might be the null set {}, a set with on
>>element {"j..._at_aol.com"} a set with multiple elements, or even a list,
>>perhaps also modeled as a set {("j..._at_aol.com",0),("j..._at_gmail.com",
>>1)}
>>
>>In any case, each attribute may have its own domain. If one has a
>>domain of sets, others need not. You chide me often,
>>so this time
>>around I'm gonna suggest you could be more careful than you were with
>>that last statement, doncha think?
> > > *cough* > >>>>other to deal with sets. And then another to deal with multi-sets
>>>even if they were just singletons. How screwy would that be.
>>>One would need two mechanisms - one to deal with propositions and the
>>>right? Oh, and anothe for lists. An on and on ad infinitum.
>>
>>Yes, there is an infinite variety of possible domains. I don't find
>>this very disturbing in practice, nor in theory, although I do
>>understand models like pick and mumps opting for all values to be
>>strings or sets/lists/bags of strings, which can then be cast to
>>numbers, dates, etc. It simplies some things, while eliminating all
>>attribute values that are sets, bags or lists simplies other things.
>>There are pros and cons to these things (along with beliefts, of
>>course ;-)
>>
>>
>>>I'll stick
>>>to a nice neat algebra with one type thank you very much.
>>
>>I just cleaned up my bedroom and now the guest room is a mess! You
>>can make one little thing tidy, but when trying to optimize the whole,
>>it might make sense to complicate something, such as within a DBMS
>>engine, in order to simplify application software maintenance, for
>>example.
>>
>>
>>>>>I have swung wildly in my understanding of 1NF and whether or not it
>>>>>made sense to me. I've come out the other side with the belief
>>
>>>>It's all religion, brother ;-)
>>
>>>It's bloody well not for me. It's an engineering problem.
>>
>>That would be my take. I wondered why you brought those "beliefs"
>>into it.
> > > Aw, c'mon that's embarrassing. I have spent a lot of time in > conversation with you and you are giving me that nonsense? You are > saying if I believe something to be true (but do not assert it with > 100% confidence because I realize there is a great deal to learn) that > it must be "religious"? What? I mean.. really...what? > >
>>
>>
>>>>>that
>>>>>1NF is absolutely essential for good data modelling. However I also
>>>>>believe that being in 1NF does not necessarily preclude propositions
>>>>>with multiple-values (you just couldn't use relations to store them).
>>
>>>>Why not use relations to model these propositions?
>>>>Here is one tuple (add quotes as desired)
>>
>>>>Person(John,Doe,[blue, green, blue, yellow],23,4/6/1956)
>>>>where [...] is a list
>>
>>>>>It is very hard to debate this though because many often assume that
>>>>>1NF => relations
>>
>>>>which is surely not the case with the old def of 1NF and the
>>>>mathematical def of relation
>>
>>>>>and MV => NFNF, both of which are wrong. Rather
>>
>>>>MV is NF2 by the def of NF2. Non-first normal form means that at
>>>>least nested sets are possible because NF2 takes its queues from the
>>>>old (still most commonly-used) definition(s) of 1NF. Deciding that 1NF
>>>>means something different just means that we have overloaded the term
>>
>>>I was not born in 1969, so care little about the origins of the term
>>>1NF. I just care that in my sphere of work there is general consensus
>>>that 1NF means that for any element in a tuple, I pick one value from
>>>one domain. (i.e attribute-value pairs form a binary mathematical
>>>relation - a finite partial mapping in the RM)
>>
>>Most of us can adjust to the term "bad" being a good thing as long as
>>there is still a term we can use for "bad" that doesn't mean "good."
>>Please provide me with a term for the form-formerly-known-as-1NF that
>>will be generally understood in our profession so I don't have to
>>refer to it that way again.
> > > There is no relevance in any of this to what I was discussing (to > which your reply was made) - call 1NF anything you want, I don't care! > Its a red herring and I will not let you lead me down the garden path. > What I don't know is if creating these sort of tangents is intentional > to make the conversation frustrating, or if it is genuinely > unintentional.
After this many years, I can see no reason for doubt. Please stop feeding the troll. Received on Sat Mar 03 2007 - 02:01:17 CET