Re: Mazes, trees, and forests

From: mAsterdam <mAsterdam_at_vrijdag.org>
Date: Tue, 27 Apr 2004 00:09:14 +0200
Message-ID: <408d8892$0$566$e4fe514c@news.xs4all.nl>

x wrote:

> ... Why only the FOREIGN-KEYS and not ANY subset of attributes ?

>>>A user can connect any two relations on any two attributes of compatible
>>>types.
>>
>>Sure, and by expanding along those lines every user can
>>build his own forest.

>
> So there would be a forest for every user ?

The users query-history would have some relevance (but would include tries which turned out as uniteresting), and the space defined by all possible queries (which would be the same for all users sharing the same external model - if you care to make that distinction). Both, IMHO forestifiable. (the stated algorithm is very rude and incorrect, but it seems you did get the idea and don't really mind the that).

>>>Do you consider only the base relations or any relation  ?  ;-)
>>
>>Well, I did. With 'any relation': you mean every conceivable relation
>>on a base?

>
> "any relation" = base or derived relation

Now I should apologise: At first I considered only the base relations, because I assumed the rest would only generically relevant (the generic loss being freedom to define all kinds of relations) - while I was looking for the loss in *actual* databases. But, indeed, for an actual database the space of all possible derived relations *is* case-specific and relevant for determining the loss. My bad.

>>>How can someone (other than the user) predict for what pairs of
>>>attributes the join of two relations make sense ?
>>
>>Why would anyone *want* to predict that? Sensible types help, but beyond
>>that ... could you clarify how this impacts the suspicions I mentioned
>>in the first posts?

>
>
> Well, you said:
> "This TELLS us something about wether and how much
> of the data in the database can be expressed as
> trees and THE LOSS we incur by doing so."

Yes. As above, I see you are right, this is relevant - and more complicated than I thought.

> What do you mean by the "data expressed as trees" ?
> Why there would be any loss in the "data expressed as trees" ?
> Do you consider "the data in the database" is "the stored data" ?
> I'm also considering that some "derived data" may be lost.
> In my opinion, in a RDBMS the data is in the:
> - names of the named relations
> - names of the attributes
> - values of the attributes of any relation (base or derived)
> - integrity constraints
> - formula that define a derived relation
> - associations of the above

Nice. Aside: I wonder what such a list would look like for MV.

>>>This is why a relational DBMS is different from other types of DBMSs.
>>
>>Do you mean to imply that with 'other types of DBMS' (historic I assume)
>>can't connect as they please? I must be misreading you.

>
> By "other type of DBMSs" I'm referring to "hierarchical" or "network"
> DBMSs.
> Maybe they can connect as they please. But with what cost ?
> I was taught that one need to write long routines to achieve some
> "connections".

True. Some more costly than others.

> Restricting the connections only to (PK,FK) keys of base relations
> sound like restricting the connections only to the existing physical access
> paths.

Physical? Now you lose me again. You just had me convinced :-) Predefined (from a user perspective), I'ld suggest. Received on Mon Apr 26 2004 - 17:09:14 CDT