Discussion :

[-ULK-]

Bonjour à tous.

Je traite des dossiers dont le suivi est important, une date associée à un "état du suivi" est donc ajouté au dossier de temps en temps. Mon schéma est le suivant :

Dossier 1-----* Suivi *-----1 LibelleSuivi

La table "Suivi" contient une date pour chaque tuple.
Les différents états du suivi sont stockés dans une table "LibelleSuivi" pour facilité leur sélection et les recherches dans la base (liste déroulante).

Pour facilité l'évolution de l'application je laisse le soin aux utilisateurs de remplir la table des libellés comme ils l'entendent, si de nouvelles étapes de suivi apparaissent.

Mais je dois aussi faire en sorte que certaines étapes importantes du suivi soient toujours renseignées, par exemple la date de réception du dossier et de traitement définitif. Ces dates ne sont pas renseignées de la même façon que le suivi, par exemple la date de réception est renseignée lorsque le dossier est ajouté dans ma base Access.

Donc, je peux :
- Ecarter ces dates importantes de mon suivi et les inclure directement à la table "Dossier", dans mon formulaire d'ajout de dossier je peux donc forcer la date du jour comme étant celle de réception du dossier. Mais ça complexifie mes requêtes de calcul de delais entre les dates qui seront dans la table "Dossier" et les dates dans la table "Suivi".
Ou
- Inclure ces dates importantes au sein de la table suivi, ça simplifie mes requêtes de calcul de délais, mais je dois coder en dur l'ajout d'un tuple dans la table "Suivi" pour "réception du dossier" lors de l'ajout du dossier. Coder en dur, ça signifie faire directement référence à la clé primaire de la table "libelleSuivi" qui correspond à "réception du dossier". Déjà je n'aime pas trop coder en dur, mais pire que ça, comme je l'ais dit précédemment mes utilisateurs peuvent modifier cette table pour faciliter l'évolution de l'application et si il viennent à désactiver cette étape, ou à modifier le texte du libellé pour lui donner un sens différent, plus rien ne fonctionne.

Alors à votre avis, vers quelle proposition devrais m'orienter ? En avez vous d'autres ? Devrais-je carrément revoir ma conception ?

Merci.

[f-leb]

bonjour -ULK-

La deuxième solution me semble un poil tarabiscoté (même si pas tout compris).

Je traite des dossiers dont le suivi est important, une date associée à un "état du suivi" est donc ajouté au dossier de temps en temps

Un truc m'inquiète: un état de suivi ne devrait concerner qu'un dossier et un seul non ?
Intuitivement j'aurais plutôt fait:
Dossier-1---------------*-Suivi

Un Dossier peut être concerné par plusieurs suivis
Un suivi concerne un dossier et un seul.
Me gouré-je ?

DateOuverture et DateCloture sont des caractéristiques du dossier (dans la table Dossier donc)
DateSuivi est une caractéristique du suivi (dans la table Suivi)

avec une contrainte du genre DateOuverture < DateSuivi <DateCloture pour un dossier.

j'aimerais ben que tu lèves mes doutes avant de poursuivre...

[-ULK-]

Si tu regarde bien, tu as fais le même schéma que moi, donc on est d'accord

Et pour éviter que mon utilisateur ais à taper "réception du dossier" pour chaque nouveau dossier, ma table Suivi à une clé étrangère vers une table qui contient tous les libellés de suivi, ce qui me permet de les mettre dans une liste déroulante. Quoique cet exemple est peut-être mal trouvé, puisque justement "réception du dossier" est ici un des cas épineux qui m'amène à venir en parler sur ce forum.

DateOuverture et DateCloture sont des caractéristiques du dossier

C'est toute la question, si on s'imagine consulter l'historique du suivi d'un dossier, ces 2 dates ont aussi du sens, donc peuvent aussi être dans la table suivi.

Je vais réexpliquer mes 2 solutions :
1 : un nouveau dossier arrive, on renseigne DateOuverture avec la date du jour dans le formulaire d'ajout de dossier. Seule la table Dossier est "impactée".
2 : un nouveau dossier arrive, aucune date n'est à renseigner pour le dossier, par contre on ajoute une étape "réception du dossier" au suivi de ce dossier avec la date du jour. La table Dossier est modifiée ainsi que la table Suivi

Dans les 2 cas, je ne veux pas embêter l'utilisateur à renseigner la date du jour, je le fait par le code. Dans le 1er cas une bête valeur par défaut pour le champ dateOuverture est suffisante, dans le deuxième je dois coder un ajout de tuple dans ma table Suivi.

Par la suite, si je dois calculer des délais entre 2 dates, la solution 1 complexifie mes requêtes car je dois aller chercher mes dates dans 2 tables (Suivi et Dossier), alors que la solution 2 me permet de me "balader" dans une seule table (Suivi).

[f-leb]

Si tu regarde bien, tu as fais le même schéma que moi, donc on est d'accord

ben non:

Dossier 1-----* Suivi *-----1 LibelleSuivi

