Discussion :

[NAGOL]

Bonjour,

Je suppose avoir la réponse à ma question, mais je préfère la soumettre à votre avis plutôt que de foncer dans le mur en cas d'erreur.
Voici le contexte:
- Des sites (forestiers) possèdent 0 à plusieurs tiges.
- Ces sites subissent 0 à plusieurs interventions.
- Lors d'une intervention, des tiges peuvent être mesurées
- Différents types de mesures peuvent être appliquées (ou pas) à une tige : hauteur (décimale en m), diamètre (décimal en cm), statut (entiers de 1 à 4), étage (valeurs P, S, ou M), ...
- Par ailleurs, de nouveaux types de mesures peuvent être ajoutés par la suite

Parmi les 2 options que je présente, celle de gauche me paraît + pertinente + simple et + évolutive.
Mais je me demandais si, à l'usage, des problèmes sont rencontrés lorsqu'on compile des valeur dont les unités diffèrent autant ?
Ou peut-être faut-il prévoir une solution intermédiaire avec une entité-type recevant les valeurs métriques, une autre pour les classes de valeurs, etc... ?



Merci d'avance pour votre diagnostic

[escartefigue]

Bonjour,

Je suis d'accord, si de nombreuses mesures de différents types sont possibles, un métamodèle est préférable.

Pour ce qui concerne l'entité-type "intervention", il vaut mieux modéliser une autre entité-type "intervenant" et une association entre "intervention" et "intervenant"

[NAGOL]

Merci Escartefigue pour cette réponse.

