# Re: What to call this operator?

From: Jon Heggland <heggland_at_idi.ntnu.no>
Date: Mon, 4 Jul 2005 08:03:27 +0200
Message-ID: <MPG.1d32ef8a9e90d0d39896d5_at_news.ntnu.no>

> > I'm not sure I understand you. Surely the keys of a join result are
> > determined by logic, not by rules one might propose?
>
> You're quibbling over terminology.

Sorry, but I think it is important to distinguish between *discovering* and *proposing* a rule. Especially if you take the stance that the rule then determines what joins are "allowed".

> What rule, derived via
> logic, would you propose? What's the right answer? Phrase
> it any way you like; I just want to know what the correct

I can't find the article or passage I was thinking about, but I believe this is correct; it is based on "Updating Joins and Other Views" by Date and McGoveran (1993):

Given two relations A and B. Let the columns of a be partitioned into two disjoint groups X and Y, and the columns of B similarly into Y and Z, so that the set of columns Y is "common" to the two relations, i.e. the join attributes.

If Y includes (is a superset of) a key of both A and B, the join is "one-to-one", and every key of both A and B is a key for the result.

If Y includes a key of A, but not of B, the join is "one-to-many", and every key of B is a key for the result. This is of course symmetrical.

If Y does not include any key for neither A nor B, the join is "many-to- many", and each union of any key of A and any key of B is a key of the result.

Deriving functional dependencies is not much harder, I think. If A and B are properly normalised, all their functional dependencies are implied by their keys. If the join is one-to-one, this is the case for the result as well. If it is a "many" join, there might be FDs in the result that are not implied by keys, but they are the same as those in A or B.

```--
Jon
```
Received on Mon Jul 04 2005 - 08:03:27 CEST

Original text of this message