avec 3 tables Dossier, suivi et LibelleSuivi
Dans ton schéma Suivi est une table de jonction
Suivi(#idDossier, #idLibelleSuivi,...) c'est ça ?
Dans ce cas un même Suivi peut concerner... plusieurs dossiers ??????

Dossier-1---------------*-Suivi

j'ai que 2 tables, Dossier et Suivi (où LibelleSuivi si tu préfères)
Suivi(idSuivi, DateSuivi, #idDossier,...)
Un Suivi concerne un dossier et un seul.

Désolé mais ça change tout. Tu es sûr qu'un même Libellesuivi peut concerner plusieurs Dossiers ?

[Tofalu]

Bonjour

Il s'agit en fait de modélisation par méta données comme le défini SQLPro, voir son excellent site : http://sqlpro.developpez.com

J'aurais tendance pour ma part dans ce cas de figure et vu que la modélisation par méta données semble une finalité à faire une table du style : PropriétéSuivi(IdProp,NomProp,Requis(Oui/Non),TypeDeDonnées)

La table suivi devient alors

Suivi(IdDossier,IdProp,Valeur)

Et effectivement lors de la création d'un nouveau dossier, il faudra forcer l'enregistrement des propriétés obligatoires. Cette saisie sera manuelle dans le cadre d'un formulaire ou bien en mode transactionnel dans le cadre d'un automatisme VBA. Le type de données de la propriété permet d'adapter les opérateurs dans le cadre des requêtes.

Ainsi l'utilisateur pourra lui même ajouter des données dans la table PropriétéSuivi et les rendre obligatoire ou non etc.

Si toutefois des données de cette table ne doivent pas être modifiées supprimer, tu peux ajouter un champ Oui/Non nommé Systeme pour lequel la valeur sera à oui pour tes enregistrements "systèmes" et non pour ceux saisis par l'utilisateur. En offrant la possibilité à l'utilisateur de ne modifier / supprimer que ceux où Système est égale à non, tu annules le risque de perte de données critiques.

[-ULK-]

Merci à vous pour vos réponses

Je vais préciser ma modélisation :

Dossier(#idDossier,commentaires, etc...)
Suivi(#idSuivi,date,fkDossier,fklibelleSuivi)
LibelleSuivi(#idLibelleSuivi,libelle,actif)

Plusieurs dossiers ont effectivement le même libellé du genre "réception ou "étape 3".
Je ne m'étais pas posé la question à propos de "Suivi" comme une table jonction car au départ ma table libellé était juste là pour faciliter la saisie avec des listes déroulantes
Effectivement, je pourrais faire de Suivi une table jonction, en virant idSuivi et en faisant de fkDossier, fklibelleSuivi et date une clé primaire. Car un même dossier peut plusieurs fois avoir le même libellé à quelques semaines d'intervalle, d'ou l'intérêt de la date dans la clé primaire.
Mais ne serais-ce pas un peu lourd ?

Actif permet de désactiver un libellé dans les listes de choix en mode création, tout en permettant de retrouver la valeur dans les dossiers archivés en mode consultation.

Si toutefois des données de cette table ne doivent pas être modifiées supprimer, tu peux ajouter un champ Oui/Non nommé Systeme pour lequel la valeur sera à oui pour tes enregistrements "systèmes" et non pour ceux saisis par l'utilisateur. En offrant la possibilité à l'utilisateur de ne modifier / supprimer que ceux où Système est égale à non, tu annules le risque de perte de données critiques.

C'est l'idée que j'étais sur le point de mettre en place avant de poster ce sujet, mais le codage un dur des ajouts d'enregistrement "système" manque de flexibilité à mon goût.

Pour les meta-données, j'ai ai déjà entendu parler mais sans jamais les utiliser. Il s'agit bien de ce tutorial ?

[Tofalu]

Je ne comprends pas ce que tu appelles codage en dur.

Ici, toutes les PropSuivi, système ou non, sont encodées dans une table.

[f-leb]

bonjour,

ok, je commence seulement à commencer de comprendre

Effectivement, je pourrais faire de Suivi une table jonction, en virant idSuivi et en faisant de fkDossier, fklibelleSuivi et date une clé primaire. Car un même dossier peut plusieurs fois avoir le même libellé à quelques semaines d'intervalle, d'ou l'intérêt de la date dans la clé primaire.
Mais ne serais-ce pas un peu lourd ?

Suivi(#idDossier, #idLibelleSuivi, DateSuivi). ça te rajoutes une contrainte supplémentaire d'unicité sur le triplet (Dossier,LibelleSuivi,DateSuivi).
Pour un dossier et à une date donnés, tu ne peux saisir deux fois le même LibelleSuivi.
A toi de voir si ce modèle est compatible avec tes contraintes ou pas...En tout cas, je n'y vois aucune lourdeur (une association ternaire avec une entité Date est quelque chose de classique pour "historiser" des évènements).

Par contre, là ou je ne saisis pas:

...Actif permet de désactiver un libellé dans les listes de choix en mode création, tout en permettant de retrouver la valeur dans les dossiers archivés en mode consultation....
LibelleSuivi(idLibelleSuivi,libelle,actif)

"actif" est dans LibelleSuivi mais est-ce que ça ne dépend pas du dossier suivi ?
Comment tu sais si un LibelleSuivi doit être actif ou pas ? Quelle est la règle qui régit ça?

à+