Discussion :

[pfortin]

Avec un GUID, le risque n'est pas nul d'avoir deux fois le même non ?
Alors qu'avec un auto-incrément, c'est certain !

Dans l'absolu, le risque n'est pas exactement nul mais c'est bien le but recherché.
Dans un contexte transactionnel classique, un autoincrement crée un 'point chaud' gênant mais éventuellement vivable.
Quand il s'agit de réplication non trivial (pas snapshot), les conflits sont systématiques et insolubles.

Il me semble avoir déjà vu un débat quelque part sur notre forum entre les partisans de l'auto-incrément et les partisans d'un GUID ou autre du même genre.
Et je crois me souvenir que SQLPro avait pointé avec sa vigueur habituelle le fait qu'un GUID était plus gourmand et moins performant qu'un entier auto-incrémenté sur les gros volumes de données.

En effet, j'ai aussi lu cet article qui, non content d'enfoncer des portes ouvertes, oublie magistralement les incomparables autres atouts des GUID.
Je rends hommage au savoir de SQLPro mais son manque de nuances dans cet article me fut personnellement dommageable (modérément).

Pour autant, quand le lis dans l’ouvrage de référence [1], au paragraphe 5.7.3 « Règles de passage du modèle conceptuel des données au modèle logique dans une représentation relationnelle » :

Les individus sont transformés en relations au sens relationnel, l’identifiant de l’individu devient la clé primaire de la relation.

Si je vous suis, alors ce que dit [1] et trop simple et doit être remplacé par quelque chose ressemblant à ceci :

Les individus sont transformés en relations au sens relationnel. S’il est artificiel, l’identifiant d’un individu devient la clé primaire de la relation, sinon (s’il est naturel), alors il devient clé alternative, la définition et la mise en œuvre de la clé primaire restant à la charge du DBA.

Votre avis ? (On admettra que, comme c’est souvent le cas, les concepteurs ne son plus là et ne binômeront donc pas avec les DBA).
[1] Hubert Tardieu, Arnold Rochfeld, René Colletti. La méthode Merise, Tome 1 : Principes et outils (Les Éditions d’organisation, réimpression de juin 1991).

Oserai-je vous demandez d'en faire une nouvelle discussion dédiée (à la façon de MacFly58 ici) ?
J'ai longuement tenté de le faire aujourd'hui mais j'ai tout jeté faute d'avoir trouvé par quel bout prendre ce vaste sujet.

[fsmrel]

Je vous accorde que l'artifice technique m'embrouille quelque peu mais la frontière est ténue entre
- Une opération comporte plusieurs détails ({OperId, DetailId})
et
- Un détail [d'opération] fait référence à une et une seule opération {DetailId} → {OperId}

Considérer Detail :
- soit comme une entité faible identifiée relativement à opération
- soit comme une entité identifiée techniquement mais uniquement avec DetailId et traiter OperId comme un attribut non-identifiant issu de la relation
me semble non pas équivalent, mais tout de même très proche.
En l'espèce, je pense qu'il s'agir surtout d'art de modéliser.

Sémantiquement parlant, je considère qu’un détail d’opération est une propriété multivaluée de l’opération, tout comme la ligne de facture est une propriété de la facture : si vous supprimez une opération, les détails disparaissent avec. Du point de vue technique de modélisation, si j’utilise le modèle de Chen, je traduirai le détail d’opération par une entité-type faible (weak entity), si j’utilise RM/T de Codd, je traduirai cela par une caractéristique (characteristic), si j’utilise un AGL, je me servirai de l’identification relative, si j’utilise Tutorial D, j’utiliserai peut-être une RVA (Relation-Valued Attribute), DetailOper devenant alors une propriété d’Operation (propriété de type RELATION), etc.

La sémantique et la modélisation sont en phase. En revanche, si on identifie DetailOper de manière absolue, on donne l’impression de marquer sa volonté de considérer que la relation entre Operation et DetailOper change de nature, DetailOper n’étant plus une propriété d’Operation, mais devenant son alter ego. Au sens de Chen, DetailOper prendrait le statut d’entité-type forte (Regular Entity), idem chez Codd (Kernel), on n’utilisera pas de RVA, etc. La sémantique et la modélisation ne sont plus en phase.

Cela dit, vous avez raison d’évoquer l’art de la modélisation, mais je persiste en disant que la technique utilisée concrètement pour valoriser la clé {OperId, DetailId} ne doit pas remettre en cause la structure de celle-ci.

Personne ne m'a jamais fais le coup avec un GUID (ou UUID).
On m'a même reproché récemment qu'ils soient illisibles dans Firebird...

Par référence à

Que les valeurs prises par l’attribut DetailId diffèrent selon la technique, pas de problème puisque cet attribut ne concerne pas l’utilisateur. S’il a besoin de numéroter ses détails, on lui définira un attribut as-hoc et l'on pourra se servir de la technique du « MAX + 1 ».

Je dirais que l’utilisateur (comme le développeur) n’a aucune raison de vous reprocher que les valeurs soient illisibles puisqu'elles lui sont cachées. S’il veut visualiser ses détails, on passera par une requête dont le résultat n’affichera que les attributs naturels (dont DetailNumero, l'attribut ad-hoc qui fait l'objet d'un MAX + 1) :

