Discussion :

[heretik25]

Bonjour,
je réfléchit à modéliser une base et j'aimerais avoir votre avis


Il s'agit d'une base de données qui va contenir des observations naturalistes. Ces observations vont être exploitées et un rendu sera effectué sur différents zonages (commune,bassin versant, grilles kilomètriques...). Nous sommes donc dans une modélisation avec un critère spatial.

Gestion :

Il peut y avoir 1 ou n contributeur
chaque contributeur produit des observations différentes
Les données seront exploitées sur des "zonages" (communes, grilles...)
Un zonage peut être attaché à un zonage (Ex : une commune est rattachée à n grilles)

Mes questions sont :

Comment gérer le fait qu'un zonage peut être lié à un autre zonage
Comment gérer les particularités de chaque contributeur ?

[CinePhil]

Commençons par le plus facile :

Comment gérer les particularités de chaque contributeur ?

Si tu entends par là les diverses propriétés d'un contributeur (nom, prénom, date de naissance...), il suffit de les mettre dans l'entité type "contributeur".

Comment gérer le fait qu'un zonage peut être lié à un autre zonage

Solution la plus simple :
1) Si un zonage ne peut être inclus que dans un un seul autre :
zonage -0,n----inclure
|----0,1----------------|

2) Si un zonage peut être inclus dans plusieurs autres :
zonage -0,n----inclure
|----0,0----------------|

Dans les deux cas, il faudra une table associative.

[heretik25]

Bonjour et merci pour votre réponse,

Pour les particularités des données des contributeurs, il s'agit en fait des observations qui sont différentes. Certains champs pourront être commun comme le nom de l'animal mais d'autres champs seront différents.

Je pensais faire une entité type "contribution" en y mettant les données communes mais que faire des particularités ? (champs non commun). J'ai pensé à ajouter une entité type "observation_extra" mais beaucoup de champs ne seront pas utilisés.

Pour les zonages, je pensais faire une entité type "zonage" avec les différents zonages puis créer une autre capable de stocker les liaisons mais votre explication me laisse perplexe (je ne comprend pas votre façon de faire)

Solution la plus simple :
1) Si un zonage ne peut être inclus que dans un un seul autre :
zonage -0,n----inclure
|----0,1----------------|

2) Si un zonage peut être inclus dans plusieurs autres :
zonage -0,n----inclure
|----0,0----------------|

Faut-il simplement ajouter une entité lié à zonages ?

En pj, le début du MCD

par avance merci pour votre aide

[CinePhil]

Pour les zonages, je pensais faire une entité type "zonage" avec les différents zonages puis créer une autre capable de stocker les liaisons

Ben c'est grosso-modo ce que je disais dans ma réponse mais ça ne correspond pas à ce que tu as fait dans ton MCD.

Tu as fait ceci :
zonage -1,1----est_infeodé_à----1,n- type_zonage

Traduction :
Un zonage est inféodé à un seul type de zonage et un type de zonage inféode un à plusieurs zonages.

C'est bon ?
Il faudrait que tu nous donnes la différence entre zonage et type_zonage pour qu'on comprenne mieux.

Pour les particularités des données des contributeurs, il s'agit en fait des observations qui sont différentes.

Donc, comme tu l'as fait dans ton MCD :
Contributeur -1,n----produit----1,1- observation

Certains champs pourront être commune comme le nom de l'animal

observation -1,1-----concerner----0,n- animal

mais d'autres champs seront différents.

Lesquels par exemple ?

j'ai pensé à ajouter une entité type "observation_extra" mais beaucoup de champs ne seront pas utilisés.

Je changerais les cardinalités de ton association :
observation -0,n----contenir----0,n- observation_extra

Tu auras ainsi - tout comme avec les cardinalités 0,1 que tu avais mises d'ailleurs - une table associative et il n'y aura jamais de colonne vide dans cette table.

[heretik25]

Tu as fait ceci :
zonage -1,1----est_infeodé_à----1,n- type_zonage

Traduction :
Un zonage est inféodé à un seul type de zonage et un type de zonage inféode un à plusieurs zonages.

Un zonage peut être par exemple une commune ou une grille ou un bassin versant et c'est cela que je souhaitait stocker dans type_zonage. Peut-être que cette entité est inutile ? L'entité zonage contiendrait la géométrie du zonage.


Concernant les données des observations. je dois pouvoir gérer le stockage des données des différents contributeurs.

Je m'explique. Chaque contributeur possède des champs en commun et certains différents des autres. Par exemple, un contributeur possède dans ses données la date d'observation, le nom de l'observateur, un autre en plus de ces champs aura la météo, la température de l'air, de l'eau... Bref, toutes les observations ne possèdent pas les même informations.

