Discussion :

[pierrot10]

Bonjour,
Je suis en pleine réflexion pour bien créer une base de données avec des tables.

La situation est la suivante.

J'ai un champs qui a plusieurs stations. Chaque station a 5 ou 6 capteurs et évidemment, je dois enregistrer les mesures dans une table.

Donc je pense créer 4 tables
- measures
- fields
- sensors
- stations

Mon questionnement est comment bien faire les liaisons entre ces bases de données.

1:n identifying relatioship?
1:n non-identifying relationship
n:m identifying relationship

Je voyais plus tôt utilier des 1:n non-identifying relationship, mais je me demande su la table 'sensors' ne devrait pas être une n:m., sachant qu'il peut avoir plusieurs sensors pour différentes stations? Dans le cas de cette table, je me demande quelle option entre 1:n ou n:m serait la mieux adaptée

Quand pensez-vous?

Voici une proposition/idée que j'ai rapidement fait avec BrenchMySQL


Merci pour vos lumières

[Invité]

...comment bien faire les liaisons entre ces bases de données...

J'ai envie de dire.... : "ça dépend" !

Ben oui... ça dépend des relations à mettre en place.
Il n'y a pas une formule magique ni universelle : c'est au cas par cas.

Exemple 1 : livres - auteurs

• 1 livre peut avoir un ou plusieurs auteurs
• 1 auteur peut écrire un ou plusieurs livres

Exemple 2 : voitures - marques

• 1 voiture NE peut avoir QU'UNE marque
• 1 marque peut décrire une ou plusieurs voitures

Et les flèches sur ton schéma ne doivent pas être n'importe où : elle doivent mettre en relation les ID.

On peut :

• avoir besoin d'une table de JOINTURE (exemple 1 : table t_livres_auteurs, contenant les colonnes id_livre et id_auteur)
• ou pas (exemple 2 : on peut mettre directement id_marque dans la table t_voitures)

N.B. oublie les "1:n identifying relatioship?", "1:n non-identifying relationship", "n:m identifying relationship", ... et utilise ta tête et la LOGIQUE.

[escartefigue]

Bonjour,
Je suis en pleine réflexion pour bien créer une base de données avec des tables.

Les tables sont une conséquence de la modélisation conceptuelle, pas un but en soi, commencez par le commencement à savoir la modélisation conceptuelle
Et pour celà il faut décrire exactement les règles de gestion, vous avez commencé à le faire, mais c'est insuffisant

Par exemple ci dessous :

J'ai un champs qui a plusieurs stations. Chaque station a 5 ou 6 capteurs et évidemment, je dois enregistrer les mesures dans une table.

Doit se traduire sous la forme
R001 : un champ est concerné par au moins une station
R002 : une station concerne un et un seul champ
ou bien
R002 : une station concerne un ou plusieurs champs
R003 : etc...

Selon le cas de la règle R002 vous aurez une table "champ" et une table "station" ou bien "champ", "station" et "concerner"

Mon questionnement est comment bien faire les liaisons entre ces bases de données.

Pour comprendre l'identification relative, il faut la aussi se positionner au niveau conceptuel, le MCD
Exemple typique: l'identification des chambres d'un hotel. La chambre n°125 n'a de sens que relativement à l'hotel dans laquelle elle se trouve, s'il n'y a plus d'hotel, il n'y a plus de chambre
On parle dans ce cas d'entité-type faible pour la chambre, l'hotel étant l'entité-type forte
Si on identifie la chambre relativement à l'hotel, alors l'identifiant de la chambre sera composé de l'identifiant de l'hotel+l'identifiant de la chambre
Autres exemples : les factures et lignes de factures, les commandes et lignes de commande etc...

Quand pensez-vous?

A peu près tout le temps, mais si la question est qu'en pensez vous, alors voir mes réponses ci-dessus
Ne m'en veuillez pas, j'aime bien taquiner sur ce chapitre

Voici une proposition/idée que j'ai rapidement fait avec BrenchMySQL

Le problème de MySQL est qu'il ne propose pas d'outil de modélisation conceptuelle, il attaque bille en tête avec le modèle logique et donc les tables, grave lacune.
Je vous conseille d'installer l'un des logiciels gratuits de modélisation (DBMAIN, JMERISE ou autre) pour commencer par le MCD, vous éviterez bien des erreurs

[Invité]

C'est sûr......

"ça dépend", ça dépasse....

[pierrot10]

Bonjour

Merci pour vos réponses

Alors pour etre plus précis dans la conception

• Il y a 8 (ou plus) capteurs

