Discussion :

[Steph18]

Bonjour,

je sollicite la communauté pour tenter de venir à bout d'un problème de modélisation que je n'arrive pas à résoudre et que voici :

J'ai deux tables :
- Analyse
- Condition

Une analyse contient des résultats qui dépendent obligatoirement de deux conditions présentes dans la table Condition, l'une étant le contrôle et l'autre étant le test.
Les conditions présentes dans la table Condition ne font pas obligatoirement l'objet d'analyses.

Me tromperais-je en modélisant le problème comme ceci :
Analyse -2,2----0,n- Condition



Je suis actuellement arrivé à la conclusion suivante :

Je dois ajouter à la table Analyse, en plus des champs associés aux résultats, 2 champs :

• condition_controle
• condition_test

Je souhaite appliquer une contrainte sur chacun de ces champs qui doivent absolument se trouver dans la table Condition.

Ensuite je dois composer la clé primaire de ma table Analyse de 3 éléments :

• un identifiant unique
• condition_controle
• condition_test

- les 2 derniers éléments étant à la fois clés primaires et étrangères ?

Est-ce juste ? Cette solution est-elle incomplète ? Existe-t-il une meilleure solution ?

Merci pour votre aide !

[Richard_35]

Bonjour Steph18,

C'est une intéressante question...

Nous avons donc, au départ, des tables du genre (avant de parler de relations entres elles) :

Table Analyses :
- Id_Analyse (PK)
...

Table Conditions :
- Id_Condition (PK)
- Type_Condition (C=Contrôle, T=Test)
...

C'est bien cela ?

[Richard_35]

En complément :

Une analyse contient des résultats qui dépendent obligatoirement de deux conditions présentes dans la table Condition, l'une étant le contrôle et l'autre étant le test.
Les conditions présentes dans la table Condition ne font pas obligatoirement l'objet d'analyses.

Me tromperais-je en modélisant le problème comme ceci :
Analyse -2,2----0,n- Condition

Dans le cas que tu exposes, c'est plutôt :
Analyse -1,2----0,n- Condition.
En outre, c'est en contradiction avec la solution

Je suis actuellement arrivé à la conclusion suivante :

Je dois ajouter à la table Analyse, en plus des champs associés aux résultats, 2 champs :
condition_controle
condition_test

Autre petite contradiction :

Ensuite je dois composer la clé primaire de ma table Analyse de 3 éléments :
un identifiant unique
condition_controle
condition_test

Néanmoins, je te laisse répondre à la question de mon premier post avant de te suggérer une piste de MCD.

[fsmrel]

Dans le cas que tu exposes, c'est plutôt :
Analyse -1,2----0,n- Condition.

Pa d’accord. En effet, Steph18 dit bien qu’il y a exactement deux conditions pour chaque analyse.

Pour le mettre sur la voie, on va dire que l’on peut établir deux relations 1,1---0,N entre ANALYSE et CONDITION, chacune jouant un rôle spécifique.

[Steph18]

Premièrement j'aimerais vous remercier pour votre réactivité, c'est tout simplement génial d'avoir une réponse aussi vite

Dans le cas que tu exposes, c'est plutôt :
Analyse -1,2----0,n- Condition.

Non, une analyse dépend obligatoirement de deux conditions. Ce que j'ai oublié de préciser par contre, c'est qu'une condition peut être un contrôle dans une analyse alors qu'elle sera le test dans une autre analyse (ou comme je le disais plus haut, ne faire l'objet d'aucune analyse).

Pa d’accord. En effet, Steph18 dit bien qu’il y a exactement deux conditions pour chaque analyse.

Pour le mettre sur la voie, on va dire que l’on peut établir deux relations 1,1---0,N entre ANALYSE et CONDITION, chacune jouant un rôle spécifique.

Cette solution me paraît effectivement idéale . La clé primaire d'Analyse est donc bien composée des 3 éléments précités, chacune des conditions étant à la fois clés primaires et étrangères (PFK).



Je crois que dans ce cas toutes les contraintes sont respectées, et chaque cas de figure est modélisé, non ?
Dans ce cas il ne me reste qu'à formuler une énorme MERCI !

[Richard_35]

Bonjour à tous,

D'accord... et pas d'accord... reprenons.

