Re: Data Display & Modeling

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news:409d491b$0$567$e4fe514c_at_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.

That's fine -- it is a FUNCTION, ok? And we have a definition of that in our glossary ;-)

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

of almost nothing, so no ;-)

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

Or, you don't need R, H will do. --dawn Received on Sat May 08 2004 - 23:08:14 CEST