relation ternaire et dates

Version imprimable

05/10/2015, 12h36
jackherrer57

1 pièce(s) jointe(s)

relation ternaire et dates

Bonjour,
je dois établir une modélisation pour un stage.

voici l'analyse sémantique :
1 enseigne appartient à 1 groupe d’enseigne.
1 groupe d’enseigne comprend 1 ou plusieurs enseignes.

1 enseigne possède 0 ou plusieurs sous-groupes d’enseigne.
1 sous-groupe d’enseigne appartient à 1 groupe d’enseigne

Une promo est définie par un ensemble de critères qui sont réuni :

Une promo a 1 seul nom d’opération
Une promo concerne 1 ou plusieurs produits
Une produit peut etre 0 fois, 1 fois ou plusieurs fois en promo
Une promo détient 1 et 1 seul statut qui évolue dans le temps
Une promo commence à 1 date et termine à 1 date
Une promo s’applique sur 1 seule enseigne (national ) OU sur 1 sous-groupe d’enseigne ou périmètre ( régional, ou restreint )
Une promo contient 1 type de promo ( type d’opération : prospectus, carte, fidélité )

A la fin de la promotion, nous emettons 1 facture qui peut être réglé en plusieurs fois.
Il faut acquitter chaque règlement jusqu’à clôturer la facture

par rapport à ces définitions, j'etablis ce MCD :
Pièce jointe 189447

je voulais savoir comment gérer la relation entre la promo et l'enseigne ou le sous-groupe d'enseigne auxquelles la promo peut s'appliquer d'après la regle :
Une promo s’applique sur 1 seule enseigne (national ) OU sur 1 sous-groupe d’enseigne ou périmètre ( régional, ou restreint )

et enfin, est-ce que les dates sont des attributs propre à une classe d'entité? ou l'on doit les gérer autrement ( via une autre table ? )

Merci de votre aide.
05/10/2015, 15h12
fsmrel

Bonjour jackherrer57,

Votre ternaire « S’APPLIQUE » signifie ceci :

La promo « p1 » s’applique à la fois à l’enseigne « e1 » et au sous-groupe « sg1 », autrement dit il faut casser cette ternaire en deux binaires et mettre en œuvre une contrainte d’exclusion (X) et totalité (T) :

http://www.fsmwarden.com/developpez_...exclusions.png

A ce propos, voici ce que dit la « norme » (journée Afcet du 15 novembre 1990) :

http://www.fsmwarden.com/developpez_3/Exclusion.jpg

Le problème est qu’avec Power AMC, vous ne pouvez pas définir cette contrainte _:), alors que c’est possible avec WinDesign _:D. Au stade SQL, cette contrainte devra faire l’objet d’une assertion, en fait d’un trigger dans l’état des SGBDR à ce jour...
06/10/2015, 09h21
jackherrer57

bonjour fsmrel

merci pour cette réponse clair et précise.

par contre je ne comprend pas pourquoi vous rajoutez "totalité"?
dans ce cas j'aurais plutôt pensé à une contrainte de partition ( l'un ou l'autre mais pas les deux )

je corrige une erreur : entre 'promo' et 'regler': la cardinalité est de 1,1.

cordialement
06/10/2015, 19h43
fsmrel
Bonsoir jackherrer57,

Citation:

Envoyé par jackherrer57

par contre je ne comprend pas pourquoi vous rajoutez "totalité"?
dans ce cas j'aurais plutôt pensé à une contrainte de partition ( l'un ou l'autre mais pas les deux )

« XT » symbolise le OU exclusif donc le partitionnement. C’est le symbolisme utilisé par WinDesign et je l’ai repris ici, en observant par ailleurs que PowerAMC ne propose rien.

Quant à la prise en compte de la totalité, elle est la conséquence de la règle :

« Une promo s’applique au moins et au plus une fois à une entité »

Où « entité » est une enseigne ou un sous-groupe.

Je propose ce MCD pour la partie qui nous intéresse (j’ai identifié l’entité-type SOUS_GROUPE relativement à ENSEIGNE dans la mesure où je formule l’hypothèse qu’un sous-groupe ne peut pas changer d’enseigne, mais si j’ai faux, je rectifierai) :

http://www.fsmwarden.com/developpez_...usions_mcd.png

Et le MLD dérivé :

http://www.fsmwarden.com/developpez_...usions_mld.png

