Re: 1 NF

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, 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. I'll stick to a nice neat algebra with one type thank you very much.

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

> and now NF2 refers only to one of these two (categories of)
> definitions. But yes, by Def MV ==> NFNF aka NF2
>
> > relations => 1NF
>
> That is just a silly redefinition

It is not a definition. It is a material implication. If I have relations then I also have 1NF. But I do not require relations to have a model in 1NF.

> that serves to make it that we do
> not change our practices to align with our new understanding of
> theory. Relations do not need to be in 1NF by the original and most-
> commonly used def of 1NF. Let's say instead that we now understand
> that relations do not need to be in 1NF. I really, really dislike
> this toying with terms in a way that obscures changes in theory to the
> detriment of our practices. Once there was a pretty widely agreed
> upon understanding that the form-formerly-known-as-1NF was not
> required, we should have said "We don't need to put relations in 1NF
> anymore."
>
> > and NFNF => MV.
>
> This is also inaccurate IMO. MV is acronym for "MultiValue" which is
> a trademark (Spectrum International owns it) for those databases that
> use the Nelson-Pick data model employed by the database formerly known
> as PICK, among others.

I appreciate the correction in terminology - you see, that is helpful. By 'MV' i meant the desire to store or view a proposition of the order "Employee 5 has name 'John Smith' and works for departments 4,5 and 6." without breaking it down into 3 separate propositions. What would you think a better general description/acronym to usre if I am referring to this broad category? (obviously not 'NF2' as that is only a single methodology for encoding the proposition).

> But there are other data models, such as M/
> MUMPS, the one employed by Caché that are non-first normal form and
> are not MV. Cheers! --dawn
>
> > Regards, J.
Received on Fri Mar 02 2007 - 19:34:09 CET