Discussion :

[laurent_42]

Bonjour,

Je découvre Open ModelSphere, version 3.2.

Après avoir vérifié mon MCD (dans lequel j'ai déjà défini les clés primaires), je l'ai converti en MRD. J'essaie ensuite de générer les clés étrangères. Et là, Open ModelSphere me rajoute des clés primaires dans mes entités.

Exemple

Etudes --- 1,N --- Se diviser en --- 1,1 --- Bordereaux
ETU_ID est la clé primaire de Etudes
BORD_ID celle de Bordereaux

J'attends une clé étrangère ETU_ID dans Bordereaux. Il la crée effectivement.

Mais en plus il définit dans Bordereaux ETU_ID aussi comme clé primaire.

Et là je ne comprends pas. Je tourne en rond depuis l'autre jour. Je n'arrive pas à voir où je fais une bêtise...

Si vous aviez une idée à me suggérer...

Merci d'avance !

Laurent

[fsmrel]

Bonsoir Laurent,


Vous avez sans doute utilisé l'identification relative, mais il faudrait que vous affichiez cette partie du MCD, pour qu'on y voie clair et qu'on puisse vous aider.

[laurent_42]

Bonjour,

Merci pour votre réponse.

Tout d'abord, sachez qu'en plus de découvrir Open ModelSphere, je découvre aussi la modélisation. J'ai lu plusieurs fois des messages dans lesquels il est question d'identification relative. Mais j'avoue que je n'ai pas réussi à comprendre ce que ça voulait dire, ce à quoi ça correspondait et comment on créait une identification relative ni comment on pouvait la supprimer sous Open ModelSphere.
J'ai juste cru comprendre qu'une cardinalité soulignée indiquait une identification relative (c'est en gros ce que vous dites dans un message de 2010). Dans ce cas, je sais créer une identification relative. Mais à part ça... pfffoouuuu... Est-ce qu'il s'agit simplement du nom que l'on donne à une association dans le cas d'un héritage ?

J'ai pensé à un truc de ce type hier après-midi. Ne sachant pas comment on annule une identification relative, j'ai repris mon modèle conceptuel en copiant les entités et en redéfinissant les associations. Je n'ai pas eu le temps de finir et donc je n'ai pas pu encore tester la génération des clés étrangères. Mais ça serait la direction ?

Pour répondre à votre question, voici une copie d'écran de la relation mentionnée dans mon premier message.



Merci beaucoup,

Au plaisir,
Laurent

PS : ne vous offusquez pas d'une absence de réponse de ma part cette fin de semaine. Je ne pourrai pas trop consulter mes mails et encore moins travailler à ce projet.

[fsmrel]

Bonsoir Laurent,


Comme vous débutez en modélisation, j’attire votre attention sur un point préalable : le diagramme que vous présentez n’est pas un MRD (modèle relationnel de données), car « modèle relationnel de données » est l’autre nom de la théorie relationnelle, n’en déplaise aux auteurs d’Open ModelSphere qui vous ont donc induit en erreur. Votre diagramme est un MLD (modèle logique des données), c'est-à-dire un modèle où sont pris en compte des concepts différents de ceux du MCD (modèle conceptuel des données), tels que celui de table (on ne parle plus d’entité-type ou d’association), de clé primaire (traduction de l’identifiant d’entité-type), de clé étrangère (traduisant notamment les associations porteuses de cardinalités 1,1), etc. OMS utilise en réalité une terminologie SQL : en relationnel on parle de variables relationnelles quand SQL parle de tables ; le qualificatif de « primaire » ne concerne que les clés SQL (il n’apporte aucune valeur ajoutée et a donc été passé au fil du rasoir d’Ockham), etc.


A propos de l’identification relative

Prenons le cas de la discussion dans laquelle vous posez vos questions, auxquelles nous essayons de répondre...

Cette discussion est caractérisée notamment par son titre, son auteur, la date de sa création et bien sûr les messages qui s’y raccrochent. Ces derniers ne vivent qu’au travers de la discussion qui les a suscités, leur a donné naissance : si un modérateur supprime la discussion, les messages en question disparaissent eux aussi. Si un modérateur déplace la discussion d’un forum à un autre, les messages suivent le mouvement. Question : les messages accrochés à une discussion peuvent-ils en être détachés, pour être rattachés à une autre discussion ? Certes non, Ce serait un non-sens, une absurdité, voyez ma tentative de réponse atterrir on se sait où... Bref, un message n’a ici aucune autonomie , c’est une propriété d’une discussion, il en dépend complètement. Peter Chen, père du modèle entité-relation, a formalisé cela : un message est une entité faible (weak entity), dépendant d’une entité-plus forte, à savoir une discussion. Peter Chen symbolise la chose à l’aide d’un rectangle emboîté dans un autre :





En traduisant cela en Merise, il y a une relation de composition, et on dit que l’entité-type (faible) MESSAGE est identifiée relativement à l’entité-type DISCUSSION. On pourrait préférer ne parler que de relation de composition (comme c’est le cas dans un diagramme de classes UML), mais « identification relative » est l’expression consacrée. A cela près, au lieu de l’emboîtement des rectangles, OMS offre le soulignement de la cardinalité 1,1 :






Lors du passage au MLD, l’identification relative, l’entité-type MESSAGE a donné lieu à une table de même nom, dont la clé primaire est la paire {DiscussionId, MessageNo}, l’attribut DiscussionId étant hérité de DISCUSSION :







Pour virer l’attribut DiscussionId de la clé primaire, il eut été trop simple de se contenter de cliquer sur le souligné de la cardinalité1,1, il faut sélectionner la clé elle-même, par exemple ainsi :






Un clic droit à la souris sur « Propriétés » provoque l’ouverture de la boîte magique où se cache un onglet « Colonnes » qui nous intéresse au plus haut point :






En cliquant sur cet onglet, on voit maintenant apparaître les noms des colonnes composant la clé :






Il n’y a plus qu’à utiliser le bouton « Délier ». Et dans OMS, au stade du MLD, tout est à peu près aussi (voire plus) compliqué : à conseiller aux masos...

Autrement dit, pour produire un MLD, le mieux est d’encadrer soigneusement le MCD et l’accrocher au mur, ça fait toujours de l’effet sur l’amateur... Ensuite, on crée un MLD avec MySQL Workbench (je vous ai mijoté un mode d’emploi à peu près complet), ça va beaucoup plus vite et on n’a plus envie de tout envoyer balader. Voyez la discussion avec Jéjé34 exemplaire à ce propos.

Revenons à l'identification relative considérée pour elle-même.

Pour les valeurs prises par les colonnes de la clé primaire, le principe est le suivant :

Supposons que pour la 1re discussion engrangée dans la table DISCUSSION l'attribut DiscussionId prenne la valeur 1 : pour chaque message qui s'y accroche, l'attribut DiscussionId prendra aussi la valeur 1, tandis que pour le 1er message, l'attribut MessageNo prendra la valeur 1, pour le 2e message, il prendra la valeur 2, etc., pour le nième ça sera la valeur n.

Pour la 2e discussion, même principe : si dans la table DISCUSSION l'attribut DiscussionId prend la valeur 2, pour chaque message qui s'y accroche, l'attribut DiscussionId prendra aussi la valeur 2, tandis que pour le 1er message, l'attribut MessageNo prendra la valeur 1, pour le 2e message, il prendra la valeur 2, etc., pour le n’ième ça sera la valeur n’, etc.


Exemple (table MESSAGE) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
DiscussionId    MessageNo    MessageTitre    MessageAuteur    MessageDate    MessageContenu
------------    ---------
           1            1    Merise ?        Fernand          1961-01-22     Bonjour, ...
           1            2                    Raoul            1961-01-23     Certes, ....
           1            3    Ça marche       Paul             1661-01-25     Pas compris...

           2            1    SQL, !          Albert           1961-01-23     Bonsoir à tous, ...
           2            2    Non et non !    Bernard          1961-01-27     Ben voyons....
           2            3    Si !            Albert           1961-01-28     Le chef a dit ...
           2            4    SQL encore      Caroline         1961-01-30     C’est pourtant simple...

Mais en fait, l’attribut MessageNo peut prendre des valeurs qui ne respectent pas la séquence 1, 2, 3, etc. : tout ce qu’on demande est que la paire {DiscussionId, MessageNo} prenne des valeurs toutes différentes, tout en respectant bien sûr l’intégrité référentielle : les valeurs prises par l’attribut DiscussionId doivent être des valeurs prises par l’attribut DiscussionId de la table DISCUSSION.

ne vous offusquez pas d'une absence de réponse de ma part cette fin de semaine

Ne vous inquiétez pas, chez DVP il y a toujours du boulot ! De toute façon, n’hésitez pas à poser les questions qui vous tarabustent...

[laurent_42]

Bonjour,

Waaaaooouuuhhhhh !!! Ca, c'est une réponse complète et super claire !

Merci infiniment.

Je vote pour que la réponse passe dans la FAQ. Mais peut-être que l'identification relative est un concept clair pour tout le monde.

A très bientôt (oui la discussion avec Jéjé34 m'a donné des idées de post... :-)

Laurent

[fsmrel]

Bonsoir Laurent,

peut-être que l'identification relative est un concept clair pour tout le monde

Euh...


En tout cas, n'hésitez pas à revenir faire un tour.