Envoyé par
SQLpro
Vous partez d'un postulat faux au départ qui est qu'une table est une relation. Ceci est faux....
Jamais je ne "postulerai" une chose pareille ! Qu’une table soit une relation est évidemment faux, il n’y a pas d’équivalence à établir entre ces deux concepts, bien au contraire, ne serait-ce que, parce que contrairement à une relation, une table n’a pas nécessairement de clé (primaire au sens SQL), parce qu’elle peut comporter des doublons, parce que le résultat d’un SELECT peut avoir des colonnes non nommées ou ayant des noms en double, etc. Je dis simplement que le pendant d’une table au sens SQL, peut être soit une relvar (variable relationnelle) soit une relation (valeur) au sens du Modèle Relationnel de Données, mais ça n’est pas pour autant qu’une table serait une relvar ou une relation.
Tout au plus, une table peut-elle être perçue comme l’avatar d’une relation (ou d’une relvar), elle en est une image, elle en a le goût mais ça n’en est pas, etc. Évitons soigneusement tout amalgame.
Envoyé par
SQLpro
une table n'a rien à voir avec une relation (au sens algébrique du terme)
Comme on vient de le voir, une table ressemble tout au plus à une relation. Quant à l’algèbre relationnelle, elle utilise les opérateurs RESTRICT, PROJECT, JOIN, RENAME, EXTEND, etc., dont les opérandes sont exclusivement des relvars (de base ou dérivées) : en vertu de la propriété de fermeture, les opérations relationnelles produisent de nouvelles relvars dont les valeurs (relations) peuvent à leur tour être utilisées à volonté pour de nouvelles opérations. Pour sa part, SQL permet d’utiliser plus ou moins nommément et laborieusement ces opérateurs appliqués cette fois-ci à des tables, mais sans garantie que les résultats soient eux-mêmes des tables : ça peut être des sacs, ou encore des choses qui ne peuvent pas être dotées de clés primaires à cause du bonhomme NULL, etc., cf. le paragraphe précédent) et le principe de fermeture peut être facilement mis en échec. Comme vous dites, au sens algébrique, une relation et une table ne sont pas comparables, ne serait-ce qu’en raison des faiblesses inhérentes à cette dernière (Mais nom d’une pipe, pourquoi IBM n’a-t-elle pas confié la direction du projet SEQUEL à Codd ?)
Envoyé par
SQLpro
s'accrocher à tout prix à la notion de relation n'a pas de sens
Plaît-il ? Quand on veut travailler le sujet des bases de données relationnelles avec une grande rigueur, on ne peut que faire référence au Modèle Relationnel de Données, comme l’ont fait Codd, Date, Darwen et McGoveran, Fagin, Rissanen, Maier, Delobel et Adiba, Ullman, Valduriez et compagnie. Je suis navré, mais la relation est au coeur de ce modèle. Ni vous ni moi n’y pouvons rien, il en est ainsi depuis 1969 et les gens que j’ai cités sont des êtres sensés. Bien sûr, le Modèle relationnel a régulièrement évolué et continuera à le faire (heureusement, il n’est pas figé), mais en raison de ce qui différencie une relation d’une table, c’est "s’accrocher" à tout prix à l’avatar de la relation qui serait dénué de sens. Au fait, quel est l’objet de votre remarque ? Que reprochez-vous aux relations, c'est-à-dire au Modèle Relationnel de Données ? Qu’elles soient fidèles au principe de fermeture ? Qu’elles soient toujours identifiées ? Qu’elles ne puissent pas donner lieu à des sacs ? Que leur en-tête soit systématiquement un ensemble d’attributs et toujours formé de façon régulière ? Que le Modèle relationnel ne soit pas laxiste ? Que seul le Sorry Query Language et ses tables seraient sensés et dignes d’intérêt ? Quelque chose m’échappe. J’ai l’impression d’assister à une inversion des valeurs.
Envoyé par
SQL pro
Le fait que Codd admet le NULL pour les tables et l'interdit dans l'algèbre relationnel nous montre que la différence est en fait très importante
Tout ceci est nul (sic) et non avenu. En effet, Codd n’a absolument rien interdit de tel ! Je vous renvoie au paragraphe 2.3 de son article de 1979 :
Extending the Database Relational Model to Capture More Meaning, dans lequel il étend en réalité l’algèbre relationnelle pour prendre en compte NULL (à noter que dans son ouvrage de
1990 il abandonne NULL au bénéfice des marques A-mark et I-mark). Maintenant, chacun peut avoir ses raisons d’être d’accord ou non avec Codd quant à la façon de traiter l’information absente, mais c’est un autre débat.
Envoyé par
SQLpro
Or dans vos débats vous tentez d'imposer une vision trop proche de l'algèbre relationnel, qui n'est en fait qu'un support (et non la vérité) des tables d'un SGBDR.
Vous semblez avoir une bien piètre opinion de l’algèbre relationnelle, sans laquelle SQL ne serait pourtant qu’un sac vide. Qui plus est, ne limitons pas notre vision à l’algèbre relationnelle, il faut considérer le Modèle Relationnel de Données dans sa totalité, c'est-à-dire prendre aussi en compte ses aspects qui touchent à la structure des données et à leur intégrité ; tout cela se tient et se complète. A défaut, nous ne ferions que dans le bricolage et la recette de cuisine, mais là je dis : stop !
Je ne veux pas non plus mélanger modèle (c'est-à-dire le Modèle Relationnel de Données) et implémentation (c'est-à-dire les SGBD dits relationnels). Et puis, si je ne faisais pas référence ici à la matrice relationnelle, qui donc le ferait ? Je ne cherche pas à imposer quoi que ce soit, mais à montrer aux plus jeunes l'intérêt, la nécessité qu'il y a à connaître un minimum de théorie autrement que d’un point de vue strictement scolaire et sec. Libre à eux ensuite de se désintéresser des aspects théoriques.
Quant à prétendre que l’algèbre relationnelle n’est qu’un support, voulez-vous dire qu'elle ne serait qu'un faire-valoir, un impedimentum qu'il faudrait supporter bon gré mal gré ? Qu’elle peut être remplacée par autre chose ? Mais dans ce cas, il faudra supprimer la lettre R du terme SGBDR. Quant à votre énoncé "l’algèbre relationnelle n’est pas la vérité des tables", qu’entendez-vous par là ? L’algèbre relationnelle serait-elle coupable de faire mentir les tables ? J’avoue rester perplexe face à cette affirmation pour le moins bizarre.
Envoyé par
SQLpro
En fait, c'est toute la différence entre la théorie et la pratique, et c'est un vieux débat, initié par Codd lui même (exemple la 6e forme normal : toute table se représente par un ensemble de colonne formant la clef assortie d'au plus une unique colonne non clef), puis repris par Chris Date, Pascal Fabian, Hugh Darwen (pour le côté pro relationnel) ou Joe Celko, Peter Chen et bien d'autres (pour le côté SQL / SGBDR)
Décidemment, il est bien difficile de suivre votre discours. Codd a initié (entre autres) Date et Boyce au Modèle Relationnel de Données, et qu’il ait entamé un "vieux débat", c’est possible, mais alors merci d’en fournir la référence, que l’on puisse savoir de quoi vous voulez parler. S’il s’agit du fameux débat de mai 1974 à Ann Arbor "
Interactive support for non-programmers: The relational and network approaches", celui-ci illustre magistralement le fait que l’absence de la théorie est particulièrement préjudiciable à l’art de traiter les données. A cette occasion, face à Codd, Bachman (récipiendaire de la Turing Award l’année précédente) a fini K.O. debout, au 1er round.
Et voilà que maintenant vous attribuez à Codd une 6e forme normale. Décidemment... Quoi qu’il en soit, quelque chose ne va pas dans la définition que vous donnez. Je la reproduis donc (tout en conservant le terme "table", ça n’est pas un problème) :
Toute table se représente par un ensemble de colonne formant la clef assortie d'au plus une unique colonne non clef
1) Considérons en ce sens une table T1 dont l’en-tête est composé de trois attributs A, B et C et dont la clé est composée du couple {A, B} :
T1 {A, B, C}
Supposons que la couverture minimale des dépendances fonctionnelles de T1 soit représentée par l’ensemble de dépendances fonctionnelles suivant :
DF1 : {A, B} → {C}
DF2 : {C} → {B}
Du fait de DF2, T1 viole la BCNF, donc la 6NF, ce qui invalide votre définition.
2) Considérons le cas d’une table T2 dont tous les attributs font partie de la clé :
T2 {A, B, C}
Cette fois-ci, toutes les dépendances fonctionnelles sont triviales, en vertu de quoi T2 respecte la BCNF. Supposons maintenant qu’il existe la dépendance multivaluée :
DM1 : {A} →→ {B} | {C}
Alors T2 viole la 4NF, ce qui invalide à nouveau votre définition.
3) Et si l’on suppose que DM1 n’existe pas et que T2 respecte la 4NF, mais qu’en revanche il existe la dépendance de jointure :
DJ1 : * {{A, B}, {B, C}, {C, A}}
Alors cette dépendance de jointure n’est pas triviale et T2 viole la 5NF.
Ainsi, on voit bien qu'on ne peut pas faire l'économie de la théorie qui, en plus de permettre de faire avancer les choses, sert aussi de garde-fou. Faire du trapèze volant c'est chouette, mais sans filet ça craint.
Bien qu’elle ne soit pas valide, votre définition est toutefois intéressante dans la mesure où elle est facile à comprendre, donc à retenir, tout comme l’énoncé proposé par
Kent, synthétisant fort élégamment la 2NF et 3NF (pour une table respectant bien entendu la 1NF) :
Un attribut non clé doit représenter un fait concernant la clé, toute la clé et rien que la clé.
Mais il est évident que, si cette définition vaut elle aussi par son côté didactique, elle n’en demeure pas moins incomplète et il est facile à son tour de l’invalider.
Pour faire fonctionner correctement votre définition, il faudrait donc préciser que la table respecte d’abord la 5NF.
A l'instar de Date, vous pourriez aussi la reformuler ainsi, à la façon de la 5NF :
Une table est en 6NF si et seulement si elle ne satisfait à aucune dépendance de jointure non triviale.
Et pour ne pas effrayer les gens avec des gros mots du genre "5NF", "dépendance de jointure", vous pourriez écrire par exemple :
Si une table comporte une clé simple et au plus un attribut non clé, alors cette table est en 6NF (par clé simple, j’entends clé mono-attribut).
Ça n’est jamais qu’un prolongement d’une des définitions de la 5NF, fournie par Fagin et Date pour un cas particulier :
Si une table est en 3NF et si chacune de ses clés candidates est simple, alors cette table est en 5NF.
Évidemment, ces définitions sont très spécifiques car elles ne prennent pas en compte les tables dont une clé est composée de plus d'un attribut, mais c’est toujours ça de pris comme disait ma grand-mère.
Puisque vous parlez de la 6NF et pour essayer d'en terminer, commentons la définition qu’en donne Chris Date dans son ouvrage "An Introduction to Database Systems" (et déjà proposée ci-dessus) :
Une relvar est en 6e forme normale (6NF) si et seulement si elle ne satisfait à aucune dépendance de jointure non triviale — sachant qu’une dépendance de jointure est triviale si et seulement si au moins une de ses projections (éventuellement U_projections) met en jeu l’ensemble des attributs de la relvar.
Pour être un peu plus précis, les dépendances de jointure dont il est question sont en fait des dépendances de jointure généralisées et ainsi définies :
Soit R une relvar, soit A, B, ..., Z des sous-ensembles d’attributs de R, et ACL une liste d’attributs de R, dont les valeurs sont des intervalles. On dit alors que R satisfait la dépendance de jointure généralisée (JD) :
USING (ACL) * {A, B, ..., Z}
si et seulement si l’expression
USING (ACL) ◀ R = R’ ▶
est vraie pour toute valeur de R. (R’ est la U_jointure des U_projections de R sur A, B, ..., Z, et cette U_jointure et les U_projections en question mettent en jeu une spécification USING de la forme USING (ACL)).
Etc. Évidemment, ça devient un peu difficile, mais tant qu’à traiter de la 6NF, autant le faire avec rigueur. Je ne chercherai pas à commenter outre mesure, car il faudrait d'abord expliquer à ceux qui ne la maîtrisent pas ce qu’est la 5NF, puis reproduire le chapitre 23 de l’ouvrage susmentionné, et cela représente indéniablement trop de conditions préalables pour aller plus avant.
Je rappellerai quand même que l’expression
USING (ACL) ◀ R = R’ ▶
est un raccourci pour
(UNPACK r1 ON (ACL)) = UNPACK r2 ON (ACL))
Sachant que chaque attribut figurant dans ACL doit être un attribut de type intervalle.
Dans tout cela, le but de la manœuvre n’est pas de produire systématiquement des tables ayant au plus un attribut non clé, ça serait particulièrement inefficace et coûteux, voire dangereux (comme dans le cas des bases de données dans lesquelles les relations ne seraient que binaires, voir à ce sujet le
paragraphe 30.3 de l’ouvrage de 1990 de Codd). Pour passer au plan pratique, le but visé avec la 6NF est clairement la simplification des tables dans lesquelles, pour faire (très !) court, on a essentiellement des dates de début
et de fin (en théorie représentées sous forme intervallaire). Autrement dit, il s’agit de simplifier la programmation de la gestion des historiques et apparentés, en isolant dans des tables normalisées en 6NF les données évoluant dans le temps, à leur rythme propre. Ceux qui conçoivent les MCD et les MLD dans les établissements financiers, dans la distribution, etc., diront que, comme pratiquement chaque donnée est datée, cela aurait pour effet de multiplier le nombre de tables, mais après mûre réflexion de leur part, ils y regarderont peut-être à deux fois. Mais il s’agit encore là d’un autre débat, chaque chose en son temps.
C’est tout pour cette fois-ci...
2 |
0 |
respecte la 1NF fausse et absconse, elle peut indûment et en toute impunité subir allègrement l’épreuve de la 2NF et suivantes : "Une table est en 2NF si elle est en 1NF et si, etc."
