Discussion :

[Obsidian]

Salut à tous,
Comme pas mal de monde, je fais du SQL presqu'au quotidien depuis presqu'une vingtaine d'année mais cette semaine, je me suis (re-)posé une question de débutant à laquelle je n'ai pas réussi à trouver une explication claire dans la norme.

Bien sûr, je sais à quoi sert une clé, et en particulier une clé primaire. Elle permet de désigner un champ ou un agrégat de champ qui, à eux seuls, permettent de distinguer de façon déterministe un enregistrement de la table. Cela implique notamment l'unicité et la non-nullité de la valeur de cette clé. Le fait de désigner une clé principale permet également d'indiquer la méthode préférentielle à suivre pour explorer la table concernée.

Par contre, au niveau du langage SQL, PRIMARY KEY n'est pas un simple raccourci pour une déclaration combinée du style UNIQUE NOT NULL INDEX. C'est aussi un qualificatif qui apparait clairement dans la description d'une table, sur à peu près tous les SGBD. Et à ma connaissance, il n'existe pas de déclaration REGULAR KEY pour définir d'autres clés officielles sur la même table (ce qui ne nous empêche pas de le faire quand même en utilisant les clauses habituelles).

Certes, elle a été définie très tôt par Codd, mais a-t-elle un impact technique au sein des SGBD habituellement utilisés aujourd'hui, autre que ceux décrits ci-dessus, ou bien cette déclaration est-elle purement consultative au delà de la table qu'elle concerne ?

Merci à tous !

[SQLpro]

...
Bien sûr, je sais à quoi sert une clé, et en particulier une clé primaire. Elle permet de désigner un champ ou un agrégat de champ qui, à eux seuls, permettent de distinguer de façon déterministe un enregistrement de la table.

Beaucoup d'erreur dans vos propos montre que vous ne comprenez pas ce qu'est un SGBD Relationnel et en êtes resté aux fichiers Cobol des années 60.
1) le terme champ n'existe pas dans le vocabulaire des SGBD Relationnels. Un champs c'est pour les paysans ou pour les formulaires ou c'est une zone de saisie. On parle de colonne au niveau du MPD ou d'attribut au niveau du MCD.
2) le terme enregistrement n'existe pas non plus au niveau des SGBD Relationnel mais bien dans les fichiers Cobol.... Dans une table on parle de ligne.

Cela implique notamment l'unicité et la non-nullité de la valeur de cette clé.

OUI

Le fait de désigner une clé principale permet également d'indiquer la méthode préférentielle à suivre pour explorer la table concernée.

NON

Il n'y a aucune possibilité d'indiquer au SGBDR qu'il doit utiliser cette clé primaire pour accéder aux lignes de la table. C'est lui qui décide en fonction des circonstances. Vous ne pouvez rien lui imposer...

Par contre, au niveau du langage SQL, PRIMARY KEY n'est pas un simple raccourci pour une déclaration combinée du style UNIQUE NOT NULL INDEX. C'est aussi un qualificatif qui apparait clairement dans la description d'une table, sur à peu près tous les SGBD. Et à ma connaissance, il n'existe pas de déclaration REGULAR KEY pour définir d'autres clés officielles sur la même table (ce qui ne nous empêche pas de le faire quand même en utilisant les clauses habituelles).

Oulala, tellement d'approximation....
Il ne peut y avoir qu'une seule clé primaire dans une table et cela correspond à la clé de la relation (dans le monde mathématique de l'algèbre relationnelle). Cette PK est toujours NOT NULL par essence. pas besoin de le spécifier.
Il peut en revanche y avoir d'autres clés appelées indifféremment clefs alternatives (alternate key) ou cléfs subrogées (surrogate key) dans l'univers mathématique de l'algèbre relationnelle. Dans le monde physique des tables, cela s’appelle une contrainte d'unicité...

Certes, elle a été définie très tôt par Codd, mais a-t-elle un impact technique au sein des SGBD habituellement utilisés aujourd'hui, autre que ceux décrits ci-dessus, ou bien cette déclaration est-elle purement consultative au delà de la table qu'elle concerne ?

Évidemment que cela a un impact énorme pour le fonctionnement des SGBDR ! D'abord cela créé un index unique et ensuite cela permet de retrouver très rapidement n'importe quelle ligne.
Normalement une table sans clé primaire n'est pas une table relationnelle. Certains SGBDR interdisent d'ailleurs et à dessein le fait de créer des tables sans PK. C'est le cas d'Azure SQL et pour des raisons de haute disponibilité synchrone...

Je vous livrerait d'autres explications plus tard.... extraite de mon livre à paraître !

