Discussion :

[kstor4U]

Salut,

Je suis en train de faire un site pour le monitoring de structures tels que des ponts, barrages et autres éléments de Génie Civil...
J'en suis à me demander quelle structure donner à ma base (MySQL).
Voici mes contraintes :

• Les capteurs appartiennent tous à un ouvrage (pont...)
• Un ouvrage peut avoir jusqu'à 200 capteurs
• Les capteurs envoient les données à 1Hz grand maximum
• Pour chaque mesure, il me faudra stocker la date
• Je peux avoir jusqu'à 10000 structures (si le site marche bien^^)
• Je peux créer autant de bases que nécessaire pour stocker ces mesures
• Je n'ai pas a faire de liaison entre les données de différents capteurs, la plupart des requêtes consisteront à rajouter des mesures et récupérer les valeurs d'un ou deux capteurs entre deux dates.

Du coup j'ai pensé à plusieurs possibilités :

• Faire une table qui regroupe tous les capteurs, avec un champ par capteur, comme les capteurs ne renvoient pas des mesures en même temps, la plupart des champs de chaque entrée seront vides
• Faire une table par élément qui regroupe tous les capteurs d'un élément avec un champ par capteur, comme les capteurs ne renvoient pas des mesures en même temps, la plupart des champs de chaque entrée seront vides
• Faire une table qui regroupe tous les capteurs, avec un seul champ "capteur" dans lequel, pour chaque entrée, je mettrai l'ID du capteur, il n'y aura aucun champ vide mais pour chaque entrée, j'écrirai l'ID du capteur en plus de la date et de la valeur
• Faire une table par élément qui regroupe tous les capteurs d'un élément avec un seul champ "capteur" dans lequel, pour chaque entrée, j'écrirai l'ID du capteur en plus de la date et de la valeur, ca permettrait de faire plusieurs tables plus légères que celle du dessus.
• Faire une table par capteur

Voilà, je ne sais pas si c'est très clair, n'hésitez pas à poser des questions.
Cette liste n'est surement pas exhaustive, n'hésitez pas à proposer des alternatives.
Je n'ai pas parlé de faire plusieurs bases (p.ex une par élément), mais au stade où j'en suis c'est tout à fait faisable.

Je vous remercie d'avance pour votre aide.


Roland

[escartefigue]

Bonjour,

Voici un sujet original, je n'ai pas souvenir de l'avoir déjà vu abordé ici

Il manque des précisions et probablement des acteurs.
Par exemple :
- Est-ce que tous les capteurs mesurent la même chose, que mesurent ils (pressions, températures, longueurs, durées...)
- Vous intéressez vous à différents types de capteurs, des sous-types, quelles sont les caractéristiques de ces appareils
- Idem pour les ouvrages, quels sont les types, sous-types d'ouvrages qui vous intéressent
- Tous les types de capteurs sont ils implantés dans tous les types d'ouvrages, sinon quelles sont les règles
- Ne souhaitez pas gérer des secteurs, sous-secteurs géographiques
- Y a-t- il d'autres éléments temporels (notion de saisons, de jours feriés, chomés...)
- Ne souhaitez vous pas gérer des notions de maintenance : date d'installation du capteur, de dernière révision, historique des interventions
etc...

[JPhi33]

Bonjour Roland,

Aurais-tu une première ébauche de schéma à proposer ?
J'ai noté les concepts de Structure (= Ouvrage), Capteur et Mesure (= Donnée). Le premier schéma devrait donc être simple.
Les questions d'Escartefigue pourront te guider dans un 2e temps pour enrichir le modèle si nécessaire.

[SQLpro]

Principe de base de la modélisation :
1) pas de NULL
2) pas de redondance
3) la modification d'une information ne doit pas impacter plus d'une ligne dans une seule table
Ce sont les règles d'or d'une modélisation qui vous donnera toutes les performances possible et toute la souplesse de requêtage.

Je peux créer autant de bases que nécessaire pour stocker ces mesures

Absurde... Aucune intérêt si ce n'est que de complexifier les requêtes, et la maintenance !

Je n'ai pas a faire de liaison entre les données de différents capteurs, la plupart des requêtes consisteront à rajouter des mesures et récupérer les valeurs d'un ou deux capteurs entre deux dates.

Du coup j'ai pensé à plusieurs possibilités :

Faire une table qui regroupe tous les capteurs, avec un champ par capteur, comme les capteurs ne renvoient pas des mesures en même temps, la plupart des champs de chaque entrée seront vides

Vous violez la règle 1

Faire une table par élément qui regroupe tous les capteurs d'un élément avec un champ par capteur, comme les capteurs ne renvoient pas des mesures en même temps, la plupart des champs de chaque entrée seront vides

Vous violez la règle 1

Faire une table qui regroupe tous les capteurs, avec un seul champ "capteur" dans lequel, pour chaque entrée, je mettrai l'ID du capteur, il n'y aura aucun champ vide mais pour chaque entrée, j'écrirai l'ID du capteur en plus de la date et de la valeur

C'est la bonne solution

Faire une table par élément qui regroupe tous les capteurs d'un élément avec un seul champ "capteur" dans lequel, pour chaque entrée, j'écrirai l'ID du capteur en plus de la date et de la valeur, ca permettrait de faire plusieurs tables plus légères que celle du dessus.

En multipliant les tables vous multiplier la complexité de requêtage et de maintenance de la base...

Faire une table par capteur

Pire que la précédent !!! En multipliant les tables vous multiplier la complexité de requêtage et de maintenance de la base...[QUOTE]

A +

Et pour vous former à la modélisation, n'hésitez pas à lire l'ouvrage co écrit par mon collègue C. Soutou et moi même :

[kstor4U]

Bonjour,

Désolé pour la réponse tardive, j'avais mal configuré les notifications...

Je crois que j'ai ma réponse. Je vais stocker toutes les données dans une seule table avec un champ date, un IDcapteur, un valeur et c'est tout. Par contre, j'imagine qu'il y a une limite de taille pour cette table ? Si je ne mplante pas, ça dépend du format de ma partition ?

Pour répondre aux autres questions :
-Les capteurs mesurent des tas de phénomènes mais toutes les valeurs sont numériques au même format, l'unité est stockée dans une table contenant les propriétés des capteurs
-Tous les capteurs sont susceptibles de se trouver sur tout type d'ouvrage
-Il y a des tas d'ouvrages différents mais il me semble inutile de chercher à les catégoriser (et très compliqué)
-Pour les secteurs géographiques, voire le client etc, tout est susceptible de changer...
-Pour ce qui est de la maintenance, les données se trouveront dans la table des propriétés du capteur

Au final j'aurai quatre tables :
-Capteurs avec (ID, type, unité, date d'installation, dernière révision, remarques...)
-Ouvrages avec (ID, type, date de construction, dernière tournée, remarques...)
-Ouvrages_capteurs avec (IDouvrage, IDcapteur), elle permettra de savoir quels capteurs sont liés à quels ouvrages
-Donnees avec (date, mesure, capteur)

Ma question concernait uniquement la table données, à savoir s'il vallait mieux la splitter ou en faire une seule. La réponse est claire.

Résolu et concore merci !

[JPhi33]

Bonjour,
Désolé pour la réponse tardive

C'est le moins qu'on puisse dire avec un retard de 14 mois !!

Bonjour,
Résolu et concore merci !

C'est l'essentiel.