Dans son premier post Steph18 nous dit :

Une analyse contient des résultats qui dépendent obligatoirement de deux conditions présentes dans la table Condition, l'une étant le contrôle et l'autre étant le test.
Les conditions présentes dans la table Condition ne font pas obligatoirement l'objet d'analyses.

Me tromperais-je en modélisant le problème comme ceci :
Analyse -2,2----0,n- Condition

==> à la question précise "Me tromperais-je" concernant ce cas, je dis oui, tu te trompes (cela ne veut pas dire que c'est ce que je propose). Car, dans ce cas (une analyse dépend de deux conditions) la cardinalité est : Analyse -1,2--[dépend]--0,n- Condition. Non ?


D'autre part, une question est posée dans le post #2 "pour planter le décor" : Steph18, si tu veux bien répondre, STP.

Ensuite, il me semble que nous pourrons étudier le MCD final : établir les relations adéquates entre ces deux tables.

[Steph18]

Bonjour Steph18,

C'est une intéressante question...

Nous avons donc, au départ, des tables du genre (avant de parler de relations entres elles) :

Table Analyses :
- Id_Analyse (PK)
...

Table Conditions :
- Id_Condition (PK)
- Type_Condition (C=Contrôle, T=Test)
...

C'est bien cela ?

Bonjour, désolé si j'ai été un peu vite.. Au départ, les tables sont simplement :

Table Analyse :
- Id_Analyse (PK)
- Id_condition_ctrl
- Id_condition_test
...

Table Condition :
- Id_Condition (PK)
...

Une condition n'est attachée un aucun type particulier (contrôle, test, ou rien). C'est l'analyse qui définit justement une condition contrôle et une condition test. L'analyse 1 peut avoir la condition 1 en contrôle et la condition 2 en test. Alors que l'analyse 2 peut elle avoir la condition 2 en contrôle et la condition 1 en test.

En ce sens, la solution proposée par fsmrel semblait donc répondre à mes interrogations.

[fsmrel]

dans ce cas (une analyse dépend de deux conditions) la cardinalité est : Analyse -1,2--[dépend]--0,n- Condition. Non ?

Reprenons au niveau conceptuel :

1er cas :

[ANALYSE] --- 2,2 ---(DEPENDRE)--0,N--[CONDITION]

La cardinalité minimum 2 signifie qu’une analyse participe au moins deux fois à l’association-type DEPENDRE ;
La cardinalité maximum 2 signifie qu’une analyse participe au plus deux fois à l’association-type DEPENDRE.

=>

Une analyse participe exactement deux fois à l’association-type DEPENDRE.

2e cas :

[ANALYSE] --- 1,2 ---(DEPENDRE)--0,N--[CONDITION]

La cardinalité minimum 1 signifie qu’une analyse participe au moins une fois à l’association-type DEPENDRE ;
La cardinalité maximum 2 signifie qu’une analyse participe au plus deux fois à l’association-type DEPENDRE.

=>

Une analyse peut ne pas participer exactement deux fois à l’association-type DEPENDRE, mais une seule fois, en contradiction avec la contrainte initiale selon laquelle il doit y avoir exactement deux conditions pour chaque analyse.

Redescendons au niveau tabulaire.

Le diagramme de Steph18 est correct, sinon qu’il comporte une erreur concernant la clé primaire de la table Statiscal_Analysis et doit être remplacé par le suivant :




En effet, une clé primaire est une clé candidate et à ce titre doit respecter les contraintes d’unicité et d’irréductibilité des clés.

Supposons maintenant que l’analyse 1 fasse référence aux conditions 2 et 4, ni plus, ni moins. D’après le diagramme proposé par Steph18, cette analyse peut en réalité faire référence à une diarrhée de conditions :

Code :

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

1
2
3
4
5
6
7
8
9
Analyse       Control     Test
-------       -------     ----
      1             1        2
      1             1        3
      1             2        1
      1             2        4
      1             3        1
    ...           ...      ...

En respectant la règle d’irréductibilité, cette situation devient impossible :

Code :

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

1
2
3
4
5
6
7
8
9
Analyse       Control     Test
-------       -------     ----
      1             1        2
      1             1        3
      1             2        1
      1             2        4
      1             3        1
    ...           ...      ...

Maintenant, même avec une clé primaire rendue irréductible, rien n’interdit qu’une analyse fasse référence deux fois à un contrôle ou à un test :

Code :

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

1
2
3
4
5
Analyse       Control     Test
-------       -------     ----
      1             2        2
    ...           ...      ...

Mais ceci est facilement contrôlable au niveau SQL :

Code sql :

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

1
2
3
4
5
6
7
8
9
10
11
 
CREATE TABLE ANALYSE 
(
        Analyse   INTEGER    NOT NULL
      , Control   INTEGER    NOT NULL
      , Test      INTEGER    NOT NULL
  , CONTRAINT ANALYSE_PK PRIMARY KEY (Analyse)
  , CONTRAINT ANALYSE_FK1 FOREIGN KEY (Control) REFERENCES CONDITION (condition)
  , CONTRAINT ANALYSE_FK2 FOREIGN KEY (Test) REFERENCES CONDITION (condition)
  , CONSTRAINT ANALYSE_C1 CHECK (Test <> Control)
) ;

[Richard_35]

Cela est allé un peu vite pour moi...

En final, deux possibilités :

1ère possibilité (que tu sembles avoir choisie) :
Table Analyse :
- Id_Analyse (PK)
- Id_condition_ctrl
- Id_condition_test
...
==> le traitement doit contrôler que Id_condition_ctrl <> Id_condition_test.


Table Condition :
- Id_Condition (PK)
...

Relation :
Condition 0,n ----- 1,1 Analyse via Id_Condition vers Id_condition_ctrl
ou
Condition 0,n ----- 0,1 Analyse via Id_Condition vers Id_condition_ctrl (s'il est possible d'avoir des analyse sans condition de contrôle) ;

Condition 0,n ----- 1,1 Analyse via Id_Condition vers Id_condition_test.
ou
Condition 0,n ----- 0,1 Analyse via Id_Condition vers Id_condition_test (s'il est possible d'avoir des analyse sans condition de test).
==> la table Condition étant, en quelque sorte, considérée comme 2 tables, puisque accédée par 2 champs distincts.

Juste une petite remarque (sans importance) concernant ce que tu dis :

Cette solution me paraît effectivement idéale . La clé primaire d'Analyse est donc bien composée des 3 éléments précités, chacune des conditions étant à la fois clés primaires et étrangères (PFK).

==> pas trop d'accord :
la clé primaire est uniquement Id_Analyse, puisque c'est l'identifiant unique d'une analyse (et non pas le triplé Id_Analyse/Id_condition_ctrl/ Id_condition_test, qui est unique aussi, d'ailleurs, mais non nécessaire) ;
Id_condition_ctrl, Id_condition_test sont, simplement, des clés étrangères.