A +

[Obsidian]

Bonjour,
C'est gentil d'avoir pris le temps de répondre.

Beaucoup d'erreur dans vos propos montre que vous ne comprenez pas ce qu'est un SGBD Relationnel et en êtes resté aux fichiers Cobol des années 60.

Non, non. Je ne confonds rien du tout et je n'étais pas encore né à l'époque du Cobol. Par contre, j'ai fait beaucoup de fichiers dans les années 80 sur huit bits quand c'était encore la mode du BASIC et mon père utilisait lui-même dBase III. Et depuis fin des années 90, je n'utilise (comme à peu près tout le monde) que le SQL.

Et oui, je construis bien des bases relationnelles et pas des tables isolées dans leur coin. Je ne gère pas non plus mes bases de données avec Excel (je le dis en préventif car j'ai le sentiment que c'est la prochaine torpille prête à partir).

1) le terme champ n'existe pas dans le vocabulaire des SGBD Relationnels. Un champs c'est pour les paysans ou pour les formulaires ou c'est une zone de saisie. On parle de colonne au niveau du MPD ou d'attribut au niveau du MCD.
2) le terme enregistrement n'existe pas non plus au niveau des SGBD Relationnel mais bien dans les fichiers Cobol.... Dans une table on parle de ligne.

Pas d'accord, mais admettons. On va dire OK pour la « terminologie officielle ».

On a le droit d'utiliser « tuple » quand même ou c'est interdit ?

NON
Il n'y a aucune possibilité d'indiquer au SGBDR qu'il doit utiliser cette clé primaire pour accéder aux lignes de la table. C'est lui qui décide en fonction des circonstances. Vous ne pouvez rien lui imposer...

C'est bien ce que j'ai dit ! C'est même l'objet de la question.

Il ne peut y avoir qu'une seule clé primaire dans une table et cela correspond à la clé de la relation (dans le monde mathématique de l'algèbre relationnelle). Cette PK est toujours NOT NULL par essence. pas besoin de le spécifier. Il peut en revanche y avoir d'autres clés appelées indifféremment clefs alternatives (alternate key) ou cléfs subrogées (surrogate key) dans l'univers mathématique de l'algèbre relationnelle. Dans le monde physique des tables, cela s’appelle une contrainte d'unicité...

Ça, c'est clair aussi. La vraie question est en dessous.

Évidemment que cela a un impact énorme pour le fonctionnement des SGBDR ! D'abord cela créé un index unique et ensuite cela permet de retrouver très rapidement n'importe quelle ligne.
Normalement une table sans clé primaire n'est pas une table relationnelle.

Même chose.

Certains SGBDR interdisent d'ailleurs et à dessein le fait de créer des tables sans PK. C'est le cas d'Azure SQL et pour des raisons de haute disponibilité synchrone...

Je vais reformuler. La vraie question était en fait :

1. Pourquoi faut-il une clé primaire officielle plutôt que s'en tenir aux clés alternatives ? Ça paraît être une bonne idée de prime abord mais en y réfléchissant, la question se pose. → Je veux bien admettre toutefois que ce soit un prérequis pour faire de l'algèbre relationnelle ;
   
2. EDIT : Est-ce que la vraie raison originale est « ensembliste » au sens mathématique du terme, c'est-à-dire que la théorie des ensemble interdit de fait d'avoir deux éléments identiques au sein d'un même ensemble parce que sous cet angle, il s'agit nécessaire du même élément ? Et que du coup, on nous laisse le soin de choisir nous-mêmes au moins une clé pour garantir ce prérequis ?
   
3. Si oui, pourquoi faut-il désigner une clé principale à partir du moment où on a au moins une ? Est-ce, là encore, pour les besoins de l'algèbre relationnel primordial et nous permettre de combiner les terminaux avec les opérateurs sans avoir à préciser la clé ? (ce qui était à peu près ce que j'entendais dans mon premier post).
   
4. Si je pose « R ⋈ S », cela implique que l'une des relations utilise une clé étrangère vers l'autre relation, mais pas nécessairement la clé primaire, si ?
   
5. Est-ce les SGBD s'en servent de façon tacite (il n'a jamais été question d'imposer quoi que ce soit dans mon post initial) lorsqu'on les déclare et si oui, dans quelle mesure exactement ? Là encore, je parle bien des clés « primaires » ;
   
6. On a évoqué Azure et la haute-disponibilité, qui est déjà un travail d'expert. Est-ce que les SGBD que l'on utilise sur micro-ordinateur (PostGreSQL au hasard, les autres aussi) les utilisent techniquement et en pratique ?

