Re: Data Display & Modeling
Date: Sat, 8 May 2004 08:03:46 -0500
Message-ID: <c7ilrv$l2v$1_at_news.netins.net>
"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
news:409c30d7$0$567$e4fe514c_at_news.xs4all.nl...
> Dawn M. Wolthuis wrote:
>
> > Therefore, I see no reason for that R part in any aspect of the system,
> > other than (recent) tradition and the fact that a ton of data has been
> > (unnecessarily) placed in 1NF. If the application of relational
processes
> > were really loss-less, then the data could be viewed the way I like to
see
> > it (but, alas, while non-1NF databases have no problem showing
themselves as
> > if they were relational, the reverse is often not the case).
> >
> > I'd like to see diagramming tools for data modeling to specify data in
its
> > more conceptually simple format of propositions as functions that need
not
> > be in 1NF, showing foreign key links and such -- a web of data.
>
> Could you please refine a little on what's wrong with 1NF ?
>
> I take 1NF to mean:
> a. no duplicates
If you work with functions (as a type of relation) this is automatic -- you
map a key to a tuple -- so count me in on this one.
> b-1. no internal structure in attributes
Complete disagreement on this. The purpose of this, as best I can tell, is
to keep the model as simple as possible (but no simpler). But
mathematically simple and conceptually simple are not the same thing. So,
even if you have to map the more mathematically complex, but conceptually
easier, approach of permitting types with internal structure in your model
to the relational model for some reason, it is worth it. A significant
number of relational theorists seem to now permit attributes with internal
structures, at least relation-valued attributes now.
> b-2. no lists/array attributes (MV)
This follows from the previous one -- once you have no problem with
non-scalar types, lists are fine.
>
> You have been talking a lot about b-2, but what about
> a and b-1 (or aspects I've missed) ?
I accept a and pour b-1 and 2 together. --dawn Received on Sat May 08 2004 - 15:03:46 CEST