2nde possibilité :
Table Analyse :
- Id_Analyse (PK)
...

Table Condition :
- Id_Condition (PK)
...

Table Analyse_Condition :
- Id_Analyse (PK)
- Id_Condition (PK)
- Type_Condition (C=Contrôle, T=Test)
- Date_Affectation_Couple
...

Relation :
Analyse (0,n) ----- (0,n) Condition, donc en passant par Analyse_Condition pour gérer la relation (n,n), à savoir :
Analyse 0 ----- n Analyse_Condition via Id_Analyse ;
Condition 0 ----- n Analyse_Condition via Id_Condition.


Personnellement, je penche pour la seconde possibilté qui me semble plus évolutive (en cas de troisième condition, à terme, par exemple). Pour l'instant, le traitement pourrait interdire la siaisie de + de deux couples.

Comme indiqué précédemment, débat analytique intéressant...

[Steph18]

Donc si je récapitule :

Reprenons au niveau conceptuel :
2e cas :

[ANALYSE] --- 1,2 ---(DEPENDRE)--0,N--[CONDITION]

Ce cas n'existe effectivement pas et il n'existera jamais.

Redescendons au niveau tabulaire.

Le diagramme de Steph18 est correct, sinon qu’il comporte une erreur concernant la clé primaire de la table Statiscal_Analysis et doit être remplacé par le suivant :

Je comprends tout à fait mon erreur, la notion d'irréductibilité allait bien vite me rappeler à l'ordre.

