Discussion :

[gollunk]

Bonjour,

Je travaille actuellement sur la conception d'un système qui intègre une base de données. En gros, il s'agit d'un logiciel permettant d'assister les utilisateurs lors d'étalonnages.

J'ai un soucis car chaque étalonnage doit aboutir à un ensemble de données (calculs, formulaire, etc.) qui doivent être stockées; mais certaines données sont, elles même, un ensemble de valeurs (en fait il me faudrait un tableau quoi). Ma question est simple: Existe-t-il un type "tableau" ? Sinon quel type de champ dois-je utiliser pour ce genre de donnée ? Peut-être dois-je utiliser une nouvelle entité où une chaine de caractère ?

Merci d'avance pour vos réponses. Cordiallement,

Julien

[CinePhil]

La première forme normale impose qu'un attribut soit atomique. Il faudrait donc normalement décomposer le tableau en ses éléments dans le MCD.
Ceci n'est toutefois pas facile dans le cas que vous citez. J'ai été confronté à un cas similaire et, comme l'efficacité de l'application n'était pas en cause, j'ai stoppé la normalisation.

Mon cas :
Des indicateurs ont des paramètres en nombre variable mais ces paramètres peuvent eux-mêmes être des listes ayant un nombre variable d'éléments selon les indicateurs.

Ma modélisation (non normalisée j'en conviens) :
Indicateur -0,n----Avoir----0,n- Paramètres

Mes tables :
Indicateurs(IndIndex, ...)
Parametres(ParIndex, ParNom, ParValeurDéfaut)
ParInd(ParIndIndicateur, ParIndParametre, ParIndValeur)

Exemples fictifs de tuples dans ParInd :
(1, 1, 10)
(1, 2, toto@tata@titi@tutu)
(1, 3, 1-m@2-d@3-f)

La ParIndValeur du deuxième tuple est en fait une liste.
Celle du troisième tuple est carrément un tableau (qui donne l'ordre des couches de la carte géographique sur laquelle on représente le résultat de l'indicateur)

Nota : ce modèle est issu d'un existant encore pire puisque tous les paramètres étaient stockés dans une colonne TEXT de la table des indicateurs. Merci à la fonction explode en PHP pour séparer tout ça !
Ce n'était d'ailleurs pas le seul cas dans la base existante mais j'ai réussi à normaliser tout le reste.
Normaliser totalement cette partie aurait compliqué les programmes existants pour un gain de performances négligeable.

Pour mon mémoire, je suis quand même intéressé par une modélisation correcte de ce genre de problème.

[gollunk]

Tout d'abord, merci de ta réponse.

Il me semble que mon problème est plus simple que ça. Dans mon cas le nombre de valeurs est fixe ( par exemple 14 valeurs ayant le même libellé). En fait ce que je voudrais éviter c'est d'avoir dans ma table: valeur1, valeur2, valeur3, etc... alors que dans un programme ceci peut se simplifier par un tableau.

[CinePhil]

Si je comprends bien, les 14 valeurs en question sont les 14 relevés effectués lors d'un étalonnage ?

Et tous les étalonnages se font sur 14 valeurs ?

Deux solutions :
1) 14 colonnes - val1, val2... val14
2) 1 colonne et 14 lignes par étalonnage NumEtalonnage Valeur

[gollunk]

Il s'agit bien de 14 valeurs relevées lors de l'étalonnage mais je précise car je m'explique mal:

J'ai une table "PROCEDURE" (qui correspond en fait à un étalonnage), cette table contient une quinzaine de champs (de type int, date, etc.), pour le moment rien d'extraordinaire.

A cet ensemble de champ s'ajoute plusieurs ensemble de données dont je n'arrive pas à définir le type (ou je ne connais pas la méthode "propre" à utiliser pour la notation).

La machine étalonnée dispose de 14 cellules rétro-réfléchissantes auxquels sont attribuées plusieurs informations. Pour chaque cellule on a donc plusieurs informations et pour compliquer la chose, il y a des données pour la nuit d'autres pour le jour.

Si j'utilise la premiére méthode je risque d'avoir une 50aine de champs dans PROCEDURE. Pour la 2eme méthode si je comprend bien il s'agit de créer une nouvelle table avec un enregistrement pour chaque cellule et un champ en plus permettant d'identifier l'étalonnage en relation ? Ca me parait pas mal.

[gollunk]

Dans ce cas faut-il utiliser la clé étrangère de "procedure" pour identier la procédure ou un nouveau champ ?

[CinePhil]

Oui la table de mesures contiendra en clé étrangère l'identifiant de la procédure.

Par contre, ceci va encore compliquer la chose :

La machine étalonnée dispose de 14 cellules rétro-réfléchissantes auxquels sont attribuées plusieurs informations. Pour chaque cellule on a donc plusieurs informations et pour compliquer la chose, il y a des données pour la nuit d'autres pour le jour.

Si je comprends bien, pour une procédure d'étalonnage, il y a 14 cellules qui délivrent chacune plusieurs informations ?
Et une procédure d'étalonnage comprend des mesures le jour et la nuit ?

[gollunk]

Oui c'est çà mais les valeurs de jour et de nuit sont propres aux cellules pas à l'étalonnage en lui même. Il est tout a fait possible de mettre les differentes informations dans la table Cellule. Pour chaque enregistrement on aura l'ensemble des informations pour une cellule identifiée par un champ num_cellule (de 1 à 14). Et tout les 14 enregistrements, la clé étrangère sera incrémenté pour identifier la procédure suivante.

[CinePhil]

Alors je ferais la structure suivante :
T_Procedures_P(P_Id, P_Libelle, ...)
T_Mesures_M(M_Id, M_IdProcedure, M_DateHeure, M_NumCellule, M_Mesure, ...)

[gollunk]

C'est ça. Seulement je ne l'appellerai pas "mesure" car l'étalonnage abouti à d'autres mesures qui n'ont pas de rapport avec les cellules.

Merci du coup de main, c'était vraiment cool de ta part. Cordialement,

Julien