Re: Data Display & Modeling

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 08 May 2004 23:58:50 +0200
Message-ID: <409d581d$0$559$e4fe514c_at_news.xs4all.nl>


Dawn M. Wolthuis wrote:

> mAsterdam wrote:

>>Dawn M. Wolthuis wrote:
>>>mAsterdam wrote:
>>>>Dawn M. Wolthuis wrote:

[snip]
>>I couln't care less wether relation is a mathematically
>>correct name for the construct. It is not what people
>>expect when they see the word relation in database context.
>>Any attempt to dicuss this would dry up in endless
>>hairsplitting. At least temporarily another name is
>>crucial.
> 
> That's fine -- it is a FUNCTION, ok?  And we have 
> a definition of that in our glossary ;-)

Suggesting *that* would do the trick of setting a good stage, you must be kidding - aaah the blinker, you *are* kidding - sigh.

Hm. How about this: 'atom' for the the atomic attributes (hesitation: possible prolog clash), 'compound' for the structered attributes (maybe just 'list' for list), and 'chunk' for the construct which *only* differs from a RM.relation in that it's attributes maybe compound.

Reiterating:

- relations have atoms only as attributes
- chunks have compounds as well as atoms as attributes
- a list is a special kind of compound
- model R only allows relations
- model H allows relations as well as chunks (this is the only 
difference between H and R).

>>>The model I'm working
>>>with has names as "descriptive" (and therefore synonyms are prevelent),
>>>allowing the ordering of the tuple to be what is fixed (and that fits
>>>with the def of a relation).
>>>Typing is also descriptive rather than the database
>>>employing types (even sizes) as constraints.
>>>This gives the builder enough
>>>rope to hang themselves, but also provides some freedom not available to
>>>developers in SQL-DBMS's.

Is it necessary to mix this in as well?
It seriously blurs the issue I thought I understood.

>>>>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.
>>>
>>>Yes, internal structure and also functions can be defined
>>>at any level and need not be only set-functions
>>>(or type functions). For example, you can
>>>have navigation functions and record (row-ish) functions.

What do you mean by this?
(Or did I get it in my previous post?)

>>>>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.
>>>
>>>We really only need to know what functions
>>>can be used on what, right?
>>
>>Are you sure?
> of almost nothing, so no ;-)

Then, to prevent nasty gotchas:
Let's keep the distinction clear.
Atoms and compounds.

>>>>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?
[snip] Received on Sat May 08 2004 - 23:58:50 CEST

Original text of this message