CONSTRAINT ANALYSE_C1 CHECK (Analyse <> Control)

Merci

1ère possibilité (que tu sembles avoir choisie) :
...
Condition 0,n ----- 0,1 Analyse via Id_Condition vers Id_condition_ctrl (s'il est possible d'avoir des analyse sans condition de contrôle/test) ;

Idem que plus haut : ce cas n'existe effectivement pas et il n'existera jamais.

Juste une petite remarque (sans importance) concernant ce que tu dis :==> pas trop d'accord :
la clé primaire est uniquement Id_Analyse, puisque c'est l'identifiant unique d'une analyse (et non pas le triplé Id_Analyse/Id_condition_ctrl/ Id_condition_test, qui est unique aussi, d'ailleurs, mais non nécessaire) ;
Id_condition_ctrl, Id_condition_test sont, simplement, des clés étrangères.

Oui merci, je suis complètement d'accord avec ça.

2nde possibilité :

Table Analyse :
- Id_Analyse (PK)
...

Table Condition :
- Id_Condition (PK)
...

Table Analyse_Condition :
- Id_Analyse (PK)
- Id_Condition (PK)
- Type_Condition (C=Contrôle, T=Test)
- Date_Affectation_Couple
...

Relation :
Analyse (0,n) ----- (0,n) Condition, donc en passant par Analyse_Condition pour gérer la relation (n,n), à savoir :
Analyse 0 ----- n Analyse_Condition via Id_Analyse ;
Condition 0 ----- n Analyse_Condition via Id_Condition.


Personnellement, je penche pour la seconde possibilté qui me semble plus évolutive (en cas de troisième condition, à terme, par exemple). Pour l'instant, le traitement pourrait interdire la siaisie de + de deux couples.

Comme indiqué précédemment, débat analytique intéressant...

Je comprends bien l'avantage et l'importance de l'évolutivité. J'avais pensé à quelque chose de similaire au départ mais spécifier le type de la condition dans un champ séparé ne me paraissait pas être une bonne solution. Si j'opte néanmoins pour cette solution, j'ai une question subsidiaire :
Dans la première solution, il m'est possible de demander que les champs relatifs aux conditions (test et contrôle) soient remplis pour chaque entrée (ce qui impose deux conditions par analyse). Dans cette seconde solution, est-il possible de forcer une entrée dans la table Analyse à posséder obligatoirement une condition contrôle et une condition test ?

En complément, voici un deuxième élément de réponse qui semblait m'indiquer que ma modélisation n'était pas la bonne :
Le problème de départ a fini par être simplifié mais ce cas de figure est plutôt probable : 2 analyses, par 2 méthodes différentes qui concernent le même couple de conditions test+contrôle. La mise en œuvre d'un modèle répondant à cette question reste assez simple avec la première solution mais dans le cas de la seconde, il sera impératif de passer par une relation ternaire avec une table Methode reliée à l'actuelle table Analyse_Condition afin de permettre d'avoir plusieurs couples Id_Analyse (PK)/Id_Condition (PK)/Method (PK) et cela me paraissait un peu trop..

Je termine une fois de plus avec un merci !

[Richard_35]

Bonjour Steph18,

Dans cette seconde solution, est-il possible de forcer une entrée dans la table Analyse à posséder obligatoirement une condition contrôle et une condition test ?

==> Eh bien oui, tout ne doit pas être, forcément, géré par le MCD : l'écran de saisie peut effectuer tous les contrôles de saisie que l'on souhaite.

En complément, voici un deuxième élément de réponse qui semblait m'indiquer que ma modélisation n'était pas la bonne :
Le problème de départ a fini par être simplifié mais ce cas de figure est plutôt probable : 2 analyses, par 2 méthodes différentes qui concernent le même couple de conditions test+contrôle. La mise en œuvre d'un modèle répondant à cette question reste assez simple avec la première solution mais dans le cas de la seconde, il sera impératif de passer par une relation ternaire avec une table Methode reliée à l'actuelle table Analyse_Condition afin de permettre d'avoir plusieurs couples Id_Analyse (PK)/Id_Condition (PK)/Method (PK) et cela me paraissait un peu trop..

