Discussion :

[ced]

Bonjour,

Je gère une base de données dans laquelle la notion de temps commence à prendre de plus en plus d'importance, alors que ce n'était fonctionnellement pas le cas initialement (au moment de sa conception initiale). Vu que j'ai la main sur le modèle de données, je voudrais y mettre un peu de rigueur, si possible.
Il s'agit d'enquêtes statistiques sur des points du territoire, avec collecte de données annuelles (chaque année, on collecte des informations sur différents points du territoire).
Or, il se trouve que les données collectées évoluent dans le temps : certaines sont créées à partir d'une année donnée, d'autres s'arrêtent à partir d'une certaine date (et d'autres ont une nomenclature qui évolue dans le temps, mais là, ça ne me pose pas de problème).

Je sais que la modélisation, c'est l'art d'éviter de stocker le "bonhomme NULL".

Mais là, je sèche sur le modèle le plus efficace dans mon cas : pour le moment, je dispose d'une entité "points" avec un attribut par donnée collectée sur le point. J'ai également un attribut qui stocke l'année de collecte.
Sauf que, dès lors qu'une donnée apparaît dans la collecte, ou en disparait, je me retrouve avec autant de NULL sur les points créés avant la mise en place de la collecte de cette donnée, et pareil pour les points créés après la disparition de la collecte de la donnée.

Exemple : l'attribut "donneeA" n'a plus été collecté à partir de la campagne 2007.
Tous les points correspondant à des enquêtes au-delà de 2007 ont donc NULL en base dans la colonne "donneeA".
Autre exemple : l'attribut "donneeB" a commencé à être collecté en 2008. Ainsi, tous les points correspondant aux campagnes antérieures à 2008 ont NULL sur cette colonne en base.

Ma question est donc : est-ce que je peux améliorer mon modèle de données pour limiter tous ces NULL ? Sachant qu'il n'est pas question de créer une table POINT par campagne annuelle...
J'ai regardé du côté de la 6ème forme normale (qui permet de prendre en compte les notions temporelles), sans vraiment y trouver de réponse jusque-là...

Pour moi, c'est une première étape, avant de complexifier encore le modèle (bientôt, un point pourra être visité plusieurs fois dans le temps, mais ça fera l'objet d'une autre question plus tard...).

Merci pour vos conseils et votre aide,

ced

[CinePhil]

Le problème vient du fait qu'il y a mélange entre les points et les données collectées.

Règle de gestion :
Une donnée peut être mesurée à plusieurs dates sur un à plusieurs points et sur un point on peut mesurer plusieurs données à une à plusieurs dates.

MCD :
donnée -0,n----mesurer----0,n- point
date -0,n--------------|

Si pour la date, il suffit de faire en fait référence à une campagne de mesures, laquelle peut avoir d'autres attributs, et donc si lors d'une campagne de mesures une donnée ne peut être mesurée qu'une seule fois en un point donné (mais plusieurs fois sur plusieurs points), alors on peut remplacer l'entité-type date par campagne :

donnée -0,n-------------mesurer----0,n- point
campagne -0,n--------------|

Sinon, s'il n'est pas utile de stocker un calendrier complet pour référencer à une date possible du calendrier, alors il est d'usage de ramener l'entité-type date en tant que propriété de l'association.

Ça pourrait donc donner les tables suivantes :
te_point_pnt (pnt_id,...)
te_donnee_dne (dne_id,...)
te_campagne_cmp (cmp_id,...)
tj_dne_mesurer_cmp_pnt_dmcp (dmcp_id_donnee, dmcp_id_point, dmcp_id_campagne, dmcp_valeur)

[ced]

Bonjour CinePhil et merci de ta réponse,

C'est bien vers ce type de modèle que je compte aller, notamment pour gérer la revisite d'un même point dans le temps.
Toutefois, j'avais identifié un problème avec cette modélisation, c'est que les données prises sur un point sont de natures différentes : qualitatives, quantitatives discrètes, quantitatives continues, commentaires, etc.
Du coup, côté modèle, ça se traduit par des types différents : entiers, décimaux, chaînes de caractères de longueurs différentes, etc.

Ainsi, dans le modèle logique que tu proposes, la colonne dmcp_valeur ne suffit pas, parce que je ne peux pas lui fixer un seul type.

Je ne sais pas trop comment gérer cela : par héritage ?

[CinePhil]

La solution sale, parce qu'on remet des bonshommes NULL dans chaque ligne :
tj_dne_mesurer_cmp_pnt_dmcp (dmcp_id_donnee, dmcp_id_point, dmcp_id_campagne, dmcp_valeur_num, dmcp_valeur_texte,...)

Une solution plus propre avec, effectivement, un héritage :
donnee_qualitative -(1,1)----etre----0,1- donnee
donnee_quantitative -(1,1)----etre----0,1----|
...

À voir pour les données discrètes à modéliser aussi les valeurs possibles d'une donnée de ce type et ensuite à contraindre le choix de la valeur parmi les valeurs possibles. Ça dépasse mes capacités de représentation en format texte dans ce forum.
Peut-être aussi y a t-il des valeurs possibles dans une plage pour les valeurs continues (de n à m) ?

[ced]

Merci pour ton aide.

Pour les valeurs possibles pour une donnée qualitative), tout ça existe d'ores et déjà dans la base de données initiale, sur laquelle je gère les métadonnées (et donc les modalités pour chaque donnée qualitative).
Pareil pour les plages de valeurs possibles pour les données quantitatives...

