Modéliser les données avec MySQL Workbench

Partons de la généralisation/spécialisation des types d'entités merisiennes ou des classes umliennes. Le but est de traduire en diagramme MWB le diagramme de classes ci-dessous, relatif au référentiel PERSONNES de l'entreprise Dubicobit, selon lequel :

      —   Une personne peut avoir plusieurs adresses ;

      —   - Une personne peut être un collaborateur Dubicobit ou un tiers ;

      —   Un collaborateur peut être un directeur ou un employé ;

      —   Un tiers peut être un client ou un fournisseur de Dubicobit.


Diagramme de classes UML :

Rappelons au passage que le losange accolé à PERSONNE symbolise une relation de composition, c'est-à-dire qu'une adresse est la propriété d'une personne, ADRESSE est un type d'entité faible au sens Entité/Relation (cf. paragraphe 1.3) : l'association est identifiante, du type un à plusieurs (cf. paragraphe 5.2). En revanche une relation de spécialisation est à traduire par une association identifiante de type 1:1 (1,1 : 0,1). Dans cette affaire sont donc parties prenantes les relations de spécialisation qu'entretiennent PERSONNE et COLLABORATEUR, PERSONNE et TIERS, COLLABORATEUR et EMPLOYE, COLLABORATEUR et DIRECTEUR, TIERS et CLIENT, TIERS et FOURNISSEUR.

Mettons en œuvre une table PERSONNE (de clé primaire {PersonneId}) et une table COLLABORATEUR (ici d'en-tête vide) et « tirons » un lien identifiant 1:1 entre les deux tables (Identifying Relationship) :

Une fois les deux tables connectées, la situation est la suivante :

L'outil a ajouté une colonne PersonneId à l'en-tête de la table COLLABORATEUR et établi une bijection entre celle-ci et la table PERSONNE. Le singleton {PersonneId} est à la fois clé primaire de COLLABORATEUR et clé étrangère vis-à-vis de PERSONNE.

Pour remplacer la cardinalité minimale (multiplicité) 1 par 0, il faut cliquer sur le lien, puis sur l'onglet « Foreign Key » et décocher la case « Mandatory » côté COLLABORATEUR (Referencing Table) :

Au sujet du métabolisme (cf. paragraphe 10.4.6) : ci-dessous, on retient l'option ON DELETE CASCADE pour la clé étrangère, car un collaborateur étant une personne, sémantiquement parlant on supprime un collaborateur plutôt qu'une personne au sens large, même si (à moins d'en passer par une vue qui soit la jointure naturelle de PERSONNE et COLLABORATEUR) les opérations de suppression portent en fait sur la table PERSONNE (DELETE FROM PERSONNE WHERE ...) :

On procède de la même façon avec les autres tables, sans oublier de compléter l'en-tête des tables, pour obtenir au bout du compte le diagramme :

N.B. Pour afficher le nom des rôles, se reporter au paragraphe 10.11 :