Modéliser une GED : multiples index pour un objet

Bonjour,

Dans le cadre du développement d'une GED interne, j'ai les règles de gestion suivantes :

• Un fichier (objet) peut être qualifié par plusieurs index
• Un index a un type et une valeur

Par exemple, mon fichier "facture-05.pdf" aurait les index suivants :

• Nature de document : facture
• Date du document : 01/05/2011
• Nom du client : DUPOND
• N° du client : 201

Cela donne la modélisation suivante :

http://i0.simplest-image-hosting.net...507/modele.jpg

Les 4 index de l'exemple sont stockés dans INDEXATION, et pointent tous vers l'unique OBJET correspondant à mon fichier.

L'avantage de cette conception est qu'elle est très souple au niveau de la configuration de la GED : on peut créer les types d'index que l'on veut, et n'utiliser que ceux dont on a besoin pour chaque objet.

Mon souci se trouve au niveau de l'interrogation de cette base.
Imaginons les critères de recherche suivants :

• Nature de document : facture
• Nom du client : DUPOND

Ma requête va se traduire par :

• Une recherche des enregistrements de INDEXATION où FkIdTypeIndex = "Nature de document" ET ValeurIndex = "Facture". Cela nous donne une première sélection.
• Une recherche des enregistrements de INDEXATION où FkIdTypeIndex = "Nom du client" ET ValeurIndex="DUPOND". On a une deuxième sélection.
• Une recherche dans OBJET des enregistrements qui correspondent aux FkIdObjet de la réunion des deux sélections de INDEXATION

Vue la relative complexité de cette requête pourtant basique, j'ai peur d'être en train de partir sur un modèle inadapté.

Quel est votre avis ?

Bonjour Grasdubide :aie:,

Je trouve que c'est assez bien joué ! :ccool:

Citation:

---

Envoyé par Grasdubide

Vue la relative complexité de cette requête pourtant basique, j'ai peur d'être en train de partir sur un modèle inadapté.

---

==> en fait, il ne faudrait pas parler, là, de la simplicité apparente de la requête, mais plutôt de la "variabilisation" du nombre et du type d'index : tous les cas sont prévus, dans ton analyse : :ccool: (bis). Et donc, du fait de cette "variabilisation" extrême, l'extraction de la moindre donnée s'en trouve complexifiée. Logique.

Bonjour,

En faisant un peu de rétro-ingénierie vers le niveau conceptuel (au sens Merise), il apparaît que la table INDEXATION est issue d'une association entre OBJET et TYPE_INDEX.

[ TYPE_INDEX ]--0,n----( INDEXATION )----0,n--[ OBJET ]

Il s'ensuit que la clé de la table INDEXATION doit être {IdObjet, IdTypeIndex} (version 2) ce qui prémunit cette table de l'introduction de doublons ; chose que ne peut garantir la clé {IdIndexation} (version 1) et qu'il faut garantir d'une autre manière.

Autres avantages :
- Dans la version 1, si les colonnes IdObjet et IdTypeIndex ne sont pas indexées, alors la performance des requêtes avec la version 2 sera largement supérieure (sensiblement identique si ces colonnes ont un index en version 1).
- Avec une colonne en moins, la table INDEXATION est simplifiée.

Bonjour JPhi33,

C'est exact.

Il s'agit du débat éternel entre [un ID de type "numérotation automatique" en clé primaire et le couple {IdObjet, IdTypeIndex} en index unique] et [le couple {IdObjet, IdTypeIndex} en clé primaire, tout court].

Suivant le soft de programmation, la première version peut s'avérer plus pratique (Access, par exemple).

C'est de la modélisation par méta-données. Elle a ses avantages et ses inconvénients.

Merci à tous pour vos commentaires.

Finalement, je m'aperçois que les quelques divergences se situent au niveau des clefs à utiliser dans la table d'indexation.

J'ai pour ma part un avis personnel plutôt tranché, à savoir que je conserve un identifiant unique malgré la présence des 2 clefs étrangères qui pourraient en faire office. D'expérience, je trouve que la manipulation d'une table sans clef primaire est indigeste.

En tout cas, vos réponses me confortent dans le modèle que j'envisage. Encore merci.

Bonjour,

la clef primaire de votre table sera le couple des deux FK, en quoi est-ce indigeste ? :)

Dans le code, lorsque l'on doit conserver une référence à un enregistrement particulier, il est beaucoup plus aisé de manipuler une variable contenant l'identifiant primaire plutôt que 2.

C'est encore plus vrai lorsque l'on manipule plusieurs enregistrements à la fois.

Ma remarque n'est peut être pas vraie pour tous les langages, mais pour celui que j'utilise (4D), c'est le cas.