Jusque-là, nous parlions de classes unitaires, mais un domaine c'est souvent un ensemble de classes liées entre elles. Dans ce chapitre, nous allons aborder plus en détail la façon de relier les classes pour former un tout. Nous verrons comment représenter ceci en UML et comment cela se traduit en termes de base de données relationnelle.
Lors de la modélisation d'un domaine fonctionnel, vous devez tout d'abord comprendre quels sont les différentes entités en jeu (-> les classes) et comment celles-ci forment un système cohérent.
Pour ce faire, dans le cadre d'un système de vente en ligne, vous pouvez poser des questions comme :
Qu'est-ce qui est vendu ?
Les articles sont-ils classables en plusieurs catégories ?
Dois-je prendre en compte le stock des articles ?
Un client peut-il avoir des bons d'achat sur son compte ?...
Tout ce questionnement va vous permettre de faire une idée générale du domaine fonctionnel en identifiant les différentes parties qui le composent et les liens qui existe entrent elles (un Article est dans une Categorie, un Client peut détenir des BonAchat...).
Décrivez les relations
Une base de données relationnelle s'appuie sur un modèle relationnel et donc il s'agit d'un système possédant des relations entre ses différentes parties (les tables).
UML fournit un formalisme pour décrire les relations entre les classes ainsi que les contraintes apposées sur ces relations.
Comme nous l'avons déjà vu dans le chapitre précédent, nous avons, de manière générale, une correspondance entre les classes du modèle objet (UML) et les tables de la base de données (MPD).
En UML, la relation entre deux classes s'appelle une association.
Pour modéliser une association entre deux classes, vous tracez simplement un trait entre elles.
Vous pouvez, si besoin, préciser un nom pour cette association au milieu du trait (généralement un verbe) :
On lit alors la relation comme ceci :
« Un musicien forme des groupes »
« Un groupe est formé par des musiciens »
Vous pouvez également donner un rôle à chaque classe en le notant du côté des classes concernées :
On interprète alors la relation comme ceci :
« Une personne, en tant que conducteur, conduit un véhicule »
« Un véhicule, en tant moyen de locomotion, est conduit par une personne »
Imaginez 2 associations entre une classe Personne et une classe Livre :
la première indique le/les auteurs d'un livre
la deuxième indique le/les traducteurs d'un livre
Voici comment cela peut être représenté avec les noms des associations :
Voici comment cela peut être représenté avec les rôles sur les associations :
Posez des limites avec les multiplicités
Les multiplicités servent à apposer des contraintes numériques sur l'association, ou plus précisément, combien d'instances d'une classe peuvent être liées à une instance de la classe de l'autre côté de l'association. En d'autres termes, elles bornent les cardinalités des instances liées entre elles.
Si on reprend l'exemple du dessus avec les musiciens, il est possible de fixer le nombre de musiciens minimum et maximum qui peuvent jouer dans un groupe. De même il est possible de définir dans combien de groupes différents (min et max) un même musicien peut jouer.
Voici un exemple abstrait montrant comment sont représentées les multiplicités :
Cela s'interprète comme ceci :
Une instance de la classe
Adoit être associée à au moinsmet au plusninstances de la classeBUne instance de la classe
Bdoit être associée à au moinsxet au plusyinstances de la classeA
Si je reprends l'exemple des musiciens, voici, ci-dessous, le diagramme correspondant aux règles suivantes :
Un musicien joue dans 5 groupes maximum, mais peut aussi ne jouer dans aucun groupe.
Un groupe est constitué d'au moins 2 musiciens et 10 au maximum
Synthèse des multiplicités
Il existe des abréviations pour certaines plages de cardinalités. Voici un tableau de synthèse des multiplicités, avec leur notation, leur abréviation éventuelle et leur signification en termes de cardinalités :
Multiplicité | Abréviation | Cardinalités |
|---|---|---|
0..0 | 0 | Aucune instance |
0..1 |
| Aucune ou une seule instance |
1..1 | 1 | Exactement une instance |
0..* | * | Aucune, une ou plusieurs instances (aucune limite) |
1..* |
| Au moins une instance (aucune limite maximum) |
x..x | x | Exactement x instance(s) |
m..n |
| Au moins m et au plus n instances |
Les 3 catégories d'association
Les associations sont classées en trois catégories en fonction des multiplicités apposées sur celles-ci :
un à un (one-to-one) :
Un conducteur conduit une et une seule voiture à la fois
Une voiture n'est pas conduite (en stationnement) ou conduite par un seul conducteur à la fois
un à plusieurs (one-to-many) ou plusieurs à un (many-to-one) :
Un journal contient aucun (journal en préparation), un ou plusieurs articles
Un article est contenu dans aucun (en cours d'écriture) ou un seul journal
plusieurs à plusieurs (many-to-many) :
Un musicien fait partie d'aucun, un ou plusieurs groupes
Un groupe est constitué de un ou plusieurs musiciens
Dans ce chapitre nous avons vu :
comment décrire les relations entre les différentes classes du domaine fonctionnel,
comment imposer des limites de cardinalité
et les 3 catégories de relations :
un à un (one-to-one)
un à plusieurs (one-to-many) ou plusieurs à un (many-to-one)
plusieurs à plusieurs (many-to-many)
Dans le prochain chapitre, nous verrons comment mettre en œuvre ces relations dans la base de données en commençant par s'assurer que chaque instance d'une classe ait un identifiant unique.
Qu'est-ce que cela signifie ? C'est justement ce que nous allons aborder !
