Envoyé par
pacmann
Je ressens la clause SELECT comme un opérateur très fonctionnel (par opposition à la relation simple : elle effectue un lien n..1 entre deux ensembles), qui s'applique sur le sous-ensemble du produit cartésien.
SELECT joue un rôle analogue à celui de PROJECT, l’opérateur relationnel utilisé pour effectuer une projection, mais il ne peut être confondu avec lui. Pour mieux percevoir l’analogie, au lieu d’écrire :
SELECT colx, coly, ...
FROM ...
WHERE ...
il suffit de présenter ainsi les choses, c'est-à-dire dans l’ordre selon lequel les choses se passent (au moins conceptuellement) :
FROM ...
WHERE ...
SELECT colx, coly, ...
SELECT est l’opérateur qui permet de présenter le résultat final, par projection sur colx, coly, ....
Dans le contexte de la tambouille SQL, ce résultat n’est pas forcément une relation car les doublons y sont autorisés : si l’on a le moindre doute, il est prudent d’utiliser la clause DISTINCT. Malgré cela, le résultat peut encore ne pas être une relation : les colonnes ne sont pas nécessairement nommées et l’on peut avoir des doutes quant à leur domaine de référence. Il est possible aussi de faire figurer plusieurs fois la même colonne... Par ailleurs, ce résultat peut comporter des valeurs nulles, auquel cas il peut s’avérer impossible de respecter l’intégrité d’entité (toute relation doit être munie d’une clé et celle-ci ne peut pas comporter d’attribut pouvant être marqué null).
Je ne dirais pas que l'opération est commutative :
SELECT *
FROM A, B
ne donne pas la même chose que
SELECT *
FROM B, A
Dans le cadre du Modèle relationnel, le produit cartésien étendu est bien commutatif. Il faut le dissocier de SELECT, qui comme on vient de le voir ressemble vaguement à PROJECT. En fait, vos requêtes sont équivalentes à celles-ci :
SELECT A.*, B.*
FROM A, B
et
SELECT B.*, A.*
FROM B, A
Les produits A TIMES B et B TIMES A donnent lieu au même résultat, en revanche, dans un 2e temps, c’est bien le simulacre de projection qui produit des résultats différents.
Quant à l'associativité, elle découle naturellement de "l'abus de langage" (ou simplification de notation) de CODD.
Codd utilise l’expression : "expanded cartesian product" (Cf. Relational completeness of data base sublanguages, page 5).
Le but de ces remarques, c'est juste de dire que je ne trouve pas qu'on s'éloigne de la théorie mathématique, mais plutôt qu'on "l'approfondit", qu'on la spécialise dans une direction
I agree with you Tovaritch ! Le but de Codd fut bien de construire sur des bases simples mais solides, un modèle théorique pour les bases de données, qui reste accessible à tous, à une époque où l’on ne traitait ces bases de données qu’au niveau élémentaire et non pas ensembliste, de manière plutôt fruste, strictement procédurale, navigationnelle, séquentielle, enregistrement par enregistrement, en suivant les pointeurs. Codd a créé un pays qui s’appelle le Relationland, lequel est hélas ! encerclé par le Askew wall (prononcer SQL), sorte de construction bancale, non orthogonale et dans laquelle tout le monde se vautre, croyant avoir atteint le pays des relations. Je relis de temps en temps ce qu’a écrit Codd il y a bientôt 40 ans et je reste impressionné. De temps en temps, un peu comme en relisant les aventures d’Astérix le Gaulois, je découvre des choses qui m’avaient échappé ou encore je me rends compte que j’avais mal capté certains points (et il y a surement bien des choses qui m’échappent encore). En revanche, quand je feuillette les documentations jaunies traitant des bases de données pré-relationnelles (qui m'ont quand même fait vivre du temps où Codd posait ses fondations), j’ai l’impression de revenir à une époque extrêmement lointaine, plus qu'antédiluvienne...
Si le résultat est le même après passage de l'optimisateur, d'un point de vue conceptuel, ça peut s'interpréter différemment : p est soit un lien logique entre deux ensembles, ou p est simplement la caractérisation d'un sous ensemble...
Certes, mais comme dirait Chevallier à Laspalès, c’est vous qui voyez...
Partager