En créant une entité "observation_extra" je pensais stocker toutes les différences, je devrai donc ajouter les champs "meteo,climat,..." sachant que certains contributeurs n'utiliserons jamais ces champs et peut-être en posséderons d'autres, différents.

[Richard_35]

Bonjour heretik25 et Philippe,

Je me permets de m'immiscer, vite fait...

Philippe, je pense que par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
2) Si un zonage peut être inclus dans plusieurs autres :
zonage -0,n----inclure
  |-----0,0-------|

tu as voulu dire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
2) Si un zonage peut être inclus dans plusieurs autres :
zonage -0,n----inclure
  |-----0,n-------|

non ?

[CinePhil]

Un zonage peut être par exemple une commune ou une grille ou un bassin versant et c'est cela que je souhaitait stocker dans type_zonage. Peut-être que cette entité est inutile ? L'entité zonage contiendrait la géométrie du zonage.

OK, c'est ce que je pensais et tu as raison d'avoir modélisé cela. Par contre, tu n'as pas modélisé ce qui figurait dans ton premier message et dont je donnais une solution dans ma première réponse :

Un zonage peut être attaché à un zonage (Ex : une commune est rattachée à n grilles)

Pour prendre un exemple classique, la commune "Toulouse" est un zonage et elle fait partie du zonage "Haute-Garonne" qui fait partie du zonage "Midi-Pyrénées".
Ce qui n'empèche pas Toulouse d'être du type "Commune", Haute-Garonne du type "Département" et Midi-Pyrénées du type "Région".

Concernant les données des observations. je dois pouvoir gérer le stockage des données des différents contributeurs.

Je m'explique. Chaque contributeur possède des champs en commun et certains différents des autres. Par exemple, un contributeur possède dans ses données la date d'observation, le nom de l'observateur, un autre en plus de ces champs aura la météo, la température de l'air, de l'eau... Bref, toutes les observations ne possèdent pas les même informations.

Ne mélange pas les concepts ! Contributeur est différent de Observation ! Ce que tu décris sont des propriétés des observations, pas des contributeurs !
Si tu as des propriétés génériques, même si elles ne sont pas systématiquement renseignées, tu as le modèle suivant :
observation -1,n----avoir----0,n- element

Les éléments sont par exemple Météo, Température de l'air, température de l'eau, direction du vent.
L'observation n'aurait pour propriétés que ce qui est obligatoire tel que la date d'observation et tout ce qui facultatif mais pouvant faire partie de plusieurs observations utiliserait là structure que j'ai donnée ci-dessus.

En créant une entité "observation_extra" je pensais stocker toutes les différences, je devrai donc ajouter les champs "meteo,climat,..." sachant que certains contributeurs n'utiliserons jamais ces champs et peut-être en posséderons d'autres, différents.

Non. Il ne faut pas créer une entité observation_extra avec plein de colonnes facultatives mais faire l'association ci-dessus.

[CinePhil]

Bonjour heretik25 et Philippe,

Je me permets de m'immiscer, vite fait...

Philippe, je pense que par :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
2) Si un zonage peut être inclus dans plusieurs autres :
zonage -0,n----inclure
  |-----0,0-------|

tu as voulu dire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
2) Si un zonage peut être inclus dans plusieurs autres :
zonage -0,n----inclure
  |-----0,n-------|

non ?

Oups !
Oui bien sûr ! Le cas de cardinalités 0,0 n'est pas dans ma liste !

[heretik25]

Ne mélange pas les concepts ! Contributeur est différent de Observation ! Ce que tu décris sont des propriétés des observations, pas des contributeurs !
Si tu as des propriétés génériques, même si elles ne sont pas systématiquement renseignées, tu as le modèle suivant :
observation -1,n----avoir----0,n- element

Les éléments sont par exemple Météo, Température de l'air, température de l'eau, direction du vent.
L'observation n'aurait pour propriétés que ce qui est obligatoire tel que la date d'observation et tout ce qui facultatif mais pouvant faire partie de plusieurs observations utiliserait là structure que j'ai donnée ci-dessus.

Effectivement, ma phrase n'était pas très claire. Il faut effectivement bien distinguer observations et observateurs.

Pour autant, si j'applique la solution

observation -1,n----avoir----0,n- element

J'aurais dans ma future table "element" un champ "meteo" qui risque de ne pas être rempli si l'observation n'en possède pas.


Attributs de ma table "element"

• meteo
• vent
• climat
• humidite
• temperature

