Modéliser les données avec MySQL Workbench

Image non disponible


précédentsommairesuivant

5. Associations de un à plusieurs

5.1. Associations de un à plusieurs entre types d'entités indépendantes

5.1.1. Entité-type indépendante (rappel)



MySQL Workbench permet d'exprimer au niveau logique un concept important, celui d'entité forte, indépendante (cf. paragraphe 1.2). Rappelons qu'une entité (instance) est indépendante (forte, autonome) si son existence ne dépend pas de façon permanente et définitive de celle d'une autre entité. Par exemple, chez Dubicobit, un dépôt n'est pas forcément lié sa vie durant à une même région commerciale, il peut changer d'affectation dans le temps, tandis que la suppression d'une région n'entraînera pas celle des dépôts qui la desservent (pour arriver à supprimer une région il aura donc fallu préalablement rattacher ses dépôts à une autre région).

Structure des données en amont, version MCD merisien :

         Une région peut être desservie par plusieurs dépôts et un dépôt dessert exactement une région.

Image non disponible
Figure 5.1 - Association 0,N-1,1 (Merise)



Version diagramme de classes :

Image non disponible
Figure 5.2 - Association 0,N-1,1 (UML)

5.1.2. Icône « 1:n Non-Identifying Relationship »



Au niveau MLD, avant qu'on associe DEPOT et REGION, la situation est la suivante :

Image non disponible
Figure 5.3 - Association 1 à N non identifiante



On sélectionne l'icône « 1:n Non-Identifying Relationship », puis on clique successivement sur les objets DEPOT et REGION (dans cet ordre, c'est-à-dire le référençant d'abord, puis le référencé). Au résultat :

Image non disponible
Figure 5.4 - Association 1 à N non identifiante, suite



La patte entre DEPOT et REGION est en pointillés : c'est la façon qu'a l'outil de signaler que DEPOT n'est pas une propriété (multivaluée) de REGION. DEPOT et REGION sont bien des types d'entités fortes, indépendantes (kernels) au sens de Codd, et DEPOT se contente de désigner REGION.

Comme une région n'est pas nécessairement desservie par un dépôt, la cardinalité 1,N est à remplacer par 0,N (décocher la case « Mandatory » du côté DEPOT (Referencing Table)) :

Image non disponible
Figure 5.5 - Cardinalité minimale 0

5.2. Associations de un à plusieurs (entre entités-types fortes et dépendantes)

5.2.1. Associations binaires

5.2.1.1. A la vie à la mort



