Mocodo
\n- 1 Introduction
- 2 Installation et lancement du programme
- 3 Syntaxe de description d'un MCD
- 4 Conversion d'un MCD
- 5 Mocodo pour la pédagogie
- 6 Compléments sur l'aspect visuel
- 7 Annexe A : Miscellanées académiques
- 8 Annexe B : La commande
mocodo - 9 Annexe C : Crédits
%reload_ext mocodo\nMocodo 4.3.2 loaded.\n\n
from IPython import display\nfrom pathlib import Path\nimport os\nif Path.cwd().name != \"mocodo_notebook\":\n Path(\"mocodo_notebook\").mkdir(parents=True, exist_ok=True)\n os.chdir(\"mocodo_notebook\")\n![\"\"](\"https://cdn.rawgit.com/laowantong/mocodo/master/logos/banner.svg\"/)
Introduction¶
\nMocodo est un logiciel d'aide à l'enseignement et à l'apprentissage des bases de données relationnelles.
\n- \n
- En entrée, il prend un MCD (modèle conceptuel de données) décrit dans un langage dédié minimaliste. \n
- En sortie, il produit un diagramme entité-association et, à la demande, un MLD (schéma relationnel, sous forme graphique ou textuelle), un DDL (script SQL de création de la base), un diagramme de classes UML, etc. \n
- En bonus, il est capable de réarranger automatiquement votre MCD de façon esthétique, et de lui appliquer des opérations de réécriture qui vont du mondain (typographie) à l'académique (décomposition d'associations), en passant par le merveilleux (inférence de types, génération d'exercices et d'exemples). \n
Vous pouvez utiliser Mocodo :
\n- \n
- à distance, sans rien installer, avec Mocodo online ; \n
- en local, comme n'importe quel programme Python ; \n
- dans un document Jupyter Notebook (à l'instar de cette documentation). \n
Tracé du modèle conceptuel¶
\nCi-dessous, un exemple d'utilisation sous Jupyter Notebook. L'appel du programme est en première ligne ; le texte-source proprement dit, lignes suivantes. En sortie, le diagramme conceptuel, égayé au passage par l'option --colors :
%%mocodo --colors ocean\nClient: Réf. client [VARCHAR(8)], Nom [VARCHAR(255)], Prénom [VARCHAR(255)], Adresse [VARCHAR(255)]\nPasser, 0N Client, 11 Commande\nCommande: Num. commande [VARCHAR(8)], Date [DATE], Montant [DECIMAL(10,2)]\nInclure, 1N Commande, 0N Produit: Quantité [INTEGER]\nProduit: Réf. produit [VARCHAR(8)], Libellé [VARCHAR(50)], Prix unitaire [DECIMAL(10,2)]\nOpérations de conversion¶
\nL'appel précédent a automatiquement enregistré le texte-source sous le nom de sandbox.mcd. Renommons-le ccp.mcd pour y avoir accès tout au long de ce document.
Path(\"sandbox.mcd\").rename(\"ccp.mcd\");\nOn peut le récupérer avec --input pour lui appliquer diverses opérations. Ainsi, l'appel suivant génère et affiche son MLD, son diagramme relationnel et son DDL :
%mocodo --input ccp --transform mld diagram ddl --colors mondrian\n\n\n\nccp_mld.md\n\n\n
- \n
- Client (Réf. client, Nom, Prénom, Adresse) \n
- Commande (Num. commande, Date, Montant, #Réf. client) \n
- Inclure (#Num. commande, #Réf. produit, Quantité) \n
- Produit (Réf. produit, Libellé, Prix unitaire) \n
\n\n\nccp_mld.svg\n\n\n
\n\n\nccp_ddl.sql\n\n\n
CREATE TABLE Client (\n PRIMARY KEY (Ref_client),\n Ref_client VARCHAR(8) NOT NULL,\n Nom VARCHAR(255),\n Prenom VARCHAR(255),\n Adresse VARCHAR(255)\n);\n\nCREATE TABLE Commande (\n PRIMARY KEY (Num_commande),\n Num_commande VARCHAR(8) NOT NULL,\n Date DATE,\n Montant DECIMAL(10,2),\n Ref_client VARCHAR(8) NOT NULL\n);\n\nCREATE TABLE Inclure (\n PRIMARY KEY (Num_commande, Ref_produit),\n Num_commande VARCHAR(8) NOT NULL,\n Ref_produit VARCHAR(8) NOT NULL,\n Quantite INTEGER\n);\n\nCREATE TABLE Produit (\n PRIMARY KEY (Ref_produit),\n Ref_produit VARCHAR(8) NOT NULL,\n Libelle VARCHAR(50),\n Prix_unitaire DECIMAL(10,2)\n);\n\nALTER TABLE Commande ADD FOREIGN KEY (Ref_client) REFERENCES Client (Ref_client);\n\nALTER TABLE Inclure ADD FOREIGN KEY (Ref_produit) REFERENCES Produit (Ref_produit);\nALTER TABLE Inclure ADD FOREIGN KEY (Num_commande) REFERENCES Commande (Num_commande);\nDans la suite, pour épargner la frappe, les options --input et --transform seront respectivement abrégées en -i et -t.
Les opérations de conversion ne se limitent pas forcément au schéma relationnel. En voici une qui extrait un dictionnaire des données, par défaut sous la forme d'un tableau Markdown à trois colonnes :
\n%mocodo -i ccp -t data_dict\n\n\n\nccp_data_dict_3.md\n\n\n
| Entité ou association | \nLibellé de l'attribut | \nType | \n
|---|---|---|
| Client | \nAdresse | \nVARCHAR(255) | \n
| \" | \nNom | \nVARCHAR(255) | \n
| \" | \nPrénom | \nVARCHAR(255) | \n
| \" | \nRéf. client | \nVARCHAR(8) | \n
| Commande | \nDate | \nDATE | \n
| \" | \nMontant | \nDECIMAL(10,2) | \n
| \" | \nNum. commande | \nVARCHAR(8) | \n
| Inclure | \nQuantité | \nINTEGER | \n
| Produit | \nLibellé | \nVARCHAR(50) | \n
| \" | \nPrix unitaire | \nDECIMAL(10,2) | \n
| \" | \nRéf. produit | \nVARCHAR(8) | \n
Une autre qui transcrit le MCD dans la notation crow's foot (crow) pour Mermaid (mmd) :
%mocodo -i ccp -t crow:mmd\n\n\n\nccp_erd_crow.mmd\n\n\n
mmd\nerDiagram\n Client {\n VARCHAR(8) Ref_client PK\n VARCHAR(255) Nom\n VARCHAR(255) Prenom\n VARCHAR(255) Adresse\n }\n Commande {\n VARCHAR(8) Num_commande PK\n DATE Date\n DECIMAL(10-2) Montant\n }\n Inclure {\n INTEGER Quantite PK\n }\n Produit {\n VARCHAR(8) Ref_produit PK\n VARCHAR(50) Libelle\n DECIMAL(10-2) Prix_unitaire\n }\n Client ||--o{ Commande: Passer\n Inclure }|..|| Commande: DF\n Inclure }o..|| Produit: DF\n\nLe rendu des diagrammes décrits dans des langages-tiers (comme Mermaid, PlantUML, etc.) n'est pas directement pris en charge, mais peut être délégué (--defer) de façon transparente au service web approprié. Dans ce cas, c'est la sortie graphique qui est affichée :
%mocodo -i ccp -t crow:plantuml --defer\n\n\n\nccp_erd_crow.svg\n\n\n
Opérations de réécriture¶
\nUne réécriture transforme un MCD Mocodo en un autre MCD Mocodo (au contraire d'une conversion, qui produit un animal d'une espèce différente).
\nHeureusement, l'utilisateur n'a pas à réfléchir si la transformation qu'il souhaite appliquer est une réécriture ou une conversion : dans les deux cas, il invoque -t (c'est-à-dire --transform), et Mocodo se débrouille.
En guise de premier exemple de réécriture, mettons les noms des entités et associations (boxes) en majuscules, et les libellés (labels) en ASCII et snake case :
%mocodo -i ccp -t upper:boxes ascii:labels snake:labels --colors brewer+3\n\n\n\nccp.mcd\n\n\n
%%mocodo --colors brewer+3\nCLIENT: Ref_client [VARCHAR(8)], Nom [VARCHAR(255)], Prenom [VARCHAR(255)], Adresse [VARCHAR(255)]\nPASSER, 0N CLIENT, 11 COMMANDE\nCOMMANDE: Num_commande [VARCHAR(8)], Date [DATE], Montant [DECIMAL(10,2)]\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantite [INTEGER]\nPRODUIT: Ref_produit [VARCHAR(8)], Libelle [VARCHAR(50)], Prix_unitaire [DECIMAL(10,2)]\n\n
Remarquez que l'exécution d'une réécriture affiche, au-dessous du diagramme, le code-source résultant. Celui-ci est précédé de la commande magique originale, privée de l'option -i et de toute opération de réécriture. Ces dispositions permettent de continuer à travailler directement dessus si on le copie-colle dans une autre cellule.
Plusieurs opérations de réécriture de nature sémantique sont également offertes. Par exemple, on peut décomposer un MCD quelconque en un MCD équivalent, mais n'employant que des dépendances fonctionnelles et des entités faibles :
\n%mocodo -i ccp -t explode:weak,arity=2 arrange:wide --seed=3 --colors brewer+3\n\n\n\nccp.mcd\n\n\n
%%mocodo --seed=3 --colors brewer+3\nClient: Réf. client [VARCHAR(8)], Nom [VARCHAR(255)], Prénom [VARCHAR(255)], Adresse [VARCHAR(255)]\nPasser, 0N Client, 11 Commande\nCommande: Num. commande [VARCHAR(8)], Date [DATE], Montant [DECIMAL(10,2)]\nDF, _11 Inclure, 1N Commande\nInclure: _Quantité [INTEGER]\nDF, _11 Inclure, 0N Produit\nProduit: Réf. produit [VARCHAR(8)], Libellé [VARCHAR(50)], Prix unitaire [DECIMAL(10,2)]\n\n
Notez l'argument arrange:wide. Il a procédé à une réorganisation aléatoire des boîtes, ce que l'insertion de deux nouvelles associations de dépendance fonctionnelles avait rendu nécessaire. Quant à l'option --seed=3, elle garantit que le résultat sera le même à chaque exécution.
Après cet aperçu de quelques-unes des fonctionnalités de Mocodo, entrons dans les détails.
\nInstallation et lancement du programme¶
\nComme nous l'avons dit, vous pouvez utiliser Mocodo sans rien installer. Il vous suffit d'aller sur mocodo.net et de commencer à taper votre MCD. Appuyez à tout moment sur le ventilateur pour rafraîchir les diagrammes conceptuel et relationnel. Quand le résultat vous convient, appuyez sur le bouton de téléchargement pour récupérer une archive ZIP contenant tous les fichiers d'entrée et de sortie spécifiés.
\nMocodo online est conçu pour une utilisation occasionnelle et/ou interactive, et son interface vise avant tout à la simplicité. Vous n'avez donc accès qu'aux options essentielles du programme. Si vous en voulez davantage, tant en termes de paramétrage que de calcul ou de fonctionnalités, nous vous conseillons d'installer Mocodo sur votre machine.
\nInstallation minimale¶
\nMocodo est un programme écrit en Python 3. Si vous êtes sous macOS ou Linux, il est déjà installé. Dans le cas contraire, vous devrez peut-être le faire.
\nUne fois Python présent sur votre machine, tapez sous un terminal:
\n python -m pip install mocodoPuis testez-le :
\n mocodoInvoqué sous cette forme, Mocodo récupère le texte d'entrée du MCD dans le répertoire courant sous le nom de sandbox.mcd. Si ce fichier n'existe pas, il y sera automatiquement créé avec un MCD d'exemple. Par la suite, vous n'aurez qu'à le garder ouvert sous un éditeur de texte, afin de le modifier à votre fantaisie avant de relancer la commande.
Si votre système se plaint que cette commande n'existe pas, localisez le fichier mocodo et ajoutez à votre PATH le chemin du répertoire contenant:
- \n
- sous Linux ou macOS ; \n
- sous Windows. \n
Installation complète (recommandé)¶
\n- \n
Installez la distribution Anaconda, qui contient Python 3, Jupyter Notebook et bien plus encore.
\n \nLa ligne donnée précédemment installe en fait, en plus de Mocodo, sa « commande magique » pour Jupyter Notebook. Nous l'avons déjà invoquée plusieurs fois dans ce document :
\n
\npython -m pip install mocodo\nMocodo fonctionne parfaitement sans aucune dépendance. Cependant, si vous souhaitez :
\n- \n
- utiliser l'option
--svg_topour générer des figures en PDF ou en PNG ; \n - copier directement dans le presse-papier le résultat d'une réécriture ; \n
... vous pouvez installer les dépendances optionnelles aux bibliothèques CairoSVG et Pyperclip ainsi :
\n
\npython -m pip install 'mocodo[svg,clipboard]'\n- utiliser l'option
Pour mettre la « commande magique » mocodo à disposition d'un notebook donné, évaluez dans celui-ci la cellule suivante:
%reload_ext mocodoTechniquement, %load_ext mocodo suffit, mais cette forme vous épargnera un message d'erreur si vous réévaluez ultérieurement la cellule.
Pour tester la commande :
\n%%mocodo\nMISSION: accomplie\nPour charger automatiquement mocodo à chaque ouverture d'un notebook (ce qui dispense d'évaluer %load_ext mocodo) :
- \n
- exécutez sous un terminal : \n
ipython profile create\n- \n
- éditez le fichier créé (p. ex.:
~/.ipython/profile_default/ipython_config.py) en remplaçant la ligne suivante : \n
# c.TerminalIPythonApp.extensions = []\npar celle-ci :
\nc.InteractiveShellApp.extensions = [\"mocodo\"]\nUtilisation par importation¶
\nNouveauté de la version 4.1.3. Un wrapper minimaliste permet de simuler programmatiquement l'appel à la commande mocodo.
from mocodo.api import mocodo\nAinsi, l'équivalent de :
\nmocodo -i ccp --colors mondrian\n... s'écrira :
\nmessages = mocodo(\"-i ccp --colors mondrian\")\nPar défaut (second argument quiet=True), la fonction n'affiche pas les messages de succès, mais renvoie leur concaténation :
print(messages)\nFichier de sortie « ~/Dropbox/Sites/mocodo/doc/mocodo_notebook/ccp.svg » généré avec succès.\n\n
Plus important, les fichiers de sortie sont bel bien créés :
\ndisplay.SVG(\"ccp.svg\")\nSi vous travaillez sous une implantation de Jupyter Notebook qui ne prend pas en charge les commandes magiques, l'importation conseillée est :
\nfrom mocodo.magic import mocodo\nElle permet de simuler les commandes magiques, aussi bien celles qui sont réduites à une ligne :
\nmocodo(\"%mocodo -i ccp --colors ocean\")\n... que celles qui portent sur toute une cellule :
\nmocodo(\"\"\"\n%%mocodo --colors pond\nMission: accomplie\n\"\"\")\nLe préfixe \"%mocodo\" ou \"%%mocodo\" est ignoré, mais l'autoriser permet de copier toute une ligne ou toute une cellule (vraiment) magique, et de la coller directement comme argument de la fonction.
Nouveauté de la version 4.2. Avec cette technique, Mocodo peut être utilisé sous Basthon v. 0.62.12 ou ultérieure. Basthon est une plateforme permettant de travailler sous Jupyter Notebook sans avoir à rien installer. Son auteur, Romain Casati, a ajouté un exemple d'utilisation de Mocodo dans la galerie du logiciel, à tester ici. Sous Mocodo online, cliquez sur le symbole de lecture de Basthon (dans le pied de page) pour ouvrir un notebook avec le MCD en cours d'édition.
\nSyntaxe de description d'un MCD¶
\nNotions élémentaires¶
\nEntités, associations, attributs, identifiants, cardinalités¶
\n%%mocodo\nCLIENT: Réf. client, Nom, Prénom, Adresse\nPASSER, 0N CLIENT, 11 COMMANDE\nCOMMANDE: Num. commande, Date, Montant\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantité\nPRODUIT: Réf. produit, Libellé, Prix unitaire\nPassons en revue les principes de la syntaxe. Ils ne devraient pas poser trop de problèmes.
\nLa première ligne ne fait pas partie de la définition du MCD. Sous Jupyter Notebook, elle dénote l'appel à une « commande magique », qui lance Mocodo sur le reste de la cellule. En dehors d'un notebook, vous n'en avez pas besoin, et toute ligne commençant par un pourcentage (%) sera considérée comme un commentaire.
Une entité est définie par :
\n$$\n\\overbrace{\\texttt{COMMANDE}}^{\\text{son nom}}\n\\quad\n\\overbrace{\\texttt{:}}^{\\text{deux-points}}\n\\quad\n\\overbrace{\\texttt{Num. commande, Date, Montant}}^{\\text{ses attributs séparés par des virgules}}\n$$
\nNotez que le premier attribut d'une entité est considéré par défaut comme son identifiant, et donc souligné.
\nUne association est définie par :
\n$$\n\\overbrace{\\texttt{INCLURE}}^{\\text{son nom}}\n\\quad\n\\overbrace{\\texttt{,}}^{\\text{une virgule}}\n\\quad\n\\overbrace{\n \\underbrace{\\texttt{1N}}_{\\text{cardinalités}}\n \\underbrace{\\texttt{COMMANDE}}_{\\text{entité}}\n \\quad\n ,\n \\quad\n \\underbrace{\\texttt{0N}}_{\\text{cardinalités}}\n \\underbrace{\\texttt{PRODUIT}}_{\\text{entité}}\n}^{\\text{ses pattes séparées par des virgules}}\n\\quad\n\\overbrace{\\texttt{:}}^{\\text{deux-points}}\n\\quad\n\\overbrace{\\texttt{Quantité}}^{\\text{ses attributs séparés par des virgules}}\n$$
\nNotez que pour les associations sans attributs (comme PASSER), le deux-points est facultatif.
\nAstuce. Si vous recopiez un MCD ou que vous l'avez bien en tête, commencez par les associations et, à tout moment, faites apparaître les entités manquantes (double clic sur le lapin magique sous Mocodo online). Elles auront comme identifiant le nom de l'entité en minuscules, par défaut précédé de « id. » (sauf pour les entités DATE et PÉRIODE). Vous n'aurez plus qu'à remplir les autres attributs :
\n%%mocodo -t guess:entities\nRéserver, 1N Client, 1N Chambre, 0N Date: Durée\n\n\n\nsandbox.mcd\n\n\n
%%mocodo \nRéserver, 1N Client, 1N Chambre, 0N Date: Durée\n\nClient: id. client, \nChambre: id. chambre, \nDate: date\n\n
Dépendances fonctionnelles entre entités¶
\nLorsque l'une des cardinalités maximales d'une association binaire est 1 (ou quelquefois 0), on désigne cette association sous le nom de dépendance fonctionnelle. On la figure souvent par un cercle portant le symbole DF : cela évite de se creuser la tête pour trouver un nom à une association qui (spoiler) disparaîtra corps et biens au moment du passage au relationnel.
\n%%mocodo\nCLIENT: Réf. client, Nom, Prénom, Adresse\nDF, 0N CLIENT, 11 COMMANDE\nCOMMANDE: Num. commande, Date, Montant\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantité\nPRODUIT: Réf. produit, Libellé, Prix unitaire\nAssociations réflexives¶
\nQuelquefois appelées circulaires, unaires ou récursives, elles associent une entité à elle-même. Voici par exemple une représentation des filiations patrilinéaires (le 01 permet d'« arrêter » la remontée des ancêtres) :
\n%%mocodo\nHOMME: Num. SS, Nom, Prénom\nENGENDRER, 0N HOMME, 01 HOMME\nIdentifiants composites¶
\nPréfixez d'un tiret bas (_) les second, troisième, etc. attributs pour les inclure dans l'identifiant.
%%mocodo\nGRATTE-CIEL: latitude, _longitude, nom, hauteur, année de construction\nFlèches sur les pattes¶
\nSuffixez d'un chevron (< ou >) les cardinalités de la patte concernée. La direction indiquée se lit en partant de l'association et en allant vers l'entité.
%%mocodo\nPeut recevoir, 1N> Groupe sanguin, 1N< Groupe sanguin\nGroupe sanguin: type de sang\nAppartient, 11> Personne, 0N Groupe sanguin\nPersonne: Num. SS, Nom, Prénom, Sexe\nEngendre, 0N< Personne, 22> Personne\nTypes de données¶
\nComme on l'a vu dans l'introduction, chaque attribut peut être assorti d'un type entre crochets, qui servira lors de la conversion en SQL. À partir de la version 4.0, Mocodo est capable de deviner le type des attributs usuels à partir de leur nom :
\n%%mocodo -t guess:types data_dict --select cv\nCLIENT: Réf. client, Nom, Prénom, Adresse\nPASSER, 0N CLIENT, 11 COMMANDE\nCOMMANDE: Num. commande, Date, Montant\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantité\nPRODUIT: Réf. produit, Libellé, Prix unitaire\n\n\n\nsandbox_data_dict_3.md\n\n\n
| Entité ou association | \nLibellé de l'attribut | \nType | \n
|---|---|---|
| CLIENT | \nAdresse | \nVARCHAR(30) | \n
| \" | \nNom | \nVARCHAR(255) | \n
| \" | \nPrénom | \nVARCHAR(255) | \n
| \" | \nRéf. client | \nVARCHAR(8) | \n
| COMMANDE | \nDate | \nDATE | \n
| \" | \nMontant | \nDECIMAL(10,2) | \n
| \" | \nNum. commande | \nVARCHAR(8) | \n
| INCLURE | \nQuantité | \nINTEGER | \n
| PRODUIT | \nLibellé | \nVARCHAR(50) | \n
| \" | \nPrix unitaire | \nDECIMAL(10,2) | \n
| \" | \nRéf. produit | \nVARCHAR(8) | \n
Nouveauté de la version 4.3. Avec l'option -t prompt:types, Mocodo compose un prompt à copier-coller sous ChatGPT (ou autre) pour compléter le MCD avec les types manquants. Ce prompt est trop long pour être reproduit ici : il consiste en une présentation de la syntaxe de Mocodo, des instructions sur le travail demandé, plusieurs exemples corrigés, et enfin le MCD à compléter. Voici par exemple les types générés par Claude 3.5 Haiku pour le MCD de la page d'accueil de Mocodo online :
%%mocodo -t data_dict\nAYANT-DROIT: nom ayant-droit [VARCHAR(100)], lien [VARCHAR(50)]\nDIRIGER, 0N [responsable] EMPLOYÉ, 01 PROJET\nREQUÉRIR, 1N PROJET, 0N PIÈCE: qté requise [INTEGER]\nPIÈCE: réf. pièce [VARCHAR(20)], libellé pièce [VARCHAR(255)]\nCOMPOSER, 0N [composée] PIÈCE, 0N [composante] PIÈCE: quantité [INTEGER]\n\nDF, _11 AYANT-DROIT, 0N EMPLOYÉ\nEMPLOYÉ: matricule [VARCHAR(20)], nom employé [VARCHAR(100)]\nPROJET: num. projet [VARCHAR(20)], nom projet [VARCHAR(255)]\nFOURNIR, 1N PROJET, 1N PIÈCE, 1N SOCIÉTÉ: qté fournie [INTEGER]\n\nDÉPARTEMENT: num. département [VARCHAR(20)], nom département [VARCHAR(100)]\nEMPLOYER, 11 EMPLOYÉ, 1N DÉPARTEMENT\nTRAVAILLER, 0N EMPLOYÉ, 1N PROJET\nSOCIÉTÉ: num. société [VARCHAR(20)], raison sociale [VARCHAR(255)]\nCONTRÔLER, 0N< [mère] SOCIÉTÉ, 01 [filiale] SOCIÉTÉ\n\n\n\nsandbox_data_dict_3.md\n\n\n
| Entité ou association | \nLibellé de l'attribut | \nType | \n
|---|---|---|
| AYANT-DROIT | \nlien | \nVARCHAR(50) | \n
| \" | \nnom ayant-droit | \nVARCHAR(100) | \n
| COMPOSER | \nquantité | \nINTEGER | \n
| DÉPARTEMENT | \nnom département | \nVARCHAR(100) | \n
| \" | \nnum. département | \nVARCHAR(20) | \n
| EMPLOYÉ | \nmatricule | \nVARCHAR(20) | \n
| \" | \nnom employé | \nVARCHAR(100) | \n
| FOURNIR | \nqté fournie | \nINTEGER | \n
| PIÈCE | \nlibellé pièce | \nVARCHAR(255) | \n
| \" | \nréf. pièce | \nVARCHAR(20) | \n
| PROJET | \nnom projet | \nVARCHAR(255) | \n
| \" | \nnum. projet | \nVARCHAR(20) | \n
| REQUÉRIR | \nqté requise | \nINTEGER | \n
| SOCIÉTÉ | \nnum. société | \nVARCHAR(20) | \n
| \" | \nraison sociale | \nVARCHAR(255) | \n
Ce problème d'inférence n'est pas très difficile pour une IA. Les résultats devraient être très bons, surtout en comparaison de ceux de la version purement algorithmique, qui sont généralement incomplets :
\n%%mocodo -t guess:types data_dict --select cv\nAYANT-DROIT: nom ayant-droit, lien\nDIRIGER, 0N [responsable] EMPLOYÉ, 01 PROJET\nREQUÉRIR, 1N PROJET, 0N PIÈCE: qté requise\nPIÈCE: réf. pièce, libellé pièce\nCOMPOSER, 0N [composée] PIÈCE, 0N [composante] PIÈCE: quantité\n\nDF, _11 AYANT-DROIT, 0N EMPLOYÉ\nEMPLOYÉ: matricule, nom employé\nPROJET: num. projet, nom projet\nFOURNIR, 1N PROJET, 1N PIÈCE, 1N SOCIÉTÉ: qté fournie\n\nDÉPARTEMENT: num. département, nom département\nEMPLOYER, 11 EMPLOYÉ, 1N DÉPARTEMENT\nTRAVAILLER, 0N EMPLOYÉ, 1N PROJET\nSOCIÉTÉ: num. société, raison sociale\nCONTRÔLER, 0N< [mère] SOCIÉTÉ, 01 [filiale] SOCIÉTÉ\n\n\n\nsandbox_data_dict_3.md\n\n\n
| Entité ou association | \nLibellé de l'attribut | \nType | \n
|---|---|---|
| AYANT-DROIT | \nlien | \n\n |
| \" | \nnom ayant-droit | \nVARCHAR(255) | \n
| COMPOSER | \nquantité | \nINTEGER | \n
| DÉPARTEMENT | \nnom département | \nVARCHAR(255) | \n
| \" | \nnum. département | \nVARCHAR(8) | \n
| EMPLOYÉ | \nmatricule | \n\n |
| \" | \nnom employé | \nVARCHAR(255) | \n
| FOURNIR | \nqté fournie | \nINTEGER | \n
| PIÈCE | \nlibellé pièce | \n\n |
| \" | \nréf. pièce | \nVARCHAR(8) | \n
| PROJET | \nnom projet | \nVARCHAR(255) | \n
| \" | \nnum. projet | \nVARCHAR(8) | \n
| REQUÉRIR | \nqté requise | \nINTEGER | \n
| SOCIÉTÉ | \nnum. société | \nVARCHAR(8) | \n
| \" | \nraison sociale | \n\n |
Tracé d'un MCD : principes¶
\nMocodo combine les avantages de l'approche diagram as code (comme PlantUML, Mermaid ou Graphviz), avec la liberté de positionnement offerte par les logiciels WYSIWYG (what you see is what you get).
\nSa grande originalité est de se baser sur l'ordre et la séparation des lignes de la description pour définir une mise en page qui se révèle suffisante dans la majorité des cas.
\nLe pont aux ânes du langage Mocodo¶
\nPremier principe : les boîtes (entités et associations) définies sur des lignes consécutives sont tracées sur une seule rangée.
\nSi l'on écrit les définitions sur des lignes consécutives, on se retrouve donc vite avec des chevauchements qui ne sautent pas forcément aux yeux :
\n%%mocodo\nCLIENT: Réf. client, Nom, Prénom, Adresse\nCOMMANDE: Num. commande, Date, Montant\nPRODUIT: Réf. produit, Libellé, Prix unitaire\nPASSER, 0N CLIENT, 11 COMMANDE\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantité\nL'option --detect_overlaps (active par défaut sous Mocodo online) signale le problème et donne la solution :
%mocodo -i sandbox --detect_overlaps\nMocodo Err.29 - Mauvaise disposition des boîtes :\n - La patte « INCLURE — COMMANDE » chevauche « PRODUIT ».\n - La patte « INCLURE — PRODUIT » chevauche « PASSER ».\n - La patte « PASSER — CLIENT » chevauche « COMMANDE ».\n - Les pattes « PASSER — COMMANDE » et « INCLURE — COMMANDE » se chevauchent.\nPour corriger cela, réordonnez et/ou sautez des lignes dans le texte-source, soit à la\nmain, soit à l'aide de l'option -t arrange (tablette de chocolat sous Mocodo online).\n
Limitation. Seuls les chevauchements mettant en jeu des pattes horizontales ou verticales sont détectés.
\nMCD sur plusieurs lignes¶
\nDeuxième principe : pour commencer une nouvelle rangée, il faut sauter une ligne :
\n%%mocodo\nSCELERISQUE LOREM: blandit, elit, ligula\nEROS, 11 SCELERISQUE LOREM, 1N PELLENTESQUE IPSUM: metus, congue\n\nNIBH, 1N SCELERISQUE LOREM, 11 PELLENTESQUE IPSUM\nPELLENTESQUE IPSUM: tincidunt, bibendum, consequat, integer\nLes centres des boîtes sont placés aux intersections d'une grille invisible. Ils sont donc alignés aussi bien horizontalement que verticalement. De plus, dans un but esthétique, le dessin fait l'objet d'une compression dans les deux dimensions. Par exemple, ci-dessus, un espace horizontal négatif a été créé entre le bord droit de l'entité de gauche et le bord gauche de l'entité de droite.
\nMise en miroir¶
\nMocodo permet de calculer facilement les symétriques d'un MCD :
\n- \n
- verticalement :
-t flip:v; \n - horizontalement :
-t flip:h; \n - selon la seconde diagonale (transposition) :
-t flip:d. \n - selon la première diagonale (transposition) :
-t flip:vhd. \n
%mocodo -i sandbox --select mcd -t flip:h\nCorrections de la version 4.0.
\n- \n
- Les sens de « horizontal » et « vertical » sont permutés pour être plus conformes à l'intuition. \n
- La documentation parlait de première diagonale, c'était la seconde, et vice-versa. \n
Astuce. Transposez le MCD temporairement pour réaliser plus facilement certaines opérations d'édition en colonne, en particulier sous Mocodo online.
\nInsertion d'espacements¶
\nMocodo centre les rangées qui contiennent moins de boîtes que les autres. Ce comportement n'est pas toujours idéal :
\n%%mocodo \nUltrices, 01 Aliquet, 0N Aliquet\nAliquet: hendrerit, metus, lacus, quis\nRisus, 1N Aliquet, 0N Massa\nMassa: metus, posuere\nEuismod, 0N Massa, 0N Massa\n\nConvallis, 0N Aliquet, 0N Ante: vestibulum\nTincidunt, 11 Ante, 0N Massa\n\nGravida: ornare\nRutrum, 0N Gravida, 0N Ante, 0N Aliquet: faucibus, curae\nAnte: vitae, tempor\nL'utilisateur peut alors spécifier les espacements qu'il désire en complétant les rangées par des boîtes invisibles dont le seul rôle est de « pousser » les autres à l'emplacement voulu. Cela se fait en insérant manuellement des lignes réduites au caractère deux-points :
\n%%mocodo\nUltrices, 01 Aliquet, 0N Aliquet\nAliquet: hendrerit, metus, lacus, quis\nRisus, 1N Aliquet, 0N Massa\nMassa: metus, posuere\nEuismod, 0N Massa, 0N Massa\n\n:\n:\nConvallis, 0N Aliquet, 0N Ante: vestibulum\nTincidunt, 11 Ante, 0N Massa\n\nGravida: ornare\nRutrum, 0N Gravida, 0N Ante, 0N Aliquet: faucibus, curae\n:\nAnte: vitae, tempor\nRéarrangement automatique¶
\nCependant, en général, ces manipulations sont inutiles : Mocodo est capable de calculer tout seul des plongements à la fois compacts et esthétiques. Voici une compilation des réarrangements automatiques du MCD précédent produits par :
\n%mocodo -i sandbox -t arrange --seed 1\n%mocodo -i sandbox -t arrange --seed 2\n%mocodo -i sandbox -t arrange --seed 3\n%mocodo -i sandbox -t arrange --seed 4\n%mocodo -i ../examples/four_random_layouts --scale 0.8\nExtensions du modèle¶
\nEntité faible (ou identification relative)¶
\nPréfixez d'un tiret bas (_) une cardinalité 11 pour indiquer que l'entité distinguée est faible.
%%mocodo\nŒUVRE: Cote œuvre, Titre, Date parution\nDF, 1N ŒUVRE, _11 EXEMPLAIRE\nEXEMPLAIRE: Num. exemplaire, État du livre, Date d'achat\nDans le diagramme, les identifiants (ou plutôt, discriminateurs) d'une telle entité seront soulignés en pointillés, tandis que le 11 sera par défaut souligné d'un trait plein.
\nNotez qu'un discriminateur n'est pas toujours obligatoire :
\n%%mocodo \nEmployé: Num. employé, Nom employé, Prénom employé\nDf, _11 Conjoint, 01 Employé\nConjoint: _Nom conjoint, Prénom conjoint\nSon absence implique cependant que l'occurrence de l'entité forte qui « renforce » une occurrence de l'entité faible ne peut en renforcer une autre : d'où la cardinalité maximale 1 sur la patte distinguant EMPLOYÉ.
\nMocodo rejettera donc la version « polygame » du MCD précédent (avec 0N à la place de 01) :
\n%%mocodo\nEmployé: Num. employé, Nom employé, Prénom employé\nDf, _11 Conjoint, 0N Employé\nConjoint: _Nom conjoint, Prénom conjoint\nMocodo Err.50 - L'entité faible « CONJOINT » devrait avoir un discriminateur.\n
Héritage (généralisation / spécialisation)¶
\nL'héritage permet de regrouper dans une entité, dite « mère », les attributs communs à plusieurs autres entités, dites « filles », qui se distinguent les unes des autres par des attributs spécifiques.
\nPour définir une spécialisation, insérez une ligne spécifiant :
\n$$\n\\overbrace{\\texttt{/}\\,\\texttt{XT}\\,\\texttt{\\\\}}^{\\text{sa nature entre barres obliques}}\n\\qquad\n\\overbrace{\\texttt{<}\\,\\texttt{-}}^{\\text{son type de flèche}}\n\\qquad\n\\overbrace{\\texttt{mère}}^{\\text{une entité}}\n\\qquad\n\\overbrace{\\texttt{,}}^{\\text{une virgule}}\n\\qquad\n\\overbrace{\\texttt{fille 1, fille 2, fille 3}}^{\\text{des entités séparées par des virgules}}\n\\qquad\n\\overbrace{\\texttt{: discriminateur}}^{\\text{optionnellement, un attribut}}\n$$
\n%%mocodo\nPersonne: num SS, nom, prénom\n\n/XT\\ Personne <- Homme, Femme: sexe\n\nHomme: \n:\nFemme: nom de jeune fille\nInscrivez dans le triangle les symboles de votre choix pour prendre une part active aux guerres culturelles de notre temps :
\n| Totalité | \nExclusion | \nSymboles | \nExemple de population | \nToute personne est : | \n
|---|---|---|---|---|
| oui | \noui | \n/XT\\ | \n♂♂♂♂♂♂♂ ♀♀♀♀♀♀♀♀♀♀ | \n- soit un homme - soit une femme | \n
| non | \noui | \n/X\\ | \n♂♂♂♂♂♂♂♂ ♀♀♀♀♀♀ ○○○○ | \n- soit un homme - soit une femme - soit aucun des deux | \n
| oui | \nnon | \n/T\\ | \n♂♂♂♂♂♂ ♀♀♀♀♀♀♀♀ ⚥⚥⚥⚥ | \n- soit un homme - soit une femme - soit les deux à la fois | \n
| non | \nnon | \n/\\ | \n♂♂♂♂♂ ♀♀♀♀♀♀ ○○○○ ⚥⚥⚥⚥ | \n- soit un homme - soit une femme - soit aucun des deux - soit les deux à la fois | \n
Contrainte inter-associations¶
\nPour définir une telle contrainte, ajoutez n'importe où une ligne spécifiant :
\n$$\n\\overbrace{\\texttt{(}\\,\\texttt{FOO}\\,\\texttt{)}}^{\\text{son nom entre parenthèses}}\n\\quad\n\\overbrace{\n \\texttt{-}\\,\\texttt{>}\n \\texttt{boîte 1,}\n \\quad\n \\texttt{.}\\,\\texttt{.}\n \\texttt{boîte 2,}\n \\quad\n \\texttt{-}\\,\\texttt{-}\n \\texttt{boîte 3,}\n \\quad\n \\texttt{boîte 4}\n}^{\\text{les types de liens et les boîtes qu'elle met en jeu, séparés par des virgules}}\n\\quad\n\\overbrace{\\texttt{:}\\,\\,\\texttt{horizontale, verticale}}^{\\text{optionnellement, ses coordonnées}}\n$$
\nPrécisions.
\n- \n
- Comme leur nom ne l'indique pas, ces contraintes peuvent aussi bien porter sur des entités que des associations. \n
- Le nom d'une contrainte peut être formé de zéro à trois symboles quelconques. \n
- Un lien est soit vide (trait invisible), soit formé d'un ou plusieurs symboles
-(trait plein) ou.(trait pointillé), optionnellement précédés d'un symbole<(flèche vers la contrainte) et/ou suivis d'un symbole>(flèche vers la boîte). \n - Au contraire des boîtes (entités et associations), les contraintes ne sont pas... contraintes par la grille sous-jacente : la mise en page du MCD n'en tient absolument pas compte. Celui de l'exemple ci-dessous a donc dû être « aéré » avec des
:pour leur faire de la place. \n - Les clauses de définition des contraintes peuvent apparaître n'importe où. Notez cependant que tout réarrangement automatique les enverra systématiquement à la fin du texte-source. \n
- Chaque coordonnée du centre de la contrainte peut être exprimée sous la forme :
- \n
- d'une référence à une boîte sur laquelle l'aligner horizontalement ou verticalement (respectivement) ; \n
- d'un pourcentage de la largeur ou de la hauteur (respectivement) du MCD. \n
\n - En l'absence de coordonnées, la contrainte est placée au barycentre des boîtes qu'elle relie. \n
Voici un exemple concret, adapté de la Fig. 7.37 de Merise, deuxième génération (Dominique Nanci et Bernard Espinasse, 4e éd., 2001) :
\n%%mocodo -t\n:::\nDépôt: num dépôt, surface\n\n:\nLouer, 11 Commande, 0N Dépôt\n:\nStocker, 1N Dépôt, 1N Article: quantité\n\nCommande: num. commande, date\nComposer, 1N Commande, 0N Article\n:\nArticle: réf. article, prix\n\n(I) ->Stocker, ..Dépôt, ..Article, --Composer, --Louer, Commande\n- \n
- Article (réf. article, prix) \n
- Commande (num. commande, date, #num dépôt) \n
- Composer (#num. commande, #réf. article) \n
- Dépôt (num dépôt, surface) \n
- Stocker (#num dépôt, #réf. article, quantité) \n
Notez que pour Mocodo, ces contraintes sont purement décoratives : le passage au niveau relationnel ou physique n'en tient pas compte.
\nAgrégat (ou pseudo-entité)¶
\nDans le MCD ci-dessous, le petit rond et l'enveloppe pointillée indiquent qu'une réservation d'une chambre donnée à une date donnée ne peut être faite que par un seul client :
\n%%mocodo --colors ocean # changement de palette pour faire apparaître un fond semi-transparent \nDate: Date\nRéserver, /1N Client, 1N Chambre, 0N Date: Durée\nChambre: Num. chambre, Prix\n\nClient: Id. client\nLa syntaxe est minimale : une simple barre oblique / avant la cardinalité de l'entité-cible.
S'il y a au maximum deux entités à agréger, et que l'angle formé par l'association et les entités est plat ou rectangle, une enveloppe de points matérialise la pseudo-entité.
\nSinon, pour des raisons de simplicité du code et de clarté du diagramme, l'enveloppe n'est pas affichée. Cependant, le petit rond subsiste et le reste des traitements est bien sûr inchangé.
\nRemarques.
\n- \n
- La représentation traditionnelle demanderait à insérer une association DF entre CLIENT et RÉSERVER. Mais permettre l'association d'une entité et d'une association demanderait à apporter au code de Mocodo des changements conséquents, pour un bénéfice qui ne nous saute pas forcément aux yeux. \n
- Les agrégats sur association binaire sont soit inutiles (sur une DF), soit impossibles (sur une non-DF, ils reviennent à permettre à une même occurrence d'entité de renforcer plusieurs occurrences d'une entité faible sans discriminateur). Mocodo les interdit dans les deux cas. \n
CIF à unicité complète¶
\nLa notion d'agrégation n'a pas très bonne presse dans les milieux autorisés. Ceux-ci lui préfèrent généralement celle (équivalente) de contrainte d'intégrité fonctionnelle à unicité complète. Pour rentrer dans leurs bonnes grâces (et désactiver du même coup la visualisation de l'enveloppe et du petit rond), il suffit d'expliciter la contrainte correspondante dans le MCD précédent. Mocodo peut le faire pour vous :
\n%mocodo -i sandbox -t create:cifs arrange --seed=12 --colors ocean\n\n\n\nsandbox.mcd\n\n\n
%%mocodo --seed=12 --colors ocean\nDate: Date\nRéserver, /1N Client, 1N Chambre, 0N Date: Durée\nChambre: Num. chambre, Prix\n\n-INVISIBLE_1, XX Client, XX Client\nClient: Id. client\n:\n\n(CIF) ..Réserver, ->Client, --Chambre, --Date: INVISIBLE_1, INVISIBLE_1\n\n
Remarquez que la visibilité de la CIF est assurée par le positionnement de celle-ci sur une boîte invisible introduite à cet effet : si vous rectifiez ce positionnement, vous pouvez bien sûr supprimer cette boîte.
\nVous avez également le droit d'alléger la visualisation des CIFs complètes en transformant les traits pleins \"--\" des entités émettrices en traits invisibles \"\". Là encore, Mocodo peut le faire pour vous :
%mocodo -i sandbox -t create:cifs=light arrange --seed=12 --colors ocean\n\n\n\nsandbox.mcd\n\n\n
%%mocodo --seed=12 --colors ocean\nDate: Date\nRéserver, /1N Client, 1N Chambre, 0N Date: Durée\nChambre: Num. chambre, Prix\n\n-INVISIBLE_1, XX Client, XX Client\nClient: Id. client\n:\n\n(CIF) ..Réserver, ->Client, Chambre, Date: INVISIBLE_1, INVISIBLE_1\n\n
Limitation. Au niveau fonctionnel, c'est toujours la barre oblique qui conditionne le traitement des CIF. Par conséquent, les CIF à unicité incomplète ne sont prises en charge qu'au niveau visuel.
\nIdentifiants explicites dans les associations¶
\nMocodo 4.1.1 relaxe par défaut (sauf dans la version en ligne) la contrainte de Merise restreignant aux entités la présence d'identifiants. Si vous l'osez, vous pouvez donc obtenir le même schéma relationnel avec le MCD « allégé » suivant :
\n%%mocodo -t\nClient: Id. client\nRéserver, 1N Client, 0N Chambre: _Date, Durée\nChambre: Num. chambre, Prix\n- \n
- Chambre (Num. chambre, Prix) \n
- Réserver (Id. client, #Num. chambre, Date, Durée) \n
L'introduction de cette possibilité, surtout destinée à simplifier le plongement des MCD touffus, est discutée ici.
\nConversion d'un MCD¶
\nPassage au relationnel¶
\nIl se fait en deux étapes:
\n- \n
- la création d'une représentation interne complète du MLD ; \n
- la traduction de celle-ci en une représentation externe dans le ou les formats de sortie souhaités. \n
Pour construire la représentation interne, l'algorithme de base réalise la séquence d'opérations suivante :
\n- \n
- Pour chaque entité, une relation (table) de même nom et de mêmes attributs est créée. Le ou les identifiants de l'entité constituent la clé primaire de la relation. \n
- Toute relation issue d'une entité faible est renforcée, c'est-à-dire que la clé primaire de l'entité qu'elle détermine fonctionnellement vient s'adjoindre à sa clé primaire, au besoin de façon récursive. \n
- Les associations sont traitées ainsi : \n
- si toutes les pattes de l'association portent la cardinalité maximale N, une relation de même nom et de mêmes attributs est créée. Sa clé primaire est constituée de l'ensemble des clés primaires des relations issues des entités mises en jeu ; \n
- dans le cas contraire, c'est-à-dire si l'une des pattes de l'association porte la cardinalité (1,1), ou à défaut (0,1), l'entité distinguée se voit adjoindre :\n1. en tant que clés étrangères, l'ensemble des clés primaires des autres entités mises en jeu;\n2. en tant que simples attributs, l'ensemble des attributs de l'association. \n
Remarque. Un couple de cardinalités non standard, c'est-à-dire distinct de (0,1), (1,1), (0,N) et (1,N), est traité comme (0,1) si son deuxième symbole est un 1, et comme (0,N) sinon. Cela couvre en particulier les cas (*, 1), (*,N), (?,?) et (X,X).
\nPour construire la représentation externe, Mocodo formate la représentation interne à l'aide d'un gabarit. Près d'une centaine de gabarits sont fournis, qui permettent de produire quatre grandes catégories de résultats :
\n- \n
- le schéma relationnel dans toutes les combinaisons de formats (HTML, Markdown, texte brut, $\\LaTeX$) et d'options (avec ou sans explications, avec ou sans boilerplate, avec ou sans visualisation des contraintes d'unicité et d'optionalité) ; \n
- le diagramme relationnel au format Mocodo, avec ou sans visualisation des contraintes d'unicité et d'optionalité, ou dans des formats externes, comme DBML ou D2. \n
- le DDL en SQL ANSI et dans les principaux dialectes (Microsoft SQL Server, MySQL, Oracle DB, PostgreSQL, SQLite), avec ou sans boilerplate de création de la base ; \n
- le graphe des dépendances. \n
Niveau logique¶
\nSchéma relationnel¶
\nLa transformation -t mld opère la conversion d'un MCD (modèle conceptuel de données) en un MLD (modèle logique de données), autrement appelé schéma relationnel :
%mocodo -i ccp -t mld\n\n\n\nccp_mld.md\n\n\n
- \n
- Client (Réf. client, Nom, Prénom, Adresse) \n
- Commande (Num. commande, Date, Montant, #Réf. client) \n
- Inclure (#Num. commande, #Réf. produit, Quantité) \n
- Produit (Réf. produit, Libellé, Prix unitaire) \n
Sous Jupyter Notebook, comme pour toutes les opérations de conversion, le tracé du MCD est omis par défaut. Dans le cas très fréquent où l'on a besoin de visualiser simultanément le MCD et le MLD, on peut invoquer l'option -t sans arguments (ou encore --mld) :
%mocodo -i ccp -t\n- \n
- Client (Réf. client, Nom, Prénom, Adresse) \n
- Commande (Num. commande, Date, Montant, #Réf. client) \n
- Inclure (#Num. commande, #Réf. produit, Quantité) \n
- Produit (Réf. produit, Libellé, Prix unitaire) \n
Diagramme relationnel¶
\nLa plupart des SGBD offrent une représentation hybride (graphique / texte) de la base sous la forme de tables liées par des flèches. Nous l'appelons diagramme relationnel. Sous Mocodo :
\n%mocodo -i ccp --colors mondrian -t diagram\n\n\n\nccp_mld.svg\n\n\n
Le nom du fichier généré avant rendu graphique se termine par _mld.mcd. L'extension .mcd signifie que Mocodo peut le prendre comme texte-source (bien que ce ne soit pas un schéma conceptuel). Examinons son contenu :
display.Code(\"ccp_mld.mcd\", language=\"text\")\n%%mocodo\n:\nClient: Réf. client, Nom, Prénom, Adresse\n:\nCommande: Num. commande, Date, Montant, #Réf. client > Client > Réf. client\n:\nInclure: #Num. commande > Commande > Num. commande, _#Réf. produit > Produit > Réf. produit, Quantité\n:\nProduit: Réf. produit, Libellé, Prix unitaire\n:\nLa syntaxe d'un MLD est effectivement la même que celle d'un MCD, à ceci près que les associations sont remplacées par des liens allant de l'attribut a1 de l'entité E1 à l'attribut a2 de l'entité E2, et notés : E1: ... a1 > E2 > a2.
Les relations sont placées dans le même ordre que les boîtes du MCD d'origine. Vous devrez quelquefois les réarranger (automatiquement ou manuellement) pour obtenir un résultat plus esthétique. Notez que des boîtes invisibles ont été automatiquement insérées une colonne sur deux afin de laisser de la place aux flèches.
\nLimitation. Les clés étrangères composites sont actuellement représentées comme si elles étaient séparées (autant de flèches que de parties).
\nNouveautés de la version 4.0.
\n- \n
- Ce qui se notait
E1: ... a1->E2->a2se note maintenantE1: ... a1 > E2 > a2. \n - Sous Jupyter Notebook, un seule étape suffit pour visualiser le diagramme relationnel. \n
- Le nom du fichier intermédiaire se termine par
_mld.mcdau lieu de.mld. L'ancienne extension est abandonnée. \n
Niveau physique : DDL¶
\nSQL¶
\nLa principale raison de vivre d'un MCD est de se métamorphoser in fine en une chatoyante base de données relationnelles. Cela se fait au moyen d'un sous-ensemble du langage SQL appelé DDL (Data Definition Language). Sous Mocodo :
\n%mocodo -i ccp -t sql\n\n\n\nccp_ddl.sql\n\n\n
CREATE TABLE Client (\n PRIMARY KEY (Ref_client),\n Ref_client VARCHAR(8) NOT NULL,\n Nom VARCHAR(255),\n Prenom VARCHAR(255),\n Adresse VARCHAR(255)\n);\n\nCREATE TABLE Commande (\n PRIMARY KEY (Num_commande),\n Num_commande VARCHAR(8) NOT NULL,\n Date DATE,\n Montant DECIMAL(10,2),\n Ref_client VARCHAR(8) NOT NULL\n);\n\nCREATE TABLE Inclure (\n PRIMARY KEY (Num_commande, Ref_produit),\n Num_commande VARCHAR(8) NOT NULL,\n Ref_produit VARCHAR(8) NOT NULL,\n Quantite INTEGER\n);\n\nCREATE TABLE Produit (\n PRIMARY KEY (Ref_produit),\n Ref_produit VARCHAR(8) NOT NULL,\n Libelle VARCHAR(50),\n Prix_unitaire DECIMAL(10,2)\n);\n\nALTER TABLE Commande ADD FOREIGN KEY (Ref_client) REFERENCES Client (Ref_client);\n\nALTER TABLE Inclure ADD FOREIGN KEY (Ref_produit) REFERENCES Produit (Ref_produit);\nALTER TABLE Inclure ADD FOREIGN KEY (Num_commande) REFERENCES Commande (Num_commande);\nNotez le NOT NULL des clés primaires. Il s'agit d'une redondance, mais aussi d'une bonne pratique. Non seulement parce qu'explicit is better than implicit : elle peut se révéler utile, par exemple pour désactiver les contraintes de clé primaire pendant une maintenance tout en continuant à interdire le remplissage avec des NULL. Si cela vous gêne, nous montrons en annexe comment l'éliminer.
Principales nouveautés de la version 4.0.
\n- \n
- Génération automatique des contraintes
UNIQUE,NOT NULLetNULLappropriées. \n - Les libellés sont convertis en ASCII, et toute suite de caractères qui ne sont ni des lettres, ni des chiffres, ni des tirets bas sont remplacés par un unique tiret bas. Cela simplifie la référence aux tables et aux champs, et évite de noyer le DDL sous un essaim de délimiteurs (qui plus est spécifiques à chaque dialecte). Ainsi, « Réf. client » se trouvera transformé en
Ref_client. \n - Vos choix de casse (minuscules, MAJUSCULES, snake_case, camelCase, PascalCase, etc.) sont respectés. \n
Inférence de type¶
\nAvec l'option de réécriture -t create:types Mocodo essaiera d'inférer des libellés des attributs tout type manquant. La langue définie avec l'option --language est prioritaire, mais l'anglais prend la relève en cas d'échec.
%%mocodo -t create:types --select rw\nCustomer: Customer ID, Last Name, First Name, Address\nMake Order, 0N Customer, 11 Order\nOrder: Order Number, Date, Amount\nINCLUDE, 1N Order, 0N Product: Quantity\nProduct: Product ID, Description, Unit Price\n\n\n\nsandbox.mcd\n\n\n
%%mocodo --select rw\nCustomer: Customer ID [VARCHAR(8)], Last Name [VARCHAR(255)], First Name [VARCHAR(255)], Address [VARCHAR(30)]\nMake Order, 0N Customer, 11 Order\nOrder: Order Number [VARCHAR(8)], Date [DATE], Amount [DECIMAL(10,2)]\nINCLUDE, 1N Order, 0N Product: Quantity [INTEGER]\nProduct: Product ID [VARCHAR(8)], Description [TEXT], Unit Price [DECIMAL(10,2)]\n\n
Il va de soi que les types inférés devront être systématiquement contrôlés, et parfois corrigés ou complétés. Une discussion sur StackOverflow, Common MySQL fields and their appropriate data types, a servi de point de départ. La liste des types utilisée est celle de Wikipedia. Consultez les correspondances spécifiées dans mocodo/resources/default_datatypes_fr.tsv, etc. pour plus de détails, et n'hésitez pas à ouvrir le débat si vous avez des corrections ou des suggestions.
Si vous préférez tout typer à la main, vous pouvez au moins créer les « cases » à remplir :
\n%%mocodo -t create:types=[] --select rw\nCustomer: Customer ID, Last Name, First Name, Address\nMake Order, 0N Customer, 11 Order\nOrder: Order Number, Date, Amount\nINCLUDE, 1N Order, 0N Product: Quantity\nProduct: Product ID, Description, Unit Price\n\n\n\nsandbox.mcd\n\n\n
%%mocodo --select rw\nCustomer: Customer ID [], Last Name [], First Name [], Address []\nMake Order, 0N Customer, 11 Order\nOrder: Order Number [], Date [], Amount []\nINCLUDE, 1N Order, 0N Product: Quantity []\nProduct: Product ID [], Description [], Unit Price []\n\n
Dialectes de SQL¶
\nL'argument sql peut être remplacé par un nom de dialecte parmi mysql, oracle, postgresql, sqlite et (nouveauté de la version 4) mssql. Quelques transformations seront alors appliquées au code-source généré. Du fait de l'uniformisation de la syntaxe apportée par la version 4, elles sont assez minimes.
Notez les points suivants :
\n- \n
- Mocodo ne touche pas aux types spécifiés par l'utilisateur. Une traduction inter-dialectes automatique est envisageable dans le futur, mais c'est un problème qui n'a en réalité aucune solution satisfaisante. \n
- Mocodo protège les noms de tables ou de colonnes qui se trouveraient faire partie des mots réservés par le dialecte-cible. Par exemple, ci-dessous, les noms
USERetMEMBERsont réservés en MySQL. Les listes viennent du site modern-sql.com de Markus Winand, et plus précisément de la page https://modern-sql.com/reserved-words-empirical-list. \n - Avec la sous-sous-option
b, un boilerplate de création de la base est ajouté en préambule. \n
%%mocodo -t mysql:b\nUSER: username, mail, member\n\n\n\nsandbox_ddl_mysql.sql\n\n\n
CREATE DATABASE IF NOT EXISTS `MCD`\n CHARACTER SET utf8mb4\n COLLATE utf8mb4_general_ci\n;\nUSE `MCD`;\n\nCREATE TABLE `USER` (\n PRIMARY KEY (username),\n username VARCHAR(42) NOT NULL,\n mail VARCHAR(42),\n `member` VARCHAR(42)\n);\nNotes sur les règles de passage¶
\nGénération de contraintes d'optionalité et d'unicité¶
\nAvec la sous-sous-option c, Mocodo peut faire apparaître dès le niveau logique certaines contraintes du niveau physique. Les notations sont les suivantes :
| Contrainte | \nniveau logique | \nniveau physique | \n
|---|---|---|
| non-optionalité | \nattribut! | \nNOT NULL | \n
| optionalité | \nattribut? | \nNULL | \n
| unicité | \nattribut $^{u1\\ u2...}$ | \nUNIQUE | \n
Par exemple, ci-dessous, la clé étrangère #Réf_client est maintenant marquée comme non optionnelle :
\n%mocodo -i ccp -t mld:c\n\n\n\nccp_mld.md\n\n\n
- \n
- Client (Réf. client, Nom, Prénom, Adresse) \n
- Commande (Num. commande, Date, Montant, #Réf. client!) \n
- Inclure (#Num. commande, #Réf. produit, Quantité) \n
- Produit (Réf. produit, Libellé, Prix unitaire) \n
La clé étrangère #id entreprise est marquée comme optionnelle :
\n%%mocodo --select all -t mld:c\nEntreprise: id. entreprise, raison, activité, adresse\nEnvoyer, 0N Entreprise, 01 Participant\nParticipant: id. inscrit, nom, adresse\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Entreprise (id. entreprise, raison, activité, adresse) \n
- Participant (id. inscrit, nom, adresse, #id. entreprise?) \n
La clé étrangère #id employé est marquée comme unique :
\n%%mocodo --select all -t mld:c\nEMPLOYÉ: id. employé, nom employé\nDIRIGER, 11 DÉPARTEMENT, 01 EMPLOYÉ\nDÉPARTEMENT: id. département, nom département\n\n\n\nsandbox_mld.md\n\n\n
- \n
- DÉPARTEMENT (id. département, nom département, #id. employé! u1) \n
- EMPLOYÉ (id. employé, nom employé) \n
Ajout manuel de contraintes d'optionalité et d'unicité¶
\nLes contraintes NOT NULL ou NULL spécifiées dans les types peuvent également faire l'objet d'une visualisation au niveau relationnel :
%%mocodo -t mld:c\nPersonne: id. personne [VARCHAR(8)], nom [VARCHAR(255) NOT NULL], prénom [VARCHAR(255)], nom de jeune fille [VARCHAR(255) NULL]\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Personne (id. personne, nom!, prénom, nom de jeune fille?) \n
Pour les contraintes d'unicité, qui peuvent s'appliquer à plusieurs groupes d'attributs potentiellement non disjoints, la notation est un peu plus complexe. Voici un exemple proposé par Fabien Duchateau :
\n%%mocodo --select all -t mld:c --shapes trebuchet # changement de police de caractères pour mieux distinguer les 1 des I\nCLIENT: Réf. client, 1_Nom, 1_Prénom, Adresse, 2_Mail\n\n\n\nsandbox_mld.md\n\n\n
- \n
- CLIENT (Réf. client, Nom u1, Prénom u1, Adresse, Mail u2) \n
C'est l'occasion d'introduire quelques définitions :
\n- \n
- On appelle identifiant candidat d'une entité tout sous-ensemble minimal d'attributs dont chaque occurrence est unique. \n
- Parmi ces sous-ensembles, l'un est élu identifiant (tout court), souligné, et appelé à devenir clé primaire lors du passage au relationnel. \n
- Les candidats malheureux sont appelés identifiants alternatifs. \n
Ainsi, dans l'exemple précédent, l'ensemble des identifiants candidats de CLIENT est constitué de :
\n- \n
- l'identifiant proprement dit Réf. client ; \n
- l'identifiant alternatif (Nom, Prénom) (dont on supposera pour les besoins de la cause qu'il assure l'unicité) ; \n
- l'identifiant alternatif Mail. \n
Par défaut, dès la première déclaration d'un identifiant alternatif, Mocodo fait apparaître une gouttière à gauche des attributs de toutes les entités. Y sont portés :
\n- \n
- un symbole « ID » (resp. « id ») pour l'identifiant fort (resp. faible). \n
- des chiffres de 1 à 9 correspondant aux numéros des identifiants alternatifs. \n
La notation de Mocodo permet de faire de n'importe quels sous-ensembles d'attributs des identifiants alternatifs. Ci-dessous, le premier identifiant alternatif est le triplet (bar, biz, quux), le second (biz, buz, quux) et le troisième (qux, quux) :
\n%%mocodo --select all -t markdown:c sql --shapes trebuchet\nFOO: foo, 1_bar, 12_biz, 2_buz, 3_qux, 123_quux\n\n\n\nsandbox_mld.md\n\n\n
- \n
- FOO (foo, bar u1, biz u1 u2, buz u2, qux u3, quux u1 u2 u3) \n
\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE FOO (\n PRIMARY KEY (foo),\n foo VARCHAR(42) NOT NULL,\n bar VARCHAR(42),\n biz VARCHAR(42),\n buz VARCHAR(42),\n qux VARCHAR(42),\n quux VARCHAR(42),\n UNIQUE (bar, biz, quux),\n UNIQUE (biz, buz, quux),\n UNIQUE (qux, quux)\n);\nExaminons le cas exceptionnel où l'identifiant à souligner a un attribut commun avec un identifiant alternatif. Ce dernier devant être distinct et minimal, cela implique que l'identifiant est composite.
\n%%mocodo --shapes trebuchet\nEntité 1_: 1_foo, _bar, 1_biz\nEntité 2_: foo, 1_bar, 1_biz\nEntité 3_: foo, 01_bar, 1_biz\n- \n
- Si l'attribut commun est en tête de liste (ici, foo, entité 1), rien ne change, on écrit
1_foo. \n - S'il n'est pas en tête de liste (ici, bar, entité 2), l'écriture
1_bardénote déjà l'appartenance à un identifiant alternatif. Elle ne peut dénoter simultanément l'appartenance à l'identifiant à souligner. \n - C'est pourquoi on doit donc expliciter l'appartenance à l'identifiant à souligner qui, comme on l'a vu, est numéroté
0(entité 3). \n
Un sous-cas demande encore réflexion : celui où le premier attribut ne fait pas partie de l'identifiant à souligner (entité 4). Si l'on veut alors que ce premier attribut appartienne à une clé alternative, il faut expliciter le 0 (entité 5).
%%mocodo --shapes trebuchet\nEntité 40: _foo, _bar, biz\nEntité 50: 01_foo, _bar, 1_biz\nEn résumé, on explicite le 0, soit pour empêcher le soulignement du premier attribut, soit pour forcer le soulignement d'un attribut suivant.
Cela devrait vous rappeler quelque chose… Remplacez 0 par _ dans la phrase précédente et vous retrouverez la règle que vous avez appris à connaître et à aimer : on explicite le _, soit pour empêcher le soulignement du premier attribut, soit pour forcer le soulignement d'un attribut suivant.
Gestion des entités faibles (identification relative)¶
\nDans ce joli exemple dû à Idris NEUMANN, Initiation à la conception de bases de données relationnelles avec MERISE, les renforcements successifs aboutissent à faire entrer l'identifiant de RUE dans celui de APPARTEMENT, alors même que ces entités sont séparées par non moins de trois associations :
\n%%mocodo -t\nAppartement: num appart., nb pièces\nComposer, 0N Étage, _11 Appartement\nÉtage: num étage, nb appartements\nAppartenir, 1N Immeuble, _11 Étage\nImmeuble: num immeuble, nb étages\nSe situer, 0N Rue, _11 Immeuble\nRue: code rue, nom rue\n- \n
- Appartement (#code rue, #num immeuble, #num étage, num appart., nb pièces) \n
- Étage (#code rue, #num immeuble, num étage, nb appartements) \n
- Immeuble (#code rue, num immeuble, nb étages) \n
- Rue (code rue, nom rue) \n
Le résultat apparaît plus clairement sur le diagramme relationnel :
\n%mocodo -i sandbox -t diagram --colors mondrian\n\n\n\nsandbox_mld.svg\n\n\n
Une phase préliminaire de l'algorithme de passage au relationnel consiste à « renforcer » les entités faibles de façon à traiter uniquement des identifiants forts dans la suite. Cela permet la gestion des renforcements en cascade comme ci-dessus, ainsi que la détection des problèmes de renforcement cyclique :
\n%%mocodo\nPick, 0N Land, _11 Peer\nLand: true, hold\n\nPeer: foot, city\nZone, 1N Peer, _11 Land\n%mocodo -i sandbox -t\nMocodo Err.17 - Cycle d'entités faibles dans \"Land\", \"Peer\".\n
Gestion de l'héritage¶
\nLa bonne gestion d'un héritage est primordiale, tant du point de vue de la préservation du patrimoine, que de l'optimisation des ressources financières, de la minimisation des conflits familiaux et du respect des dernières volontés du défunt. Je blague.
\nAdaptons ici un exemple d'un cours de Stéphane Crozat. Nous reprenons sa terminologie et donnons en parallèle celle introduite par Martin Fowler dans Patterns of Enterprise Application Architecture, Addison-Wesley (2003).
\nCi-dessous, l'héritage est considéré comme total (tout document est soit un ouvrage, soit une thèse, soit les deux). Crozat passe en revue trois mécanismes possibles pour le passage au relationnel.
\n\n
L'héritage par référence (en anglais, Class Table Inheritance ou Table Per Type Inheritance) se note en Mocodo par une flèche simple allant vers les filles. Une référence à la table-mère sera ajoutée dans chaque table-fille comme clé étrangère. L'intérêt de cette solution est en raison directe du nombre d'attributs non identifiants de l'entité-mère.
\n%%mocodo --select all -t mld:c\nDOCUMENT: cote, titre, auteur\n \nOUVRAGE: éditeur\n/T\\ DOCUMENT -> OUVRAGE, THÈSE\nTHÈSE: discipline, université\n\n\n\nsandbox_mld.md\n\n\n
- \n
- DOCUMENT (cote, titre, auteur) \n
- OUVRAGE (#cote, éditeur) \n
- THÈSE (#cote, discipline, université) \n
\n
L'héritage par absorption dans les tables-filles (en anglais, Concrete Table Inheritance ou Table Per Concrete Inheritance) se note en doublant la flèche :
\n- \n
- les attributs de la table-mère sont reproduits dans chacune des filles. Pour chaque document qui est à la fois un ouvrage et une thèse, il y aura donc duplication des triplets (cote, titre, auteur). \n
- la table-mère disparaît. Pour éviter de perdre les informations sur les documents qui ne seraient ni des ouvrages, ni des thèses, Mocodo lève une erreur si l'héritage n'est pas total (T ou XT). \n
%%mocodo --select all -t mld:c\nDOCUMENT: cote, titre, auteur\n \nOUVRAGE: éditeur\n/T\\ DOCUMENT => OUVRAGE, THÈSE\nTHÈSE: discipline, université\n\n\n\nsandbox_mld.md\n\n\n
- \n
- OUVRAGE (cote, titre, auteur, éditeur) \n
- THÈSE (cote, titre, auteur, discipline, université) \n
\n
L'héritage par absorption dans la table-mère (en anglais, Single Table Inheritance ou Table Per Hierarchy Inheritance) se note par une flèche simple allant vers la mère. Les tables-filles disparaissent, et leurs attributs migrent dans la mère avec une contrainte d'optionalité (point d'interrogation en relationnel, NULL en SQL).
%%mocodo --select all -t mld:c sql\nDOCUMENT: cote, titre, auteur\n\nOUVRAGE: éditeur\n/X\\ DOCUMENT <- OUVRAGE, THÈSE: discriminateur [ENUM ('OUVRAGE', 'THÈSE')]\nTHÈSE: discipline, université\n\n\n\nsandbox_mld.md\n\n\n
- \n
- DOCUMENT (cote, titre, auteur, discriminateur?, éditeur?, discipline?, université?) \n
\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE DOCUMENT (\n PRIMARY KEY (cote),\n cote VARCHAR(42) NOT NULL,\n titre VARCHAR(42),\n auteur VARCHAR(42),\n discriminateur ENUM ('OUVRAGE', 'THÈSE') NULL,\n editeur VARCHAR(42) NULL,\n discipline VARCHAR(42) NULL,\n universite VARCHAR(42) NULL\n);\nCi-dessus, nous avons donné comme « attribut » au triangle d'héritage un « discriminateur » de type ENUM. Cela ajoute à la table un champ optionnel ou non (selon que l'héritage est partiel ou total) permettant de déterminer à quel type concret d'une occurrence on a affaire.
C'est par défaut un UNSIGNED INT, qui pourra prendre les valeurs :
- \n
- 1 = OUVRAGE, 2 = THÈSE, pour l'héritage exclusif ; \n
- 1 ($2^0$) = OUVRAGE, 2 ($2^1$) = THÈSE, 3 ($2^0 | 2^1$) = OUVRAGE + THÈSE, pour l'héritage non exclusif. \n
Alternativement à l'emploi d'un discriminateur, Mocodo peut ajouter un drapeau booléen par table-fille. Cela se note en doublant la flèche :
\n%%mocodo --select all -t mld:c sql\nDOCUMENT: cote, titre, auteur\n\nOUVRAGE: éditeur\n/T\\ DOCUMENT <= OUVRAGE, THÈSE\nTHÈSE: discipline, université\n\n\n\nsandbox_mld.md\n\n\n
- \n
- DOCUMENT (cote, titre, auteur, est ouvrage!, éditeur?, est these!, discipline?, université?) \n
\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE DOCUMENT (\n PRIMARY KEY (cote),\n cote VARCHAR(42) NOT NULL,\n titre VARCHAR(42),\n auteur VARCHAR(42),\n est_ouvrage BOOLEAN NOT NULL,\n editeur VARCHAR(42) NULL,\n est_these BOOLEAN NOT NULL,\n discipline VARCHAR(42) NULL,\n universite VARCHAR(42) NULL\n);\nGestion de l'agrégation¶
\nUn agrégat simple autour d'une association dont toutes les cardinalités maximales sont N se traduit en relationnel comme la même association non agrégée, mais avec une clé primaire réduite :
\n%%mocodo --select all -t mld:c\nDATE: date\nRÉSERVER, /1N CLIENT, 1N CHAMBRE, 0N DATE: durée\nCHAMBRE: num. chambre, prix\n\nCLIENT: id. client, nom client\n\n\n\nsandbox_mld.md\n\n\n
- \n
- CHAMBRE (num. chambre, prix) \n
- CLIENT (id. client, nom client) \n
- RÉSERVER (#num. chambre, date, #id. client!, durée) \n
Un agrégat simple autour d'une association dont la cardinalité maximale « de sortie » est 1 se traduit en relationnel comme la même association non agrégée, mais avec une contrainte d'unicité sur la clé étrangère. Ci-dessous, au lieu d'avoir simplement num résa $\\implies$ (num voilier, num semaine), on a donc en plus (num voilier, num semaine) $\\implies$ num résa :
\n%%mocodo --select all -t mld:c\nVoilier: num voilier, longueur\nOffrir, /11 Réservation, 0N Voilier, 0N Semaine: tarif\nSemaine: num semaine, date début\n\nRéservation: num résa, arrhes, date résa\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Réservation (num résa, arrhes, date résa, #num voilier! u1, #num semaine! u1, tarif) \n
- Semaine (num semaine, date début) \n
- Voilier (num voilier, longueur) \n
Le cas des agrégats multiples, plus rare, est étudié en annexe.
\nAjustement des règles de passage¶
\nSupprimer ou maintenir une table facultative¶
\nLe passage au relationnel supprime automatiquement les tables réduites à une clé primaire, pourvu qu'aucun composant de celle-ci ne soit clé étrangère. Si l'on souhaite maintenir certaines de ces tables, on préfixe d'un + l'entité concernée. Ainsi, ci-dessous, Date est supprimée, mais pas Thème.
%%mocodo --select mld mcd -t mld:e\nAnimateur: num. animateur, nom animateur\nIntervenir, 1N Animateur, 1N Formation, 1N Date: nb heures\nFormation: id. formation, durée\nAborder, 1N Thème, 1N Formation\n+Thème: thème\n\nDate: date\n:\n\n\n\nsandbox_mld.md\n\n\n
- \n
Aborder (#thème, #id. formation)
\n- \n
- Le champ thème fait partie de la clé primaire de la table. C'est une clé étrangère qui a migré directement à partir de l'entité Thème. \n
- Le champ id. formation fait partie de la clé primaire de la table. C'est une clé étrangère qui a migré directement à partir de l'entité Formation. \n
\nAnimateur (num. animateur, nom animateur)
\n- \n
- Le champ num. animateur constitue la clé primaire de la table. C'était déjà un identifiant de l'entité Animateur. \n
- Le champ nom animateur était déjà un simple attribut de l'entité Animateur. \n
\nFormation (id. formation, durée)
\n- \n
- Le champ id. formation constitue la clé primaire de la table. C'était déjà un identifiant de l'entité Formation. \n
- Le champ durée était déjà un simple attribut de l'entité Formation. \n
\nIntervenir (#num. animateur, #id. formation, date, nb heures)
\n- \n
- Le champ num. animateur fait partie de la clé primaire de la table. C'est une clé étrangère qui a migré directement à partir de l'entité Animateur. \n
- Le champ id. formation fait partie de la clé primaire de la table. C'est une clé étrangère qui a migré directement à partir de l'entité Formation. \n
- Le champ date fait partie de la clé primaire de la table. Sa table d'origine (Date) ayant été supprimée, il n'est pas considéré comme clé étrangère. \n
- Le champ nb heures était déjà un simple attribut de l'association Intervenir. \n
\nThème (thème)
\n- \n
- Le champ thème constitue la clé primaire de la table. C'était déjà un identifiant de l'entité Thème.\n
\n- Le champ thème constitue la clé primaire de la table. C'était déjà un identifiant de l'entité Thème.\n
\n
NB. La table Date a été supprimée car elle était réduite à la clé primaire de son entité d'origine. Pour conserver de telles tables, préfixez d'un « + » la définition des entités d'origine.
\nNotez l'explication de la suppression (en NB) et celle de la perte du caractère étranger de l'attribut date (dans la table Intervenir). Pour une discussion sur cette problématique, cf. issue #66.
\nForcer une table pour éviter un champ optionnel¶
\nUne association de dépendance fonctionnelle ne donne normalement pas lieu à une création de table. Pour reprendre un exemple vu plus haut :
\n%%mocodo --select all -t mld:c\nEntreprise: id. entreprise, raison, activité, adresse\nEnvoyer, 0N Entreprise, 01 Participant\nParticipant: id. inscrit, nom, adresse\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Entreprise (id. entreprise, raison, activité, adresse) \n
- Participant (id. inscrit, nom, adresse, #id. entreprise?) \n
Dans le cas où les particuliers sont beaucoup plus nombreux que les employés d'entreprise, la clé étrangère #id. entreprise est presque toujours à NULL. C'est une perte d'espace de stockage. On peut entourer l'association de crochets droits préfixer d'un + (à partir de la version 4) l'association pour forcer sa conversion en table. Mocodo produit alors une visualisation intermédiaire entre entité et association :
%%mocodo --select all -t mld:c --colors mondrian\nEntreprise: id. entreprise, raison, activité, adresse\n+Envoyer, 0N Entreprise, 01 Participant\nParticipant: id. inscrit, nom, adresse\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Entreprise (id. entreprise, raison, activité, adresse) \n
- Envoyer (#id. inscrit, #id. entreprise!) \n
- Participant (id. inscrit, nom, adresse) \n
Cela permet du même coup d'éviter un champ optionnel, dont la gestion peut être délicate (notamment sous Microsoft SQL Server qui, au mépris du standard SQL, ne semble pas convaincu qu'une colonne UNIQUE peut contenir plus d'un NULL !).
Préciser le rôle d'une clé étrangère¶
\nCe MCD modélise la soutenance de stage des étudiants, ainsi que la visite d'amitié et de contrôle dont les honore leur enseignant responsable :
\n%%mocodo -t\nSoutenir, 01 Étudiant, 0N Date: note stage\nÉtudiant: num. étudiant, nom, coordonnées\n\nDate: date\nRépondre de, 0N Date, 11 Étudiant, 0N Enseignant\nEnseignant: num. enseignant, nom, coordonnées\n- \n
- Enseignant (num. enseignant, nom, coordonnées) \n
- Étudiant (num. étudiant, nom, coordonnées, date 1, note stage, date 2, #num. enseignant) \n
Force est de constater que la table Étudiant laisse quelque peu à désirer du point de vue sémantique :
\n- \n
- on ne sait pas à quoi correspondent les attributs date 1 et date 2 : ils ne peuvent en tout cas certainement pas être laissés en l'état ; \n
- ensuite, on pourrait avoir envie d'expliciter la raison pour laquelle un enseignant apparaît parmi les attributs d'un étudiant. \n
Ces précisions peuvent être apportées en insérant, entre la cardinalité et l'entité des pattes appropriées, une note entre crochets, appelée rôle. Ces rôles seront utilisés pour compléter le nom des clés étrangères correspondantes. Cela permet de réintroduire la sémantique perdue lors de la disparition des associations de dépendance fonctionnelle par lesquelles elle ont migré :
\n%%mocodo -t mld\nSoutenir, 01 Étudiant, 0N [soutenance] Date: note stage\nÉtudiant: num. étudiant, nom, coordonnées\n\nDate: date\nRépondre de, 0N [+ visite resp] Date, 11 Étudiant, 0N [-num. ens. resp.] Enseignant\nEnseignant: num. enseignant, nom, coordonnées\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Enseignant (num. enseignant, nom, coordonnées) \n
- Étudiant (num. étudiant, nom, coordonnées, date soutenance, note stage, date visite resp, #num. ens. resp.) \n
La composition du rôle est entièrement paramétrable :
\n- \n
- date soutenance : par défaut, le rôle est concaténé à la clé, avec un séparateur dépendant du gabarit (espace par défaut, tiret bas pour SQL). \n
- date visite resp. :
+en préfixe supprime le séparateur. \n - num. ens. resp. :
-en préfixe supprime le nom de la clé et le remplace par le rôle. \n
Pour ne pas surcharger le dessin, le rôle n'est pas affiché à côté du lien, mais il apparaît au survol de la cardinalité.
\nCorrection de la version 4.0. Dans une association réflexive hiérarchique, c'est désormais le rôle porté par la patte *N qui sert à rétablir la sémantique. Auparavant c'était l'inverse, en contradiction avec le traitement des associations binaires et n-aires : si vous avez utilisé des rôles dans une association réflexive avant la version 4.0.0, vous devez donc les permutez pour que Mocodo les traite correctement. Reprenons la filiation patrilinéaire :
%%mocodo -t\nHOMME: num. SS, nom, prénom\nENGENDRER, 0N [père] HOMME, 01 [fils] HOMME\n- \n
- HOMME (num. SS, nom, prénom, #num. SS père) \n
Orienter la migration dans les DF à double sens¶
\nLorsque toutes les cardinalités d'une dépendance fonctionnelle sont 11 (ou toutes 01), le sens de migration est spécifié à coût zéro en référençant l'entité réceptrice en tête de la liste des entités énumérées dans la clause de définition de l'association :
\n%%mocodo -t mld diagram sql --colors mondrian\nUSER: user id [VARCHAR(8)], name [VARCHAR(100)], pseudo [VARCHAR(100)]\nDF, 11 USER, 11 AUTHENTICATION\nAUTHENTICATION: email [VARCHAR(255)], password hash [BINARY(64)], salt [BINARY(16)]\n\n\n\nsandbox_mld.md\n\n\n
- \n
- AUTHENTICATION (email, password hash, salt) \n
- USER (user id, name, pseudo, #email) \n
\n\n\nsandbox_mld.svg\n\n\n
\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE AUTHENTICATION (\n PRIMARY KEY (email),\n email VARCHAR(255) NOT NULL,\n password_hash BINARY(64),\n salt BINARY(16)\n);\n\nCREATE TABLE USER (\n PRIMARY KEY (user_id),\n user_id VARCHAR(8) NOT NULL,\n name VARCHAR(100),\n pseudo VARCHAR(100),\n email VARCHAR(255) NOT NULL,\n UNIQUE (email)\n);\n\nALTER TABLE USER ADD FOREIGN KEY (email) REFERENCES AUTHENTICATION (email);\nDans la version avec identification relative, c'est l'entité faible qui doit être placée en tête :
\n%%mocodo -t mld diagram sql --colors mondrian\nUSER: user id [VARCHAR(8)], name [VARCHAR(100)], pseudo [VARCHAR(100)]\nDF, _11 AUTHENTICATION, 11 USER\nAUTHENTICATION: email [VARCHAR(255)], password hash [BINARY(64)], salt [BINARY(16)]\n\n\n\nsandbox_mld.md\n\n\n
- \n
- AUTHENTICATION (#user id, email, password hash, salt) \n
- USER (user id, name, pseudo) \n
\n\n\nsandbox_mld.svg\n\n\n
\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE AUTHENTICATION (\n PRIMARY KEY (user_id, email),\n user_id VARCHAR(8) NOT NULL,\n email VARCHAR(255) NOT NULL,\n password_hash BINARY(64),\n salt BINARY(16)\n);\n\nCREATE TABLE USER (\n PRIMARY KEY (user_id),\n user_id VARCHAR(8) NOT NULL,\n name VARCHAR(100),\n pseudo VARCHAR(100)\n);\n\nALTER TABLE AUTHENTICATION ADD FOREIGN KEY (user_id) REFERENCES USER (user_id);\nLes traitements alternatifs (fusion en une seule table ou migration dans les deux sens) ne sont pas pris en charge par Mocodo. La dernière pratique ressortit à la phase d'optimisation et de dénormalisation de la base, qui est en dehors de sa juridiction. La seule chose que vous pouvez faire, à des fins d'illustration, est de reprendre le MLD généré pour y ajouter à la main la migration inverse. Notez cependant que les schémas logique et physique générés seront alors dépourvus de toute clé étrangère (et nécessiteront donc également d'être retouchés à la main).
\n%%mocodo -t mld sql --colors mondrian --select all\n:\nUSER: user id [VARCHAR(8)], name [VARCHAR(100)], pseudo [VARCHAR(100)], #email > AUTHENTICATION > email\n:\nAUTHENTICATION: email [VARCHAR(255)], password hash [BINARY(64)], salt [BINARY(16)], #user id > USER > user id\n:\n\n\n\nsandbox_mld.md\n\n\n
- \n
- AUTHENTICATION (email, password hash, salt, user id) \n
- USER (user id, name, pseudo, email) \n
\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE AUTHENTICATION (\n PRIMARY KEY (email),\n email VARCHAR(255) NOT NULL,\n password_hash BINARY(64),\n salt BINARY(16),\n user_id VARCHAR(42)\n);\n\nCREATE TABLE USER (\n PRIMARY KEY (user_id),\n user_id VARCHAR(8) NOT NULL,\n name VARCHAR(100),\n pseudo VARCHAR(100),\n email VARCHAR(42)\n);\nAutres sorties relationnelles¶
\nGraphe des dépendances¶
\nLa table A dépend de la table B lorsque A possède une clé étrangère qui est clé primaire de B. Cette notion est utile dans le cas où l'on doit importer une base de données à partir d'un ensemble de fichiers CSV (ou autres). Si l'on veut éviter de perdre le bénéfice du contrôles de clés étrangères (en faisant, p. ex. sous MySQL, SET FOREIGN_KEY_CHECKS = 0), il conviendra de lire ces fichiers dans un ordre topologique quelconque. Mocodo peut générer un graphe des dépendances qui met cet ordre en évidence :
%mocodo -i ccp -t dependencies --defer\n\n\n\nccp_dependencies.svg\n\n\n
Même si un tel graphe n'est pas forcément sans circuits, remplir les tables dans le sens de lecture des langues latines minimisera le recours à la désactivation des contraintes de clés étrangères.
\nDiagramme relationnel / DDL BDML¶
\nD'après son site officiel :
\n\n\nDBML (Database Markup Language) est un DSL (langage dédié) open-source conçu pour définir et documenter les schémas et structures de base de données. Il vise la simplicité, la cohérence et la lisibilité.
\n
Mocodo parle maintenant DBML :
\n%mocodo -i ccp -t dbml --title CCP\n\n\n\nccp_ddl.dbml\n\n\n
dbml\nTable \"Client\" {\n \"Réf. client\" VARCHAR(8) [pk, NOT NULL]\n \"Nom\" VARCHAR(255)\n \"Prénom\" VARCHAR(255)\n \"Adresse\" VARCHAR(255)\n}\n\nTable \"Commande\" {\n \"Num. commande\" VARCHAR(8) [pk, NOT NULL]\n \"Date\" DATE\n \"Montant\" DECIMAL(10,2)\n \"Réf. client\" VARCHAR(8) [NOT NULL]\n}\n\nTable \"Inclure\" {\n \"Num. commande\" VARCHAR(8) [NOT NULL]\n \"Réf. produit\" VARCHAR(8) [NOT NULL]\n \"Quantité\" INTEGER\n Indexes {\n (\"Num. commande\", \"Réf. produit\") [pk]\n }\n}\n\nTable \"Produit\" {\n \"Réf. produit\" VARCHAR(8) [pk, NOT NULL]\n \"Libellé\" VARCHAR(50)\n \"Prix unitaire\" DECIMAL(10,2)\n}\n\nRef:\"Commande\".\"Réf. client\" > \"Client\".\"Réf. client\"\nRef:\"Inclure\".\"Num. commande\" > \"Commande\".\"Num. commande\"\nRef:\"Inclure\".\"Réf. produit\" > \"Produit\".\"Réf. produit\"\n\nÀ notre connaissance, il n'existe pas actuellement d'API publique de rendu des diagrammes DBML. Pour les visualiser, copiez-collez la sortie sur Dbdiagram.io, ou installez un plugin VS-Code :
\ndisplay.SVG(\"../examples/dbml.svg\")\nDiagramme relationnel D2¶
\nD2 est un langage de description de diagrammes de différents types. La prise en charge des diagrammes relationnels est minimale, mais le projet est jeune (actuellement en version 0.6.1, open source depuis novembre 2022). Son point fort est TALA, son algorithme de plongement propriétaire, que vous pouvez tester ici. Celui-ci requérant une licence payante, si vous déférez le rendu, c'est le plongement par défaut (Dagre, celui de Mermaid) qui sera utilisé.
\n%mocodo -i ccp -t d2\n\n\n\nccp_ddl.d2\n\n\n
d2\n\"Client\": { shape: sql_table\n \"Réf. client\": VARCHAR(8) {constraint: PK}\n \"Nom\": VARCHAR(255) \n \"Prénom\": VARCHAR(255) \n \"Adresse\": VARCHAR(255) \n}\n\n\"Commande\": { shape: sql_table\n \"Num. commande\": VARCHAR(8) {constraint: PK}\n \"Date\": DATE \n \"Montant\": DECIMAL(10,2) \n \"Réf. client\": VARCHAR(8) {constraint: [FK; NOT NULL]}\n}\n\n\"Inclure\": { shape: sql_table\n \"Num. commande\": VARCHAR(8) {constraint: [PK; FK]}\n \"Réf. produit\": VARCHAR(8) {constraint: [PK; FK]}\n \"Quantité\": INTEGER \n}\n\n\"Produit\": { shape: sql_table\n \"Réf. produit\": VARCHAR(8) {constraint: PK}\n \"Libellé\": VARCHAR(50) \n \"Prix unitaire\": DECIMAL(10,2) \n}\n\n\"Commande\".\"Réf. client\" -> \"Client\".\"Réf. client\"\n\"Inclure\".\"Num. commande\" -> \"Commande\".\"Num. commande\"\n\"Inclure\".\"Réf. produit\" -> \"Produit\".\"Réf. produit\"\n\n%mocodo -i ccp -t d2 --defer\n\n\n\nccp_ddl.svg\n\n\n
Autres conversions¶
\nDiagramme de classes UML¶
\nÀ tout seigneur tout honneur, Mocodo peut traduire votre MCD en UML. Ce formalisme graphique n'a, curieusement, pas de DSL textuel officiel. Nous nous rabattons donc sur le standard de fait, PlantUML :
\n%mocodo -i ccp --title CCP -t uml:plantuml=- # '-' supprime un préambule par défaut qui ne nous intéresse pas ici\n\n\n\nccp_uml.puml\n\n\n
puml\n@startuml \"CCP\"\n\n!define Table(x) class \"x\" << (T,#FFFFFF) >>\n!define pk(x) <b>x</b>\n\nTable(\"Client\") {\n {field} + pk(Réf. client) VARCHAR(8)\n {field} + Nom VARCHAR(255)\n {field} + Prénom VARCHAR(255)\n {field} + Adresse VARCHAR(255)\n}\n\n\"Client\" \"1\" --- \"*\" \"Commande\": \"Passer\"\n\nTable(\"Commande\") {\n {field} + pk(Num. commande) VARCHAR(8)\n {field} + Date DATE\n {field} + Montant DECIMAL(10,2)\n}\n\n\"Commande\" \"*\" --- \"1..*\" \"Produit\": \"Inclure\"\n(\"Commande\", \"Produit\") .. \"Inclure\"\nTable(\"Inclure\") {\n {field} + Quantité INTEGER\n}\n\nTable(\"Produit\") {\n {field} + pk(Réf. produit) VARCHAR(8)\n {field} + Libellé VARCHAR(50)\n {field} + Prix unitaire DECIMAL(10,2)\n}\n\n@enduml\n\n%mocodo -i ccp -t uml --defer --colors brewer+5\n\n\n\nccp_uml.svg\n\n\n
ERD avec la convention Look across¶
\nNouveauté de la version 4.0. Force est de reconnaître que de nos jours, les MCD à la sauce Merise ne sont plus goûtés que par une poignée d'irréductibles Gaulois (et contractuellement leurs étudiants). Dans le cadre de son projet secret de domination planétaire, Mocodo commence à faire du pied à des notations mieux comprises du reste de l'univers.
\nNotation de Chen¶
\nUn MCD peut être converti en un ERD (Entity-Relationship Diagram) dans la notation de Chen, sans ses attributs ou avec :
\n%mocodo -i ccp -t chen --defer --colors ocean\n\n\n\nccp_erd_chen.svg\n\n\n
%mocodo -i ccp -t chen:attrs --defer --colors ocean\n\n\n\nccp_erd_chen.svg\n\n\n
Notation crow's foot¶
\nDans le même ordre d'idées, Mocodo peut générer des ERD dans l'astucieuse notation introduite en 1976 par Gordon Everest. Par défaut, le format du fichier intermédiaire est là encore Graphviz :
\n%mocodo -i ccp -t crow --defer --colors brewer+3\n\n\n\nccp_erd_crow.svg\n\n\n
Il est également possible de demander une sortie au format Mermaid. Vous en avez un exemple dans l'introduction, nous ne le répétons pas ici. Le DSL de Mermaid est de plus haut niveau, non encombré d'informations de style. Cependant, le format Graphviz peut être préféré pour plusieurs raisons :
\n- \n
- on peut lui appliquer une palette de couleurs de Mocodo (cf. ci-dessus) ; \n
- il gère les accents ; \n
- il admet la virgule dans les types (Mermaid demande actuellement à transformer
DECIMAL(10,2)enDECIMAL(10-2)) ; \n - il peut produire de meilleurs plongements (notamment en jouant sur la valeur de l'option
--seed) ; \n - ceux-ci peuvent-être rectifiés à la main (quoique péniblement). \n
Dictionnaire des données¶
\nVous pouvez extraire sous forme de table diverses informations sur les attributs de votre MCD.
\nUn format possible est TSV. Dans ce cas, sous Jupyter Notebook, si la bibliothèque pandas est installée, elle sera rendue comme un dataframe :
%mocodo -i ccp -t data_dict:tsv\n\n\n\nccp_data_dict_3.tsv\n\n\n
| \n | Entité ou association | \nLibellé de l'attribut | \nType | \n
|---|---|---|---|
| 0 | \nClient | \nAdresse | \nVARCHAR(255) | \n
| 1 | \nClient | \nNom | \nVARCHAR(255) | \n
| 2 | \nClient | \nPrénom | \nVARCHAR(255) | \n
| 3 | \nClient | \nRéf. client | \nVARCHAR(8) | \n
| 4 | \nCommande | \nDate | \nDATE | \n
| 5 | \nCommande | \nMontant | \nDECIMAL(10,2) | \n
| 6 | \nCommande | \nNum. commande | \nVARCHAR(8) | \n
| 7 | \nInclure | \nQuantité | \nINTEGER | \n
| 8 | \nProduit | \nLibellé | \nVARCHAR(50) | \n
| 9 | \nProduit | \nPrix unitaire | \nDECIMAL(10,2) | \n
| 10 | \nProduit | \nRéf. produit | \nVARCHAR(8) | \n
Le format par défaut est Markdown. Vous pouvez préciser en sous-sous-option tout ou partie des colonnes suivantes dans l'ordre où vous les souhaitez :
\n- \n
label: le libellé de l'attribut ; \ntype: son type ou un descriptif (auquel cas il conviendra de changer le nom de la colonne) ; \nbox: le nom de l'entité ou association où il se trouve. \n
Entourez ces noms de colonnes de balises Markdown pour les mettre en forme (pas d'incidence en TSV). Faites-les suivre de =\"Nom de colonne personnalisé\" pour éviter la valeur par défaut (dépendante de l'option language). Dans l'exemple ci-dessous, les sous-sous-options se décodent ainsi :
- \n
**box**=\"Entité ou association\": boîtes en colonne 1, en-tête personnalisé, cellules en gras ; \nlabel: libellé des attributs en colonne 2 ; \n- `
type`=`Type` : types en colonne 3, en-tête personnalisé et cellules dans une police non proportionnelle. \n
%mocodo -i ccp -t data_dict:**box**=\"Entité ou<br>association\",label,`type`=`\"Type de données\"`\n\n\n\nccp_data_dict_3.md\n\n\n
| Entité ou association | \nLibellé de l'attribut | \nType de données | \n
|---|---|---|
| Client | \nAdresse | \nVARCHAR(255) | \n
| \" | \nNom | \nVARCHAR(255) | \n
| \" | \nPrénom | \nVARCHAR(255) | \n
| \" | \nRéf. client | \nVARCHAR(8) | \n
| Commande | \nDate | \nDATE | \n
| \" | \nMontant | \nDECIMAL(10,2) | \n
| \" | \nNum. commande | \nVARCHAR(8) | \n
| Inclure | \nQuantité | \nINTEGER | \n
| Produit | \nLibellé | \nVARCHAR(50) | \n
| \" | \nPrix unitaire | \nDECIMAL(10,2) | \n
| \" | \nRéf. produit | \nVARCHAR(8) | \n
Aménités.
\n- \n
- Au format Markdown, les répétitions de cellules de la première colonne sont remplacées par un guillemet itératif. \n
- Le tableau est automatiquement trié selon sa première, puis éventuellement deuxième et troisième colonnes. \n
- Si une seule colonne est demandée, la ligne d'en-tête n'est pas générée et, en Markdown, c'est une liste qui est produite. \n
%mocodo -i ccp -t data_dict:label\n\n\n\nccp_data_dict_1.md\n\n\n
- \n
- Adresse \n
- Date \n
- Libellé \n
- Montant \n
- Nom \n
- Num. commande \n
- Prix unitaire \n
- Prénom \n
- Quantité \n
- Réf. client \n
- Réf. produit \n
Nouveautés de la version 4.0.
\n- \n
- Sélection, ordre et nommage des colonnes, mise en forme Markdown, tri, guillemets itératifs. \n
- Remplacement par un algorithme dédié du gabarit relationnel utilisé (abusivement) dans les versions antérieures. \n
URL de partage¶
\nVous pouvez demander à encoder le texte-source de votre MCD dans un lien vers Mocodo online, qui le composera automatiquement dans la zone d'entrée :
\n%mocodo -i ccp -t share\n\n\n\nccp_url.url\n\n\n
https://www.mocodo.net/?mcd=eNptkMEKgkAQhu89xRwLJDQQwtuySgm5mEgX6bDlBgu6xrYLvZLP4Ys1ahZYt_m_Yeb_Z2glhTIBZF17W8N1UFCcSEb3JFtuV2cHWFN_ycb3e5bqrlV_OCm1eDzEjC9SjlA74DKgg4UDnge0qWuuSrGYigCYrTHFW85yhNwgCkkeoUgaZXgfNYxonJDD0nOdDTrF6lpZLXA_--wffFPdlFbipUeLc9J0LRQxy6NdlGG-qTm-4T7Kmf9BXkRV9XMT9t3xF_IJVknDpRY_gV4LRG5Z\n\n\n
Mocodo pour la pédagogie¶
\nVue en extension¶
\nUn chiffre ou tiret bas à la fin du nom d'une boîte (entité ou association) est utilisé en interne pour distinguer cette boîte des autres, mais n'est pas affiché dans le diagramme conceptuel. Cela peut servir à produire une vue en extension d'un MCD.
\nVoici par exemple le MCD que j'utilise en cours pour introduire la notion d'entité faible (à gauche, vue en compréhension, à droite vue en extension):
\n%%mocodo\nŒUVRE1: cote, titre, date de publication\n:::\nŒUVRE2: 612.NAT.34, J'apprends à lire à mes souris blanches, mai 1975\n:\n \nDF, 1N ŒUVRE1, _11 EXEMPLAIRE1\n::\nDF, XX ŒUVRE2, XX EXEMPLAIRE2\nDF, XX ŒUVRE2, XX EXEMPLAIRE3\nDF, XX ŒUVRE2, XX EXEMPLAIRE4\n\nEXEMPLAIRE1: numéro d'exemplaire, état, date d'achat\n::\nEXEMPLAIRE2: 1, bon état, 12/6/1975\nEXEMPLAIRE3: 2, bon état, 1/8/1977\nEXEMPLAIRE4: 3, reliure rongée, 3/4/2005\nMocodo n'interdit pas la conversion en relationnel d'un tel MCD, mais celle-ci n'a aucun sens.
\nSi l'on veut garder les cardinalités sans les afficher, on peut les préfixer d'un -. Le résultat de la conversion en relationnel peut alors être interprété comme l'ensemble des lignes des différentes tables.
%%mocodo -t\nŒUVRE: 612.NAT.34, J'apprends à lire à mes souris blanches, mai 1975\n \nDF, -1N ŒUVRE, -_11 EXEMPLAIRE1\nDF, -1N ŒUVRE, -_11 EXEMPLAIRE2\nDF, -1N ŒUVRE, -_11 EXEMPLAIRE3\n\nEXEMPLAIRE1: 1, bon état, 12/6/1975\nEXEMPLAIRE2: 2, bon état, 1/8/1977\nEXEMPLAIRE3: 3, reliure rongée, 3/4/2005\n- \n
- EXEMPLAIRE (#612.NAT.34, 1, bon état, 12/6/1975) \n
- EXEMPLAIRE (#612.NAT.34, 2, bon état, 1/8/1977) \n
- EXEMPLAIRE (#612.NAT.34, 3, reliure rongée, 3/4/2005) \n
- ŒUVRE (612.NAT.34, J'apprends à lire à mes souris blanches, mai 1975) \n
MCD interactif¶
\nAfficher des explications au survol¶
\nLes débutants ont souvent des doutes sur la sémantique de telle ou telle cardinalité. Cette information peut être incluse dans le texte-source en annotant les pattes correspondantes. Survolez les cardinalités du MCD ci-dessous pour faire apparaître leur description.
\n%%mocodo\nProduit: réf. produit, libellé, prix unitaire\nInclure, 1N [Une commande inclut au moins un produit.] Commande, 0N [Un produit peut être commandé un nombre quelconque de fois.] Produit: quantité\nCommande: num. commande, date, montant\nDF, 0N [Un client peut passer zéro (prospect) ou plusieurs commandes.] Client, 11 [Une commande est passée par un et un seul client.] Commande\nClient: réf. client, nom, adresse\nParrainer, 01 [Un client peut avoir été parrainé ou non.] Client, 0N [Un client peut parrainer d'autres clients.] Client : date parrainage\nNouveauté de la version 4.3. Avec l'option -t prompt:cards, Mocodo compose un prompt à copier-coller sous ChatGPT (ou autre) pour compléter le MCD avec de telles descriptions. Ce prompt est trop long pour être reproduit ici : il consiste en une présentation de la syntaxe de Mocodo, des instructions sur le travail demandé, plusieurs exemples corrigés, et enfin le MCD à compléter. Voici par exemple les explications générées par DeepSeek pour le MCD de la page d'accueil de Mocodo online :
%%mocodo\nAYANT-DROIT: nom ayant-droit, lien\nDIRIGER, 0N [Un employé peut diriger zéro ou un projet.] EMPLOYÉ, 01 [Un projet est dirigé par au plus un employé.] PROJET\nREQUÉRIR, 1N [Un projet requiert au moins une pièce.] PROJET, 0N [Une pièce peut être requise par plusieurs projets.] PIÈCE: qté requise\nPIÈCE: réf. pièce, libellé pièce\nCOMPOSER, 0N [Une pièce peut être composée de plusieurs autres pièces.] PIÈCE, 0N [Une pièce peut entrer dans la composition de plusieurs autres pièces.] PIÈCE: quantité\n\nDF, _11 [Un ayant-droit est associé à un et un seul employé.] AYANT-DROIT, 0N [Un employé peut avoir plusieurs ayants-droit.] EMPLOYÉ\nEMPLOYÉ: matricule, nom employé\nPROJET: num. projet, nom projet\nFOURNIR, 1N [Un projet est fourni par au moins une société.] PROJET, 1N [Une pièce est fournie par au moins une société.] PIÈCE, 1N [Une société fournit au moins une pièce pour un projet.] SOCIÉTÉ: qté fournie\n\nDÉPARTEMENT: num. département, nom département\nEMPLOYER, 11 [Un employé appartient à un et un seul département.] EMPLOYÉ, 1N [Un département emploie au moins un employé.] DÉPARTEMENT\nTRAVAILLER, 0N [Un employé peut travailler sur plusieurs projets.] EMPLOYÉ, 1N [Un projet implique au moins un employé.] PROJET\nSOCIÉTÉ: num. société, raison sociale\nCONTRÔLER, 0N< [Une société peut en contrôler une autre.] SOCIÉTÉ, 01 [Une société est contrôlée par au plus une autre société.] SOCIÉTÉ\nLe résultat est en général plus qu'honorable, mais demande à être relu attentivement pour vérifier l'adhérence au MCD original, corriger d'éventuelles hallucinations ou apporter des précisions. Ci-dessus, en l'occurrence, une société peut en contrôler plusieurs autres (et non une autre).
\nDifférence syntaxique entre rôles et explications. Remarquez que la syntaxe est la même que pour les rôles, qui sont en plus utilisés lors du passage au relationnel. Comment Mocodo fait-il la différence ? En appliquant les règles suivantes :
\n- \n
- si la note de patte commence par
+ou-, ou qu'elle ne contient aucun espace, c'est un rôle. \n - sinon, c'est une description de cardinalité. \n
Explication de contraintes. Le même principe s'applique aux contraintes (survolez le Ⓘ) :
\n%%mocodo\nProjet: num. projet, nom projet\n:\nFournir, 1N Projet, 1N Pièce, 1N Société: quantité\nSociété: num. société, raison sociale\n\nRequérir, 1N Projet, 0N Pièce: quantité\n:\nPièce: réf. pièce, libellé pièce\n\n(I) [Toute pièce fournie doit avoir été requise.] ..Pièce, ->Requérir, --Fournir, Projet\nLimitations.
\n- \n
- Non pris en charge par les éditeurs de SVG comme Inkscape. \n
- Ne semble pas fonctionner dans une page HTML statique (comme la version HTML de ce document sous GitHub). \n
- Nécessite de faire confiance à un notebook (Trust notebook) pour s'afficher à la réouverture. \n
Dévoiler un MCD par étapes¶
\nNouveauté de la version 3. Il est possible de faire apparaître progressivement les différentes « boîtes » constituant un MCD. Pour cela, il suffit d'indenter (décaler vers la droite à l'aide d'espaces ou de tabulations) au moins une ligne. Les éléments correspondants seront alors répartis sur autant de « calques » qu'il y a de niveaux d'indentations.
\nVoici par exemple un exercice consistant en la description du « réel perçu » d'une entreprise de VPC :
\n\n\n\n
\n- Un produit est connu par une référence, un libellé et un prix unitaire.
\n- Toute commande inclut un produit ou plusieurs, chacun en une certaine quantité.
\n- Un client peut passer zéro (client potentiel) ou plusieurs commandes.
\n- Un client peut entrer dans la base par parrainage d'un autre client.
\n
L'enseignant peut le présenter pas à pas en suivant les étapes de l'énoncé :
\n%%mocodo --colors ocean\n Parrainer, 01 Client, 0N Client : date parrainage\nProduit: Réf. produit, Libellé, Prix unitaire\n Inclure, 1N Commande, 0N Produit: Quantité\n \n Client: Réf. client, Nom, Prénom, Adresse\n DF, 0N Client, 11 Commande\n Commande: Num. commande, Date, Montant\nRemarques.
\n- \n
Pas de règle sur la taille de l'indentation. Pour Mocodo, autant de niveaux d'indentation distincts, autant de calques.
\n \nLes différents calques sont codés directement dans le SVG. L'interaction ne nécessite donc aucun logiciel spécifique.
\n \nSous Mocodo online, le MCD est toujours présenté entièrement dévoilé. Cela permet de voir directement le résultat d'une modification du texte-source.
\n \nPour ajouter facilement de l'interactivité à un MCD existant :
\n- \n
- commencez par indenter au maximum toutes les lignes ; \n
- effacez l'indentation des lignes du premier calque ; \n
- décalez votre curseur de $n$ caractères vers la droite ; \n
- placez-vous tour à tour sur les lignes à intégrer au deuxième calque et effacez les espaces surnuméraires ; \n
- recommencez à l'étape 3 jusqu'au dernier calque. \n
Depuis la version 4.0, l'éditeur de Mocodo online vous permet de créer des curseurs multiples, ce qui simplifie encore ces opérations.
\n \n
Limitations.
\n- \n
- Pas de granularité plus fine que la ligne (entité ou association avec toutes ses pattes et cardinalités). \n
- Pas de prise en charge des touches directionnelles. Cela serait sans doute possible, mais difficilement compatible avec la présence de plusieurs MCD interactifs sur une même page (comme dans cette documentation). \n
Éviter qu'une interaction sur un SVG ne s'applique à un autre.
\nDans le cas très rare où plusieurs SVG interactifs générés à partir du même texte-source coexistent sur une même page web, une interaction opérée sur l'un s'applique également à tous les autres. Par exemple, cliquer sur l'un des ronds gris de l'une des figures ci-dessous agira sur les deux figures :
\n%%mocodo\nFOO: foo\n BAR: bar\n%%mocodo\nFOO: foo\n BAR: bar\nCe problème trahit une « collision » : différents éléments du DOM se sont vus attribuer la même empreinte (obtenue par hachage du texte-source). La solution est de passer un entier discriminant qui, par concaténation, fera de ces empreintes de véritables identifiants.
\n%%mocodo --uid_suffix 1\nFOO: foo\n BAR: bar\n%%mocodo --uid_suffix 2\nFOO: foo\n BAR: bar\nExplications du passage au relationnel¶
\nLes gabarits de conversion en MLD (à savoir html, markdown, latex et text) admettent une sous-sous-option e qui accompagne le résultat par des explications détaillées du mécanisme de passage :
%mocodo -i ccp -t markdown:e\n\n\n\nccp_mld.md\n\n\n
- \n
Client (Réf. client, Nom, Prénom, Adresse)
\n- \n
- Le champ Réf. client constitue la clé primaire de la table. C'était déjà un identifiant de l'entité Client. \n
- Les champs Nom, Prénom et Adresse étaient déjà de simples attributs de l'entité Client. \n
\nCommande (Num. commande, Date, Montant, #Réf. client)
\n- \n
- Le champ Num. commande constitue la clé primaire de la table. C'était déjà un identifiant de l'entité Commande. \n
- Les champs Date et Montant étaient déjà de simples attributs de l'entité Commande. \n
- Le champ Réf. client est une clé étrangère. Il a migré par l'association de dépendance fonctionnelle Passer à partir de l'entité Client en perdant son caractère identifiant. \n
\nInclure (#Num. commande, #Réf. produit, Quantité)
\n- \n
- Le champ Num. commande fait partie de la clé primaire de la table. C'est une clé étrangère qui a migré directement à partir de l'entité Commande. \n
- Le champ Réf. produit fait partie de la clé primaire de la table. C'est une clé étrangère qui a migré directement à partir de l'entité Produit. \n
- Le champ Quantité était déjà un simple attribut de l'association Inclure. \n
\nProduit (Réf. produit, Libellé, Prix unitaire)
\n- \n
- Le champ Réf. produit constitue la clé primaire de la table. C'était déjà un identifiant de l'entité Produit. \n
- Les champs Libellé et Prix unitaire étaient déjà de simples attributs de l'entité Produit. \n
\n
Nous avons essayé d'être aussi précis que possible, tout en « factorisant » avec soin les lignes consécutives suseptibles de l'être. Vous pouvez adapter ces explications à votre enseignement en modifiant une copie du gabarit html-ce.yaml, dont les autres sont dérivés.
MCD à compléter¶
\nLes MCD à trous sont des exercices classiques d'introduction aux bases de données.
\nSupprimer le marquage d'un identifiant¶
\nPour éviter le marquage automatique du premier attribut d'une entité comme identifiant, il suffit de le préfixer par un tiret bas (_) : ce caractère est donc un commutateur, qui souligne un attribut non souligné par défaut, et désouligne un attribut souligné par défaut.
%%mocodo\nCLIENT: _Réf. client, Nom, Prénom, Adresse\nPASSER, 0N CLIENT, 11 COMMANDE\nCOMMANDE: _Num. commande, Date, Montant\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantité\nPRODUIT: _Réf. produit, Libellé, Prix unitaire\nMasquer un couple de cardinalités¶
\nVous pouvez masquer n'importe quelles cardinalités en les remplaçant par XX ou en les préfixant d'un - :
%%mocodo\nCLIENT: Réf. client, Nom, Prénom, Adresse\nPASSER, XX CLIENT, XX COMMANDE\nCOMMANDE: Num. commande, Date, Montant\nINCLURE, -1N COMMANDE, -0N PRODUIT: Quantité\nPRODUIT: Réf. produit, Libellé, Prix unitaire\nNouveauté de la version 4.0. Si la cardinalité comporte un et un seul X, l'autre caractère sera affiché tout seul.
Masquer un attribut¶
\nVous pouvez mettre deux virgules consécutives pour réserver la place d'un attribut manquant. Les espaces insécables sont préservés, ce qui permet de réserver plus d'espace horizontal, cf. ci-dessous premier attribut vide de INCLURE.
\n%%mocodo\nCLIENT: Réf. client,,, \nPASSER, XX CLIENT, XX COMMANDE\nCOMMANDE: , Date, Montant\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantité,,,,\nPRODUIT: Réf. produit, Libellé, Prix unitaire\nRégression de la version 4.0. Les espaces insécables ne sont plus préservés. Il n'y a donc plus d'autre moyen de réserver davantage d'espace horizontal que d'employer le style blank (paragraphe suivant).
Ne faire apparaître que le squelette du schéma conceptuel¶
\nVous pouvez transformer en exercice à trous n'importe quel MCD en rendant complètement transparentes les couleurs des attributs, associations et cardinalités. Le style blank a été prédéfini à cet effet:
%mocodo -i ccp --colors=blank\nAttention, n'utilisez cette méthode que pour la projection : l'information textuelle est toujours présente, susceptible d'être sélectionnée et collée ailleurs. Vous pouvez bien sûr empêcher cette possibilité en convertissant le SVG en PNG, mais le plus simple est d'appliquer une réécriture empty :
%mocodo -i ccp -t empty # équivalent de \"delete:types,notes,attrs,cards\"\n\n\n\nccp.mcd\n\n\n
%%mocodo \nClient: , , , \nPasser, XX Client, XX Commande\nCommande: , , \nInclure, XX Commande, XX Produit: \nProduit: , ,\n\n
Obfuscation d'un MCD donné¶
\nObfusquer un MCD consiste à vider celui-ci de sa sémantique de surface en substituant des chaînes aléatoires à tous les libellés. Cela permet de créer des exemples d'illustration de telle ou telle notion « pure » sans risquer de voir son public se focaliser sur des détails-métier (c'est l'équivalent de la variable méta-syntaxique foobar dans le contexte de la pédagogie de la programmation).
%mocodo -i ccp --seed=1 --select mcd -t obfuscate # raccourci pour \"obfuscate:labels\"\nEn argument, vous pouvez ajouter le chemin d'un fichier texte quelconque où puiser les mots de substitution. Par exemple, le texte du README de ce projet :
%mocodo -i ccp -t obfuscate:labels=../../README.md --seed=1 --select mcd\nMocodo essaie d'abord de trouver ce fichier à l'endroit indiqué. En cas d'échec, il le cherche (avec extension .txt facultative) parmi ceux distribués avec le logiciel, à savoir:
- \n
\"lorem.txt\"(6464 mots) : le faux-texte le plus courant, augmenté d'une sélection des 10000 mots latins les plus courants compilés par Kyle P. Johnson, le tout privé de ses doublons et des mots de moins de 3 lettres (\"lorem_ipsum.txt\"avant la version 4.0). \n\"fr.txt\"(3396 mots) : une liste des 4000 mots français les plus courants, privée de ceux comportant une apostrophe ou moins de 4 lettres. Source : http://wortschatz.uni-leipzig.de/index.html via Wikitionary. Nouveauté de la version 4.0. \n\"fr5.txt\"(464 mots): la liste de\"fr.txt\", restreinte aux mots de 5 lettres. Nouveauté de la version 4.0. \n\"en4.txt\"(640 mots): une sélection (SFW) de mots anglais de quatre lettres (\"four_letter_words.txt\"avant la version 4.0). \n\"disparition.txt\"(7489 mots) : le lexique du célèbre roman lipogrammatique de Georges Perec, privé des mots de moins de 4 lettres. \n
En cas de nouvel échec, il se rabat sur \"lorem.txt\".
NB. L'algorithme s'assure que la distance de Damerau-Levenshtein entre deux libellés de substitution quelconques est d'au moins 3. En clair, cela signifie que, si vous donnez en examen un exercice de conversion en relationnel basé sur un tel MCD, les erreurs de transcription d'un étudiant stressé, inattentif, illettré, dyslexique, roublard, ou tout cela à la fois, ne devraient pas vous empêcher de lui octroyer les points qui lui reviennent.
\nCroissance stochastique¶
\nVous pouvez créer un MCD partiellement aléatoire à partir d'un MCD donné en lui ajoutant un nombre n d'associations (avec les entités nécessaires) :
%mocodo -i ccp -t grow:n=4 arrange --seed=1 --select mcd\n- \n
Des sous-options pré-définies (données ci-dessous avec leur valeur par défaut après le
\n=) permettent de spécifier finement le nombre désiré :- \n
- d'associations réflexives (
arity_1=2) ; \n - d'associations ternaires (
arity_3=2) ; \n - d'associations quaternaires (
arity_4=0) ; \n - d'associations doubles, i.e., associant le même couple d'entités (
doubles=1) ; \n - d'identifiants composites (
composites=1) ; \n - d'attributs maximum par entité (
ent_attrs=4) ; \n - d'attributs maximum par association (
assoc_attrs=2). \n
\n- d'associations réflexives (
On ne peut pas préciser directement le nombre d'associations binaires : si le nombre total des autres associations spécifiées n'arrivent pas à
\nn, elles viennent en complément. \nDes sous-options de forme plus ou moins libre décrivent les cardinalités. Par exemple,
\n_11-*N=2créera deux entités faibles et/*N-*Nun agrégat. Les associations de complément sont*N-*N. \n
Avec la sous-option from_scratch, le MCD de départ est vide. À titre d'exemple, voici la transformation complexe invoquée par Mocodo online pour créer un MCD d'entraînement à la conversion au relationnel, accompagné de cette dernière. Notez la création de rôles par défaut : ils permettent de simuler le rétablissement de la sémantique des associations disparues.
%mocodo --seed=2 --mld -t grow:from_scratch,arity_3=1,_11-*N=1 obfuscate create:roles lower:roles arrange\nIl n'est pas impossible que le MCD résultant soit incorrect (p. ex., apparition d'une identification relative circulaire), mais les contrôles effectués a priori et a posteriori devraient dans la majorité des cas produire quelque chose de raisonnable.
\nGénération d'un QR code¶
\nImpressionnez votre public en accompagnant l'option -t share de --defer :
%mocodo -i ccp -t share --defer\n\n\n\nccp_url.svg\n\n\n
Limitation. Comme il faut un mobile pour scanner ce QR code, et que Mocodo online n'est pas vraiment adapté aux mobiles, l'intérêt réel de cette fonctionnalité est pour l'instant discutable.
\nBibliothèque de MCD en ligne¶
\nVous avez créé avec Mocodo toute une bibliothèque de MCD, certains pour illustrer des points de votre cours, d'autres comme solutions d'exercices. À partir de la version 4.1, vous pouvez donner accès à tel ou tel de ces MCD en communiquant simplement son nom à vos étudiants.
\nAccès sous Mocodo online¶
\nPour comprendre le fonctionnement, accédons à un MCD de la bibliothèque par défaut : copiez-collez la chaîne def_weak-974e comme titre du MCD dans l'onglet Entrée de Mocodo online. Le texte-source est mis à jour avec le contenu d'un fichier def_weak-974e.mcd stocké en ligne :
![\"\"](\"examples/lib_demo.png\"/)
Remarques.
\n- \n
- Vous avez sans doute déjà utilisé cette fonctionnalité sans le savoir en parcourant le tutoriel, dont les MCD, appelés
tuto-0000,tuto-0001, etc., sont récupérés de la même manière. \n - Tous les noms de fichiers de la bibliothèque par défaut se terminent par un code de quatre caractères alphanumériques : cette disposition évite qu'un utilisateur ne tombe dessus par hasard, et protège certains MCD (typiquement, les solutions d'exercices) de la curiosité naturelle des étudiants. Au moment de la correction, je leur donne simplement le nom complet, et ils récupèrent directement la solution, ce qui dégage du temps pour des activités plus éducatives que la recopie. \n
Bien sûr, la plupart des MCD de la bibliothèque par défaut n'intéressent que mon enseignement, et n'ont pas vocation à être diffusés au-delà du cercle très select des happy few qui en bénéficient.
\nPour mettre votre propre bibliothèque à la disposition de vos propres étudiants :
- \n
- placez-la dans un répertoire dédié d'un serveur sur lequel vous avez les droits ; \n
- copiez-collez l'URL de ce répertoire dans le champ Bibliothèque de MCD (onglet Options). Désormais, c'est à cette adresse que Mocodo essaiera de trouver les MCD quand vous mettrez à jour leur titre ; \n
- vos étudiants devront eux-mêmes avoir renseigné le champ en question, ce qui peut poser des problèmes à certains. Facilitez-leur la tâche en leur donnant le lien suivant (tout ce qui suit
lib=doit bien sûr être remplacé par l'adresse de votre répertoire distant) : \n
https://www.mocodo.net/?lib=https://your_server.com/path/to/your/mcd/directory\nIls n'auront plus qu'à cliquer pour remplir automatiquement le champ approprié, lequel persistera dans les cookies de leur navigateur.
\nAccès sous terminal ou Jupyter Notebook¶
\nL'option --input (ou -i) est surchargée pour aller chercher un MCD sur internet s'il ne se trouve pas dans le répertoire local. Pour commencer la démonstration, assurons-nous que le fichier en question n'existe pas en local :
path = Path(\"def_weak-974e.mcd\")\npath.unlink(missing_ok=True)\npath.is_file()\nFalse\n
Récupérons-le de façon transparente dans la bibliothèque par défaut (avec ou sans extension .mcd) :
%mocodo -i def_weak-974e.mcd\nNotez qu'au passage, pour le rendre disponible hors ligne, le fichier a été sauvegardé sur votre machine :
\npath.is_file()\nTrue\n
NB. Si le paramètre de -i est un chemin de la forme path/to/file.mcd (avec ou sans extension .mcd), c'est la dernière partie du chemin (à savoir file.mcd) qui sera récupérée sur le serveur. Par contre, c'est le chemin complet qui déterminera l'emplacement de la sauvegarde.
Pour utiliser votre propre répertoire distant, passez son URL à l'option --lib :
mocodo -i your_diagram.mcd --lib https://your_server.com/path/to/your/mcd/directory\nNous vous conseillons d'ajouter cette option dans votre fichier de paramètres personnalisé params.json.
Compléments sur l'aspect visuel¶
\nStyles¶
\nPlusieurs styles prédéfinis sont distribués avec l'application. Un style se définit comme la combinaison d'une palette de couleurs (répertoire colors) avec un dictionnaire de polices et de dimensions (répertoire shapes).
Vous pouvez bien sûr créer vos propres styles en vous inspirant des fichiers fournis. Si vous êtes particulièrement content d'un style, soumettez-le pour inclusion dans une prochaine distribution.
\nRéglages. Une approximation de la largeur des caractères des différentes polices a été pré-calculée sous macOS. Il est possible qu'elle soit inexacte, en particulier sous Windows ou Linux. Dans ce cas, en particulier, les traits de soulignement n'atteindront pas ou excéderont la largeur des libellés soulignés. Vous pouvez contourner le problème en appliquant un facteur multiplicatif avec l'argument --adjust_width).
Paramétrage du réarrangement automatique¶
\nIl est possible de demander à Mocodo de chercher tout seul une « bonne » permutation des définitions des boîtes, ce qui à la main deviendrait vite difficile.
\nLe critère que nous avons retenu pour évaluer la qualité du tracé est double :
\n- \n
- les liens ne doivent pas se couper ; \n
- leur longueur cumulée doit être minimale. \n
Actuellement, deux algorithmes d'arrangement sont fournis :
\n- \n
- un algorithme exact (
bb, pour Branch & Bound), qui ne trouve que des solutions satisfaisant au premier critère ; \n - un algorithme approché (
ga, pour Genetic Algorithm), réservé aux cas où il est impossible d'y satisfaire. L'algorithme va alors chercher des solutions où les liens se coupent seulement le moins possible. \n
Remarque. Mocodo met en œuvre une technique de réarrangement originale : en contraignant la position des boîtes aux intersections d'une grille invisible, il transforme un classique problème de plongement en un problème d'affectation, ce qui permet de satisfaire de façon efficace à un certain nombre de contraintes esthétiques pertinentes (planarité, compacité, etc.).
\nNous illustrerons les algorithmes et leurs paramètres sur le MCD d'accueil de Mocodo online.
\nLe réarrangement automatique peut se faire sans contraintes, ou dans les limites d'une grille spécifiée par l'utilisateur.
\nMéthode exacte (branch & bound)¶
\nArrangement non contraint (par défaut)¶
\nLe réarrangement dit organique consiste à choisir une première boîte au hasard, puis à essayer d'agréger les autres sans se préoccuper de contenir le tout dans une grille prédéterminée :
\n%mocodo -i ../examples/landing --select mcd --seed=2 -t arrange\nCela donne un plongement sur une grille $5\\times4$, ce qui est loin d'être optimal. Cependant, l'arrangement organique fournit souvent un bon point de départ pour chercher soi-même une permutation plus esthétique ou mettant en évidence certaines propriétés du MCD.
\nArrangement dans la grille courante¶
\nLe réarrangement automatique des boîtes peut s'opérer dans les limites de la grille courante ; c'est-à-dire que le MCD résultant aura (au plus) le même nombre de colonnes et de rangées que le texte de départ (ici, $4\\times5$) :
\n%mocodo -i ../examples/landing --select mcd --seed=2 -t arrange:current\nArrangement en privilégiant la largeur¶
\nDans un document paginé, on cherche en général à utiliser en priorité l'espace horizontal. La version 4.0 introduit à cet effet une option de réarrangement « en largeur d'abord ». Le MCD d'accueil s'y prête particulièrement bien :
\n%mocodo -i ../examples/landing --select mcd --seed=2 -t arrange:wide=8 --scale 0.8\nIci, l'utilisateur a demandé $8$ boîtes en largeur (c'est aussi la valeur par défaut). L'algorithme commence par calculer le nombre de lignes minimal correspondant, sachant qu'il a $14$ boîtes à placer : c'est $\\lceil14/8\\rceil=2$. Il cherche donc un plongement sur une grille $8\\times2$.
\nArrangement dans une grille équilibrée minimale¶
\nOn peut chercher à faire tenir le MCD dans la plus petite grille possible, tout en maintenant entre hauteur et largeur un rapport « équilibré » (ou proche du nombre d'or). Par exemple, un MCD de 13 boîtes (entités ou associations) peut tenir dans les grilles:
\n- \n
- $13\\times1$; \n
- $7\\times2$, ce qui laisse 1 case vide; \n
- $5\\times3$, ce qui laisse 2 cases vides; \n
- $4\\times4$, ce qui laisse 3 cases vides; \n
- etc. \n
Les deux premières grilles étant non équilibrées, on retiendra la plus petite des suivantes, de dimensions $5\\times3$.
\nLa table ci-dessous énumère les dimensions des grilles minimales d'équilibre supérieur à 0,5 pour tous les MCD comportant moins de 100 boîtes. On peut y vérifier par exemple que le MCD de taille 13 (en gras) se trouve effectivement aux coordonnées (5, 3).
\n| \n | 1 | \n2 | \n3 | \n4 | \n5 | \n6 | \n7 | \n8 | \n9 | \n10 | \n11 | \n12 | \n13 | \n
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | \n1 | \n2 | \n3 | \n\n | \n | \n | \n | \n | \n | \n | \n | \n | \n |
| 2 | \n\n | 4 | \n5, 6 | \n\n | \n | \n | \n | \n | \n | \n | \n | \n | \n |
| 3 | \n\n | \n | 7, 8, 9 | \n10, 11, 12 | \n13, 14, 15 | \n\n | \n | \n | \n | \n | \n | \n | \n |
| 4 | \n\n | \n | \n | 16 | \n17, 18, 19, 20 | \n21, 22, 23, 24 | \n26, 27, 28 | \n\n | \n | \n | \n | \n | \n |
| 5 | \n\n | \n | \n | \n | 25 | \n29, 30 | \n31, 32, 33, 34, 35 | \n37, 38, 39, 40 | \n43, 44, 45 | \n\n | \n | \n | \n |
| 6 | \n\n | \n | \n | \n | \n | 36 | \n41, 42 | \n46, 47, 48 | \n50, 51, 52, 53, 54 | \n57, 58, 59, 60 | \n65, 66 | \n\n | \n |
| 7 | \n\n | \n | \n | \n | \n | \n | 49 | \n55, 56 | \n61, 62, 63 | \n67, 68, 69, 70 | \n73, 74, 75, 76, 77 | \n82, 83, 84 | \n91 | \n
| 8 | \n\n | \n | \n | \n | \n | \n | \n | 64 | \n71, 72 | \n78, 79, 80 | \n85, 86, 87, 88 | \n92, 93, 94, 95, 96 | \n\n |
| 9 | \n\n | \n | \n | \n | \n | \n | \n | \n | 81 | \n89, 90 | \n97, 98, 99 | \n\n | \n |
| 10 | \n\n | \n | \n | \n | \n | \n | \n | \n | \n | 100 | \n\n | \n | \n |
Le MCD d'accueil ayant déjà été arrangé avec l'option -t arrange:balanced, nous ne le reproduisons pas ici. Sachez cependant qu'au cas où, pour une raison ou une autre, la plus petite grille équilibrée ne convient pas, il est possible de passer à la $i^\\text{e}$ suivante en mettant $i$ en sous-sous-argument. Ici, pour $14$ boîtes, balanced=1 permet donc de passer de la grille $5\\times3$ (prévue pour $13$, $14$ et $15$ boîtes) à la grille $4\\times4$ (prévue pour $16$ boîtes).
%mocodo -i ../examples/landing --select mcd --seed=1 -t arrange:balanced=1\nLimitations de la méthode exacte¶
\nLe réarrangement exact ne fonctionnera jamais sur les MCD non planaires ou n'admettant aucun plongement planaire dans les limites de la grille spécifiée (par les sous-options current, wide ou balanced).
Rappelons qu'un graphe est dit planaire lorsqu'il en existe au moins un arrangement sans croisement. Le graphe non planaire comportant le plus petit nombre de liens est connu sous le doux nom de $K_{3,3}$ :
\n%%mocodo\nDIGNISSIM: nec sem, nunc, vulputate\nIMPERDIET: a praesent, nibh, semper\nTINCIDUNT: faucibus, orci, cursus\n\nRHONCUS, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\nSODALES, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\nQUIS ENIM, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\nSon réarrangement par Branch & bound échouera donc nécessairement :
\n%mocodo -i sandbox --seed=1 -t arrange:balanced\nMocodo Err.9 - Impossible de calculer un plongement planaire satisfaisant la contrainte\ndonnée.\n
Comme on voit, Mocodo ne cherche pas à savoir si la non-planarité est intrinsèque au graphe, ou résulte des dimensions de la grille imposée pour le plongement. Pour en avoir le cœur net, tentez un arrangement non contraint :
\n%mocodo -i sandbox --seed=1 -t arrange\nMocodo Err.41 - Impossible de calculer un plongement planaire.\n
NB. Plusieurs paramètres permettent de régler le fonctionnement de l'algorithme exact (Branch and Bound) :
\n- \n
call_limit: nombre maximal d'appels pour une boîte de départ donnée (défaut:10000). \nmin_objective: meilleur objectif esthétique pour la mise en page (défaut:0). \nmax_objective: pire objectif esthétique pour la mise en page (défaut:15). \n
Réservés aux spécialistes, ils ne sont pas décrits dans cette documentation.
\nMéthode heuristique (algorithme génétique)¶
\nDans tous les cas où la méthode exacte ne produit pas de résultat satisfaisant, on pourra se rabattre sur une heuristique qui, au lieu d'interdire les croisements, cherchera simplement à en minimiser le nombre.
\n%mocodo -i sandbox --seed=1 -t arrange:algo=ga\n\n\n\nsandbox.mcd\n\n\n
%%mocodo --seed=1\nDIGNISSIM: nec sem, nunc, vulputate\nRHONCUS, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\nIMPERDIET: a praesent, nibh, semper\n\nSODALES, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\nTINCIDUNT: faucibus, orci, cursus\nQUIS ENIM, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\n\n
L'amélioration ne saute pas forcément aux yeux, mais il n'y a plus que trois croisements au lieu de neuf. Ce plongement constitue en tout cas un bon point de départ pour un réarrangement manuel. Il ne reste en effet plus qu'à insérer quelques boîtes invisibles:
\n%%mocodo\nRHONCUS, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\n\nDIGNISSIM: nec sem, nunc, vulputate\n:::\nIMPERDIET: a praesent, nibh, semper\n\nSODALES, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\n:::\nQUIS ENIM, 1N DIGNISSIM, 1N IMPERDIET, 1N TINCIDUNT\n\nTINCIDUNT: faucibus, orci, cursus\nNB. Plusieurs paramètres permettent de régler le fonctionnement de l'algorithme génétique :
\n- \n
population_size: nombre d'individus à faire évoluer (défaut:1000). \ncrossover_rate: taux de croisement, entre 0 et 1 (défaut:0.9). \nmutation_rate: taux de mutation, entre 0 et 1 (défaut:0.06). \nsample_size: taille de l'échantillon pour les tournois (défaut:7). \nmax_generations: nombre maximal de générations (défaut:300). \nplateau: nombre maximal de générations consécutives sans amélioration (défaut:30). \n
Réservés aux spécialistes, ils ne sont pas décrits dans cette documentation.
\nAmélioration du plongement¶
\nUne entité liée à de nombreuses associations peut limiter ou même empêcher les possibilités de réarrangement sans croisements.
\nPar duplication d'entités réduites à leur identifiant¶
\nLorsque cette entité est indépendante et réduite à son identifiant, elle est vouée à disparaître lors du passage au relationnel. Il n'y a donc aucun inconvénient à en créer plusieurs, et cela peut avoir l'avantage de faciliter (ou même de rendre possible) l'obtention d'une bonne mise en page.
\nPrenons comme exemple un MCD extrait d'une étude de François de Sainte Marie, et présenté comme suit :
\n![\"\"](\"examples/ullman_cthrsg_mcd_sans_cif_80.png\"/)
Le graphe sous-jacent étant non planaire, des croisements sont inévitables (ici entre certaines pattes des associations SHR, CT et THR). Cependant, cette non-planarité résulte elle-même de la mise en jeu d'une même entité Période dans quatre associations triples. La monnayer en quatre entités Période numérotées augmente l'ordre du graphe, mais le rend planaire, le tout sans impact sur le schéma relationnel :
\n%%mocodo -t\nÉtudiant: id. étudiant, nom étudiant\n:\n:\nSHR, 0N Période3, 0N Salle, 0N Étudiant\nPériode3: heure\n\n:\nCSG, 0N Niveau, 1N Cours, 1N Étudiant\nNiveau: niveau\n:\n\nCHS, 0N Période2, 0N Cours, 0N Étudiant\nCours: id. cours, nom cours\nCHR, 0N Période4, 0N Salle, 0N Cours\nSalle: id. salle, nom salle\n\nPériode2: heure\nCT, 11 Cours, 1N Professeur\nPériode4: heure\n:\n:\n\n:\nProfesseur: id. professeur, nom professeur\n:\nTHR, 0N Période1, 0N Salle, 0N Professeur\nPériode1: heure\n- \n
- CHR (heure, #id. salle, #id. cours) \n
- CHS (heure, #id. cours, #id. étudiant) \n
- Cours (id. cours, nom cours, #id. professeur) \n
- CSG (niveau, #id. cours, #id. étudiant) \n
- Étudiant (id. étudiant, nom étudiant) \n
- Professeur (id. professeur, nom professeur) \n
- Salle (id. salle, nom salle) \n
- SHR (heure, #id. salle, #id. étudiant) \n
- THR (heure, #id. salle, #id. professeur) \n
Ce genre de problème (et sa solution) se présente typiquement lorsqu'une entité DATE réduite à un identifiant date est associée à un grand nombre d'entités n'ayant rien à voir entre elles.
\nPar suppression de ces mêmes entités¶
\nInversement, toujours étant donné que ce type d'entité est destiné à disparaître lors du passage au relationnel, on peut décider de les supprimer par anticipation. Pour cela, il faut accepter que les associations puissent être porteuses d'identifiants (ce qui n'est pas prévu par Merise). Cela permet d'obtenir un schéma conceptuel beaucoup plus lisible, toujours sans impact sur le schéma relationnel :
\n%%mocodo -t\nCSG, 1N Cours, 1N Étudiant: _niveau\n:\nCours: id. cours, nom cours\nCT, 11 Cours, 1N Professeur\n\n:\nCHS, 0N Cours, 0N Étudiant: _heure\nCHR, 0N Salle, 0N Cours: _heure\nProfesseur: id. professeur, nom professeur\n \nÉtudiant: id. étudiant, nom étudiant\nSHR, 0N Salle, 0N Étudiant: _heure\nSalle: id. salle, nom salle\nTHR, 0N Salle, 0N Professeur: _heure\n- \n
- CHR (#id. salle, #id. cours, heure) \n
- CHS (#id. cours, #id. étudiant, heure) \n
- Cours (id. cours, nom cours, #id. professeur) \n
- CSG (#id. cours, #id. étudiant, niveau) \n
- Étudiant (id. étudiant, nom étudiant) \n
- Professeur (id. professeur, nom professeur) \n
- Salle (id. salle, nom salle) \n
- SHR (#id. salle, #id. étudiant, heure) \n
- THR (#id. salle, #id. professeur, heure) \n
Notez qu'avec cette technique, les cardinalités minimales des pattes distinguées par les entités supprimées sont perdues dès le niveau conceptuel (sachant qu'elles l'auraient été de toute façon lors du passage au relationnel).
\nComme la notion d'identifiant explicite d'association enfreint le standard Merise, et risque de semer la discorde entre professeurs et étudiants, elle est par défaut désactivée sous Mocodo online. En ligne de commande, elle est interdite à la demande :
\n%mocodo -i sandbox --no_assoc_ids\nMocodo Err.52 - L'association « CSG » ne peut pas avoir d'identifiant.\n
Ajustement de l'aspect de certains éléments¶
\nFormat des cardinalités¶
\nPar défaut, les cardinalités sont séparées par une virgule, et celles des entités faibles soulignées, mais cela peut être changé :
\n%%mocodo --card_format=({min_card}/{max_card}) --strengthen_card=(1/1)(R)\nŒUVRE: Cote œuvre, Titre, Date parution\nDF, 1N ŒUVRE, _11 EXEMPLAIRE\nEXEMPLAIRE: Num. exemplaire, État du livre, Date d'achat\nFormat des clés étrangères¶
\nLa mise en forme des clés étrangères affichées dans le diagramme relationnel peut être paramétrée, par exemple pour enlever le préfixe par défaut (#) :
%mocodo -i ccp -t diagram --fk_format={label}\n\n\n\nccp_mld.svg\n\n\n
Symbole de dépendance fonctionnelle¶
\nIl est possible d'activer l'encerclement d'un autre sigle que DF. C'est ce sigle qui devra alors apparaître en entrée, par exemple:
\n%%mocodo --df CIF\nCLIENT: Réf. client, Nom, Prénom, Adresse\nCIF, 0N CLIENT, 11 COMMANDE\nCOMMANDE: Num. commande, Date, Montant\nINCLURE, 1N COMMANDE, 0N PRODUIT: Quantité\nPRODUIT: Réf. produit, Libellé, Prix unitaire\nComme le cercle est alors un peu plus grand, on peut vouloir régler (a priori une fois pour toutes) le ratio défini dans l'objet shapes du fichier appelé par défaut sandbox_geo.json):
\"df_text_height_ratio\" : 1.00,\nBasculement des cardinalités et inflexion des pattes rectilignes¶
\nMocodo est capable de détecter certaines configurations de pattes dont les cardinalités présentent un risque élevé de collision. Il procède alors à deux types d'ajustements:
\n- \n
- Issue 25. Les cardinalités d'une patte verticale ou horizontale sont envoyées de l'autre côté de la patte. Par exemple, dans le plongement du MCD précédent, la présence de la patte oblique BLANDIT-VIVAMUS envoie les cardinalités de VELIT-BLANDIT à l'opposé de leur position par défaut (à droite d'une patte verticale ou en bas d'une patte horizontale). \n
- Issue 27. Les pattes obliques sont infléchies de façon à ménager plus d'espace pour afficher deux couples de cardinalités. Ici, l'inflexion de la patte DF-CONGUE permet à ses cardinalités de coexister sans problème avec celles de l'association réflexive. \n
Ces ajustements automatiques résolvent les problèmes les plus courants. Toutefois, étant antérieurs au tracé proprement dit, ils peuvent seulement réduire les risques de collision, et non les prévenir totalement. Ils peuvent même en produire d'autres. Ainsi, autour des entités monstrueusement pattues, des collisions qui ne se seraient pas produites par défaut seront parfois observées. L'utilisateur a alors deux possibilités:
\n- \n
- diminuer la valeur du paramètre
--flex(par défaut,0.75) pour réduire la courbure de l'inflexion automatique, en allant jusqu'à0pour la désactiver totalement ; \n - modifier à la main les positions des cardinalités en conflit, comme expliqué dans la section suivante. \n
Positionnement des contraintes¶
\nEn ajoutant des liens invisibles¶
\nLa possibilité de rendre un trait invisible peut être exploitée pour « attirer » une contrainte vers telle ou telle boîte existante, soit en la répétant dans la définition de la contrainte, soit en l'y intégrant (fictivement) si elle n'en fait pas partie.
\nPar exemple, ci-dessous, répéter l'association Stocker et intégrer l'entité Commande permet de réduire la largeur du MCD sans compromettre sa lisibilité :
\n%%mocodo\n:::\nDépôt: num dépôt, surface\n\n:\nLouer, 11 Commande, 0N Dépôt\n:\nStocker, 1N Dépôt, 1N Article: quantité\n\nCommande: num. commande, date\nComposer, 1N Commande, 0N Article\n:\nArticle: réf. article, prix\n\n(I) ->Stocker, ..Dépôt, ..Article, --Composer, --Louer, Commande, Stocker\nEn ajoutant une boîte invisible¶
\nCes réglages restent relativement fragiles. Une façon d'assurer qu'ils survivront à un réarrangement est de faire coïncider le centre d'une contrainte avec celui d'une boîte supplémentaire, que nous appelons ici « Z » :
\n%%mocodo\n:::\nDépôt: num dépôt, surface\n\n:\nLouer, 11 Commande, 0N Dépôt\nZ, XX Commande, XX Article, XX Dépôt\nStocker, 1N Dépôt, 1N Article: quantité\n\nCommande: num. commande, date\nComposer, 1N Commande, 0N Article\n:\nArticle: réf. article, prix\n\n(I) ->Stocker, ..Dépôt, ..Article, --Composer, --Louer: Z, Z\nIl ne reste plus qu'à rendre invisibles l'association Z et ses pattes en préfixant Z d'un signe moins - :
%%mocodo\n:::\nDépôt: num dépôt, surface\n\n:\nLouer, 11 Commande, 0N Dépôt\n-Z, XX Commande, XX Article, XX Dépôt\nStocker, 1N Dépôt, 1N Article: quantité\n\nCommande: num. commande, date\nComposer, 1N Commande, 0N Article\n:\nArticle: réf. article, prix\n\n(I) ->Stocker, ..Dépôt, ..Article, --Composer, --Louer: Z, Z\nCette technique résiste très bien aux réarrangements automatiques.
\nGouttière d'identifiants¶
\nElle apparaît automatiquement (visibility=auto) dès qu'il y a au moins un identifiant alternatif. Il est possible de l'en empêcher :
%%mocodo --gutters ids:visibility=off\nCLIENT: Réf. client, 1_Nom, 1_Prénom, Adresse, 2_Mail\n... ou au contraire de la forcer quand elle est superfétatoire :
\n%%mocodo --gutters ids:visibility=on\nCLIENT: Réf. client, Nom, Prénom, Adresse, Mail\nVous pouvez aussi préciser quelles chaînes dénoteront un identifiant fort (par défaut, strong=ID), un identifiant faible (par défaut, weak=id) ainsi que les numéros des groupes d'identifiants alternatifs (par défaut, alts=123456789, mais vous pouvez lister moins de 9 symboles) :
%%mocodo --gutters ids:strong=➤,alts=❶❷❸❹\nCLIENT: Réf. client, 1_Nom, 1_Prénom, Adresse, 2_Mail\nStyle et direction des pattes de l'héritage¶
\nLe type de flèche spécifiant le mécanisme de passage au modèle relationnel (<=, <-, -> ou =>) fait par défaut l'objet d'une visualisation dès le modèle conceptuel : la ou les pattes vers les entités de destination des attributs migrants sont orientées vers celles-ci ; et la ou les autres pattes sont doublées (pour <= et =>) ou non (pour <- et ->).
%%mocodo -t\nPersonne: num SS, nom, prénom\n\n/XT\\ Personne => Homme, Femme: sexe\n\nHomme: \n:\nFemme: nom de jeune fille\n- \n
- Femme (num SS, nom, prénom, nom de jeune fille) \n
- Homme (num SS, nom, prénom) \n
Cette visualisation n'est pas conventionnelle : on se borne normalement à ajouter une flèche dirigée vers l'entité-mère.
\nPour désactiver l'embellissement opéré par Mocodo, sans pour autant changer le mécanisme de passage au relationnel, prolongez simplement d'un caractère la flèche : <==, <--, --> ou ==> :
%%mocodo -t\nPersonne: num SS, nom, prénom\n\n/XT\\ Personne ==> Homme, Femme: sexe\n\nHomme: \n:\nFemme: nom de jeune fille\n- \n
- Femme (num SS, nom, prénom, nom de jeune fille) \n
- Homme (num SS, nom, prénom) \n
Changement de la version 4.0. Précédemment, --> et ==> s'écrivaient respectivement ->> et =>>.
Retouches fines¶
\nLors du plongement, Mocodo génère systématiquement un fichier (intitulé par défaut sandbox_geo.json) répertoriant les positions les plus importantes du dessin. Les autres coordonnées sont calculées relativement à celles-ci.
%%mocodo --colors brewer+1\nVELIT, 1N> BLANDIT, 11 NONUMMY: sollicitudin\n\nBLANDIT: consequat, ligula, nibh, consequat\n:::\nNONUMMY: consequat, ligula\n \nVIVAMUS, 0N NONUMMY, 0N BLANDIT: eleifend, iaculis\nOuvrons le fichier de géométrie généré :
\ndisplay.Code(\"sandbox_geo.json\")\n{\n \"width\": 444,\n \"height\": 242,\n \"cx\": [\n [ \"VELIT\", 214 ],\n [ \"BLANDIT\", 58 ],\n [ \"NONUMMY\", 378 ],\n [ \"VIVAMUS\", 214 ]\n ],\n \"cy\": [\n [ \"VELIT\", 38 ],\n [ \"BLANDIT\", 117 ],\n [ \"NONUMMY\", 117 ],\n [ \"VIVAMUS\", 196 ]\n ],\n \"shift\": [\n [ \"VELIT,BLANDIT,0\", 0 ],\n [ \"VELIT,NONUMMY,0\", 0 ],\n [ \"VIVAMUS,NONUMMY,0\", 0 ],\n [ \"VIVAMUS,BLANDIT,0\", 0 ]\n ],\n \"ratio\": [\n [ \"VELIT,BLANDIT,0\", 1.0 ]\n ]\n}\nOn y trouve :
\n- \n
- un couple de dimensions
widthetheightdéfinit la taille du MCD ; \n - deux listes de couples
cxetcy, les abscisses et ordonnées des centres des boîtes ; \n - un dictionnaire
shift, les positions relatives des cardinalités par rapport à leur position par défaut ; \n - une liste
ratio, les positions des flèches éventuelles : leur valeur peuvent varier de0.0(flèche cachée sous la boîte d'origine) à1.0(par défaut, pointe de la flèche au contact du bord de la boîte de destination, compte non tenu de l'arrondi s'il s'agit d'une association). \n
Copions-collons ce texte, apportons-lui quelques modifications et sauvegardons-le :
\n%%file sandbox_geo.json\n{\n \"width\": 444,\n \"height\": 182,\n \"cx\": [\n [ \"VELIT\", 214 ],\n [ \"BLANDIT\", 58 ],\n [ \"NONUMMY\", 378 ],\n [ \"VIVAMUS\", 214 ]\n ],\n \"cy\": [\n [ \"VELIT\", 38 ],\n [ \"BLANDIT\", 87 ],\n [ \"NONUMMY\", 87 ],\n [ \"VIVAMUS\", 136 ]\n ],\n \"shift\": [\n [ \"VELIT,BLANDIT,0\", -30 ],\n [ \"VELIT,NONUMMY,0\", -30 ],\n [ \"VIVAMUS,NONUMMY,0\", 0 ],\n [ \"VIVAMUS,BLANDIT,0\", 0 ]\n ],\n \"ratio\": [\n [ \"VELIT,BLANDIT,0\", 0.5 ]\n ]\n}\nOverwriting sandbox_geo.json\n\n
Il suffit maintenant d'ajouter l'option --reuse_geo pour appliquer ces modifications :
%mocodo -i sandbox --colors brewer+1 --reuse_geo\nBien entendu, ce genre de manipulations doit rester exceptionnel. Il est en tout cas à réserver à la toute dernière étape de production d'un MCD, puisque la plupart des évolutions subséquentes de son texte-source frapperaient d'obsolescence votre fichier de géométrie.
\nNB. Étant donné que Mocodo produit des SVG, rien ne vous empêche de retoucher ceux-ci avec un logiciel de dessin vectoriel dédié, comme Inkscape (libre) ou Adobe Illustrator, Freehand, CorelDRAW, etc. Attention, le SVG généré n'est pas spécialement pensé pour cet usage. Certains éléments sont groupés pour permettre leur déplacement en bloc, mais les liens ne suivent pas ces déplacements, ce qui peut vite devenir fastidieux.
\nConversion dans d'autres formats graphiques¶
\nAvec l'option --svg_to suivie de pdf et/ou png, Mocodo convertit en PDF et/ou PNG le SVG généré pour le MCD.
%mocodo -i ccp --svg_to png pdf --select\nLe premier format est prévu pour inclusion dans des documents qui ne gèrent pas les SVG :
\ndisplay.IFrame(\"mocodo_notebook/ccp.pdf\", width=\"100%\", height=\"100%\")\nAttention, seules les polices de caractères les plus courantes apparaîtront correctement sur toutes les plateformes.
\nLe second est un format bitmap, donc avec une certaine perte de qualité :
\ndisplay.Image(\"ccp.png\")\nMentionnons une possibilité amusante, actuellement non intégrée à Mocodo : Svg2Rough.js pourra donner à votre travail une touche finale plus informelle, dans un style « tracé à main levée ».
\ndisplay.Image(\"../examples/svg2roughjs.png\")\nAnnexe A : Miscellanées académiques¶
\nDécompositions d'un MCD¶
\nAussi surprenant que cela puisse paraître, tout MCD peut être transformé en un MCD équivalent dont les seules associations sont des dépendances fonctionnelles binaires non porteuses d'attributs, telles que celle ci-dessous :
\n%%mocodo \nENTITÉ 1_: at 1 1, at 1 2, at 1 3\nDF, ?1 ENTITÉ 1_, XX ENTITÉ 2_\nENTITÉ 2_: at 2 1, at 2 2, at 2 3\nLa transformation peut demander jusqu'à trois opérations que Mocodo appelle drain, split et explode, et que nous allons découvrir dans la suite.
\nVider les DF de leurs attributs¶
\n%%mocodo -t\nEntreprise: nom entreprise, adresse, téléphone\nProposer, 0N Entreprise, 11 Stage: date proposition\nStage: num. stage, sujet\nAttribuer, 11 Étudiant, 01 Stage: date signature\nÉtudiant: num étudiant, nom\nSoutenir, 01 Étudiant, 0N Date: note stage\nDate: date\n- \n
- Entreprise (nom entreprise, adresse, téléphone) \n
- Étudiant (num étudiant, nom, #num. stage, date signature, date, note stage) \n
- Stage (num. stage, sujet, #nom entreprise, date proposition) \n
Le MCD ci-dessus comporte trois associations de dépendance fonctionnelle porteuses d'attributs. Certains auteurs considèrent cela comme une anomalie. En tout état de cause, Mocodo peut les déplacer dans les entités distinguées par les cardinalités 11. Nous appelons cette opération un « drainage des dépendances fonctionnelles » (option -t drain). Notez bien que ces deux MCD sont strictement équivalents, et produisent le même MLD.
%mocodo -i sandbox --mld -t drain\n- \n
- Entreprise (nom entreprise, adresse, téléphone) \n
- Étudiant (num étudiant, nom, date signature, #num. stage, date, note stage) \n
- Stage (num. stage, sujet, date proposition, #nom entreprise) \n
La première version peut être préférée pour des raisons de localité sémantique (date proposition dans PROPOSER), ou honnie parce qu'elle complique la définition d'identifiant d'association. Mocodo n'a pas d'opinion sur la question. Par contre, il se refuse à procéder au drainage via les cardinalités 01. Dans le MCD ci-dessus, le placement de note stage dans SOUTENIR indique qu'un étudiant peut ne pas se voir attribuer de note de stage ; si elle était mise dans ÉTUDIANT, la connaissance du fait que ce champ autorise la valeur NULL serait perdue.
Décomposer les DF n-aires¶
\nDe même, d'aucuns regardent de travers les dépendances fonctionnelles d'arité $n$ supérieure à 2 :
\n%%mocodo -t\nBataille: nom bataille, lieu, date\nRécolter, 0N Villageois, 0N Bataille, 11 Trophée\nVillageois: nom villageois, adresse, fonction\n\nTrophée: numéro, type, état\n- \n
- Bataille (nom bataille, lieu, date) \n
- Trophée (numéro, type, état, #nom villageois, #nom bataille) \n
- Villageois (nom villageois, adresse, fonction) \n
Toute DF de ce type peut en effet être « fendue » en $n-1$ DF. L'option -t split génère le MCD équivalent :
%mocodo -i sandbox --seed=3 --mld -t split arrange:wide\n- \n
- Bataille (nom bataille, lieu, date) \n
- Trophée (numéro, type, état, #nom bataille, #nom villageois) \n
- Villageois (nom villageois, adresse, fonction) \n
Décomposer les associations n-aires non DF¶
\nToute association non DF d'arité $n$ peut être décomposée en un ensemble de $n$ associations DF : elle-même se voit alors remplacée par une entité liée aux $n$ entités originales. Cette nouvelle entité est appelée « entité-intersection », « entité-associative » ou « Gerund », cf. Song, Il-Yeol & Evans, Mary & Park, Eui Kyun. A Comparative Analysis of Entity-Relationship Diagrams. Journal of Computer and Software Engineering. 3 (1995). Dans les cours de Laurent Audibert ou de Patrick Bergougnoux, l'opération est illustrée à l'aide du MCD suivant :
\n%%mocodo -t\nFilm: id. film, titre, durée\nProjeter, 1N Salle, 1N Créneau, 1N Film: tarif\nSalle: num. salle, capacité\n\nCréneau: num. créneau, date, heure début\n- \n
- Créneau (num. créneau, date, heure début) \n
- Film (id. film, titre, durée) \n
- Projeter (#num. salle, #num. créneau, #id. film, tarif) \n
- Salle (num. salle, capacité) \n
La décomposition est invoquée par l'option -t explode :
%mocodo -i sandbox --seed=8 --mld -t explode arrange:balanced\n- \n
- Créneau (num. créneau, date, heure début) \n
- Film (id. film, titre, durée) \n
- Projeter (id. projeter, tarif, #id. film, #num. salle, #num. créneau) \n
- Salle (num. salle, capacité) \n
Le nouveau MCD a vocation à être retouché pour :
\n- \n
- se rapprocher du plongement initial ; \n
- nommer judicieusement les nouveaux identifiant, entité et associations créés. \n
%%mocodo -t\nFilm: id. film, titre, durée\nConcerner, 11 Projection, 1N Film\nProjection: id. projection, tarif\nAvoir lieu dans, 11 Projection, 1N Salle\nSalle: num. salle, capacité\n\nAvoir lieu pendant, 11 Projection, 1N Créneau\n\nCréneau: num. créneau, date, heure début\n- \n
- Créneau (num. créneau, date, heure début) \n
- Film (id. film, titre, durée) \n
- Projection (id. projection, tarif, #id. film, #num. salle, #num. créneau) \n
- Salle (num. salle, capacité) \n
Décomposer les associations binaires non DF¶
\nConsidérons le MCD suivant, qui comporte deux associations binaires non DF, l'une porteuse d'attribut, l'autre non :
\n%%mocodo -t\nCOMMANDE: num. commande, date, montant\nLIGNE COM., 1N COMMANDE, 0N PRODUIT: quantité\nPRODUIT: réf. produit, libellé, prix unitaire\nDISPONIBILITÉ, 1N PRODUIT, 0N PAYS\nPAYS: code pays, nom pays\n- \n
- COMMANDE (num. commande, date, montant) \n
- DISPONIBILITÉ (#réf. produit, #code pays) \n
- LIGNE COM. (#num. commande, #réf. produit, quantité) \n
- PAYS (code pays, nom pays) \n
- PRODUIT (réf. produit, libellé, prix unitaire) \n
Par souci de concision, quand on parle d'associations $n$-aires dans ce document, c'est par opposition aux associations binaires ; mais bien sûr, la règle de décomposition énoncée à la section précédente est également valable pour $n=2$, même si par défaut elle ne s'applique qu'aux associations d'arité minimale 3. En réduisant la valeur de arity à 2, toutes les associations binaires non DF seront également décomposées :
%mocodo -i=sandbox --seed=1 --scale=0.9 --mld -t explode:arity=2 arrange:wide=9\n- \n
- COMMANDE (num. commande, date, montant) \n
- DISPONIBILITÉ (id. disponibilité, #réf. produit, #code pays) \n
- LIGNE COM. (id. ligne com., quantité, #num. commande, #réf. produit) \n
- PAYS (code pays, nom pays) \n
- PRODUIT (réf. produit, libellé, prix unitaire) \n
Cette décomposition devient un peu extrême ! Vous pouvez conserver certaines associations binaires non DF, à savoir celles qui ne portent aucun attribut, en mettant arity à 2.5 (à lire comme « intermédiaire entre 2 et 3 ») :
%mocodo -i=sandbox --mld -t explode:arity=2.5 arrange:wide --seed=1\n- \n
- COMMANDE (num. commande, date, montant) \n
- DISPONIBILITÉ (#réf. produit, #code pays) \n
- LIGNE COM. (id. ligne com., quantité, #réf. produit, #num. commande) \n
- PAYS (code pays, nom pays) \n
- PRODUIT (réf. produit, libellé, prix unitaire) \n
Décomposer en créant des entités faibles¶
\nCi-dessus, le processus de modification a créé un identifiant id. ligne com. qui peut sembler superfétatoire. Si l'on a introduit la notion d'entité faible, on aura ici avantage à utiliser l'option weak :
%mocodo -i=sandbox --mld -t explode:arity=2.5,weak arrange:wide --seed=1\n- \n
- COMMANDE (num. commande, date, montant) \n
- DISPONIBILITÉ (#réf. produit, #code pays) \n
- LIGNE COM. (#num. commande, #réf. produit, quantité) \n
- PAYS (code pays, nom pays) \n
- PRODUIT (réf. produit, libellé, prix unitaire) \n
Cas des agrégats. Comme on sait, la notion d'entité faible peut souvent permettre de se passer de celle d'agrégat. Ainsi, le MCD ci-dessous :
\n%%mocodo -t --colors ocean\nChambre: num. chambre, tarif\nRéservation, /1N Client, 1N Chambre, 0N Date: durée\nClient: réf. client, nom client\n\nDate: date\n- \n
- Chambre (num. chambre, tarif) \n
- Client (réf. client, nom client) \n
- Réservation (#num. chambre, date, #réf. client, durée) \n
... se verra décomposé de la même façon que sans agrégat, à ceci près que la patte distinguée par le \"/\" produira une cardinalité 11 au lieu d'une cardinalité _11 :
%mocodo -i sandbox --mld -t explode:weak arrange:wide=5 --seed 21\n- \n
- Chambre (num. chambre, tarif) \n
- Client (réf. client, nom client) \n
- Réservation (date, #num. chambre, durée, #réf. client) \n
Cette décomposition peut quelquefois se simplifier. Ici, on remarque que l'entité DATE est indépendante et réduite à son identifiant. Si l'on anticipe sur le passage au relationnel, on peut donc la supprimer, après avoir pris soin, bien sûr, de déplacer dans RÉSERVATION son unique attribut. Celui-ci renforçant une entité faible, il doit garder son caractère identifiant.
\n%%mocodo -t\nChambre: num. chambre, tarif\nDF, _11 Réservation, 1N Chambre\nRéservation: date, durée\nDF, 11 Réservation, 1N Client\nClient: réf. client, nom client\n- \n
- Chambre (num. chambre, tarif) \n
- Client (réf. client, nom client) \n
- Réservation (#num. chambre, date, durée, #réf. client) \n
Conclusion sur ces décompositions¶
\nComme l'indique le nom que nous leur avons malicieusement attribué, certaines de ces décompositions peuvent littéralement faire exploser la taille du MCD. Cependant :
\n- \n
- elles sont intéressantes d'un point de vue
terroristethéorique ; \n - elles peuvent permettre la détection d'erreurs de conception ; \n
- elles peuvent conduire à des améliorations fines du MCD (c'est ce qu'on a fait sur celui des réservations de chambre) ; \n
- elles décrivent le MCD dans un langage volontairement appauvri, ce qui le rendra plus aisément portable dans une autre notation, comme UML ou crow's foot. \n
Équivalences avec la convention Look Across¶
\nLa convention Look Across s'oppose à la convention Look Here de Merise. Elle est plus répandue internationalement.\nNous allons l'étudier par le biais du formalisme graphique de Chen, auquel cette section pourra du même coup servir d'introduction pour les personnes familières avec Merise.
\nAssociations binaires en Look Across¶
\nCardinalités minimale et maximale¶
\nConsidérons un MCD Merise avec une association de dépendance fonctionnelle :
\n%%mocodo\nEmployé: employé\nTravailler, 11 Département, 1N Employé\nDépartement: département\nDans le formalisme graphique de Chen, cela donnera :
\n%mocodo -i sandbox -t chen:layout=circo --defer\n\n\n\nsandbox_erd_chen.svg\n\n\n
Le 1 et le N correspondent aux cardinalités maximales du MCD Merise. Comme on voit, elles sont permutées. Merise suit la convention Look Here (LH) ; la notation de Chen, Look Across (LA). Comme cette dernière est la plus répandue dans le monde anglo-saxon, nous parlerons par commodité d'« ERD » (Entity-relationship diagram) pour les modèles conceptuels selon Chen, et toujours de « MCD » pour ceux de Merise.
\nConsidérons maintenant les deux versions d'une association avec des cardinalités minimales distinctes :
\n%%mocodo\nMer: mer\nRecevoir, 01 Rivière, 1N Mer\nRivière: rivière\n%mocodo -i sandbox -t chen:layout=circo --defer\n\n\n\nsandbox_erd_chen.svg\n\n\n
Les cardinalités maximales sont toujours permutées ; par contre, les cardinalités minimales ne le sont pas. Dans l'ERD, elles sont figurées par un trait simple (0) ou double (1). On les appelle aussi des « participations » : une rivière peut ne participer (directement) à l'alimentation d'aucune mer (ce n'est pas un fleuve) ; toute mer participe à la réception d'une rivière (un fleuve) minimum. Les conventions sont donc les suivantes :
\n| Cardinalités | \nMCD Merise | \nERD Chen | \n
|---|---|---|
| minimale | \nLH | \nLH | \n
| maximale | \nLH | \nLA | \n
La notation Merise a l'avantage de la cohérence ; celle de Chen en a d'autres, que nous verrons un peu plus loin.
\nAvant cela, voyons un dernier point de détail : lorsque deux cardinalités N se trouvent de part et d'autre d'une association binaire, l'une est notée M :
\n%%mocodo\nPROJET: projet\nREQUÉRIR, 1N PROJET, 0N PIÈCE\nPIÈCE: pièce\nCOMPOSER, 0N PIÈCE, 0N PIÈCE\n%mocodo -i sandbox -t chen:layout=circo --defer\n\n\n\nsandbox_erd_chen.svg\n\n\n
Entités faibles et entités associatives¶
\nMaintenant examinons le cas des entités faibles :
\n%%mocodo\nŒuvre: œuvre\nDF, 0N Œuvre, _11 Exemplaire\nExemplaire: exemplaire\n%mocodo -i sandbox -t chen:layout=circo --defer\n\n\n\nsandbox_erd_chen.svg\n\n\n
L'entité faible, à l'instar de la DF « renforçante », sont entourées d'un double trait.
\nLe vocabulaire de Chen comporte encore un élément graphique, que Merise ne distingue pas spécialement. Nous avons vu que toute association non DF pouvait être décomposée de façon équivalente par l'insertion d'entités faibles :
\n%%mocodo\nProduit: produit\nDF, _11 Ligne de commande, 0N Produit\nLigne de commande: _quantité\nDF, _11 Ligne de commande, 1N Commande\nCommande: commande\nLIGNE DE COMMANDE est quelquefois qualifiée d'« entité associative », et Chen la figure logiquement par un losange (association) inscrit dans un rectangle (entité). Graphviz ne prend actuellement pas en charge cette représentation. Nous l'approximons donc ainsi :
\n%mocodo -i sandbox -t chen:layout=circo,mindist=2,scale=0.6 --defer\n\n\n\nsandbox_erd_chen.svg\n\n\n
Associations n-aires en Look Across¶
\nTriplet NNN¶
\nPassons maintenant aux choses sérieuses. Jusqu'ici, la différence entre les deux notations était purement cosmétique. Qu'en est-il des associations n-aires, et que signifie Look Across quand across peut désigner plusieurs endroits ?
\n%%mocodo -t\nEmployé: employé\nAppliquer, 0N Employé, 1N Projet, 1N Compétence\nProjet: projet\n\nCompétence: compétence\n- \n
- Appliquer (employé, projet, compétence) \n
Dans ce cas (le plus usuel), la question ne se pose pas vraiment, ou du moins n'est pas tranchée de façon évidente :
\n%mocodo -i sandbox -t chen:layout=circo,mindist=1,scale=0.4 --defer\n\n\n\nsandbox_erd_chen.svg\n\n\n
Quels sont les autres cas ? Il ne s'agit pas de ceux où l'association n-aire est entourée d'une ou plusieurs cardinalités maximale 1, puisqu'on pourrait alors la décomposer en DF binaires (cf. argument split). En réalité, on touche ici aux limites de la notation Look Here, plus intuitive, mais moins puissante que Look Across, et que Merise n'a pu rattraper que dans sa version 2.
Pour répondre progressivement à la question, procédons désormais dans l'ordre inverse, en présentant d'abord l'ERD, et ensuite seulement le MCD équivalent.
\nLes exemples qui suivent (ainsi d'ailleurs que le précédent), sont adaptés des pages 28 sqq. et 96 sqq. de l'ouvrage de Toby J. Teorey, Sam S. Lightstone, Tom Nadeau, H.V. Jagadish, Database Modeling and Design - Logical Design, 5th Edition - February 10, 2011 (Elsevier).
\nTriplet 1NN¶
\nLe premier ERD apportant véritablement quelque chose de nouveau a cette structure :
\n%%mocodo -t chen:layout=circo,mindist=1,scale=0.45 --defer\nIngénieur: ingénieur\nGérer, /1N Responsable, 1N Ingénieur, 1N Projet\nProjet: projet\n\nResponsable: responsable\n\n\n\nsandbox_erd_chen.svg\n\n\n
Les auteurs explicitent ainsi ses règles de gestion :
\n\n\nChaque ingénieur travaillant sur un projet particulier a exactement un responsable, mais chaque responsable d'un projet peut gérer plusieurs ingénieurs, et chaque responsable d'un ingénieur peut gérer cet ingénieur sur plusieurs projets.
\n
Reprenons ces trois assertions, et faisons-les correspondre au trois cardinalités dans le sens anti-horaire à partir du 1 :
\n- \n
- 1 : pour un couple (ingénieur, projet) donné, un seul responsable possible ; \n
- N : pour un couple (responsable, projet) donné, plusieurs ingénieurs possibles ; \n
- N : pour un couple (responsable, ingénieur) donné, plusieurs projets possibles. \n
Avec Merise, les assertions seraient plutôt du type : « pour un x donné, tant de couples (y, z) possibles ». Il y a donc bien permutation, mais permutation des références au singleton et au $n-1$-uplet.
\nC'est la réponse à notre question initiale, et nous verrons avec plaisir qu'elle reste valable quel que soit le triplet de cardinalités de l'association ternaire.
\nPour l'instant, résumons les règles de gestion par cette unique dépendance fonctionnelle :
\n- \n
- (Ingénieur, Projet) $\\implies$ Responsable. \n
Pour exprimer cela en (ou en dépit de) Look Here, on doit recourir à un agrégat :
\n%mocodo -i sandbox --mld --colors pond\n- \n
- Gérer (ingénieur, projet, responsable) \n
… ou à une CIF à unicité complète (ici en notation allégée) :
\n%mocodo -i sandbox --mld -t create:cifs=light arrange:balanced --seed=3\n- \n
- Gérer (ingénieur, projet, responsable) \n
... Ou encore à une entité faible :
\n%mocodo -i sandbox --mld -t explode:weak,arity=2 arrange:balanced --seed=14\n- \n
- Gérer (ingénieur, projet, responsable) \n
Les schémas relationnels produits permettent de se convaincre que ces différentes variantes respectent bien la dépendance fonctionnelle désirée : (Ingénieur, Projet) $\\implies$ Responsable.
\nTriplet 11N¶
\nPassons à la deuxième combinaison intéressante :
\n%%mocodo -t chen:layout=circo,mindist=1,scale=0.45 --defer\nProjet: projet\nAffecter, /1N Site, /1N Projet, 0N Employé\nSite: site\n\nEmployé: employé\n\n\n\nsandbox_erd_chen.svg\n\n\n
Règles de gestion :
\n\n\nChaque employé affecté à un projet travaille sur un seul site pour ce projet, mais peut se trouver sur différents sites pour différents projets. Sur un site donné, un salarié ne travaille que sur un seul projet. Sur un site donné, il peut y avoir plusieurs employés affectés à un projet donné.
\n
Autrement dit (en partant du bas et dans le sens anti-horaire) :
\n1 : pour un couple (projet, employé) donné, un seul site possible ;\n1 : pour un couple (employé, site) donné, un seul projet possible ;\nN : pour un couple (projet, site) donné, plusieurs employés possibles.
\nEn résumé, deux dépendances fonctionnelles :
\n- \n
- (Projet, Employé) $\\implies$ Site. \n
- (Employé, Site) $\\implies$ Projet. \n
Voici le MCD correspondant, successivement avec des agrégats et des CIFS (plus de variante possible avec entité faible) :
\n%mocodo -i sandbox --select all -t mld:c --colors pond\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Affecter (projet, employé u1, site! u1) \n
%mocodo -i sandbox --select mcd mld -t mld:c create:cifs=light arrange:balanced --seed=3\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Affecter (projet, employé u1, site! u1) \n
On voit apparaître dans le schéma relationnel un « u1 » en exposant qui signifie : contrainte d'unicité n°1. Il y a en effet deux clés candidates : (projet, employé) et (employé, site). Seule l'une des deux est devenue clé primaire, mais cela ne veut pas dire qu'on a perdu la contrainte de dépendance fonctionnelle induite par l'autre. En SQL :
\n%mocodo -i sandbox -t sql\n\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE Affecter (\n PRIMARY KEY (projet, employe),\n projet VARCHAR(42) NOT NULL,\n employe VARCHAR(42) NOT NULL,\n site VARCHAR(42) NOT NULL,\n UNIQUE (employe, site)\n);\nTriplet 111¶
\nLa dernière combinaison obéit à la même logique :
\n%%mocodo -t chen:layout=circo,mindist=1,scale=0.45 --defer\nTechnicien: technicien\nUtiliser, /1N Technicien, /1N Carnet, /1N Projet\nProjet: projet\n\nCarnet: carnet\n\n\n\nsandbox_erd_chen.svg\n\n\n
Règles de gestion :
\n\n\nUn technicien utilise exactement un carnet pour chaque projet. Chaque carnet appartient à un technicien pour chaque projet. Notez qu'un technicien peut toujours travailler sur plusieurs projets et gérer différents carnets pour différents projets.
\n
Autrement dit (en partant du haut et dans le sens horaire) :
\n- \n
- 1 : pour un couple (technicien, projet) donné, un seul carnet possible ; \n
- 1 : pour un couple (carnet, projet) donné, un seul technicien possible ; \n
- 1 : pour un couple (carnet, technicien) donné, un seul projet possible. \n
En résumé, trois dépendances fonctionnelles :
\n- \n
- (Technicien, Projet) $\\implies$ Carnet. \n
- (Carnet, Technicien) $\\implies$ Projet. \n
- (Carnet, Projet) $\\implies$ Technicien. \n
%mocodo -i sandbox --select all -t mld:c --colors pond\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Utiliser (carnet u1, projet u2, technicien! u1 u2) \n
%mocodo -i sandbox --select mcd mld -t mld:c create:cifs=light arrange:balanced flip:d,v --seed=12\n\n\n\nsandbox_mld.md\n\n\n
- \n
- Utiliser (carnet u1, projet u2, technicien! u1 u2) \n
Il y a maintenant trois clés candidates, correspondant à deux contraintes d'unicité. En SQL :
\n%mocodo -i sandbox -t sql\n\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE Utiliser (\n PRIMARY KEY (carnet, projet),\n carnet VARCHAR(42) NOT NULL,\n projet VARCHAR(42) NOT NULL,\n technicien VARCHAR(42) NOT NULL,\n UNIQUE (carnet, technicien),\n UNIQUE (projet, technicien)\n);\nConclusion sur les agrégats multiples¶
\nNotre syntaxe /1N pour les agrégats permet d'exprimer simplement toutes les combinaisons possibles de cardinalités d'une association n-aire dans la notation de Chen : il suffit de mettre un /1N partout où Chen met un 1. Chaque /1N créera une nouvelle dépendance fonctionnelle, autrement dit, une nouvelle clé candidate.
Plus rigoureusement : supposons une association $n$-aire $A$ exclusivement entourée de 1N (ou 0N). Soient $E_1$, $E_2$, ..., $E_n$ les entités mises en jeu, et $k_1, k_2$, ..., $k_n$ leurs identifiants respectifs. Alors, noter /1N (ou /0N) la cardinalité de la patte de $E_i$ dénote l'existence de la dépendance fonctionnelle suivante : $(k_1, ..., k_{i-1}, k_{i+1}, ..., k_n) \\implies k_i$, autrement dit : que $(k_1, ..., k_{i-1}, k_{i+1}, ..., k_n)$ est une clé candidate de la table $A$.
Notez pour finir que Mocodo permet de spécifier à coût zéro quelle clé candidate sera élue clé primaire. Il suffit pour cela de placer en tête de la liste des entités mises en jeu par $A$ celle dont l'identifiant ne doit pas entrer dans la clé primaire. Si c'est $E_1$, la clé primaire sera automatiquement $(k_2, ..., k_n)$.
\nAnnexe B : La commande mocodo¶
\nParamétrage¶
\nmocodo --help¶
\n%mocodo --help\nusage: mocodo [--language CODE] [--params_path PATH] [--input PATH] [--help]\n [--version] [--restore] [--lib [URL]] [--output_dir PATH]\n [--encodings [STR ...]] [--svg_to {png,pdf} [{png,pdf} ...]]\n [--print_params] [--reuse_geo] [--uid_suffix INT]\n [--select [{all,mcd,rw,source,text,code,mocodo,cv,mld,ddl,sql} ...]]\n [--defer [STR ...]] [--mld] [--transform [STR ...]]\n [--seed [FLOAT]] [--title STR] [--df STR] [--card_format [STR]]\n [--fk_format [STR]] [--strengthen_card [STR]] [--flex FLOAT]\n [--colors STEM_OR_PATH] [--shapes STEM_OR_PATH] [--scale RATE]\n [--adjust_width RATE] [--detect_overlaps] [--no_assoc_ids]\n [--gutters STR [STR ...]]\n\nNOM :\nMocodo - Un générateur de diagrammes entité-association.\n\nDESCRIPTION :\nMocodo est un outil libre destiné à l'enseignement des bases de données relationnelles.\nIl prend en entrée une description textuelle des entités et associations d'un diagramme\nentité-association (MCD). Il produit en sortie un dessin vectoriel en SVG et un schéma\nrelationnel dans divers formats (SQL, LaTeX, Markdown, etc.).\n\nNOTE :\nChacune des valeurs suivantes est :\n- spécifiée explicitement par l'utilisateur comme option de ligne de commande ;\n- sinon, récupérée depuis un fichier de chemin --params_path ;\n- sinon, récupérée depuis un fichier nommé « params.json » dans le répertoire d'entrée ;\n- sinon, calculée à partir d'une valeur par défaut, éventuellement dépendante de votre système.\n \n\nOPTIONS SUR MOCODO LUI-MÊME :\n --language CODE force la localisation des messages avec le code de\n langue donné (par exemple, « fr », « en », ...)\n (default: fr)\n --help affiche ce message d'aide, puis termine\n --version affiche le numéro de version, puis termine\n --restore recrée une version vierge des fichiers « sandbox.mcd »\n et « params.json » dans le répertoire d'entrée, puis\n termine (default: False)\n\nENTRÉE/SORTIE :\n --params_path PATH le chemin du fichier de paramètres. S'il est omis,\n utilise « params.json » dans le répertoire d'entrée.\n S'il n'existe pas, utilise les paramètres par défaut.\n (default: params.json)\n --input PATH, -i PATH\n le chemin du fichier d'entrée. Par défaut, les\n fichiers de sortie seront générés dans le même\n répertoire (default: /Users/aristide/Dropbox/Sites/moc\n odo/doc/mocodo_notebook/sandbox.mcd)\n --lib [URL] remote directory to use as fallback when the input\n file is not found locally (default:\n https://mocodo.net/web/lib)\n --output_dir PATH le répertoire des fichiers de sortie (default: .)\n --encodings [STR ...]\n un ou plusieurs encodages à essayer successivement\n lors de la lecture du fichier d'entrée (default:\n ['utf8', 'macroman'])\n --svg_to {png,pdf} [{png,pdf} ...]\n génère une version PNG ou PDF de la sortie SVG\n (requiert CairoSVG) (default: [])\n --print_params affiche le contenu du fichier de paramètres, puis\n termine (default: False)\n --reuse_geo réutilise le fichier de géométrie de l'exécution\n précédente (default: False)\n --uid_suffix INT ajoute un discriminateur à un SVG interactif (default:\n 0)\n --select [{all,mcd,rw,source,text,code,mocodo,cv,mld,ddl,sql} ...]\n sous Jupyter Notebook, spécifie explicitement les\n catégories de résultats à afficher\n --defer [STR ...] utilise un service web externe pour convertir les\n résultats de la conversion dans les formats graphiques\n donnés\n --mld alias de compatibilité ascendante pour « -t » (sans\n arguments). Équivalent à « -t markdown » mais, sous\n Jupyter Notebook, n'empêche pas le rendu du diagramme\n conceptuel dans la sortie de la cellule (default:\n False)\n --transform [STR ...], -t [STR ...]\n crée une nouvelle version du MCD en appliquant\n séquentiellement les opérations de réécriture données,\n et/ou le convertit dans les formats ou langages\n donnés. Sous Jupyter Notebook, « -T » remplace\n respectivement la cellule courante par le résultat\n textuel, ou le copie dans le presse-papier (pip3\n install pyperclip)\n --seed [FLOAT] valeur initiale pour le générateur de nombres\n aléatoires (default: None)\n --title STR nom du modèle, utilisé à divers endroits (système de\n fichiers, base de données, etc.) (default: MCD)\n\nASPECT DE LA SORTIE GRAPHIQUE :\n --df STR l'acronyme à entourer dans une dépendance\n fonctionnelle (default: DF)\n --card_format [STR] chaîne de formatage pour les cardinalités minimales et\n maximales (default: {min_card},{max_card})\n --fk_format [STR] chaîne de formatage pour les clés étrangères dans le\n diagramme relationnel (default: #{label})\n --strengthen_card [STR]\n chaîne pour les cardinalités relatives (default:\n _1,1_)\n --flex FLOAT incurve les pattes rectilignes dont les cardinalités\n peuvent se chevaucher (default: 0.75)\n --colors STEM_OR_PATH\n la palette de couleurs à utiliser lors de la\n génération du dessin. Nom (sans extension) d'un\n fichier situé dans le répertoire « colors », ou chemin\n vers un fichier personnel (default: bw)\n --shapes STEM_OR_PATH\n spécification des polices, dimensions, etc. Nom (sans\n extension) d'un fichier situé dans le répertoire\n « shapes », ou chemin vers un fichier personnel\n (default: copperplate)\n --scale RATE applique au diagramme le facteur de mise à l'échelle\n donné (default: 1)\n --adjust_width RATE applique à tous les textes calculés le facteur de mise\n à l'échelle donné (default: 1)\n --detect_overlaps lève une erreur quand des pattes horizontales ou\n verticales se chevauchent (default: False)\n --no_assoc_ids interdit l'utilisation d'identifiants dans les\n associations (conformément au standard Merise)\n (default: False)\n --gutters STR [STR ...]\n définit la visibilité et le contenu des gouttières\n latérales\n\nVOIR AUSSI :\n Version en ligne https://mocodo.net\n Code source https://github.com/laowantong/mocodo\n Documentation https://laowantong.github.io/mocodo/doc/fr_refman.html\n Aide-mémoire pour -t https://github.com/laowantong/mocodo/blob/master/doc/fr_cheat_sheet.md\n\nLICENCE : MIT\n\nCONTACT :\n Auteur Aristide Grange\n Adresse Université de Lorraine\n Laboratoire LCOMS - UFR MIM\n 3 rue Augustin Fresnel\n 57070 METZ Technopôle\n France\n Courriel <prénom.nom>@univ-lorraine.fr\n \n\nParamétrage à long terme¶
\nPour éviter d'avoir à invoquer Mocodo répétitivement avec une longue kyrielle d'options, vous pouvez mettre celles-ci dans un fichier params.json situé dans le répertoire de lancement de Mocodo. La commande:
mocodo --restore... le fait pour vous avec un fichier de paramètres vide, i.e., un fichier-texte réduit aux deux caractères {} (attention, elle rétablit aussi le fichier sandbox.mcd à son contenu par défaut).
Pour que le style de vos MCD soit maintenu à moindre frais à travers tous vos documents, vous êtes encouragés à modifier ce fichier de paramètres selon vos goûts et vos besoins. Mocodo peut même vous aider à le faire en exécutant la cellule suivante:
\n%mocodo --print_params\nSon évaluation remplace son propre contenu par des lignes de code similaires à :
\n# You may edit and run the following lines\nimport json, pathlib\nparams = \"\"\"\\\n{\n \"adjust_width\": 1,\n \"card_format\": \"{min_card},{max_card}\",\n \"colors\": \"bw\",\n \"detect_overlaps\": false,\n \"df\": \"DF\",\n \"encodings\": [ \"utf8\", \"macroman\" ],\n \"fk_format\": \"#{label}\",\n \"flex\": 0.75,\n \"language\": \"fr\",\n \"lib\": \"https://mocodo.net/web/lib\",\n \"mld\": false,\n \"no_assoc_ids\": false,\n \"output_dir\": \".\",\n \"restore\": false,\n \"scale\": 1,\n \"seed\": null,\n \"shapes\": \"copperplate\",\n \"strengthen_card\": \"_1,1_\",\n \"svg_to\": [],\n \"title\": \"MCD\",\n \"uid_suffix\": 0\n}\"\"\"\ntry:\n json.loads(params)\nexcept:\n raise RuntimeError(\"Invalid JSON. Check your syntax on https://jsonlint.com.\")\npathlib.Path(\"./params.json\").write_text(params, encoding=\"utf8\");\nEnsuite :
\n- \n
- Modifiez la variable
paramsà votre gré en respectant la syntaxe JSON. \n - Exécutez la cellule pour créer un fichier de nom et emplacement adéquats. \n
En cas de besoin, vous pourrez toujours ponctuellement passer outre ces réglages en en précisant d'autres en ligne de commande. Plus précisément, chaque paramètre est déterminé:
\n- \n
- par sa valuation en ligne de commande; \n
- à défaut, par sa valuation dans le fichier de paramètres indiqué par
--params_path; \n - à défaut d'une telle indication, par sa valuation dans le fichier
params.jsondu répertoire courant; \n - à défaut, par une valeur défaut éventuellement dépendante de votre système. \n
Dissection de la commande¶
\nL'API de Mocodo a été revue de façon radicale pour la version 4.0. Le nombre d'options de premier niveau a été réduit ; en contrepartie, certaines sont devenues de véritables mini-commandes, avec leur propre liste d'arguments, et une syntaxe et un comportement uniformes. Voici leur définition en ABNF :
\n![\"\"](\"examples/option_syntax_2.png\"/)
Introduisons, sur un exemple fictif, un vocabulaire que nous avons essayé d'employer le plus rigoureusement possible tout au long de cette documentation (et dans le code lui-même) :
\nmocodo --select all --transform drain arrange:wide explode:weak,arity=2.5\n- \n
- La commande
mocodoest invoquée avec les options--selectet--transform. \n - On passe à la seconde trois arguments de complexité croissante,
drain,arrange:wideetexplode:weak,arity=2.5. Notez que le séparateur des arguments est l'espace. Par conséquent, un argument ne peut contenir d'espaces qu'entre guillemets. \n - Chacun des arguments consiste en un nom de sous-option (
drain,arrangeouexplode), suivi éventuellement d'un deux-points (:), suivi d'une liste de sous-arguments séparés par des virgules (,). \n - Chacun des sous-arguments consiste en un nom de sous-sous-option, suivi éventuellement d'un signe égal (
=), suivi d'un sous-sous-argument (éventuellement entre guillemets). \n
On n'ira pas plus loin et, heureusement, la plupart des commandes réelles n'atteignent pas ce degré d'imbrication. La décomposition suivante fixera peut-être les idées, ou pourra du moins servir de référence en cas de doute :
\n$$\n\\underbrace{\\texttt{mocodo}}_{\\text{command}}\n\\qquad\n\\texttt{-}\\,\\texttt{-}\n\\underbrace{\\texttt{select}}_{\\text{option}}\n\\underbrace{\n \\texttt{all}\n}_{\\text{argument}}\n\\qquad\n\\texttt{-}\\,\\texttt{-}\n\\underbrace{\\texttt{transform}}_{\\text{option}}\n\\qquad\n\\underbrace{\n \\underbrace{\n \\texttt{drain}\n }_{\\text{sub-option}}\n}_{\\text{argument}}\n\\qquad\n\\underbrace{\n \\underbrace{\n \\texttt{arrange}\n }_{\\text{sub-option}}\n \\texttt{:}\n \\underbrace{\n \\underbrace{\n \\texttt{wide}\n }_{\\text{sub-sub-opt}}\n }_{\\text{sub-arg}}\n}_{\\text{argument}}\n\\qquad\n\\underbrace{\n \\underbrace{\n \\texttt{explode}\n }_{\\text{sub-option}}\n \\texttt{:}\n \\underbrace{\n \\underbrace{\n \\texttt{weak}\n }_{\\text{sub-sub-opt}}\n }_{\\text{sub-arg}}\n \\texttt{,}\n \\underbrace{\n \\underbrace{\n \\texttt{arity}\n }_{\\text{sub-sub-opt}}\n \\texttt{=}\n \\underbrace{\n \\texttt{2.5}\n }_{\\text{sub-sub-arg}}\n }_{\\text{sub-argument}}\n}_{\\text{argument}}\n$$
\nL'intérêt de cette structuration en arborescence est double. Elle permet :
\n- \n
- de créer des pipelines d'opérations : le résultat de l'application du premier argument est fourni en entrée au second, etc ; \n
- de regrouper les opérations interdépendantes. Par exemple, avant la version 4.0, l'argument
explode:weak,arity=2.5aurait dû être mis à plat :--explode --weak_explosion --explosion_arity=2.5. Cela donne le même statut à toutes, masquant le fait que certaines n'ont de sens qu'en présence d'une autre. \n
L'option --transform et ses arguments¶
\nTriage et exécution des transformations¶
\nL'option à tout faire est --transform, que vous pouvez abréger -t. Avant de traiter ses arguments, Mocodo commence par les répartir en deux catégories :
- \n
- les réécritures, qui transforment le MCD original en un nouveau MCD avec, par exemple, les libellés mis en majuscules, ou les associations n-aires décomposées en DF, ou les boîtes réarrangées ; \n
- les conversions, qui produisent quelque chose qui n'est pas un MCD : ce peut être un dictionnaire des données, un diagramme de classes UML, un ERD dans la notation crow's foot, etc. \n
L'exécution se déroule alors en deux étapes :
\n- \n
- les réécritures sont opérées en pipeline, c'est-à-dire que le MCD produit par la première réécriture est passé en entrée de la seconde, etc. Leur ordre a donc de l'importance ; \n
- les conversions sont alors appliquées au résultat de la dernière réécriture. Leur ordre n'a pas d'importance. \n
Aide-mémoire des transformations¶
\nL'option -t (ou --transform) permet d'accéder à un grand nombre d'opérations de conversion ou de réécriture.
Toutes les opérations de conversion ont déjà été décrites dans ce document :
\n- \n
- produits dérivés :
data_dict,share; \n - schémas relationnels textuels :
html,latex,markdown,text; \n - DDL :
sql(et ses dialectes) ; \n - autres sorties relationnelles :
diagram,dbml,d2,dependencies; \n - conversions dans d'autres notations :
uml,crow,chen. \n
Certaines opérations de réécriture ont été présentées, d'autres passées sous silence :
\n- \n
- réorganisation du MCD :
arrange,flip; \n - obfuscation et randomisation d'éléments donnés :
randomize,drown; \n - génération de MCD aléatoires :
grow; \n - décomposition d'associations :
split,drain,explode; \n - inférence d'informations manquantes :
create; \n - suppression d'éléments donnés :
delete; \n - traitement de chaînes de caractères :
truncate,slice,prefix,suffix,replace; \n - homogénéisation de la mise en forme :
ascii,camel,snake,pascal,lower,upper, etc. \n
L'aide-mémoire suivant devrait vous permettre de prendre en main les sous-options de --transform qui vous intéressent. Survolez une sous-option pour afficher ses alias éventuels.
display.Markdown(\"../fr_cheat_sheet.md\")\nOpérations de conversion¶
| Sous-option | \nDescription | \nExemples | \nExplications | \n
|---|---|---|---|
| ast | \ncrée l'arbre de syntaxe abstraite du texte source (pour le débogage) | \n\n | \n |
| chen | \nconvertit le modèle conceptuel dans la notation de Chen | \nchen | \nsans attributs | \n
| \n | \n | chen:attrs | \navec attributs | \n
| \n | \n | chen:attrs --defer | \ncalcule le rendu graphique via un service web | \n
| \n | \n | chen:layout=circo,mindist=2,scale=0.6 | \najoute des options arbitraires pour Graphviz | \n
| crow | \nconvertit le modèle conceptuel dans la notation crow's foot | \ncrow | \nformat Graphviz | \n
| \n | \n | crow --defer | \ncalcule le rendu graphique via un service web | \n
| \n | \n | crow:mmd | \nformat Mermaid | \n
| \n | \n | crow:mermaid | \nidem | \n
| d2 | \nconvertit le modèle conceptuel en un schéma relationnel au format D2 | \n\n | \n |
| data_dict | \nextrait tous les attributs du MCD dans une table | \ndata_dict | \ntableau Markdown, trois colonnes | \n
| \n | \n | data_dict:label | \nliste Markdown, une colonne | \n
| \n | \n | data_dict:label,type='Description' | \ndeux colonnes, un libellé personnalisé | \n
| \n | \n | data_dict:label='Attribut',type='Description' | \ndeux colonnes, deux libellés personnalisés | \n
| \n | \n | data_dict:**box**='Entité ou<br>association',label,`type`=`'Type de données'` | \nmise en forme de certains libellés | \n
| \n | \n | data_dict:tsv | \ntableau TSV, trois colonnes | \n
| \n | \n | data_dict:tsv,label | \nliste des attributs séparés par des retours à la ligne | \n
| dbml | \nconvertit le modèle conceptuel en un schéma relationnel au format DBML | \ndbml | \nversion de base | \n
| \n | \n | dbml:b | \navec boilerplate | \n
| debug | \nliste des informations internes relatives à la conversion en schéma relationnel | \n\n | \n |
| dependencies | \nconvertit le modèle conceptuel en un graphe de dépendances | \n\n | \n |
| diagram | \nconvertit le modèle conceptuel en un diagramme relationnel au format Mocodo | \ndiagram | \nversion de base | \n
| \n | \n | diagram:c | \navec contraintes d'unicité et d'optionalité | \n
| html | \nconvertit le modèle conceptuel en un schéma relationnel au format HTML | \nhtml | \nversion de base | \n
| \n | \n | html:b | \navec boilerplate | \n
| \n | \n | html:c | \navec contraintes d'unicité et d'optionalité | \n
| \n | \n | html:e | \navec explications | \n
| \n | \n | html:bce | \navec boilerplate, contraintes et explications | \n
| latex | \nconvertit le modèle conceptuel en un schéma relationnel au format LaTeX | \nlatex | \nversion de base | \n
| \n | \n | latex:b | \navec boilerplate | \n
| \n | \n | latex:c | \navec contraintes d'unicité et d'optionalité | \n
| \n | \n | latex:e | \navec explications | \n
| \n | \n | latex:bce | \navec boilerplate, contraintes et explications | \n
| markdown | \nconvertit le modèle conceptuel en un schéma relationnel au format Markdown | \nmarkdown | \nversion de base | \n
| \n | \n | markdown:c | \navec contraintes d'unicité et d'optionalité | \n
| \n | \n | markdown:e | \navec explications | \n
| \n | \n | markdown:ce | \navec contraintes et explications | \n
| mssql | \nconvertit le modèle conceptuel en un modèle physique pour Microsoft SQL Server | \nmssql | \nversion de base | \n
| \n | \n | mssql:b | \navec boilerplate | \n
| mysql | \nconvertit le modèle conceptuel en un modèle physique pour MySQL | \nmysql | \nversion de base | \n
| \n | \n | mysql:b | \navec boilerplate | \n
| oracle | \nconvertit le modèle conceptuel en un modèle physique pour Oracle DB | \noracle | \nversion de base | \n
| \n | \n | oracle:b | \navec boilerplate | \n
| postgresql | \nconvertit le modèle conceptuel en un modèle physique pour PostgreSQL | \npostgresql | \nversion de base | \n
| \n | \n | postgresql:b | \navec boilerplate | \n
| prompt | \ngénère un prompt pour demander à une IA de compléter le MCD | \nprompt:cards | \navec les explications des cardinalités | \n
| \n | \n | prompt:types | \navec les types des attributs | \n
| relation | \nconvertit le modèle conceptuel en schéma relationnel avec le gabarit donné | \nrelation:path/to/my_template.yaml | \nchemin relatif, extension obligatoire | \n
| share | \nencode le MCD dans une URL pour Mocodo online | \nqr --defer | \ngénère un QR code via un service web | \n
| sql | \nconvertit le modèle conceptuel en un modèle physique pour SQL | \n\n | \n |
| sqlite | \nconvertit le modèle conceptuel en un modèle physique pour SQLite | \nsqlite | \nversion de base | \n
| \n | \n | sqlite:b | \navec boilerplate | \n
| text | \nconvertit le modèle conceptuel en un schéma relationnel au format texte | \ntext | \nversion de base | \n
| \n | \n | text:c | \navec contraintes d'unicité et d'optionalité | \n
| \n | \n | html:e | \navec explications | \n
| \n | \n | html:ce | \navec contraintes et explications | \n
| uml | \nconvertit le modèle conceptuel en diagramme de classes UML | \numl | \nformat PlantUML | \n
| \n | \n | uml:plantuml | \nidem | \n
| \n | \n | uml --defer | \ncalcule le rendu graphique via un service web | \n
| \n | \n | uml:plantuml=- | \nsupprime les styles par défaut | \n
| \n | \n | uml:plantuml='skinparam backgroundColor yellow\\nskinparam classAttributeFontName Arial\\n' | \najoute des styles personnalisés | \n
Opérations de réécriture¶
| Sous-option | \nDescription | \nExemples | \nExplications | \n
|---|---|---|---|
| arrange | \nréarrange la disposition, soit par Branch & Bound, soit avec un algorithme génétique | \narrange | \nB&B sans contraintes | \n
| \n | \n | arrange:timeout=60 | \nB&B limité à une minute | \n
| \n | \n | arrange:wide | \nB&B privilégiant la largeur | \n
| \n | \n | arrange:current | \nB&B sur la grille courante | \n
| \n | \n | arrange:balanced=0 | \nB&B sur la plus petite grille équilibrée | \n
| \n | \n | arrange:balanced=1 | \nB&B sur la seconde plus petite grille équilibrée | \n
| \n | \n | arrange:algo=ga | \nalgorithme génétique | \n
| ascii | \nréécrit les éléments donnés en ASCII | \nascii:roles,labels | \nrôles, libellés des boîtes et des attributs en ASCII | \n
| camel | \nréécrit les éléments donnés en camelCase | \n\n | \n |
| capitalize | \nréécrit les éléments donnés en capitalisant la première lettre de chaque mot | \n\n | \n |
| casefold | \nréécrit les éléments donnés en minuscules, mais plus agressivement que « lower » | \n\n | \n |
| create | \nessaie d'inférer les types, entités, CIFs ou flèches de DF à partir des éléments existants | \nguess:types | \ndeviner les types manquants | \n
| \n | \n | create:types= | \nremplacer les types manquants par [] | \n
| \n | \n | create:types=TODO | \nremplacer les types manquants par [TODO] | \n
| \n | \n | make:entities | \nréparer l'oubli d'entités référencées dans des associations | \n
| \n | \n | create:dfs | \nmettre des DF partout où c'est possible | \n
| \n | \n | add:df_arrows | \najouter des flèches aux DF 11 | \n
| \n | \n | add:cifs | \najouter les CIF correspondant aux agrégats | \n
| \n | \n | add:cifs=light | \nmême chose en visualisation allégée | \n
| \n | \n | add:roles | \nmettre comme rôles le nom des associations partout où c'est utile | \n
| delete | \nsupprime les éléments donnés quand c'est possible | \nempty | \nne garde que la structure et le nom des boîtes | \n
| \n | \n | delete:types,notes,attrs,cards | \nidem | \n
| \n | \n | delete:cards | \nremplace les cardinalités par XX | \n
| \n | \n | delete:card_prefixes | \nsupprime les marqueurs d'entités faibles et d'agrégats | \n
| \n | \n | delete:dfs | \nsupprime les entités indépendantes dont tous les attributs sont identifiants (et les DF qui les relient) | \n
| drain | \ndéplace tout attribut d'association (1,1) vers l'entité appropriée | \n\n | \n |
| drown | \nremplace tous les noms d'éléments par un libellé générique numéroté | \n\n | \n |
| echo | \nréécrit le texte source tel quel | \n\n | \n |
| explode | \ndécompose toute association n-aire (*,N) en n associations binaires | \nexplode arrange | \ndécomposer les non-DF ternaires et plus, puis réarranger | \n
| \n | \n | explode:arity=3 arrange | \nidem | \n
| \n | \n | explode:weak arrange | \nidem, avec création d'entités faibles | \n
| \n | \n | explode:arity=2.5 arrange | \nétendre aux non-DF binaires porteuses d'attributs | \n
| \n | \n | explode:arity=2 arrange | \nétendre à toutes les non-DF binaires | \n
| fix | \nessaie de corriger les erreurs courantes dans les éléments donnés | \nfix:cards | \nnormaliser les cardinalités en 01, 11, 0N et 1N | \n
| flip | \napplique au diagramme une symétrie verticale, horizontale ou diagonale | \nflip:v | \nsymétrie verticale | \n
| \n | \n | flip:h | \nsymétrie horizontale | \n
| \n | \n | flip:d | \nsymétrie selon la seconde diagonale | \n
| \n | \n | flip:vhd | \nsymétrie selon la première diagonale | \n
| \n | \n | flip:dhv | \nidem (ordre indifférent) | \n
| grow | \najoute des entités et associations aléatoires (par défaut : 10 nouvelles associations) | \ngrow arrange | \najouter des éléments avec les paramètres par défaut, puis réarranger | \n
| \n | \n | grow:n=10 | \nnombre total d'associations à ajouter (défaut) | \n
| \n | \n | grow:arity_1=2 | \nnombre d'associations réflexives (défaut) | \n
| \n | \n | grow:arity_3=2 | \nnombre d'associations ternaires (défaut) | \n
| \n | \n | grow:arity_4=0 | \nnombre d'associations quaternaires (défaut) | \n
| \n | \n | grow:doubles=1 | \nnombre d'associations liant deux mêmes entités (défaut) | \n
| \n | \n | grow:composite_ids=1 | \nnombre d'identifiants composites (défaut) | \n
| \n | \n | grow:ent_attrs=4 | \nnombre maximal d'attributs par entité (défaut) | \n
| \n | \n | grow:assoc_attrs=2 | \nnombre maximal d'attributs par association (défaut) | \n
| \n | \n | grow:'*1-*N'=3 | \nnombre d'associations *1-*N (défaut) | \n
| \n | \n | grow:'01-11'=1 | \nnombre d'associations 01-11 (défaut) | \n
| \n | \n | grow:'_11-*N'=1 | \nune entité faible (zéro par défaut) | \n
| \n | \n | grow:'/1N-*N'=1 | \nun agrégat (zéro par défaut) | \n
| \n | \n | grow:from_scratch arrange | \nà partir d'un MCD vide | \n
| \n | \n | grow:grow:n=9,from_scratch,ent_attrs=3 obfuscate:labels=en4 create:roles lower:roles arrange | \ncréer un MCD d'entraînement à la conversion en relationnel | \n
| lower | \nréécrit les éléments donnés en minuscules | \nlower:attrs,roles | \nattributs et rôles en minuscules | \n
| pascal | \nréécrit les élements donnés en PascalCase | \n\n | \n |
| prefix | \npréfixe les éléments donnés avec la chaîne donnée | \nprefix:roles='-' | \nforce les rôles à remplacer le nom des clés étrangères lors du passage au relationnel | \n
| randomize | \ngarde la structure, mais randomise les éléments donnés quand c'est possible | \nobfuscate | \nlibellés remplacés par du Lorem Ipsum | \n
| \n | \n | obfuscate:labels=lorem | \nidem | \n
| \n | \n | obfuscate:labels=disparition | \nidem, lexique du roman de Perec | \n
| \n | \n | obfuscate:labels=en4 | \nidem, mots anglais de 4 lettres (SFW) | \n
| \n | \n | obfuscate:attrs=fr,boxes=fr5 | \nidem, mots français de longueur quelconque pour les attributs, de 5 lettres pour les boîtes | \n
| \n | \n | randomize:types | \ntypes randomisés avec les fréquences de default_datatypes_fr.tsv. | \n
| replace | \nréécrit les éléments donnés en appliquant le motif « recherche/remplacement » donné | \nreplace:boxes='DIRIGER/RÉPONDRE DE' | \nrenomme une boîte | \n
| \n | \n | replace:texts='personel/personnel' | \ncorrige une faute d'orthographe | \n
| \n | \n | replace:replace:texts='_/ ' | \nremplace les tirets bas par des espaces | \n
| \n | \n | replace:types='VARCHAR/VARCHAR2' | \nmodifie un nom de type | \n
| \n | \n | replace:cards=0N/1N | \nremplace toutes les cardinalités 0N par 1N | \n
| \n | \n | replace:cards=1N//1N | \ncrée des agrégats un peu partout | \n
| \n | \n | replace:cards='0/X' replace:cards='11/X1' replace:cards='1N/XN' | \nmasque les cardinalités minimales | \n
| \n | \n | delete:card_prefixes replace:cards=11/_11 | \najoute des marqueurs d'entités faibles | \n
| slice | \nréécrit les éléments donnés en n'en gardant qu'une tranche donnée | \nslice:boxes=5:10 | \nde l'indice 5 (inclus) à l'indice 10 (exclu) | \n
| \n | \n | slice:boxes=5: | \nsupprime les 5 premiers caractères | \n
| \n | \n | slice:boxes=:5 | \nne garde que les 5 premiers caractères | \n
| \n | \n | slice:boxes=:-5 | \nsupprime les 5 derniers caractères | \n
| \n | \n | slice:boxes=: | \néquivalent de echo | \n
| \n | \n | slice:boxes= | \nidem | \n
| \n | \n | slice:boxes | \nidem | \n
| snake | \nréécrit les éléments donnés en snake_case | \n\n | \n |
| split | \ndécompose toute association n-aire (*,1) en n-1 associations binaires | \nsplit arrange | \ndécomposer, puis réarranger | \n
| suffix | \nsuffixe les éléments donnés avec la chaîne donnée | \nsuffix:boxes=1 | \nAjoute un suffixe numérique au nom des boîtes en vue de mettre un MCD et sa copie sur le même diagramme. | \n
| swapcase | \nréécrit les éléments donnés en inversant la casse de chaque lettre | \n\n | \n |
| title | \nréécrit les éléments donnés en mettant la première lettre de chaque mot en majuscule | \n\n | \n |
| truncate | \ntronque les éléments donnés à la longueur donnée (par défaut : 64) | \ntruncate:boxes=10 | \ntronque les noms des boîtes à 10 caractères | \n
| upper | \nréécrit les éléments donnés en majuscules | \nupper:boxes | \nnoms des boîtes en majuscules | \n
Réécriture d'éléments donnés¶
\nDans l'aide-mémoire, de nombreuses opérations de réécriture sont décrites comme s'appliquant à des « éléments donnés ». Il s'agit de certains ensembles de tokens produits par l'analyse syntaxique. Plus précisément :
\n- \n
arrows: flèches de pattes (suffixes<ou>des cardinalités). \nattrs: libellés des attributs d'entités ou d'associations. \nboxes: libellés des entités et associations. \ncards: cardinalités (11,1N, etc., sans préfixe ni suffixe). \ncard_prefixes: préfixes de cardinalités (_pour les entités faibles,/pour les agrégats). \nconstraint_notes: messages affichés au survol d'une contrainte. \nlabels: libellés des entités, des associations et des attributs. \nleg_notes: notes de pattes (rôles ou messages affichés au survol). \nnotes: équivalent deroles+constraint_notes. \nroles: alias deleg_notes. \ntexts: équivalent delabels+notes. \ntypes: types de données. \n
Fonctionnement de la commande magique¶
\nIl peut être utile de comprendre ce qui se passe en coulisses lorsque l'on invoque la commande magique sur une cellule d'un notebook Jupyter :
\n- \n
- dans le répertoire courant est créé au besoin un sous-répertoire
mocodo_notebook; \n - le texte d'entrée y est sauvegardé sous le nom de
sandbox.mcd; \n - la commande est lancée sur ce fichier avec tous les paramètres donnés par l'utilisateur. Cela signifie que tous les fichiers générés le seront au même endroit sous les noms de
sandbox.svg,sandbox.html, etc. (relisez-les avec la commande magique%load) ; \n - certains des fichiers générés sont affichés dans la sortie de la cellule, d'autres pas, selon les règles suivantes (
rwetcvdénotent respectivement une opération de réécriture et de conversion) : \n
| commande | \ntracé du MCD | \nrésultat des réécritures | \nrésultats des conversions | \n
|---|---|---|---|
mocodo | \ninitial | \n- | \n- | \n
mocodo -t ou mocodo --mld | \ninitial | \n- | \nMLD en Markdown | \n
mocodo -t rw1 rw2 ... | \nfinal | \nfinal | \n- | \n
mocodo -t cv1 cv2 ... | \n- | \n- | \ntous | \n
mocodo -t rw1 rw2 ... cv1 cv2 ... | \nfinal | \n- | \ntous | \n
Ces règles d'affichage par défaut devraient répondre aux besoins les plus courants, mais l'option --select peut prendre le pas :
- \n
- sans arguments, rien n'est affiché ; \n
- l'argument
mcdaffiche le diagramme conceptuel ; \n - l'argument
rw(ou un alias de commodité parmisource,text,code,mocodo) affiche le résultat de la dernière réécriture ; \n - l'argument
cv(ou un alias de commodité parmimld,ddl,sql) affiche les résultats des conversions ; \n - ces arguments peuvent être librement combinés et ordonnés ; \n
- l'argument
allaffiche tout ce qui est disponible, dans l'ordremcd,rwetcv; \n
Les conversions génèrent par défaut un fichier-texte. Un dessin s'affichera à la place :
\n- \n
- pour l'argument
diagram; \n - avec l'option
--defer, pour autant qu'un web-service de rendu soit défini pour le fichier en question. \n
Il est possible de mettre -t en majuscule. Dans ce cas :
- \n
- s'il y a une ou plusieurs opérations de réécriture, le résultat de la dernière réécriture remplace le contenu de la cellule et la sortie est effacée ; \n
- sinon, s'il y a une ou plusieurs opérations de conversion et que Pyperclip est installé, le résultat de la dernière conversion est copié dans le presse-papier. \n
Gabarits de passage au relationnel¶
\nL'algorithme convertissant la représentation interne d'un schéma relationnel en une représentation externe dans tel ou tel format est totalement découplé dudit format. Cela signifie que vous pouvez modifier ou créer un format sans écrire une seule ligne de code, mais en remplissant une espèce de formulaire, ou gabarit (template en anglais).
\nSi vous n'avez aucune velléité de le faire ou que vous n'êtes pas ami avec les expressions régulières, vous pouvez sauter cette section. Sinon, accrochez-vous, ça va devenir un peu technique.
\nFormat des gabarits¶
\nLes gabarits de Mocodo étaient à l'origine écrits en JSON. Par conséquent, un grand nombre des caractères utilisés dans les expressions régulières devaient être échappés, ce qui rendait celles-ci (encore) plus difficiles à écrire, à relire et à tester. La version 4 passe à YAML, qui n'a pas cet inconvénient. Voici par exemple un extrait de gabarit dans l'ancienne syntaxe :
\n {\n \"order\": 400,\n \"comment\": \"Move all foreign keys constraints at the end of the document\",\n \"search\": \"(?sm)(CREATE TABLE ([^\\n]+) \\\\(\\n(?:[^\\n]+\\n)*) (FOREIGN KEY[^\\n]+),\\n(.*)\",\n \"replace\": \"\\\\1\\\\4\\nALTER TABLE \\\\2 ADD \\\\3;\",\n \"iterated\": true\n },\n... et le même dans la nouvelle :
\n - order: 400\n comment: 'Move all foreign keys constraints at the end of the document'\n search: '(?sm)(CREATE TABLE ([^\\n]+) \\(\\n(?:[^\\n]+\\n)*) (FOREIGN KEY[^\\n]+),\\n(.*)'\n replace: '\\1\\4\\nALTER TABLE \\2 ADD \\3;'\n iterated: true\nSi vous avez écrit vos propres gabarits JSON, vous pouvez les convertir automatiquement en YAML à l'aide du script json_to_yaml_templates.py fourni dans le répertoire dev.
Remarque. Si les gabarits de Mocodo constituent des fichiers YAML valides, l'inverse n'est pas forcément vrai. Mocodo utilise un sous-ensemble sain de YAML adapté à ses besoins. Il a son propre parser avec les particularités suivantes :
\n- \n
- Un gabarit est un dictionnaire dont les valeurs sont :
- \n
- soit des types scalaires (chaînes, nombres, booléens,
null) ; \n - soit des listes de dictionnaires à valeurs scalaires. \n
\n - soit des types scalaires (chaînes, nombres, booléens,
- Toute valeur chaîne doit être délimitée par des simples quotes (
'). Les quotes internes sont échappées en les doublant (''). \n - Les expressions régulières de recherche et de remplacement suivent les mêmes règles d'échappement que les r-strings de Python. \n
- Les autres chaînes (notamment les chaînes de composition) ne demandent pas à échapper les anti-slashes, mais à doubler les accolades (règles des fr-strings). Exception : pour les distinguer du retour-chariot et de la tabulation, il faudra échapper les
\\net les\\tsi on veut les laisser littéralement. Vous en avez un exemple pour\\newcommandet\\titledans le boilerplate du gabarit pour $\\LaTeX$. \n
Dérivation de gabarits¶
\nDepuis la version 3.1, il est possible de définir un gabarit dérivé d'un autre (qui lui-même peut dériver d'un autre, etc.). Dans le but de réduire les redondances et de faciliter les tests et la maintenance, la version 4.0 fait un usage intensif de cette fonctionnalité :
\ndisplay.SVG(\"../../mocodo/resources/relation_templates/_graph.svg\")\nLes teintes les plus foncées correspondent approximativement aux gabarits les plus complexes. Les autres ne sont souvent que des alias, par exemple, tex.yaml renvoie directement à latex.yaml :
display.Code(\"../../mocodo/resources/relation_templates/tex.yaml\")\nparent: 'latex'\nLa clé \"parent\" donne le chemin ou le nom du gabarit dont on souhaite créer une version dérivée :
- \n
- une chaîne terminée par
.yamlest interprétée comme un chemin ; \n - sinon, comme le nom d'un gabarit de la distribution. \n
Tous les gabarits textuels (text.yaml, latex.yaml, markdown.yaml, html.yaml et leurs alias) dérivent des gabarits html-c.yaml (version avec affichage des contraintes) et html-ce.yaml (version avec affichage des contraintes et des explications).
Par exemple, le gabarit latex se borne à ajouter un message d'aide pour la ligne de commande et à empêcher l'ajout des contraintes d'unicité et d'optionalité :
display.Code(\"../../mocodo/resources/relation_templates/latex.yaml\")\nhelp_en: 'convert the conceptual model into a relational schema in LaTeX format'\nhelp_fr: 'convertit le modèle conceptuel en un schéma relationnel au format LaTeX'\nhelp_zh: '将概念模型转换为 LaTeX 格式的关系模式'\nfr_examples:\n - order: 1\n example: 'latex'\n explanation: 'version de base'\n - order: 2\n example: 'latex:b'\n explanation: 'avec _boilerplate_'\n - order: 3\n example: 'latex:c'\n explanation: 'avec contraintes d''unicité et d''optionalité'\n - order: 4\n example: 'latex:e'\n explanation: 'avec explications'\n - order: 5\n example: 'latex:bce'\n explanation: 'avec _boilerplate_, contraintes et explications'\nparent: 'latex-c'\nadd_unicity_constraints:\nadd_optionality_constraints:\nSi maintenant on regarde le contenu de son parent latex-c :
display.Code(\"../../mocodo/resources/relation_templates/latex-c.yaml\")\nparent: 'html-c'\nextension: 'tex'\nhighlight: 'latex'\ncolumn_separator: ', '\ncompose_relation: ' \\item \\relat{{{this_relation_name}}} ({columns})'\ncompose_relational_schema: '% Generated by Mocodo {version}\\n\\n\\begin{{itemize}}\\n{relations}\\n\\end{{itemize}}\\n'\ntransform_relation:\n - order: 1000\n comment: 'Compose normal attributes'\n search: '<span class=''normal''>(.+?)</span>'\n replace: '\\\\attr{\\1}'\n - order: 1100\n comment: 'Compose primary keys'\n search: '<span class=''primary''>(.+?)</span>'\n replace: '\\\\prim{\\1}'\n - order: 1200\n comment: 'Compose foreign primary keys'\n search: '<span class=''foreign primary''>#(.+?)</span>'\n replace: '\\\\foreign{\\\\prim{\\1}}'\n - order: 1300\n comment: 'Compose foreign attributes'\n search: '<span class=''foreign''>#(.+?)</span>'\n replace: '\\\\foreign{\\1}'\n - order: 1400\n comment: 'Exponents'\n search: '(<sup>.*u)(\\d)(.*</sup>)'\n replace: '\\1_\\2\\3'\n iterated: true\n - order: 1500\n comment: 'Exponents'\n search: ' <sup>(.+?)</sup>'\n replace: '$^{\\1}$'\n - order: 1600\n comment: 'Escape underlines'\n search: '_'\n replace: '\\_'\n... on voit que les opérations consistent simplement à modifier le séparateur de colonne, à composer les tables et le schéma relationnel complet avec un boilerplate, et enfin à remplacer les balises HTML par leur équivalent en $\\LaTeX$. Toute la logique complexe est traitée dans le gabarit html-c.
Exemples de création de gabarit dérivé ¶
\nLe gabarit SQL par défaut rend explicite la contrainte NOT NULL des clés primaires :
%%mocodo -t sql\nPERSONNE: id. personne [VARCHAR(8)], nom [VARCHAR(255)]\n\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE PERSONNE (\n PRIMARY KEY (id_personne),\n id_personne VARCHAR(8) NOT NULL,\n nom VARCHAR(255)\n);\nSupposons que cette redondance nous défrise, et voyons comment l'éliminer. Pour cela, examinons le contenu du gabarit sql.yaml :
![\"\"](\"examples/sql_template_1.png\"/)
La contrainte d'optionalité {optionality} apparaît à côté de PRIMARY KEY en lignes 28 et 31. Nous pouvons donc simplement remplacer les valeurs associées à compose_primary_key et compose_primary_foreign_key par des copies supprimant cette mention :
%%file new_sql.yaml\nparent: 'sql'\ncompose_primary_key: '{label} {datatype}\\nPRIMARY KEY ({label})'\ncompose_primary_foreign_key: '{label} {datatype}\\nPRIMARY KEY ({label})\\nFOREIGN KEY ({label}) REFERENCES {outer_source} ({non_disambiguated_label})'\nOverwriting new_sql.yaml\n\n
Pour tester ce nouveau gabarit, nous devons ajouter la sous-option -t relation avec en sous-argument le chemin complet du fichier créé :
%mocodo -i sandbox -t relation:new_sql.yaml\n\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE PERSONNE (\n PRIMARY KEY (id_personne),\n id_personne VARCHAR(8),\n nom VARCHAR(255)\n);\nMission accomplie !
\nNous aurions pu procéder autrement. Reprenons le gabarit original :
\n![\"\"](\"examples/sql_template_2.png\"/)
Le dictionnaire transform_relation spécifie une séquence de réécritures à appliquer à chacune des clauses CREATE TABLE (composées ligne 37). La première accumule toutes les lignes contenant PRIMARY KEY en fin de table (où elles seront concaténées avant d'être ramenées au début). Nous devons donc intervenir avant que NOT NULL ne soit séparé de PRIMARY KEY. Pour cela, définissons un gabarit qui se borne à insérer avant cette transformation (de numéro d'ordre 100) une suppression des NOT NULL incriminés :
%%file new_sql.yaml\nparent: 'sql'\ntransform_relation:\n - order: 50\n comment: 'Suppress PK NN redundancy.'\n search: ' NOT NULL\\nPRIMARY KEY'\n replace: '\\nPRIMARY KEY'\nOverwriting new_sql.yaml\n\n
Le résultat est le même :
\n%mocodo -i sandbox -t relation:new_sql.yaml\n\n\n\nsandbox_ddl.sql\n\n\n
CREATE TABLE PERSONNE (\n PRIMARY KEY (id_personne),\n id_personne VARCHAR(8),\n nom VARCHAR(255)\n);\nNB. Les gabarits définis par l'utilisateur n'ont pas vocation à être placés dans le répertoire relation_templates de la distribution. Votre nouveau gabarit new_sql ne peut donc pas être invoqué aussi simplement que les gabarits officiels (i.e., avec -t new_sql). Si vous faites une modification ou un ajout que vous voulez voir inclus dans la distribution, n'hésitez pas à faire une PR.
Mécanisme de mise à jour¶
\nLe mécanisme de mise à jour des clés dépend de la scalarité de leur valeur associée.
\nCas scalaire.
\nPour les valeurs scalaires (chaînes, nombres, booléens, null), selon la présence d'une entrée donnée dans le gabarit enfant et/ou le gabarit parent, l'association clé-valeur correspondante sera créée, mise à jour ou conservée :
| enfant | \nparent | \nrésultat | \n
|---|---|---|
| oui | \nnon | \ncréation | \n
| oui | \noui | \nmise à jour | \n
| non | \noui | \nconservation | \n
Il n'y a pas de moyen de supprimer une association clé-valeur, mais étant donné que toutes celles qui sont absentes se voient substituer une association par défaut, il est équivalent de spécifier explicitement la valeur-défaut.
\nCas non scalaire.
\nDans les gabarits de relations de Mocodo, une seule catégorie de valeur non scalaire est possible : la liste de dictionnaires. Dans l'exemple précédent, c'est le cas de transform_relation.
Une clé \"order\" est systématiquement présente dans chacun des dictionnaires de la liste. Selon la présence d'un dictionnaire de numéro d'ordre donné dans le gabarit enfant et/ou le gabarit parent, ce dictionnaire sera inséré, supprimé, mis à jour ou conservé :
| enfant | \nparent | \nrésultat | \n
|---|---|---|
| oui | \nnon | \ninsertion | \n
| oui | \noui | \nsi les clés sont parmi {\"order\", \"comment\"} : suppressions'il y a plusieurs clés : mise à jour | \n
| non | \noui | \nconservation | \n
Nouveauté de la version 4.0. Si une clé d'un gabarit enfant est associée à une liste vide, cette association remplace l'éventuelle association existante.
\nRemarque. Les numéros d'ordre utilisés dans les dictionnaires sont des multiples de 100. Si vous voulez créer des gabarits dérivés, évitez par précaution les multiples de 10 : cela augmentera les chances que votre gabarit survive à une mise à jour de l'un de ses ancêtres. Vous pouvez aussi partir d'une copie de ceux-ci, sachant que vous renoncez alors aux bénéfices de leurs éventuelles mises à jour.
\nAnnexe C : Crédits¶
\n- \n
- Auteur
- \n
- Aristide Grange, Université de Lorraine, Metz, LCOMS. \n
\n - Administration système
- \n
- Cyril Minette. \n
\n - Outils
- \n
- Aspect visuel
- \n
- Color Brewer (Cynthia Brewer). \n
- Real Favicon Generator (Philippe Bernard). \n
- reset.css (Eric Meyer). \n
\n - JavaScript
- \n
- JQuery (John Resig). \n
- JS-Cookie (Klaus Hartl). \n
- Ace Editor (Cloud9 IDE et Mozilla). \n
\n - Python
- \n
- Distance de Damerau-Levenshtein (Michael Homer). \n
- Lark Parser (Erez Shinan). \n
- CairoSVG (CourtBouillon). \n
- Pyperclip (Al Sweigart). \n
\n - Services de rendu
- \n
- Kroki.io (Guillaume Grossetie). \n
- QR Code Generator (Foundata GmbH). \n
\n
\n - Aspect visuel
- Divers
- \n
- Modern SQL (Markus Winand). \n
- DBML (Holistics). \n
- D2 (Terrastruct). \n
- Basthon (Romain Casati). \n
\n