Re: Data Display & Modeling
Date: Sun, 09 May 2004 02:16:51 +0200
Message-ID: <409d7876$0$567$e4fe514c_at_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_at_mac.com
Received on Sun May 09 2004 - 02:16:51 CEST