[Modèle Relationnel] Modéliser une GED : multiples index pour un objet [Résolu]

grasdubide · 30/12/2011, 13h34

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 :

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 ?

Richard_35 · 30/12/2011, 16h52

Bonjour Grasdubide

,

Je trouve que c'est assez bien joué !

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 :

(bis). Et donc, du fait de cette "variabilisation" extrême, l'extraction de la moindre donnée s'en trouve complexifiée. Logique.

JPhi33 · 30/12/2011, 17h19

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.

Richard_35 · 30/12/2011, 17h32

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).

CinePhil · 31/12/2011, 15h47

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

grasdubide · 04/01/2012, 10h52

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.

punkoff · 04/01/2012, 10h54

Bonjour,

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

grasdubide · 04/01/2012, 11h40

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.

30/12/2011, 13h34	#1
grasdubide Invité de passage Inscription : mars 2011 Messages : 8 Détails du profil Informations forums : Inscription : mars 2011 Messages : 8 Points : 2 Points : 2	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 : 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 ?
	00

30/12/2011, 17h19	#3
JPhi33 Modérateur Jean-Philippe Inscription : août 2007 Messages : 632 Détails du profil Informations personnelles : Nom : Jean-Philippe Âge : 49 Localisation : France, Gironde (Aquitaine) Informations forums : Inscription : août 2007 Messages : 632 Points : 1 007 Points : 1 007	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. __________________ « Cela va sans dire... mais cela va mieux en le disant ! » (maxime populaire) __________________ Vous avez votre réponse ? N'oubliez pas de cliquer sur
	00

30/12/2011, 17h32	#4
Richard_35 Expert Confirmé Inscription : juillet 2007 Messages : 2 184 Détails du profil Informations personnelles : Sexe : Localisation : France, Ille et Vilaine (Bretagne) Informations forums : Inscription : juillet 2007 Messages : 2 184 Points : 2 814 Points : 2 814	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). __________________ Dis-nous et à bientôt, Richard. ---------------------------------------------------------------------------------------------- En cas de résolution, et afin de faciliter la tâche des bénévoles, merci de cliquer sur . et permettent aux forumeurs de cibler leur recherche dans une discussion : n'hésitez pas à voter !
	00

31/12/2011, 15h47	#5
CinePhil Modérateur Philippe Leménager Ingénieur d'études en informatique Inscription : août 2006 Messages : 11 029 Détails du profil Informations personnelles : Nom : Philippe Leménager Âge : 48 Localisation : France, Haute Garonne (Midi Pyrénées) Informations professionnelles : Activité : Ingénieur d'études en informatique Secteur : Enseignement Informations forums : Inscription : août 2006 Messages : 11 029 Points : 18 331 Points : 18 331	C'est de la modélisation par méta-données. Elle a ses avantages et ses inconvénients. __________________ Philippe Leménager. Ingénieur d'étude à l'École Nationale de Formation Agronomique. Mon blog sur la conception des BDD, le langage SQL, le PHP avec Zend Framework... « Ce que l'on conçoit bien s'énonce clairement, et les mots pour le dire arrivent aisément ». (Nicolas Boileau) À la maison comme au bureau, j'utilise Mandriva Linux ou Mageïa ! Soutenons l'industrie logicielle française ! Linuxiens, comptez-vous !
	00

04/01/2012, 10h52	#6
grasdubide Invité de passage Inscription : mars 2011 Messages : 8 Détails du profil Informations forums : Inscription : mars 2011 Messages : 8 Points : 2 Points : 2	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.
	00

04/01/2012, 10h54	#7
punkoff Expert Confirmé Inscription : mai 2002 Messages : 1 657 Détails du profil Informations personnelles : Sexe : Âge : 29 Localisation : France, Rhône (Rhône Alpes) Informations forums : Inscription : mai 2002 Messages : 1 657 Points : 2 660 Points : 2 660	Bonjour, la clef primaire de votre table sera le couple des deux FK, en quoi est-ce indigeste ?
	00

04/01/2012, 11h40	#8
grasdubide Invité de passage Inscription : mars 2011 Messages : 8 Détails du profil Informations forums : Inscription : mars 2011 Messages : 8 Points : 2 Points : 2	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.
	00

Outils de la discussion
Afficher une version imprimable Envoyer un lien vers cette page par email