Discussion :

[zoltix]

Bonjour,
Etant débutant dans PowerDesigner pour faire le design d’une db déjà existante.
Je n’arrive pas à représenter une liaison entre deux entité/table.
J’ai la table A avec les colonnes col1, col2, col3
Et la table B avec les colonnes col1,

La liaison entre les tables est B.col1 = A.col1+ A.col2+ A.col3.

Comme faire faire pour représenter ceci dans PowerDesigner 15 dans un Physical DataModel

Cette liaison n’est peut être pas bonne mais elle est est existante et je dois la représenter.

Merci d'avance

[fsmrel]

Qu'entendez-vous par "B.col1 = A.col1+ A.col2+ A.col3" ?

"+" représente-t-il pour vous l'opérateur de concaténation ?

Merci de joindre les instructions CREATE TABLE ou de donner des exemples concrets de valeurs pour ces colonnes dans les deux tables.

[zoltix]

Ce signe + est bien le signe de la concaténation.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
Create table tbl_Position (cFamille char(4), cCat char(4), cSubCat char(4),cRef char(4), fData_1 Float,  vcData_2 varchar(20) )
/* Clef primaire  Famille SubCat Float*/

Create table tbl_Description_Group (ID_cGroup char(12), vcData_2 varchar(30) )
/* Clef primaire  Famille SubCat Float*/


insert into	  tbl_Position (cFamille , cCat , cSubCat,cRef    , fData_1 ,  vcData_2)
				     values( 'fAAA'  ,'cAAA', 'sAAA' ,'T1',  2.2     , 'AAAqsdfqsdf')

insert into	  tbl_Position (cFamille , cCat , cSubCat,cRef    , fData_1 ,  vcData_2)
				     values( 'fBBB'  ,'cBBB', 'sBBB' ,'T2',  3.2     , 'BBBqsdfqsdf')

insert into	  tbl_Position (cFamille , cCat , cSubCat,cRef    , fData_1 ,  vcData_2)
				     values( 'fCCC'  ,'cCCC', 'sCCC' ,'T3',  4.2     , 'CCCqsdfqsdf')				     



insert into	  tbl_Description_Group (ID_cGroup , vcData_2)
				     values( 'fAAA'+'cAAA'+ 'sAAA' ,  'AAAqsdfqsdf')
insert into	  tbl_Description_Group (ID_cGroup , vcData_2)
					          values( 'fBBB'+'cBBB'+ 'sBBB' ,  'BBBqsdfqsdf')
					          
insert into	  tbl_Description_Group (ID_cGroup , vcData_2)
values( 'fCCC'+'cCCC'+ 'sCCC' ,  'CCCqsdfqsdf')
					          





/* */
select * 
from  tbl_Position Pos  inner join  tbl_Description_Group Desc_ 
     on   Pos.cFamille +   Pos.cCat +Pos.cSubCat  = Desc_.ID_cGroup

tbl_Position Pos inner join tbl_Description_Group Desc_
on Pos.cFamille + Pos.cCat +Pos.cSubCat = Desc_.ID_cGroup



Comment représenter ce type de liaison dans powerDesigner ?

Merci d'avance

[fsmrel]

Bonjour zoltix,

A juste titre, PowerDesigner ne permet pas de faire de la rétroconception à partir des structures que vous utilisez (et cela vaut pour tout autre AGL). Pour établir une relation entre les deux tables, si la table tbl_Position comporte le triplet d’attributs {cFamille, cCat, cSubCat}, alors la table tbl_Description_Group doit comporter elle aussi ce triplet, sous la même forme et non pas sous la forme du singleton {ID_cGroup} qui en est la concaténation. Vous devrez « déplier » la table tbl_Description_Group en éclatant l’attribut ID_cGroup en trois attributs...

Si cela vous est interdit, alors pas de rétroconception possible, et tout est à reprendre à zéro, à la main. Et n’oubliez pas les clés étrangères car elles servent à garantir la cohérence entre les tables.

Une question : les deux tables se ressemblent fortement : tbl_Description_Group est-elle un sous-ensemble de tbl_Position ? tbl_Description_Group peut-elle avoir des valeurs {cFamille, cCat, cSubCat} qui n’existent pas dans tbl_Position ? Bref, qu’est-ce qui justifie son existence ?