Je vous livrerait d'autres explications plus tard.... extraite de mon livre à paraître !

Celles-là, je les veux bien dans ce cas. Je mets une notification sur le fil !

[SQLpro]

... Et oui, je construis bien des bases relationnelles et pas des tables isolées dans leur coin.

la encore grave confusion, relationnel ne signifie pas du tout lien... Erreur que l'on trouve communément. Ce qui fait la force des SGBD Relationnel c'est justement l'absence totale de liens ! Le terme relationnel désignant l'objet porteur de l'information (en d'autres termes la table...).

Extrait du dico Larrousse :
relation
nom féminin
Définitions : Action de rapporter en détail ce dont on a été le témoin ou dont on a eu connaissance ; récit qu'on en fait : Faire la relation des événements auxquels on a participé.

Autrement dit la relation c'est l'objet mathématique qui porte les données. Et l'algèbre relationnelle, l'algèbre qui manipule les relations à l'aide d'opérateurs (UNION, INTERSECTION, DIFFÉRENCE, PROJECTION, RESTRICTION, PRODUIT CARTÉSIEN, DIVISION et JOINTURE). Une table pouvant être relationnelle si et seulement si :

• elle contient une clé primaire
• tous les attributs de toutes les occurrences sont valuées
• toutes les informations y figurant sont atomiques (insécable sans perte de sens).

Pas d'accord, mais admettons. On va dire OK pour la « terminologie officielle ».

C'est très important... mauvais terminologie = mauvaise compréhension; Un petit exemple par les synonymes :
Microonde <=> Four
Four <=> Bide (lire : https://www.larousse.fr/dictionnaire...6?q=Four#34781 pour cette définition...)
Bide <=> ventre
Conclusion : Microonde = Ventre !!!

On a le droit d'utiliser « tuple » quand même ou c'est interdit ?

C'est un mot réservé au MCD, pas au MPD. Dans le MCD on parle d'entité, d'association, de valeur et de n-uplet (ou tuple si l'on est anglophone).
Dans le MPD on parle table, ligne, colonne, contraintes...

Pourquoi faut-il une clé primaire officielle plutôt que s'en tenir aux clés alternatives ? Ça paraît être une bonne idée de prime abord mais en y réfléchissant, la question se pose. → Je veux bien admettre toutefois que ce soit un prérequis pour faire de l'algèbre relationnelle ;

Une clé alternative admet le NULL, qui, par essence peu être plural. Comprenez que plusieurs ligne de la table peuvent avoir le marquer NULL dans la clef.... Comment alors repérer avec certitude les lignes si le reste des informations doublonne ?

Est-ce que la vraie raison originale est « ensembliste » au sens mathématique du terme, c'est-à-dire que la théorie des ensemble interdit de fait d'avoir deux éléments identiques au sein d'un même ensemble parce que sous cet angle, il s'agit nécessaire du même élément ? Et que du coup, on nous laisse le soin de choisir nous-mêmes au moins une clé pour garantir ce prérequis ?

Exactement, l'algèbre relationnel de Codd repose sur la théorie des ensembles...

Si oui, pourquoi faut-il désigner une clé principale à partir du moment où on a au moins une ? Est-ce, là encore, pour les besoins de l'algèbre relationnel primordial et nous permettre de combiner les terminaux avec les opérateurs sans avoir à préciser la clé ? (ce qui était à peu près ce que j'entendais dans mon premier post).

Toujours à cause du NULL !

Si je pose « R ⋈ S », cela implique que l'une des relations utilise une clé étrangère vers l'autre relation, mais pas nécessairement la clé primaire, si ?

Absolument pas.... Il n'y a pas de lien génétique entre clef primaire / clef étrangères et jointure. L'opération de jointure peut se faire sur n'importe quoi. Dans tous mes cours, je montre immédiatement ce point là alors que la plupart de mes auditeur considère que faire une jointure n'est possible qu'en PK et Fk !!!
Je viens d'ailleurs de le démontrer ce matin, donnant un cours.... Tout dépend de la question que je pose !

Est-ce les SGBD s'en servent de façon tacite (il n'a jamais été question d'imposer quoi que ce soit dans mon post initial) lorsqu'on les déclare et si oui, dans quelle mesure exactement ? Là encore, je parle bien des clés « primaires » ;

Non, pas de manière tacite, cela n'a pas de sens. Mais l'optimiseur est aidé, dans certaines circonstance par la présence de FK pour établir un plan efficace;

On a évoqué Azure et la haute-disponibilité, qui est déjà un travail d'expert. Est-ce que les SGBD que l'on utilise sur micro-ordinateur (PostGreSQL au hasard, les autres aussi) les utilisent techniquement et en pratique ?

