Modéliser les données avec MySQL Workbench

Image non disponible


précédentsommaire

10. Annexes

10.1. Afficher/cacher la grille



Menu : View > Toggle grid :

Un clic sur « Toggle Grid » et la grille est cachée. Même principe pour cacher les guides de page (Toggle Page Guides).

Image non disponible
Figure 10.1 - Grille cachée

10.2. Changer la couleur d'un objet



On peut changer la couleur d'un objet, pour cela on commence par cliquer sur cet objet, ce qui provoque l'ouverture de la fenêtre « Description Editor » :

Image non disponible
Figure 10.2 - Changer la couleur d'un objet



On clique ensuite sur l'onglet « Properties » de la fenêtre « Description Editor » :

Image non disponible
Figure 10.3 - Couleur actuelle



Puis on choisit la couleur qui va bien :

Image non disponible
Figure 10.4 - Palette de couleurs



Au résultat :

Image non disponible
Figure 10.5 - Nouvelle couleur



10.3. Réduire la taille des objets à l'affichage



Si l'on manque de place pour afficher les objets, on peut en réduire la taille avec les possibilités de zoom de Bird's Eye :

Image non disponible
Figure 10.6 - Bird's eye



10.4. Noms et types par défaut

10.4.1. MySQL Workbench et les éléments par défaut



MySQL Workbench utilise des noms par défaut pour les objets suivants : colonnes des tables, type des colonnes, tables associatives (cf. paragraphe 4.3), clés étrangères. Pour modifier ces noms : menu « Edit » puis « Preferences » :

Image non disponible
Figure 10.7 - Noms par défaut, préférences



On ouvre ensuite l'onglet « Model » de la fenêtre  Workbench Preferences  (les valeurs par défaut ci-dessous ne sont pas forcément celles qui étaient en vigueur lors de l'installation du produit) :

Image non disponible
Figure 10.8 - Fenêtre Preferences, onglet « Model »

10.4.2. Nom par défaut de la 1re colonne d'une table



Le nom par défaut de la 1re colonne d'une table est constitué du nom de la table en minuscules, préfixé par « id ». Le type de cette colonne est INT. Par défaut, cette colonne est le seul élément de la clé primaire de la table. Tout ceci ne vaut que si la table n'est pas identifiée relativement une autre table (auquel cas MySQL Workbench recopie le nom de la (des) colonne(s) composant la clé primaire de cette dernière) :

Image non disponible
Figure 10.9 - Nom par défaut de la 1re colonne d'une table



Une infobulle permet de voir que MySQL Workbench propose de mettre le nom par défaut de la table en lettres majuscules, minuscules, capitales.

10.4.3. Nom et type par défaut d'une colonne banale



Pour les colonnes qui ne participent pas à la clé primaire, on voit ci-dessous que le nom par défaut est celui de la table, suffixé par « col ». Afin d'éviter les doublons, l'outil remplace en fait « col » par « col1 », « col2 », etc. Comme autre nom possible par défaut, MySQL Workbench propose le minimum syndical, à savoir seulement le nom de la table, ce qui du reste n'est pas plus mal :

Image non disponible
Figure 10.10 - Nom des autres colonnes

10.4.4. Types par défaut



Outre le nom par défaut des colonnes, on peut en définir le type par défaut, par exemple CHAR(8) au lieu de VARCHAR(45) :

Image non disponible
Figure 10.11 - Nouveaux noms et types par défaut pour les colonnes

10.4.5. Nom par défaut des clés étrangères



Par défaut, le nom d'une étrangère est la concaténation de la constante « fk_ », du nom de la table référençante, de la constante « _ » et du nom de la table référencée, avec des possibilités d'autres noms par défaut (substitutions) :

Image non disponible
Figure 10.12 - Clé étrangère, nom par défaut



Les colonnes d'une clé étrangère ont aussi un nom par défaut : nom de la table référençante concaténé avec le nom de la colonne correspondante de la clé primaire de la table référencée :

Image non disponible
Figure 10.13 - Nom par défaut de colonnes d'une clé étrangère



Si on ne souhaite pas que le nom de la table référençante fasse partie du nom par défaut des colonnes composant la clé étrangère, il suffit de remplacer « %table%_%column% » par « %column% ».

