Comment ajouter une relation n:m ?

Version imprimable

11/09/2025, 00h59
pierrot10

5 pièce(s) jointe(s)

Comment ajouter une relation n:m ?

Bonjour,

Il y a quelques années, j'ai fait un schéma avec MySQLWorkbench, avec plusieurs tables et relation.
J'ai importé ce schéma dans MySQL ce qui a construit ma base de données, et j'ai maintenant une belle base de données qui fonctionne bien de depuis.

Dès que j'édite une table qui a une relation avec une autre, et que j'insère une saisie, j'ai un liste déroulante pour sélectionner ma relation
exemple:
Pièce jointe 670210

J'ai ajouté une relation n:m 'threshold' pour ajouter différents seuil d'alarm en finction du type de station

Pièce jointe 670209

Etant donné que ma base de données à beaucoup de donnée, je ne pense pas que je peux réimporter ce sachéma.

Dans ma base de donnée, je vais donc créer une nouvelle table 'thersholds',
Pièce jointe 670212
avec un champs 'stations_id_station' et 'stations_types_id_stations_type' et les et les champs 'label' et 'values'.
Mais je sais que je n'aurai pas un choix déroulant
exemple:
Pièce jointe 670211

J'aimerais bien donc créer cette table proprement et que dans MySQL considère cette relation.

Ne serait-il pas mieux d'exécuter une requête MySQL pour créer relation n:m en ligne de commande?
Pièce jointe 670213

Mais comment le faire sans créer un problème sur ma base de donnée, car j'ai vraiement beaucoup d'enregistrements

Merci
11/09/2025, 01h11
pierrot10

La challenge que j'ai, c'est que j'ai des niveaux de seuils pour des types de stations.

Par exemple, actuellement, j'ai des stations pour l'irrigation et des stations pour surveiller la température.
Les seuils sont différents, exemple:

température
label | value
===
-4° | -4
-3° | -3
-2° | -2
-1° | -1
0° | 0
1° | 1
2° | 2

Irrigation
label| value
===
0-10kPa | 10-20
10-30kPa|10-20
30-60kpa | 30-60

Si une station est de type 'irrigation', elle va utiliser les Threshold Irrigation, si elle est de type température elle va utiliser les threshold de -4 à 2

Mais je ne suis pas sûre je m'y prends bien.

Il faudrait avoir une table qui liste les seuils des températures et une autre qui liste les seuils de l'irrigation. Mais comment dire à la station en fonction de son type, la table 'des seuils' qu'elle doit utiliser???
11/09/2025, 07h43
escartefigue

2 pièce(s) jointe(s)
Bonjour,

Quand on veut modéliser correctement une base de données, la première des choses à faire est de rédiger les règles de gestion, c'est essentiel.
Pour ce faire, suivez ce fil de discussion dans lequel la réponse n°8 explique comment les rédiger.

Ici, si je comprends bien, les règles sont les suivantes (merci de confirmer et corriger si nécessaire)

R001 : une station est caractérisée par un et un seul type de stations
R002 : un type de stations peut caractériser zéro à plusieurs stations

R003 : un type de stations est limité par un à plusieurs seuils
R004 : un seuil limite un et un seul type de stations.

Si tel est bien le cas, le modèle conceptuel des données est le suivant :

Pièce jointe 670217

Ce qui donne le MLD suivant :

Pièce jointe 670216

Notes :
- j'ai utilisé des termes en français : il n'y a aucun intérêt à se compliquer la vie avec de l'anglais si le projet est francophone ;
- ce modèle est simplifié, il faut le compléter avec les attributs manquants ;
- j'ai proposé dans ce modèle une notion de seuil mini et maxi, à vous de voir si c'est opportun ;
- ici, le seuil est identifié relativement au type de station, le seuil étant une entité-type faible du type de station, d'où les cardinalités avec (R) entre parenthèses ;
- dans votre modèle, la station est en relation avec le seuil, c'est une erreur, le seuil ne doit être lié qu'au type de station, c'est par transitivité qu'on connait les seuils d'une station (en passant par son type) ;
- dans votre modèle, le type de station est associé à au moins une station, là aussi c'est le plus souvent une erreur : les typologies doivent autoriser un minimum de zéro, car à un instant "t" il est fort possible qu'on n'ait aucune occurrence d'un type.
EDIT : ce qui me surprend ici c'est l'absence de notion de sonde.

