Discussion :

[CinePhil]

Dans la base actuelle, la table 'indicateurs' comporte une colonne 'indiparametres' qui stocke les paramètres de l'indicateur selon le format suivant :
[nomParametre1]##[valeurs1]#@#[nomParametre2]##[valeurs2]#@#...

[valeursX] peut lui-même contenir plusieurs informations en quantité variable et a la forme :
[élément1]--[valeur1]--[élément2]--[valeur2]--...

Exemple : hlongueurlegendecouche##c--0--m--#@#hnompolice##d--ariali--m--#@#htaillepolicecouche##d--12--m--#@#...

L'exploitation de ce machin compliqué est fait grâce aux fonctions 'implode' et 'explode' de PHP et ça fonctionne.
Comme je normalise la base de données, je cherche un moyen de rationaliser l'enregistrement des paramètres.

J'ai extrait dans une table provisoire, grâce à un programme PHP, les triplets (indiind, parametre, valeurs) ou 'indiind' est le numéro de l'indicateur dans la table 'indicateurs'. Ca me donne :
- 136 indicateurs différents ;
- plus de 176 mille lignes (indiind, parametre, valeurs) ;
- 2107 indicateurs distincts ;
- près de 30 mille (parametre, valeurs) distincts.

Dans le système actuel, les paramètres par défaut proposés par le logiciel sont enregistrés avec chaque indicateur créé. Il y a donc redondance à chaque fois que ces paramètres par défaut ne sont pas modifiés, ce qui explique en partie la différence entre les 176 milliers de lignes de ma table et la trentaine de milliers de couples (parametre, valeurs) différents.

L'idée de base que j'ai eue pour normaliser l'enregistrement des paramètres est le système suivant :
- Une table parametres(ParIndex, ParNom, ParDescription, ParValeurDefaut)
- Une table de jointure avec la table 'indicateur', ParInd(ParIndParametre, ParIndIndicateur, ParIndValeur) qui n'enregistrerait que les paramètres modifiés par l'utilisateur.

Là où je coince un peu, c'est pour la modélisation des valeurs multiples pour un paramètre. Dans l'exemple donné plus haut, le paramètre 'hlongueurlegendecouche' comprend une valeur '0' pour l'élément 'c' et aucune valeur pour l'élément 'm'. Cependant, il pourrait y avoir d'autres éléments ou un seul.

Schématiquement, j'ai en quelque sorte la relation ParInd qui est composée ou pas d'un ou plusieurs éléments valués. Et faire partir une composition d'une relation, c'est pas bon il me semble ?

Résumons...
Pour le moment j'ai :
Indicateurs -1,n----ParInd----0,n- Parametres
qui donne :
- Indicateurs(IndIndex,...)
- Parametres(ParIndex, ...)
- ParInd(ParIndParametre, ParIndIndicateur, ParIndValeur)

Si je dois éclater 'ParIndValeur', je pourrais faire :
- ParInd(ParIndParametre, ParIndIndicateur, ParIndElement, ParIndValeur)

Mais dans ce cas j'aurai plusieurs lignes de ParInd pour un seul couple(Indicateur, Parametre). Est-ce correct ou peut-on faire mieux ?

[CinePhil]

Mon problème ne semble pas vous inspirer...

Petit complément :
sur les 136 paramètres différents, 76 ont un seul élément valorisé et donc 60 sont en fait des tableaux de valeurs.

J'ai aussi détecté des cas de paramètres qui ne sont présents qu'avec une seule valeur pour tous les indicateurs qui sont concernés. Ceux-ci correspondent par exemple au choix de l'utilisateur de cocher une case sur l'interface du logiciel, ce qui influe sur la représentation et/ou le traitement de l'indicateur. J'ai par exemple le parametre "hecritvaleur" qui concerne 9 indicateurs et qui est systématiquement à la valeur "on". Logiquement, ce type d'indicateur pourrait être une colonne de ma table, de type binaire avec valeur par défaut 0. Mais ajouter des colonnes à la table va à force l'alourdir, donc les traitements qui vont avec. De plus, certains paramètres ne concernent que peu d'indicateurs, comme on le voit dans l'exemple ci-dessus (9 indicateurs sur 2107).

Bref, j'hésite toujours entre :
- Laisser mon modèle tel quel et garder partiellement le système existant avec la fonction explode pour tous les paramètres multi-valeurs ;
- Normaliser un peu plus, mais je ne sais toujours pas comment.

[CinePhil]

Suite de mes aventures...
Depuis le précédent message datant du mois d'avril, j'ai provisoirement adopté le schéma suivant :
Indicateurs -0,n----Paramétrer----0,n- Parametres

Ce qui donne :
Indicateurs(IndIndex, ...)
Parametres(ParIndex, ParNom, ParDescription, ParValeurDéfaut)
ParInd(ParIndIndicateur, ParIndParametre, ParIndValeur)

Et j'ai importé les valeurs brutes dans ParInd, ce qui veut dire que certaines 'ParIndValeurs' sont en fait des tableaux de valeurs dont voici un exemple : 'm--on--c--on--d--on'

Dans l'état actuel, PArInd contient 169200 lignes.

Si je relance le sujet aujourd'hui, c'est que depuis avril je suis passé à l'adaptation des programmes PHP à ma nouvelle base de données et que j'approche à grand pas du moment où je vais être confronté à ces fameux indicateurs.

J'ai posé la question à mon professeur tuteur pour le mémoire d'ingénieur que je prépare. Il se trouve que c'était mon prof de base de données durant le cursus CNAM.

Il m'a répondu que je pouvais laisser le schéma comme ça si l'utilisation n'est pas fréquente car les enjeux en matière de gains de performance sur l'application ne se situent pas à ce niveau là.

Qu'en pensez-vous ?

[SQLpro]

Solution de facilité : modélisation par méta données.
Solution générale : modéliser le tout.

Pour 1) lire l'article que j'ai écrit à ce sujet : http://sqlpro.developpez.com/cours/m...n/metadonnees/

A +

[CinePhil]

Merci pour la réponse.
J'avais déjà vu cet article... après avoir fait mon modèle de données !
J'avais trouvé l'approche intéressante et peut-être applicable à une partie de mes bases de données, mais quand même assez déroutante et quelque peu extrémiste, ceci dit sans vouloir vous offenser.

Je verrai le moment venu si c'est utile pour le cas qui me préoccupe.