Imaginons qu'une observation ait seulement trois de ces champs. Je vais me retrouver avec une entrée qui possèdera deux champs à null dans la table element. L'entité porteuse contenir va effectivement me permettre de récupérer les bon éléments mais est-ce quand même ok ?


Pour les zonages, est-ce que c'est ok au regard du nouveau MCD en PJ ?

[CinePhil]

Pour autant, si j'applique la solution

observation -1,n----avoir----0,n- element

J'aurais dans ma future table "element" un champ "meteo" qui risque de ne pas être rempli si l'observation n'en possède pas.


Attributs de ma table "element"

• meteo
• vent
• climat
• humidite
• temperature

Non, tu n'as pas compris la structure. Passons à la génération des tables à partir de mon MCD :

observation -1,n----avoir----0,n- element

observation (obs_id, obs_date...)
element (elt_id, elt_libelle...)
obs_avoir_elt (oae_id_observation, oae_id_element, oae_valeur)

Soit l'observation n° 124 du 12/10/2011 qui a comme éléments la température de l'air (élément n° 10) de 26° et la direction du vent (élément n° 25) de SE, tu auras dans la table associative obs_avoir_elt les lignes suivantes :
oae_id_observation, oae_id_element, oae_valeur
124, 10, '26'
124, 25, 'SE'

Et pour l'observation 110 du 01/10/2011 tu auras des lignes différentes qui pourront porter sur d'autres éléments.

[heretik25]

Ah, ouai, je ne voyais pas ça comme ça. La table "element" sera donc en quelque sorte une liste de tous les éléments potentiels ?

Mais comment l'entité porteuse obs_avoir_elt se retrouve avec le champ "oae_valeur" ?

[CinePhil]

Ah, ouai, je ne voyais pas ça comme ça. La table "element" sera donc en quelque sorte une liste de tous les éléments potentiels ?

Oui, c'est ça !

Mais comment l'entité porteuse obs_avoir_elt se retrouve avec le champ "oae_valeur" ?

L'association entre les observations et les éléments est porteuse de données : le résultat de l'observation de l'élément, donc sa valeur. Je crois que l'exemple de mon précédent message est explicite ? La colonne oae_valeur contient la valeur de la température et le sens du vent de l'observation.

[heretik25]

Effectivement, la relation est porteuse mais le champ "valeur" est donc ajouté manuellement ?

[CinePhil]

Si tu utilises un logiciel de modélisation digne de ce nom, tu devrais pouvoir ajouter une propriété à une association sans problème dans le MCD. À la génération du MLD, le modeleur créera la table associative avec les deux clés étrangères et la propriété portée par l'association.

[heretik25]

Bonjour,

Ok mais comment gérer le fait que le champ "valeur" puisse avoir un type de champ différent ?

[CinePhil]

Ok mais comment gérer le fait que le champ "valeur" puisse avoir un type de champ différent ?

Le plus simple est d'utiliser le type VARCHAR pour la colonne (et pas champ ! ) contenant la valeur. C'est aux requêtes de trastyper ensuite la valeur en fonction de sa signification. C'est pour ça que j'ai mis la température entre apostrophes dans mon exemple précédent.

oae_id_observation, oae_id_element, oae_valeur
124, 10, '26'
124, 25, 'SE'

[heretik25]

Ok, et si le contenu de la colonne possède plus de 255 caractères

[heretik25]

une autre question qui n'est pas facile à appréhender.

Comment modéliser le fait qu'une observation soit rattachée à 1 ou n référentiel taxonomique*.


*Un référentiel taxonomique permet de connaître des informations précises sur l'espèce observée. Cependant, selon les espèces végétales ou animales, on utilise différents référentiels. Parfois des ponts existent entre les référentiels car l'entité "taxref" est un référentiel agrégateur de certains référentiels. Nous pourront aborder cette idée de pont un peu plus tard.

En PJ, la capture d'écran de la partie incriminée.

N.B : Comme vous pourrez le constater sur la capture d'écran, j'ai ajouté l'entité "lot_donnee" entre "contributeur" et "observation" car je dois être capable de connaître le lot de donnée attaché à la donnée.

Encore merci :-)

[CinePhil]

Je m'attendais à cette demande et j'y avais pensé en rédigeant mon précédent message.
Le type TEXT n'est pas top notamment pour l'indexation alors vite fait j'aurais tendance à dire qu'il vaudrait mieux faire une colonne séparée pour ces valeurs, voire une table séparée pour ces valeurs trop longues. Pas le temps de détailler un modèle plus fignolé pour le moment.

[heretik25]

Et pour le multi-référentiel ?