Modéliser les données avec MySQL Workbench

Image non disponible


précédentsommairesuivant

6. Associations de un à un (généralisation/spécialisation)

6.1. Rappels



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 :

Image non disponible
Figure 6.1 - Généralisation/spécialisation, diagramme de classes



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.

6.2. Icône « 1:1 Identifying Relationship »


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) :

Image non disponible
Figure 6.2 - Lien identifiant 1:1 à établir



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

Image non disponible
Figure 6.3 - Lien identifiant (bijection)



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) :

Image non disponible
Figure 6.4 - Lien identifiant (injection)



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 ...) :

Image non disponible
Figure 6.5 - Lien identifiant (ON DELETE CASCADE)

6.3. Diagramme final



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 :

Image non disponible
Figure 6.6 - Généralisation/spécialisation, au final



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

Image non disponible
Figure 6.7 - Nom de rôle pour mettre en évidence une spécialisation




précédentsommairesuivant

  

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.