Au passage, vos tables ne sont pas des tables, mais des sacs. En effet, une table est un ensemble (au sens de la théorie des ensembles), c'est-à-dire que ses éléments (les lignes de la table) ne peuvent exister en double, et la façon de s’en assurer est de déclarer une clé primaire.

Commençons par réécrire de façon lisible votre instruction de création de la prétendue table tbl_Position.

Code SQL :

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

1
2
3
4
5
6
7
8
9
Create table tbl_Position 
(
    cFamille    char(4), 
    cCat        char(4), 
    cSubCat     char(4),
    cRef        char(4), 
    fData_1     Float,  
    vcData_2    varchar(20) 
) ;

Pour que tbl_Position mérite le label « table », il est nécessaire d’en déclarer la clé primaire, c'est-à-dire un sous-ensemble K (non strict) des attributs de tbl_Position, qui vérifie la double condition :

Unicité. Deux lignes distinctes de tbl_Position ne peuvent avoir même valeur de K.

Irréductibilité (ou minimalité). Il n’existe pas de sous-ensemble strict de K garantissant la règle d’unicité.

Par exemple, si les lignes suivantes sont illégales, c'est-à-dire si le triplet de valeurs {fAAA, cAAA, sAAA} ne peut pas figurer deux fois dans la table, alors le triplet d’attributs {cFamille, cCat, cSubCat} vérifie la condition n’unicité des clés primaires (soulignées) :

Code :

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

1
2
3
( cFamille, cCat, cSubCat, cRef, fData_1, vcData_2 )
    fAAA    cAAA   sAAA     c1    f1        v1
    fAAA    cAAA   sAAA     c2    f2        v2        /* illégal */

Mais si les lignes suivantes sont illégales, c'est-à-dire si la paire de valeurs {fAAA, cAAA} ne peut pas figurer deux fois, alors la paire d’attributs {cFamille, cCat} vérifie la condition n’unicité des clés primaires et donc le triplet {cFamille, cCat, cSubCat} est réductible et ne peut pas être clé primaire :

Code :

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

1
2
3
( cFamille, cCat, cSubCat, cRef, fData_1, vcData_2 )
    fAAA    cAAA   sAAA     c1    f1        v1
    fAAA    cAAA   sAAZ     c2    f2        v2        /* illégal */

Considérons néanmoins l’hypothèse selon laquelle le triplet {cFamille, cCat, cSubCat} n’est pas réductible et peut donc être déclaré clé primaire. Du point de vue du SGBD, on écrit :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
Create table tbl_Position 
(
    cFamille    char(4), 
    cCat        char(4), 
    cSubCat     char(4),
    cRef        char(4), 
    fData_1     Float,  
    vcData_2    varchar(20),
  Primary Key (cFamille, cCat, cSubCat)
) ;

Même principe pour la table tbl_Description_Group, après éclatement de l’attribut ID_cGroup :

Code SQL :

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

1
2
3
4
5
6
7
8
Create table tbl_Description_Group
(
    cFamille    char(4), 
    cCat        char(4), 
    cSubCat     char(4),
    vcData_2    varchar(30),
  Primary Key (cFamille, cCat, cSubCat)
) ;

[zoltix]

Je sais que vous avez raison car c'est ce que je pense aussi, je ne peux pas changer ce qui existe dejà , mais mon souci c'est comment dois je faire dans PowerDesigner pour le signaler malgré cette incohérence.

Merci d'avance

Par hasard Vous ne savez pas comment je dois faire dans un MCD pour schématiser Contraintes d'exclusion / totalité / inclusion
comme dans l'image les trucs qui sont en jaune....

[fsmrel]

Bonsoir,

mon souci c'est comment dois je faire dans PowerDesigner pour le signaler malgré cette incohérence

S’il s’agit d’exprimer que l’attribut ID_cGroup de la table tbl_Description_Group est une concaténation des attributs cFamille, cCat, cSubCat je ne vois pas comment le faire comprendre à PowerDesigner, puisque cette concaténation est une bidouille ponctuelle invalide au plan de la modélisation. Je répète qu’il faut en revenir à une structure saine, comme je vous l’ai expliqué précédemment. A vos interlocuteurs de comprendre et de prendre leurs responsabilités.

