Étant donné que (a) les informations avec lesquelles vous travaillez semblent être, en soi, une ressource organisationnelle très précieuse, et (b) le volume de données sera considérable, je déciderais (c) de construire une base de données relationnelle sur l'un des les principales plateformes SQL.
Cela, bien entendu - dans une perspective très générale - requiert trois facteurs essentiels:
Un schéma conceptuel clairement défini , dans lequel il faut identifier et délimiter avec précision les prototypes de choses, c'est-à-dire les types d'entités (y compris leurs propriétés et leurs interrelations ) pertinents dans l'environnement commercial avec lequel vous travaillez (par exemple, les tours et Capteurs que vous mentionnez).
Comme vous le savez, ce point implique d'établir une communication continue et productive avec des experts métier.
Une disposition logique qui reflète le niveau conceptuel avec précision, au moyen de tableaux (c.-à-d. Des relations mathématiques) contenant des colonnes bien délimitées avec des noms et des types de colonnes appropriés (c.-à-d. Des attributs de relation) et toutes les contraintes correspondantes pour garantir la conformité des données toutes les règles déterminées au niveau précédent.
C'est donc ici que la grande puissance du modèle relationnel entre en jeu (bien que ses avantages aient des répercussions positives à d'autres niveaux d'abstraction).
Un agencement physique qui, par exemple, augmente la vitesse d'exécution des opérations de manipulation de données logiques «dynamiques» et garantit les contraintes logiques.
Étant donné que le modèle relationnel offre une indépendance physique des données , un système de gestion de base de données (SGBD pour plus de concision) peut fournir tout type de structure à ce niveau, pas exclusivement des index, pour prendre en charge les définitions logiques. Dans le cas des principales plates-formes SQL, oui, cela implique généralement, précisément, de mettre en place une stratégie d'indexation basée sur les tendances de requête spécifiques à la base de données, et vous avez soulevé des considérations très intéressantes en ce qui concerne certaines configurations possibles mais, sans connaître le particulier des nécessités informationnelles avec exactitude, offrant des conseils spécifiques à cet égard ne seraient pas appropriés.
D'autres éléments qui méritent une évaluation sont, par exemple, la mise à niveau de l'infrastructure réseau pour augmenter la bande passante, l'activation des configurations de serveur appropriées (au niveau matériel et logiciel), etc. Et, si, et seulement si, un praticien est suffisamment qualifié, il ou elle pourrait même modifier le code source du SGBD de son choix (plus réalisable dans les environnements open source, naturellement).
De cette façon, les aspects suivants que vous mettez en évidence
- Gérez et récupérez les configurations de tour / capteur pour donner un sens à l'analyse des données.
- Visualisation des données par capteur ou intervalles de temps pour les observations météorologiques.
- Fournir aux clients des ressources / ensembles de données fiables et persistants pour comparer les performances du modèle et du capteur (peut nécessiter un certain post-traitement pour être livré dans le format requis?).
serait bien traité, car vous seriez facilement en mesure de déclarer des requêtes pour, par exemple, obtenir des informations sous des formes très significatives. Par exemple, vous pouvez obtenir des données associées à
- le capteur identifié par SensorNumber
1750, installé dans la tour identifiée par TowerNumber 31, entre la date 1 June 2017et la date27 June 2017 .
De plus, puisque (1) les données d'une base de données relationnelle sont gérées logiquement en termes d' ensembles à l'aide d'opérations basées sur l' algèbre relationnelle , et (2) les différents moteurs SQL sont physiquement optimisés (certains plus que les autres) pour l' ensemble le traitement , vous pouvez, par exemple,
- comparer l'ensemble a avec l'ensemble b ;
- joindre l'ensemble c à l'ensemble d ;
- obtenir le sous- ensemble f par une restriction sur l'ensemble e ;
- produire n sous-ensembles à partir de n intersections d'ensemble;
- projeter n attributs de l'ensemble f
- récupérer des informations de l'ensemble z qui sont le résultat d'une union de l'ensemble x avec l'ensemble y ;
- etc.
Les possibilités de manipulation des données sont en effet énormes - démontrant la polyvalence inégalée du paradigme relationnel - puisque vous pouvez travailler non seulement avec des tables de base (celles déclarées avec des CREATE TABLE … ( … );instructions) mais aussi avec des tables dérivées (celles exprimées via des SELECT …;opérations, parfois fixées comme VIEWs) . En d'autres termes, vous pouvez (i) exprimer de nouvelles structures de données basées sur (ii) des précédentes opérant sur (iii) l'unique construction relationnelle sous-jacente, c'est-à-dire la relation mathématique.
De toute évidence, la disposition des tables et des colonnes de base d'une base de données relationnelle peut évoluer et (a) de nouvelles tables ou colonnes de base peuvent y être incorporées lorsque (b) le suivi de nouveaux types d'entité ou de propriétés de type d'entité est jugé utile dans le contexte commercial pertinent. En d'autres termes, ni la structure initiale ni les contraintes d'ouverture d'une base de données relationnelle ne devraient être statiques ou immuables. En outre, une base de données correctement organisée dès le début a tendance à être beaucoup plus facile à modifier lorsque de nouvelles exigences en matière d'information se présentent.
En accord avec les considérations ci-dessus, le format logique des ensembles applicables doit être produit de manière déclarative , au niveau logique de la base de données. La mise en forme graphique ou de présentation des ensembles (par exemple, les faces de coloration ou de police utilisées) doit à son tour être traitée au moyen du code d'un ou plusieurs programmes d'application (oui, principalement de manière procédurale , peut-être avec l'aide d'un objet -Oriented framework, HTML, etc.), afin de rendre l'accès et la présentation de tels ensembles conviviaux. Certes, vous pouvez également utiliser un logiciel de reporting qui se connecte à votre base de données.
La modélisation d'une base de données pertinente
Étant donné que vous travaillerez avec des données de capteur (qui, entre autres, impliquent généralement des informations sous la forme de séries chronologiques ), vous pouvez trouver de l'aide pour la conception de plusieurs bases de données et les principes généraux d'administration contenus dans les deux réponses exceptionnelles, par @PerformanceDBA , aux questions intitulées:
Les approches relationnelles, Flat File et NoSQL
Le modèle relationnel du Dr Edgar Frank Codd , bien que publié en 1970, reste véritablement la méthode la plus moderne et élégante (basée sur la logique et la théorie des ensembles) pour faire face au problème de la gestion des données. Les SGBD SQL distincts sont, à leur tour, les approximations les plus populaires (qui, bien que non entièrement conformes, sont néanmoins vraiment puissantes) aux systèmes proposés dans la théorie relationnelle, et certains d'entre eux ont été fortement optimisés (par exemple, en ce qui concerne leur physique). mécanismes de niveau) depuis des décennies, même maintenant. De plus, les principales plates-formes SQL peuvent bien sûr (et pourront) fonctionner de manière assez efficace avec les technologies de stockage (par exemple, les disques durs) et de traitement (par exemple, les CPU) les plus récentes.
Construite sur un SGBD puissant, une base de données relationnelle correctement conçue aux niveaux conceptuel, logique et physique deviendrait décidément un actif autonome, auto-descriptif et autoprotecteur qui (1) est digne de confiance et (2) offre un une réponse rapide, deux aspects qui, comme vous le savez, sont d'une grande importance.
Fichiers plats
Par conséquent, l'allégation qui suit
On m'a dit que la raison d'utiliser des fichiers plats était qu'ils pensaient qu'une base de données relationnelle prendrait trop de temps.
est facilement jeté, car l'approche du fichier plat serait:
- pré-scientifique;
- loin d'être optimal pour de gros volumes de données;
- trop lourd;
- dépendant du programme d'application (et vous devrez implémenter manuellement la plupart des fonctionnalités que les SGBD appropriés offrent nativement);
- ses performances seront facilement compromises;
- etc.
Alors que la mode relationnelle - beaucoup plus commode -, c'est le moins qu'on puisse dire:
- offrirait une grande évolutivité (elle est indépendante du niveau physique, vous pouvez donc améliorer les mécanismes physiques sous-jacents si nécessaire);
- apporterait un style simple pour manipuler les données (via des opérations abstraites ) et
- pourrait fonctionner avec plusieurs programmes d'application simultanément (par exemple, une ou plusieurs applications mobiles et / ou une ou plusieurs applications Web et / ou une ou plusieurs applications de bureau, etc.).
Si, cependant, vous optez pour l'utilisation de fichiers plats, vous devez évaluer l'emploi d'un utilitaire robuste comme Awk qui, bien qu'il ne s'agisse pas d'un SGBD (et n'a pas été conçu comme tel), fournit des ressources pratiques pour gérer les fichiers , les enregistrements , les champs , etc. Voir le Guide de l'utilisateur de GNU Awk pour plus d'informations à ce sujet.
NoSQL
«Données non structurées» et termes associés
Selon leur propagande, la justification initiale de l'utilisation des SGBD NoSQL est qu'ils sont destinés à être utilisés dans des domaines commerciaux qui impliquent le traitement de «données non structurées», de sorte que la question se pose:
- Que signifie l'expression «données non structurées»?
À cet égard, force est de constater que les données, de par leur nature même, sont structurées; s'il n'avait pas de structure, alors ce serait quelque chose de dénué de sens, par conséquent une telle chose (i) ne pourrait pas être considérée comme des données et (ii) ne serait pas la peine d'être administrée. Par conséquent, les «données non structurées» sont une expression contradictoire et malheureuse.
Une autre expression de ces contextes est «données semi-structurées». Cette phrase suggère qu'il existe des données structurées «en partie» ou «en deux». Ainsi, conformément au paragraphe précédent, seule la «partie» ou la «moitié» structurée peut être des données réelles, la «partie» restante ou «moitié» est simplement une chose informe car elle manque de structure et ne peut pas être appelée données.
Hélas, un autre terme typique que l'on retrouve dans le marketing NoSQL est «données polymorphes». Si ce terme signifie quelque chose comme «des données qui ont de nombreuses formes différentes», alors ce sont en fait des données ordinaires , elles se présentent sous de nombreuses formes distinctes comme toujours. Et comme il a de nombreuses formes différentes, il présente de nombreuses structures distinctes , il n'y a donc rien de spécial dans ce «type» de données.
Il va sans dire que les données et les structures de données ont toujours été susceptibles de changer , il n'y a donc rien d'inhabituel à cet égard non plus.
Croissance du volume de données
Évidemment, les volumes d'informations gérés au moyen de systèmes informatisés ont certainement augmenté au fil des ans - et continueront d'augmenter de façon exponentielle au fil du temps, car de nouveaux systèmes sont construits chaque jour -, mais c'est un fait qui n'a rien à voir avec la structure de l'information en soi .
Absence de fondement théorique arrondi
Une limitation critique des systèmes NoSQL (il existe différentes classes, par exemple, basées sur des documents et des graphiques ) est qu'aucun des produits actuels - bien que fortement commercialisés et étiquetés comme «modernes» - ne possède une base théorique solide (le cas échéant) qui prend en charge chacun des trois éléments les plus importants d'un SGBD approprié, c'est-à-dire les outils de définition des données (a), (b) de manipulation et (c) de constriction. Ainsi, l'approche NoSQL suggère en fait une régression vers une époque ancienne où le traitement des données était effectué de manière ad hoc et peu judicieuse, avec toute la complexité inutile qu'elle implique.
De nos jours, les systèmes de graphes sont inclus dans le spectre «NoSQL». Ces produits logiciels invitent à gérer les données en vertu d'opérations sur deux structures distinctes: les nœuds et les relations - qui, encore une fois, sont en conflit avec le terme «données non structurées» -, et ils se distinguent dans le groupe «NoSQL» parce qu'ils le font avoir une base mathématique. Cependant, les produits graphiques sont assez similaires aux plates-formes réseau , qui sont considérées comme obsolètes depuis des dizaines d'années (un inconvénient évident est que, comme suggéré ci-dessus, elles ont besoin de deux structures pour la représentation des données, tandis qu'un SGBD relationnel - selon le principe de l' information - n'en a besoin que d'un).
Même si la création des différents systèmes NoSQL est chronologiquement plus récente par rapport aux origines de la majorité des SGBD SQL, la plupart des concepts sur lesquels les produits NoSQL sont basés sont, en effet, primitifs .
Un programme NoSQL devrait être utilisé, principalement, dans des scénarios où, par exemple,
- le personnel informatique ne possède pas les compétences techniques requises pour déterminer (ou pour déterminer de manière opportune) la structure des données d'intérêt - par exemple, en raison de sa complexité -; et / ou
- l'organisation ne peut pas se permettre l'éducation et la formation appropriées pour le personnel actuel, ou ne peut pas embaucher de nouveaux employés qui possèdent l'éducation et la formation requises; et / ou
- lorsque l'intégrité et la cohérence des données ne sont pas particulièrement importantes; et / ou
- on ne s'attend pas à mélanger les données concernées avec celles des systèmes critiques qui nécessitent une grande précision.
Mais, même si la structure des données en cause n'est pas définie avant la création des systèmes concernés, une ou plusieurs personnes devront nécessairement
- découvrir la structure précitée,
- jeter toutes les «interférences» environnantes et
- collecter et lier les données appropriées
une fois que la base de données et les applications sont entrées dans la phase de production afin de pouvoir tirer le meilleur parti de toutes les ressources investies dans un projet, la délimitation de la structure des données est une tâche qui ne peut pas être contournée, elle doit être effectuée plus tôt ou plus tard.
Ainsi, tout en adoptant la méthode NoSQL est une possibilité, tous les facteurs mentionnés précédemment doivent certainement être pris en compte.
La méthode la plus robuste
En revanche, l'approche des exigences informationnelles d'un environnement commercial de manière relationnelle - c'est-à-dire avec un paradigme général derrière - offre les possibilités de (1) gérer les données dans sa structure naturelle dès le début - ce qui facilite l'intégration avec d'autres sources de données - et aussi de (2) produire de nouvelles structures fiables à force de manipuler un instrument unique - comme expliqué dans les sections précédentes - qui a une base scientifique solide.
Selon votre description du scénario en question, vous avez déjà identifié une structure particulière en termes de besoins organisationnels pertinents, je suggère donc de demander aux experts du domaine métier de la valider. Successivement, je recommande de profiter (i) des constructions - la relation, les contraintes et les opérations - fournies par le modèle relationnel pour gérer ladite structure et les données respectives, et (ii) de votre SGBD SQL de choix qui sera très probablement offrir des outils physiques très efficaces qui peuvent supporter les demandes actuelles et fourniront une évolutivité future.