En sachant que des traitements différents sont appliqués selon le type de mesure (calculs de diamètres moyens avec des mesures de type numérique, nombre de tiges ayant la valeur d'étage "P" ou "S", ...), me sera t-il toutefois nécessaire de créer une entité-type supplémentaire "mesure_format" pour chaque format que je prévois de stocker (CHAR, FLOAT, etc...) ?

Ou, dans le cas où je garderai un MCD tel que celui présenté sur la moitié gauche, l'attribut "mesure" devra nécessairement (?) être au format VARCHAR. Ce serait donc lors du traitement des valeurs filtrées que je devrai convertir celles-ci depuis un format VARCHAR vers SMALLINT, FLOAT, CHAR, etc... ?

[escartefigue]

Je ne pense pas qu'une entité-type supplémentaire soit requise, on retient bien un nombre de valeurs "P" et un nombre de valeurs "S" dans votre exemple. Une colonne de type decimal convient donc. Par contre, il faut identifier quelle mesure correspond aux "P" et quelle autre aux "S". Je suppose que toutes les mesures n'ont pas ce genre d'attribut.
On peut soit définir un attribut nullable pour les cas où cet attribut est nécessaire, soit utiliser un ou des sous-type pour les cas particuliers.
La solution dépend des cas concrètement identifiés où un ou plusieurs attributs supplémentaires sont requis.

[fsmrel]

Ou peut-être faut-il prévoir une solution intermédiaire

Quant à la modélisation, il y a une alternative qui mérite réflexion, en considérant des sous-types de MESURE, un par type de mesure :



Notez l’identification relative. En effet, le diagramme comporte une boucle selon laquelle la mesure m1 peut concerner le site s1 via l’intervention i1, mais aussi concerner le site s2 via la tige t1. Au stade MLD, on saura forcer l’égalité s1 = s2 en ne conservant dans MESURE qu’un seul attribut id_site participant à deux clés étrangères, une référençant INTERVENTION et l’autre référençant TIGE :



A noter encore que si MESURE est une entité-type associative entre INTERVENTION et TIGE, l’attribut id_mesure est peut-être superflu, à vous de voir.

[NAGOL]

Merci à tous les deux, je pense que la situation s'est maintenant bien clarifiée grace à vos réponses.

Je ne pense pas qu'une entité-type supplémentaire soit requise, on retient bien un nombre de valeurs "P" et un nombre de valeurs "S" dans votre exemple. Une colonne de type decimal convient donc.

En fait, lors d'une même intervention i1 la tige t1 peut avoir tout ou partie des mesures suivantes : par exemple 34,2 cm (diamètre) + 24,8 m (hauteur) + 1 (= statut social dominant) + P (= étage principal) + d'autres encore.

J'aurais pu (dû !) penser à l'identification relative, comme cela m'a bien été expliqué sur une autre discussion de ce forum. Et il me semble par ailleurs que la création des sous-types de MESURE éloignent bien les craintes que j'ai pu avoir. Et les valeurs NULL sont elles aussi écartées Par contre, je vais avoir un grand nombre de sous-types (des dizaines !).

Merci pour votre efficacité et bon week-end à vous.

[fsmrel]

Bonne fin de semaine à vous aussi !

Par contre, je vais avoir un grand nombre de sous-types (des dizaines !)

Concernant tous les tiges ?

[NAGOL]

Concernant tous les tiges ?

Oui, pour une même tige, on peut avoir (entre autres) :
- Suivi de la croissance : diamètre (de 2 manières différentes), circonférence, hauteur totale (x 5 mesures différentes), hauteur de la base du houppier, hauteur de la 1è branche vivante, projection du houppier (x8 mesures différentes), ...
- Suivi du feuillage : débourrement (x3 mesures différentes), jaunissement (x3 mesures différentes), éventuellement chimie foliaire (x n paramètres chimiques)
- santé du houppier : défoliation, décoloration, ...
- position "sociale" dans le peuplement : statut social, étage, accès à la lumière, ...
- etc...

[CinePhil]

Intéressant comme sujet...

L'héritage peut être à plusieurs étages. On rassemblera les morceaux avec des vues.

- Suivi de la croissance : diamètre (de 2 manières différentes)

Ce sont des diamètres qu'on peut spécialiser :
Diamètre type 1 <-- Diamètre <-- Mesure
Diamètre type 2 <---------|

Mais ce n'est peut-être pas nécessaire de faire ainsi. En fait, pour ceci :

diamètre (de 2 manières différentes)

Vous avez peut-être la règle de gestion suivante :
R1 : Une mesure de diamètre est une mesure lors d'une intervention et lors d'une intervention on peut avoir deux mesures de diamètre.

Ce qui donne :
Intervention -0,n----effectuer----(1,1)- Mesure -0,1----être----(1,1)- Diametre
|-------Contrainte : maxi 2 -----------------------------------------------------------|

Pas sûr de la représentation, surtout en format textuel, mais c'est l'idée !

Idem pour les hauteurs qui sont à typer (association avec un type de hauteur) et pour les projections du houppier...

Si vous avez encore d'autres types de mesures potentielles, vous pouvez aussi, pour avoir des valeurs bien formatées (INTEGER, DECIMAL, CHAR...) modéliser d'une manière un peu différente en conservant l'entité-type "TYPE_MESURE" et en faisant un héritage :

Règles de gestion :
R2 : Une mesure entière est une mesure et une mesure peut être une mesure entière.
R3 : Une mesure décimale est une mesure et une mesure peut être une mesure décimale.
R4 : Une mesure textuelle est une mesure et une mesure peut être une mesure textuelle.

MCD :
mesure_entiere -(1,1)----être----0,1- mesure
mesure_decimale -(1,1)----être----0,1---|
mesure_textuelle -(1,1)----être----0,1----|

Il faut ensuite mettre les contraintes d'exclusion sur l'héritage et de bonne concordance entre le type de mesure (qui contiendra un attribut précisant le format de mesure attendu) et la mesure enfant.

Une autre modélisation, moins élégante mais plus pratique à utiliser consiste à mettre un attribut par format de mesure :
mesure (id_intervention, id_mesure, id_tige, mesure_entiere, mesure_decimale, mesure_textuelle...)
Les colonnes mesure_x sont valorisées à 0 ou '' par défaut et une contrainte vérifie qu'une seule des colonnes de mesure est différente de sa valeur par défaut.

Par contre...

nombre de tiges ayant la valeur d'étage "P" ou "S", ...)

+ 1 (= statut social dominant) + P (= étage principal)

Une tige a t-elle 1 ou potentiellement plusieurs valeurs d'étage ?
Ce P ou S est-il la seule information qu'on enregistre ou bien est-ce associé à une mesure quantitative sur une tige ?

Au vu de ce texte que j'ai cité, j'ai l'impression qu'il s'agit plutôt d'attributs de la tige, selon les règles de gestion suivantes :
R5 : Une tige est caractérisée par une valeur d'étage et une valeur d'étage peut caractériser plusieurs tiges.
R6 : Une tige est caractérisée par un statut social et un statut social peut caractériser plusieurs tiges.

Ce qui donnerait le MCD suivant :
Valeur_etage -0,n----caractériser----1,1- Tige
Statut_social -0,n----caractériser----1,1-----|

=> Ce n'est plus de la spécialisation de mesures pour ces informations là.

Bref, si vous ne l'avez déjà fait, ne négligez pas l'étape d'écriture des règles de gestion des données.