Par hasard Vous ne savez pas comment je dois faire dans un MCD pour schématiser Contraintes d'exclusion / totalité / inclusion comme dans l'image les trucs qui sont en jaune...

Ces contraintes relèvent de Merise/2 et sont disponibles avec Win'Design. Concernant la contrainte de partitionnement (XT) dans la spécialisation de l’entité-type ARTICLE, vous avez l’équivalent dans Power AMC (pour PowerDesigner, à vous de vérifier). Voyez la spécialisation de l’entité-type PERSONNE dans la discussion avec heledir.

Concernant la contrainte d’inclusion entre les associations-types STOCKÉ DANS et RÉSERVATION, dans le cas de Power AMC vous pouvez quitter le mode Merise pour utiliser le mode Entité/Relation et en faire des entités-types associatives. En mode Merise, vous pouvez aussi transformer les associations-types en entités-types, quitte à ce que la sémantique en prenne un petit coup.

Concernant la contrainte d’exclusion entre les associations-types PASSÉ PAR et FACTURÉ A AUTRE, vous serez obligé de développez un trigger au niveau SQL (cela dit, rien ne vous empêche de dessiner la contrainte dans le MCD, histoire d'attirer l'oeil).

[zoltix]

Grand merci pour ton aide .........

Je vais essayer

[fsmrel]

Si on peut faire quelque chose, n'hésitez pas à poser vos questions.
Sinon, combien y a-t-il de tables ? Quelle est la volumétrie ? Le SGBD ?

[zoltix]

Si on peut faire quelque chose, n'hésitez pas à poser vos questions.
Sinon, combien y a-t-il de tables ? Quelle est la volumétrie ? Le SGBD ?

On a +- 200 tables qui sont regroupé par sujet de +- 10 a 20 tables

Avec un système de table de définition.....

Pour faire cours:
En fait on fait des enquêtes dans le monde entier chanque equête est composé de +- 2000 questions regroupées en catégories(Métier, Adresse, Voiture façon de vivre, taxe, assurance....) . Chaque pays a ses particularités: Taxe en France de 19%, en Belgique 21%...Sexe(dans certain pays sont des données confidentielle)..Taxe sur certain produits et pas d'autres.....Il y a des tonnes de différences.

Et bien sur une série de tables communes a tout le monde(code pays, ....).


Donc on a un dictionnaire pour définir tout ca, qui nous indique sa définition, la façon accéder a la donnée(Table_1,2 ....N ), comment l'utiliser(unité, précision).

Donc on un disctionnaire(MetaData) et une série de tables containers qui peuvent contenir toutes les infos qui sont recueillent par nos enquêtes.

Il y a 6 ans que j'ai fait ce projet, mais je pense qu'on a besoin de medernisation. C'est la raison que je m'intéresse très fort a la modélisation UML malgré que certaine personnes trouvent que c'est une perte de temps.

La taille de la Db actuelle dépasse 250 GigB et on recueille par année plus +- 20-30 millions d'individu par ans.... Et optimisé pour travailler avec un calculateur qui est un serveur SAS.

Encore merci de pouvoir nous aider a accomplir notre projet car actuellement avec la crise on doit de plus en plus se débrouiller seul.

A+

[fsmrel]

Bonsoir,

Il y a 6 ans que j'ai fait ce projet, mais je pense qu'on a besoin de modernisation. C'est la raison que je m'intéresse très fort a la modélisation UML malgré que certaine personnes trouvent que c'est une perte de temps.

Produire un diagramme de classes UML ou un MCD ne sera pas une perte de temps, seuls les ignorants pourraient le prétendre. Faites-le, ne serait-ce que pour avoir une vision claire de votre univers du discours (votre système d’information conceptualisé) et faire l'état des lieux, pouvoir juger de l’ampleur des maladresses et erreurs du genre de celle que vous avez signalée dans votre premier message et qui polluent l’existant.

Certains sont ici à même de vous aider, peut-être pas pour deux cents entités-types, mais au moins pour les fondamentaux et certains points qui peuvent paraître délicats. Je vous conseille de proposer un début de MCD sur le forum Schéma, et n'oubliez surtout pas les énoncés des règles de gestion des données, rédigés de façon claire, complète et non ambiguë.

