Re: Data Display & Modeling
Date: Sat, 08 May 2004 22:09:13 +0200
Message-ID: <409d3e6c$0$65124$e4fe514c_at_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.
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 - 22:09:13 CEST