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_number et channel_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.

ChampTypeDescription
idbigintIdentifiant unique de l’enregistrement (clé primaire).
equipment_idbigintRéférence à l’équipement (equipment.id).
seance_idbigintRéférence à la séance (seances.id).
channel_idbigintRéférence au canal (channels.id).
unit_idbigintRéférence à l’unité de mesure (units.id).
archive_type_idintegerRéférence au type d’archive (referenceparameters.id).
event_timeintegerHeure de l’événement (par ex. horodatage).
valuecharacter varying(100)Valeur reçue du canal.
created_attimestamp(6) without time zoneDate de création de l’enregistrement.
updated_attimestamp(6) without time zoneDate de dernière mise à jour de l’enregistrement.

Relations :

  • La clé étrangère unit_id référence la table units.
  • La clé étrangère archive_type_id référence la table referenceparameters.
  • La clé étrangère equipment_id référence la table equipment.
  • La clé étrangère channel_id référence la table channels.
  • La clé étrangère seance_id référence la table seances.

Table units

Cette table stocke les unités de mesure utilisées pour les données des canaux.

ChampTypeDescription
idbigintIdentifiant unique de l’enregistrement (clé primaire).
namecharacter varying(30)Nom de l’unité de mesure.
varnamecharacter varying(30)Nom de variable abrégé pour l’unité de mesure.
descriptioncharacter varying(100)Description de l’unité de mesure.
conversion_factordouble precisionFacteur de conversion d’une unité de mesure.
roundingsmallintNombre de décimales à conserver lors de l’arrondi.
synonymscharacter varying[]Tableau des synonymes de l’unité de mesure.
created_attimestamp(6) without time zoneDate de création de l’enregistrement.
updated_attimestamp(6) without time zoneDate 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.

ChampTypeDescription
idbigintIdentifiant unique de l’enregistrement (clé primaire).
namecharacter varying(30)Nom de l’unité de mesure.
varnamecharacter varying(30)Nom de variable abrégé pour l’unité de mesure.
descriptioncharacter varying(100)Description de l’unité de mesure.
parent_idintegerRéférence au paramètre parent (hiérarchie).
referencemodel_idintegerRéférence au modèle de répertoire.
created_attimestamp(6) without time zoneDate de création de l’enregistrement.
updated_attimestamp(6) without time zoneDate de dernière mise à jour de l’enregistrement.
deleted_attimestamp(6) without time zoneDate de suppression de l’enregistrement (suppression logique).

Relations :

  • La clé étrangère parent_id référence la même table (referenceparameters.id), ce qui permet de construire des hiérarchies.

Table equipment

ChampTypeDescription
idbigintIdentifiant unique de l’enregistrement (clé primaire).
equipment_type_idbigintRéférence au type d’équipement.
serial_numbercharacter varying(25)Numéro de série de l’équipement.
manufacture_datetimestamp(6) without time zoneDate de fabrication de l’équipement.
installation_datetimestamp(6) without time zoneDate d’installation de l’équipement.
program_versioncharacter varying(100)Version logicielle de l’équipement.
created_attimestamp(6) without time zoneDate de création de l’enregistrement.
updated_attimestamp(6) without time zoneDate de dernière mise à jour de l’enregistrement.

Table channels

Cette table stocke les informations relatives aux canaux des équipements.

ChampTypeDescription
idbigintIdentifiant unique de l’enregistrement (clé primaire).
equipment_type_idbigintRéférence au type d’équipement (equipment_type.id).
unit_idbigintRéférence à l’unité de mesure (units.id).
namecharacter varying(100)Nom du canal.
varnamecharacter varying(20)Nom de variable abrégé pour le canal.
created_attimestamp(6) without time zoneDate de création de l’enregistrement.
updated_attimestamp(6) without time zoneDate de dernière mise à jour de l’enregistrement.

Relations :

  • La clé étrangère equipment_type_id référence la table equipment_type.
  • La clé étrangère unit_id référence la table units.

Table seances

Cette table stocke les informations relatives aux séances de communication des équipements.

ChampTypeDescription
idbigintIdentifiant unique de l’enregistrement (clé primaire).
telemetry_idbigintRéférence à la télémétrie (telemetry.id).
event_timeintegerHeure de l’événement.
evtidsmallintIdentifiant de l’événement.
trycntsmallintNombre de tentatives.
tryflcharacter varying(12)Indicateur de la tentative.
statesmallintÉtat de la séance.
btmintegerCharge de la batterie.
rssiintegerPuissance du signal (le cas échéant).
created_attimestamp(6) without time zoneDate de création de l’enregistrement.
updated_attimestamp(6) without time zoneDate de dernière mise à jour de l’enregistrement.

Structure générale et relations

Table principalechannel_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éancesseances, 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 :

example.json
{
  "device_id": "sensor-123",
  "timestamp": 1739950861,
  "value": 42.5
}

L’adaptateur convertit les données en une structure channel_data :

example.sql
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 :

Request example
GET /api/v1/channel_data?equipment_id=1&archive_type=daily&channel_id=3

Réponse :

Response example
[
  {
    "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

Dernière mise à jour le

Cette page vous a-t-elle été utile ?