Discussion :

[Oppenheimer]

Bonjour!

On nous enseignait que la clé primaire identifiait les enregistrements. J'ai donc dit à la plus grande horreur de mon formateur d'il y a 4 ans, que ce que j'appelais le "complément" (à ladite clé) identifiait tout autant la clé, étant donné que l'identité est une bijection.

Seulement, je me dit depuis quelques jours (seulement), quelque chose d'assez fondamental: En fait, la clé, par son unicité, n'identifie qu'elle même!

Du coup, je me suis dit, (pour autant que les attributs non identifiant varient selon des catégories, à séparer, selon Audibert) :
Pour garantir un haut niveau de normalisation, les tables devraient ne contenir que des clés primaires naturelles (en dehors de clé étrangères pour les références) !

-Qu'en pensez-vous ?

(L'avis de Fsmrel, ou de Audibert m'intéressent particulièrement).

D'avance merci pour votre contribution.

[Oishiiii]

Bonjour,

Pour garantir un haut niveau de normalisation, les tables devraient ne contenir que des clés primaires naturelles (en dehors de clé étrangères pour les références) !

Qu'est-ce que vous entendez par "haut niveau" de normalisation ? Il ne s'agit apparemment pas de 4ème ou 5ème forme normale.

Si par clé "naturelle" vous faites référence à un attribut dont les valeurs ne sont pas générées artificiellement (GUID, auto-incrément, etc.). Par exemple un nom de société ou de produit.
Alors il faut prendre en compte le fait que la clé garantit en effet l'unicité des valeurs, mais elle ne garantit pas leur invariance (il peut y avoir des changements).
Une clé primaire étant très souvent utilisée comme référence de clés étrangères, il est préférable que les valeurs qu'elles peut prendre soient invariantes.
Mais là, il s'agit à mon avis plus d'une question de modélisation que de normalisation.

[escartefigue]

Si par clé "naturelle" vous faites référence à un attribut dont les valeurs ne sont pas générées artificiellement (GUID, auto-incrément, etc.). Par exemple un nom de société ou de produit.
Alors il faut prendre en compte le fait que la clé garantit en effet l'unicité des valeurs, mais elle ne garantit pas leur invariance (il peut y avoir des changements).
Une clé primaire étant très souvent utilisée comme référence de clés étrangères, il est préférable que les valeurs qu'elles peut prendre soient invariantes.
Mais là, il s'agit à mon avis plus d'une question de modélisation que de normalisation.

Tout à fait, vous touchez là un point majeur dans le choix des clefs primaires !