PostGreSQL est faiblement relationnel. Ce n'est pas le pire, mais déjà, il ne sait pas faire certaines opérations normales que tout SGBD réellement relationnel devrait pouvoir faire. Codd dénonçait cela dès 1985 dans ses articles de la revue COMPUTERWORLD.
• « Is Your DBMS Really Relational? » le 14 octobre 1985.
• « Does Your DBMS Run by the Rules? » 21 octobre 1985.

A +

[Obsidian]

Encore une fois, merci d'avoir pris le temps.

la encore grave confusion, relationnel ne signifie pas du tout lien... Erreur que l'on trouve communément. Ce qui fait la force des SGBD Relationnel c'est justement l'absence totale de liens ! Le terme relationnel désignant l'objet porteur de l'information (en d'autres termes la table...).

On est d'accord, mais j'admets qu'il faut être précis. Comme on a cité d'autres vieilleries (Cobol et dBase en l'occurrence) qui, elles, traitent les choses de façon légèrement différente, je voulais être clair sur ce fait.

Autrement dit la relation c'est l'objet mathématique qui porte les données.

On est d'accord aussi.

Et l'algèbre relationnelle, l'algèbre qui manipule les relations à l'aide d'opérateurs (UNION, INTERSECTION, DIFFÉRENCE, PROJECTION, RESTRICTION, PRODUIT CARTÉSIEN, DIVISION et JOINTURE). Une table pouvant être relationnelle si et seulement si :

• elle contient une clé primaire
• tous les attributs de toutes les occurrences sont valuées
• toutes les informations y figurant sont atomiques (insécable sans perte de sens).

On va en profiter pour préciser ça aussi : ici, une « occurrence » correspond à une ligne de la table (à un n-uplet) ? Et par « information y figurant », on considère que c'est au niveau de l'attribut ou de la ligne ? Parce que j'imagine qu'on ne considère pas la table entière comme insécable… (ou alors elles le sont, et c'est l'opération qui engendre un nouvel objet mais là, je me dissipe un peu).

C'est très important... mauvais terminologie = mauvaise compréhension; Un petit exemple par les synonymes :
Microonde <=> Four
Four <=> Bide (lire : https://www.larousse.fr/dictionnaire...6?q=Four#34781 pour cette définition...)
Bide <=> ventre
Conclusion : Microonde = Ventre !!!

L'exemple est un peu douteux parce qu'il ne s'agit pas exactement de synonymes, mais d'hyponymes. Mais je suis d'accord sur le fond quand même. Mal nommer les choses, c'est ajouter à la misère du monde et c'est spécialement en vrai en mathématiques (particulièrement en théorie des graphes) mais également en aviation et dans d'autres disciplines qui ont leur propre phraséologie. Donc OK pour le « lexique » initial.

C'est un mot réservé au MCD, pas au MPD. Dans le MCD on parle d'entité, d'association, de valeur et de n-uplet (ou tuple si l'on est anglophone).
Dans le MPD on parle table, ligne, colonne, contraintes...

Ok.

Une clé alternative admet le NULL, qui, par essence peu être plural. Comprenez que plusieurs ligne de la table peuvent avoir le marquer NULL dans la clef.... Comment alors repérer avec certitude les lignes si le reste des informations doublonne ?

Alors voila : on est tout-à-fait d'accord sur le principe mais c'est là l'ambiguïté qui me gêne au départ : quand on se met à gérer des bases de données sérieusement en commençant directement par le SQL, il manque un peu l'historique (comme souvent) et c'est difficile de faire « l'intersection » des deux justement (ce qui a été défini par la théorie initiale et ce qui est propre au SQL ensuite).

Ce que je voulais dire, c'est qu'il est tout-à-fait possible (et même fréquent) de déclarer une colonne « UNIQUE NOT NULL » dans une table sans qu'il s'agisse forcément de la clé primaire.

Du coup, est-ce que c'est illégal (ou simplement indéfini) de le faire en algèbre relationnel ou alors, à l'inverse, la clause PRIMARY KEY apporte-t-elle des choses en plus (outre le fait de déclarer officiellement la colonne comme telle) ?

Ou alors, est-il exact d'affirmer que l'on considère que toute donnée peut être non renseignée (donc NULL), y compris une clé, et que seulement ensuite on en indique une pour laquelle ce ne sera jamais le cas, car c'est la condition « nécessaire et suffisante » pour que l'algèbre relationnel puisse s'appliquer ?

Non, pas de manière tacite, cela n'a pas de sens. Mais l'optimiseur est aidé, dans certaines circonstance par la présence de FK pour établir un plan efficace;

PostGreSQL est faiblement relationnel. Ce n'est pas le pire, mais déjà, il ne sait pas faire certaines opérations normales que tout SGBD réellement relationnel devrait pouvoir faire. Codd dénonçait cela dès 1985 dans ses articles de la revue COMPUTERWORLD.
• « Is Your DBMS Really Relational? » le 14 octobre 1985.
• « Does Your DBMS Run by the Rules? » 21 octobre 1985.

D'accord ! C'est l'autre pièce du puzzle qui me manquait.

Le SQL, je l'ai appris sur le tas en 1999-2000 avec le cours de SQLPro. La théorie, dont les formes normales, je les ai étudiées ensuite en retournant en école d'ingé mais à cette époque, je traversais des moments difficiles qui m'ont empêché de bien consolider ces acquis et ensuite, professionnellement, on a beaucoup moins l'occasion de faire du conceptuel pur que de pratiquer directement le SQL en mettant les mains dans le cambouis.

Merci pour les références.
A++

[SQLpro]

...
Alors voila : on est tout-à-fait d'accord sur le principe mais c'est là l'ambiguïté qui me gêne au départ : quand on se met à gérer des bases de données sérieusement en commençant directement par le SQL, il manque un peu l'historique (comme souvent) et c'est difficile de faire « l'intersection » des deux justement (ce qui a été défini par la théorie initiale et ce qui est propre au SQL ensuite).

Effectivement le problème est que le langage SQL diverge fortement des principes mathématiques de l'algèbre relationnelle. Il prend de telles libertées que certaines, dont Chris Date on inventé un autre langage "Tutorial D" pour satisfaire pleinement la théorie...

Ce que je voulais dire, c'est qu'il est tout-à-fait possible (et même fréquent) de déclarer une colonne « UNIQUE NOT NULL » dans une table sans qu'il s'agisse forcément de la clé primaire.

Fréquent, hélas pas trop. Mes audits montrent que généralement les développeurs qui créent des bases de données ne connaissent pas la contrainte d'unicité !...

Du coup, est-ce que c'est illégal (ou simplement indéfini) de le faire en algèbre relationnel ou alors, à l'inverse, la clause PRIMARY KEY apporte-t-elle des choses en plus (outre le fait de déclarer officiellement la colonne comme telle) ?

Elle apporte déjà la gestion des conséquences de l'articulation des référence entre la clé de référence (PK ou UK) et la clé étrangères, à savoir :
1) le mode de gestion qui peut être ON DELETE / ON UPDATE ...
... NO ACTION
... RESTRICT
... SET DEFAULT
... SET NULL
... CASCADE
2) le contrôle de valeur de clé, qui peut être MATCH
... FULL
... PARTIAL
... SIMPLE

