Re: Relational query with path expressions

From: rpost <>
Date: Tue, 7 Apr 2009 19:40:53 +0000 (UTC)
Message-ID: <grga85$2fo5$>

David BL wrote:

>I get the impression that a lot of the time, a query (or a large
>portion of a query) can be thought of as a navigation from attribute
>to attribute using a sequence of joins. This made me think there may
>be some merit in thinking of attribute names as global in nature and
>the user only has to specify the start and end attributes and the DBMS
>is able to deduce the joins that are required.

I like this idea, but it doesn't generalize to joins in general.

>I think the biggest problem is that quite often there are multiple
>useful paths.


Yes, and global renaming isn't always possible:

  PERSON(P#, NAME, DAYOFBIRTH, FATHER#, MOTHER#) Here, every FATHER# and every MOTHER# is also a P#. Pretty much all of our queries involving FATHER# and MOTHER# are going to join them with P#. We can't rename to express those joins.

Splitting it out doesn't help:


We can name FATHER's attribute FATHER# or P#, but not both.

(BTW replacing the # attributes with natural keys doesn't help either.)

>After thinking about that problem for a while, it occurred to me that
>access paths should emphasise navigation from relation to relation,
>rather than from attribute to attribute (as suggested by the hyper-
>graphs in the literature on the Universal Relation).

Yes, but sometimes you're going to have to specify which attributes to join on.


>The idea that R1.R2 can drop attributes from R1 may seem strange. A
>benefit arises for example in path expressions like R1.R2.R3 because
>it can avoid joining on attributes which happen to have the same name
>in R1 and R3. This can help to control the joins along a path.

Nice idea, but not completely general:
it cannot express joins on FATHER#/MOTHER# above.


>Renaming of attributes is supported. For example
>retrieves all pairs of city names (SCITY, PCITY) such that a supplier
>in city SCITY supplies a part to city PCITY

Now I'm happy :-)

I initially assumed that SQL worked like this and was startled to discover that it doesn't.

Received on Tue Apr 07 2009 - 21:40:53 CEST

Original text of this message