« Open ModelSphere est un outil complet de modélisation de données qui prend en charge la modélisation conceptuelle, logique et physique. Il supporte plusieurs formalismes, entre autres: Entité-Association, DATARUN, et Information Engineering. Les modèles conceptuels peuvent être convertis en modèles relationnels et vice versa. »

Avec Open Modelsphere, on peut notamment modéliser des bases de données selon la méthode Merise ou en faisant un diagramme de classes UML.

C’est aussi, à ma connaissance, le seul logiciel de modélisation open source qui permette de faire des MCT Merise.

Il est téléchargeable sur le site officiel.

Vous remarquerez que la version téléchargeable est indiquée pour Windows mais comme il s’agit d’un programme Java, il fonctionne aussi sous Linux.

Voici les changements à opérer pour que ça fonctionne…

Après téléchargement de « Open ModelSphere 3.2 sous Windows (fichier zip) », décompressez celui-ci dans le répertoire de votre choix, puis donnez-vous éventuellement les droits d’accès nécessaires.
Sur ma Mageia Linux 2, je l’ai installé dans /usr/share/. Vous aurez alors un répertoire « Open_ModelSphere_[version] ». J’ai renommé ce répertoire tout simplement en « modelsphere » pour éviter des problèmes avec les noms à espaces et autres points.
Dans ce répertoire, vous trouverez un fichier « modelsphere.bat » dont le contenu est le suivant :

Ouvrez ce fichier avec un éditeur de texte et transformez-le de cette manière :

=> Il faut ajouter le descripteur du shell et la commande pour se rendre dans le répertoire du logiciel, supprimer le chemin Windows vers le programme java et remplacer :
– les antislashes par des slashes ;
– les points virgules par des doubles-points.
Vous pouvez copier/coller directement le code ci-dessus pour la version 3.2 mais si vous installez une version ultérieure, appliquez le principe donné juste avant pour faire votre lanceur d’application.

Enregistrez-le sous « modelsphere.sh », rendez-le exécutable (chmod a+x modelsphere.sh) et servez-vous en pour démarrer Open Modelsphere.

Vous pouvez ensuite faire un raccourci vers le programme. Je l’ai placé dans le menu « Développement » de KDE en lui associant la commande suivante : /usr/share/modelsphere/./modelsphere.sh

Il faut bien sûr que Java soit installé et qu’il puisse être activé par la simple commande « java » !

PS :
– Merci à passie pour sa collaboration dans la recherche de la bonne syntaxe en 2009.
– Un site utile pour utiliser Open Modelsphere : http://www.marco-savard.com/OpenModelSphere/index_fr.html

Bonnes modélisations !

Ceux qui connaissent le modèle conceptuel de données (MCD) de la méthode Merise savent que lorsque les cardinalités maximales d’une association sont toutes deux à n, cela entraînera la création d’une table associative dans la base de données.

Mais il y a d’autres cas et certains suscitent quelques débats au sein des forums.

Examinons tous les cas possibles…

Soit deux entités A et B et une association entre elles. Les 16 associations possibles sont les suivantes :
01) A -0,1—-associer—-0,1- B
02) A -0,1—-associer—-1,1- B
03) A -0,1—-associer—-0,n- B
04) A -0,1—-associer—-1,n- B
05) A -1,1—-associer—-0,1- B
06) A -1,1—-associer—-1,1- B
07) A -1,1—-associer—-0,n- B
08) A -1,1—-associer—-1,n- B
09) A -0,n—-associer—-0,1- B
10) A -0,n—-associer—-1,1- B
11) A -0,n—-associer—-0,n- B
12) A -0,n—-associer—-1,n- B
13) A -1,n—-associer—-0,1- B
14) A -1,n—-associer—-1,1- B
15) A -1,n—-associer—-0,n- B
16) A -1,n—-associer—-1,n- B

On remarque que les cardinalités de l’association 02 sont inversées par rapport à l’association 05, de même pour la 03 et la 09, la 04 et la 13, la 07 et la 10, la 08 et la 14, la 12 et la 15.
Il ne reste donc plus que les 10 cas suivants :
01) A -0,1—-associer—-0,1- B
02) A -0,1—-associer—-1,1- B
03) A -0,1—-associer—-0,n- B
04) A -0,1—-associer—-1,n- B
06) A -1,1—-associer—-1,1- B
07) A -1,1—-associer—-0,n- B
08) A -1,1—-associer—-1,n- B
11) A -0,n—-associer—-0,n- B
12) A -0,n—-associer—-1,n- B
16) A -1,n—-associer—-1,n- B