Soyez patient, en cette saison estivale tout le monde n’a peut-être pas les yeux rivés sur son écran...

[xav463fr]

salut fsmrel,

je suis dubitatif quant à la notion d'exclusion, et je suis d'autan interressé car j'en ai quelques unes à mettre en oeuvre dans mon model.
Tu nous ecris qu'il faudra en passer par les trigger et SQL.
Pourrais-tu m'expliquer comment rédiger le ou les trigger pour faire l'exclusion entre les associations-types PASSÉ PAR et FACTURÉ A AUTRE.
Ou me conseil un fil qui illustre cet application.

Merci

[fsmrel]

Bonsoir,

comment rédiger le ou les trigger pour faire l'exclusion entre les associations-types PASSÉ PAR et FACTURÉ A AUTRE.

Considérons donc la partie concernée du MCD :





Le SGBD dont je me sers ici est SQL Server 2005. Pour un autre SGBD, il faudra au besoin aménager le code.

Lors du passage au MLD, si on n’a pas d’état d’âme en ce qui concerne le bonhomme NULL, la table COMMANDE comportera deux clés étrangères en relation avec la table CLIENT, la 1re traduisant l’association-type Passé par (que je renomme PASSER pour la suite), la 2e traduisant l’association-type Facturé à autre (que je renomme REGLER).

A quelques attributs près qui ne nous intéressent pas pour la suite, le code SQL de création des tables est le suivant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
CREATE TABLE CLIENT
(
     ClientId      CHAR(03)       NOT NULL
   , ClientNom     VARCHAR(32)    NOT NULL
 , CONSTRAINT CLIENT_PK PRIMARY KEY (ClientId) 
) ;
CREATE TABLE COMMANDE
(
     CommandeId    CHAR(03)       NOT NULL
   , CommandeDate  CHAR(03)       NOT NULL
   , ClientPasse   CHAR(03)       NOT NULL 
   , ClientPaye    CHAR(03)       
 , CONSTRAINT COMMANDE_PK PRIMARY KEY (CommandeId) 
 , CONSTRAINT COMMANDE_PASSER_FK FOREIGN KEY (ClientPasse)
         REFERENCES CLIENT (ClientId)
 , CONSTRAINT COMMANDE_PAYER_FK FOREIGN KEY (ClientPaye)
         REFERENCES CLIENT (ClientId)
/* Le client qui règle ne peut pas être celui qui passe la commande */
 , CONSTRAINT COMMANDE_EXCLUSION CHECK (ClientPasse <> ClientPaye)
);

Pour garantir la contrainte d’exclusion, aucune difficulté : il a suffi de définir la contrainte suivante, attachée à la table COMMANDE :

CONSTRAINT COMMANDE_EXCLUSION CHECK (ClientPasse <> ClientPaye)

Comme la présence du bonhomme NULL me donne des boutons, j’utiliserai un MLD différent du précédent : l’association-type REGLER est dérivée sous forme d’une table. Le code SQL de création des tables est le suivant :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
CREATE TABLE CLIENT
(
     ClientId      CHAR(03)       NOT NULL
   , ClientNom     VARCHAR(32)    NOT NULL
 , CONSTRAINT CLIENT_PK PRIMARY KEY (ClientId) 
) ;
CREATE TABLE COMMANDE
(
     CommandeId    CHAR(03)       NOT NULL
   , CommandeDate  CHAR(03)       NOT NULL
   , ClientPasse   CHAR(03)       NOT NULL 
 , CONSTRAINT COMMANDE_PK PRIMARY KEY (CommandeId) 
 , CONSTRAINT COMMANDE_PASSER_FK FOREIGN KEY (ClientPasse)
         REFERENCES CLIENT (ClientId)
) ;
CREATE TABLE REGLER
(
     CommandeId    CHAR(03)       NOT NULL
   , ClientId      CHAR(03)       NOT NULL
 , CONSTRAINT REGLER_PK PRIMARY KEY (CommandeId) 
 , CONSTRAINT REGLER_COMMANDE_FK FOREIGN KEY (CommandeId)
         REFERENCES COMMANDE (CommandeId)
 , CONSTRAINT REGLER_CLIENT_FK FOREIGN KEY (ClientId)
         REFERENCES CLIENT (ClientId)
) ;

