Re: Data Display & Modeling

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 08 May 2004 22:09:13 +0200
Message-ID: <409d3e6c$0$65124$e4fe514c@news.xs4all.nl>

Dawn M. Wolthuis wrote:

> mAsterdam wrote:

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

Ok. Clear enough.

What would be an approprate name for this construct? Not "relation", as that would prevent any sensible dicussion. I could not think of one yet.
The only difference with a relation (or relational variable) would be that it's attributes would be allowed have an exposed internal structure, b-2 (lists) being a relatively simple case of that.

Say model H allows relations and these constructs. One preliminary thing: I suspect it is practical that we should be able to easily distinguish attributes as either atomic or structured.

One approach is historical : Why the restriction?

Anoter one is: Qualify existing systems as being more H-ish or more R-ish, and let the proponents brag about their qualities.

Yet another one is:
- what nice thing can't we do with H what we can with R, (or less absolute: what is more difficult), that is: what do we lose? - what we can we still do <duck> what nice properties does this construct inherit from relation </duck>
- what nice thing can we do with H what we can't do with R? (or less absolute: what is easier), that is: what do we win? Received on Sat May 08 2004 - 15:09:13 CDT