Commençons par les cas les plus faciles…
Comme dit en introduction, il faut une table associative lorsque les cardinalités maximales sont à n. Il s’agit ici des 3 derniers cas, 11, 12 et 16.
Lorsque que les cardinalités sont à 1,1 d’un côté d’une association, il y aura une clé étrangère dans la table issue de l’entité située du côté des cardinalités 1,1. Il s’agit ici des cas 02, 07 et 08. Le cas 06 appelle des commentaires que je ferai plus tard…

Inscrivons ces cas simples dans le tableau :
01) A -0,1—-associer—-0,1- B
02) A -0,1—-associer—-1,1- B => Clé étrangère dans la table issue de l’entité B
03) A -0,1—-associer—-0,n- B
04) A -0,1—-associer—-1,n- B
06) A -1,1—-associer—-1,1- B
07) A -1,1—-associer—-0,n- B => Clé étrangère dans la table issue de l’entité A
08) A -1,1—-associer—-1,n- B => Clé étrangère dans la table issue de l’entité A
11) A -0,n—-associer—-0,n- B => Table associative
12) A -0,n—-associer—-1,n- B => Table associative
16) A -1,n—-associer—-1,n- B => Table associative

Examinons maintenant les cas qui restent, en commençant par le 06, qui semblerait entrer dans la seconde catégorie des cas faciles…

Cas 06) A -1,1—-associer—-1,1- B
Lorsque les deux couples de cardinalités sont à 1,1, on doit se demander si on peut fusionner les deux entités. Si elles représentent des choses sémantiquement différentes ou si on les conserve pour une raison technique (ajout de table à une BDD existante, amélioration des performances par séparation de données importantes en volume mais rarement lues…), on a le choix de la table qui accueillera la clé étrangère.

Cas 04) A -0,1—-associer—-1,n- B
La clé étrangère ne peut pas aller dans B puisque un B peut être associé à plusieurs A. Mais elle ne peut pas non plus aller dans A puisque un A peut ne pas être associé à un B. Il faut donc une table associative. Et comme un A sera associé au maximum une seule fois à un B, la clé primaire de la table associative sera la clé étrangère référençant A.

Cas 03) A -0,1—-associer—-0,n- B
Aucune des deux entités n’est systématiquement associée à l’autre (cardinalités minimales à 0). Il faut donc une table associative dont la clé primaire sera, pour la même raison que dans le cas 04, la clé étrangère référençant A.

Cas 01) A -0,1—-associer—-0,1- B
Pour la même raison que dans le cas 03, il faut une table associative. Et pour la même raison que dans le cas 06, on a le choix de la clé étrangère qui sera également clé primaire, l’autre clé étrangère devant être munie d’une contrainte d’unicité.

Complétons le tableau :
01) A -0,1—-associer—-0,1- B => Table associative avec le choix de la clé primaire.

• A (IdA, …) ;
• B (IdB, …) ;
• AB (#IdA, #IdB, …) + index unique sur #IdB
  ou AB(#IdB, #IdA, …) + index unique sur #IdA.

02) A -0,1—-associer—-1,1- B => Clé étrangère dans la table issue de l’entité B

• A (IdA, …) ;
• B (IdB, #IdA, …).

03) A -0,1—-associer—-0,n- B => Table associative dont la clé primaire référence A

• A (IdA, …) ;
• B (IdB, …) ;
• AB (#IdA, #IdB, …).

04) A -0,1—-associer—-1,n- B => Table associative dont la clé primaire référence A

• A (IdA, …) ;
• B (IdB, …) ;
• AB (#IdA, #IdB, …).

06) A -1,1—-associer—-1,1- B => Fusion des deux entités ou clé étrangère dans A ou B

• AB (IdAB, {attributs de A}, {attributs de B}, …).

ou :

• A (IdA, #IdB, …) ;
• B (IdB, …).

ou

• A (IdA, …) ;
• B (IdB, #IdA, …).

07) A -1,1—-associer—-0,n- B => Clé étrangère dans la table issue de l’entité A

• A (IdA, #IdB, …) ;
• B (IdB, …) ;

08) A -1,1—-associer—-1,n- B => Clé étrangère dans la table issue de l’entité A

• A (IdA, #IdB, …) ;
• B (IdB, …) ;

11) A -0,n—-associer—-0,n- B => Table associative

• A (IdA, …) ;
• B (IdB, …) ;
• AB (#IdA, #IdB, …).

12) A -0,n—-associer—-1,n- B => Table associative

• A (IdA, …) ;
• B (IdB, …) ;
• AB (#IdA, #IdB, …).

16) A -1,n—-associer—-1,n- B => Table associative

• A (IdA, …) ;
• B (IdB, …) ;
• AB (#IdA, #IdB, …).

Sur 10 cas, il y en a donc 6 qui nécessitent une table associative !

== Mise à jour du 20/09/2011 ==
Suite à une question posée par cretthie dans une discussion du forum MySQL/Requêtes, j’apporte des précisions pour les cas demandant une table associative.

01) Il y aura une clé étrangère référençant A et une autre référençant B. On a le choix de décider quelle clé étrangère constituera également, toute seule, la clé primaire de la table. L’autre colonne portant la seconde clé étrangère sera en plus munie d’une contrainte d’unicité (index de type UNIQUE chez MySQL) pour respecter la cardinalité 0,1.
03) et 04) Là aussi, la clé primaire n’est constituée que d’une seule des deux clés étrangères : celle référençant A. L’autre est une clé étrangère « ordinaire ».
11), 12) et 16) Dans ces trois cas, la clé primaire de la table associative est composée des clés étrangères référençant A et B.