10.4.6. Note à propos des actions de compensation (ON UPDATE, ON DELETE)



La fenêtre « Model » utilisée jusqu'ici pour définir les valeurs par défaut des noms des colonnes et leur type permet aussi de définir les actions de compensation par défaut. Une action de compensation permet de décider du comportement du SGBD au cas où :

On souhaite remplacer par une valeur k2 la valeur k1 (k1 ≠ k2) de la clé (primaire en général) d'une table T1 qui fait l'objet de contraintes référentielles de la part d'autres tables T2, ..., Tn (voire T1 elle-même en cas d'auto-référence), T1 jouant le rôle de table référencée ;

On souhaite supprimer au moins une ligne de T1 : les tables énumérées ci-dessus touchées seront en droit de donner leur accord pour en subir les conséquences, ou bien refuser énergiquement et donc faire échouer l'opération.



On retrouve ici les options possibles, RESTRICT (et/ou NO ACTION selon les SGBD) pour refuser énergiquement les opérations de mise à jour portant sur la table référencée, et CASCADE pour les accepter et les propager dans les tables référençantes. Il va de soi que SET NULL est une incongruité laissant le champ libre au bonhomme Null (Horresco referens !), lequel est hors-la loi au pays des relations.


A cette occasion, faisons un retour rapide sur l'intégrité référentielle et le métabolisme des données.

Prenons l'exemple des commandes passées par les clients. On a vu à l'occasion de la déclaration des tables CLIENT et COMMANDE que dans un 1er temps ces tables n'entretenaient aucune relation (cf. paragraphe 5.2.1) :

Image non disponible
Figure 10.14 - Absence de relation entre tables



Une fois qu'on a connecté les deux tables, MySQL Workbench a recopié la colonne ClientId de l'en-tête de la table Client dans l'en-tête de la table COMMANDE :

Image non disponible
Figure 10.15 - Relation effective entre tables



Un lien a été établi entre les deux tables, ce qui signifie fondamentalement que chaque valeur prise par la colonne ClientId de l'en-tête de la table COMMANDE doit être une valeur prise en premier lieu par la colonne ClientId de l'en-tête de la table CLIENT : comme {ClientId} est clé de la table CLIENT (clé primaire dans l'exemple ou clé candidate dans le cas général), on conclut qu'une commande doit nécessairement faire référence à un client existant, ce qui du reste est la moindre des choses si l'on tient à ce que la base de données soit valide et que les comptables de chez Dubicobit ne viennent pas exiger, à juste titre, que les choses rentrent dans l'ordre...

Par définition la colonne ClientId appartient à une clé étrangère {ClientId} de la table COMMANDE dont les valeurs doivent d'abord être des valeurs de la clé {ClientId} de la table CLIENT. Plus précisément on est en présence d'une contrainte d'intégrité référentielle. Si la colonne ClientId de l'en-tête de la table COMMANDE prenait une valeur qui ne fût pas une valeur prise par la colonne ClientId de l'en-tête de la table CLIENT, alors la contrainte d'intégrité référentielle serait violée : à charge du SGBD de veiller au respect de la contrainte, ce qu'on lui signifie ainsi en SQL :

 
Sélectionnez
CREATE TABLE COMMANDE
... ClientId    INT    NOT NULL ...
    CONSTRAINT COMMANDE_CLIENT_FK FOREIGN KEY (ClientId)
        REFERENCES CLIENT (ClientId) ...


Où COMMANDE_CLIENT_FK est le nom de la contrainte à faire respecter.


Du métabolisme des données

La contrainte COMMANDE_CLIENT_FK ci-dessus est manifestement statique, elle dit seulement qu'une commande doit faire référence à exactement un client, ni plus, ni moins. Comme disait Ted Codd, au-delà de l'aspect statique, anatomique de la base de données, il faut aussi se préoccuper du métabolisme des données pour mieux comprendre la nature de celles-ci, de leurs relations, et à un niveau plus terre à terre, ne pas avoir la sensation d'avoir les pieds pris dans le béton lors des opérations de mise à jour, et cela grâce à des actions de compensation illustrées par les clauses ON UPDATE et ON DELETE :

Image non disponible
Figure 10.16 - Du métabolisme des données



Si, comme dans la figure ci-dessus, c'est l'option RESTRICT qui a été retenue pour la table COMMANDE :

 
Sélectionnez
CREATE TABLE COMMANDE
... ClientId    INT    NOT NULL ...
    CONSTRAINT COMMANDE_CLIENT_FK FOREIGN KEY (ClientId)
        REFERENCES CLIENT (ClientId) ON DELETE RESTRICT ...


Alors, si on exécute une instruction DELETE :

 
Sélectionnez
DELETE FROM CLIENT
    WHERE ClientId = 123 ;


Comme on l'a évoqué dans le paragraphe 1.2, de deux choses l'une, ou bien il y a au moins une commande pour le client pour lequel on vérifie la condition « ClientId = 123 », auquel cas la demande de suppression du client sera rejetée, ou bien il n'y a aucune commande pour ce client, auquel cas la demande de suppression sera satisfaite (à condition, bien sûr, qu'il n'y ait pas d'autres tables référençant la table CLIENT et pouvant provoquer, comme dans le cas de la table COMMANDE, un rejet de la demande de suppression).