Code SQL :

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

1
2
3
4
SELECT  b.OperNumero, a.DetailNumero, a.DetailMontant, a.DetailNote, c.CategNom 
FROM    DetailOper As a 
        INNER JOIN Operation AS b ON a.OperId = b.OperId
        INNER JOIN CategorieNoeud AS c ON a.CategId = c.CategNoeudId ;

Code :

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

1
2
3
4
5
6
7
8
OperNumero  DetailNumero  DetailMontant  DetailNote  CategNom
----------  ------------  -------------  ----------  --------
      1000             1           -100  blabla      Pharmacie non remboursée
      1000             2            -75              Livres
      2000             1            -50              Pharmacie non remboursée
      2000             2            -20              Livres
      2000             3            -30              Jardinage
      2000             4            -70              Alimentation

Oserai-je vous demandez d'en faire une nouvelle discussion dédiée (à la façon de MacFly58 ici) ?

Osez, mais j'ai pas mal de fers au feu et il y a beaucoup à dire : je ne le ferai pas avant l'année prochaine (si j'ai le courage de m'y lancer)...

[pfortin]

Sémantiquement parlant, je considère qu’un détail d’opération est une propriété multivaluée de l’opération, tout comme la ligne de facture est une propriété de la facture : si vous supprimez une opération, les détails disparaissent avec.
...
Cela dit, vous avez raison d’évoquer l’art de la modélisation, mais je persiste en disant que la technique utilisée concrètement pour valoriser la clé {OperId, DetailId} ne doit pas remettre en cause la structure de celle-ci.

Le critère de suppression est clair et précis, exactement ce qu'il me manquait.
Vous avez brillamment tranché le débat. Je m'incline respectueusement.

Du point de vue technique de modélisation, si j’utilise le modèle de Chen, je traduirai le détail d’opération par une entité-type faible (weak entity), si j’utilise RM/T de Codd, je traduirai cela par une caractéristique (characteristic), si j’utilise un AGL, je me servirai de l’identification relative, si j’utilise Tutorial D, j’utiliserai peut-être une RVA (Relation-Valued Attribute), DetailOper devenant alors une propriété d’Operation (propriété de type RELATION), etc.

Encore des liens passionnants ! Je viens d'y découvrir l'association-type faible.

Je dirais que l’utilisateur (comme le développeur) n’a aucune raison de vous reprocher que les valeurs soient illisibles puisqu'elles lui sont cachées.

On est bien d'accord mais allez empêcher un développeur qui en a les droits de faire un

Code :

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

SELECT * FROM table

Osez, mais j'ai pas mal de fers au feu et il y a beaucoup à dire : je ne le ferai pas avant l'année prochaine (si j'ai le courage de m'y lancer)...

Tant pis, je comprends parfaitement. J'ai juste tenté le coup. Je m'y collerai prochainement.
Merci pour toutes vos nombreuses interventions qui ne manquent jamais d'être d'une excellente qualité et très documentées.

[fsmrel]

Je dirais que l’utilisateur (comme le développeur) n’a aucune raison de vous reprocher que les valeurs soient illisibles puisqu'elles lui sont cachées.

On est bien d'accord mais allez empêcher un développeur qui en a les droits de faire un

Code :

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

SELECT * FROM table

On ne l’en empêchera évidemment pas, et s’il se sent frustré, ça ne le gênera pas pour autant dans son travail puisqu’il dispose de tous les attributs nécessaires et suffisants pour faire ce qu’il a à faire. Comme je l’ai dit, il ne pourra pas vous tenir grief que le contenu des identifiants artificiels soit incompréhensible. Consolez-le quand même en lui offrant le café.