La méthode que je décris ci-après devrait vous aider beaucoup pour apprendre à modéliser correctement.

1) Écrire une règle de gestion
L’exercice consiste à écrire en français (ou dans la langue de votre choix) une phrase décrivant comment sont associés deux concepts.

Par exemple, on vous demande de modéliser les données nécessaires à une gestion de projets et on vous dit, entre autres, qu’il y a toujours une personne qui est nommée chef de projet pour un projet et que plusieurs personnes travaillent sur un projet.

L’extrait en italique de la phrase précédente pourrait suffire à un concepteur habitué à la modélisation des données pour produire un MCD correct et possible mais il manque des informations pour ne pas faire d’erreur :
– est-ce qu’une personne est obligatoirement chef de projet au moins une fois ?
– est-ce que toute personne enregistrée dans le système travaille sur au moins un projet ?
– est-ce qu’une personne ne peut travailler que sur un seul projet à la fois ?

Muni des réponses à ces questions, vous pouvez écrire vos règles de gestion relatives aux associations entre les personnes et les projets. Par exemple, les réponses peuvent vous amener à écrire à coup sûr ces deux règles de gestion :
1) Un projet est dirigé par une seule personne (nommée « chef de projet » pour ce projet) et une personne peut diriger plusieurs projets (en étant nommée « chef de projet » pour chacun d’eux).
2) Un projet fait travailler de une à plusieurs personnes et une personne peut travailler sur plusieurs projets.

Il faut écrire la phrase en partant d’une personne et décrire son association avec les projets (diriger) et compléter la phrase en partant cette fois du projet et décrire l’association inverse vers les personnes.

2) Le passage au MCD
Des règles de gestion écrites précédemment, il est très facile d’en déduire le MCD :
personne -0,n—-diriger—-1,1- projet
|———0,n—-travailler—-1,n—|

Comment ai-je fait ?
Examinons la première règle de gestion :
1) Un projet est dirigé par une seule personne (nommée « chef de projet » pour ce projet) et une personne peut diriger plusieurs projets (en étant nommée « chef de projet » pour chacun d’eux).

Les termes en gras représentent les entités types du MCD : personne et projet. Ce sont, dans les règles de gestion, généralement des noms communs qui font ou qui subissent une action.

Les termes soulignés représentent l’association : diriger. Ce sont généralement des verbes, le plus souvent conjugués une fois à la forme active ([peut] « diriger », ou bien « dirige ») et une fois à la forme passive (« est dirigé par »). Dans le MCD, on laissera ce verbe à l’infinitif pour pouvoir lire l’association dans les deux sens plus facilement.

Les termes en italique sont un guide pour déterminer les cardinalités de l’association :
– « est dirigé » indique une obligation, donc une cardinalité minimale de 1 ;
– « un seul » indique une cardinalité maximale de 1 ;
– « peut [diriger] » indique une possibilité, donc aussi la possibilité qu’une personne ne dirige aucun projet, soit une cardinalité minimale de 0 ;
– « plusieurs » indique une cardinalité maximale de n.

Examinez la seconde règle de gestion et vous verrez que cela fonctionne de la même manière.

Au bout de quelques exercices de formalisation de règles de gestion de la sorte, vous passerez tellement facilement à la génération du MCD que vous finirez par vous passer de l’écriture des règles de gestion et vous contenterez seulement d’y penser quand vous dessinerez directement le MCD.

3) Petit exercice
Comment modéliseriez-vous le fait qu’un projet est dirigé obligatoirement par une personne ayant le titre de chef de projet et que d’autres personnes peuvent travailler sur le projet ?

Écrivez une ou des règles de gestion possibles puis passez au MCD.