Re: Data Display & Modeling

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sat, 08 May 2004 22:54:48 +0200
Message-ID: <409d491b$0$567$e4fe514c@news.xs4all.nl>

Dawn M. Wolthuis wrote:

> mAsterdam wrote:

>>Dawn M. Wolthuis wrote:
[snip]
>>>> a. no duplicates
[snip]

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

>
>
> Yes, it is a relation and, in particular, a function.

Please don't.

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.

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

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

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

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

>
> Here is one nice thing that can be done with H -- a link could be defined
> without requiring a constraint.

You don't need H for that. R will do. Just have a list of attributes of R2 (linker) be of the same type as the key of R1 (linked). Do not define a foreign key.

> So, you can link to things outside of a
> centrally managed data source and if you navigate to the link and it is not
> there (because you can't control it), then you can simply let the user know
> that it is not there.

Same here, you don't need H. R will do. Received on Sat May 08 2004 - 15:54:48 CDT