Re: 1 NF

On Mar 2, 6:25 pm, "JOG" <j..._at_cs.nott.ac.uk> 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:

dang, yes, I should have said the domain of an attribute could be the set whose elements are all subsets of this set. I thought the shorthand  would be understandable (language being a tool for communication and all).

>
> "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.

Yup.

> That, as I
> said, then would mean that "every element would have to be a set".

Yes.

> If you cannot agree with this simple sort of maths then what on earth
> can I do?

I do agree. I thought the shorthand would communicate the idea, and it seems to have, but I should have been more precise.

> However I give you the chance to retract your pointed
> comments. Maybe you read something that wasn't there.

I have corrected it to be more precise.

> > 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*

So, you are going to stand by
> > > Yes. And of course then, to be consistent, every element would have to
> > > be a set,

Really? The domain for each element of your relations must be the same? Or they must all be sets of sets if one is? Must they all be sets of numbers if one is? Of colors if one is? What is the logic behind this kind of consistency? (Brings to mind "A foolish consistency is the hobgoblin..." quote)

> > > even if they were just singletons. How screwy would that be.
> > > One would need two mechanisms - one to deal with propositions and the
> > > other to deal with sets. And then another to deal with multi-sets
> > > 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?

There was a wink after it, sorry for the extraneous banter. --dawn Received on Sat Mar 03 2007 - 06:27:19 CET