• 1 stations peut avoir 1 mais généralement les 8 capteurs

• 1 champs peut contenir un ou plusieurs stations (généralement plusieurs)

• 1 stations ne peut etre attribuer qu'à un champs, mais plusieurs champs peuvent avoir des stations identiques. (un peu comme trois voitures (=le champs) équipées du même autoradio (=la station) :o)

Aussi, la table qui est (pour moi la plus important) est la table 'measures', car c'est de cette table que les données seront extraites pour réalisé des graphiques comme celui-ci, par exemple http://www.smart-idea.io/chart-step/(les filtres ne fonctionne pas encore)

Merci pour votre aide!!

[escartefigue]

Dans ce nouveau modèle logique, vous avez ajouté une table "station_has_sensor" ce qui signifie implicitement les règles de gestion suivantes que vous n'avez pas rédigées :

Rnnn : une station a un ou plusieurs capteurs
ou bien
Rnnn : une station à zéro à plusieurs capteurs

et

Rppp : un capteur appartient à une ou plusieurs stations
ou bien
Rppp : un capteur appartient à zéro à plusieurs stations

Qu'en est il ?

De plus dans un champ, il peut y avoir différentes cultures en fonction de la période, il faut donc évacuer l'attribut culture de l'entité-type champ, et créer une relation à date entre champ et culture

Si CP est le code postal, il est préférable d'utiliser un type char(5) que du varchar

[pierrot10]

Hello
Merci beaucoup poue ta réponse

De plus dans un champ, il peut y avoir différentes cultures en fonction de la période

Ha oui . Je suis jutement en pleine réflection et je refais un schéma. Et je m'étais justement dit. Alors vu que j'ai l'art de me compliqué les choses, je me suis simplement.... on verra ca plus tard

Rnnn : une station a un ou plusieurs capteurs
ou bien
Rnnn : une station à zéro à plusieurs capteurs

Une station à au moin un capteur, mais elle au principalement 7 capteurs ou plus

Rppp : un capteur appartient à une ou plusieurs stations
ou bien
Rppp : un capteur appartient à zéro à plusieurs stations

Un capteur est connecté qu'a UNE station. Par exemple un capteur d'humidité du sol. Mais plusieurs stations peuvent avoir un capteur d'humidité du sol.

En réalisté chaque station aura au minimum
- 3 capteurs d'humidité du sol (à des profondeurs différente)
- 1 capteur de température du sol
- 1 capteur d'humidité de l'air
- 1 capteur de température de l'air
- 1 pluviometre
- 1 capteur de luminosité
- et encore en fonction du besoin/condition


Je reviens avec un autre conception de mes tables, car je me dis que la table des 'measures' devrait avoir une ligne par mesure. Puis avoir une table 'values' qui conteindra toutes les mesures avec une liaison avec la table 'measures', mais elle devrait aussi avoir une liaison avec la table 'sensors' et ' stations'..... Je suis en train de faire un schema

[pierrot10]

Re-bonjour.
Voilà. Si vous pouvez m'aider à partir dans la bonne direction, voilà comment j'imagine ma base de donnée.
J'espère avoir mis assez d'information!!!
Ensuite quand j'aurai maitrisé ceci. Je verrrai encore pour ajouter une table pour le type du terrain



Milles mercis pour vos lumières!!

[pierrot10]

Si non, l'autre idée serait d'extraire les mesures pour les afficher su ma page web, depuis la table sensors_has_values (ancienement values), mais là je pars un peu dans tous les senses...



Quel serait la meilleurs situation, à votre avis??

Milles mercis

[pierrot10]

Je me demande si je ne me suis pas trop trop compliqué la vie.
Ceci me semble plus simple, après tourner ma tête dans tous les sens , non?

