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.

[-ULK-]

Si je dois ajouter un dossier à ma base, je devrais executer une requête de ce style : "INSERT INTO Suivi VALUES (54,3,'16/05/2009')
Avec 54 l'id du dernier dossier ajouté, et 3 l'id du libelleSuivi correpondant à "Reception dossier".

Ce chiffre 3 sera celui que j'aurais choisi comme étant celui du libellé de réception.
Si dans le futur l'ajout d'un dossier doit ajouter l'id 5, je devrais aller modifier mon code.

J'y pense aussi, je peux aussi ajouter un booléen "ajout par défaut" à mes libellés qui oblige à les faire figurer ou pas lors de la saisie initiale d'un dossier... A voir.

Mais certaines autres étapes du suivi ne sont pas forcément à renseigner lors de l'ajout du dossier, mais a d'autre moment clé de la "vie" du dossier.

[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?

à+

[-ULK-]

En fait l'unicité des triplets dossiers,libelle,date serait peut-être plus correcte, mais elle n'est pas une contrainte essentielle dans mon cas. L'utilisation d'un idSuivi même si elle ne sert pas pour l'instant, pourrais faciliter des développements futurs, avec juste une seule colonne liée au lieu de trois dans les listes déroulantes.
En gros, je suis un bel ingrat puisque tu m'as fait remarquer quelque chose que je n'avais pas vu dans ma conception, mais je ne vais rien changer

Pour ce qui est du "actif", si un libellé de suivi est "Dossier dans les mains de Mr truc" et que Mr Truc part en retraite, il suffira de décocher "actif" pour qu'il n'apparaisse plus dans les listes lors de l'ajout d'étapes de suivi des dossiers récents. Mais il sera toujours visible si on consulte l'historique des dossiers plus ancien. (Je parle bien du libellé, pas de Mr Truc )


Au final après cette journée de réflexion, je crois que je vais retenir la solution 2 en faisant en sorte qu'il y ais des libellés "système" non modifiables par les utilisateurs, et dont je forcerais l'ajout à certains moment clé de la vie du dossier.

[ilank]

Bonjour à tous,

une idée en passant serait tout simplement de qualifier les suivis. Il y a d'après ce que je comprends trois types de suivis; RD pour Réception de Dossier, CD pour Clôture de Dossier et ETAPE. Dans un dossier ne peut exister qu'un seul suivi de type RD et qu'un seul de type CD; il suffit de les créer à la saisie de tout nouveau dossier.
De cette manière peut importe le libelle choisi par l'utilisateur; c'est la nature du suivi qui permet de qualifier le libellé.
Pour un dossier existant, l'ajout d'un nouveau suivi exige de le qualifier, soit il s'agit de la cloture du dossier ou d'une nouvelle étape; dans le cas d'une nouvelle étape ajouter un nouvel enregistrement dans la table SUIVI, dans le cas de la cloture ouvrir en modification l'enregistrement de type CD de la table SUIVI.
L'utilisateur peut continuer à utiliser à sa guise les libellés.