Dans le cadre de la théorie relationnelle, l’exclusion fait l’objet de la contrainte suivante :
```
CONSTRAINT CONS_X1 IS_EMPTY
    { PROMO_ENSEIGNE {PromoId} INTERSECT PROMO_SOUS_GROUPE {PromoId} }
```
De la même façon, la totalité fait l’objet de la contrainte :
```
CONSTRAINT CONS_T1 IS_NOT_EMPTY
    { PROMO_ENSEIGNE {PromoId} UNION PROMO_SOUS_GROUPE {PromoId} }
```
Dans le contexte de la norme SQL, l’exclusion et totalité font l’objet de l’instruction CREATE ASSERTION, laquelle peut laisser passer des erreurs en ce qui concerne la totalité, dans la mesure où les contrôles doivent être différés : entre le moment où l’on met à jour les tables concernées et le moment du contrôle, il peut se passer pas mal d’événements...

Quant aux SGBD SQL (lequel est le vôtre _{_:question:}), on est obligé d’en passer par des triggers, ce qui permet de garantir l’exclusion, mais pas la totalité...8O
07/10/2015, 09h34
jackherrer57

woouff:P , je m'incline.

C'est bien un OU exclusif avec 'au moins et au plus un'.
Et pour répondre aux autres question, en effet, un sous groupe ne changera pas d'entité et la base sera en mysql.

merci fsmrel pour votre aide et ces précisions chirurgicales.

A propos de l'exclusion

Bonjour jackherrer57,

Ci-joint un script SQL pour la partie étudiée :


CREATE TABLE ENSEIGNE
(
        EnseigneId              INT              NOT NULL
      , EnseigneNom             VARCHAR(32)      NOT NULL
    , CONSTRAINT ENSEIGNE_PK PRIMARY KEY (EnseigneId)       
) ;

CREATE TABLE SOUS_GROUPE
(
        EnseigneId              INT              NOT NULL
      , SousGroupeId            INT              NOT NULL        
      , SousGroupeNom           VARCHAR(32)      NOT NULL
    , CONSTRAINT SOUS_GROUPE_PK PRIMARY KEY (EnseigneId, SousGroupeId) 
    , CONSTRAINT SOUS_GROUPE_ENSEIGNE_FK FOREIGN KEY (EnseigneId) REFERENCES ENSEIGNE (EnseigneId)
) ;

CREATE TABLE PROMO
(
        PromoId                 INT              NOT NULL        
      , PromoNom                VARCHAR(48)      NOT NULL
      , PromoDebut              DATE             NOT NULL  DEFAULT '2015-10-01'            
      , PromoFin                DATE             NOT NULL  DEFAULT '2015-10-15' 
      , CONSTRAINT PROMO PRIMARY KEY (PromoId) 
) ;

CREATE TABLE PROMO_ENSEIGNE
(
        PromoId                 INT              NOT NULL        
      , EnseigneId              INT              NOT NULL
    , CONSTRAINT PROMO_ENSEIGNE_PK PRIMARY KEY (PromoId) 
    , CONSTRAINT PROMO_ENSEIGNE_PROMO_FK FOREIGN KEY (PromoId) REFERENCES PROMO (PromoId)
    , CONSTRAINT PROMO_ENSEIGNE_FK FOREIGN KEY (EnseigneId) REFERENCES ENSEIGNE (EnseigneId)
) ;

CREATE TABLE PROMO_SOUS_GROUPE
(
        PromoId                 INT              NOT NULL        
      , EnseigneId              INT              NOT NULL
      , SousGroupeId            INT              NOT NULL
    , CONSTRAINT PROMO_SOUS_GROUPE_PK PRIMARY KEY (PromoId)
    , CONSTRAINT PROMO_SOUS_GROUPE_PROMO_FK FOREIGN KEY (PromoId) REFERENCES PROMO (PromoId)     
    , CONSTRAINT PROMO_SOUS_GROUPE_FK FOREIGN KEY (EnseigneId, SousGroupeId) REFERENCES SOUS_GROUPE (EnseigneId, SousGroupeId)
) ;

Un bout de jeu d’essai :


INSERT INTO ENSEIGNE (EnseigneId, EnseigneNom) VALUES
    (1, 'enseigne 1'), (2, 'enseigne 2'),(3, 'enseigne 3'),(4, 'enseigne 4')