J'ai plaidé récemment le cas dans une étude de MCD où la personne avait choisi le code SIREN comme clef primaire... très mauvaise idée !
Le SIREN peut changer (ex : rachat d'entreprise) s'il est clef, primaire, alors le changement requiert une mise à jour en cascade dans toutes les tables filles et là, c'est potentiellement le drame (en fonction du volume à mettre à jour)

Le SIREN peut être une très bonne clef alternative, mais pas la clef primaire.
Une clef primaire doit être stable et donc asémantique
Les identifiants issus d'une nomenclature externe, ne doivent donc jamais être retenus comme clef primaire (SIREN, RIB, IBAN, etc...)

De plus, une clef primaire doit être concise, pour pouvoir être manipulée avec le moins de cycles processeur possibles.
Cas du SIREN : 9 caractères soit 9*8 = 72 bits soit 2 cycles processeur pour un proc 64 bits et 3 pour un proc 32 bits
Avec un identifiant de type integer, un seul cycle suffit.

[Oppenheimer]

Bonjour,



Qu'est-ce que vous entendez par "haut niveau" de normalisation ? Il ne s'agit apparemment pas de 4ème ou 5ème forme normale.

Si par clé "naturelle" vous faites référence à un attribut dont les valeurs ne sont pas générées artificiellement (GUID, auto-incrément, etc.). Par exemple un nom de société ou de produit.
Alors il faut prendre en compte le fait que la clé garantit en effet l'unicité des valeurs, mais elle ne garantit pas leur invariance (il peut y avoir des changements).
Une clé primaire étant très souvent utilisée comme référence de clés étrangères, il est préférable que les valeurs qu'elles peut prendre soient invariantes.
Mais là, il s'agit à mon avis plus d'une question de modélisation que de normalisation.

Mmm... En effet, je n'ai pas parlé explicitement de 6NF, car son application suit un processus, selon lequel l'on scinde les données variant différemment, puis l'historique du courant, et je n'étais pas sûr si un intervalle pouvait être défini comme clé.
Mais la nature de la clé et ce qu'elle implique concerne à mon avis plus la normalisation que le modèle; typiquement, j'avais un problème de composition de FKs en PK - pour une question d'incohérence que j'ai réglée sans aucune modification du modèle - mais l'ajout d'un ID ferait une redondance (d'identification). Si je me rappelle bien 2NF (la plus compliquée à comprendre, selon moi), l'ajout d'un ID non-nécessaire serait contre-indiqué, du moment où les attributs secondaires doivent dépendre (non-transitivement) de la clé. Donc selon cette vision, une redondance d'identifiant ne pourrait empêcher une potentielle dépendance transitive.

Je vois ce que vous voulez dire pour la question de l'invariance, mais une clé primaire naturelle n'a pas (non plus) à être changée, une fois l'enregistrement établi ?

[Oppenheimer]

Tout à fait, vous touchez là un point majeur dans le choix des clefs primaires !

J'ai plaidé récemment le cas dans une étude de MCD où la personne avait choisi le code SIREN comme clef primaire... très mauvaise idée !
Le SIREN peut changer (ex : rachat d'entreprise) s'il est clef, primaire, alors le changement requiert une mise à jour en cascade dans toutes les tables filles et là, c'est potentiellement le drame (en fonction du volume à mettre à jour)

Le SIREN peut être une très bonne clef alternative, mais pas la clef primaire.
Une clef primaire doit être stable et donc asémantique
Les identifiants issus d'une nomenclature externe, ne doivent donc jamais être retenus comme clef primaire (SIREN, RIB, IBAN, etc...)

De plus, une clef primaire doit être concise, pour pouvoir être manipulée avec le moins de cycles processeur possibles.
Cas du SIREN : 9 caractères soit 9*8 = 72 bits soit 2 cycles processeur pour un proc 64 bits et 3 pour un proc 32 bits
Avec un identifiant de type integer, un seul cycle suffit.

Ah, À vrai dire, je ne connais pas la notion de SIREN, mais l'exemple de l'IBAN m'évoque quelque chose. Mais après tout, si ladite entreprise (appelons-la A) a été rachetée (par B), ce n'est plus la même entreprise! Dans votre méthode, vous êtes susceptible de perdre toute trace de l'entreprise A, non?

Ce SIREN, de A, pourrait être stocké dans l'historique, et vous pourriez invoquer un SIREN(B) comme SIREN courant?

Resterait à faire les bonnes liaisons pour savoir quel entreprise courante a quel passé...

[escartefigue]

Ah, À vrai dire, je ne connais pas la notion de SIREN, mais l'exemple de l'IBAN m'évoque quelque chose. Mais après tout, si ladite entreprise (appelons-la A) a été rachetée (par B), ce n'est plus la même entreprise! Dans votre méthode, vous êtes susceptible de perdre toute trace de l'entreprise A, non?

Ce SIREN, de A, pourrait être stocké dans l'historique, et vous pourriez invoquer un SIREN(B) comme SIREN courant?

Resterait à faire les bonnes liaisons pour savoir quel entreprise courante a quel passé...

Ce n'est pas ma méthode, c'est tout le contraire !
Le SIREN est l'identification des entreprises attribuée par l'INSEE, complété du NIC il forme le SIRET qui identifie l'établissement au sein d'une entreprise. SIREN(9 car)+NIC(5Car) forment le SIRET
Si une entreprise change de SIREN, on peut bien sur utiliser une notion d'historique avec date de changement, mais à condition que le SIREN ne soit pas la clef primaire.

L'IBAN est le numéro de compte bancaire au format international, en France, il est d'une structure très proche de celle du RIB, et contient notamment le code banque et le code guichet.
Or un projet de portabilité du compte bancaire est dans les tiroirs (il n'est plus trop à l'ordre du jour, mais que je sache pas encore enterré).
Ca signifie que s'il aboutit, on conservera le même n° de compte en banque même si l'on change de banque ou de guichet !
En ce cas le code banque ou guichet du RIB ou de l'IBAN ne correspondra plus au code banque ou guichet réel !
Là aussi ca peut faire mal
De plus l'IBAN fait 34 caractères, c'est loin d'être optimal pour une clef primaire : 5 cycles CPU pour un processeur 64 bits

[Oishiiii]

Si je me rappelle bien 2NF (la plus compliquée à comprendre, selon moi), l'ajout d'un ID non-nécessaire serait contre-indiqué, du moment où les attributs secondaires doivent dépendre (non-transitivement) de la clé. Donc selon cette vision, une redondance d'identifiant ne pourrait empêcher une potentielle dépendance transitive.

Pour la définition de la 2NF je vous invite à consulter l'article d'fsmrel.
La définition se base sur chaque clé de la relation. Il peut y en avoir plusieurs.

Il est important de rappeler que dans la normalisation, il n'y a qu'un seule type de clé (la clé candidate).
Il n'y a pas de notion "d'identification" ou "d'identifiant".

La clé primaire est une clé que l'on choisi parmi toutes les clé disponibles.
Comment fait-on pour la choisir ? Il n'y a pas de méthode formelle, ça ne fait pas partie de la normalisation.
On choisit la clé primaire pour des raisons pratiques. Pratique au niveau logique lors de la modélisation et pratique également pour l'aspect performance.

Si une relation possède une seule clé, alors effectivement elle pourrait être choisie comme clé primaire.
Mais le concepteur de base de données fort de son expérience va souvent préférer ajouter une clé non "naturelle", que ce soit pour des raisons de performances ou tout simplement car on sait que les valeurs d'une clé "naturelle" peuvent être amenées à changer, qu'on le veuille ou non (cf. exemple d'escartefigue).

Concernant les relations qui possèdent plusieurs clés.
Chacune de ces clés peut être la référence de clés étrangères partout dans la base de données, dans différentes relations.
La bonne pratique est de choisir une seule de ces clé pour simplifier toutes ces références.
Quelle clé choisir ?
Là aussi, plutôt que choisir on préfère créer une clé "artificielle", dont les valeurs sont donc invariantes et dénuées de sens.

Je vois ce que vous voulez dire pour la question de l'invariance, mais une clé primaire naturelle n'a pas (non plus) à être changée, une fois l'enregistrement établi ?

Mais on constate souvent dans la pratique que les valeurs peuvent changer.


Donc je reste sur ma position.
Le choix de la clé primaire, qu'elle soient naturelle ou non, qu'elle soit chaîne de caractères ou entier, concerne la modélisation, la conception de bases de données et pas la normalisation.

D'ailleurs si on regarde la méthode Merise, chaque entité doit posséder un code "identifiant" au niveau conceptuel, qui au final en SQL se retrouve être une clé primaire de type entier auto-incrémenté.

Michel Diviné dans Parlez-vous Merise ? écrit page 44 :

Quand l'individu "personne" existe, les informations qu'il porte, ses propriétés peuvent être mentionnées plus tard.
A la question "cite moi des occurrences de tel individu", la réponse doit être aisée.
En conséquence, les occurrences d'individus peuvent être identifiées.
Même deux clones sont identifiables par un code, un numéro, une référence, en un mot, un identifiant. Celui-ci est une information particulière.

PS: Je vois que fsmrel passe en ce moment sur le sujet. Il viendra certainement mettre les points sur les i.

[fsmrel]

Bonsoir à vous trois,


Je découvre cette discussion entamée par Oppenheimer. Au fil des ans, le sujet abordé revient régulièrement sur le tapis, tel le serpent de mer...

Une clé primaire étant très souvent utilisée comme référence de clés étrangères, il est préférable que les valeurs qu'elles peut prendre soient invariantes.
Mais là, il s'agit à mon avis plus d'une question de modélisation que de normalisation.

Hello vaillant Oishiiii ! Toujours les bons réflexes ! C’est effectivement un strict problème de modélisation.

Le SIREN peut être une très bonne clef alternative, mais pas la clef primaire.
Une clef primaire doit être stable et donc asémantique
Les identifiants issus d'une nomenclature externe, ne doivent donc jamais être retenus comme clef primaire (SIREN, RIB, IBAN, etc...)

Hello fidèle commandant ! Là encore c’est très clair, nous menons le même combat. Le SIREN est un point d’entrée dans la base de données pour l’utilisateur, et son instabilité interdit qu’on en fasse une clé primaire.


@ Oppenheimer : à ce propos, avez-vous lu mon billet traitant de l’invariance des clés primaires ?

De plus, une clef primaire doit être concise, pour pouvoir être manipulée avec le moins de cycles processeur possibles.
Cas du SIREN : 9 caractères soit 9*8 = 72 bits soit 2 cycles processeur pour un proc 64 bits et 3 pour un proc 32 bits
Avec un identifiant de type integer, un seul cycle suffit.

Certes, mais on est là dans la soute, et même avec les processeurs d’il y a quarante ans (IBM 308x, Burroughs 68xx, etc.) on ne perdrait pas trop de temps. Il faut aussi tenir compte de l’encombrement en mémoire du SIREN et (surtout) de la hauteur de l’arbre correspondant à l’index utilisé pour les accès.


Exemple (IBM DB2 V8). Prenons le cas d’une table ENTREPRISE, dotée d’une clé primaire artificielle et d’une clé alternative, en l’occurrence le SIREN et le résultat des calculs effectués par DB2 Estimator.

Cas de l’index associé à la clé primaire (4 octets) :





Cas du SIREN (type DECIMAL(9), soit 5 octets) :





Variante du SIREN (type CHAR(9), soit 9 octets) :





Bon, y a pas l’feu au Lac ! D’accord, dans le cas CHAR(9), le nombre de pages (4K chacune) est en accroissement, mais la hauteur de l’arbre reste égale à 3, ce qui fait que le nombre d’entrées/sorties pour accéder aux données de la table cible est le même dans tous les cas.

Bien entendu, on prendrait la raison sociale pour la clé primaire, la normalisation ne serait évidemment pas perturbée, mais les performances le seraient, car la hauteur de l’arbre passe à 4 :

la nature de la clé et ce qu'elle implique concerne à mon avis plus la normalisation que le modèle

Qu’entendez-vous par nature de la clé ? Quoi qu’il en soit, la normalisation dit que chaque sous-ensemble K (non strict) de noms d’attributs de l’en-tête d’une relvar (variable relationnelle) R est seulement astreint à respecter les contraintes suivantes :

Unicité. Deux tuples distincts de R ne peuvent avoir même valeur de K.

Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Dans ces conditions, K est un ensemble ayant pour éléments chacun des (noms d’) attributs de l’en-tête de R. Autrement dit, si F est l’ensemble des dépendances fonctionnelles de R, la fermeture K⁺ de K par rapport à F doit être égale à la fermeture F⁺ de l’ensemble F :

K⁺ = F⁺

Incidemment, si par nature de la clé, vous voulez dire « primaire » ou « alternative », je rappelle que du point de vue de la théorie relationnelle, ces qualificatifs sont obsolètes, ils ont été évacués de la théorie il y a près de 20 ans. Je cite C.J. Date dans An Introduction to Database Systems, Seventh Edition, ouvrage paru en 2000 :

« [...] it is possible for a given relvar to have more than one candidate key. In such a case, the relational model has historically required—at least in the case of base relvars—that exactly one of those keys be chosen as the primary key, and the others are then called alternate keys. »

Ou encore, dans les éditions successives de SQL and Relational Theory :

« [...] wheter some key is chosen as primary, and if so which one, are essentially psychological issues, beyond the purview of the relational model as such. »

En remontant à 1993, voyez l’article paru dans InfoDB 7, No. 3 (Summer 1993) et repris dans Relational Database, Writings 1991-1994 au chapitre 2 « The Primacy of Primary keys: An Investigation » :

« The final point was an appeal to Occam’s Razor (“no unnecessary concepts”). In effect, I was arguing that to treat all candidate keys as equals was to complicate the addressing scheme unnecessarily. But it might well be argued that Occam’s Razor applies the other way around, and that is the concepts of primary and alternate key that are unnecessary!—i.e., all we really need is candidate keys. »

Et dans cet article, C.J. Date fait référence à ses écrits de 1984, dans lesquels il évoquait déjà la possibilité d’évacuer la distinction PK:AK alors que la reine des clés était Miss Clé Primaire, régnant sans partage sur ses dauphines, les clés alternatives, auxquelles il était interdit, par privilège royal, à la moindre clé étrangère de pouvoir s’adresser.

PS: Je vois que fsmrel passe en ce moment sur le sujet. Il viendra certainement mettre les points sur les i.

Si fait ! Tout ce que vous avez écrit est frappé au coin du bon sens, donc je ne commenterai pas, d’autant que nous disons les même choses

Si je me rappelle bien 2NF (la plus compliquée à comprendre, selon moi), l'ajout d'un ID non-nécessaire serait contre-indiqué, du moment où les attributs secondaires doivent dépendre (non-transitivement) de la clé. Donc selon cette vision, une redondance d'identifiant ne pourrait empêcher une potentielle dépendance transitive.

Oishiiii a tout dit. Notamment : « La définition se base sur chaque clé de la relation. Il peut y en avoir plusieurs ». De votre côté, vous faites mention de « la clé », ce qui ne fonctionne pas.

[escartefigue]

Certes, mais on est là dans la soute, et même avec les processeurs d’il y a quarante ans (IBM 308x, Burroughs 68xx, etc.) on ne perdrait pas trop de temps. Il faut aussi tenir compte de l’encombrement en mémoire du SIREN et (surtout) de la hauteur de l’arbre correspondant à l’index utilisé pour les accès.

Hello Fsmrel, heureux de vous retrouver sur ce topic, il est vrai récurrent
En effet la concision de la clef primaire n'est pas le paramètre majeur, mais, toute choses égales par ailleurs, une clef concise reste la meilleure
De plus, la profondeur ou hauteur de l'arbre est une chose, mais la taille de la clef -et la on reste dans la soute, voire dans le compartiment moteur - génère aussi de l'encombrement disque, de la charge réseau, de l'encombrement mémoire, bref toutes sortes de choses nécessaires mais dont l'encombrement a un coût, qu'il convient de réduire autant que faire se peut.

[Oppenheimer]

Bonjour à tous,

Excusez-moi, j'ai pris un week-end de libre.

Ce n'est pas ma méthode, c'est tout le contraire !
Le SIREN est l'identification des entreprises attribuée par l'INSEE, complété du NIC il forme le SIRET qui identifie l'établissement au sein d'une entreprise. SIREN(9 car)+NIC(5Car) forment le SIRET
Si une entreprise change de SIREN, on peut bien sur utiliser une notion d'historique avec date de changement, mais à condition que le SIREN ne soit pas la clef primaire.

-Etant donné que ? -À mon sens, si une clé primaire n'est pas gérée par le système, (et qu'elle est véritablement unique), il suffirait de transposer celle-ci dans l'historique, et de créer une nouvelle pour le rachat. Il s'agirait d'une simple update, non?

L'IBAN est le numéro de compte bancaire au format international, en France, il est d'une structure très proche de celle du RIB, et contient notamment le code banque et le code guichet.
Or un projet de portabilité du compte bancaire est dans les tiroirs (il n'est plus trop à l'ordre du jour, mais que je sache pas encore enterré).
Ca signifie que s'il aboutit, on conservera le même n° de compte en banque même si l'on change de banque ou de guichet !

-Perso, je suis absolument contre un tel projet, car il ne représentera plus la réalité - mais vous semblez aussi dénoncer cette deuxième partie, dont je n'ai pas vraiment compris le rapport; vous semblez mettre en évidence le problème de variance, au sujet de quoi ai-je au maximum évoqué qu'il fallait garder un historique.

Je vais prendre un peu de temps pour répondre aux autres intervenants.

[Oppenheimer]

Okay,

Je crois que j'ai compris; j'ai été trop simple en mentionnant que le type de clé, à savoir naturelle ou artificielle, ne modifiait pas mon schéma. Vous avez raison, je ne suis pas dans une forme normale particulière lorsque je mentionne cela. Je suis dans une modélisation qui ne va rien changer du tout à mon modèle. Soit.

Pour la définition de la 2NF je vous invite à consulter l'article d'fsmrel.
La définition se base sur chaque clé de la relation. Il peut y en avoir plusieurs.

Une relation R est en deuxième forme normale si elle est en première forme normale et si chaque attribut n'appartenant à aucune clé candidate est en dépendance totale de chaque clé candidate de R.

(« A relation R is in second normal form if it is in first normal form and every non-prime attribute of R is fully dependant on each candidate key of R. »)

-Si je puis me permettre, la traduction est erronée: être en dépendance totale ne veut pas dire grand-chose, sinon que qu'on aurait répertorié tous les types de dépendances possibles, et que ces attributs (que j'appelle secondaires) devraient avoir à chaque fois tous les types de dépendance...

La juste traduction comprend: Complètement dépendant. Selon ma compréhension, cela veut dire que l'attribut secondaire doit pouvoir être impliqué par la clé candidate, mais je ne sais pas si c'est le cas.

-Je ne sais pas si vous l'avez fait exprès, mais vous avez écrit "chaque clé" en oubliant de préciser que c'étaient des candidates.

Peut-être que je n'ai pas écrit dans le cadre d'une forme normale particulière, mais même si j'expose réellement un problème de modèle, alors je parle bien de clé primaire - et vous avouerez qu'une redondance de clé primaire est inutile, comme n'importe quelle autre redondance, j'espère ?

-Vous me direz que le système de peut pas gérer plusieurs clés primaires... La définition de la clé primaire est-elle effectuée par le système? -Non, faute de quoi les différents système auraient le plus probablement différentes définitions, ce qui rendrait imports et export le plus probablement impossibles.

À mon sens, la définition de clé primaire est bien ce qui identifie. (Sinon, autant l'appeler un éléphant).

Il est important de rappeler que dans la normalisation, il n'y a qu'un seule type de clé (la clé candidate).

Okay. Un seul type, mais potientiellement plusieurs candidates.

Il n'y a pas de notion "d'identification" ou "d'identifiant".

-Vraiment ? -Qu'il n'y ait pas ces appellations, soit, mais qu'il n'y ait pas ces notions, j'en doute!

La clé primaire est une clé que l'on choisi parmi toutes les clé disponibles.
Comment fait-on pour la choisir ? Il n'y a pas de méthode formelle, ça ne fait pas partie de la normalisation.

Je vais vous dire pourquoi il n'y a pas de méthode formelle; parce qu'il n'y en a aucune tout court - tout simplement. Et comme il n'y en a pas, cela ne fait partie ni de la normalisation, ni de la modélisation. Il n'en a pas, parce que s'il y en avait une, cela signifierait par absurde qu'une des clés candidate n'était pas une clé cnadidate.

On choisit la clé primaire pour des raisons pratiques. Pratique au niveau logique lors de la modélisation et pratique également pour l'aspect performance.

Si une relation possède une seule clé, alors effectivement elle pourrait être choisie comme clé primaire.
Mais le concepteur de base de données fort de son expérience va souvent préférer ajouter une clé non "naturelle", que ce soit pour des raisons de performances ou tout simplement car on sait que les valeurs d'une clé "naturelle" peuvent être amenées à changer, qu'on le veuille ou non (cf. exemple d'escartefigue).

En réponse, je n'ai pas encore consulté le lien, mais je l'admets. Ce qui ne semble pas invalider les clés primaire gérées manuellement ?

Concernant les relations qui possèdent plusieurs clés.
Chacune de ces clés peut être la référence de clés étrangères partout dans la base de données, dans différentes relations.
La bonne pratique est de choisir une seule de ces clé pour simplifier toutes ces références.
Quelle clé choisir ?
Là aussi, plutôt que choisir on préfère créer une clé "artificielle", dont les valeurs sont donc invariantes et dénuées de sens.


Mais on constate souvent dans la pratique que les valeurs peuvent changer.


Donc je reste sur ma position.

Soit.

Le choix de la clé primaire, qu'elle soient naturelle ou non, qu'elle soit chaîne de caractères ou entier, concerne la modélisation, la conception de bases de données et pas la normalisation.

Le fait que les primaires ne soient pas définies selon une des formes normales n'implique pas qu'il s'agisse pour autant d'une problème de modélisation. Il faudrait peut-être inventer une nouveau terme; déverouillage, pourquoi pas ?

D'ailleurs si on regarde la méthode Merise, chaque entité doit posséder un code "identifiant" au niveau conceptuel, qui au final en SQL se retrouve être une clé primaire de type entier auto-incrémenté.

-Pourquoi pas en SSADM? Mais j'accepte votre proposition au sujet de "identifiant", c'est sage de l'accepter; pas celle au sujet de auto-incrémenté, en ce qui me concerne. Je changerai peut-être d'avis, mais pour moi, l'identifiant doit faire partie de la sémantique. (J'ai pas encore lu la réponse de Fsmrel !).

Michel Diviné dans Parlez-vous Merise ? écrit page 44 :




PS: Je vois que fsmrel passe en ce moment sur le sujet. Il viendra certainement mettre les points sur les i.

-J'espère, car il n'y a plus que lui, dans les viennent ensuite chronologiques!

-J'ai un rendez-vous, à dans 30 minutes.

[Oppenheimer]

Bonsoir à vous trois,


Je découvre cette discussion entamée par Oppenheimer. Au fil des ans, le sujet abordé revient régulièrement sur le tapis, tel le serpent de mer....

-Vraiment ? J'espère que ce n'est pas entièrement de ma faute! (Bine qu'ayant une bonne mémoire à long terme, j'ai une mémoire à moyen terme chancellante). Un sujet récurrent qui revient une fois par année, c'est encore correct.

S'agit-il de gens si démoniaques, ou serait-ce peut-être parce que des personnes ont réalisé que la clé choisie, primaire, identifiant, devait être en adéquation avec la sémantique, sans quoi sa vertu d'identifiant devenait cadique ?

Hello vaillant Oishiiii ! Toujours les bons réflexes ! C’est effectivement un strict problème de modélisation.

Si c'est écrit, c'est donc vrai. Je vois donc même quatre points sur les i.

Hello fidèle commandant ! Là encore c’est très clair, nous menons le même combat. Le SIREN est un point d’entrée dans la base de données pour l’utilisateur, et son instabilité interdit qu’on en fasse une clé primaire.


@ Oppenheimer : à ce propos, avez-vous lu mon billet traitant de l’invariance des clés primaires ?

-Parlez y-vous de corps au sens mathématique, ou au sens commun ?
Okay, je vois 2 problèmes pratiques:
-Trop de mises à jour (si beaucoup de tables), et le gérant lambda qui ne doit pas accéder à certaines informations au cas où il accède à la clé, (ce qu'on empêche déjà, par précaution).

Mais mon problème est théorique.

Certes, mais on est là dans la soute, et même avec les processeurs d’il y a quarante ans (IBM 308x, Burroughs 68xx, etc.) on ne perdrait pas trop de temps. Il faut aussi tenir compte de l’encombrement en mémoire du SIREN et (surtout) de la hauteur de l’arbre correspondant à l’index utilisé pour les accès.


Exemple (IBM DB2 V8). Prenons le cas d’une table ENTREPRISE, dotée d’une clé primaire artificielle et d’une clé alternative, en l’occurrence le SIREN et le résultat des calculs effectués par DB2 Estimator.

Cas de l’index associé à la clé primaire (4 octets) :





Cas du SIREN (type DECIMAL(9), soit 5 octets) :





Variante du SIREN (type CHAR(9), soit 9 octets) :





Bon, y a pas l’feu au Lac ! D’accord, dans le cas CHAR(9), le nombre de pages (4K chacune) est en accroissement, mais la hauteur de l’arbre reste égale à 3, ce qui fait que le nombre d’entrées/sorties pour accéder aux données de la table cible est le même dans tous les cas.

Bien entendu, on prendrait la raison sociale pour la clé primaire, la normalisation ne serait évidemment pas perturbée, mais les performances le seraient, car la hauteur de l’arbre passe à 4 :







Qu’entendez-vous par nature de la clé ?

-La même chose que dans "naturelle", terme que j'ai employé plusieurs fois, et donc que dans son contraire, à savoir: le fait que le sens soit intrinsèque ou non-intrinsèque.

Quoi qu’il en soit, la normalisation dit que chaque sous-ensemble K (non strict) de noms d’attributs de l’en-tête d’une relvar (variable relationnelle) R est seulement astreint à respecter les contraintes suivantes :

Unicité. Deux tuples distincts de R ne peuvent avoir même valeur de K.

Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Dans ces conditions, K est un ensemble ayant pour éléments chacun des (noms d’) attributs de l’en-tête de R. Autrement dit, si F est l’ensemble des dépendances fonctionnelles de R, la fermeture K⁺ de K par rapport à F doit être égale à la fermeture F⁺ de l’ensemble F :

K⁺ = F⁺

Incidemment, si par nature de la clé, vous voulez dire « primaire » ou « alternative », je rappelle que du point de vue de la théorie relationnelle, ces qualificatifs sont obsolètes, ils ont été évacués de la théorie il y a près de 20 ans. Je cite C.J. Date dans An Introduction to Database Systems, Seventh Edition, ouvrage paru en 2000 :

« [...] it is possible for a given relvar to have more than one candidate key. In such a case, the relational model has historically required—at least in the case of base relvars—that exactly one of those keys be chosen as the primary key, and the others are then called alternate keys. »

Ou encore, dans les éditions successives de SQL and Relational Theory :

« [...] wheter some key is chosen as primary, and if so which one, are essentially psychological issues, beyond the purview of the relational model as such. »

En remontant à 1993, voyez l’article paru dans InfoDB 7, No. 3 (Summer 1993) et repris dans Relational Database, Writings 1991-1994 au chapitre 2 « The Primacy of Primary keys: An Investigation » :

« The final point was an appeal to Occam’s Razor (“no unnecessary concepts”). In effect, I was arguing that to treat all candidate keys as equals was to complicate the addressing scheme unnecessarily. But it might well be argued that Occam’s Razor applies the other way around, and that is the concepts of primary and alternate key that are unnecessary!—i.e., all we really need is candidate keys. »

J'avoue que de devoir choisir une clé primaire parmi les candidates est quelque chose de troublant, comme C. J. Date que vous citez, lorsqu'on y a affaire au début, ou alors en tant que théoricien.

Par contre, je trouve qu'il va trop loin dans la partie de 1993, à moins qu'il eût mis le "s" terminal en trop. Je suis d'accord qu'une seule clé candidate suffit, sans quoi elle n'est plus une clé candidate. Si c'est ce que Date a voulu dire, je salue son geste.

Et dans cet article, C.J. Date fait référence à ses écrits de 1984, dans lesquels il évoquait déjà la possibilité d’évacuer la distinction PK:AK alors que la reine des clés était Miss Clé Primaire, régnant sans partage sur ses dauphines, les clés alternatives, auxquelles il était interdit, par privilège royal, à la moindre clé étrangère de pouvoir s’adresser.

En gros, la clé candidate devenant primaire, étant utilisée par des relations, les redondance des clé n'avaient aucune valeur, comme je le mentionne plus haut.

Si fait ! Tout ce que vous avez écrit est frappé au coin du bon sens, donc je ne commenterai pas, d’autant que nous disons les même choses .

Non, ne commentez pas, la première place vous revient!

Oishiiii a tout dit. Notamment : « La définition se base sur chaque clé de la relation. Il peut y en avoir plusieurs ». De votre côté, vous faites mention de « la clé », ce qui ne fonctionne pas..

Vous croyez réellement que je m'amuse à des ambivalences ? Primaire est mentionnée dès le titre. Si j'ai mentionné "la", c'est parce que j'ai précisé "primaire" dans tout le reste de mon texte. Si j'avais voulu changer de contexte pour "candidate", je l'aurais fait. Je ne suis quand-même pas né de la dernière pluie.

Par contre Oishiiii a oublié de préciser "chaque clé candidate", mais ça semble vous avoir échappé.

Par contre, vous devriez changer "dépendance complète" pour "a complètement une dépendance" (j'ai mis à jour mon précédent message), et ça change tout le sens! Et ce n'est pas la première fois que vous faites ce genre de raccourici. (La dernière fois était sur la 6NF, où vous aviez concaténé différentes négations en une seule chose affirmée).

[Oishiiii]

Bonjour Oppenheimer,

Je ne vais pas commenter vos réponses.
J'ai l'impression que l'on n'a pas la même définition des termes clés (sans jeu de mots) de la discussion.
Dans ces conditions on n'a pas fini de se renvoyer la balle.

Quoiqu'il en soit, quelle est votre position maintenant par rapport à votre premier message dans ce sujet ?
Est-ce que vous avez trouvé réponse à votre question, s'il y en avait une ?

[Oppenheimer]

Bonjour Oishiiii,

Merci pour votre réponse, et de me permettre de donner mon point de vue éventuellement nouveau.

-Je comprends qu'une clé primaire naturelle peut poser des problèmes pratiques; en particulier lorsque l'on fait gérer la base à des personnes non soumises au secret professionnel, ou pour tout autre fin d'objectivité (études statistiques?), auquel cas l'accès à une clé sémantique est non-désiré.

Situation actuelle, et initiale (mais non précisé à l'origine) :

Mon problème est théorique, (d'autant qu'on est dans schématisation (pour les SGBD)); comprenons en outre que je pense plus particulièrement au modèle logique (MLD), (non précisé au départ).


Enfin, j'ai trouvé une expression plus spécifique de la 2NF (je crois que j'avais donné celle pour 3 NF - mon document de formes normales est sur ma partition Mac, et j'écris ici sous Windows, pour un problème de souris); voici ce que j'ai trouvé (mais je ne retrouve pas sa référence; normalement, je les mets toutes, mais le document n'est pas finalisé). Il se peut que j'aie inféré cette expression à partir d'un contre-exemple rectifié en exemple:

2NF (à confirmer):

1. 1NF, et
2. aucun attribut secondaire n'est dépendant d'un sous-jeu propre de la clé.

ce qui signifie qu'une clé (à ce stade: candidate), ne peut être contenue dans une autre.

Je n'ai pas révisé toutes les formes normales. Il se peut que le problème de transitivité soit exposé dans 3NF (au vu de l'exemple, de mémoire, je dirais celle-ci, mais je confirmerai ou infirmerai).

Merci encore.

[fsmrel]

Bonjour,


En réponse à votre message de ce jour, à 13h02 (post #10).

la traduction est erronée: être en dépendance totale ne veut pas dire grand-chose, sinon que qu'on aurait répertorié tous les types de dépendances possibles, et que ces attributs (que j'appelle secondaires) devraient avoir à chaque fois tous les types de dépendance...

Votre citation ne fait pas référence au message que j’ai produit dans cette discussion, mais manifestement vous faites allusion à une définition que j’ai donnée dans un article sur la normalisation :

« Rappelons qu'une dépendance fonctionnelle est totale (ou irréductible à gauche ou élémentaire) si elle n'est ni triviale ni partielle (cf. paragraphe 3.2.2). »

Maintenant, si vous préférez utiliser l’un des synonymes de dépendance fonctionnelle totale (irréductible à gauche ou élémentaire), ou le qualificatif « pleine et entière », faites-le.

Je ne sais pas si vous l'avez fait exprès, mais vous avez écrit "chaque clé" en oubliant de préciser que c'étaient des candidates.

Les termes « clé » et « clé candidate » sont synonymes, voyez la définition que je donne de la clé candidate et qui n’est que la traduction de la définition donnée dans l’ouvrage de référence Databases, Types, and the Relational Model, The Third Manifesto (téléchargeable). Je vous renvoie aussi aux différents écrits de C.J. Date, par exemple à son dictionnaire :

« K is a candidate key (key for short) for, or of, R... »

Voyez encore ici :

« A key attribute for relvar R is an attribute of R that’s part of at least one key of R. »

Il n’y a donc pas d’oubli de ma part, tout au plus une ellpise, et je ne serai pas plus royaliste que le roi. Clé est synonyme de clé candidate, fermez le ban.

je parle bien de clé primaire

Je rappelle que la notion de clé primaire a été passée au fil du rasoir d’Occam, évacuée du modèle relationnel de données, voyez mon précédent message. On n’utile donc la notion de clé primaire qu’en SQL (et langages du même tonneau). Au niveau théorique, c’est fini, on ne parle plus de clé primaire qu’à titre historique, alors que dans les années septante, huitante, la clé primaire régnait sans partage dans les écrits de Codd, Date et compagnie.

Quoi qu’il en soit, quand vous employez l’expression « redondance de clé primaire », il s’agit d’un oxymore.

À mon sens, la définition de clé primaire est bien ce qui identifie.

Au sens du modèle relationnel de données, vous pouvez remplacer par « Informellement, la clé candidate (ou clé pour abréger) est un identifiant »

Il n'y a pas de notion "d'identification" ou "d'identifiant".

-Vraiment ? -Qu'il n'y ait pas ces appellations, soit, mais qu'il n'y ait pas ces notions, j'en doute!

Oishiiii se situe dans le contexte du modèle relationnel de données et pas dans celui, par exemple, du formalisme Merise, où l’on parle effectivement d’identifiant et pas de clé.

Ainsi, le terme identifier (identifiant) ne fait pas l’objet d’une entrée dans le dictionnaire relationnel, pas plus que dans l’ouvrage de référence Databases, Types, and the Relational Model, The Third Manifesto (débarrassé de son index, mais voyez ce qu’il y est écrit à propos du terme identifier).

En réponse, je n'ai pas encore consulté le lien, mais je l'admets. Ce qui ne semble pas invalider les clés primaire gérées manuellement ?

D’un point de vue pratique, bien des applications en production ont fini par boire le bouillon parce qu’elle n’ont pas respecté la « règle d’or » de Tabourier. Après plus de 40 ans passés à auditer, venir au secours des base de données de bien des grandes entreprises françaises, je confirme ce qu’a écrit Tabourier (et participé d’une main de fer à la refonte des applications peccamineuses...)

dans les viennent ensuite chronologiques!

Plaît-il ?

[Oppenheimer]

Voilà, j'ai vérifié.

Effectivement, l'aspect de dépendance non transitive est exposé en 3NF, relativement à toute super-clé. Donc, un attribut secondaire, comme je l'appelle, (n'appartenant pas à la clé), ne peut pas être dépendant d'un autre attribut secondaire (étant donné que l'aspect doit être évalué pour toute super-clé), hormis bien-sûr la super-clé constituée d'une clé candidate et de l'attribut secondaire considéré (le premier des deux sus-cité), auquel cas il y a une dépendance directe. (Selon ma compréhension).

On peut bien stocker une seule clé primaire dès le modèle logique, ce qui est valable pour le MCD doit l'être pour le MLD, (quant aux restrictions). Mais je expose une proposition, si le SIREN ou le SIRET, pour reprendre un des exemples, n'est pas une clé primaire, on a deux options:

• Soit on est le plus restrictif possible, et ce que je comprends de 3NF (qui invoque des clés conceptuelles (en l'occurrence: toute super-)) doit être appliqué dès le modèle logique - auquel cas l'ajout d'un "ID" automatique en plus du SIRET n'est pas autorisé; (doublon de ce que j'appelle l'identifiant);
• Soit on prend Codd, Date & al au mot, et l'on jette à la poubelle ce qu'on a compris pour les clés "conceptuelles" une fois arrivé au stade logique.

La question posée ainsi peut être une question de normalisation - terme très ambigu (la normalisation n'est pas une forme normale, surtout pas nécessairement la 6NF) - ou alors, aucune question n'engage la normalisation, à moins de générer une nouvelle forme normale!

Comme j'ai tourné ma question, vous devinez ma préférence.

J'insiste sur le fait qu'il s'agirait d'une question théorique, gestion dans Access, DB 2, ou même au sein d'une banque ou d'une fédération de celles-ci n'étant pas dans le sujet.

Appelez ça une question de modélisation si cela vous fait plaisir, je cherche une confirmation ou une infirmation.

Le truc qui risque le plus de contre-indiquer ma proposition en cette date, est une exemple de mes propres soins; le cas d'école d'une bibliothèque:
Vu qu'un prêt peut être rendu en plusieurs fois, j'ai distingué plusieurs retours par prêt dans Access (que j'invoque malgré ce qui précède, en partant du principe que ce qui est valable dans le logique, l'est dans le modèle physique), mais en attribut des retours figurent deux valeurs essentielles: retourPrevu, et retourEffectif (étant donné qu'il peut y avoir des retards et des retours anticipés; ce sera même le plus courant d'avoir deux valeurs non égales).

Cette base de prêts de livres peut être consultée par clé par tout gérant y oeuvrant, (les livres n'étant pas confidentiels, et les personnes devant pouvoir être trouvées selon des attributs les plus officiels).

retourEffectif est un attribut nécessaire, et pourtant, je ne peux pas le prévoir (cf. "bases de données prévisionnelles" sur Google, pour quelques bons gags). Par conséquent, en tel cas, ma proposition ne peut être nécessaire en terme de complétude d'information, même si elle pouvait être suffisante en terme de normalisation.

Du coup, on peut se poser la question suivante:
Existe-t-il des bases de données qui ne font qu'enregistrer des trucs, (sans attribut du type retourEffectif) ? (je pense à des bases-historiques).

[Oppenheimer]

Merci Fsmrel pour votre réponse.

Je soupe un peu tôt, mais verrai cela dès que possible.

[Oppenheimer]

Merci Fsmrel,

Parfois, on vous attends, ensuite, et bien, on vous retrouve! Ca fait plaisir.

Bonjour,


En réponse à votre message de ce jour, à 13h02 (post #10).





Votre citation ne fait pas référence au message que j’ai produit dans cette discussion, mais manifestement vous faites allusion à une définition que j’ai donnée dans un article sur la normalisation :

« Rappelons qu'une dépendance fonctionnelle est totale (ou irréductible à gauche ou élémentaire) si elle n'est ni triviale ni partielle (cf. paragraphe 3.2.2). »

Maintenant, si vous préférez utiliser l’un des synonymes de dépendance fonctionnelle totale (irréductible à gauche ou élémentaire), ou le qualificatif « pleine et entière », faites-le.?

Absolument! Ca ne fait pas référence à un message que vous avez produit ici (si je vous ai cité, il est juste marqué: "a écrit"), mais je ne retrouve pas ma citation dans mon post de 13H02.

Les termes « clé » et « clé candidate » sont synonymes, voyez la définition que je donne de la clé candidate et qui n’est que la traduction de la définition donnée dans l’ouvrage de référence Databases, Types, and the Relational Model, The Third Manifesto (téléchargeable). Je vous renvoie aussi aux différents écrits de C.J. Date, par exemple à son dictionnaire :

« K is a candidate key (key for short) for, or of, R... »

Voyez encore ici :

« A key attribute for relvar R is an attribute of R that’s part of at least one key of R. »

Il n’y a donc pas d’oubli de ma part, tout au plus une ellpise, et je ne serai pas plus royaliste que le roi. Clé est synonyme de clé candidate, fermez le ban.

Je croyais que c'était Codd, qui avait instauré la notion de clé, dans la 2NF, (mais je peux me tromper). À vrai dire, je ne m'intéresse qu'aux sources d'origine; si des gens ont voulu se rendre intéressants en ajoutant ou en enlevant un mot, très peu pour moi.

Toutefois, dans le cas occurrent (clé), je l'admets: Oshiiiiii aurait eu raison de mentionner clé tout court... s'il n'y avait eu de risque de confusion, ce qui n'était pas le cas - étant donné tantôt que la question fut posée, tantôt parce que de mon côté, j'ai mentionné les clés primaires, depuis le titre, alors que lui voulait mentionner les candidates.

-Je reconnais que - hors contexte - étant donné que toutes les clés candidates ont la même vertu (pour ne pas dire valeur), il suffit de mentionner clé, sauf si l'on considère des extensions (comme en 3NF).

Je rappelle que la notion de clé primaire a été passée au fil du rasoir d’Occam, évacuée du modèle relationnel de données, voyez mon précédent message. On n’utile donc la notion de clé primaire qu’en SQL (et langages du même tonneau). Au niveau théorique, c’est fini, on ne parle plus de clé primaire qu’à titre historique, alors que dans les années septante, huitante, la clé primaire régnait sans partage dans les écrits de Codd, Date et compagnie.

Ah oui, le rasoir d'Occam, ça me dit quelque chose.

Codd et Date ont laissé une trace plus marquante dans l'histoire que Occam, je le crains!

Afin d'éviter d'autre confusions, on nous a enseigné ainsi, (en 2010, en apprentissage):
Clé(s) (candidate(s)) dans le MCD, clé primaire dans le MLD. Ce n'était donc pas pour vous induire en erreur que j'ai agit ainsi, mais parce que je l'ai appris.

Quoi qu’il en soit, quand vous employez l’expression « redondance de clé primaire », il s’agit d’un oxymore.

Oxymore est un terme pour dire contradiction de manière courtoise, si ce n'est que ma phrase a été tronquée de son contexte. Une bonne pratique est de ne citer que des phrases complètes; avec des phrases tronquées, on peut dire tout et son contraire, la méthode est aisée. Je vais donc devoir repêcher cette phrase!..

Voilà:
"Peut-être que je n'ai pas écrit dans le cadre d'une forme normale particulière, mais même si j'expose réellement un problème de modèle, alors je parle bien de clé primaire - et vous avouerez qu'une redondance de clé primaire est inutile, comme n'importe quelle autre redondance, j'espère ?

-Vous me direz que le système de peut pas gérer plusieurs clés primaires... La définition de la clé primaire est-elle effectuée par le système? -Non, faute de quoi les différents système auraient le plus probablement différentes définitions, ce qui rendrait imports et export le plus probablement impossibles."

À ce stade je n'avais pas encore précisé que je considérais le Modèle Logique, qui est le plus souvent un modèle papier. Si vous considérez le support papier comme une élément non pertinent, alors restez au modèle conceptuel, avec sa normalisation. Le fait d'avoir plusieurs "clés" est in-intéressant, comme l'ont confirmé de hauts théoriciens.

-Ce que je voulais mentionner par là, est qu'avoir un attribut identifiant en plus de la clé primaire donnait l'équivalent des dépendances transitives contre-indiquées pour 3NF.

Je crois savoir que l'approche du monde des données selon Merise, suit une cascade, même si c'est une méthode déconseillée de nos jours, pour d'autres plans. Elle signifie que le MCD contient déjà toute l'information désirée pour le MLD, et le MLD pour le MPD. Selon cette vision - d'un point de vue théorique - il n'y a pas lieu de ré-itérer les erreurs que l'on avait voulu éviter dans le MCD.

Au sens du modèle relationnel de données, vous pouvez remplacer par « Informellement, la clé candidate (ou clé pour abréger) est un identifiant »

Avec des incréments gérés par le système, l'on comprend le côté informel; avec des clés primaires naturelles, l'on comprend le côté identifiant. Restait plus qu'à élaguer la clé candidate de son qualificatif, chose suivie par des clés auto-gérées, pour faire croire que ces clés avaient quelconque vertu d'identification.
-Explication; rien ne m'empêche d'avoir ceci:

Code :

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

1
2
3
4
5
K|char(1)
----------
1 | a
2 | a

-On peut faire de la logique informelle:
http://www.amazon.fr/Argumenter-Cour...que+informelle
mais une relation aussi élémentaire qu'une identification mène sur du vrai, ou sur du faux; aucun côté informel possible, selon moi.

Si vous voulez mon humble avis, cela fait partie du "Mainstream misdirection"; je savais que ça existait en physique, mais pas pour l'identification.

Oishiiii se situe dans le contexte du modèle relationnel de données et pas dans celui, par exemple, du formalisme Merise, où l’on parle effectivement d’identifiant et pas de clé.

En êtes-vous sûr? -Relisez le message de 13H46, qui est celui que vous avez voulu citer.

Ainsi, le terme identifier (identifiant) ne fait pas l’objet d’une entrée dans le dictionnaire relationnel, pas plus que dans l’ouvrage de référence Databases, Types, and the Relational Model, The Third Manifesto (débarrassé de son index, mais voyez ce qu’il y est écrit à propos du terme identifier).

Je verrai ça, alors.

D’un point de vue pratique, bien des applications en production ont fini par boire le bouillon parce qu’elle n’ont pas respecté la « règle d’or » de Tabourier. Après plus de 40 ans passés à auditer, venir au secours des base de données de bien des grandes entreprises françaises, je confirme ce qu’a écrit Tabourier (et participé d’une main de fer à la refonte des applications peccamineuses...)




Plaît-il ?

Ah, oui, et selon la mémoire que j'ai de Audibert, 75% des projets ont été plantés par manque de cahier des charges; j'espère que c'est dedans! mais je verrai.

[Oppenheimer]

Résolu par le post No 16, (un contre-exemple qui m'était passé sous le nez), mais je suis ouvert à continuer la discussion.

[Oishiiii]

Bonjour,

Effectivement, l'aspect de dépendance non transitive est exposé en 3NF, relativement à toute super-clé. Donc, un attribut secondaire, comme je l'appelle, (n'appartenant pas à la clé), ne peut pas être dépendant d'un autre attribut secondaire (étant donné que l'aspect doit être évalué pour toute super-clé), hormis bien-sûr la super-clé constituée d'une clé candidate et de l'attribut secondaire considéré (le premier des deux sus-cité), auquel cas il y a une dépendance directe. (Selon ma compréhension).

On peut bien stocker une seule clé primaire dès le modèle logique, ce qui est valable pour le MCD doit l'être pour le MLD, (quant aux restrictions). Mais je expose une proposition, si le SIREN ou le SIRET, pour reprendre un des exemples, n'est pas une clé primaire, on a deux options:

• Soit on est le plus restrictif possible, et ce que je comprends de 3NF (qui invoque des clés conceptuelles (en l'occurrence: toute super-)) doit être appliqué dès le modèle logique - auquel cas l'ajout d'un "ID" automatique en plus du SIRET n'est pas autorisé; (doublon de ce que j'appelle l'identifiant);
• Soit on prend Codd, Date & al au mot, et l'on jette à la poubelle ce qu'on a compris pour les clés "conceptuelles" une fois arrivé au stade logique.

Faisons pragmatique

Soit les 2 tables ci-dessous.
Clé primaire en gras.
Chaque clé (chaque clé candidate) est soulignée. Il y en a plusieurs par table.

Code :

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

1
2
3
4
5
6
7
SIRET        NOM                     Localisation
-----------------------------------------------------
QWE          Soylent Green           USA
ERT          The Daily Planet        Metropolis
TZU          Umbrella Corporation    USA
UIO          Wayne Enterprises       Gotham City

Code :

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

1
2
3
4
5
6
ID       SIRET        NOM                     Localisation
---------------------------------------------------------------
1        QWE          Soylent Green           USA
2        ERT          The Daily Planet        Metropolis
3        TZU          Umbrella Corporation    USA
4        UIO          Wayne Enterprises       Gotham City

Dans la deuxième table, il y a peut-être "doublon de ce que vous appelez l'identifiant", je ne sais pas ce que ça veux dire..
Mais les deux sont en 3NF !

La question posée ainsi peut être une question de normalisation - terme très ambigu (la normalisation n'est pas une forme normale, surtout pas nécessairement la 6NF) - ou alors, aucune question n'engage la normalisation, à moins de générer une nouvelle forme normale!

Le terme normalisation n'a rien d'ambigu.
C'est la procédure par laquelle une table (d'une certaine forme normale) sujette à certaines complications (de la redondance de données, des anomalie de mises à jours), va être décomposée en plusieurs tables, d'une forme normale plus élevée.
Plus la forme normale respectée par la table est élevée, plus le risque de ces complications diminue.
Cette procédure est basée sur des théorèmes, ce n'est pas sujet à discussion. Lisez l'article d'fsmrel.

Je n'ai pas saisi la suite du message sur retourEffectif, etc..