Habituellement, une station possède une à plusieurs sondes (sonde de température, de pression, de vitesse du vent...), chaque sonde est associée à une unité de mesure (° Celsius, millibar, m/s...) et éventuellement à des seuils
Ici vous ne parlez pas de sonde, est-ce normal ?
11/09/2025, 10h22
escartefigue

Attention aussi aux noms des colonnes et à leur typage.
Pour la valeur du seuil, "VALUE" est un mot réservé SQL, du coup, si on le choisit comme nom de colonne, il faudra encadrer celui-ci par des délimiteurs, ce qui est très pénible à l'usage.
À ce titre, utiliser l'anglais pour nommer les tables et leurs attributs augmente le risque de percussion avec les mots réservés SQL. Un argument de plus en défaveur de l'utilisation de l'anglais quand ce n'est pas contraint par un contexte international.
Utiliser un préfixe d'entité comme je le fais quand je suis libre de la codification élimine ce risque, par exemple, avec le préfixe SE utilisé pour la table des seuils SE_seuil, la colonne serait nommée SE_value et ainsi plus de probème avec les mots réservés et plus besoin de s'embêter avec les délimiteurs ;)

Également, un type char ou varchar est inadapté pour une mesure, il faudra un type numérique, probablement décimal ou éventuellement integer si ce sont des valeurs entières.
Je ne l'ai pas précisé dans mon modèle simplifié, mais une mesure doit être accompagnée de l'unité de mesure.
11/09/2025, 22h01
pierrot10

3 pièce(s) jointe(s)

Hello
Je vous remercie pour vos réponses. (Je lis votre message maintenant).
Entre temps, je me suis posé la question si je devais d'abord me consacrer aux utlisateurs.

Ma soucis de clareté, j'apporte plus de détails (j'aurais dû le faire avant) afin de comprendre les modifications que je dois apporter à ma base de donnée

Il y a quelques année j'ai mis en place de projets. Des stations étaient installés dans des terrains. (station météo, irrigation, et pour lutter contre le gel de printemps). Les mesures sont envoyées via le protocole LoRaWAN et elles sont sauvegardées dans une base de donnée. Ca fonctionne super bien :).

Sans trop de connaissances, j'ai fais une application pour SmartPhone avec Cordova.

Ces projets pilotes sont terminés, mais j'ai entrepris de refaire mon application pour SmartPhone avec React Native. Cette application a une API qui va faire des requetes sur ma base de données et retourner les resultats en JSON. J'affiche des status, des stations et les graph des mesures.

Pour revnir à mon sujet, je souhaite implémenter les Push Notification et améliorer le système d'alarme pour en recevoir sur le SmartPhone quand une mesure(s) est(sont) critiqe(s). Pour cela, le contrôles des mesures doit faire côté serveur pour une push notification soit envoyée aux téléphones.

Je dois donc modifier ma base de données pour avoir un nouveau tableau qui mémorise les valeurs seuil (thresholds). Cet après-midi, j'ai réalisé que j'ai pas assez réflaichi :), car ils ne faut pas que les nofications soient envoyés à TOUS les téléphones mais aux téléphones (utilisateur) qui est proriétaire d'un ou de plusieurs terrains. Donc, je pense qu'il faudrait que je penche sur les tables qui vont contenir les utilisateurs, avant...

J'avais déjà commencé ceci