En passant : avec certains SGBD (par exemple MS SQL Server) on n'utilise pas RESTRICT mais NO ACTION. Avec d'autres (par exemple DB2 for z/OS ou MySQL), on peut utiliser RESTRICT et NO ACTION.

Rappelons que l'option CASCADE n'a guère de sens que lorsque les tables atteintes par les stimuli engendrés par un DELETE correspondent à des entités-types spécialisées (cf. paragraphe 6.1) ou à des entités-types faibles (cf. paragraphe 1.3), cas en l'occurrence des lignes de commande, lesquelles sont des propriétés multivaluées des commandes : une ligne de commande n'a pas plus de raison que la date de commande de s'opposer à la suppression légitime d'une commande...

Image non disponible
Figure 10.17 - La suppression d'une commande entraîne celle de ses lignes



Partant de là, on retient l'option CASCADE pour la table LIGNE_COMMANDE :

 
Sélectionnez
CREATE TABLE LIGNE_COMMANDE
...
    CONSTRAINT COMMANDE_COMMANDE_FK FOREIGN KEY (ClientId, CommandeId)
        REFERENCES COMMANDE ON DELETE CASCADE ...


En conséquence de quoi, si aucune autre contrainte ne s'y oppose, l'exécution de l'instruction suivante provoque, dans la table LIGNE_COMMANDE, la suppression des lignes de la commande 2 du client 123 :

 
Sélectionnez
DELETE FROM COMMANDE
    WHERE ClientId = 123 AND CommandeId = 2 ;


10.4.7. Nom par défaut des tables associatives


Rappelons (cf. paragraphe 4) qu'une table associative résulte d'une association de plusieurs à plusieurs entre deux tables (ou plusieurs, cf. paragraphe 5.3), par exemple DEPOT et ARTICLE : un type d'article donné peut être stocké dans plusieurs dépôts et dans un dépôt donné peuvent être stockés plusieurs types d'articles.

Situation avant connexion des tables :

Image non disponible
Figure 10.18 - Tables à associer


Du fait du paramétrage ci-dessous, par défaut, la table associative connectant DEPOT (considérée ci-dessous comme source) et ARTICLE (considérée comme cible) sera nommée DEPOT_has_ARTICLE :

Image non disponible
Figure 10.19 - Nom par défaut d'une table associative



Mais si, par exemple, on remplace « %stable%_has_%dtable » par « %stable%_%dtable », le nom par défaut de la table associative sera DEPOT_ARTICLE.

10.5. Changer l'ordre des colonnes d'une table



Pour changer l'ordre des colonnes dans l'en-tête d'une table, il suffit de sélectionner la colonne à changer de place (colonne CodeNAF ci-dessous) et effectuer un glisser-déposer vers la position voulue ; l'outil permet de visualiser le déplacement de la colonne en affichant une barre ad-hoc.

Avant et pendant :

Image non disponible
Figure 10.20 - Changer l'ordre des colonnes d'une table : situation avant



