Discussion :

[subrms]

Bonjour,

En partant d'une situation réelle, j'ai modélisé le diagramme de classes suivant en UML :

Le schéma :



Le contexte :

Un producteur dispose d'un stock de matière première. Il peut effectuer plusieurs levées de différentes quantités pour constituer une part. Cette part passera au cours de sa transformation par plusieurs étapes dont le cycle peut changer (ce ne sont pas les mêmes étapes qui sont appliquées pour toutes les parts). Une interaction définit chaque passage d'une part par une étape, et celle-ci est faite par un ou plusieurs employés pour produire un produit défini. Il y a des pertes (déchets) qui seront par la suite recyclées dans le stock.

Les questions :

Diagramme de classes UML (DC) :
Tout d'abord, ce diagramme est-il correct syntaxiquement ? L'utilisation des classes d'association Levee, Interaction et Production est-elle justifiée ?

Passage du Modèle de Classes UML au Modèle Physique de Données (MPD) :
Quand on relie une classe d'association (ex : Interaction) à d'autres classes du modèle (ex : Employe, TypeProduit, Dechet) et que lors du passage au MPD il faut créer une table ad hoc (ex : entre Interaction et Employe créer la table EmployeInteraction) matérialisant les liens multiples à l'aide d'une clé primaire composée des clés étrangères (dans le cas de l'exemple pris, les clés étrangères pointeront vers les tables Interaction et Employe). Or la clé primaire de la classe d'association elle-même est composée d'une combinaison de clés étrangères (ici la classe association Interaction).

Ce schéma représente le passage du DC vers le MPD pour les classes Levee, Etape, Interaction et Employee, avec la création d'une table ad hoc EmployeInteraction :



Dans ce cas, la clé primaire de la classe EmployeInteraction est-elle composée de trois clés étrangères (employeId, leveeId et etapeId) ? Ces clés pointent vers les tables Employe et Interaction ou bien vers Employe, Etape et Levee ?

Je vous remercie d'avance pour vos éclaircissements.

[CinePhil]

Bonjour,

Je maîtrise mieux le MCD Merise que le DC UML mais le principe est le même : lorsque qu'il y a des multiplicités * des deux côtés d'une association, il faut ce que j'appelle une "table associative" dont la clé primaire est composée des clés étrangères référençant les tables issues des classes en jeu dans l'association.

Voir mon article à ce sujet (côté MCD Merise mais c'est pareil).

[subrms]

Bonjour,

Je maîtrise mieux le MCD Merise que le DC UML mais le principe est le même : lorsque qu'il y a des multiplicités * des deux côtés d'une association, il faut ce que j'appelle une "table associative" dont la clé primaire est composée des clés étrangères référençant les tables issues des classes en jeu dans l'association.

Voir mon article à ce sujet (côté MCD Merise mais c'est pareil).

Je te remercie pour ta réponse. Après avoir essayé plusieurs approches, il me semble que le DC UML suivi d'un schéma relationnel semble être le meilleur moyen pour mettre en place rapidement une base de données relationnelle. J'évite d'utilisation des clés primaires composées de clés étrangères, mais à chaque fois des identifiants uniques.

[CinePhil]

il me semble que le DC UML suivi d'un schéma relationnel semble être le meilleur moyen pour mettre en place rapidement une base de données relationnelle

À mon avis, le MCD Merise est le meilleur outil de conception d'une BDD. C'est plus rigoureux que le DC UML qui peut autoriser des choses bizarres.

Et avec un logiciel de modélisation, quel que soit la méthode/langage utilisé (Merise/UML), la génération de la BDD est au moins semi-automatisée.

J'évite d'utilisation des clés primaires composées de clés étrangères, mais à chaque fois des identifiants uniques.

Mauvaise idée !
Pour être conforme aux règles de gestion, il faut de toute manière mettre une contrainte d'unicité sur le groupe de clés étrangères alors autant s'en servir de clé primaire.
Relire mon article donné dans le message précédent.

[subrms]

Il y a à mon sens aujourd'hui des approches de développement beaucoup plus rapidement et qui parfois encourage à commencer à coder avant même la conception de la base de données (Code First x Database First), et c'est efficace. Maintenant pour une application volumineuse avec des règles de gestion nombreuses je ne sais pas s'il convient de privilégier ce genre d'approches.

La méthode Merise est trop rigoureuse et lourde à mettre en place pour quelqu'un qui veut entamer le développement vite et le DC UML fait l'affaire, le passage au modèle relationnel est plutôt simple.
J'ai lu ton article que j'ai trouvé très bon, il m'a aidé à comprendre certains aspects que je ne maîtrisais pas, je t'en remercie.

Je suis arrivé à ce schéma, je voudrais bien avoir ton avis :

[CinePhil]

Il y a à mon sens aujourd'hui des approches de développement beaucoup plus rapidement et qui parfois encourage à commencer à coder avant même la conception de la base de données

Et c'est ce genre de démarche qui conduit à des bases de données pourries qui un jour ou l'autre poseront problème.

Je n'ai pas encore trouvé une seule base de données correctement modélisée dans les logiciels courants disponibles en open source, que ce soient les CMS, Moodle, PMB (logiciel de bibliothèque) ou même Jira. Résultat : tous ces logiciels finissent par être des monstres lents nécessitant davantage de ressources matérielles, des caches et autres artifices pour continuer à tourner avec des performances satisfaisantes lorsque le volume de données devient plus important.

Les SGBD sont calibrés pour traiter d'énormes volumes de données. Avec une BDD bien structurée et bien indexée, n'importe quelle requête doit obtenir son résultat en moins d'une seconde.

Je n'ai pas dit que le DC UML est mauvais pour modéliser une BDD mais que le MCD Merisien est plus rigoureux et donc peut éviter des fautes de modélisation, surtout pour les débutants.