Pièce jointe 670243
mais il faudra que j'efface ces deux tables et que je les recrée proprement, car apparement (je me trompe peut-être) MySQL ne fait pas la lisaion, puisque je n'ai pas menu déroulant pour sélectionner un utilisateur ou un terrain déja existant. Je dois saisir manuellement l'ID de mes users ou terrain
Pièce jointe 670244
alors que pour mes autres liaisons (par exemple, quand je crée un sonde) il me propose des choix.

Pour répondre à la question d'ecatefirgue, je vais essayer d'établir ces règles. J'espère bien faire :)

R001: Un terrain a des attributs qui définis sa position et la date de création
R002: Un terrain est attribué à un ou plusieurs comptes utilisateur.
R003: Un compte peut être attribué à plusieurs terrains
R004: Un terrain contient une ou plusieurs stations
R005: Un terrain peut avoir une ou plusieurs station
R006: Une station est représentée par un type (météo, irrigation, gel) et un type peut être attribué à plusieurs stations.
R006: Une station à plusieurs sondes et des sondes peuvent être attribuées à plusieurs station
R007: Une station conteint un valeur critique (threshod) qui dépend du type de terrain

Citation:

exemple:
gel: -5+ à 12° (si en dessous, génère un notification push)
irrigation: 0-10, 10-30, 30-60 (si en dehor de, génère un notification push)

NB:
Le seuil critique d'une batterie d'une station est la même pour toutes les stations et ne peut pas être paramètrée/chagée
Il n'y a pas de seiul critique pour une station météo. Ce n'est pas le sujet aujourd'hui, mais si je devait le faire, j'aurai un autre problème car une station météo à plusieurs sonde (vent, rayonnement solaire, température, pression, humidité)