J'avais bien pensé aussi à la solution "sale", mais elle ne me plaisait pas non plus pour 2 raisons :

• je change le modèle pour supprimer le bonhomme NULL, du coup ce n'est pas pour le réintroduire avec potentiellement encore plus de bonshommes dans le nouveau modèle...
• les données qualitatives ont des modalités de tailles différentes : CHAR(1), CHAR(2), ..., jusqu'à CHAR(7). Je pourrais tout mettre dans un VARCHAR(7), mais je trouve que ça s'apparente, sur le principe, au bonhomme NULL (au niveau de la valeur...)

Du coup, je ne sais pas trop quoi faire...

[CinePhil]

Il devient difficile de réfléchir sur une base abstraite. Peux-tu nous montrer quelques exemples concrets ou bien ton domaine est-il secret ?

[ced]

Non, non, il n'y a rien de secret dans tout ça... Je prépare un modèle en exemple (un peu moins détaillé que le modèle réel) pour illustrer un peu mieux mon problème et je reviens avec ces précisions.

[ced]

Voici l'exemple d'une des entités de mon modèle.
Il s'agit de l'entité correspondant aux points qui sont les unités d'échantillonnages (le lieu où on effectue l'enquête).

Un point est donc identifié par un identifiant unique, généré automatiquement.
Pour le moment, chaque est échantillonné au cours d'une et une seule année (l'attribut "campagne" qui correspond à l'année de visite sur le point).
Plusieurs données sont collectées, d'autres proviennent de croisement carto, etc.
Par exemple, COUVERTURE est la couverture du sol observée sur le point (forêt, végétation basse, urbain, lande, sans végétation (artificiel), etc.). UTILISATION est l'utilisation observée sur le point (production de bois, militaire, agriculture, passage de réseau, etc.). On peut renseigner 2 utilisations au plus sur un point.
L'altitude est issue du croisement avec le MNT du territoire, tout comme la pente et l'exposition.

Ce qu'on voit sur cette exemple, c'est qu'il y a plusieurs types de données : entiers, nombres à virgule flottante, chaînes de caractères de longueur variable, etc.
La donnée AZIMUT_BM n'est prise que depuis la 4è campagne annuelle. Ce qui signifie que pour le moment, elle vaut NULL sur tous les points des campagnes antérieures (campagnes 1, 2 et 3).
À contrario, UTILISATION1 et UTILISATION2 ont été remplacées par de nouvelles données (UTIL, DISPO) à la 5ème campagne. Ce qui signifie que pour tous les points échantillonnés des campagnes au-delà de la 4è, ces deux colonnes n'auront plus que du NULL...

Comment faire ?