Couche d'abstraction des données
La couche d'abstraction des données, le modèle de données unifié du système, l'abstraction des équipements et la normalisation des données qui découplent les applications du stockage physique.
La couche d’abstraction des données s’intercale entre le stockage physique des données et les applications qui les utilisent. Elle masque l’implémentation physique et les spécificités matérielles en offrant une interface unique pour exploiter les données. Elle apporte :
- L’indépendance vis-à-vis du matériel : les données sont stockées sur des dispositifs variés (serveurs, le nuage, dispositifs IoT), mais l’application y accède au travers d’une interface unique.
- Un développement simplifié : les développeurs manipulent des entités abstraites sans se soucier des détails du stockage physique.
- De la souplesse : les modifications de la structure physique des données (par exemple, une migration vers le nuage) n’ont aucune incidence sur les applications.
Modèle de données unifié
Le système s’appuie sur un modèle de données unifié, adapté aux différents types d’équipements, qui permet de les exploiter de manière homogène, quelle que soit leur source ou leur nature. Il comprend des structures de données communes, des règles de traitement uniformes et une cohérence sémantique des données dans l’ensemble des systèmes et sous-systèmes.
À titre d’exemple, un modèle de données unifié du système comprend :
- Des entités : équipements, canaux, séances, unités et paramètres de référence.
- Des relations : un équipement possède des canaux, les canaux sont liés aux données, et les données sont liées aux séances.
- Des attributs : des attributs sont définis pour chaque entité (par exemple,
equipment.serial_numberetchannel_data.value).
Structure du modèle de données unifié du système
Le modèle de données unifié du système est une structure de stockage et de gestion des données relatives aux équipements, aux canaux, aux séances et aux mesures. Examinons chaque table et son rôle, ainsi que les relations qui les unissent.
Table channel_data
Cette table stocke les données reçues des canaux des équipements au cours de séances déterminées.
| Champ | Type | Description |
|---|---|---|
id | bigint | Identifiant unique de l’enregistrement (clé primaire). |
equipment_id | bigint | Référence à l’équipement (equipment.id). |
seance_id | bigint | Référence à la séance (seances.id). |
channel_id | bigint | Référence au canal (channels.id). |
unit_id | bigint | Référence à l’unité de mesure (units.id). |
archive_type_id | integer | Référence au type d’archive (referenceparameters.id). |
event_time | integer | Heure de l’événement (par ex. horodatage). |
value | character varying(100) | Valeur reçue du canal. |
created_at | timestamp(6) without time zone | Date de création de l’enregistrement. |
updated_at | timestamp(6) without time zone | Date de dernière mise à jour de l’enregistrement. |
Relations :
- La clé étrangère
unit_idréférence la tableunits. - La clé étrangère
archive_type_idréférence la tablereferenceparameters. - La clé étrangère
equipment_idréférence la tableequipment. - La clé étrangère
channel_idréférence la tablechannels. - La clé étrangère
seance_idréférence la tableseances.
Table units
Cette table stocke les unités de mesure utilisées pour les données des canaux.
| Champ | Type | Description |
|---|---|---|
id | bigint | Identifiant unique de l’enregistrement (clé primaire). |
name | character varying(30) | Nom de l’unité de mesure. |
varname | character varying(30) | Nom de variable abrégé pour l’unité de mesure. |
description | character varying(100) | Description de l’unité de mesure. |
conversion_factor | double precision | Facteur de conversion d’une unité de mesure. |
rounding | smallint | Nombre de décimales à conserver lors de l’arrondi. |
synonyms | character varying[] | Tableau des synonymes de l’unité de mesure. |
created_at | timestamp(6) without time zone | Date de création de l’enregistrement. |
updated_at | timestamp(6) without time zone | Date de dernière mise à jour de l’enregistrement. |
Table referenceparameters
Cette table stocke des paramètres de référence tels que les types d’archives ou d’autres qualificatifs.
| Champ | Type | Description |
|---|---|---|
id | bigint | Identifiant unique de l’enregistrement (clé primaire). |
name | character varying(30) | Nom de l’unité de mesure. |
varname | character varying(30) | Nom de variable abrégé pour l’unité de mesure. |
description | character varying(100) | Description de l’unité de mesure. |
parent_id | integer | Référence au paramètre parent (hiérarchie). |
referencemodel_id | integer | Référence au modèle de répertoire. |
created_at | timestamp(6) without time zone | Date de création de l’enregistrement. |
updated_at | timestamp(6) without time zone | Date de dernière mise à jour de l’enregistrement. |
deleted_at | timestamp(6) without time zone | Date de suppression de l’enregistrement (suppression logique). |
Relations :
- La clé étrangère
parent_idréférence la même table (referenceparameters.id), ce qui permet de construire des hiérarchies.
Table equipment
| Champ | Type | Description |
|---|---|---|
id | bigint | Identifiant unique de l’enregistrement (clé primaire). |
equipment_type_id | bigint | Référence au type d’équipement. |
serial_number | character varying(25) | Numéro de série de l’équipement. |
manufacture_date | timestamp(6) without time zone | Date de fabrication de l’équipement. |
installation_date | timestamp(6) without time zone | Date d’installation de l’équipement. |
program_version | character varying(100) | Version logicielle de l’équipement. |
created_at | timestamp(6) without time zone | Date de création de l’enregistrement. |
updated_at | timestamp(6) without time zone | Date de dernière mise à jour de l’enregistrement. |
Table channels
Cette table stocke les informations relatives aux canaux des équipements.
| Champ | Type | Description |
|---|---|---|
id | bigint | Identifiant unique de l’enregistrement (clé primaire). |
equipment_type_id | bigint | Référence au type d’équipement (equipment_type.id). |
unit_id | bigint | Référence à l’unité de mesure (units.id). |
name | character varying(100) | Nom du canal. |
varname | character varying(20) | Nom de variable abrégé pour le canal. |
created_at | timestamp(6) without time zone | Date de création de l’enregistrement. |
updated_at | timestamp(6) without time zone | Date de dernière mise à jour de l’enregistrement. |
Relations :
- La clé étrangère
equipment_type_idréférence la tableequipment_type. - La clé étrangère
unit_idréférence la tableunits.
Table seances
Cette table stocke les informations relatives aux séances de communication des équipements.
| Champ | Type | Description |
|---|---|---|
id | bigint | Identifiant unique de l’enregistrement (clé primaire). |
telemetry_id | bigint | Référence à la télémétrie (telemetry.id). |
event_time | integer | Heure de l’événement. |
evtid | smallint | Identifiant de l’événement. |
trycnt | smallint | Nombre de tentatives. |
tryfl | character varying(12) | Indicateur de la tentative. |
state | smallint | État de la séance. |
btm | integer | Charge de la batterie. |
rssi | integer | Puissance du signal (le cas échéant). |
created_at | timestamp(6) without time zone | Date de création de l’enregistrement. |
updated_at | timestamp(6) without time zone | Date de dernière mise à jour de l’enregistrement. |
Structure générale et relations
Table principale — channel_data, qui relie les données des canaux aux équipements, aux séances et aux unités.
Tables de relation :
units— unités de mesure.referenceparameters— types d’archives et autres qualificatifs.
Tables d’équipement :
equipment— informations sur les équipements.channels— canaux des équipements.
Table des séances — seances, qui stocke les informations relatives aux séances de communication.
Exemple d’utilisation :
- Les données des canaux (
channel_data) proviennent des équipements (equipment) au cours de séances déterminées (seances). - Chaque canal (
channels) possède sa propre unité de mesure (units). - Le type d’archive (
referenceparameters) détermine la manière dont les données doivent être stockées ou traitées.
Avantages d’un modèle unifié
Ce modèle de données apporte la souplesse et l’évolutivité nécessaires au stockage et à l’analyse de données issues d’équipements différents.
Parmi les avantages d’un modèle de données unifié, on peut citer :
- La cohérence : les données présentent la même structure et la même sémantique dans tous les systèmes.
- L’évolutivité : il est aisé d’ajouter de nouvelles sources de données ou de nouveaux types d’équipements.
- La protection des données : des mécanismes d’authentification, d’autorisation et de chiffrement unifiés.
- Une analyse simplifiée : les données peuvent être analysées à l’aide d’outils unifiés.
Abstraction des équipements
L’abstraction des équipements est un principe de conception fondamental du système, qui sépare la logique de traitement des données des caractéristiques physiques des équipements. Cela revêt une importance particulière dans les systèmes mettant en œuvre des dispositifs hétérogènes.
L’abstraction des équipements signifie que le système traite les données à un niveau logique, indépendant des dispositifs physiques sur lesquels elles sont stockées ou traitées. Cela repose sur :
- L’unification des interfaces : un mode d’accès unique aux données, quel que soit l’équipement.
- Le masquage des détails d’implémentation : l’emplacement physique des données, les protocoles de transmission et les autres aspects techniques sont masqués aux applications.
- Les adaptateurs : la conversion des données d’un format propre à l’équipement vers un format unifié.
Mise en œuvre de l’abstraction des équipements
L’exemple suivant illustre la manière dont cette approche est mise en œuvre dans notre système. Il suit le cheminement des données depuis un dispositif IoT, en passant par un adaptateur, jusqu’au modèle de données unifié, puis vers l’extérieur via l’API.
Considérons un dispositif IoT qui transmet des données de consommation de gaz. Les algorithmes mis en place permettent de :
- Recevoir les données du dispositif au travers d’un adaptateur.
- Les convertir en une structure
channel_data. - Les stocker dans une base de données.
- En donner l’accès via une API.
Pour chaque type d’équipement, des adaptateurs sont créés afin de gérer les protocoles propres au dispositif et de convertir les données vers un format unifié.
Exemple : transformation des données
Pour un dispositif IoT, les données peuvent arriver au format JSON :
{
"device_id": "sensor-123",
"timestamp": 1739950861,
"value": 42.5
}L’adaptateur convertit les données en une structure channel_data :
INSERT INTO channel_data (equipment_id, seance_id, channel_id,
archive_type_id, value, event_time)
VALUES (1, 2, 3, 4, '42.5', 1739950861);Requête de données :
GET /api/v1/channel_data?equipment_id=1&archive_type=daily&channel_id=3Réponse :
[
{
"id": 123,
"equipment_id": 1,
"seance_id": 2,
"channel_id": 3,
"archive_type_id": 4,
"value": 42.5,
"event_time": 1739950861
}
]Avantages de l’abstraction des équipements
- L’indépendance vis-à-vis du matériel : les applications exploitent les données sans connaître leur emplacement physique.
- La souplesse : ajout aisé de nouveaux dispositifs ou modification de ceux qui existent.
- Un développement simplifié : les développeurs manipulent des entités abstraites sans se soucier des détails matériels.
- L’évolutivité : les données peuvent être stockées sur des dispositifs différents, tandis que le système continue de fonctionner de manière homogène.
Normalisation des données
La normalisation des données est le processus d’organisation des données au sein d’une base de données de manière à réduire au minimum la redondance et à améliorer leur intégrité. Dans le contexte de la couche d’abstraction des données, la normalisation joue un rôle essentiel dans la construction d’un modèle de données unifié et efficace, capable de prendre en charge différents types d’équipements et de sources de données.
La normalisation des données répartit les données en tables logiques et établit des relations entre elles afin de :
- Éliminer les données dupliquées.
- Simplifier la maintenance et la mise à jour des données.
- Garantir l’intégrité des données.
- Améliorer les performances des requêtes.
Le modèle de données unifié du système est ramené à la (troisième) forme normale de Boyce-Codd pour ce qui concerne les valeurs atomiques (scalaires). Certaines entités du modèle de données recourent à des structures composites afin d’optimiser le traitement des attributs rares et non standard.
Avantages de la normalisation
- La suppression de la redondance : les données sont stockées en un seul endroit, ce qui réduit la redondance.
- La cohérence des données : le maintien de la cohérence des données est simplifié.
- La souplesse : il est aisé d’apporter des modifications à la structure des données.
- Les performances : les performances des requêtes sont améliorées (dans la plupart des cas).
La normalisation dans le contexte de la couche d’abstraction des données
La normalisation des données est une étape importante de la conception de la couche d’abstraction des données.
Elle permet de :
- Créer un modèle de données unifié, exploitable pour prendre en charge différents types d’équipements.
- Éliminer la redondance et la duplication des données.
- Garantir l’intégrité et la cohérence des données, quelle que soit leur source.
- Simplifier l’intégration de nouveaux dispositifs et systèmes.
Sujets connexes
Cette page vous a-t-elle été utile ?
Merci pour votre retour !