R008: Une station pourrait changer de type, mais c'est un cas très très rare
R009: Une station gànère une alarme quand une sonde mesure une valeur critique est sauvegarde l'événement dans la table 'alarms'
R010: Une station mesure une collection de mesures toutes les 60mn (une collection de mesure est l'ensemble des mesures des sondes qui sont attachées à la station)
R011: Une sonde contient plusieurs mesures
R012: Une sondes contient plusieurs attributs (ID, nom, description, active, date de création)
R013: Une sonde peut contenir encore d'autres attributs pour la représentation graphique des mesures. Elle peut contenir une des ses valeurs (couleur, style du graph, épaisseur, etc). Ces attributs peuvent être attribués à plusieurs sondes.

Voilà ,j'espère avoir bien répondu à ta question en établissant des règles. Est-ce bien ce que tu demandes?
A mon avis, ce qui concerne ma problématique actuelle, soit d'ajouter des nouvelles tables, se sont les règles de R001 à R010, non?

J'aimerais donc bien créer mes nouvelles tables et avoir un choix comme lorsque je crée une sonde pour une station où j'ai le choix de sélectionner une station ou a type de sondes existants

Pièce jointe 670245

Ai-je raison de penser que si on n'a pas ce choix, la table n'est pas bien liée/créée?
12/09/2025, 07h57
escartefigue

Bonjour Pierrot10,

Merci pour les règles de gestion, ça va faciliter la compréhension et les échanges.

Je m'interrogeais sur l'absence de sondes, je vois qu'elles sont finalement bien présentes, mais, concernant ces règles :

Citation:

Envoyé par pierrot10

R006: Une station à plusieurs sondes et des sondes peuvent être attribuées à plusieurs station
R007: Une station conteint un valeur critique (threshod) qui dépend du type de terrain

Si j'arrive à comprendre facilement qu'une station contient plusieurs sondes, à l'inverse, j'ai du mal à imaginer comment une sonde peut être attribuée à plusieurs stations.
Habituellement, une station est localisée à un endroit précis et possède plusieurs sonde (par exemple : une sonde de température, une sonde de pression atmosphérique et un anémomètre pour la vitesse du vent)
Ce faisant, une même sonde ne peut être attribuée qu'à une seule station. Ou alors, il faut ajouter une notion temporelle pour pouvoir localiser telle sonde dans telle station à tel instant.

Concernant la règle R009 :

Citation:

Envoyé par pierrot10

R009: Une station génère une alarme quand une sonde mesure une valeur critique est sauvegarde l'événement dans la table 'alarms'

Cette règle implique que la valeur critique (le seuil donc ou "threshold") est liée à la sonde et non pas à la station.

À propos de la règle R010

Citation:

Envoyé par pierrot10

R010: Une station mesure une collection de mesures toutes les 60mn (une collection de mesure est l'ensemble des mesures des sondes qui sont attachées à la station)

Si la collection est porteuse d'attributs, alors il faut la matérialiser par une entité-type au niveau conceptuel (un rectangle du MCD), entité-type qui deviendra une table.
Si ce n'est pas le cas, on se contentera de collecter toutes les mesures d'une même heure et d'une même station pour constituer la collection par traitement et on oublie cette notion dans le modèle de données.
Bien évidement, chaque mesure doit être horodatée et ce qu'on ait ou non besoin de gérer des collections.

Relativement aux règle R011 à R013

Citation:

Envoyé par pierrot10

R011: Une sonde contient plusieurs mesures
R012: Une sondes contient plusieurs attributs (ID, nom, description, active, date de création)
R013: Une sonde peut contenir encore d'autres attributs pour la représentation graphique des mesures. Elle peut contenir une des ses valeurs (couleur, style du graph, épaisseur, etc). Ces attributs peuvent être attribués à plusieurs sondes.

Le terme "contient" est inapproprié, pour plus de clarté, on dira plutôt
R011 : une sonde effectue une à plusieurs mesures, chaque mesure étant horodatée.
R012 : une sonde possède des ou est caractérisée par ou est porteuse d'attributs
R013 : idem R012

Citation:

Envoyé par pierrot10

Ai-je raison de penser que si on n'a pas ce choix, la table n'est pas bien liée/créée?

Oui, le modèle n'est à priori pas conforme au besoin, sous réserve des réponses à mes questions ci-dessus
12/09/2025, 09h06
escartefigue

2 pièce(s) jointe(s)

Voici un modèle qui semble correspondre au besoin.

Je n'ai pour l'instant pas intégré la notion de collection, nous pourrons l'ajouter si le besoin est avéré.
La relation ternaire (PO_posseder) entre [TE_terrain], [PE_personne] et l'entité-type fictive [CA_calendrier] permettra de n'envoyer les alertes qu'aux personnes qui possèdent le terrain au moment de l'envoi (les anciens propriétaires n'étant probablement plus concernés).
[CA_calendrier] ne deviendra pas une table, elle n'intervient que pour faire participer la date à l'association, c'est pourquoi elle apparait entre parenthèses et n'est plus présente dans le MLD.

EL_element contiendra le type d'éléments mesurés (pression, température, vitesse du vent...) en association avec une unité de mesure (hectopascal, °C, m/s...)
ME_mesure contiendra les mesures proprement dites, l'unité de mesure de la mesure étant celle de l'élément mesuré par la sonde ayant effectué la mesure.

Ici j'ai considéré que les personnes sont toutes des personnes physiques avec un nom et un prénom, mais si certains propriétaires sont des personnes morales, alors il faudra enrichir le modèle.

Ce qui donne au niveau conceptuel :

Pièce jointe 670250

Et au niveau tabulaire :

Pièce jointe 670251
12/09/2025, 13h32
pierrot10

Hello

Merci pour tout. Je vais lire attentivement vos message ce soir.
J'ai rapidement lu une question

Citation:

Si j'arrive à comprendre facilement qu'une station contient plusieurs sondes, à l'inverse, j'ai du mal à imaginer comment une sonde peut être attribuée à plusieurs stations.

Oui j'ai bugué :aie: En effet, une station peut contenir plusieurs sondes, mais une sonde ne peut appartenir qu'a une station. Il peut avoir plusieurs mêmes sondes, mais évidemment que physiquement une sonde appartient à une station.

Je revins plus tard après avoir bien lu vos messages :D