Abstrakte Datenschicht
Die abstrakte Datenschicht, das einheitliche Systemdatenmodell, die Geräteabstraktion und die Datennormalisierung, die Anwendungen von der physischen Speicherung entkoppeln.
Die abstrakte Datenschicht liegt zwischen der physischen Speicherung der Daten und den Anwendungen, die sie nutzen. Sie abstrahiert die physische Umsetzung und die Hardwarespezifika und stellt eine einheitliche Schnittstelle für die Arbeit mit den Daten bereit. Sie bietet:
- Hardwareunabhängigkeit: Die Daten werden auf unterschiedlichen Geräten gespeichert (Server, Cloud, IoT-Geräte), doch die Anwendung greift über eine einheitliche Schnittstelle darauf zu.
- Einfachere Entwicklung: Entwickler arbeiten mit abstrakten Entitäten, ohne sich um die Details der physischen Speicherung kümmern zu müssen.
- Flexibilität: Änderungen an der physischen Struktur der Daten (etwa eine Migration in die Cloud) wirken sich nicht auf die Anwendungen aus.
Einheitliches Datenmodell
Das System verwendet ein einheitliches Datenmodell, das an unterschiedliche Gerätetypen angepasst ist und eine einheitliche Arbeit mit ihnen ermöglicht – unabhängig von ihrer Quelle oder ihrem Gerätetyp. Es umfasst gemeinsame Datenstrukturen, einheitliche Verarbeitungsregeln und die semantische Konsistenz der Daten über alle Systeme und Subsysteme hinweg.
Ein einheitliches Systemdatenmodell umfasst beispielsweise:
- Entitäten: Geräte, Kanäle, Sitzungen, Einheiten und Referenzparameter.
- Beziehungen: Geräte besitzen Kanäle, Kanäle stehen mit Daten in Beziehung und Daten stehen mit Sitzungen in Beziehung.
- Attribute: Für jede Entität sind Attribute definiert (zum Beispiel
equipment.serial_numberundchannel_data.value).
Aufbau des einheitlichen Systemdatenmodells
Das einheitliche Systemdatenmodell ist eine Struktur zum Speichern und Verwalten von Daten zu Geräten, Kanälen, Sitzungen und Messungen. Sehen wir uns jede Tabelle und ihren Zweck sowie die Beziehungen zwischen ihnen an.
Tabelle channel_data
Diese Tabelle speichert die Daten, die innerhalb bestimmter Sitzungen aus den Gerätekanälen empfangen werden.
| Feld | Typ | Beschreibung |
|---|---|---|
id | bigint | Eindeutige Datensatzkennung (Primärschlüssel). |
equipment_id | bigint | Verweis auf das Gerät (equipment.id). |
seance_id | bigint | Verweis auf die Sitzung (seances.id). |
channel_id | bigint | Verweis auf den Kanal (channels.id). |
unit_id | bigint | Verweis auf die Maßeinheit (units.id). |
archive_type_id | integer | Verweis auf den Archivtyp (referenceparameters.id). |
event_time | integer | Zeitpunkt des Ereignisses (z. B. Zeitstempel). |
value | character varying(100) | Der vom Kanal empfangene Wert. |
created_at | timestamp(6) without time zone | Zeitpunkt der Erstellung des Datensatzes. |
updated_at | timestamp(6) without time zone | Zeitpunkt der letzten Aktualisierung des Datensatzes. |
Beziehungen:
- Der Fremdschlüssel
unit_idverweist auf die Tabelleunits. - Der Fremdschlüssel
archive_type_idverweist auf die Tabellereferenceparameters. - Der Fremdschlüssel
equipment_idverweist auf die Tabelleequipment. - Der Fremdschlüssel
channel_idverweist auf die Tabellechannels. - Der Fremdschlüssel
seance_idverweist auf die Tabelleseances.
Tabelle units
Diese Tabelle speichert die für die Kanaldaten verwendeten Maßeinheiten.
| Feld | Typ | Beschreibung |
|---|---|---|
id | bigint | Eindeutige Datensatzkennung (Primärschlüssel). |
name | character varying(30) | Bezeichnung der Maßeinheit. |
varname | character varying(30) | Kurzer Variablenname für die Maßeinheit. |
description | character varying(100) | Beschreibung der Maßeinheit. |
conversion_factor | double precision | Umrechnungsfaktor für eine Maßeinheit. |
rounding | smallint | Anzahl der Nachkommastellen zum Runden. |
synonyms | character varying[] | Array von Synonymen für die Maßeinheit. |
created_at | timestamp(6) without time zone | Zeitpunkt der Erstellung des Datensatzes. |
updated_at | timestamp(6) without time zone | Zeitpunkt der letzten Aktualisierung des Datensatzes. |
Tabelle referenceparameters
Diese Tabelle speichert Referenzparameter wie Archivtypen oder andere Qualifizierer.
| Feld | Typ | Beschreibung |
|---|---|---|
id | bigint | Eindeutige Kennung des Datensatzes (Primärschlüssel). |
name | character varying(30) | Die Bezeichnung der Maßeinheit. |
varname | character varying(30) | Kurzer Variablenname für die Maßeinheit. |
description | character varying(100) | Beschreibung der Maßeinheit. |
parent_id | integer | Verweis auf den übergeordneten Parameter (Hierarchie). |
referencemodel_id | integer | Verweis auf das Verzeichnismodell. |
created_at | timestamp(6) without time zone | Zeitpunkt der Erstellung des Datensatzes. |
updated_at | timestamp(6) without time zone | Zeitpunkt der letzten Aktualisierung des Datensatzes. |
deleted_at | timestamp(6) without time zone | Zeitpunkt der Löschung des Datensatzes (Soft Delete). |
Beziehungen:
- Der Fremdschlüssel
parent_idverweist auf dieselbe Tabelle (referenceparameters.id) und ermöglicht so den Aufbau von Hierarchien.
Tabelle equipment
| Feld | Typ | Beschreibung |
|---|---|---|
id | bigint | Eindeutige Kennung des Datensatzes (Primärschlüssel). |
equipment_type_id | bigint | Verweis auf den Gerätetyp. |
serial_number | character varying(25) | Seriennummer des Geräts. |
manufacture_date | timestamp(6) without time zone | Herstellungsdatum des Geräts. |
installation_date | timestamp(6) without time zone | Installationsdatum des Geräts. |
program_version | character varying(100) | Softwareversion des Geräts. |
created_at | timestamp(6) without time zone | Zeitpunkt der Erstellung des Datensatzes. |
updated_at | timestamp(6) without time zone | Zeitpunkt der letzten Aktualisierung des Datensatzes. |
Tabelle channels
Diese Tabelle speichert Informationen über die Gerätekanäle.
| Feld | Typ | Beschreibung |
|---|---|---|
id | bigint | Eindeutige Kennung des Datensatzes (Primärschlüssel). |
equipment_type_id | bigint | Verweis auf den Gerätetyp (equipment_type.id). |
unit_id | bigint | Verweis auf die Maßeinheit (units.id). |
name | character varying(100) | Kanalname. |
varname | character varying(20) | Kurzer Variablenname für den Kanal. |
created_at | timestamp(6) without time zone | Zeitpunkt der Erstellung des Datensatzes. |
updated_at | timestamp(6) without time zone | Zeitpunkt der letzten Aktualisierung des Datensatzes. |
Beziehungen:
- Der Fremdschlüssel
equipment_type_idverweist auf die Tabelleequipment_type. - Der Fremdschlüssel
unit_idverweist auf die Tabelleunits.
Tabelle seances
Diese Tabelle speichert Informationen über die Kommunikationssitzungen des Geräts.
| Feld | Typ | Beschreibung |
|---|---|---|
id | bigint | Eindeutige Kennung des Datensatzes (Primärschlüssel). |
telemetry_id | bigint | Verweis auf die Telemetrie (telemetry.id). |
event_time | integer | Zeitpunkt des Ereignisses. |
evtid | smallint | Kennung des Ereignisses. |
trycnt | smallint | Anzahl der Versuche. |
tryfl | character varying(12) | Flag des Versuchs. |
state | smallint | Status der Sitzung. |
btm | integer | Batterieladung. |
rssi | integer | Signalstärke (falls verwendet). |
created_at | timestamp(6) without time zone | Zeitpunkt der Erstellung des Datensatzes. |
updated_at | timestamp(6) without time zone | Zeitpunkt der letzten Aktualisierung des Datensatzes. |
Allgemeine Struktur und Beziehungen
Haupttabelle – channel_data, die Kanaldaten mit Geräten, Sitzungen und Einheiten verknüpft.
Beziehungstabellen:
units– Maßeinheiten.referenceparameters– Archivtypen und andere Qualifizierer.
Gerätetabellen:
equipment– Geräteinformationen.channels– Gerätekanäle.
Sitzungstabelle – seances, die Informationen über Kommunikationssitzungen speichert.
Anwendungsbeispiel:
- Kanaldaten (
channel_data) stammen aus Geräten (equipment) innerhalb bestimmter Sitzungen (seances). - Jeder Kanal (
channels) verfügt über seine eigene Maßeinheit (units). - Der Archivtyp (
referenceparameters) legt fest, wie die Daten gespeichert oder verarbeitet werden sollen.
Vorteile eines einheitlichen Modells
Dieses Datenmodell bietet die Flexibilität und Skalierbarkeit, um Daten von unterschiedlichen Geräten zu speichern und zu analysieren.
Zu den Vorteilen eines einheitlichen Datenmodells zählen:
- Konsistenz: Die Daten besitzen über alle Systeme hinweg dieselbe Struktur und Semantik.
- Skalierbarkeit: Neue Datenquellen oder Gerätetypen lassen sich leicht hinzufügen.
- Datenschutz: Einheitliche Mechanismen für Authentifizierung, Autorisierung und Verschlüsselung.
- Einfachere Analyse: Die Daten lassen sich mit einheitlichen Werkzeugen analysieren.
Geräteabstraktion
Die Geräteabstraktion ist ein zentrales Konstruktionsprinzip des Systems, das die Logik der Datenverarbeitung von den physischen Eigenschaften der Geräte trennt. Dies ist besonders bei Systemen wichtig, die heterogene Geräte einsetzen.
Geräteabstraktion bedeutet, dass das System die Daten auf einer logischen Ebene verarbeitet, die von den physischen Geräten unabhängig ist, auf denen die Daten gespeichert oder verarbeitet werden. Erreicht wird dies durch:
- Vereinheitlichung der Schnittstellen: Eine einheitliche Art des Datenzugriffs, unabhängig vom Gerät.
- Verbergen der Umsetzungsdetails: Der physische Speicherort der Daten, die Übertragungsprotokolle und weitere technische Aspekte bleiben vor den Anwendungen verborgen.
- Adapter: Umwandlung der Daten aus einem gerätespezifischen Format in ein einheitliches Format.
Umsetzung der Geräteabstraktion
Das folgende Beispiel zeigt, wie dieser Ansatz in unserem System umgesetzt wird. Es verfolgt die Daten von einem IoT-Gerät über einen Adapter in das einheitliche Datenmodell und über die API wieder hinaus.
Betrachten wir ein IoT-Gerät, das Daten zum Gasverbrauch sendet. Die implementierten Algorithmen ermöglichen es uns:
- Die Daten über einen Adapter vom Gerät zu empfangen.
- Sie in eine
channel_data-Struktur umzuwandeln. - Sie in einer Datenbank zu speichern.
- Den Zugriff auf die Daten über eine API bereitzustellen.
Für jeden Gerätetyp werden Adapter erstellt, die gerätespezifische Protokolle verarbeiten und die Daten in ein einheitliches Format umwandeln.
Beispiel: Datentransformation
Bei einem IoT-Gerät können die Daten im JSON-Format eintreffen:
{
"device_id": "sensor-123",
"timestamp": 1739950861,
"value": 42.5
}Der Adapter wandelt die Daten in eine channel_data-Struktur um:
INSERT INTO channel_data (equipment_id, seance_id, channel_id,
archive_type_id, value, event_time)
VALUES (1, 2, 3, 4, '42.5', 1739950861);Datenabfrage:
GET /api/v1/channel_data?equipment_id=1&archive_type=daily&channel_id=3Antwort:
[
{
"id": 123,
"equipment_id": 1,
"seance_id": 2,
"channel_id": 3,
"archive_type_id": 4,
"value": 42.5,
"event_time": 1739950861
}
]Vorteile der Geräteabstraktion
- Hardwareunabhängigkeit: Anwendungen arbeiten mit den Daten, ohne zu wissen, wo diese physisch liegen.
- Flexibilität: Neue Geräte lassen sich leicht hinzufügen und bestehende leicht anpassen.
- Einfachere Entwicklung: Entwickler arbeiten mit abstrakten Entitäten, ohne sich um Hardwaredetails kümmern zu müssen.
- Skalierbarkeit: Die Daten können auf unterschiedlichen Geräten gespeichert werden, das System arbeitet dennoch einheitlich weiter.
Datennormalisierung
Datennormalisierung ist der Prozess, Daten in einer Datenbank so zu strukturieren, dass Redundanz minimiert und die Datenintegrität verbessert wird. Im Kontext der abstrakten Datenschicht spielt die Normalisierung eine zentrale Rolle bei der Erstellung eines einheitlichen, effizienten Datenmodells, das sich für die Verarbeitung unterschiedlicher Gerätetypen und Datenquellen nutzen lässt.
Die Datennormalisierung teilt die Daten in logische Tabellen auf und stellt Beziehungen zwischen ihnen her, um:
- Doppelte Daten zu vermeiden.
- Pflege und Aktualisierung der Daten zu vereinfachen.
- Die Datenintegrität sicherzustellen.
- Die Abfrageleistung zu verbessern.
Das einheitliche Datenmodell des Systems ist hinsichtlich atomarer (skalarer) Werte auf die (dritte) Boyce-Codd-Normalform reduziert. Einige Entitäten des Datenmodells verwenden zusammengesetzte Strukturen, um die Verarbeitung seltener, nicht standardisierter Attribute zu optimieren.
Vorteile der Normalisierung
- Beseitigt Redundanz: Die Daten werden an einer Stelle gespeichert, wodurch Redundanz verringert wird.
- Datenkonsistenz: Die Wahrung der Datenkonsistenz wird vereinfacht.
- Flexibilität: Änderungen an der Datenstruktur lassen sich leicht vornehmen.
- Leistung: Die Abfrageleistung wird verbessert (in den meisten Fällen).
Normalisierung im Kontext der abstrakten Datenschicht
Die Datennormalisierung ist ein wichtiger Schritt beim Entwurf der abstrakten Datenschicht.
Sie ermöglicht es Ihnen:
- Ein einheitliches Datenmodell zu erstellen, das sich für die Verarbeitung unterschiedlicher Gerätetypen nutzen lässt.
- Redundanz und Datenduplizierung zu vermeiden.
- Die Datenintegrität und -konsistenz unabhängig von der Quelle sicherzustellen.
- Die Integration neuer Geräte und Systeme zu vereinfachen.
Verwandte Themen
War diese Seite hilfreich?
Danke für dein Feedback!