Discussion :

[laowantong]

Bonjour,

Ici l'auteur de Mocodo (https://www.mocodo.net/).

Merci de vos critiques concernant l'exemple d'utilisation du logiciel donné dans le Readme de son dépôt GitHub (https://github.com/laowantong/mocodo).

Il est vrai que j'y donnais quelque peu des verges pour me faire battre

Ce MCD est tiré de l'exposé « survol » que je fais dans la première demi-heure de mon tout premier cours d'intro aux bases de données pour donner aux étudiants une idée de ce qui les attend (modélisation conceptuelle, passage au relationnel, algèbre relationnelle, SQL en 30 heures). La diapo précédente présente une demi-douzaine de règles de gestion (dont, comme l'a deviné Escartefigue, celle stipulant qu'un prof peut faire subir des examens oraux à des étudiants qui ne sont pas les siens). Les suivantes reprennent ces règles en les faisant apparaître une à une à proximité de leur « traduction » dans le MCD. À ce stade du cours, il est clair que mon but n'est pas de produire un MCD réaliste, juste de montrer à quoi ressemble un MCD. En particulier, modéliser par une association quadruple un examen a des avantages dans le contexte (avoir autre chose que des associations binaires, ne pas encombrer la diapo), mais des conséquences embarrassantes hors contexte.

Quand je me suis décidé à publier mon petit logiciel, il y a plus de dix ans, je n'ai pas réfléchi davantage : j'ai repris tel quel cet exemple, sans tout ce qu'il y avait autour (un prof, un public, un énoncé, des objectifs et contraintes), alors que mon but était tout autre : illustrer le fonctionnement de Mocodo sur un cas présentant une certaine variété, sans pour autant divulguer la solution d'un exercice que je serais susceptible de proposer en TD ou en examen

Ceci dit, Mocodo ayant pas mal évolué entre-temps, ça faisait plusieurs années que je me disais vaguement que je devais trouver un meilleur exemple (comportant notamment une association réflexive et une entité faible). En tombant sur votre discussion ce matin, mon sang n'a fait qu'un tour, et j'ai vu que le moment était arrivé de signifier son congé à ce vieux MCD bizarre (que les professionnels des BD détestent !). Et curieusement, c'est une très ancienne intervention de ce même fsmrel sur ce même forum qui m'a fourni la solution : le diagramme ER de l'article fondateur de Chen (1976), que j'avais oublié depuis presque aussi longtemps. Outre sa compacité et sa richesse (entité faible, association multiple, association réflexive, plusieurs associations entre deux mêmes entités), il n'a pas besoin d'explications (ou sinon, on les trouve dans l'article).

