[PowerAMC] Gestion des attributs non commun

Bonjour,

j'aimerais avoir votre retour concernant la façon de faire pour modéliser un système permettant de gérer au mieux des attributs non commun à une entité type.

Je m'explique au travers d'un exemple :

Prenons par exemple le cas d'une modélisation d'une observation. Un individu A travaillant pour une société A observe quelque chose. Il note des champs obligatoire et commun entre toutes les observation (date, position, chose observée...) mais aussi des attributs non commun (météo, présence de vent...).

L'individu B qui travaille pour la société B fait pareil mais lui va avoir d'autres champs associés a ses propres observations.

La question est de savoir comment peut-on faire pour stocker ces différences et être tout de même capable de restaurer les informations différentes pour chaque individu ?


Par avance, merci pour vos lumières

S'il y a différents types d'observations avec pour chaque type les mêmes informations à enregistrer dans un type quel que soit l'observateur, alors il suffit de faire un héritage :
obs_typeA -(1,1)----être----0,1- observation
obs_typeB -(1,1)----être----0,1----------|

observation (obs_id, [colonnes communes à tous les types d'observations])
obs_typeA (ota_id_observation, [colonnes spécifiques aux observations de type A])
obs_typeB (ota_id_observation, [colonnes spécifiques aux observations de type B])

Si par contre c'est l'observateur qui décide sur le moment les informations qu'il note, en plus de quelques informations standardisées pour toutes les observations, alors il faut une table séparée pour les informations complémentaires :
observation -0,n----contenir----(1,1)- info_complementaire

observation (obs_id, [colonnes communes à toutes les observations])
info_complementaire (icp_id_observation, icp_numero, libelle...)

Bonjour et merci pour ta réponse,

Sachant qu'il y a potentiellement plusieurs type d'observation et que dans un avenir proche, il y en aura d'autre, comment peut-on créer quelque chose d'évolutif qui permettrait d’éviter la création d'une nouvelle table dès lors qu'un nouveau type d'observateur apparaît ?

Ça veut dire que tu es dans le premier cas (héritage) avec des types d'observations bien définies ?

Si tu veux que ce soit évolutif sans création de tables filles supplémentaires, je ne vois plus qu'une table des types et des métadonnées associées aux types.

type_obs -0,n----typer----1,1- observation -0,n----recueillir
    |-----0,n----avoir----1,n- critere -0,n------------|

Il faut prévoir en plus une contrainte d'inclusion entre les associations pour qu'une association de type A n'enregistre pas de critèress recueillis qui ne sont normalement pas présents dans le type A.

Citation:

---

Ça veut dire que tu es dans le premier cas (héritage) avec des types d'observations bien définies ?

---

Oui. pour autant, rien empêche que dans un mois, un observateur du type A créer de nouveaux champs qu'il faudra stocker. Par contre, seul les nouvelles données contiendront les informations.

Je relève une ambiguïté dans tes deux derniers messages :

Citation:

---

Sachant qu'il y a potentiellement plusieurs type d'observation

...

dès lors qu'un nouveau type d'observateur apparaît

.....

dans un mois, un observateur du type A créer de nouveaux champs

---

Dans ton premier message, tu ne parlais que d'observations et c'est sur cette base que j'avais conçu ma réponse avec ou sans héritage.

Ton dernier message me laisse à penser que ce serait plutôt la solution sans héritage qui conviendrait.