Discussion :

[sammy22]

Bonjour,

Je dois effectuer des recherches sur l' utilisation du XOR en modélisation des données, et savoir à quel moment il est vraiment judicieux d' utiliser un XOR plutôt qu' autre chose (ex :FK etc..).

Si qqun à un début de piste à suivre je suis preneuse

Merci d' avance !

Sam

[fsmrel]

Bonsoir sammy22,


Je suppose que par XOR vous voulez dire « Ou exclusif ». S’il en est ainsi, disons de façon informelle que le Ou exclusif permet, dans un MCD merisien (ou un diagramme de classes UML), de mettre en évidence que deux types d’entités (classes) ou sous-types (sous-classes) ne partagent pas de propriétés communes.

Par exemple, si vous modélisez Les personnes dans un organisme tel que la Sécurité sociale, ou une caisse de retraite, vous aurez vraisemblablement une entité-type PERSONNE et deux sous-types ENTREPRISE (personne morale) et INDIVIDU (personne physique, disons le salarié d’une entreprise). L’entité-type PERSONNE regroupe les propriétés communes aux personnes physiques et morales : adresse, numéro de téléphone, etc., tandis que les personnes physiques ont un NIR (j'utilise les termes en vigueur en France) et pas de SIREN, alors que les entreprises ont un SIREN mais pas de NIR :




A noter que s’il n’y a pas d’autres personnes que les entreprises clientes et les personnes physiques (par exemple des syndicats, des organismes administratifs, ...), alors il y a partitionnement et le symbole X est à remplacer par XT (exclusion et totalité) :





Les contraintes d'exclusion valent aussi entre les associations. Exemple :

Une personne donnée ne peut pas à la fois suivre des cours et en donner (même si les cours sont différents). Cette contrainte est marquée par un pivot (lui-même symbolisé ici par des pointillés) permettant de limiter la contrainte aux personnes.



Mais un cours peut à la fois être suivi et donné ! (Absence de pivot côté COURS).

Voyez aussi la FAQ Merise (cliquez sur le dessin pour mieux voir...)

Mais pour tout savoir sur le sujet, faites l’acquisition de l’ouvrage très complet de D. Nanci et Bernard Espinasse, Ingénierie des systèmes d’information : Merise deuxième génération.

[sammy22]

Bonjour,

Merci de me votre réponse. J ai compris le fonctionnement général d' une contrainte OU-Exclusif par contre je ne comprend pas le cas présenté en annexe.

Je ne comprendre pas la table de vérité et le pourquoi des cas valides.

Merci de me consacrer un peu de votre temps !

Sam

[fsmrel]

Bonsoir Sam,


A propos du 1e schéma

Le 1er schéma que vous proposez est analogue à celui que j’ai utilisé dans mon message précédent, sinon que votre schéma ne montre pas de pivot.

Le concept de pivot fait l’objet de la norme Merise proposée en 1990 dans le fascicule « Journée afcet du 15 novembre 1990, Le formalisme Merise : extension du pouvoir d’expression. Jeudi 15 novembre 1990, Paris » (fascicule dont j’ai repris l’exemple des personnes qui donnent / suivent des cours) :




Si seuls les hôtels sont concernés par le Ou exclusif, le schéma est le suivant :




Si en plus des hôtels les vacanciers sont aussi concernés, alors le schéma est le suivant :



Mais selon la norme, dans ce cas on peut ne pas faire figurer de pivot, donc la représentation suivante est équivalente à la précédente :




En principe, votre 1er schéma est équivalent à ce dernier, où sont définies deux typologies, celle des hôtels et celle des vacanciers :

— Un hôtel ne peut pas héberger à la fois avec et sans pension ;

— Un vacancier ne peut pas à la fois avoir le profil de simple hébergé et le profil de pensionnaire.

Ça vaut ce que ça vaut...

A vue de nez, je pense quand même que dans votre représentation, le Ou exclusif ne concerne que les hôtels, mais pour le moment ça reste une hypothèse.


Au sujet du 2e schéma

Les colonnes numérotées de 1 à 16 représentent manifestement les 16 combinaisons possibles des 4 cardinalités maximales, symbolisées par A(1), A(2), B(1) et B(2).

Exemple correspondant à la colonne 1 : A(1) = 1, A(2) = 1, B(1) = 1, B(2) =1 (appelons « Cas 1 » cet exemple) :




Ce que l’auteur du schéma appelle ACTIONS représente les réactions à avoir du fait de chaque combinaison de cardinalités maximales et du Ou exclusif, au cas par cas :

Décider qu'on peut en faire quelque chose ou bien qu'il n'y a rien à en tirer (situation d’erreur), et si on peut en faire quelque chose, décider si on peut y aller ou non. En outre, au niveau logique (SQL pour faire court), on doit décider de prévoir ou non des clés étrangères, si oui, combien.

Par exemple, le cas 1 est coché comme possible, il n’est pas coché comme erreur, il n’est pas pris en charge et au niveau logique et on se pose la question de l’opportunité de clés étrangères (pour ma part, je prendrai position sans équivoque, je ne vous laisserai pas dans l'embarras...)

Bref, il y a à boire et à manger dans cette affaire. Dans mon prochain message, je vous ferai part des ambiguïtés que comportent les schémas de votre exercice et des hypothèses que j’ai retenues pour vous expliquer plus à fond ce que j’ai cru comprendre de la signification de la table de décision...

A tout à l’heure.

[fsmrel]

Je poursuis donc. Votre exercice comporte des ambiguïtés et il est incomplet...


1re ambiguïté relevée

Il faut arriver à savoir dans quel sens on lit les cardinalités : A la façon Merise ? A la façon UML ? On est au niveau conceptuel ? Au niveau logique ? (ce n'est pas à vous que je pose la question ! )

Votre 1er schéma utilise le terme « MCD » qui est propre à Merise. Il utilise le terme « entité » qui appartient au vocabulaire Merise mais aussi au vocabulaire Entité/Relation (E/R) de Peter Chen (The Entity-Relationship Model -Toward a Unified View of Data) et la lecture du sens des cardinalités diffère dans les deux approches...

Merise et E/R utilisent des figures géométriques pour symboliser les associations (ellipses dans un cas, losanges dans l’autre) mais votre schéma n’utilise pas ces figures, il fait penser en cela aux diagrammes de classes UML ou aux diagrammes du niveau logique...

Votre schéma utilise le terme « PK » qui relève du niveau logique, plus précisément du vocabulaire SQL, tout comme le concept de clé étrangère qui figure dans la table de décision (actions).

Bref, ce schéma mélange tout, c’est un Big Mac et l’on ne sait pas vraiment trop comment le lire...

Puisqu’il faut se décider, on va conjecturer que la lecture des cardinalités est à l’inverse de celle de Merise et comme dans votre schéma les associations sont résumées à des liens, qu’on y parle de clés primaires (PK), que sont aussi évoquées les clés étrangères dans la table de décision, on peut penser qu’on est au niveau logique.


Dans ces conditions, le cas 6 donne alors lieu à la lecture suivante (indépendamment des problèmes de Ou exclusif, évitons de mélanger les problèmes...) :

— Un hôtel peut héberger plusieurs vacanciers avec pension ;

— Un hôtel peut héberger plusieurs vacanciers sans pension ;

— Un vacancier peut être hébergé dans un hôtel en y prenant pension ;

— Un vacancier peut être hébergé dans un hôtel sans y prendre pension.

Au niveau logique, on peut représenter les choses ainsi (car de toute façon, c’est à ce niveau que tout se joue) :




En conformité avec les « actions » du cas 6 (cas possible et pris en charge, présence de deux clés étrangères), par exemple, le vacancier Raoul a réservé en 2013 dans l’hôtel Les mouettes en y prenant pension et en 2012 dans l’hôtel L’albatros sans y prendre pension. Mais la prise en compte du Ou exclusif reste en suspens.


2e ambiguïté relevée dans votre exercice

On ne sait pas a priori si le Ou exclusif porte à la fois sur les hôtels et les vacanciers ou seulement sur les hôtels ou seulement sur les vacanciers...

Si le sens de lecture conjecturé est le bon, alors le Ou exclusif porte seulement sur les hôtels, sinon le cas 6 devrait être coché « cas d’erreur » et Raoul ne pourrait pas réserver auprès de l’hôtel de l’Albatros puisqu’il aurait déjà réservé à l’hôtel des mouettes, bien que ce ne soit pas à la même date. La prise en compte du Ou exclusif reste en suspens : on regardera si un attribut TypeHebergement (comme ci-dessous) doublé d'une contrainte permet de d'en sortir, on verra ça plus tard.

Examinons le cas 11 :

C’est le miroir du cas 6, car au lieu d’avoir la configuration 1,N,1,N, on a N,1,N,1. Il est dit que c’est un cas possible, pris en charge et faisant l’objet d’une seule clé étrangère : c'est d'accord. Au niveau logique la représentation est la suivante :



Un hôtel héberge un (seul) vacancier et cela selon la valeur prise par l’attribut TypeHebergement : cette valeur peut être représentée par booléen (par exemple « vrai » pour « avec pension », « faux » pour « sans pension »). On confirme ainsi que le Ou exclusif ne s’applique qu’aux hôtels, tandis les vacanciers font ce qui leur chante.


Reprenons le cas 1 :

Jusqu’ici je n’ai pas fait mention des cardinalités minimales et à ce sujet je vous conseille de lire ce qu’à écrit CinePhil.

Supposons que ces cardinalités soient 1, comme les cardinalités maximales :

MCD :




MLD :




Selon votre exercice, c’est un cas possible, non pris en charge et embarrassant du point de vue des clés étrangères.

Remplaçons HOTEL et VACANCIER par X et Y, pour éviter la surcharge émotionnelle (si un hôtel ne peut accueillir qu’un vacancier et qu’un vacancier ne peut fréquenter qu’un seul hôtel, c’es quand même un peu restrictif...)

X et Y participent à une magnifique bijection et on observe la présence d’un cycle, chose propre à mettre en émoi une armée de concepteurs. En fait ce cycle peut être correctement pris en charge dans la mesure où on le traitre comme il doit l’être. Je veux dire par là que les clés étrangères ne peuvent pas remplir leur rôle, elles doivent disparaître. En effet, ces clés n’empêchent pas d’avoir la situation suivante (je reviens aux hôtels et aux vacanciers) :

Code :

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

1
2
3
4
5
6
Table HOTEL                                  Table VACANCIER

HotelId    VacancierId                       VacancierId    HotelId
-------    -----------                       -----------    -------
H1         V1                                V1             H2
H2         V2                                V2             H1

C'est-à-dire que si l’on en croit la table VACANCIER, le vacancier V1 fréquente l’hôtel H2, tandis que d’après la table HOTEL ce vacancier fréquente l’hôtel H1 : comme dit l’autre, faudrait savoir !

Bref, on doit se contenter d’une représentation sans clés étrangères :




Mais sous réserve de prévoir un filet, c'est-à-dire une contrainte (exprimée ici en D, conformément à la théorie relationnelle) :

Code D :

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

1
2
CONSTRAINT Cx
    HOTEL {HotelId, VacancierId} = VACANCIER {HotelId, VacancierId} ;

Autrement dit la projection de HOTEL sur les attributs {HotelId, VacancierId} doit être égale à la projection de VACANCIER sur ces mêmes attributs.

Je vous laisse le soin de déclarer l’assertion correspondante en SQL.

En tout cas, la case « clés étrangères dans l’entité la table » doit être décochée pour ce sous-cas (ou plutôt on doit y préciser qu’une contrainte prend le relais).

Par ailleurs, si une cardinalité minimale est à 0, on n’a plus affaire à une bijection mais à une injection et cette fois-ci la clé étrangère joue son rôle :



En plus, {HotelId} doit être clé alternative pour la table VACANCIER (cf. le mickey « ak »).

La case « clés étrangères dans la table » doit être cochée pour ce sous-cas et en plus, il faut préciser la présence de la clé alternative.

Si les deux cardinalités minimales sont à 0, on met en œuvre une table associative entre HOTEL et VACANCIER (revoyez à nouveau le billet de CinePhil) :



Vous noterez que {HotelId} est clé (primaire) de la table associative HOTEL_VACANCIER, tandis que {VacancierId} y est clé alternative, Ou exclusif oblige.

J'espère que vous commencez à décrypter l'exercice...

Je ne sais pas où vous l'avez pêché, mais il mérite manifestement d’être sérieusement revu, corrigé et complété...

A suivre.

[fsmrel]

Bonjour Sam,

La prise en compte du Ou exclusif reste en suspens : on regardera si un attribut TypeHebergement (comme ci-dessous) doublé d'une contrainte permet de d'en sortir, on verra ça plus tard.

Reprenons le schéma correspondant au cas n° 6 :



Où HotelAvecId et HotelSansId correspondent respectivement à une réservation auprès d’un hôtel qui prend ou non des pensionnaires.
On peut très bien avoir affaire à la situation suivante :

Code :

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

1
2
3
4
5
6
Table HOTEL                       Table VACANCIER

HotelId                           VacancierId    Nom        HotelSansId    HotelAvecId
-------                           -----------    -------    -----------    -----------
H1 (sans pension)                 V1             Fernand    H2             H1
H2 (avec pension)                 V2             Raoul      H1             H1

C'est-à-dire n’importe quoi : le vacancier V1 a effectué une réservation sans pension auprès de l’hôtel H2 qui ne prend que des pensionnaires, etc.

Pour éviter ce genre de situation, on peut définir pour la table HOTEL un attribut de type booléen, appelons-le TypeHebergement, et mettre en place une contrainte selon laquelle les valeurs figurant dans les colonnes HotelAvecId et HotelSansId doivent être compatibles avec le type d’hôtel défini par l’attribut TypeHebergement. La représentation est la suivante (tandis que la contrainte fera l’objet d’une assertion si on est en SQL, ou de triggers à défaut) :




Maintenant, si JPhi33, CinePhil ou Richard_35 et tous gens compétents passent par là, leur réaction sera peut-être celle d’Alexandre le Grand : il faut trancher dans le vif ! Autrement dit, procédons à une scissiparité de la table HOTEL, les « avec pension » d’un côté et les »sans » de l’autre, effectuons le vrai travail de modélisation au lieu de nous égarer dans de longues, pénibles et vaines réflexions. L’effet Ou exclusif est iimmédiat !



Bien sûr, le travail de modélisation est à poursuivre, il s’agit ici seulement de montrer la direction d’une évolution qui peut être intéressante.

En factorisant les données communes pour les hôtels (généralisation), tout en restant vigilant car Le Ou exclusif refait surface (mais est contrôlable) :



Bien entendu, le travail de modélisation n’est toujours pas achevé, car selon cette représentation, un vacancier est obligé de réserver pour un hôtel « sans » et un hôtel « avec ». En poursuivant le travail, on peut en arriver à la représentation suivante :

MCD (Notation Merise selon PowerAMC)



MLD




Le défi

Reprenons la table de décision qui vous est proposée :



Sur 16 situations, 13 sont à considérer comme devant donner lieu à erreur. C’est vite dit ! Ces 13 situations peuvent en effet correspondre à autant de cas fonctionnels légitimes, Ou exclusif ou pas.

Tout en notant que les clés étrangères n’ont rien à faire dans cette histoire, les « actions » doivent se résumer à ceci :




Voici quelques exemples de MLD possibles, à faire varier avec les cardinalités minimales.

Prenons le cas n° 2 :



Après modélisation, une possibilité :




Cas n° 3



Après modélisation :




Cas n° 4



Après modélisation :




Cas n° 16




Après modélisation :




Maintenant, si le schéma fourni au départ ne se lit pas comme je l’ai conjecturé, même pas grave, on recommencera sur d’autres bases !

[sammy22]

Bonjour fsmrel !

Merci beaucoup pour vos réponses !
Je dois dire que je ne m' attendais pas à ça..
Il me semble que j ai compris le fond de mon problème! Et vous y avez grandement contribué
Merci aussi pour les recommandations de lecture (spécialement le blog de CinéPhil
Vous avez raison l' exemple donné est plus que discutable.. Je vais continuer le travail de mon côté et je vous tiendrai informé de l' avancée de mes recherches ces prochaines semaines.

Merci au fait pour les Cours et tutoriels pour apprendre UML surtout celui la est bien : Cours apprendre UML 2.0 par Laurent Audibert


Sam

[Richard_35]

Bonjour Sammy22 et Fsmrel,

l'exemple donné est plus que discutable

==> tu me l'a enlevé du clavier () !



semble suffire (avec un contrôle de non-chevauchement des périodes en trigger).

Mais c'est vrai que, si le but est d'étudier le XOR, alors il faut complexifier l'exemple.

[fsmrel]

Bonjour Sam,

Je dois dire que je ne m' attendais pas à ça..

Il faut dire que le lascar qui a concocté l'exercice m'a particulièrement agacé : tout mélanger, être incomplet malgré les apparences, ne pas fournir de mode d'emploi, c'est du j'm'en-foutisme, tout ça pour aboutir à des conclusions fausses...

Comme dirait Richard, ça ne vaut pas un coup de cidre !

J'ai voulu démonter le machin, comme un gamin démonte un moteur de mobylette.

Enfin, l'essentiel est que vous ayez pu voir de quoi il en retournait.

Bon courage pour la suite de vos aventures chez les approximatifs piégeux, restez méfiante !