Re: Data Display & Modeling

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Sun, 09 May 2004 02:16:51 +0200
Message-ID: <409d7876$0$567$e4fe514c@news.xs4all.nl>

Dawn M. Wolthuis wrote:

> mAsterdam wrote:

>>Dawn M. Wolthuis wrote:
>>>mAsterdam 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"

That is what I feared :-/

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

I heard that, to. I still have to read and think about that. The important thing here is: would that be enough to satisfy the (or your) need for compound attributes or are there desirable compound attributetypes *not* covered by relation valued attributes?

>>- 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 way to designate

- attributes (because they may be compound)
- atoms within a compound
- their value

would be more complicated in H.
A good typesystem would help.
Anything else?

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

Just dump/serialize and restore/deserialize the state of the whole system for the ultimate, perfect, it-can't-get-any-better-than-that persistence service. It's not what you are looking for, IMHO.

orthogonal=irrelevant?

While the handling of constraints definitely is generally relevant, to the model the constraint *definition* is all we need to talk about, again IMHO.

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

I don't know what you mean by hypertext-like links from an entire row.

Iterators: Who needs iterators when you can define a set and operate on it? If you insist this can be rephrased as iterators. Not permitted is here like saying you are not permitted to walk in a train. Sure you can, but it won't help you arrive any sooner.

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

I think so.
Scalar is fine by me. I don't like non-scalar. What's wrong with compound besides not being used by Date c.s.?

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

Why would scalar types not have associated functions/operators/methods?

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

A nice read for when you want to go into that: The string manifesto:
http://groups.google.com/groups?selm=488F0B8B-9906-11D8-88D8-000393A6B9DA@mac.com Received on Sat May 08 2004 - 19:16:51 CDT