==> Ne t'égares-tu pas un peu ?
2 analyses (donc 2 Id_Analyse différents) avec le même couple de conditions test+contrôle est tout à fait possible : attention à ne pas ajouter un niveau "Méthode" au dessus de "Analyse" peut-être non nécessaire.
Dans la première méthode :

Code :

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

1
2
3
4
5
Id_Analyse  Id_condition_ctrl  Id_condition_test
1           1                  2
2           1                  2
3           1                  2
...

Dans la seconde méthode :

Code :

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

1
2
3
4
5
Id_Analyse
1
2
3
...

Code :

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

1
2
3
4
5
Id_Condition
1
2
3
...

Code :

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

1
2
3
4
5
6
7
8
Id_Analyse   Id_Condition   Type_Condition
1            1              C
1            2              T
2            1              C
2            2              T
3            1              T
3            2              C
...

Après, c'est toi qui connais les tenants et les aboutissants...

[ego]

On voit ici une conséquence de certains points de vue rencontrés dans les discussions UML, modèle métier ou modèle de base de données. Il faut correctement modéliser le métier avant de faire le MPD

Tu dis toi-même qu'une Analyse possède une Condition "test" et une Condition "contrôle" obligatoirement et que les Contrôles peuvent être associés à plusieurs Analyses. En UML ou en MCD Merisien, il faut donc 2 relations entre Analyse et Condition. En UML ça donne ceci :


Analyse --------1 Condition
| **************1
| ************* |
--------------------
Les* sont des espaces :-(
Le rôle de l'association "du haut" côté Condition est "contrôle"
Le rôle de l'association "du bas" côté Condition est "test"
On a du 0..* côté Analyse

Attention pour les multiplicités c'est l'inverse de Merise.

Dans ce cas, s'il n'y a rien d'autre comme objets et relations, on aura, au niveau du MPD, 2 clés étrangères, disons FK_test et FK_controle dans la table "Analyse" qui pointent la table "Condition"

[fsmrel]

Bonsoir,

s'il n'y a rien d'autre comme objets et relations, on aura, au niveau du MPD, 2 clés étrangères, disons FK_test et FK_controle dans la table "Analyse" qui pointent la table "Condition"

On retrouve donc la table ANALYSE déjà présentée dans mon message précédent.

A noter que l’on n’en est pas encore au stade du MPD mais du MLD. En effet, c’est au cours d'une étape ultérieure que l’on décide de la mise en œuvre de la batterie des table spaces, index et autres objets de cette farine qui concernent les DBA. Au niveau du MLD, on en est encore à raisonner en termes de logique des prédicats, d’algèbre relationnelle, d’intégrité : contraintes référentielles (attention au vocabulaire, une clé étrangère n'est pas un pointeur, mais un ensemble), contraintes diverses du genre : CONSTRAINT ANALYSE_C1 CHECK (Test<> Control), etc.), contrainte que j’ai corrigée dans le message évoqué, car elle comportait une coquille.

Pour y voir plus clair, on peut dessiner un peu. En partant du MLD (diagramme) initialement proposé à Steph18, et repris ici avec Power AMC :