Enfin l'optimiseur peut décider de supprimer certaines jointures écrites inutilement dans une requête, du fait de présence de la FK...

Ou alors, est-il exact d'affirmer que l'on considère que toute donnée peut être non renseignée (donc NULL), y compris une clé, et que seulement ensuite on en indique une pour laquelle ce ne sera jamais le cas, car c'est la condition « nécessaire et suffisante » pour que l'algèbre relationnel puisse s'appliquer ?

Le but de la modélisation des données est de supprimer le NULL qui pèse sur les performances.... Stocker des octets pour rien possède un coût non négligeable dans de nombreux traitement sauvegardes, index, lecture de tables par balayage...), à commencer par un volume de données anormalement accru par le stockage du NULL (réservation d'octets), là ou, en pratique on ne devrait rien stocker!

Pour la petite histoire au sujet des malfaçons de PostGreSQL, je donne la petite requête suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
CREATE TABLE T (C INT PRIMARY KEY);
INSERT INTO T VALUES (1), (2), (3);
UPDATE T SET C = C + 1;

Qui passe dans tous les véritable SGBD relationnels (DB2, Oracle, SQL Server, Sybase...)
Mais pas dans les ersatz que sont : MySQL ou PostGreSQL...

Or Codd le précise bien dans ses règles :
Règle 7 : Insertion, modification et suppression de haut niveau
La capacité de gérer une relation basique ou dérivée comme un opérande pour une opération relationnelle s'applique non seulement à l’extraction des données mais également à l'insertion, la modification et la suppression.
Par "haut niveau" comprenez "ensembliste" et non ligne à ligne, ce que font hélas MySQL et PostGreSQL, raison pour laquelle ils se vautrent !

A +

[escartefigue]

Bonjour,

Quelques explications sur ce sujet ici :

https://sgbd.developpez.com/actu/859...es-par-fsmrel/