Petit détail important: Je n'ai pas mis tous les champs, mais il est évident que dans la table 'measures', il y aura encore un champs 'measureid' pour identifier la mesure venant d'une station. (mesureid sera unique, il peut en avoir deux même id)
Pour être plus claire: le 2018-02-22 à 10:30:00, une mesure est prise (mesureid) qui en faite représente les mesures de tous les capteurs d'une station. Donc si mes stations ont 8 capteur, à 10:30 je prend une mesure, j'en aurai en fait 8, donc 8 enregistrements dans la table 'measures' avec le même 'mesuresid'. En fait toutes mes stations (4 pour l'exemple) enverrons 8 mesures. Donc à 10:30, j'aurai 32 nouveaux enregistrements avec 4 'mesuresid' différent. Une mesure étant prise par une station.






Edit: Ou alors, ma page web va questionner (requête MySQL) une station, qui elle va informer de ses capteurs et retourner ses valeurs ... Ca me semble plus logique...

[escartefigue]

Une station à au moin un capteur, mais elle au principalement 7 capteurs ou plus

Un capteur est connecté qu'a UNE station. Par exemple un capteur d'humidité du sol. Mais plusieurs stations peuvent avoir un capteur d'humidité du sol.

En réalisté chaque station aura au minimum
- 3 capteurs d'humidité du sol (à des profondeurs différente)
- 1 capteur de température du sol
- 1 capteur d'humidité de l'air
- 1 capteur de température de l'air
- 1 pluviometre
- 1 capteur de luminosité
- et encore en fonction du besoin/condition

Encore une fois écrivez toutes les règles de gestion avant d'attaquer la modélisation, croyez moi, vous y gagnerez beaucoup de temps

Plutôt que de parler de capteur, il me semble plus judicieux de parler d'instrument (de mesure), qui selon le cas est de type "capteur d'humidité au sol", "pluviomètre", "thermomètre" etc...
Ce qui donnerait les règles suivantes
Rxxx : un instrument est d'un et un seul type
Ryyy : un type d'instrument concerne zéro à plusieurs instruments
Rzzz : une station utilise un à plusieurs instruments
Ruuu : un instrument est utilisé par une et une seule station

Je suis en train de faire un schema

Bis repetita c'est trop tôt pour le schema, collectez les règles de gestion !
Et pensez à éliminer les synonymes, sources de confusion, choisissez un et un seul terme pour chaque objet du discours, par exemple soit "champ" soit "field" pas alternativement l'un ou l'autre

[Invité]

Bonjour,

Chaque capteur enregistre un type de mesure : humidité (air, sol,...), température,....
Il faut une table type_mesure, avec notamment l'unité à utiliser (%, ° degré celsius,.....)

• Chaque mesure est prise par un seul capteur, envoyée à une seule station, pour un champ donné, à une date donnée.
• Un capteur envoie ses données à une seule station
• Une station regroupe plusieurs capteurs
• Une station est dans un seul champ
• Un champ à plusieurs stations
• ...

Voilà comment tu dois réfléchir.
La construction des tables vient après.

Et pour éviter les confusions : arrête de mettre "id" dans toutes tes tables !
Écris id_champ, id_capteur, id_station,.....

Ce sont ces ids qu'il faut relier, d'une table à l'autre.

• Soit on peut mettre l'id directement dans la table (ex. id_type_mesure dans la table capteur)
• Soit on doit créer une table de liaison

[escartefigue]

Compte tenu des règles exprimées ou supposées, voici ce que je vous propose

Au niveau conceptuel, comme mentionné plus haut, une culture est à date, d'où l'externalisation de la culture et l'entrée en jeu d'une entité-type calendrier
J'ai identifié la station relativement au champ (présence des parenthèses autour des cardinalités), puisque si le champ est cédé, la station n'existe plus.
Il s'agit d'un MCD simplifié avec des attributs à minima, à vous de compléter

Pièce jointe 353427


Ce qui donne le MLD suivant
Pièce jointe 353431

Notez la présence de l'identifiant du champs comme composante de l'identifiant primaire de la station, conséquence de l'identification relative

[Invité]

@escartefigue
Inutile de compliquer la situation en ajoutant des conditions qui ne sont pas demandées.
La "culture" et "type de culture" n'ont rien à faire ici.

Quant au reste du schéma, il est cohérent.

Pour faire simple :

• 1 champ -> plusieurs stations - 1 station -> 1 seul champ : on peut mettre id_champ dans la table "stations"
• 1 station -> plusieurs capteurs - 1 capteur -> 1 seule station : on peut mettre id_station dans la table "capteurs"
• 1 capteur -> 1seul type de mesure : on met id_type_mesure dans la table "capteurs"
  1 capteur -> plusieurs mesures (à des dates différentes) - 1 mesure -> 1 capteur : on met id_capteur dans la table "mesures"

Maintenant, la prise des mesures et leur enregistrement.

le 2018-02-22 à 10:30:00, une mesure est prise (mesureid) qui en faite représente les mesures ...

Je pense qu'il faut une table "collectes" qui regroupe les infos liées à une collecte : date de prélèvement/mesure, conditions extérieures,... Mais PAS les mesures elles-mêmes.

Dans la table "mesures" on met id_collecte.
En effet les dates des mesures ne seront pas forcément égales à la seconde près.
Par contre, elles seront regroupées dans une seule "collecte"

On a donc ici les tables (simplifiées) :

- T_fields

• id_field (INT, Auto-Incrément)

- T_stations

• id_station (INT, Auto-Incrément)
• id_field (INT)

- T_mesure_types

• id_mesure_type (INT, Auto-Incrément)
• mesure_unite

- T_sensors

• id_sensor (INT, Auto-Incrément)
• id_station (INT)
• id_mesure_type (INT)

- T_collections

• id_collection (INT, Auto-Incrément)
• date_collection (DATETIME)

- T_measures

• id_mesure (INT, Auto-Incrément)
• id_collection (INT)
• id_sensor (INT)
• mesure_value (DECIMAL)

[escartefigue]

@escartefigue
Inutile de compliquer la situation en ajoutant des conditions qui ne sont pas demandées.
La "culture" et "type de culture" n'ont rien à faire ici.
Quant au reste du schéma, il est cohérent.

Sauf que dans les versions des post n°5, 8 et 10 d'hier soir, il y avait un attribut "culture" dans la table champ, j'avais mentionné que la culture ne peut être considérée qu'à date, d'où cette proposition.
Vu que le MLD a évolué moultes fois, je laisse le soin à Pierrot10 de choisir si oui ou non la notion de culture est encore requise.

Il en va de même pour la ville et le code postal, a externaliser dans une entité-type "ville" si toutefois ces attributs subsistent

[pierrot10]

Bonjour à tous,

Merci beaucoup pour votre aide.
Pour le moment, je veux pas compliqué les choses. En effet plus tard, je vais ajouter des tables, comme irrigation, culuture etc, mais je souhaited'abord me concentré sur le besoin actuelle et partir sur une bonne base.

Les deux derniere photos que j'ai mise, résume bien l'application que je veux faire.

Chaque mesure est prise par un capteur, dans un champ donné, à une date donnée.
Un capteur envoie ses données à une seule station
Une station regroupe plusieurs capteurs
Un capteur est dans un seul champ
Un champ à plusieurs capteurs

Oui c'est ca.

Une table 'fileds' qui liste mes champs
(je n'utiliserai plus un champs id, mais un champs id_field)
En soit cette table contient qu'un champ (pour le moment)
Elle peut avoir un ou plusieurs stations.

Une table 'stations' qui liste mes stations
(je n'utiliserai plus un champs id, mais un champs id_station)
Une stations peut avoir un ou plusieurs capteurs (généralement 8)
Un capteur est utilisé par une station


Une table 'sensors' (capteurs) qui liste mes capteurs
Un capteur est utilisé par une station, mais plusieurs stations peut avoir le même type de capteur
Il y a plusieurs type de capteurs (humidité, temperature, luminosité, pluviomètre, etc)
Exemple:
sensors_id : nom : type:id
-------------------------------
1 : nom du capteur 1 : type_id
2 : nom du capteur 2 : type_id
3 : nom du capteur 3 : type_id

Une table 'types' (type de capteur) qui va lister tous les types de capteur
exemple:
type_id : nom
1 : Humidité sol
1 : Humidité air
3 : temerature sol
4 : temperature air
5 : pression
6 : luminosité
7 : pluviometre
etc...


@jreaux62
Merci pour ta proposition de table que tu as posté aujourd'hui à 10:28. Je t'avoir ne pas avour eu le temps de me concentré sur ceci (je suis au travail...). Mais je me concentrai la dessus, ce soir. Mais voic deja comment je résume ta proposition

- T_fields
id_field (INT, Auto-Incrément)

- T_stations
id_station (INT, Auto-Incrément)
id_field (INT)

- T_sensors
id_sensor (INT, Auto-Incrément)
id_station (INT)
id_mesure_type (INT)

- T_mesure_types (Oui ca , c'est une bonne idée, car en effet, un capteur retourne une mesure avec des unités différente)
id_mesure_type (INT, Auto-Incrément)
mesure_unite

- T_collections (Ceci est aussi intéressant, je détaille plus bas)
id_collection (INT, Auto-Incrément)
date_collection (DATETIME)

- T_measures
id_mesure (INT, Auto-Incrément)
id_collection (INT)
id_sensor (INT)
mesure_value (DECIMAL)

En fait, une station chaque 20minutes une station prend une collection de 8 mesures. L'étudiant qui m'a demandé de l'aider, identifie cette collection comme l'id de la mesure, ce que moi j'ai nommé dans mes précédents message 'mesuresid'. Ce nommage porte à confusion, mais il faut pouvoir identifier une mesure, soit une collection de mesure. Donc pour éviter ce cafouillage, je ne parlerai plus de mesure mais de collection de mesures. La mesure étant la mesure proprement dite d'un capteur.

Donc une station prend une collection de mesures toutes les 10 minutes et je doit sauver ces mesures dans la table 'T_measures', pour ensuite faire un graphique comme j'ai commencé ici : http://www.smart-idea.io/chart-step/ et afficher les mesures en fonction du filtre...

Cependant, selon ta proposition, je nommerai plus tot T_sensor_types, au lieu de T_mesure_type (qu'en penses-tu) vu que T_mesure_type n'est liée qu'a T_sensors, et j'ajoureai encore le nom du type (humidité: unité, luminosité: unité).

Je pense qu'il faut une table "collectes" qui regroupe les infos liées à une collecte : date de prélèvement/mesure, conditions extérieures

Pour la tabée T_collections, j'avais aussi pensé à ca et je pense que ton idée est bonne . Ceci dit, les information sur les conditions extérieurs seront stockées dans la table T_measures (luminosité, pression, températeur, humidité)

- T_fields
id_field (INT, Auto-Incrément)

- T_stations
id_station (INT, Auto-Incrément)
id_field (INT)

- T_sensors
id_sensor (INT, Auto-Incrément)
id_station (INT)
id_mesure_type (INT)

- T_sensor_types (Oui ca , c'est une bonne idée, car en effet, un capteur retourne une mesure avec des unités différente)
id_sensor_type (INT, Auto-Incrément)
name
mesure_unite

- T_collections (Ceci est aussi intéressant, je détaille plus bas)
id_collection (INT, Auto-Incrément)
date_collection (DATETIME)

- T_measures
id_mesure (INT, Auto-Incrément)
id_collection (INT)
id_sensor (INT)
mesure_value (DECIMAL)

Miles milles miles mercis pour vos lumières, mais je dois me remettre au travail . Je me concentrai la dessus, ce soir !!!

Merciiiiiii

[Invité]

Quand je parlais de "conditions extérieures", ce n'était pas les conditions climatiques (encore moins les mesures prises par les capteurs), mais "extérieures à la notion de mesure".
Par exemple : identifiant du contrôleur, date de contrôle, un commentaire, une photo prise à ce moment là.... ou que sais-je encore...

Cela dit ça peut aussi être les moyennes calculées de chaque type de mesures, les mini/maxi,...

[pierrot10]

Merci jreaux62 et excartefigue.

J'arrive donc à ca


J'ai encore une question que je dois penser maintenant.
Le fichier json que l'on m'a donné à env 1 millions de lignes!! (qui comprends aussi les lignes de la syntaxe Json). Donc il y a beaucoup de mesure qui seront stockés dans la table T_measures.

Au niveau de la base que dois-je prévoir pour le nombre de requête?
Une table peut avoir autant de lignes? Quel est son maximum?

[escartefigue]

Bonjour,

Au niveau de l'assemblage des tables c'est OK

Par contre des mesures en varchar ca ne va pas il faut une colonne de type decimal, et comme vous mesurez des choses différentes (humidité, température, pression...) il faut impérativement associer une unité de mesure, soit au niveau de chaque mesure, soit au niveau de la sonde
Dans les deux cas, il est préférable de créer une table de typologie pour les unités de mesure

Vous auriez pu utiliser l'identification relative pour les mesures en constituant la PK de mesure avec id_sensor + id_mesure

EDIT : je n'avais pas vu que vous aviez mis l'unité de mesure dans "sensor_type", pourquoi pas mais il faut en ce cas être certain que par exemple les sondes de pression font bien toutes des mesures en hPa, il en suffit d'une qui mesure en millibars en bars en hauteur de mercure ou autre pour que ça ne tienne pas. Risqué donc. Quoi qu'il en soit, n'utilisez pas du varchar pour les colonnes de petite taille (les colonnes de code en général font moins de 10 caractères), le varchar présente de nombreux inconvénients au niveau performances et les codes ont souvent une longueur fixe, surtout si vous utilisez une codification normée (ISO par exemple)

[Invité]

... il faut une colonne de type decimal...

DECIMAL(6,2), par exemple

il faut impérativement associer une unité de mesure...

Ca, c'est fait dans sensor_types.

par exemple les sondes de pression font bien toutes des mesures en hPa, il en suffit d'une qui mesure en millibars en bars en hauteur de mercure

Dans ce cas, ce sont des types de capteurs différents. Avec une unité différente.
Pas de souci donc.

Inutile de compliquer inutilement.