Relationale Datenbanken meiden

In den 1980er Jahren wurden relationale Datenbanken im großen Stil entwickelt (vergl. Oracle, was sind Datenbanken?). Eine Ablageform von Daten, die sich vorallem dadurch auszeichnet, dass mit Tabellen gearbeitet wird und die einzelnen Datensätze in Reihen, die Datenfelder in Spalten organisiert sind. Hat man einen neuen Datensatz, zum Beispiel einen neuen Zählerstand, dann fügt man lediglich eine neue Reihe mit den Werten am Ende hinzu. Der Begriff „Relation“ kommt von einer anderen Eigenschaft: Häufig verwendet man Zeiger, von einem Datensatz in einer Tabelle zu einem anderen Datensatz in einer anderen Tabelle. So könnte bei einem Adressdatensatz in einer Tabelle der Namen und die Straße stehen sowie die Postleitzahl. In einer anderen Tabelle hingegen Postleitzahl und Ort. Nutzt man nun die Postleitzahl als „Relation“, so kommt man auf den Ortsnamen ohne den Wert doppelt speichern zu müssen. Der große Vorteil ist, man muss sich beim Speichern von Datensätzen wenig Gedanken machen, da diese immer in eine Tabelle kommen, die eine Struktur haben. Relationen (Verknüpfungen, Pointer) zu andern Tabellen werden nachgelagert betrachtet.

Der Nachteil der hieraus entsteht, ist dass man die Daten nur schwer „bereinigen“ kann, denn zum Beispiel aus der Ortstabelle kann man nicht einfach einen Ort löschen, da man zunächst schauen muss, ob der Datensatz (PLZ, Ort) noch von einer Anschrift „benötigt“ wird. Relationale Datenbanken sind daher hervorragend für die Ablage von transaktionellen Daten geeignet, die eine Konsitenz benötigen, können aber durch die relativ lose Verknüpfung nicht bereinigt werden. Ein Show-Stopper, wenn man mit DIDs als „globale“ Zeiger arbeiten möchte, denn ein Eintrag in einer Tabelle kann nicht wissen, ob es noch Zeiger gibt, die auf diesen Eintrag verweisen.

Arbeitet man am „Edge“, also den Endgeräten des Internets, so hat man nur begrenzt Speicherplatz zur Verfügung. Eine Datenstruktur, bei der es schwierig ist nicht mehr benötigte Daten zu entfernen, ist daher ungeeignet. Im Rahemen der Entwicklungen des ID-Ideal Projektes nutzen wir daher hauptsächlich Timeseries Datenstrukturen (verkettete Listen), sowie Graphen.

Einfacher Graph

Bei einem Graphen existieren einzelne Knoten, welche jeweils für einen Datensatz stehen. Schreibt man einen neuen Datensatz, so sind dessen Felder (Eigenschaften) zweitrangig, zunächst muss man die richtige Stelle finden, die der Datensatz im Graphen einnimmt. Werden im Schaubild es einfachen Graphen die Werte von allen 5 Eigenschaften benötigt, so muss man alle drei Knoten „abrufen“ und auslesen. Wobei ausgehend vom Knoten B kein Zeiger zu A oder C existiert – es ist somit nicht möglich alle Eigenschaften zu erhalten. Die Bereinigung von Graphen ist relativ leicht zu gestalten, da die Verknüpfung das relevante Element ist, kann jeder Knoten gelöscht werden, der nicht mehr von anderen Graphen referenziert wird. Bedeutet im Umkehrschluss allerdings auch, dass man alle Knoten kennen muss, die vorhanden sind. Auch hier würde theoretisch ein Problem bei der Verwendung von DIDs entstehen, da reingehende Zeiger auch von diesen nicht unmittelbar erkannt werden können.

Ein digitaler Stromzähler, wie er heute verbaut wird, ist in der Lage je Phase 6000 Messwerte pro Sekunde zu liefern. Diese in einen Graphen einzuordnen ist schlicht unmöglich, aber sie deshalb in einer relationale Datenbank abzulegen, ist auch keine Lösung. Der Schlüssel zum Erfolg liegt hierbei wieder in der Erkennung von Ereignissen (Events), die einem verraten, welche Daten aus einem Datenstrom benötigt werden. Im Anschluss, sobald das Ereignis eingetreten ist, den Datensatz in einem Graphen einzusortieren, ist dann nur noch ein geringer Aufwand.

Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

Inhalt nicht verfügbar.
Bitte erlauben Sie Cookies, indem Sie auf Übernehmen Sie auf das Banner