Re: Data Display & Modeling

"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