Après :

Image non disponible
Figure 10.21 - Changer l'ordre des colonnes d'une table : après

10.6. Urbanisation des diagrammes

10.6.1. Diagrammes comportant un grand nombre d'objets



Un défi ergonomique est de faire tenir les objets d'un diagramme sur une seule page au format A4 ou A3. A force d'être chargé, un diagramme devient illisible, avec des ficelles qui se croisent dans tous les sens, ça tient de l'art new-yorkais, et le concepteur tente en vain d'y mettre de l'ordre. Comme disait un des champions de Merise, Arnold Rochfeld, quand on voit un diagramme comportant plus de sept objets, on peut préparer l'aspirine...

Qui plus est, si le grand projet de la société Volfoni Frères (concurrente de Dubicobit) donne lieu à un diagramme comportant quelque chose comme mille types d'entités (ou schémas de tables dans le cas de MySQL Workbench), l'administration des données prendra la précaution d'urbaniser tout cet ensemble en grands domaines (référentiels), sous-domaines et sous-sous-domaines cohérents. Ainsi, ce projet aura été décomposé en référentiels : Personnes, Contrats, Cotisations, Catalogue produits, Prospection de masse, Éditique, Habilitations, etc., peut-être une vingtaine, voire plus. Au niveau le plus fin, la représentation graphique doit tenir — de façon claire et lisible — sur l'équivalent d'un ensemble de pages au format (disons) A3, chacune d'elles constituant une vue suffisante pour qu'un développeur puisse s'y retrouver.

Dans le même sens, supposons que l'on effectue la rétro-conception (cf. paragraphe 9) d'un modèle de taille raisonnable et que le résultat (pour le moins glauque !) de l'opération soit le suivant :

Image non disponible
Figure 10.22 - Un magma à urbaniser



De cette bouillie indigeste de 180 schémas de tables, faire quelque chose de lisible tenant sur un seul diagramme est évidemment impossible : il n'y a plus qu'à urbaniser, faire figurer dans un même diagramme les tables dont les liens sémantiques sont évidents, sans pour autant supprimer le diagramme bouillie, valide par hypothèse, mais qui n'aura plus guère l'occasion de sortir de la cave.

Du strict point de vue technique, MySQL Workbench permet d'urbaniser sans difficulté particulière. A titre indicatif, on peut procéder ainsi : en plus du diagramme bouillie, créer un diagramme par sous-ensemble (domaine, sous-domaine, etc.) dont on veut une vue intelligible et cohérente, et sur lequel on pourra travailler confortablement.

10.6.2. A la manoeuvre avec MySQL Workbench

Exemple : Supposons qu'on veuille créer un diagramme « Commandes » dédié aux commandes, à partir du diagramme « Général », lequel contient l'ensemble des tables, dont celles à faire figurer dans le nouveau diagramme (notamment les tables TIERS er CLIENT visibles ci-dessous) :

Image non disponible
Figure 10.23 - Diagramme « Général » source (vue partielle)



Opérations pour construire le diagramme « Commandes » :

—    Créer un diagramme à l'aide de la commande ad-hoc (cf. paragraphe 10.6.3).

—    Lui donner un nom (cf. paragraphe 10.6.4).

—    Le peupler avec les tables voulues (cf. paragraphe 10.6.5).

—    En retirer (en les masquant) les objets (tables, liens) qu'on aura fait figurer inutilement (cf. paragraphe 10.6.6).

10.6.3. Ajouter un diagramme



Pour créer le diagramme « Commandes » (vide), utiliser CTRL-T ou la commande « Model > Add diagram » ou encore cliquer sur l'icône Image non disponible de la barre de menus. Par défaut, le nouveau diagramme porte le nom de « EER Diagram » :

Image non disponible
Figure 10.24 - Nouveau diagramme « EER Diagram »

10.6.4. Renommer un diagramme



Le diagramme à renommer porte actuellement le nom de « EER Diagram » :

Image non disponible
Figure 10.25 - Diagramme à renommer



Passer par l'onglet « Model » et choisir « Diagram properties and Size... » :

Image non disponible
Figure 10.26 - « Diagram properties and Size »