Par rétroconception, l’AGL fournit le MCD E/R suivant (sans malheureusement que l’on puisse faire prendre en compte la contrainte : CONSTRAINT ANALYSE_C1 CHECK (TestId <> ControlId) :




Ou au format Merise :



Ou sous forme de diagramme de classes :

[Steph18]

Bonjour à tous, et merci pour vos différents retours.
Richard_35, je te remercie, je vais juste tenter de clarifier ma question précédente afin que l'on reparte en s'étant compris mais je pense aisément pouvoir passer le statut du sujet à "résolu" tant vos réponses m'ont déjà éclairé.

Cela est allé un peu vite pour moi...
2nde possibilité :
Table Analyse :
- Id_Analyse (PK)
...

Table Condition :
- Id_Condition (PK)
...

Table Analyse_Condition :
- Id_Analyse (PK)
- Id_Condition (PK)
- Type_Condition (C=Contrôle, T=Test)
- Date_Affectation_Couple
...

Relation :
Analyse (0,n) ----- (0,n) Condition, donc en passant par Analyse_Condition pour gérer la relation (n,n), à savoir :
Analyse 0 ----- n Analyse_Condition via Id_Analyse ;
Condition 0 ----- n Analyse_Condition via Id_Condition.

Bonjour Steph18,
==> Ne t'égares-tu pas un peu ?
2 analyses (donc 2 Id_Analyse différents) avec le même couple de conditions test+contrôle est tout à fait possible : attention à ne pas ajouter un niveau "Méthode" au dessus de "Analyse" peut-être non nécessaire.

Dans la seconde méthode :

Code :

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

1
2
3
4
5
6
Id_Analyse   Id_Condition   Type_Condition
1            1              C
1            2              T
2            1              C
2            2              T
...

Voici maintenant le problème auquel je faisais référence en parlant de plusieurs "méthodes" :

Code :

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

1
2
3
4
5
6
Id_Analyse   Id_Condition   Id_Methode     Type_Condition
1            1              1              C
1            2              1              T
1            1              2              C
1            2              2              T
...

Je remercie également à fsmrel et ego pour leurs réponses précises et professionnelles. Bon courage à tous dans vos modélisations présentes et futures.

[Richard_35]

Bonjour Steph18,

Arghhhhh... tu ajoutes une entité au pied levé !...

Dans ton exemple :

Code Steph18 :

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

1
2
3
4
5
6
Id_Analyse   Id_Condition   Id_Methode     Type_Condition
1            1              1              C
1            2              1              T
1            1              2              C
1            2              2              T
...

il est dommage (pour ne pas parler d'erreur d'analyse) de répéter deux fois Id_Methode à toutes les analyses !...


Il faut donc, de mon point de vue, refaire une "mini-analyse" :
- une même analyse peut être effectuée par plusieurs méthodes : Oui.
- une même méthode (même Id_Methode) peut-elle être associée à plusieurs analyses différentes ?

[ego]

Bon si on prenait les choses dans l'ordre = diagramme de classes UML ou MCD puis les autres bidules ensuite, c'est plus simple de raisonner sur le métier d'abord et la base de données ensuite.
Sinon on est d'accord avec fsmrel sauf que comme vous l'avez compris, je ferai les diagrammes dans le sens inverse de son post

[fsmrel]

Bonsoir,

Sinon on est d'accord avec fsmrel sauf que comme vous l'avez compris, je ferai les diagrammes dans le sens inverse de son post

Rassurez-vous, nous commençons tous par une approche descendante de la modélisation ! Simplement, Steph18 est parti d’une représentation tabulaire très simple, à savoir deux tables et deux contraintes référentielles, ce qui ne nécessitait pas de remonter bien haut dans l’abstraction . Lors de mon précédent message, je me suis dévoué pour que l’on représentât les choses de façon lisible, et peu importe si j’ai fait fonctionner une approche ascendante, car j’ai bien précisé « Par rétroconception, l’AGL fournit le MCD », et tout un chacun sait qu’en toute rigueur la conception commence par le haut. Ça n’est peut-être pas le cas de Steph18, sans doute parce que l’outil de modélisation dont il se sert est gratuit mais ne permet pas de représenter des diagrammes de classes ou des MCD.

les autres bidules ensuite

C’est sympa pour les autres « bidules », à savoir la logique des prédicats et l’algèbre relationnelle qui constituent la base du Modèle relationnel de données. S’ils étaient encore là, Aristote, Dedekind, Frege, Russel, Quine, Codd et compagnie ne seraient pas d’accord que l’on traitât ainsi le fruit de leur travail...



J’avais oublié : pour compléter le tableau au plan sémantique, on peut aussi utiliser une représentation NIAM :



On pourrait aussi utiliser une représentation selon le réseau sémantique Morse, etc.

[Richard_35]

Bonjour à tous,

Chapeau bas, François, pour tes publications et tes interventions, toujours hyper-pertinentes... et, bien entendu, pour l'emploi de l'imparfait du subjonctif (il me semble), si parcimonieusement usité, de nos jours...

Steph18, tu devrais tout avoir pour bosser, du plus haut niveau d'abstraction au plus bas.

[ego]

@fsmrel ok pour les bidules

[Steph18]

Bonjour à tous,

je reviens après une courte absence et effectivement, vous m'avez donné tout ce qu'il me fallait pour bien modéliser mon problème ! Du MCD au MPD, et même plus !

Merci encore pour tous vos conseils , ce forum est top !!