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
> b-1. no internal structure in attributes
> b-2. no lists/array attributes (MV)
>
> You have been talking a lot about b-2, but what about
> a and b-1 (or aspects I've missed) ?

b-1 isn't quite right - it's simply that the structure doesn't matter to the DBMS or the relational language. Each value has a type, and each type has operations. Even strings have "logical structure" - you can grab characters and substrings. The difference is that the relation is the only "type" (actually a type generator) that the DBMS knows about. The types used in attributes are user-definable, and while the system should provide some useful ones, they're not priveleged.

And technically, b-2 isn't right either. Date admits that 1NF is ill-defined, and that if viewed as a value, a list is as inoffensive as a set or a string. He shows, however, that relation-valued attributes (RVAs) are far more useful, and more consistent. He even gives some examples where RVAs are better than other standard relational approaches. But he cautions against abuse (of course).

• erk