Mais cette fois-ci, il faut en passer par des triggers.

Informellement, la contrainte que l’on veut vérifier est la suivante :

Si un client a passé une commande, ça n’est pas lui qui la règle. Autrement, si l’on insère une ligne dans la table REGLER (sachant que forcément on connaît déjà le client passant la commande), il suffit de s’assurer que le résultat de la requête suivante est vide au moment de l’ajout :

Code SQL :

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

1
2
3
4
    SELECT   ''
    FROM     REGLER AS x JOIN COMMANDE AS y
               ON   x.CommandeId = y.CommandeId
               AND  x.ClientId = y.ClientPasse

Comme on utilise un trigger, SQL Server fournit le contenu exact de la ligne (voire d’un ensemble de lignes en cas d’insert de masse) à insérer dans la table REGLER. Ce contenu est installé dans une table de service dont le nom est dénué de toute poésie : INSERTED. Il y a aura donc viol de la contrainte d’exclusion si le client qui règle la commande et qui figure dans la table INSERTED est celui qui figure dans la table COMMANDE pour cette commande. Autrement dit, il y a viol si le résultat de la requête qui suit n’est pas vide :

Code SQL :

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

1
2
3
4
    SELECT   ''
    FROM     INSERTED AS x JOIN COMMANDE AS y
               ON   x.CommandeId = y.CommandeId
               AND  x.ClientId = y.ClientPasse

Pour savoir si le résultat est vide ou non, on exploite le contenu d’une variable appelée @@Rowcount et qui fournit le nombre de lignes satisfaisant à la requête.

Une définition d'un trigger attaché à la table REGLER et dédié à l'INSERT peut être la suivante :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TRIGGER REGLER_TRIGGER_INSERT ON REGLER INSTEAD OF INSERT AS
 
    SELECT   '' 
    FROM     INSERTED AS x JOIN COMMANDE AS y
               ON   x.CommandeId = y.CommandeId
               AND  x.ClientId = y.ClientPasse 
 
    IF @@Rowcount > 0
       BEGIN 
           Raiserror ('Insert dans table REGLER : Contrainte d''exclusion non respectée !',16,1) 
       RETURN
    END
 
    INSERT INTO REGLER 
        SELECT CommandeId, ClientId
        FROM   INSERTED ;

A noter que si le viol est constaté, après avoir injurié, on dégage (instruction RETURN). En revanche, si tout est correct, on insère le contenu de la table INSERTED dans la table REGLER.

