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.

[subrms]

Il y a en fait trois approches :

Model-First
Avantages :

• Nous serons en mesure de créer le schéma de la base de données et le diagramme de classe dans son ensemble en utilisant un outil de conception visuelle, ce qui peut être très utile lorsque la structure des données est assez grande.
• Chaque fois que la base de données change, le modèle peut être mis à jour en conséquence, sans perte de données.

Inconvénients :

• Les scripts SQL autogénérés, pilotés par des diagrammes, peuvent entraîner des pertes de données en cas de mises à jour. Une solution simple consiste à générer les scripts sur le disque et à les modifier manuellement, ce qui nécessite une connaissance suffisante du langage SQL.
• L'utilisation du diagramme peut être délicate, surtout si nous voulons avoir un contrôle précis sur nos classes de modèle ; nous ne pourrons pas toujours obtenir ce que nous voulons, car le code source réel sera autogénéré par un outil

Database-First
Avantages :

• Si nous disposons d'une base de données déjà existante, ce sera très probablement la voie à suivre car cela nous évitera de devoir la recréer
• Le risque de perte de données sera réduit au minimum, car toute modification ou mise à jour sera toujours effectuée sur la base de données

Inconvénients :

• La mise à jour manuelle de la base de données peut être délicate si nous avons affaire à des clusters, à de multiples instances ou à un certain nombre d'environnements de développement/tests/production, car nous devrons les synchroniser manuellement au lieu de nous fier à des mises à jour/migrations par code ou à des scripts SQL autogénérés
• Nous aurons encore moins de contrôle sur les classes de modèle autogénérées (et leur code source) que si nous utilisions l'approche Model-First ; cela nécessitera une connaissance approfondie des conventions et des normes EF (Entity Framework), sinon nous aurons souvent du mal à obtenir ce que nous voulons
  
  

Code-First
Avantages :

• Pas besoin de diagrammes ni d'outils visuels, ce qui peut être très utile pour les projets de petite et moyenne taille car cela nous fera gagner beaucoup de temps
• Une API de code fluide qui permet au développeur de suivre une approche de convention sur la configuration, pour traiter les scénarios les plus courants, tout en lui donnant la possibilité de passer à une implémentation personnalisée, basée sur des attributs, chaque fois qu'il a besoin de personnaliser le mappage de la base de données

Inconvénients :

• Une bonne connaissance du langage de programmation et des conventions de l'ORM - C# pour Entity Framework - est requise
• La maintenance de la base de données peut parfois être délicate, de même que la gestion des mises à jour sans perte de données ; le support aux migrations de l'Entity Framework, ajouté dans EF 4.3 pour surmonter le problème et continuellement mis à jour depuis lors, atténue grandement le problème, bien qu'il ait également eu un effet négatif sur la courbe d'apprentissage

SOURCE

[CinePhil]

Model-First
Avantages :

Nous serons en mesure de créer le schéma de la base de données et le diagramme de classe dans son ensemble en utilisant un outil de conception visuelle, ce qui peut être très utile lorsque la structure des données est assez grande.

On peut même concevoir et développer la BDD petit à petit juste avant les programmes qui devront l'utiliser, en méthode Agile. C'est que je suis en train de faire en développant deux application utilisant 3 bases de données.
L'avantage d'une BDD bien conçue est qu'il ne devrait pas y avoir de conséquences lourdes lors de ses évolutions.
On commence par développer les parties création de compte utilisateur et login en commençant en BDD par modéliser et implémenter les parties personne physique, e-mail et utilisateur. A priori il ne devrait pas y avoir de modification majeure là-dessus au fil du développement. Même pas encore besoin à ce stade des rôles utilisateurs et de l'accessibilité des fonctions de l'application en fonction du rôle.

Inconvénients :

Les scripts SQL autogénérés, pilotés par des diagrammes, peuvent entraîner des pertes de données en cas de mises à jour. Une solution simple consiste à générer les scripts sur le disque et à les modifier manuellement, ce qui nécessite une connaissance suffisante du langage SQL.

Ben quand on fait de la BDD, il faut connaître un minimum le SQL, oui. Chose que les développeurs ont généralement tendance à laisser un peu trop de côté, ce qui aboutit à des solutions lourdes techniquement dans l'application alors que ce serait plus simple et efficient en BDD, ou bien des BDD mal foutues.
Il faut toujours vérifier les scripts auto-générés par les logiciels de modélisation avant de les lancer. L'auto-génération n'est jamais parfaite. Il y a toujours des ajustements à faire, des contraintes à ajouter ou à modifier. Et l'avantage de développer la BDD petit à petit est justement de générer les scripts SQL petit à petit. Et ensuite on agit par patches SQL pour ne pas détruire malencontreusement des données.
Et je me méfie énormément des trucs qui génèrent automatiquement du code applicatif en relation avec la BDD. Une appli ne devrait accéder à la BDD que via des vues et des procédures SQL.

Pas le temps de répondre au reste maintenant.

[Paprick]

Bonjour,

Concernant le formalisme utilisé pour la modélisation d'une base de données relationnelle, je rejoins totalement l'avis de CinePhil, et ma préférence va également vers les Schémas Entité-Association (E/A) initialement introduit dans Merise.