;
SELECT *  FROM ENSEIGNE ;   

INSERT INTO SOUS_GROUPE (EnseigneId, SousGroupeId, SousGroupeNom) VALUES
    (1, 1, 'enseigne 1, sous-groupe 1'), (1, 2, 'enseigne 1, sous-groupe 2'), (1, 3, 'enseigne 1, sous-groupe 3')
  , (2, 1, 'enseigne 2, sous-groupe 1'), (2, 2, 'enseigne 2, sous-groupe 2'), (2, 3, 'enseigne 2, sous-groupe 3')
  , (3, 1, 'enseigne 3, sous-groupe 1'), (3, 2, 'enseigne 3, sous-groupe 2'), (3, 3, 'enseigne 3, sous-groupe 3')
  , (4, 1, 'enseigne 4, sous-groupe 1'), (4, 2, 'enseigne 4, sous-groupe 2'), (4, 3, 'enseigne 4, sous-groupe 3')   
;

SELECT *  FROM SOUS_GROUPE ; 

INSERT INTO PROMO (PromoId, PromoNom) VALUES
    (1, 'promo 1, pour enseigne 1'), (2, 'promo 2, pour sous-groupe 1 de enseigne 3')
  , (3, 'promo 3, pour sous-groupe 1 de enseigne 4'), (4, 'promo 4, pour enseigne 1')
  , (5, 'promo 5, pour enseigne 1'), (6, 'promo 6, pour sous-groupe 3 de enseigne 1')
  , (7, 'promo 7, pour sous-groupe 3 de enseigne 1'), (8, 'promo 8, pour enseigne 3')    
  , (9, 'promo 9, pour enseigne 2'), (10, 'promo 10, pour sous-groupe 3 de enseigne 3')
  , (11, 'promo 11, pour sous-groupe 2 de enseigne 3'), (12, 'promo 12, pour enseigne 2')    
  , (13, 'promo 13, pour personne !')
;

SELECT *  FROM PROMO ;   

INSERT INTO PROMO_ENSEIGNE (PromoId, EnseigneId) VALUES
    (1, 1), (4, 1), (5, 1), (8, 1), (9, 2), (12, 2)
;
SELECT * FROM PROMO_ENSEIGNE ;

INSERT INTO PROMO_SOUS_GROUPE (PromoId, EnseigneId, SousGroupeId) VALUES
    (2, 3, 1), (3, 4, 1), (6, 1, 3), (7, 1, 3), (10, 3, 3), (11, 3, 2)
;

INSERT INTO PROMO_SOUS_GROUPE (PromoId, EnseigneId, SousGroupeId) VALUES
    (1, 1, 1)  -- délinquant !
;
INSERT INTO PROMO_ENSEIGNE (PromoId, EnseigneId) VALUES
    (2, 1)  -- délinquant !
;

Les triggers ci-dessous permettent de contrôler l’exclusion en INSERT (il faudrait coder les triggers correspondant aux UPDATE...)


