Re: Data Display & Modeling

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.

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.

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

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?

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 - 22:54:48 CEST