Re: Data Display & Modeling

"mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message news: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.

No, the wink was just 'cause I was referring to our existing glossary. Yes, I DO CALL THEM FUNCTIONS! I refer to databases based on this (admittedly ill-defined, but in use none-the-less) model as "Functional Databases"

> 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

I thought that now relations were permitted to have relation-valued attributes. I'm sure some think they can and some think they can't.

> - model H allows relations as well as chunks (this is the only
> difference between H and R).

The allowable operators, in particular permitting operations on "rows" would be another, right?

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

Because I am working with actual products and abstracting a model from that, and because I'm not sure why the products I'm addressing have historically provided a better bang for the buck for their companies, I'm looking at all angles. Decoupling persistence services and database constraint handling is one aspect of the whole. Nothing relevant to databases is "orthogonal" to the discussion as it is the entirety of the database approach that makes for happy users, happy owners, etc.

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

Relational theory has some "rules of the game" (which is often an advantage) and they such things as only permitting set operations (as well as value operations for each type). If I understand correctly, such row functions as iterators or hypertext-like links from an entire row would be out of scope of relational theory and not permitted, right?

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

And that is the same as scalars and non-scalars, right? The difference is that compounds come with functions that operate on the variables or values of that type to yield its parts where scalars have no such database-defined functions available, right?

I pretty much work with the scalar type "string" and everything else (typing, for example) has to do with how to view/use (whatever possible representation is needed) the string. But that's another story for another day. Cheers! --dawn Received on Sun May 09 2004 - 00:54:38 CEST