[pfortin]

[JPhi33]

Bonjour,

Les individus sont transformés en relations au sens relationnel. S’il est artificiel, l’identifiant d’un individu devient la clé primaire de la relation, sinon (s’il est naturel), alors il devient clé alternative, la définition et la mise en œuvre de la clé primaire restant à la charge du DBA.

Votre avis ? (On admettra que, comme c’est souvent le cas, les concepteurs ne son plus là et ne binômeront donc pas avec les DBA).

Je suis d'accord mais pas de manière aussi systématique. Les identifiants naturels ne sont pas tous à jeter à la poubelle ou, du moins, ne sont pas tous à reléguer au rang de clé alternative. Il existe heureusement de bons identifiants naturels. J'entends par "naturel" un identifiant existant dans la réalité.

Je pense avoir compris de travers le terme "identifiant artificiel". En effet, j'ai cru qu'on parlait uniquement des identifiants "techniques" ajoutés pour identifier proprement une entité et pallier, lorsqu'elle est avérée, la faiblesse d'un identifiant naturel... qui, du coup, n'en serait pas un. L'un des cas d'école est celui du numéro d'immatriculation servant à identifier un véhicule.

L'objectif visé par le concepteur est la modélisation de la réalité (dont le MCD devient une abstraction). Si, dans cette réalité, il existe un N° COMMANDE (pour reprendre l'exemple de TABOURIER) qui est un parfait identifiant, pourquoi en inventer un autre ? Pour moi, son existence dans la réalité justifie pleinement sa présence dans le MCD et, personnellement, je le qualifierai d'identifiant naturel et non pas d'identifiant artificiel (c'est sans doute la source du malentendu évoqué plus haut).

Je note une divergence de point de vue avec TABOURIER. Il considère d'abord l'objet (l'entité) puis le "remplit" de propriétés ; d'où son raisonnement :
- les propriétés doivent décrire l'objet
- l'identifiant ne décrit rien, il est juste là pour identifier (distinguer 2 jumeaux parfait selon ses propres termes)

Je considère d'abord les propriétés et étudie les relations qu'elles entretiennent les unes avec les autres pour en faire émerger les entités. Je rejoins TABOURIER sur le fait que je ne considère pas , moi non plus, que l'identifiant est une propriété particulière ; pour moi, c'est une propriété à part entière issue de l'abstraction de la réalité. La question de savoir si une propriété décrit ou pas l'entité ne se pose donc pas pour moi.

[CinePhil]

Un numéro de commande peut être de type VARCHAR(8) par exemple, donc plus gourmand et moins performant, à partir d'un certain volume, qu'un entier auto-incrémenté qui n'occupe que 4 octets au lieu de 9 pour le VARCHAR(8).
Comme ce numéro de commande sera probablement référencé dans pas mal d'autres tables de la BDD, les opérations de jointure seront plus rapides avec un entier qu'avec un VARCHAR(8).

Je suis cependant partiellement d'accord avec toi mais ton exemple est mal choisi.
Si on est certain que le numéro ou code ne changera jamais et sera toujours d'une taille plus économe que le type entier, alors on peut prendre une clé candidate naturelle comme clé primaire de la table. On peut ainsi considérer que le sexe ne prendra jamais d'autres valeurs que :
- M => Mâle
- F => Femelle
- H => Hermaphrodite
- I => Inconnu
Du moins pour les espèces vivantes terrestres !

Dans le cas contraire, je m'abstiens toujours et j'ajoute une clé artificielle dès le MCD qui sera de type entier auto-incrémenté dans la table.

Attention aux faux amis !
- Il n'y a que 100 départements français dont le numéro fait au maximum 3 caractères mais ces numéros peuvent changer : la Corse portait anciennement le numéro 20 et est aujourd'hui divisée en deux départements numérotés 2A et 2B.
- Un codage des services dans une entreprise peut évoluer en raison d'un rattachement à une autre entreprise ou de la création d'une filiale.
- Idem pour tout codage décidé sur moins de 4 caractères aujourd'hui et qui pourrait évoluer dans l'avenir.

[fsmrel]

Bonjour,

Je suis d'accord mais pas de manière aussi systématique. Les identifiants naturels ne sont pas tous à jeter à la poubelle ou, du moins, ne sont pas tous à reléguer au rang de clé alternative. Il existe heureusement de bons identifiants naturels. J'entends par "naturel" un identifiant existant dans la réalité.

D’accord, il faut que je parle autrement du sort qui sera réservé à l’identifiant, mais je maintiens ce que j’ai dit sur la règle de passage du MCD au MLD, à savoir que ce qui est écrit dans [1] est trop simple :

« l’identifiant de l’individu devient la clé primaire de la relation ».

En effet, dans [1] au paragraphe 4.4.7 « Exemple d’un Bureau des Immatriculations », dans le cas de l’individu-type Voiture, c’est le n° d’immatriculation qui est utilisé pour servir d’identifiant. Mais lorsqu’en tant que DBA je récupère le MLD produit (disons par l’AGL), je passe en revue chaque clé de chaque table et m’assure notamment qu’elle est invariante.

Vu que le n° d’immatriculation respecte les principes d’unicité et d’irréductibilité des clés, il a droit au statut de clé candidate. Mais étant donné qu’il peut très bien être modifié, donc que le système n’en a pas le contrôle, toujours en tant que DBA, je définirai un attribut supplémentaire qui servira pour la clé primaire et dont l’utilisateur n’aura jamais connaissance. Cet attribut ne servira que pour les opérations de jointure (cf. l’exemple de la requête SQL ci-dessus) et le n° d’immatriculation fera l’objet d’une clé alternative.

Il est aussi des situations dans lesquelles un « bon identifiant naturel » deviendra identifiant « alternatif ». Prenons le cas du matricule d’un employé, correctement défini, à savoir invariant et non significatif. Il n’empêche que si l’entité-type EMPLOYE est sous-type de l’entité-type PERSONNE, EMPLOYE héritera de l’identifiant de PERSONNE et, en accord avec la définition donnée par [1], dans le MLD la table EMPLOYE aura pour clé primaire celle de la table PERSONNE. Le matricule de l’employé fera donc l’objet d’une clé alternative pour la table EMPLOYE :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
PERSONNE {PersonneId      INT    NOT NULL,
          PersonneNom     CHAR   NOT NULL,
          ...
    , PRIMARY KEY {PersonneId}
      ...} ;
EMPLOYE {PersonneId      INT    NOT NULL,
         EmpMatricule    INT    NOT NULL,
         ...
    , PRIMARY KEY {PersonneId}
    , UNIQUE {EmpMatricule}                   /* clé alternative */
    , FOREIGN KEY {PersonneId} REFERENCES PERSONNE
      ...} ;

De l’influence des choix techniques sur la structure du MCD

CinePhil n’y va pas avec le dos de la cuiller et je vais essayer d’être plus soft (bien que concrètement je procède comme lui, car je ne vais pas réfléchir pendant des jours quand le MLD produit par l’AGL comporte 1500 tables, quitte à revenir sur quelques cas particuliers sensibles).

Supposons que le DBA procède à une campagne de mesures des performances en même temps que le concepteur conçoit (personnellement je n’attends jamais qu’on me livre un MCD pour commencer ce genre de travail, à moins bien sûr de n’arriver qu’après sa réalisation).

Si, au cours de cette campagne, je constate que l’identifiant (naturel) d’une certaine entité-type E est un facteur de ralentissement des opérations, je demande à ce qu’on en fasse un identifiant alternatif et qu’on définisse un nouvel identifiant destiné à faire l’objet de la clé primaire de la table E dérivée de l’entité-type E. Et je ne vais pas attendre que le concepteur ait bouclé son sujet et soit passé à un autre chantier.

Ainsi, le DBA peut être amené à demander à ce qu’un identifiant respectable et sans histoire tel que le n° de commande fasse l’objet d’une clé alternative. Vous me direz qu’un n° de commande est invariant, qu’il correspond à une propriété naturelle, etc. Je suppose quand même que le numéro de commande a un sens pour l’utilisateur, et si j’utilise un auto-incrément, tout ira bien, la 1re commande passée portera le n° 1, la deuxième le n° 2, la troisième le n° 3, la nième le n° n. Mais l’utilisateur sera-t-il d’accord si la 1re commande porte le n° 314116, la 2e le n° 7, la 3e le numéro 2718281, etc. ? En effet, supposons que mes travaux de prototypage des performances montrent que la production des commandes en mode transactionnel provoque des phénomènes de verrouillage tels que je sois amené à hacher les valeurs de clés primaires (j’ai donné...) : si l’utilisateur tient à conserver la séquence initiale, alors « son » numéro de commande fera l’objet d’une clé alternative.

Supposons maintenant que mes travaux de prototypage des traitements transactionnels montrent que les phénomènes de verrouillage ne se produisent pas : tout va bien, pas besoin de hacher les valeurs prises par le numéro de commande. Mais ce sont maintenant les traitements de type batch qui vont me poser des problèmes. En effet, s’il me faut sortir la liste de tous les clients avec leurs commandes, je risque de connaître des phénomènes d’I/O bound (processeur au chômage technique pour cause d’attente de fin de lecture/écriture sur disque) tels que la Production refusera de valider ma base de données et me demandera de diviser les temps de traitement par trois, dix ou trente (j’ai vu ça : batch quotidien de 240 heures (sic) à ramener à 8 heures). La solution consiste à synchroniser les valeurs de la clé primaire de la table COMMANDE avec celle de la table CLIENT :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CLIENT {CliId      INT    NOT NULL,
        CliNom     CHAR   NOT NULL,
        CliNumero  INT    NOT NULL,
        CliSiret   CHAR   NOT NULL,
        ...
    , PRIMARY KEY {CliId}
    , UNIQUE {CliNumero}
    , UNIQUE {CliSiret}
      ...} ;
COMMANDE {CliId      INT    NOT NULL,
          CdeId      INT    NOT NULL,
          CdeNumero  INT    NOT NULL,
          CdeDate    DATE   NOT NULL,
          ...
    , PRIMARY KEY {CliId, CdeId}
    , UNIQUE {CdeNumero}      /* clé alternative */
    , FOREIGN KEY {CliId} REFERENCES CLIENT}
      ...} ;

Dans cet exemple, toujours pour des raisons de blocage des transactions, on a été amené à doter la table CLIENT d’une clé primaire {CliId} faisant l'objet d'un hachage, tandis que le numéro de client CliNumero a été ravalé au rang de clé alternative. J’ai fait figurer le n° SIRET : si celui-ci suffit à l’utilisateur pour accéder aux données d’un client, l’attribut CliNumero peut disparaître.

En tout état de cause, pour que la dérivation par l’AGL de mes 1500 tables soit conforme, il faut bien se résoudre à modifier le MCD, c'est-à-dire identifier l’entité-type COMMANDE relativement à l’entité-type CLIENT. Le numéro de commande devient alors identifiant alternatif.

Bref, on essaie de « faire simple, mais pas plus simple » et de faire en sorte que les applications fonctionnent comme le veut l'utilisateur (il a payé pour ça). MCD, MLD, MPD, même combat.


[1] Hubert Tardieu, Arnold Rochfeld, René Colletti. La méthode Merise, Tome 1 : Principes et outils (Les Éditions d’organisation, réimpression de juin 1991).

[JPhi33]

Bonsoir à tous,

Mais lorsqu’en tant que DBA je récupère le MLD produit (disons par l’AGL), je passe en revue chaque clé de chaque table et m’assure notamment qu’elle est invariante.
[...]
Mais étant donné qu’il peut très bien être modifié, donc que le système n’en a pas le contrôle, toujours en tant que DBA, je définirai un attribut supplémentaire qui servira pour la clé primaire et dont l’utilisateur n’aura jamais connaissance.

Cette tâche ne devrait pas vous échoir. Le concepteur doit fournir un MCD normalisé. Il doit s'assurer, entre autres, que l'identifiant est normalisé et répond aux 3 conditions de SIBERTIN-BLANC, ce qui n'est pas le cas du n° d'immatriculation pour la raison que vous évoquez.

Il est aussi des situations dans lesquelles un « bon identifiant naturel » deviendra identifiant « alternatif ». Prenons le cas du matricule d’un employé, correctement défini, à savoir invariant et non significatif. Il n’empêche que si l’entité-type EMPLOYE est sous-type de l’entité-type PERSONNE, EMPLOYE héritera de l’identifiant de PERSONNE et, en accord avec la définition donnée par [1], dans le MLD la table EMPLOYE aura pour clé primaire celle de la table PERSONNE. Le matricule de l’employé fera donc l’objet d’une clé alternative pour la table EMPLOYE

Tout à fait d'accord. L'identification d'une entité spécialisée (EMPLOYE) par autre chose que l'identifiant de l'entité généralisée (PERSONNE) est une faute de modélisation. Ici, le concepteur doit revoir sa copie afin de fournir un MCD sans erreur duquel on dérivera un MLD conforme à ce que vous décrivez.

CinePhil n’y va pas avec le dos de la cuiller

Je n'ai pas répondu directement à ses arguments car, là aussi, je suis d'accord avec lui :
- l'exemple du code genre est un cas de bon identifiant. Il le conserve, moi aussi.
- les exemples sous "attention aux faux amis" sont 3 cas d'identifiants contrevenant aux critères d'identification (au moins à celui de stabilité). Pour cette raison, ils doivent être écartés, et ce, dès le MCD.

CinePhil a peut-être oublié ma réponse sur ce même thème il y a un an.

Supposons que le DBA procède à une campagne de mesures des performances en même temps que le concepteur conçoit (personnellement je n’attends jamais qu’on me livre un MCD pour commencer ce genre de travail, à moins bien sûr de n’arriver qu’après sa réalisation).

Evidemment, si la base de donnée est modélisée avant le MCD, autant s'en passer tout de suite et faire l'économie d'un (ou de plusieurs) concepteur(s). Exit le binôme !
Ceci dit, les DBA ne sont pas tous capables de concevoir un modèle relationnel de 1500 tables ; pensez à eux .

Dans cet exemple, toujours pour des raisons de blocage des transactions, on a été amené à doter la table CLIENT d’une clé primaire {CliId} faisant l'objet d'un hachage, tandis que le numéro de client CliNumero a été ravalé au rang de clé alternative. J’ai fait figurer le n° SIRET : si celui-ci suffit à l’utilisateur pour accéder aux données d’un client, l’attribut CliNumero peut disparaître.

En tout état de cause, pour que la dérivation par l’AGL de mes 1500 tables soit conforme, il faut bien se résoudre à modifier le MCD, c'est-à-dire identifier l’entité-type COMMANDE relativement à l’entité-type CLIENT. Le numéro de commande devient alors identifiant alternatif.

Sémantiquement, le numéro de client reste l'identifiant de l'entité CLIENT.
Par contre, en ce qui concerne l'identification relative de la commande par rapport au client, il faut bien se résoudre à modifier le MCD mais cette modification ne me choque pas. Il y a souvent plusieurs solutions de modélisation. Même si, au premier abord, le concepteur ne penche pas vers l'identification relative de la commande par rapport au client, cette solution de modélisation n'est pas farfelue et aurait très bien pu être envisagée dès le départ.

Soyons réalistes, c'est bien la solution de la CIF Commande ---> Client qui sera envisagée par la grande majorité des concepteurs et la modification de MCD a posteriori aura bien lieu.

[fsmrel]

Bonjour,

Mais lorsqu’en tant que DBA je récupère le MLD produit (disons par l’AGL), je passe en revue chaque clé de chaque table et m’assure notamment qu’elle est invariante.
[...]
Mais étant donné qu’il peut très bien être modifié, donc que le système n’en a pas le contrôle, toujours en tant que DBA, je définirai un attribut supplémentaire qui servira pour la clé primaire et dont l’utilisateur n’aura jamais connaissance.

Cette tâche ne devrait pas vous échoir. Le concepteur doit fournir un MCD normalisé. Il doit s'assurer, entre autres, que l'identifiant est normalisé et répond aux 3 conditions de SIBERTIN-BLANC, ce qui n'est pas le cas du n° d'immatriculation pour la raison que vous évoquez.

Je constate simplement que le trio TRC a donné le mauvais exemple en retenant le n° d’immatriculation pour identifier l’entité-type VEHICULE. Si d’éminents spécialistes procèdent ainsi dans leur ouvrage (de référence qui plus est), on peut penser que des concepteurs encore un peu tendres en font autant, d’où ma vigilance de tous les instants.

Par ailleurs, quand je dis que « je définirai un attribut supplémentaire », il est évident que ce n’est moi qui effectuerai cette opération directement dans le MCD, mais le concepteur (ma demande est discutée, soumise à validation et le cas échéant validée, tamponnée par qui de droit lors de la réunion de coordination périodique).

Puisque vous en faites mention, je joins la page 63 de l’article de SIBERTIN-BLANC L'identification des occurrences d'entités dans le formalisme individuel (Journée AFCET, 1990).



A ce propos, concernant la condition C1, qu’entend S-B par « fonction de caractérisation » ? Pourquoi écrit-il « cette fonction n’étant pas nécessairement partout définie ni surjective » ? Je sais ce qu’est une surjection dans le cadre de la théorie des ensembles, mais j’ai du mal à saisir le lien entre la prémisse et sa conclusion « Chaque valeur de l’identifiant caractérise donc une occurrence d’entité (au plus). », plus en rapport avec l’injection.

Idem concernant la condition C3 : pourquoi cette fonction n’est-elle pas bijective ? S’agit-il du coup des jumeaux parfaits ? En tout cas, si je switche dans la théorie relationnelle, celle-ci s’appuyant fondamentalement sur la théorie des ensembles, pour une relation R donnée il y a bijection entre chaque valeur <k> de chaque clé candidate et chaque tuple <t> identifié par <k> (je rappelle qu’il y a bijection (a) parce que <k> fait partie de <t> et (b) parce que NULL est exclu de la théorie relationnelle (un tuple — du moins prétendu tel — où apparaît NULL n’est pas un tuple et donc la relation — du moins prétendue telle — contenant un tel tuple n’est pas une relation)).

Supposons que le DBA procède à une campagne de mesures des performances en même temps que le concepteur conçoit (personnellement je n’attends jamais qu’on me livre un MCD pour commencer ce genre de travail, à moins bien sûr de n’arriver qu’après sa réalisation).

Évidemment, si la base de donnée est modélisée avant le MCD, autant s'en passer tout de suite et faire l'économie d'un (ou de plusieurs) concepteur(s). Exit le binôme !
Ceci dit, les DBA ne sont pas tous capables de concevoir un modèle relationnel de 1500 tables ; pensez à eux
[..]
Soyons réalistes, c'est bien la solution de la CIF Commande ---> Client qui sera envisagée par la grande majorité des concepteurs et la modification de MCD a posteriori aura bien lieu.

Vous ne m’avez pas compris. J’effectue des campagnes de mesures au fur et à mesure que le concepteur progresse dans la réalisation de son MCD. Pour reprendre l’exemple des clients et des commandes, le concepteur construit donc son MCD, mais, sur la base de son travail en cours et avec l’aval de la DSI, je prototype les performances et dans une note officielle rends compte de mes conclusions sur les éventuels scénarios alternatifs de modélisation comparés à la modélisation prévue. C’est au cours d’une de ces réunions périodiques à laquelle participent tous les intéressés que ces conclusions sont présentées, débattues et arbitrées.

Quelle que soit la décision prise par la DSI, je tiens au courant la Production informatique qui saura à son tour à quoi s’en tenir en termes de performances et de volumétrie.

Par ailleurs je ne passe pas les 1500 tables à la moulinette du prototypage, pour la bonne raison que je m’intéresse surtout à la dizaine de transactions et aux batchs déjà réputés les plus sensibles, que les objets impliqués sont connus, alors que les développements seront entrepris bien plus tard. Je fabrique des brouillons de programmes hébergeant les requêtes SQL types, tels que la prise de commande, l’appel des cotisations, etc. et je mesure. Mais, au fil de l’avancement des travaux, je valide néanmoins tous les objets du MCD (je suis mandaté notamment pour cela), lequel est évidemment découpé en domaines (ou référentiels, ou ce que l’on veut, peu importe), chacun avec son équipe projet et ses concepteurs, sinon une chatte n’y retrouverait pas ses chatons.

Bien sûr, il n’est pas dans les attributions du DBA de concevoir un modèle logique des données de 1500 tables ou de dix tables, et je ne joue pas à ce jeu-là (l’idée étant, je dois dire, tout à fait saugrenue). Plus sérieusement, je suis partisan du « Mieux vaut prévenir que guérir » et je dis que l’implication d’un DBA (averti) lors de l’étape de la modélisation conceptuelle peut éviter bien des déboires tels que celui du batch quotidien qui a duré 240 heures lors de sa mise en production (alors qu'aucun test de montée en charge n'avait manifestement été prévu). Quand je coiffe ma casquette de valideur, c'est pour montrer les conséquences en production d’un choix de modélisation par rapport à d’autres, m'assurer de la robustesse de la base de données, de sa pertinence, de sa performance, bref de sa pérennité.