Je n'arrive pas à joindre d'image (peut-être parce que je viens de m'inscrire sur ce forum), mais le Readme est à jour sur GitHub. Si vous y voyez d'autres erreurs, merci de me les signaler.

Je me pose tout de même des questions à propos de l'une de vos remarques : en quoi identifier Catégorie par « code catégorie » est-il une anomalie ? Est-ce le mot « code » qui a des connotations que j'ignore ? En quoi est-ce différent d'identifier Intervention par « code intervention » dans l'exemple de Looping (https://www.looping-mcd.fr/#) ?

Enfin, concernant vos interrogations sur les fonctionnalités de Mocodo :

- quels contrôles sont faits : si vous parlez des contrôles de la validité du MCD, voici une liste des messages d'erreur (https://gist.github.com/laowantong/7...2a747fb6ae2395) qui vous permettra de vous faire une idée ;
- quelles contraintes sont implémentées : aucune, je pense, en tout cas pas les CIF en tant que telles ;
- quels SGBD sont compatibles : si vous voulez parler des dialectes SQL pris en charge en sortie, actuellement c'est MySQL, Oracle, Postgres et SQLite. Ça se fait normalement sans programmation, par le biais de fichiers de configuration. Mais j'avoue que c'est un coin de Mocodo que je ne fréquente guère, et qui aurait sans doute besoin d'un bon coup de balai ;
- peut on mettre en œuvre l'identification relative : oui, je pense, mais je l'appelle « entité faible » et la représente par défaut de façon non standard ;
- peut on paramétrer la codification des objets : je ne sais pas ce que c'est, donc sans doute pas ;
- versionner les modèles : je délègue ça à Git, étant donné que Mocodo ne prend que du texte en entrée.

Désolé en tout cas que l'approche que j'ai adoptée soit déroutante. Mes connaissances et, je l'avoue, ma passion pour les bases de données sont très limitées. À l'origine, je voulais juste pouvoir générer des schémas esthétiquement plaisants (vectoriel) pour illustrer mon cours, et le faire de façon purement textuelle (l'éditeur de texte est mon outil de prédilection). De fil en aiguille, j'ai ajouté des fonctionnalités plus intéressantes (comme le passage au relationnel ou le réarrangement automatique), et à un moment où j'avais trop de temps libre j'ai fini par publier tout ça, m'exposant ainsi aux quolibets, mais me donnant aussi l'occasion de me dégrossir. Comme mon but initial était de répondre à mes problématiques d'enseignant, il y a sans doute quelques collègues à qui ça a parlé, et qui se sont mis à l'utiliser. Ça m'a valu plusieurs demandes de fonctionnalités qui dépassaient largement le cadre de mon cours d'intro. Après avoir fait la sourde oreille pendant des années, j'en ai ajouté quelques-unes l'été dernier : en gros, l'agrégation et l'héritage. Mais clairement, Mocodo n'a pas d'ambitions professionnelles, et ne sortira jamais d'un cadre pédagogique élémentaire (une dizaine d'entités).

Merci de votre compréhension, et bonne journée.

[fsmrel]

Bonsoir laowantong,

j'ai vu que le moment était arrivé de signifier son congé à ce vieux MCD bizarre

Je ne vois pas en quoi votre MCD est bizarre, il n’a rien de détestable, simplement il mérite des rectificatifs et aménagements qu’escartefigue et moi-même avons signalés. Le sujet traité a l’avantage d’être compréhensif puisqu’on y trouve les ingrédients des cours donnés par des profs à des élèves.

en quoi identifier Catégorie par « code catégorie » est-il une anomalie ?

Ça n’est pas une anomalie à proprement parler, mais dans la vraie vie des entreprises si les codes peuvent être modifiés, ça peut être la cata. Je vous renvoie à une discussion dans laquelle je cite à ce sujet un très grand de Merise, Yves Tabourier, devant qui je m’incline.

Un exemple dont je me sers au besoin : il s’agit du système préconisé par les concepteurs dans une très grande banque, consistant à identifier les entreprises par leur numéro Siren, fourni par un organisme extérieur, à savoir l’INSEE. Par voie de conséquence, au niveau du MLD (Modèle Logique de Données selon Merise), puis SQL, ce Siren devait être propagé dans toute la base de données par le jeu des liens clé primaire - clé étrangère. Les concepteurs avaient entrepris le montage d’une véritable usine à gaz pour maintenir la cohérence entre les tables, parce que l’INSEE envoie tous les mois les nombreux correctifs modifiant les numéros de Siren erronés. Tout en leur commentant l’ouvrage d’Y. Tabourier, je leur suggérai que l’identifiant de l’entreprise fît l’objet d’une propriété nouvelle et artificielle,invariante et sans signification, EntrepriseId, le numéro Siren devenant pour sa part dentifiant alternatif, c'est-à-dire conservant sa spécificité : être unique et pouvant subir toutes les modifications de la part de l’utilisateur. Au niveau MLD et SQL, l’ex clé primaire, le numéro Siren fit donc l’objet d’une clé alternative, point d'entrée dans la table, permettant à l'utilisateur d’accéder aux données de chaque entreprise, la suite des opérations se passant de façon transparente, encapsulée pour utiliser un jargon à la mode, grâce à la nouvelle clé primaire {EntrepriseId} prenant le relais de sa copine clé alternative : du point de vue de l’utilisateur et des règles fonctionnelles, rien de changé, mais l’usine à gaz disparut en fumée, des économies furent réalisées, et tout le monde fut content.  

Votre entité-type AYANT-DROIT : avec votre façon d’identifier, pour un employé donné, deux ayants-droits ne peuvent avoir le même nom (des frères par exemple), ce qui est quand même gênant...


A propos de Chen, je renvoie par exemple au message suivant :

https://www.developpez.net/forums/d1...e/#post7625393

Je rappelle son diagramme :




Ainsi que l’équivalent Merise :



Chen a oublié la spécialisation/généralisation, mais peut-être s’est-il rattrapé plus tard ?

Contraintes : on ne sait pas si l’association SUP-PROJ-PART implique l’association PROJ-PART (inclusion) ou si ces associations sont exclusives.


Bon courage pour la suite,

François

[laowantong]

Bonsoir,

Merci de votre réponse.

Oui, on est d'accord sur l'intérêt d'identifiants indépendants des données-métier. Je ne manque pas de présenter ça à mes étudiants le moment venu. Mais dans des exemples censés illustrer autre chose, comme tous les profs, je m'autorise quelques licences

une clé alternative, point d'entrée dans la table

Excellent, en effet, et très respectueux de l'utilisateur.

Contraintes : on ne sait pas si l’association SUP-PROJ-PART implique l’association PROJ-PART (inclusion) ou si ces associations sont exclusives.

Effectivement, je m'étais posé la même question, et je n'ai pas trouvé la réponse dans l'article. Je modifierai éventuellement l'exemple du README pour y ajouter p. ex. une contrainte d'inclusion si ça ne surcharge pas trop le diagramme. Je viens justement d'intégrer à Mocodo une prise en charge des contraintes entre associations, je ferai probablement une mise à jour cette semaine. Merci pour l'idée en tout cas !

Bonne soirée à vous.

[Paprick]

Bonsoir,

Ça n’est pas une anomalie à proprement parler, mais dans la vraie vie des entreprises si les codes peuvent être modifiés, ça peut être la cata. Je vous renvoie à une discussion dans laquelle je cite à ce sujet un très grand de Merise, Yves Tabourier, devant qui je m’incline.
Tout en leur commentant l’ouvrage d’Y. Tabourier, je leur suggérai que l’identifiant de l’entreprise fît l’objet d’une propriété nouvelle et artificielle, invariante et sans signification, EntrepriseId, le numéro Siren devenant pour sa part dentifiant alternatif, c'est-à-dire conservant sa spécificité : être unique et pouvant subir toutes les modifications de la part de l’utilisateur. Au niveau MLD et SQL, l’ex clé primaire, le numéro Siren fit donc l’objet d’une clé alternative, point d'entrée dans la table, permettant à l'utilisateur d’accéder aux données de chaque entreprise, la suite des opérations se passant de façon transparente, encapsulée pour utiliser un jargon à la mode, grâce à la nouvelle clé primaire {EntrepriseId} prenant le relais de sa copine clé alternative : du point de vue de l’utilisateur et des règles fonctionnelles, rien de changé, mais l’usine à gaz disparut en fumée, des économies furent réalisées, et tout le monde fut content.

Allez, je prends mon courage à 2 mains et je me lance... ou plutôt je me relance !
Je sais que ça ne va pas faire plaisir à François (et à beaucoup d'autres !) mais, malgré tout le respect que j'ai pour Y. Tabourier, je ne suis pas d'accord avec ce qui a été posé comme une règle d'or indiscutable concernant la nature des identifiants.
Alors oui, un identifiant doit être invariant, on est d'accord !
J'en profite pour rappeler toutes les qualités que doit posséder un identifiant :

• Unicité : c'est la base !
• Formalisme : il ne doit y avoir aucune ambiguïté sur la façon de l'écrire (ce qui exclut toute tentative d'utiliser des VARCHAR, et nous pousse à privilégier des entiers).
• Pérennité : on retrouve ici la nécessité d'être invariant (avec donc aucune possibilité d'évoluer dans le temps).
• Légal : bien sûr ; par exemple, l'usage du numéro SS pour identifier une personne est interdit (cf. la CNIL).
• Irréductible : afin d'obtenir une clé minimale et éviter les surclés.

Ceci étant dit, concentrons-nous sur l'invariance : certes une rubrique sans signification n'aura bien sûr aucune raison de varier... on ne prend donc aucun risque en faisant systématiquement ce choix, et ceux qui le font ne sont en rien critiquables.
Mais ce n'est en rien une règle incontournable : l'important, c'est l'invariance, et même si la non signification est une solution, ce n'est pas la seule.
Prenons le cas d'un numéro de facture NUMFAC : une fois qu'une facture est émise, il est interdit de la modifier, et encore moins d'en modifier le numéro ou de la supprimer (ce sont les règles comptables) : en cas de problème, il faut faire un avoir ; si, plus tard, le système de numération change, il est interdit de changer les numéros des factures déjà émises... Bref, le numéro de facture NUMFAC est invariant ; il possède également toutes les autres qualités d'un identifiant : il est donc inutile de créer un autre ID_FACTURE.
Prenons une référence produit (ISBN pour un livre par exemple) : si la référence change, ce n'est plus le même produit...
Les exemples sont légions !
Tous les contre-exemples pris dans le cadre de ce débat partent du principe que c'est la panique si l'identifiant évolue... c'est vrai, mais dans ce cas, il ne respecte pas la règle de pérennité : ce n'est donc pas un bon identifiant et on peut alors se rabattre sur la création d'un identifiant sans signification, inconnu du SI, mais qui fera le job.
Dernier point que j'ai déjà soulevé : les dates... elles font souvent partie de la composition des identifiants, et pourtant elles ont une réelle signification.
Certes, comme elles sont le plus souvent utilisées dans un contexte d'historisation, elles sont invariantes... mais avec signification.
Alors pourquoi seraient-elles les seules à avoir ce privilège ?
Donc, je persiste et signe : le plus important c'est l'invariance, pas la signification.

Voilà, vous pouvez vous défouler maintenant !

[escartefigue]

Il n'y a pas contradiction invariante ET sans signification ne signifie pas invariante DONC sans signification

L'absence de signification, si elle n'est pas un gage de stabilité, est plutôt rassurante sur ce chapitre.
À l'inverse, les valeurs signifiantes ont tendance à être instables.

Mais stricto sensu, je suis d'accord avec la précision de Paprick, c'est bien l'invariance des identifiants au niveau conceptuel et des clefs au stade SQL qui nous intéresse

[fsmrel]

Bonsoir,

Il serait malséant de te taper dessus, vu tout ce que tu nous a offert.

Maintenant, si je regarde dans le rétroviseur, je n’ai aucun remord à avoir suivi Tabourier. J’ai quand même longtemps modélisé, audité, conseillé, participé aux changements de système, etc., chez mes nombreux clients, à la satisfaction de tous, et avoir appliqué la règle d’or m’a permis pendant tout ce temps de dormir sur mes deux oreilles (au moins pour cet aspect des choses).

Question : Paprick, tu parles du numéro de facture. Si s’est toi qui émets les factures, la pérennité est garantie. Si tu dois modéliser les factures de tes clients, comment procèdes-tu pour les identifier ?

Utiliser des identifiants significatifs, d’accord, mais à condition d’en avoir la maîtrise, contrairement à la banque que j’évoquais, consciente que le Siren des entreprises était modifiable par l’INSEE.  

Prenons le cas de la création des numéros de téléphone. Je me situe trente ans en arrière. L’opérateur national en a la maîtrise et côté base de données (DB2) il n’y avait pas de problème particulier, jusqu’au jour où il y eut un changement dans les règles : passer de la numérotation de 8 à 10 chiffres... Du côté de la base de données, ça ne fut pas triste (problème de toutes les tables dotées des clés étrangères correspondantes. ) et j’ai participé avec les DBA à la migration, nous avons pris le temps nécessaire de bien tout vérifier avant d’être certains que tout était bon.

Prenons le cas des immatriculations des voitures. Mon immat est toujours à l’ancien format, ce qui implique l’utilisation du varchar. Ça n’est pas idéal pour les clés primaires et étrangères...

Il y a aussi l’aspect performance (temps de traitement) en production, en général crucial...

Par exemple, un numéro de facture est le plus souvent alphanumérique, du fait de la présence d’au moins un tiret, exemple "2023-05007", soit 10 caractères en l’occurrence. Dans la base de données, une page de l’index (primaire) associé contiendra en fait deux fois plus de clés si le numéro de facture est du type integer, donc. Comme par hasard, cet index est à considérer préférablement comme cluster (DB2) et l’application aura alors une meilleure performance, deux fois moins de pages à y lire lors des traitements de masse (les fameux « batch » de nuit).

Quant à l’ISBN (en espérant qu’il ne passera pas un jour à plus de 13 caractères)...

Bref, la signification portée par les clés (primaires et étrangères) peut être perturbatrice si ce n’est pas nous qui imposons leur structure, type INTEGER en l’occurrence. Certes, je raisonne en DBA, mais ce n’est pas aujourd’hui que je me referai, comme je l’ai dit, je tiens à dormir sur mes deux oreilles...

[Paprick]

Bonsoir,

Utiliser des identifiants significatifs, d’accord, mais à condition d’en avoir la maîtrise, contrairement à la banque que j’évoquais, consciente que le Siren des entreprises était modifiable par l’INSEE.

On est tout à fait d'accord : la pérennité d'une donnée ne peut s'envisager que si on en a la maîtrise.

Prenons le cas de la création des numéros de téléphone. Je me situe trente ans en arrière. L’opérateur national en a la maîtrise et côté base de données (DB2) il n’y avait pas de problème particulier, jusqu’au jour où il y eut un changement dans les règles : passer de la numérotation de 8 à 10 chiffres... Du côté de la base de données, ça ne fut pas triste (problème de toutes les tables dotées des clés étrangères correspondantes. ) et j’ai participé avec les DBA à la migration, nous avons pris le temps nécessaire de bien tout vérifier avant d’être certains que tout était bon.

Très bon, exemple d'une donnée qui n'a rien de pérenne : non seulement le format peut changer, mais c'est surtout les utilisateurs qui risquent de changer bien souvent de numéro ! C'est l'exemple que je prends en cours pour indiquer que le numéro de téléphone est un mauvais identifiant pour son propriétaire.

Prenons le cas des immatriculations des voitures. Mon immat est toujours à l’ancien format, ce qui implique l’utilisation du varchar. Ça n’est pas idéal pour les clés primaires et étrangères...

Sans oublier que les anciennes immatriculations pouvaient changer lors d'un changement de propriétaire !

Côté performance, on est d'accord qu'il n'y a pas mieux qu'un bon INTEGER. Un petit (tout petit) bémol tout de même : le fait de rajouter un identifiant sans signification alors qu'un identifiant naturel est disponible nous amène à créer une clé alternative (comme tu l'as très bien indiqué), avec le maintien de l'index correspondant.

Bref, la signification portée par les clés (primaires et étrangères) peut être perturbatrice si ce n’est pas nous qui imposons leur structure, type INTEGER en l’occurrence. Certes, je raisonne en DBA, mais ce n’est pas aujourd’hui que je me referai, comme je l’ai dit, je tiens à dormir sur mes deux oreilles...

D'accord avec cette exigence et cette solution de tranquillité, mais je maintiens que ce n'est en rien une règle inéluctable.