Apparaît la fenêtre « Diagram properties » : on pourra alors renommer « EER Diagram » comme on l'entend.

Image non disponible
Figure 10.27 - Fenêtre » Diagram Properties »



Une autre méthode pour renommer un diagramme : cliquer sur l'onglet « MySQL Model », l'outil affiche alors la fenêtre « Model Overview » et un nom de diagramme : « EER Diagram » :

Image non disponible
Figure 10.28 - Renommer un diagramme, autre méthode (a)



Pour changer le nom du diagramme, on clique délicatement sur le symbole du diagramme, ce qui suffit normalement pour sélectionner le nom et le changer, ou bien on utilise la touche F2 :

Image non disponible
Figure 10.29 - Renommer un diagramme, autre méthode (b)



On peut alors renommer « EER Diagram », par exemple en « Général » :

Image non disponible
Figure 10.30 - Renommer un diagramme, autre méthode (c)



En double-cliquant sur « Général », on ouvre le diagramme correspondant.

10.6.5. Peupler un diagramme à partir du catalogue



Les noms des tables à faire figurer dans le diagramme « Commandes » apparaissent dans le catalogue (Catalog Tree) :

Image non disponible
Figure 10.31 - Diagramme « Commandes » (a)



Le diagramme étant vide de tout objet, pour y faire figurer par exemple les tables COMMANDE et LIGNE_COMMANDE, on procède par glisser-déposer de leur nom à partir du catalogue, un par un ou ensemble :

Image non disponible
Figure 10.32 - Diagramme « Commandes » (b)



Au résultat (en notant bien que MySQL Workbench établit automatiquement les liens entre les tables) :

Image non disponible
Figure 10.33 - Diagramme « Commandes » (c)



Il n'y a plus qu'à compléter le diagramme avec les autres tables parties prenantes dans les commandes :

Image non disponible
Figure 10.34 - Diagramme « Commandes » (d)

10.6.6. Masquer une table ou un lien dans un diagramme



L'objet de l'opération est de ne plus afficher un objet (table ou lien) dans un diagramme, sans pour autant le supprimer (ne serait-ce que parce que d'autres diagrammes s'en servent !) Par exemple pour masquer la table COMMANDE_STATUT :

Sélectionner la table, puis faire un clic droit pour avoir accès à la commande « Delete » (ou passer par la commande « Menu > Edit > Delete ») :

Image non disponible
Figure 10.35 - Masquer une table (a)



Il y a ouverture de la fenêtre « Delete Object ». Choisir » Keep » pour effectivement masquer la table sans la supprimer :

Image non disponible
Figure 10.36 - Masquer une table (b)



Au résultat, la table COMMANDE_STATUT n'est plus affichée (mais elle n'est pour autant supprimée, ouf !) :

Image non disponible
Figure 10.37 - Masquer une table (c)



Pour réafficher la table : effectuer un glisser-déposer de son nom à partir du catalogue des objets (Catalog tree) :

Image non disponible
Figure 10.38 -Réafficher une table qu'on a masquée

10.6.7. Les couches de peinture (layers)



Histoire d'en rajouter une couche pour faire joli... Qu'il s'agisse du diagramme général (cf. paragraphe 10.6.2) ou d'un sous-diagramme ne contenant qu'un sous-ensemble de tables, on peut faire du coloriage et donner une sensation d'urbanisation. Partons d'un sous-diagramme où ne sont affichées que les commandes et leur livraison par les camions :

Image non disponible
Figure 10.39 - Layers, situation initiale



On commence par cliquer sur l'icône ad-hoc :

Image non disponible
Figure 10.40 - Layers, l'icône ad-hoc