Supposons qu'en amont du MLD, au niveau conceptuel, on ait les règles de gestion des données suivantes relatives aux commandes des clients :

         RG330 : Un client a pu passer plusieurs commandes d'articles.

         RG331 : Une commande est passée par exactement un client (c'est-à-dire un et un seul).

         RG332 : Une ligne de commande fait référence à exactement un article.

Quand une commande est passée par un client, disons Fernand, elle lui est attachée de manière exclusive, c'est « à la vie, à la mort », elle n'est pas transférable au client Raoul, et la suppression de Fernand devrait en théorie entraîner celle de ses commandes. Une commande devrait donc être considérée comme une entité faible (cf. paragraphe 1.3) relativement au client auquel elle est attachée, mais, à défaut de procéder par historisation ou tactique de ce genre, on joue l'exception qui confirme la règle, à savoir qu'on ne supprime pas un client qui a des commandes en cours, il ne faudrait surtout pas jouer un vilain tour à l'utilisateur (« Où sont passées mes commandes ? »)

Pour mettre en évidence cette situation de rattachement exclusif de ses commandes à Fernand, on pourra utiliser l'identification relative, tout en notant bien qu'il ne sera pas possible de supprimer un client tant qu'il aura des commandes (sous-entendu : en cours).

La situation initiale :

Image non disponible
Figure 5.6 - Association 1 à N, à rendre au besoin identifiante

5.2.1.2. Identification absolue / relative



Ci-dessus, la table COMMANDE a pour clé primaire {CommandeId} et pour clé alternative {CommandeNo}. Par hypothèse, la colonne CommandeNo représente le numéro de commande, lequel doit être unique, mais c'est aussi une propriété naturelle de la commande et sa structure est du ressort de l'utilisateur. Dans ces conditions, il est nécessaire de disposer d'une clé invariante et non significative, c'est-à-dire dont le contrôle échappe à l'utilisateur, d'où la mise en œuvre pour cela de la colonne CommandeId, correspondant à une propriété artificielle. On peut en rester là si on se cantonne à l'identification « absolue » de COMMANDE, mais on peut aussi identifier COMMANDE relativement à CLIENT : il en résulte un glissement sémantique, mais on résout ainsi une très grande majorité des problèmes liés aux contraintes de chemin comme dans l'exemple des devis et des factures. Au-delà de la modélisation pure, cela peut aussi aider le DBA à résoudre des problèmes de performance observés au cours des travaux de prototypage (récupération par exemple de toutes les commandes de tel client), de stratégie de sauvegarde, toutes choses pour lesquelles le choix de l'index dit cluster sera déterminant (choix crucial, car il est en général très difficile de changer une fois les tables en production).

Nous ne prendrons pas parti ici. Si on préfère en rester à l'identification absolue, on sera amené à procéder comme dans le cas des entités-types indépendantes (cf. paragraphe 5.1.2), pour obtenir :

Image non disponible
Figure 5.7 - Association 1 à N (identification absolue)



N.B. Dans le cas de l'identification absolue, si on utilise par exemple DB2 ou SQL Server, la clé de l'index cluster sera de préférence composée de la colonne ClientId.

Comme on l'a évoqué, on peut donc aussi choisir d'utiliser l'identification relative :

Image non disponible
Figure 5.8 - Association 1 à N, identification relative



N.B. Le DBA pourra préférer cette solution permettant de diminuer d'une unité le nombre d'index ; en effet l'index « primaire » (PRIMARY) a pour clé le couple <ClientId, CommandeId> tandis que l'index COMMANDE_CLIENT_FK a pour clé le singleton <ClientId> : on a de nouveau affaire aux index redondants (cf. paragraphe 4.10) :

Image non disponible
Figure 5.9 - Suppression des index inutiles



Rappelons à cette occasion que les valeurs prises par la colonne CommandeId sont relatives, c'est-à-dire qu'elles sont obtenues par incrémentation, mais avec une numérotation de CommandeId qui commence à 1 pour chaque client. Voir le billet de CinePhil à ce sujet : «  Trigger pour incrémentation relative ». Rappelons aussi que la suppression d'un client doit être refusée si celui-ci a au moins une commande, se reporter au paragraphe 10.4.6 pour ce qui a trait au métabolisme des données (option ON DELETE) :

Image non disponible
Figure 5.10 - Option RESTRICT



En tout cas, que l'on ait identifié COMMANDE de façon absolue ou relative, il n'y a pas à hésiter en ce qui concerne les lignes de commande, car elles correspondent véritablement à une propriété (multivaluée) de la commande (on peut aussi voir une ligne de commande comme une association entre une commande et un produit).

Situation avant établissement de la relation entre COMMANDE et LIGNE_COMMANDE :

Image non disponible
Figure 5.11 - LIGNE_COMMANDE (avant)



Situation après :

Image non disponible
Figure 5.12 - LIGNE_COMMANDE (après)



Un index, à savoir LIGNE_COMMANDE_COMMANDE_FK, est à éliminer (cf. paragraphe 4.10), car il a pour clé le couple <ClientId, CommandeId> inclus dans le triplet <ClientId, CommandeId, LigneCommandeId>, lui-même utilisé pour la clé de l'index primaire de la table LIGNE_COMMANDE (où — identification relative oblige — LigneCommandeId est à numéroter relativement à <ClientId, CommandeId>) :

Image non disponible
Figure 5.13 - Index superflu à éliminer



En ce qui concerne l'action compensatoire ON DELETE, elle est évidemment CASCADE puisque les lignes de facture sont réellement des entités faibles (cf. paragraphe 1.3), ce qui oriente les choix quant aux conséquences de la suppression d'une commande cf. paragraphe 10.4.6) :

Image non disponible
Figure 5.14 - ON DELETE CASCADE

5.3. Retour sur les associations de plusieurs à plusieurs : associations ternaires

Le procédé utilisé pour les associations binaires vaut bien entendu pour les associations ternaires et au-delà. Supposons qu'on veuille établir une telle association pour savoir quels langages de programmation les développeurs de l'entreprise Dubicobit utilisent dans le développement des projets de la maison.

Situation initiale :

Image non disponible
Figure 5.15 - Association ternaire, situation initiale



On définit la table servant à implémenter l'association ternaire, appelons-la UTILISATION :

Image non disponible
Figure 5.16 - Association ternaire, table UTILISATION vide



On établit un 1er lien identifiant :

Image non disponible
Figure 5.17 - Association ternaire, un 1er lien



Puis on établit un 2e lien :

Image non disponible
Figure 5.18 - Association ternaire, un 2e lien



Et enfin le 3e lien :

Image non disponible
Figure 5.19 - Association ternaire complétée




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.