Une définition d'un trigger attaché à la table REGLER et dédié à l'UPDATE peut être la suivante (à noter quon s'interdit de modifier la clé primaire) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CREATE TRIGGER REGLER_TRIGGER_UPDATE ON REGLER INSTEAD OF UPDATE AS
 
    SELECT   '' 
    FROM     INSERTED AS x JOIN COMMANDE AS y
               ON   x.CommandeId = y.CommandeId
               AND  x.ClientId = y.ClientPasse 
 
    IF @@Rowcount > 0
       BEGIN 
           Raiserror ('Update table REGLER : Contrainte d''exclusion non respectée !',16,1) 
       RETURN
    END
 
    IF UPDATE(ClientId)
        BEGIN
            UPDATE REGLER
               SET    ClientId = (SELECT ClientId FROM INSERTED)
               WHERE  EXISTS (SELECT * 
                              FROM   INSERTED
                              WHERE  INSERTED.CommandeId = REGLER.CommandeId)      
        END

Mais il reste des failles. Par exemple, quid si dans la table COMMANDE, on modifie le client qui a passé commande ? En effet, on pourrait malencontreusement retrouver celui qui a réglé.

Pour garantir la contrainte d’exclusion, il faut donc attacher un trigger à la table COMMANDE, dans le but de surveiller les modifications dont elle fait l’objet (à noter quon s'interdit de modifier la clé primaire) :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
CREATE TRIGGER COMMANDE_TRIGGER ON COMMANDE INSTEAD OF UPDATE 
  AS
    SELECT   '' 
    FROM     INSERTED AS x JOIN REGLER AS y
               ON    x.CommandeId = y.CommandeId
               AND   x.ClientPasse = y.ClientId
 
    IF @@Rowcount > 0
       BEGIN 
           Raiserror ('Update table COMMANDE : Contrainte d''exclusion non respectée !',16,1) 
       RETURN
    END
 
    UPDATE COMMANDE 
        SET    ClientPasse = (SELECT  ClientPasse FROM INSERTED)
             , CommandeDate = (SELECT  CommandeDate FROM INSERTED)
        WHERE EXISTS (SELECT * FROM INSERTED
                      WHERE  INSERTED.CommandeId = COMMANDE.CommandeId) ;

Tout ceci ne constitue qu'un exemple. Je n’ai pas testé à fond, donc si vous trouvez des erreurs, merci de les signaler...

A propos de la norme SQL.

La norme SQL propose l’instruction CREATE ASSERTION qui permet de garantir les contraintes sans avoir à développer des triggers qu’il faut surveiller quand la structure des tables évolue. Je pense aux triggers de type INSTEAD OF UPDATE : que se passe-t-il par exemple si on ajoute une colonne à la table COMMANDE ? Tel qu’il est écrit, le trigger attaché à la table COMMANDE sera à modifier.

Ainsi, quand le SGBDR sera à niveau, on pourra éliminer tous les triggers et coder beaucoup plus simplement, rapidement et sûrement :

Code :

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

1
2
3
4
5
6
7
8
9
10
11

CREATE ASSERTION CLIENT_COMMANDE_EXCLUSION 
   CHECK (NOT EXISTS (
      SELECT * 
      FROM   COMMANDE x 
      WHERE  EXISTS (SELECT * 
                     FROM   REGLER y 
                     WHERE  x.CommandeId = y.CommandeId 
                       AND  x.ClientPasse = y.ClientId)  
          )) ;

Pour la petite histoire, cette instruction existait déjà dans SEQUEL (l’ancien nom de SQL). C’était au milieu des années soixante-dix, elle s’appelait ASSERT.

[zoltix]

Je ne comprends pas bien la clause d'exclusion.
La définition de la clause exclusivité (X)
Toute les occurrences d'une entité peuvent participer a l'une des deux association, mais pas aux deux a la fois.

Donc dans ce cas ci le client qui paye ne peut être le même que le client qui passe.

Est ce que j'ai bien compris ? Mais dans le monde réel c'est vraiment comme ca ?

Et ça je ne comprends pas bien ?


et aussi

Code :

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

1
2
3
4
5
6
UPDATE COMMANDE 
        SET    ClientPasse = (SELECT  ClientPasse FROM INSERTED)
             , CommandeDate = (SELECT  CommandeDate FROM INSERTED)
        WHERE EXISTS (SELECT * FROM INSERTED
                      WHERE  INSERTED.CommandeId = COMMANDE.CommandeId)

ClientPasse = (SELECT ClientPasse FROM INSERTED)
Si on a plusieurs commande a modifier on n'aura pas un message d'erreur ou je n'ai pas bien compris qu'il y une contrainte qui le rend impossible que j'ai pas lu?............Oups je viens comprenre en relisant le shéma une commande ne peut être passé que par un et unique client CQFD ....

[fsmrel]

Je ne comprends pas bien la clause d'exclusion

Les pointillés qui partent des entités-types précisent qu’elles sont toutes les deux parties prenantes dans la contrainte. Celle-ci porte donc sur chaque paire {Client, Commande}. Puisqu’il s’agit d’une exclusion entre associations-types, une valeur de la paire {Commande Client} de l’association-type REGLER ne peut pas être une valeur de la paire {Commande Client} de l’association-type PASSER. Si donc la commande de la Ferrari 458 Italia a été passé par fsmrel, il lui est interdit de payer la facture (de toutes façons il n’a pas un sou), et ça sera à zoltix de casser sa tirelire personnelle. Maintenant, rien n’interdit que zoltix passe une commande de même nature, à charge de fsmrel de s’occuper des aspects financiers...

dans le monde réel c'est vraiment comme ca ?

Dans le cas de cet exemple, ça paraît assez irréaliste. Maintenant, si vous énoncez la règle de gestion suivante : A une date donnée, un professeur ne peut pas suivre le cours qu’il donne, la contrainte d’exclusion a son rôle à jouer.