Discussion :

[NAGOL]

Bonjour,

Le niveau des diverses discussions que j'ai lues sur ce forum me fait avancer sur de nombreux points, merci !
Pour ma question actuelle, je n'ai cependant pas trouvé de réponse... Je vais directement illustrer ma question par un exemple plutôt que de me perdre dans de longs discours :

- des mesures sont réalisées périodiquement sur certains sites (mais pas tous)
- une période est toujours composées de 4 dates de mesures (numérotées de 1 à 4 pour chaque période)
- tout ou partie des mesures sont réalisées simultanément, à chacune des 4 dates qui composent une période
- chaque mesure est réalisée par un appareil différent

J'y vois clairement 3 entités que j'appelerai site, periode, et appareillage. Une entité moins évidente (celle qui me pose problème) serait semaine (et ne contiendrait qu'un identifiant pouvant prendre les valeurs [1-2-3-4]). Toutes ces entités convergent vers l'association mesurer qui contient la mesure.

Je me suis orienté vers ce MCD :


Et je me retrouverai alors avec les tables suivantes :
site ( id_site, coordonnee_X, coordonne_Y, altitude, surface )
mesurer ( id_site#, id_periode#, num_semaine#, id_appareil#, mesure )
periode ( id_periode, annee, num_dans_annee, )
appareillage ( id_appareil, unite )

Mon problème semble a priori résolu dans le résultat (chacune de mes mesures étant alors précisément identifiées), et pourtant le fait de créer une entité telle que semaine et de l'associer comme je le fait me semble bancal...

Votre regard sur ce cas m'éclairera surement, et je vous en remercie par avance !

EDIT :

Ou est-ce que ce modèle est plus pertinent (?) :

[fsmrel]

Bonsoir NAGOL,

une période est toujours composée de 4 dates de mesures

Dans votre 1er diagramme, ces dates ne sont pas représentées, ce qui signifie qu’elles ne sont pas essentielles, donc que vous savez les calculer à partir des attributs de l’entité-type PÉRIODE.

Qu’en est-il ?

Une entité moins évidente (celle qui me pose problème) serait semaine (et ne contiendrait qu'un identifiant pouvant prendre les valeurs [1-2-3-4])

Quelle est la finalité de cette entité-type ?

Merci de fournir des exemples concrets de mesures, ceci permet toujours de mieux aborder les problèmes.

Ou est-ce que ce modèle est plus pertinent (?)

Il faudrait déjà que vous répondissiez aux questions précédentes pour que l’on aborde cette question. Quoi qu’il en soit, le diagramme en cause comporte une boucle, ce qui pose toujours des problèmes...

[NAGOL]

Bonsoir Fsmrel, et merci pour votre réponse.

Concrètement, les mesures (précipitations pluvieuses, température, humidité, ...) sont réalisées 1x par semaine (disons tous les mercredi) simultanément sur une partie des sites. Toutes les 4 semaines de mesures, et donc toutes les 4 mesures, on bascule dans une nouvelle période "p+1".

La date ne peut pas clairement être un identifiant car, dans les faits, il peut y avoir un écart de +/- 1 jour entre les sites pour une même mesure. c'est donc le n° de la semaine au sein de la période qui sert d'identifiant (: semaine 1, semaine 2, semaine 3, ou semaine 4).

Je dois systématiquement être en mesure de pouvoir identifier 1 mesure donnée, faite une semaine donnée (la 1, 2, 3, ou 4) au sein d'une période donnée, pour un site donné.
En "bonus", il m'est utile de savoir la date calendaire qui correspond à cette mesure donnée, dans le but de connaitre l'écart entre la date de mesure effective et la date cible.

Cet exemple me permet-il d'être plus clair dans ma demande ?

[escartefigue]

Bonjour Nagol,

quelques questions :
- la relation telle que modélisée permet à un même appareil d'être présent sur plusieurs sites, est-ce vraiment le cas ?
- vous mesurez plusieurs valeurs : température, humidité..., d'après votre MCD c'est le même appareil qui fait ces différentes mesures et chaque appareil fait toutes les mesures, est-ce bien ce qui est souhaité ?

[EDIT] je viens de voir l'attribut "unité" dans l'entité-type appareil, si c'est l'unité de mesure, la question 2 tombe mais une autre apparaît : dans ce cas, on peut avoir pour un même site et une même date, deux mesures d'une même unité (par exemple deux mesures de température), est-ce ce qui est souhaité ?


Enfin, vu vos explications sur les périodes et les semaines, il faut horodater la mesure et mettre en relation cet horodatage avec la période : la relation "mesurer" n'est plus rattachée à "période" ni à "semaine" mais à une nouvelle entité-type, disons "calendrier" dont la PK est une date qui permettra de récupérer la période.

[NAGOL]

Bonjour Escartefigue,

Merci de vous pencher sur ma question.
Le modèle que je présente est une version très épurée de ma situation réelle dans le but de présenter plus clairement la plus grosse épine que j'ai dans le pied : la manière dont je dois intégrer la périodicité dans le MCD.

Je suis très novice dans l'art de la modélisation, et j'imagine bien que mon exemple est imparfait. Mais je voulais commencer à creuser par moi même et ne pas attendre qu'un résultat me tombe tout cuit dans les mains.

Dans mon exemple, disons que l'entité appareillage pourra avoir les attributs (id_appareil, type_appareil, modele, unite). id_appareil sera auto-incrementé et type_appareil pourra avoir des valeurs comme "thermomètre", "hygromètre", "pluviomètre", ...

Il y aura bien un thermomètre sur plusieurs sites pour mesurer le paramètre "température", un pluviomètre sur plusieurs sites (pas forcément les mêmes) pour les précipitations pluvieuses, ...
Il est possible d'avoir 2 pluviomètres sur un même site (pour permettre de faire une moyenne, ou si l'un des 2 est défectueux)
Mais si la température est suivie sur 5 sites, il y a 5 thermomètres différents (et pas forcément le même modèle).

Enfin, il est évident que chaque appareil ne fait pas toutes les mesures (un thermomètre ne mesurera pas l'hygrométrie et les précipitations, par exemple). Si mon MCD indique le contraire, c'est une erreur de ma part ! Serais-je donc si loin du résultat escompté, "dans les choux" ?

[EDIT] : En incluant l'entité-type "calendrier" comme proposé, quel sera la construction qui me permettra de définir dans quelle semaine (1, 2, 3, ou 4) au sein de quel numéro période je me trouve ? L'autre point qui m’interroge est l'apparition d'une entité-type calendrier : si elle est conservée au delà du MCD, elle se retrouvera rattachée à de très (très) nombreuses associations ! Cela ne risque-t-il pas de compromettre sérieusement les performances ? J'imaginais plutôt un horodatage parmi les attributs de mes associations. Pour m'être documenté sur la question (voir entre-autres ici), je vois que la question de la date "attribut" ou "entité" n'est pas si évidente.

[escartefigue]

En ce cas, le MCD serait plutôt le suivant

SITE 0,n --- disposer ---1,1 APPAREIL 0,n --- effectuer --- (1,1) MESURE
..........................................1,1
..........................................│
..............TYPE_APPAREIL 0,n ┘

[NAGOL]

Suite à vos diverses remarques et après réflexion, j'aboutirais donc à ce MCD (?) :



avec en définitive les tables suivantes :
periode ( id_periode, annee, num_dans_annee )
semaine ( id_semaine, id_periode#, num dans annee )
calendrier ( date, id_semaine# )
type_appareil ( type_appareil, modele, unite )
site ( id_site, coordonne_X, coordonne_Y, altitude, surface )
appareil ( id_appareil, type_appareil#, id_site#)
mesure ( id_mesure, date#, id_appareil#, mesure )

Je peux donc savoir que la mesure à l'id "123456" (qui vaut 24,5) est effectuée par l'appareil 3 (qui est par définition un thermomètre dont l'unité est le degré Celsius) disposé sur la placette X. Cette mesure est effectuée à une date inclue dans la semaine "456" (dont le numéro dans la période est "3"), elle même inclue dans la période "321" (la 6è période de l'année).
Potentiellement, la mesure à l'id "n+1" peut être réalisée à la même date par un autre thermomètre (qui sera l'appareil 8) installé sur le même site.

Le raisonnement tient-il la route ?

[fsmrel]

Bonsoir,

Je me focalise sur votre 1er message, car vous y traitez quand même du « mur porteur » du reste de l’édifice (les mesures).

La date ne peut pas clairement être un identifiant.

Ma question n’a rien à voir avec l’identification.

Je rappelle ce que vous avez énoncé :

tout ou partie des mesures sont réalisées simultanément, à chacune des 4 dates qui composent une période

Il s’agit pour le moment de savoir quelles données permettent de déterminer une date (calendaire) de mesure. Pour l’année de la mesure, pas de problème, grâce à la présence de l’attribut annee dans l’entité-type PÉRIODE. Pour le mois, quels attributs permettent de déterminer celui-ci ? En ce sens, merci de donner une définition de l’attribut num_dans_annee, s’agirait-il du mois lui-même (valeurs allant de 1 à 12 ?), d’une donnée plus fine, genre semaine ?

Pour la détermination le jour, qu’en est-il ? Qu’il s’agisse d’un mercredi, à ± 1 jour, d’accord si cette approximation suffit. Je note que la prise en compte de la semaine au moyen d’une entité-type ad-hoc crée selon vous une situation bancale, et vous met mal à l’aise. Soit ! Mais quelles sont les raisons exactes de ce malaise ? Pour le moment, j’en déduis que les données de l’entité-type PERIODE ne sont pas suffisantes, alors que, si je ne m’abuse, il serait avantageux qu’elles le soient.

Quoi qu’il en soit, comme il s’agit d’effectuer des mesures périodiques, il serait évidemment ballot de faire figurer en dur chaque date de mesure, alors qu’un « modulo » suffit, économiquement parlant il n’y a pas photo. Le tout est de trouver le meilleur moyen de mettre en oeuvre ce modulo...

Pour m’éclairer, merci de remplacer dans le tableau ci-dessous les "?" par du concret.

 
PERIODE {id_periode    année    num_dans_annee}
         p1            2018     ?
         p2            2018     ?
         p3            2018     ?
         p4            2018     ?
         p5            2018     ?
         ...           ...      ...

Je n’ai pas abordé le cas du calendrier (dans son acception habituelle) dont j’ai du mal à voir la valeur ajoutée, sa nécessité, modulo oblige...

[NAGOL]

Bonsoir,

Mon unité temporelle de base est la semaine (mais si la mesure est avancée/retardée d'un jour sur un site, je peux avoir une "semaine" de 6 ou 8 jours).
Dans tous les cas, j'aurais TOUJOURS exactement 4 semaines par période, et 13 périodes par an. (13 périodes de 4 semaines = 52 semaines = 1 an).
C'est surement le vocabulaire qui est trompeur car, dans mon cas, une semaine pourrait très bien durer 2 ou 13 jours : sa durée est variable, mais il reste important de savoir combien de jours cette semaine comporte. Mais j'aurais toujours au final mes 52 semaines par an, réparties en 13 périodes.

Voici comment serait renseigné le tableau que vous me présentez :

 
PERIODE {id_periode    année    num_dans_annee}
         p1            2018     1
         p2            2018     2
         p3            2018     3
         ...           ...      ...
         p12           2018     12
         p13           2018     13
         p14           2019     1
         p15           2019     2
         ...           ...      ...

Je dois pouvoir me retrouver dans cette situation, où j'ai pour un site donné (ce qui n'est clairement pas normalisée, d'où ma question originelle) :

 
Date {id_periode    num_semaine   date_mesure}
      p1            1             19/06/2019
      p1            2             26/06/2019
      p1            3             03/07/2019
      p1            4             08/07/2019
      p2            1             17/07/2018
      p2            2             24/07/2019
      p2            3             01/08/2019
      p2            4             07/08/2019
      p3            1             14/08/2019
      ...           ...           ...

C'est bien le couple ( id_periode + num_semaine ) qui me permet d'avoir ma correspondance entre sites, puisque la date calendaire est potentiellement variable d'un site à l'autre.

En vous remerciant une fois encore pour le temps et l'aide que vous m'accordez !

[fsmrel]

Je reviens à la case Départ et avance doucement...

Vous dites qu’une semaine peut comporter 2 ou 13 jours : je suppose que cette durée dépend du site.

En effet, si je comprends bien, le lundi 17 juin 2019 peut correspondre au 1er jour de la semaine 3 pour le site s1 et au 8e jour de la semaine 2 pour le site s2 : qu’en est-il ?

[NAGOL]

La durée dépend bien du site, et le cas que vous illustrez peut effectivement se présenter.

Une semaine est supposée durer idéalement 7 jours. Dans les faits, une flexibilité de +/-1 jour est donnée sur chaque site en cas d'impondérable (absence, panne, ...). Exceptionnellement, j'ai déjà rencontré un retard de 5 jour sur une semaine pour un site. La "semaine" a alors duré 12 jours... et la semaine suivante a duré 2 jours puisque le relevé a été fait à la date cible.

Pour prolonger votre exemple, les mesures qui sont prises le dimanche 16 juin 2019 sur le site s1 marquent la fin de la semaine 2 pour ce site, alors que la semaine 2 du site s2 se terminera au bout de son 9è jour (le mardi 18 juin). La date du 18 juin n'a alors pas de signification pour le site s1, et le 16 juin n'a pas de signification pour le site s2. Par contre j'ai pour chacun des sites une mesure qui correspond à la semaine 2.

[fsmrel]

Bonsoir,

La date du 18 juin n'a alors pas de signification pour le site s1, et le 16 juin n'a pas de signification pour le site s2. Par contre j'ai pour chacun des sites une mesure qui correspond à la semaine 2.

D’accord. Maintenant, pour parler de l’association MESURER, je vais utiliser le vocabulaire de E. F. Codd (père de la théorie relationnelle) et par commodité, parler de l’entité-type associative MESURER. Dans ce cadre, on dit que l’entité-type MESURER fait référence à l’entité-type PERIODE. En passant au stade MLD, c’est la table MESURER qui fait cette fois-ci référence à la table PERIODE. La représentation tabulaire est la suivante (pour ne pas encombrer je fais abstraction de l’appareillage), dans laquelle je reprends votre exemple des sites s1 et s2 faisant tous les deux référence à la semaine 2 (c’est-à-dire num_dans_annee = 6) de l’année 2109 :

PERIODE {id_periode    annee    num_dans_annee}
         p1            2018     1
         p2            2018     2
         p3            2018     3
         ...           ...      ...
         p12           2018     12
         p13           2018     13
         p14           2019     1
         p15           2019     2
         p16           2019     3
         p17           2019     4
         p18           2019     5
         p19           2019     6
         p20           2019     7
         ...           ...      ...

MESURER {id_site    id_periode    mesure}
         ...        ...           ...
         s1         p19           v1
         ...        ...           ...
         s2         p19           v2
         ...        ...           ...

Dans le contexte relationnel, par jointure des tables MESURER et PERIODE sur l’attribut id_periode, on saura que les mesures ont été effectuées dans la semaine 2 de l’année 2019, c’est-à-dire en théorie le mercredi 12 juin. Pour le site s2 qui déroge à la règle, il y a par exemple un retard de 3 jours : je suppose qu’il serait intéressant de prendre ce retard en compte, auquel cas l’ajout d’un attribut difference pour la table (donc l’entité-type) MESURER peut être envisagé, attribut prenant des valeurs négatives, positives ou zéro (cas normal).

Observation

Quelle obstacle à la suppression de l’entité-type PERIODE si on rapatrie les attributs annee et num_dans_annee dans MESURER ?

On passerait alors à la forme tabulaire suivante :

MESURER {id_site    id_mesure    annee    num_dans_annee    difference    mesure}
         ...       ...           ...      ...               ...           ...
         s1         m1           2019     6                 0             v1
         ...       ...           ...      ...               ...           ...
         s2         m2           2019     6                 +3            v2
         ...       ...           ...      ...               ...           ...

Où en compagnie de l’attribut id_site, l’attribut id_mesure participe à l’identifiant de MESURER (qui devient alors entité-type) puisqu’il s’agit de distinguer les 52 mesures faites au cours d’une année donnée pour un site donné. MESURER devient entité-type relative (weak entity-type chez Codd). Pour compléter le tableau, MESURER devra faire référence à APPAREIL.

Quant à fournir en clair la date de mesure, à partir des attributs annee, num_dans_annee et difference, au moyen des fonctions de calcul de dates proposés par les SGBD, ça ne devrait pas poser de problème.

MCD correspondant

L’entité-type MESURE est identifiée relativement à l’entité-type MESURE.



MLD

[escartefigue]

L’entité-type MESURE est identifiée relativement à l’entité-type MESURE.

Relativement à l'entité-type SITE bien sur d'où les parenthèses autour des cardinalités

Sans doute qu'à 3h31 les idées étaient un peu moins claires

François, pourquoi ne retiens-tu pas ma proposition n°6, qui permet de s'assurer que la mesure est bien réalisée par un appareil localisé dans le bon site ?

[NAGOL]

Bonjour à vous 2,

Quand je vois l'heure à laquelle la réponse a été postée, je ne peux qu'espérer ne pas nuire à votre repos avec mes questions... dans tous les cas, merci pour votre aide !

Il m'a fallu un certain temps pour réfléchir à la proposition de Fsmrel, qui m'amène à voir sous un angle nouveau mon problème. C'est très intéressant ! Escartefigue, vos propositions participent également à ma réflexion et me sont tout aussi précieuse. Pour développer votre suggestion concernant l'appareillage, je n'ai pour l'instant pas d'utilité à savoir que la mesure est bien réalisée par un appareil localisé dans le bon site, il n'y a pas d'erreur possible sur le terrain. L'idée est toutefois intéressante et peut m'amener à faire évoluer nos pratiques.

Pour en revenir à la proposition de Fsmrel, c'est probablement moi qui ai loupé une étape mais j'ai l'impression que j'y perd l'unité intra-période (que j'appelle "semaine"). Avec un tel modèle, il me semble pouvoir savoir à quelle période se rapporte une mesure donnée sans être en capacité de dissocier (= de rattacher à une occurrence différente) les 4 mesures "hebdomadaires" prises sur un même appareil au sein de cette période.

S'il y a erreur, c'est peut-être à cette étape du raisonnement (?)

je reprends votre exemple des sites s1 et s2 faisant tous les deux référence à la semaine 2 (c’est-à-dire num_dans_annee = 6) de l’année 2019

Là, "num_dans_annee = 6" signifie "la 6ème période de l'année 2019" : cette donnée ne porte pas d'information sur la semaine que l'on considère au sein de cette période. Si l'attribut "num_semaine" est ajouté à l'entité-type PERIODE il faudrait 4 occurrences portant un même "id_periode", ce qui n'est pas possible... J'imagine qu'il faudrait que l'entité-type MESURER fasse référence à l'entité-type SEMAINE faisant elle-même référence à l'entité-type PERIODE ?

[escartefigue]

Pour développer votre suggestion concernant l'appareillage, je n'ai pour l'instant pas d'utilité à savoir que la mesure est bien réalisée par un appareil localisé dans le bon site, il n'y a pas d'erreur possible sur le terrain. L'idée est toutefois intéressante et peut m'amener à faire évoluer nos pratiques.

Sur le terrain je ne sais pas, mais au niveau traitement informatique en tout cas c'est tout à fait possible.
Après si l'affectation de tel appareil sur tel site n'a pas d'intérêt pour vous, vous pouvez oublier cette contrainte

[NAGOL]

A l'heure actuelle, il m'importe seulement de savoir que les précipitations sont mesurées dans un pluviomètre. Pour pouvoir comparer les résultats entre sites, il faut que le matériel utilisé pour la mesure (dans cet exemple le pluviomètre) soit le même partout.

Je disais que votre proposition est intéressante car - avec l'arrivée de matériels de mesure électroniques - cela pourrait devenir pertinent, à l'avenir, de pouvoir identifier chaque exemplaire. Bien que tous les exemplaires seront identique en terme d'usinage, la composante électronique (sensibilité, étalonnage, ..) sera certainement variable entre exemplaires.

[fsmrel]

Bonsoir,

François, pourquoi ne retiens-tu pas ma proposition n°6, qui permet de s'assurer que la mesure est bien réalisée par un appareil localisé dans le bon site ?

Je n’avais pas encore lu ce qui concerne les appareils et en suis donc resté au 1er MCD proposé par NAGOL. Suite à ta remarque, ta proposition d’appareil hébergé par un seul site est évidemment pertinente : au hasard, pas de bilocation ! Néanmoins, un appareil n’est peut-être pas enraciné à jamais sur un site donné et intervient donc la dimension temporelle : au cours de la période p1, l’appareil a1 a été affecté au site s1, puis au site s2 au cours de la période p2. Votre avis à tous deux ?

N.B. J’ai passé un après-midi douloureux chez l’ophtalmo, donc je ne réponds que partiellement d’autant que j’ai répondu par ailleurs ici à une question d’une autre nature.

Je vais prendre un doliprane puis essayer de réfléchir aux questions posées par NAGOL...

[escartefigue]

Tout à fait d'accord sur la localisation éventuellement horodatée, j'avais d'ailleurs commencé à répondre en ce sens avant de me raviser, ne voulant trop anticiper sur un sujet encore mouvant.
Je m'étais fait cette reflexion en repensant au sujet passionnant qu'avait soumis Aras-VBO il y a quelques mois au sujet des observatoires astronomiques mobiles car installés de façon temporaire par des amateurs.

Bon rétablissement, les yeux, c'est important !

[escartefigue]

Du coup, en reprenant les éléments qui précedent, je pense qu'on peut repartir sur le MCD qui suit :

CALENDRIER 0,n-┐
.........................│
.........................│
SITE 0,n <-- disposer ---0,n APPAREIL 0,n --- effectuer --- (1,1) MESURE 1,1 --- correspondre --- 0,n PERIODE
..........................................│
..........................................1,1
..........................................│
..............TYPE_APPAREIL 0,n ┘

L'entité-type CALENDRIER n'est requise que pour générer la date comme composante de le PK dans la table issue de l'association "disposer" et ainsi répondre au cas de l'appareil qui change de site.
Avec DB-MAIN on peut directement intervenir sur l'identifiant sans avoir besoin de cet artifice (tout dépend du logiciel de modélisation donc)
La flèche vers l'entité-type SITE met en évidence l'unicité du site pour un couple CALENDRIER-APPAREIL, c'est une Contrainte d'Intégrité Fonctionnelle
Si toutefois les appreils sont installés de façon définitive sur un site, revenir à mon MCD précédent pour cette partie.

L'entité-type MESURE possèdera un attribut "date de mesure" soit la date réelle de cette mesure, même si celle-ci déborde de la période théorique à laquelle elle fait référence via la relation "correspondre" à une PERIODE
Je suis moins serein pour cette partie du modèle car je n'ai pas encore compris selon quel critère telle mesure (effectuée à telle date précise) est affectée à telle période plutôt que telle autre (compte tenu de la faculté d'une période d'avoir des contours mouvants). Désolé de trainer un peu en queue de peloton sur ce sujet
Afin d'éclairer ma lanterne : est il possible que pour un site et une période, certaines mesures (voire toutes) soient manquantes, si tel est le cas, il faudra déterminer comment on considère qu'une nouvelle mesure concerne non pas la première période pour laquelle il manque une mesure mais une autre période.

[NAGOL]

Cela vaut peut-être le coup que j'illustre plus encore mes propos pour rendre la situation aussi clair que possible (tout en suivant la maxime présente dans la signature de Fsmrel "Faire simple, mais pas plus simple").

Parmi 102 sites répartis en forêt française, 27 servent pour suivre les précipitations pluvieuses grâce à 1 pluviomètres et/ou 2 bacs à neige.
Parmi ces 27 sites, 14 servent également pour suivre les "pluvio-lessivats" (: la pluie qui passe au travers des feuilles des arbres), grâce à 3 gouttières et/ou 4 bacs à neige.

Les mesures ne sont pas automatisées et des personnes doivent se rendre tous les mercredi pour procéder aux mesures.

Les données issues du terrain sont donc hebdomadaires, mais l'écart entre 2 relevés peut être < ou > à 7 jours selon les impondérables rencontrés. Il peut également arriver que les relevés d'une semaine soit "manqués" quand le mercredi de la semaine suivante est atteint et que les mesures ne sont toujours pas prises (ces mesures sont donc "Null" pour tout ou partie des appareils du site, pour la semaine manquée).

Toutes les 4 semaines de relevés, nous clôturons une période. De cette sorte, une année est toujours divisée en 13 périodes de 4 semaines. Pour une même période, il nous est possible de comparer les mesures de tous les sites, qui sont équipés de manière identique et suivent les mêmes protocoles.

Pour les mesures de terrain, il faut être en mesure de savoir dans quelle période on se situe (aujourd'hui, période 347) ET quelle est la semaine au sein de cette période (aujourd'hui, semaine 1 sur 4).

Je vais griller une étape en annonçant que - par la suite - la composition chimique des pluies et des pluvio-lessivats sont analysés en laboratoire, après avoir été mélangés entre semaines 1 à 4, pour avoir un échantillon représentatif de la période. Mais je n'en suis pas là.

J'ai essayé "looping" pour représenter cela et j'en suis à ce point :


Je n'y ai pas mis la contrainte d'intégrité fonctionnelle "id_appareil, date -> id_site" car je n'ai pas encore vu comment l'intégrer via "looping".
Les identifications relatives me permettent d'identifier le site, l'appareil, la période et la semaine au sein de MESURE mais je fais une erreur car l'attribut "mesure" dans la clé primaire m'autoriserait à avoir 2 mesures différentes pour un même appareil lors d'une même semaine... Pas simple...

Et merci encore à vous pour le temps passé à m'aider !