CREATE TRIGGER PromoEnseigeExclusionBeforeInsert BEFORE INSERT ON PROMO_ENSEIGNE 
FOR EACH ROW
    BEGIN
         SET @K = (SELECT COUNT(*) 
                   FROM PROMO_SOUS_GROUPE 
                   WHERE PromoId = new.PromoId);
        IF @K > 0 THEN

            SET @ens = (SELECT EnseigneNom 
                        FROM   ENSEIGNE
                        WHERE  EnseigneId = new.EnseigneId) ;

            SET @sg = (SELECT y.SousGroupeNom 
                       FROM   PROMO_SOUS_GROUPE AS x JOIN SOUS_GROUPE AS y ON x.EnseigneId = y.EnseigneId AND x.SousGroupeId = y.SousGroupeId
                       WHERE  x.PromoId = new.PromoId) ;

                    SET @Erreur = CONCAT ('La promo d''identifiant  ''', new.PromoId, '''  pour l''enseigne <', @ens, '> est déjà affectée au sous-groupe <', @sg, '>.') ;
                    SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
        END IF ;

    END 
GO 

CREATE TRIGGER PromoSousGroupeExclusionBeforeInsert BEFORE INSERT ON PROMO_SOUS_GROUPE 
FOR EACH ROW
    BEGIN
         SET @K = (SELECT COUNT(*) 
                   FROM PROMO_ENSEIGNE 
                   WHERE PromoId = new.PromoId);
        IF @K > 0 THEN

            SET @sg = (SELECT SousGroupeNom 
                       FROM   SOUS_GROUPE
                       WHERE  EnseigneId = new.EnseigneId AND SousGroupeId = new.SousGroupeId) ;
                         
            SET @ens = (SELECT y.EnseigneNom 
                        FROM   PROMO_ENSEIGNE AS x JOIN ENSEIGNE AS y ON x.EnseigneId = y.EnseigneId
                       WHERE  x.PromoId = new.PromoId) ;

                   SET @Erreur = CONCAT ('La promo d''identifiant  ''', new.PromoId, '''  pour le sous-groupe   <', @sg, '> est déjà affectée à l''enseigne <', @ens, '>.') ;
                   SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
        END IF ;

    END 
GO

En passant, si telle ou telle réponse vous a été utile, n’hésitez pas à voter... Voire cliquer sur fsmrel, puis « Voir le profil Pro », puis « Confirmer les compétences » si vous jugez que quelque compétence il y a. La reconnaissance ça fait toujours plaisir...;)

07/10/2015, 16h17
jackherrer57

merci merci, je n'en demandais pas tant, j'ai plus grand chose a faire du coup:ptdr:

compétences confirmés, plus fort et plus complet que mon ancien prof de merise.
Merci beaucoup encore
07/10/2015, 23h05
fsmrel
Bonsoir jackherrer57,

Citation:

Envoyé par jackherrer57

j'ai plus grand chose a faire du coup _:ptdr:

Faut pas pleurer Jack, il y a encore du grain à moudre... Ne pensez-vous pas qu'il faudrait automatiser certains contrôles supplémentaires ? Que penser de cette instruction, laquelle passe allègremement au travers des mailles du filet ? _:whistle:
```
INSERT INTO PROMO (PromoId, PromoNom, PromoDebut, PromoFin) VALUES
    (14, 'promo 14', '2015-11-01', '2015-10-25') ;
```
En tout cas, merci pour les votes _;) (Et peut-être aurez-vous encore la force de lever le pouce vert ?)
08/10/2015, 10h27
jackherrer57

bonjour fsmrel,

j'ai vu votre piege : date_fin < date_debut
je dirais une contrainte de verification avec CHECK :

CREATE TABLE PROMO
(
PromoId INT NOT NULL
, PromoNom VARCHAR(48) NOT NULL
, PromoDebut DATE NOT NULL
, PromoFin DATE NOT NULL
, CONSTRAINT PROMO PRIMARY KEY (PromoId)
, CONSTRAINTE check_dates CHECK PromoDebut < PromoFin )

) ;
08/10/2015, 14h26
fsmrel

Bonjour jackherrer57,

Citation:

Envoyé par jackherrer57

je dirais une contrainte de vérification avec CHECK

Bon réflexe. Avec les SGBD habituels, c’est ce qu’il faut faire. Mais, à ce jour, avec MySQL, il y a un comme un problème, car il est écrit :

« The CHECK clause is parsed but ignored by all storage engines »

Le filet est donc troué à cet endroit précis... 8O

=> Deux petits triggers (un pour INSERT, l'autre pour UPDATE) ? :P
09/10/2015, 10h30
jackherrer57

bonjour fsmerel

Citation:

Envoyé par fsmrel

Bonjour jackherrer57,

=> Deux petits triggers (un pour INSERT, l'autre pour UPDATE) ? :P

là je ne vous suis pas.

Et j'ai une autre question, si je puis abuser encore de votre temps :

on m'ajoute un élément important, là je suis perdu :

chaque promo est donc stocké et validé, on ne retouche plus.
Par contre, à des fins prévisionnel ou de simulations, il faudrait pouvoir sélectionner n promo, pouvoir modifier certain champs mais ne pas les intégrer dans la base. :calim2:

Je me suis dit qu'il suffirait de dupliquer ces promo, de rajouter un attribut pour les distinguer des autres enregistrements.

Mais cela va à l'encontre de ce que j'ai appris en BDD : on ne duplique pas de donnée dans une base ? est-ce une règle immuable, ou un tel cas peut faire exception? ou cela doit se faire d'une autre façon ? 8O
09/10/2015, 15h46
fsmrel

On ne duplique pas, on spécialise...
Bonjour jackherrer57,

Citation:

Envoyé par jackherrer57

là je ne vous suis pas.

Puisque MySQL ne permet pas de garantir la contrainte PromoDebut < PromoFin au moyen de la clause CHECK (PromoDebut < PromoFin), soit on passe par des triggers, soit— comme dans du temps des SGBD de 2e génération — on contrôle applicativement.

Il est évident qu’on va plutôt se rabattre sur des triggers, car on sait que le SGBD ne laissera jamais passer une violation de la contrainte.

Pourquoi deux triggers ? Parce que contrairement à d’autres SGBD tels que SQL Server, MySQL ne permet pas de se contenter d’un seul trigger à la fois pour les inserts et les updates.

Il faut donc deux triggers, un pour les inserts et un pour les updates, même si leur contenu est le même :
```
CREATE TRIGGER PromoCoherenceDatesInsert BEFORE INSERT ON PROMO 
FOR EACH ROW
    BEGIN
        IF new.PromoFin <= new.PromoDebut THEN
            SET @Erreur = CONCAT ('Promo d''identifiant  ''', new.PromoId, ''' : tentative d''insert avec date de fin ''', new.PromoFin, '''  <= date de début de promo ''', new.PromoDebut, '''.') ;
            SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
        END IF ;
    END 
GO

CREATE TRIGGER PromoCoherenceDatesUpdate BEFORE UPDATE ON PROMO 
FOR EACH ROW
    BEGIN
        IF new.PromoFin <= new.PromoDebut THEN
            SET @Erreur = CONCAT ('Promo d''identifiant  ''', new.PromoId, ''' : tentative d''update avec date de fin ''', new.PromoFin, '''  <= date de début de promo ''', new.PromoDebut, '''.') ;
            SIGNAL SQLSTATE '45001' SET MESSAGE_TEXT = @Erreur ;
        END IF ;
    END 
GO
```
Citation:

Envoyé par jackherrer57

chaque promo est donc stocké et validé, on ne retouche plus.
Par contre, à des fins prévisionnel ou de simulations, il faudrait pouvoir sélectionner n promo, pouvoir modifier certain champs mais ne pas les intégrer dans la base.
Je me suis dit qu'il suffirait de dupliquer ces promo, de rajouter un attribut pour les distinguer des autres enregistrements.

Ce je comprends pour le moment : ajouter dans l’en-tête de l’entité-type PROMO un attribut pour un attribut pouvant faire l’objet d’une simulation. A mon sens, il est préférable d’externaliser cet attribut supplémentaire, le but étant de ne pas polluer la table PROMO avec des données de simulation.

Techniquement, on peut passer par la spécialisation : si l’utilisateur a besoin de faire une simulation portant sur une période de promo, on définit un entité-type PROMO_SIMUL_PERIODE, sous-type de l’entité-type PROMO. Si l’utilisateur a besoin de faire une simulation impliquant l’attribut PromoTruc, on définit un entité-type PROMO_SIMUL_TRUC, sous-type elle aussi de l’entité-type PROMO. Même principe pour les autres attributs de PROMO pour lesquels l’utilisateur a besoin de faire une simulation.

MCD

http://www.fsmwarden.com/developpez_..._simul_mcd.png

MLD

http://www.fsmwarden.com/developpez_..._simul_mld.png
09/10/2015, 16h07
jackherrer57

créer une entité-type pour chaque attribut en gros?
ce que j'ai omis c'est que la table promo contient environ 20 champs, peut etre meme plus.
mais je pense que ca ne pose pas de probleme.
09/10/2015, 17h14
fsmrel

Citation:

Envoyé par jackherrer57

créer une entité-type pour chaque attribut en gros?
Ce que j'ai omis c'est que la table promo contient environ 20 champs, peut-être même plus.

Les attributs ne sont peut-être pas tous concernés ? Par exemple, je vois mal le nom de la promo faire l’objet d’une simulation. De toute façon, plutôt que de définir a priori un sous-type par attribut de la table PROMO, vous pouvez le faire au fur et à mesure des besoins de l’utilisateur.

Par ailleurs, si l’utilisateur a besoin de simuler des données pour lesquelles il n’y a pas d’attribut dans la table PROMO, il pourra le faire. Exemple d’un hypothétique attribut PromoBidule :

http://www.fsmwarden.com/developpez_...bidule_mcd.png

Citation:

Envoyé par jackherrer57

Mais je pense que ca ne pose pas de problème.

Moi non plus _:D. J’ai modélisé des bases de données de l’ordre de 2000 tables, avec très grand soin certes, mais sans problèmes liés à cette volumétrie dans le contexte de la production.
12/10/2015, 09h13
jackherrer57

bonjour fsmrel

je vois.
par contre si je veux faire une liaison 0,n entre promo et ses "enfants" promo_simu je devrais rajouter un champ d'index pour faire une clef primaire en couple avec l'id_promo sur chaque "enfant".

merci pour la piste. Je pense que c'est ce qu'il y a de plus judicieux pour respecter les règles.
12/10/2015, 17h06
fsmrel

Identification relative
Bonjour jackherrer57,

Citation:

Envoyé par jackherrer57

si je veux faire une liaison 0,n entre promo et ses "enfants" je devrais rajouter une clef primaire sur chaque "enfant".

Il est un fait que la spécialisation de l’entité-type PROMO fait que les cardinalités portées par l’associations entre PROMO, considérée comme surtype, et chaque sous-type PROMO_SIMUL_XXX, ne sont pas 0,N mais bien 0,1. Du fait du passage à 0,N, d’un point de vue sémantique, PROMO_SIMUL_XXX devient plutôt une propriété multivaluée de PROMO, c’est une entité-type faible (weak entity-type) qui ne vit que par sa « mère » : si une promo disparaît, ses « enfants » disparaissent de facto. Par analogie, PROMO_SIMUL_XXX est à PROMO ce que LIGNE_FACTURE (ligne de facture) est à FACTURE. Dans ces conditions, vous pouvez utiliser l’identification relative : L’attribut PromoId fait partie de l’identifiant de PROMO_SIMUL_XXX, mais accompagné d’un séquenceur « relatif », dont les valeurs repartent à 1 pour chaque simulation. Exemple avec PROMO_SIMUL_BIDULE :
```
PromoId    PromoBiduleId    PromoBidule
-------    -------------    -----------
      1                1    bidule 11
      1                2    bidule 12
      1                3    bidule 13
      1                4    bidule 14

      2                1    bidule 21
      2                2    bidule 22
      2                3    bidule 23
      2                4    bidule 24
```
D’où le code SQL (notez le ON DELETE CASCADE présent dans la 2e instruction CREATE TABLE) :
```
CREATE TABLE PROMO
(
        PromoId                 INT              NOT NULL
      , PromoNom                VARCHAR(48)      NOT NULL
      , PromoDebut              DATE             NOT NULL  DEFAULT '2015-10-01'
      , PromoFin                DATE             NOT NULL  DEFAULT '2015-10-15' 
      , CONSTRAINT PROMO_PK PRIMARY KEY (PromoId)
) ;

CREATE TABLE PROMO_SIMUL_BIDULE
(
       PromoId                  INT              NOT NULL
     , PromoBiduleId            INT              NOT NULL
     , PromoBidule              VARCHAR(64)      NOT NULL
    , CONSTRAINT PROMO_SIMUL_BIDULE_PK PRIMARY KEY (PromoId, PromoBiduleId)
    , CONSTRAINT PROMO_SIMUL_BIDULE_PROMO_FK FOREIGN KEY (PromoId)
          REFERENCES PROMO (PromoId) ON DELETE CASCADE
) ;
```
Même principe pour toutes les tables PROMO_SIMUL_XXX.

En remontant au MLD :

http://www.fsmwarden.com/developpez_...s_weak.mld.png

Puis au MCD :

http://www.fsmwarden.com/developpez_...s_weak.mcd.png

La mise entre parenthèses des cardinalités 1,1 est le moyen utilisé par PowerAMC pour symboliser l’identification relative.

Accessoirement :

Citation:

Envoyé par fsmrel

« XT » symbolise le OU exclusif donc le partitionnement.

Ce qui se traduit ainsi selon le formalisme cher à Pierre Dac in Essais, Maximes, Conférences :

Citation:

Envoyé par Pierre Dac

Le monde des uns n’est pas celui des autres, bien que le monde des uns et des autres soit le monde de tout le monde.

Sic locutus est Petrus.
16/10/2015, 09h52
jackherrer57

très belle citation !

..je la note. c'est tellement vrai

Tres bien fsmrel, je peux mettre le sujet en "résolu"

en vous remercient pour votre implication. :P;)