Discussion :

[cazadoor]

Bonjours tous le monde.

J'ai une entité "Dossiers" avec des attributs (num dossier, date dépôt,... )

chaque dossier subi une ou plusieurs vérifications (Date_Verif, remarque,..).

chaque vérification d'un dossier est faite en deux étape (Rejet,Retour) (Ici je suis bloqué )

Merci pour vos aides.

[CinePhil]

Tes explications sont un peu succinctes mais au plus simple, je vois ce modèle :

J'ai une entité "Dossiers" avec des attributs (num dossier, date dépôt,... )

chaque dossier subi une ou plusieurs vérifications (Date_Verif, remarque,..).

dossier -1,n----subir----(1,1)- verification

chaque vérification d'un dossier est faite en deux étape (Rejet,Retour)

verification -1,n----proceder----(1,1)- etape

Ce qui m'interroge le plus, c'est cette histoire d'étape (rejet, retour). Tu veux dire que tous les dossiers passent par une étape de rejet ?

Décris-nous un peu plus ton processus.

[cazadoor]

Bonjour merci pour votre réponse

en faite la problématique que je veux modélisé se présente dans l'image suivante:



donc le dossier peut avoir 0 à plusieurs étapes de vérification dont chaque étape désigne la date du rejet, la remarque du rejet et la date du retour après la correction selon le motif de rejet.

j'espère que j'étais clair

Merci d'avance

[CinePhil]

j'espère que j'étais clair

Pas suffisamment non.

donc le dossier peut avoir 0 à plusieurs étapes de vérification dont chaque étape désigne la date du rejet, la remarque du rejet et la date du retour après la correction selon le motif de rejet.

Ce que tu appelles une étape est en fait un rejet ?
Et il y a de zéro à deux rejets pour un dossier ?

Un dossier peut passer directement du dépôt à la validation sans rejet ?

Je ne vois pas dans ton tableau ce que tu mentionnais à propos des vérifications :

chaque dossier subi une ou plusieurs vérifications (Date_Verif, remarque,..).

Il n'y a pas la date_vérif et la remarque semble s'appliquer au rejet.

[cazadoor]

selon l'image que j'ai publier dans le message précédent:

Ce que tu appelles une étape est en fait un rejet ?

une étape est caractérisé par la date de rejet, le motif de rejet (Remarque) et la date de retour.

cette étape concerne un dossier (Id_dossier).

La complexité, ce que durant l'ajout des informations. durant une étape on doit entrer au début la date du rejet et la remarque. ensuite après la rectification du dossier on entre la date du retour.

donc pour une étape les données sont entrer séparément.

J'ai pensé qu'une étape doit avoir deux identifiant !!! le premier pour désigné le id_dossier et le deuxième id pour id_étape. en plus le rejet et le retour doit avoir le même id_étape. (ça c'est juste une aidé on peut penser autrement !!)

Et il y a de zéro à deux rejets pour un dossier ?

Non c'était juste une explication.
le dossier peut avoir de 0 à plusieurs étapes.

c-a-d on commence par le dépôt du dossier (Num_dossier, date_dépot)
on passe par vérification dossier (rejet,remarque,retour) (non obligatoire)
et enfin validation dossier (champ état dossier).

Je ne vois pas dans ton tableau ce que tu mentionnais à propos des vérifications :

étape = vérification
chaque étape est une vérification de dossier




Bien à vous

[CinePhil]

Donc mon schéma de base était bon, à la cardinalité près puisqu'un dossier peut être directement validé sans avoir subi de rejet. D'après tes explications, je vois qu'une étape de vérification est équivalente à un rejet.

MCD :
dossier -0,n----subir----(1,1)- rejet

Tables :
dossier (dos_id, dos_numero, dos_date_depot, dos_date_validation)
rejet (rjt_id_dossier, rjt_numero, rjt_date_rejet, rjt_remarque, rjt_date_retour)

[cazadoor]

Mais le rejet et le retour sont deux actions séparés
on peut pas les mettre dans un seul enregistrement

J'ai pensé de rendre la vérification en deux tables
- rejet (-id_rejet, Date_rejet, Remarque, # id_dossier)
- retour (-Id_Retour, Date_Retour, # id_dossier)

Mais le problème Ici comment connaitre le retour pour quel rejet. ?

[CinePhil]

Si tout rejet finit par avoir un retour, tu as ce schéma :
rejet -0,1----engendrer----(1,1)- retour

Ce qui donne les tables :
rejet (rjt_id_dossier, rjt_numero, rjt_date_rejet, rjt_remarque)
retour (rtr_id_dossier, rrt_numero_rejet, rtr_date_retour)

[cazadoor]

Merci pour votre soutien

Donc au final on aura le modèle suivant ?

[Richard_35]

Bonjour Cazadoor et Philippe,

Je me permets de m'immiscer...

Donc au final on aura le modèle suivant ?

==> non : Id_dossier est retrouvé via le rejet. Tu n'as donc pas besoin de relier "Retour" à "Dossier".

Ton MCD provient d'Access. Access est "pauvre", en termes de cardinalités Merise : Access ne connait que 1---1 ou 1---∞. Pour les voir apparaître, il faut cocher "Intégrité référentielle" au niveau des relations.

1ère suggestion (si tu tiens, absolument, à conserve une entité "Retour") :
Tables :
Dossier (Id_dossier, Num_dossier, Date_depot, Etat) ;
Rejet (Id_Rejet, #Id_dossier, Date_rejet, Remarque) ;
Retour (Id_Rejet, Date_retour).

Relations (apparaissant automatiquement)
Dossier 1-----∞ Rejet, via Id_dossier ;
Rejet 1-----1 Retour, via Id_rejet.


2nd suggestion (débat éternel...) :
Tables :
Dossier (Id_dossier, Num_dossier, Date_depot, Etat) ;
Rejet (Id_Rejet, #Id_dossier, Date_rejet, Remarque, Date_retour).

Relations (apparaissant automatiquement)
Dossier 1-----∞ Rejet, via Id_dossier.

[cazadoor]

Merci infiniment Richard,

en faite je vais adopter la première suggestion.

concernant Access je l'ai juste utilisé pour dessiner le modèle .
Je vais utiliser MySQL puisque mon projet est une application web.

Bien à vous