Re: Mazes, trees, and forests

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.

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?

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?

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.

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 Tue Apr 27 2004 - 00:09:14 CEST