On entoure les objets à incorporer au layer (qui a été nommé « New Layer » suite au clic sur l'icône) :

Image non disponible
Figure 10.41 - Création d'un layer



Puis en double-cliquant, on renomme le layer comme ci-dessous (et au besoin on change le coloriage) :

Image non disponible
Figure 10.42 - Layer, renommage et coloriage



Au résultat :

Image non disponible
Figure 10.43 - Un premier layer



Constitution d'un layer supplémentaire :

Image non disponible
Figure 10.44 - Deux layers



N.B. Quand on clique sur l'onglet associé à un layer, on peut le bouger, tout ce qu'il contient suit.

10.7. Définir une clé alternative



Dans un premier temps, on peut savoir si on a défini des clés alternatives pour une table et quelle en est la composition. Exemple (en France) du Siret des tiers (c'est-à-dire des clients et des fournisseurs), défini pour la table TIERS (attribut NoSiret). Supposons que la notation « Workbench simplifiée » soit active :

Image non disponible
Figure 10.45 - Définir une clé alternative (a)



On passe à la notation « Workbench par défaut », ce qui permet de mettre en évidence le cartouche « Indexes » attaché à la table concernée (MySQL Workbench n'est pas avare en matière d'index...) :

Image non disponible
Figure 10.46 - Définir une clé alternative (b)



Après avoir cliqué sur le symbole « Image non disponible », par le truchement d'une infobulle, donc de façon fugace, on peut déjà savoir à la volée si on a défini des clés alternatives et quelle en est la composition :

Image non disponible
Figure 10.47 - Définir une clé alternative (c)



Si la clé alternative {NoSiret} entrevue ci-dessus n'a pas encore été définie, on le fait via l'onglet « Indexes », en ajoutant un index de type « UNIQUE » :

Image non disponible
Figure 10.48 - Définir une clé alternative (d)



Cette façon de procéder vaut surtout pour les clés alternatives multi-colonnes. En passant par l'onglet « Columns », on peut aussi cocher la case qui va bien (« UQ ») pour les clés alternatives singletons (ce qui est quand même plus propre, puisqu'on ne descend pas au niveau physique et qu'on laisse l'outil se dépatouiller avec ses index, conformément à la huitième des douze règles de Codd) :

Image non disponible
Figure 10.49 - Définir une clé alternative (e)

10.8. Changer l'ordre des colonnes d'une clé



Une clé est un ensemble, aussi l'ordre (des noms) des colonnes qui en sont les éléments n'est pas important. Néanmoins, ça le devient au niveau physique, c'est-à-dire quand les index sont en jeu : on peut donc être amené à changer cet ordre pour ne pas pénaliser les requêtes dont la performance dépend (on change l'ordre en agissant sur la colonne « # ») :

Image non disponible
Figure 10.50 - Ordre des colonnes composant les clés

La performance des requêtes n'est pas notre propos, mais notons que l'on peut choisir d'avoir deux index, le 1er selon la séquence {DepotId, ArticleId}, utile par exemple pour les traitements d'inventaires, et le 2e selon la séquence {ArticleId, DepotId}, indispensable pour les traitements de prise des commandes.

10.9. Rendre un lien facultatif



Par défaut, MySQL Workbench force les cardinalités minimales (multiplicités en UML) à 1. C'est parfait dans le cas du lien entre COMMANDE et LIGNE_COMMANDE car une commande comporte au moins une ligne, mais dans le cas du lien entre ARTICLE et LIGNE_COMMANDE, il faut changer cette cardinalité pour signifier que des articles peuvent ne pas être référencés (provisoirement du moins) par des lignes de commande.

Pour faire passer la cardinalité minimale à 0, double-cliquer sur le lien connectant ARTICLE et LIGNE_COMMANDE :

Image non disponible
Figure 10.51 - Rendre un lien facultatif (a)



Une fois ouverte la fenêtre qui va bien :

Onglet « Foreign Key » : décocher la case « Mandatory » associée à LIGNE_COMMANDE (Referencing Table) :

Image non disponible
Figure 10.52 - Rendre un lien facultatif (b)

10.10. Supprimer un objet (sans s'énerver)



Il arrive que des forumeurs se lamentent de ne pas pouvoir supprimer un objet : colonne, table, lien entre tables, etc. D'une façon générale on peut en passer par un clic droit à la souris sur l'objet à supprimer. Ainsi, pour supprimer une colonne de table, un clic droit sur le nom de la colonne (onglet Columns) donne accès à la commande « Delete Selected Columns » :

Image non disponible
Figure 10.53 - Supprimer une colonne de table



Et bien sûr, en ce qui concerne les tables et les liens qu'elles entretiennent, on peut toujours passer par le menu « Edit ». Ainsi, quand on cherche à établir un lien entre deux tables, alors qu'on est encore un peu novice dans l'utilisation de MySQL Workbench, on crée assez facilement des associations réflexives non voulues et dont on a du mal à se débarrasser :

Image non disponible
Figure 10.54 - Association réflexive intempestive et collante



Si le lien vient d'être créé, la commande « Annuler » (Image non disponible) de la barre d'outils permet de s'en sortir facilement. En tout cas, par un clic gauche sur le lien non voulu pour le sélectionner, puis en passant par le menu « Edit », on accède à la commande « Delete » de suppression :

Image non disponible
Figure 10.55 - Commande Delete du menu Edit



En sélectionnant la commande « Delete », on provoque l'ouverture de la fenêtre « Delete Foreign Keys » : il ne reste plus qu'à « tuer » le lien (bouton « Delete » de la fenêtre), ce qui provoque aussi la suppression de la colonne CommandeStatutId1 automatiquement créée par MySQL Workbench pour servir de clé étrangère :

Image non disponible
Figure 10.56 - Suppression du lien



Mais bien sûr, un clic droit sur le lien permet d'effectuer la même opération :

Image non disponible
Figure 10.57 - Suppression par clic droit

10.11. Afficher le nom des associations entre tables



On peut afficher les noms des associations entre tables. Pour cela, il faut d'abord passer par le menu « Edit » et choisir « Preferences » :

Image non disponible
Figure 10.58 - Menu : Edit, Preferences



Puis ouvrir l'onglet « Diagram » et y décocher la case « Hide Captions » :

Image non disponible
Figure 10.59 - Autoriser l'affichage du nom des liens



Mais alors chaque nom d'association est affiché. Par défaut, il s'agit du nom des clés étrangères :

Image non disponible
Figure 10.60 - Affichage du nom des associations



Sans modifier pour autant le nom des clés étrangères, on peut afficher autre chose que ce nom. Il suffit pour cela de valoriser chaque cartouche « Caption » de l'onglet « Relationship », voire en effacer le contenu pour ne rien afficher. Par exemple, une région couvre un ou plusieurs dépôts :

Image non disponible
Figure 10.61 - Renommer les associations



10.12. MySQL Workbench 5.2 : Accueil

10.12.1. Écran d'accueil



L'écran d'accueil de la version 5.2 de MySQL Workbench est moins sinistre que celui de la version 6.0...

Image non disponible
Figure 10.58 - Bienvenue de la part de MySQL Workbench 5.2

10.12.2. Créer un nouveau modèle



Il s'agit de créer un nouveau modèle. On sélectionne l'option « Create New EER Model » ¹.

En réponse, MySQL Workbench propose la fenêtre suivante, permettant de créer un MLD (modèle logique de données) sous la forme d'un diagramme :

Image non disponible
Figure 10.59 - Ajout d'un diagramme pour un MLD



Cette fenêtre est identique à celle qui est proposée par MySQL Workbench version 6 : à partir de là, on procède de la même façon (cf. paragraphe 2.2.2).

________________________________________________________________

¹ Pour la petite histoire, EER est l'abréviation de « Enhanced Entity-Relationship », c'est-à-dire à peu de choses près que MySQL Workbench se veut une extension du modèle Entité-Relation (E/R). En réalité, l'outil nous permet plutôt de créer des modèles logiques de données (MLD) au sens Merise du terme, car il nous propose par exemple le concept de clé étrangère, qui n'a pas lieu d'être au niveau E/R où il ferait double emploi (violant donc le principe d'essentialité) avec le concept de relation (relationship, association) tel que défini en 1976 par Peter Chen, père du modèle (The Entity-Relationship Model-Toward a Unified View of Data, dans ACM Transactions on Database Systems, Vol. 1, No. 1. March 1976, Pages 9-36.) En revanche, au niveau logique, le concept de clé étrangère est essentiel. Notons encore que, pour faire partie de la famille des modèles EER « enhanced », MySQL Workbench devrait en plus offrir des fonctionnalités telles que la généralisation/spécialisation (cf. paragraphe 6).


précédentsommaire

  

Copyright © 2014 - François de Sainte Marie. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.