Avant d’aller plus loin, il convient de clarifier certains aspects concernant des comparaisons souvent erronées entre différents concepts. Il est en effet fréquent de lire des articles mettant en concurrence MERISE et UML, alors que leur finalité est bien différente. MERISE (Méthode d’Étude et de Réalisation Informatique pour les Systèmes d’Entreprise) est une méthode d'analyse et de conception permettant d’élaborer des systèmes d'information. UML (Unified Modeling Language) est un langage de modélisation proposant exclusivement un ensemble de formalismes pour la conception de logiciels à base d’objets. UML n’est donc pas une méthode : c’est un langage auquel il faut associer une démarche de développement comme, par exemple, RUP (Rational Unified Process).

UML est avant tout conçu pour la modélisation objet. Or, pour modéliser les bases de données relationnelles (qui représentent l’immense majorité des bases de données existantes… et à venir), nul besoin de concept objet. Le diagramme de classes proposé par UML ne sera donc utilisé que partiellement puisque les méthodes associées aux objets n’existent pas dans les MCD destinés aux bases de données relationnelles, comme le montre d'ailleurs votre modèle.

Alors, pourquoi utiliser UML pour modéliser les bases de données relationnelles ? Les diagrammes de classes UML n’apportent rien de plus que les schémas E/A, et affichent même parfois quelques limites, voire pas mal de confusions. Il s’agit donc juste d’une question de mode confortée par le côté « unification » avec les autres diagrammes… et le fait que le formalisme entité-association s’exporte mal en dehors des pays francophones.

Quoiqu’il en soit, les schémas E/A restent les mieux adaptés à la modélisation conceptuelle des données, et se prêtent parfaitement à la génération automatique du schéma relationnel de la base de données correspondante avec les requêtes SQL de création de tables qui vont avec. D'ailleurs, il n'est pas rare de voir les outils de conception UML repasser par la case E/A avant la génération du MLD (Win'Design par exemple).

[Paprick]

Afin d'illustrer mon propos, j'ai repris votre diagramme de classes et je l'ai modélisé rapidement avec Looping.
J'ai fait une transformation sans aucune vérification de fond du MCD... qui, à mon avis, méritera d'être revu, surtout quand on voit le schéma relationnel que vous avez proposé ensuite…

A suivre…

[Paprick]

Et voilà ce que ça donne transformé en diagramme de classe UML par Looping :

[MrTypiac]

Discussion très intéressante. Encore étudiant, j'ai commencé avec Merise et un bon prof. J'ai pleuré du sang mais pour ce qui est de la gestion de bases de données, MCD, MLD, MPD, tout était très clair.

Puis on est passé à un autre prof et UML (soi-disant plus moderne que Merise). J'ai repleuré du sang mais j'arrive à générer un MPD à partir d'un diagramme de classe. En revanche, quid de l'utilisation des méthodes au sein dudit diagramme...

Cela semble ne servir qu'à conceptualiser. Powerdesigner propose bien de générer un projet J2EE mais on est quand même à l'heure de Spring boot depuis quelques années donc autant dire qu'à part bien préparer ses petites méthodes, niveau implémentation ça ne sert à rien.

Petite question subsidiaire à Paprick: tu associes la classe production. Quand je fais ça, moi ça me reparti le contenu de la classe d'association dans les 2 autres classes et ça me donne un résultat très "bordélique". Du coup, j'ai tendance à contourner le problème via une généralisation... as-tu le même genre de résultat?

[Paprick]

Bonsoir,

Petite question subsidiaire à Paprick: tu associes la classe production. Quand je fais ça, moi ça me reparti le contenu de la classe d'association dans les 2 autres classes et ça me donne un résultat très "bordélique". Du coup, j'ai tendance à contourner le problème via une généralisation... as-tu le même genre de résultat?

Lorsqu'une association a des cardinalités multiples de part et d'autre comme c'est le cas de "Production", la génération du MLD doit provoquer la création d'une table d'association distincte, et surement pas une "répartition" de son contenu dans les classes associées !
Je ne sais pas quel logiciel vous génère ce genre de résultat, mais il y a comme un problème...

Dans l'exemple ci-dessus, voici le MLD qui doit être généré :

[MrTypiac]

Effectivement, je n'ai pas du tout le même résultat. J'utilise pourtant power designer... Etant donné que j'ai contourné le problème avec une généralisation, je n'ai plus l'exemple mais je vais en refaire un parce qu'effectivement, il m'est arrivé d'avoir deux résultats différents avec 2 associations qui étaient pourtant dans le même cas de figure avec exactement les même cardinalités où j'avais les deux résultats suivants:

- la classe associée devient une classe distincte (mais également ad hoc des deux autres classes)
- les attributs de la classe associées se retrouvent dans les deux classes "mère".

Je vais poster un exemple.

[escartefigue]

Bonjour,

Je rejoins Cinephil et Paprick quant à la préférence d'un modèle entité-association plutôt qu'un modèle UML.

Cela étant dit

la classe associée devient une classe distincte (mais également ad hoc des deux autres classes)

jusqu'ici tout va bien.

les attributs de la classe associées se retrouvent dans les deux classes "mère".

Là par contre, je ne pense pas que ce soit power-AMC qui ait produit cette aberration ...
J'ai utilisé par le passé power-AMC sans jamais obtenir (fort heureusement) ce type de résultats.