Non, les id n’ont pas leur place dans un MCD
Mais ça ne m’étonne absolument pas que ça soit une croyance aussi répandue. Voici quelques arguments qui, je l’espère, finiront de vous convaincre d’abandonner cette pratique.
Mettre ou pas les id dans un MCD, c’est un peu comme le débat pain au chocolat vs chocolatine : ça ne laisse personne indifférent. Je me pose donc ici en fervent défenseur d’un camp, prêt à asséner de l’argument à la pelle.
L’origine de cet article
À la différence du débat sus-cité sur le nom d’une viennoiserie, c’est un débat technique : il n’y a, selon moi, qu’une seule et unique vérité. L’autre camp s’est simplement créé et développé progressivement sur la base d’incompréhensions, de méconnaissance ou d’interprétation partielle des standards.
C’est, convaincu de cet état de fait mais pas encore d’avoir raison, que je suis parti en quête de preuves, de sources et de témoignages. J’ai lu/visionné des tutoriels, des articles, des thèses même, posé des questions à mes anciens profs, bouquiné l’excellent “Merise, guide pratique” (J-L. Baptiste, éditions ENI), emprunté l’ouvrage de référence “Merise deuxième génération” (D. Nanci, B. Espinasse, édtions Sybex). Bref, je me suis investi.
J’ai même songé à acheter une copie de la norme SQL. Car non, la norme SQL n’est pas disponible gratuitement : elle est maintenue par un groupe de travail de l’ISO, et commercialisée en France par l’intermédiaire de l’AFNOR. En plusieurs parties, parce qu’en un seul volume, ça serait un peu indigeste. Détail curieux, les 3 documents “essentiels” de la norme répondent aux doux noms de ISO/IEC 9075-1:2016 (SQL/Framework), ISO/IEC 9075-2:2016 (SQL/Foundation) et ISO/IEC 9075-11:2016 (SQL/Schemata) et valent respectivement 186€ pour le premier, et 207€ pour les deux autres. Soit un total bien rond de 600 balles. Hors taxes. Je me suis donc débrouillé… autrement (en restant dans la légalité, tout de même).
J’ai trouvé quelques infos contradictoires (sur Merise, pas dans la norme SQL, hein) mais pas tant que ça. Franchement, je m’attendais à pire. Commençons.
L’instant vocabulaire
On parle toujours du MCD en désignant le document schématique regroupant entités et associations avec leurs cardinalités. Mais d’un point de vue purement théorique, la méthode Merise ne définit pas de formalisme de représentation. Elle définit des modèles. Le vrai nom du MCD que tout le monde utilise aujourd’hui et qu’on peut générer via des outils comme Mocodo, c’est un DEA, pour Diagramme Entité-Association. Paradoxalement, on le doit à un chercheur américain nommé Peter Chen (le paradoxe étant que Merise n’a jamais vraiment percé au-delà des frontières françaises).
Mais parce que tout le monde dit MCD, je continuerai d’utiliser ce terme dans le reste de l’article. Évitons de créer d’autres débats clivants. C’est parti pour le premier véritable argument contre la présence des id dans un DEA… pardon, dans un MCD.
L’instant vocabulaire bis
Ceci dit, je devrais peut-être lever une ambiguïté pas si évidente que ça avant de commencer. Parce que défendre une idée claire et précise, c’est toujours beaucoup plus efficace que de défendre un concept flou et sujet à interprétation.
CREATE TABLE animal (
id int GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
name text NOT NULL,
sex sex_enum NOT NULL,
birth_date date NOT NULL,
decease_date date,
species_id int NOT NULL REFERENCES species(id),
mother_id int REFERENCES animal(id),
UNIQUE (name, species_id)
);Quand je parle d’id, je parle de cette colonne qu’on déclare toujours en premier lorsqu’on crée une table en SQL, comme illustré ci-dessus. Cet id regroupe 2 fonctions bien distinctes :
- La fonction de clé primaire : l’id incarne la valeur indivisible qui permet d’identifier à coup sûr chaque enregistrement d’une table.
- La fonction de colonne identité (avant, on appelait ça colonne auto-incrémentée) : l’id est généré automatiquement par le SGBD, on ne lui attribue jamais de valeur manuellement et sa valeur ne peut, théoriquement, pas être connue avant l’insertion de l’enregistrement dans la table. En bref, c’est pas toi qui gères.
Et autant, retrouver un discriminant de MCD en tant que clé primaire d’une table ne me pose pas vraiment de souci (en fait, si, un peu) ; autant, je vois mal comment la colonne identité d’une table peut figurer dans un MCD. Mais nous y reviendrons, retenez simplement ces 2 fonctions et passons au premier argument.
Selon moi, les id ne devraient pas figurer dans un MCD car…
Tout le monde doit comprendre un MCD
Merise, c’est le fruit d’un long travail de recherche et d’études effectué par une équipe d’ingénieurs aixois dans les années 70. C’est au Ministère de l’Industrie de l’époque qu’on doit la notoriété incontestable de la méthode aujourd’hui. Ce ministère a tout simplement imposé son utilisation à toutes les administrations françaises et leurs sous-traitants, dès que le sujet tournait autour du Système d’Information.
L’objectif affiché était de fluidifier les échanges entre les intervenants techniques et non-techniques, en développant un vocabulaire et des représentations communes, compris par tous. On peut arguer sans mal qu’un MPD ne sera sûrement pas très digeste pour un donneur d’ordres, mais comme il découle d’un MLD, lui-même issu du MCD, on présume qu’un accord entre les 2 parties sur le schéma conceptuel fera partir le projet dans le bon sens.
En quoi est-ce un argument pour ne pas mettre les id dans un MCD ? Eh bien tout simplement parce qu’en les y mettant, un commanditaire se demandera toujours ce que cet attribut fait là et à quoi il sert alors qu’il est déjà mentionné l’ISBN pour une entité Livre, le numéro de Sécurité Sociale pour une entité Personne ou encore le numéro de suivi d’une entité Colis, par exemple. En déroulant l’explication qu’il attend, son interlocuteur technique devra forcément parler à un moment de colonne identité et de clé primaire. Et là, difficile de ne pas s’embourber dans les explications techniques.
D’ailleurs, il me semble judicieux de rappeler ici que…
Le C de MCD signifie conceptuel
Le I de l’acronyme Merise signifie informatique. Rappelons que la méthode est née à l’âge d’or de l’informatisation des entreprises. Mais au final, toute sa première phase, le SIO (pour Système d’Informations Organisationnel), s’applique aussi très bien pour des projets qui ne finiront sur support informatique. Ou du moins, pas sous la forme d’une base de données.
Il m’est déjà arrivé de représenter un MCD pour un espace de stockage dont il fallait décider de la nomenclature. Donc un ensemble de dossiers, sous-dossiers, fichiers et liens symboliques (le graal pour résoudre les associations de plusieurs à plusieurs). On peut également imaginer un MCD pour un système de classement de documents papier, pour trouver la meilleure manière de ranger une collection envahissante d’animaux en porcelaine etc. Quand j’en parle en cours, Il m’arrive souvent de citer la loi : il est possible de représenter l’ensemble de la loi française, de ses codes, articles et autres alinéas sous la forme d’un gigantesque MCD.
La notion d’id telle qu’on l’entend est une notion liée aux SGBD, on ne la retrouve nulle part ailleurs. En tout cas pas directement : un système de fichiers attribuera par exemple, un inode unique à chaque fichier et chaque dossier, c’est assez semblable aux id d’une base de données relationnelle. Mais je vous mets au défi de trouver un attribut se rapprochant d’un id dans un système de classement de documents papier.
Excellente question, Harold ! Je vais d’ailleurs en profiter pour faire une superbe transition vers mon troisième argument !
On prend souvent la méthode dans le mauvais sens
J’ai beau connaître pas mal de choses sur les bases de données, je reste un développeur au fond. Ce qu’on aime, nous autres, c’est développer. En général, ce qu’on n’aime pas trop, c’est prévoir, concevoir, théoriser. En phase de conception d’un projet, au bout de 3 minutes, on en a marre de réfléchir et on a déjà commencé à coder 3 classes, à installer des modules, à écrire 2 vues et mettre en place des TU.
Je ne dis pas que c’est une règle générale, mais c’est quand même une tendance assez marquée et totalement saine et logique. On se projette, tout simplement. C’est un excellent indicateur de notre implication, de notre volonté de réaliser, de concrétiser, de faire avancer ce nouveau projet. Mais comme on code quand même beaucoup plus souvent qu’on ne conçoit, il peut arriver qu’entre deux projets, on oublie comment faire un beau MCD standard.
Et c’est là qu’on peut se laisser piéger par certains tutos. On peut assez facilement trouver des ressources qui partent d’un MCD dans lequel ne figure aucun id (youpi) mais qui aboutissent sur un MPD dans lequel il n’y a toujours pas d’id (pas youpi). Et c’est valide, le discriminant de chaque entité est simplement devenu la clé primaire de chaque table correspondante. Sauf qu’aujourd’hui, on ne crée plus de table sans colonne identité (enfin, je l’espère). Mais si le discriminant d’un MCD finit par devenir la clé primaire du MPD, c’est que l’id qu’on utilise en tant que clé primaire doit figurer dans le MCD, finalement ?
Toujours pas. Rappelez-vous des 8 modèles définis par Merise (schéma plus haut dans cet article) : le SIO est indépendant des moyens techniques. En d’autres termes, ce qui permet de passer d‘un SI à l’autre, comme leur nom l’indique en partie, c’est le choix d’une technologie informatisée. Choix qui n’est donc pas encore effectué à l’étape du MCD.
Si ces étapes existent dans cette ordre chronologique, il doit y avoir une bonne raison. J’en vois déjà une qui est loin d’être mauvaise : identifier des clés candidates. En prenant le temps de réfléchir au MCD (en impliquant le destinataire du projet, tant qu’à faire), on se force à ne pas penser aux phases ultérieures et à se concentrer notamment sur la question : qu’est-ce qui permet de distinguer deux instances d’une même entité dans le monde réel ? Cette information ne sera pas perdue par la suite, même si on a recours à un id : ce sera tout simplement une clé naturelle. On posera une contrainte d’unicité sur la colonne correspondante pour s’assurer que deux enregistrements ne disposent pas d’une valeur identique pour ce champ (et ce même si l’id permettrait encore de les distinguer).
Même si le clou est déjà pas mal enfoncé, j’aimerais attirer votre attention sur un dernier point.
Le standard SQL va dans ce sens
Ou plutôt, c’est l’initiative de standardiser la colonne identité qui va dans ce sens. Même si je n’ai finalement pas cassé ma tirelire pour acheter une copie de la norme SQL et vérifier très précisément ce qu’elle a à dire sur ce sujet, je me suis dit qu’il y a quelques personnes qui ont forcément eu besoin de casser la leur : les auteurs des principaux SGBDR du marché.
Contrairement aux travaux de l’ISO, certains de ces projets sont open source. Et mêmes les solutions propriétaires ont forcément une documentation robuste qui détaillera ce nouveau mécanisme, son origine, son fonctionnement, etc. En recoupant ces informations, j’ai pu me faire une vision assez claire de ce que peuvent bien contenir les documents officiels.
La colonne identité est un mécanisme dont la raison d’être est de mettre fin à toutes les initiatives individuelles des SGBD pour mettre en place de l’auto-incrémentation. Même si théoriquement, rien ne nous oblige à nommer une colonne identité id (elle fonctionnera aussi bien si elle s’appelle meimei) ; même si dans certains SGBD, il est possible d’avoir plusieurs colonnes identité au sein d’une même table… Soyons honnête : la colonne identité, c’est le nouveau sobriquet de notre fameux id.
La principale nouveauté de ce mécanisme, c’est l’option ALWAYSqui déclenche une erreur SQL lorsqu’on essaie d’insérer manuellement des valeurs dans la colonne. Ce mécanisme doit rendre, a priori, l’implémentation sous-jacente complètement opaque et ne nécessiter aucune configuration supplémentaire (comme c’était le cas avec les serials en PostgreSQL, par exemple, dont il fallait gérer les droits). On pose notre id là et on n’y pense plus.
Message reçu, M. Vega ! Pourquoi je vous parle de ça ? Tout simplement pour vous dire que la norme va, avec la colonne identité, dans le sens d’un id plus universel mais aussi plus discret, auquel on ne pense même plus tellement il est automatique (ou automatisable, du moins). Et même si je ne pense pas que le groupe de travail SQL décidera un jour que les id sont implicites lors de la création d’une table et qu’ils n’ont même plus besoin d’apparaître dans le script de création, pourquoi mettrions-nous ces id dans le MCD alors qu’on tente de nous les faire oublier côté MPD ?
Vers Merise 2.1 ?
Même si c’est une exception française, la méthode Merise a, selon moi, encore de belles années devant elle. Le seul “défaut” (qui est en fait une preuve de qualité) que je lui trouve aujourd’hui, c’est qu’elle n’a pas ou peu bougé en un demi-siècle. Alors que SQL a beaucoup évolué, et son usage aussi. Si dans les années 80, il semblait parfaitement logique de transformer le discriminant d’une entité en clé primaire dans la table résultante, j’espère vous avoir convaincu.e aujourd’hui qu’il n’est pas logique du tout d’ajouter un id à une entité sous prétexte qu’il sera la clé primaire d’une table.
Mais il faut bien avouer que la solution la plus efficace pour répandre cette bonne parole serait qu’un ouvrage de référence traitant de Merise utilise, dans ses exemples, des pratiques SQL récentes et adapte donc légèrement le discours pour coller avec la réalité actuelle.
