Bonsoir,
Je ne saisis pas tout à fait le sens de votre remarque, mais j'ai l'impression que vous reprochez quelque chose à Ted Codd (qui, ne l'oublions pas, avait à convaincre des informaticiens et les comptables d’IBM plutôt que des mathématiciens). Peu importe. La notion intuitive de lien c’est bien, mais encore faut-il avoir les moyens d’identifier les « bons » liens. Par exemple, je vous propose l’image suivante, extraite de l’article de Date, An analysis of Codd's contribution to the Great Debate, illustrant deux types de liens entre tables :Envoyé par pacmann
A gauche, dans le style coddien, le lien entre les tables DEPT et EMP n’est pas matérialisé (la jointure naturelle DEPT JOIN EMP fait office), alors qu’à droite, le lien matérialisé DEPTEMP cache en fait un jeu de pointeurs, permettant de naviguer de DEPT vers EMP et inversement. Sur la base de la définition rigoureuse du Modèle Relationnel de Données, (y-compris des opérateurs que nous avons évoqués), il a quand même fallu un bon moment pour que les partisans de la solution de droite avouent reconnaître la supériorité incontestable et écrasante de l’autre, dont la force tient pour beaucoup à sa simplicité. Ted Codd avait fait preuve de beaucoup de discernement, en réalité de génie, pour se contenter de l’image de gauche, qui traduit la définition de son principe de l’information (Information Principle) :
« All information in the database must be cast explicitly in terms of values in relations and no other way. »En cela, on peut reconnaître que le concept créé a plus d’importance que la définition elle-même, mais, comme vous le faites observer en citant les Principia, faire abstraction de celle-ci est pénalisant.
A ce sujet, permettez-moi une incidente (j'aime bien les incidentes). Comme je le raconte parfois ici, un « Grand débat » a eu lieu à Ann Arbor, en 1974, en réalité une joute décisive qui opposa Ted Codd à Charles Bachman (je n’ai pas dit Pachman...), champion des bases de données dites réseau (ou CODASYL). A l’occasion de son entraînement de préparation, Codd prit le soin, a posteriori, de fournir une définition pour le modèle réseau, chose qui paradoxalement n’avait jamais été faite ! bien que les bases de données y adhérant fussent très en vogue. Codd put ainsi mettre au jour les faiblesses de ce modèle. La tactique fut payante et dès le 1er round il envoya son rival mordre la poussière. Bachman n’était pourtant pas le premier venu, et avait même obtenu la Turing Award l’année précédente. Dix ans plus tard, arriva DB2, le premier SGBD relationnel capable non seulement de rivaliser, mais de littéralement surclasser (sur tous les plans) les SGBD réseau, et en très peu d’années ceux-ci furent balayés, au point que Bachman dut se résoudre à concevoir puis vendre (la feau des pesses) un outil permettant de migrer vers le relationnel. De la même façon, les promoteurs de Merise se mirent à décrire la production d’un modèle logique non plus basé exclusivement sur l’approche réseau, mais sur le Modèle Relationnel de Données (auquel ils n’ont du reste pas compris grand chose...) Ensuite, à grands renforts de trompettes, on nous annonça que les SGBD OO allaient supplanter les SGBD R. Certes, l’approche OO a beaucoup apporté avec le typage fort des données et l’héritage, mais elle a aussi pris un risque en se dispensant du principe de l'information énoncé plus haut, et en utilisant le mécanisme des pointeurs, habillés en identificateurs d’objets. Anyway, je ne sache pas que les SGBD R aient connu le sort qui leur était promis, celui des SGBD de type réseau (que nous sommes peu nombreux à savoir encore programmer, soit-dit en passant).
Il es vrai que le terme est ambigu. Par exemple, pour les théoriciens de Merise, une primitive est une action élémentaire :
Accès à une ligne d’une table par sa clé. Ajout d’une ligne, etc. Le but de la manœuvre est de calculer le coût des accès, disons en nombre d’entrées/sorties pour faire court. Cela avait un sens avec un SGBD réseau, mais ne signifie plus rien avec un SGBD R, car l’optimiseur a ses algorithmes et heuristiques qui invalident la plupart de ces calculs laborieux : en tant que vieux routier de l’administration des bases de données, je sais de quoi je parle.
Dans le contexte du Modèle relationnel, primitive est un raccourci pour opération primitive, c'est-à-dire une opération qu'on ne définit pas au moyen d'autres opérations. Inversement, certaines opérations ne sont pas primitives parce qu’elles peuvent être définies à partir d’autres opérations. Ainsi, l'intersection est à considérer comme une opération qui n'est pas primitive, car a INTERSECT b revient à a MINUS (a MINUS b), ou b MINUS (b MINUS a).
Je rappelle au passage quelques définitions telles qu’on les trouve chez Date (An Introduction to Database Systems, 8th edition).
Produit cartésien (relationnel) :
a TIMES bLe produit cartésien relationnel de deux relations a et b, a TIMES b, où a et b n’ont aucun attribut en commun, est une relation dont l’en-tête est l’union (au sens ensembliste) des en-têtes de a et de b, et dont le corps est constitué de l’ensemble des tuples t tel que t est l’union (au sens ensembliste) d’un tuple appartenant à a et d’un tuple appartenant à b. Clairement, le produit cartésien relationnel est une extension du produit cartésien de la théorie des ensembles (notamment, TIMES est commutatif et associatif).
L’opérateur TIMES peut être considéré ici comme primitif.
Restriction :
a WHERE X θ YLa θ-restriction (restriction pour abréger) d’une relation a sur les attributs X et Y, a WHERE X θ Y est une relation ayant le même en-tête que la relation a et dont le corps est constitué de tous les tuples de a pour lesquels a WHERE X θ Y prend la valeur VRAI. L’opérateur WHERE peut être considéré ici comme primitif.
L’opération de θ-jointure revient conceptuellement à un produit cartésien (relationnel) de deux relations, suivi d’une θ-restriction :
(a TIMES b) WHERE X θ YDans ces conditions, l’opération de θ-jointure n’est donc pas ici une opération primitive. Par voie de conséquence, il en va de même pour l’opération de jointure naturelle.
Maintenant, on peut adopter une attitude différente et considérer la jointure naturelle comme une opération primitive, ce que fait Chris Date, qui la note ainsi :
a JOIN bVous observerez qu'on ne précise pas quels attributs participent à l’opération : ce sont ceux qui, dans les relations a et b ont même nom (et sont évidemment du même type).
Si les deux relations n’ont aucun attribut en commun, alors cette opération revient à un produit cartésien (on peut donc se passer de l’opérateur TIMES).
De même, si les deux relations sont du même type, c'est-à-dire si tous leurs attributs participent à l’opération, alors cette opération revient à une intersection (on peut donc se passer de l'opérateur INTERSECT, mais pour le confort de l'utilisateur, il est préférable de n'en rien faire...)
Etc.
Répondre avec citation
) ?
Partager