Re: Relational query with path expressions
Date: Tue, 7 Apr 2009 19:40:53 +0000 (UTC)
Message-ID: <grga85$2fo5$1_at_mud.stack.nl>
David BL wrote:
>I get the impression that a lot of the time, a query (or a large
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
[...]
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
>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.
>useful paths.
PERSON(P#, NAME, DAYOFBIRTH, FATHER#, MOTHER#)
FATHER(FATHER#)
MOTHER(MOTHER#)
>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).
[...]
>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
>--------
>
>Renaming of attributes is supported. For example
>
> S.(CITY as SCITY, SP.P.CITY as PCITY)
>
>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.
-- ReinierReceived on Tue Apr 07 2009 - 21:40:53 CEST