Datenbanken sollten für Unternehmen arbeiten – nicht umgekehrt

ProjekteSoftware-Hersteller

Dr. Stefan Grotehans von MarkLogic erklärt im Gastbeitrag für silicon.de, worauf es bei der Datensammlung und Datenhaltung für IoT-Projekte und andere, datenintensive Vorhaben, ankommt, damit mit der großen Menge an Daten auch tatsächlich intelligentere Entscheidungen getroffen werden können.

Gartner sagt voraus, dass es spätestens 2020 “20 Milliarden IoT-Geräte geben wird, die Billionen von Dollar an Wert generieren werden”. So gut wie jede Branche ist davon bereits betroffen, vom Gesundheitswesen über den Finanzsektor über die Fertigungsindustrie bis hin zum Versicherungswesen. Die Herausforderung wird es sein, Herr der Daten zu werden und zu bleiben. Allein ein einziges vernetztes Auto erzeugt stündlich 25 Gigabyte an Daten — zum Beispiel über die Route, Geschwindigkeit, Fahrbahnbeschaffenheit und Motorleistung.

Dr. Stefan Grotehans (Bild: MarkLogic)
Dr. Stefan Grotehans, der Autor dieses Gastbeitrags für silicon.de, ist Director Sales Engineering DACH bei MarkLogic. (Bild: MarkLogic)

Es geht hier um die “echte” Welt, die Daten in Echtzeit produziert. Deshalb benötigen Unternehmen Datenbanken mit optimalen Mechanismen, um diese Daten so wie sie sind, zu verarbeiten um dann direkt umsetzbare Erkenntnisse zu erhalten. Gleichzeitig müssen Unternehmen Governance-Daten, Verlauf, Herkunft und Sicherheit im Auge behalten. Das ist insbesondere für das industriell genutzte IoT unerlässlich.

Hinzu kommt, dass diese Daten nicht in einem, sondern in vielen verschiedenen Systemen vorliegen. Diese Systeme werden in der Regel unabhängig voneinander entwickelt und haben die Tendenz, sich mit der Zeit zu vermehren. Deshalb existieren jetzt riesige Datenmengen in einer Vielzahl unterschiedlicher Systeme mit abweichenden Schemas und Semantiken.

Für Unternehmen ist es jedoch unmöglich, zielgerichtet Nutzen aus ihren Daten zu ziehen, wenn sie 70 Prozent ihres Budgets darauf verschwenden müssen, das System am Laufen zu halten. Wer es versteht, seine Daten wirklich optimal zu nutzen, wird die Mitbewerber dominieren. Deshalb müssen diese Daten alle irgendwie in ein und dieselbe Form gebracht werden, um sie gesamt nutzen zu können.

Data Architect (Bild: Shutterstock)

Der entscheidende Nachteil herkömmlicher, normalisierter Strukturen besteht darin, dass Entwickler und Anwender das Layout der Daten planen müssen, lange bevor die ersten Daten geladen oder die ersten Codezeilen geschrieben werden. Das ist ein extremer Nachteil, wenn es darum geht, Daten aus unterschiedlichen Systemen zu nutzen, die nicht auf Kompatibilität angelegt sind und oft noch nicht einmal etwas von der Existenz des anderen wissen. Die Folge sind eine sehr lange Amortisierungsdauer und geringe Agilität.

Wenn sich die Anforderungen oder die Daten ändern, eine neue Quelle hinzugefügt wird oder neue Fragen gestellt werden, müssen Mitarbeiter erneut dafür sorgen, dass alles wieder an das rigide Datenmodell angepasst wird. Diese Vorgehensweise ist zu langsam und umständlich, da Unternehmen in weltweiter Konkurrenz stehen, dauert dieser Prozess zu lange

Datenbanken müssen sich dieser Herausforderung stellen. Sie müssen Daten zu verschiedenen Entitäten, z. B. einem Kunden, einem Vermögenswert oder einem Patienten, aufnehmen und eine konsistente Rundumansicht dieser Entität ermöglichen. Sämtliche Daten zu einer Entität in einem einzelnen, denormalisierten Dokument zu speichern, ist ein wichtiger Schritt in die richtige Richtung. Dies ist ein Grund für verstärkte Nutzung von dokumentenbasierten Datenbanken.

Auf den Ansatz kommt es an

Ein eher rigider, dokumentenbasierter Ansatz reicht für die meisten Unternehmen nicht mehr aus. Angesichts des heutigen Geschäftstempos benötigen Anwender und die Datenbank eine größere Flexibilität, um innerhalb einer großen Bandbreite verteilter Systeme schneller reagieren und agieren zu. Damit die Datenbank eine größere Entlastung für den Anwender bietet, muss sie:

Einen Multimodell-Ansatz haben: Unternehmen nutzen eine Vielzahl unterschiedlicher Datentypen und -formate. Sie sollten aber nicht gezwungen sein, für jedes von ihnen ein eigenes System zu verstehen und zu verwalten oder ein Datenformat in einen Container zu zwängen, der eigentlich für ein anderes Format gedacht ist. Man stelle sich vor, eine einzige Desktop-Anwendung wäre ein Tabellenkalkulationsprogramm. Natürlich könnte man damit in Zeilen und Spalten auch ein Buch schreiben oder ein Beziehungsdiagramm darstellen, aber es gibt dafür sicherlich bessere Methoden. Auch in diesem Fall sind es die Menschen, die sich der Technologie beugen, und nicht umgekehrt.

Daten erfassen ist gut, Bedeutungen erfassen ist besser: Bei semantischen Datenmodellen liegt der Schwerpunkt auf den Beziehungen zwischen den Daten. Hierdurch entsteht kontextuelle Bedeutung, die es einfacher macht, Daten zu verstehen, zu durchsuchen und mit anderen zu teilen. Semantische Verfahren tragen dazu bei, Einschränkungen zu überwinden, und unterstützen Unternehmen dabei, ihren gesamten Datenbestand zu verstehen sowie ihren Erkenntnisgewinn zu steigern. Genutzt werden dazu Ontologien und Regeln zur Verknüpfung von Dokumenten, Daten und Tripeln, um tiefgreifendere Erkenntnisse zu ermöglichen und Chancen für intelligentere Anwendungen und Abfragen zu eröffnen.

Semantische Modelle lassen sich auf allen Ebenen einsetzen. Es geht darum, in welcher Beziehung verschiedene Daten miteinander stehen, welche Konzepte hinter den Daten stehen und wie sie mit anderen Daten in der Welt korrelieren. Dargestellt werden diese Beziehungen in einem Wissensdiagramm. Ironischerweise bieten „relationale Datenbanken“ nicht die Möglichkeit, semantische Beziehungen darzustellen. Dies ist ein entscheidender Nachteil.

Zweckmäßige Darstellung der Daten: Das Dokumentenmodell bietet dank seiner flexiblen und reichhaltigen Struktur großartige Möglichkeiten für die Darstellung von Daten; manchmal empfiehlt sich jedoch die Verwendung eines anderen Formats. Schon lange bevor es Computer überhaupt gab, wurden Tabellen erstellt und Zahlen in Spalten addiert. Das ist bei einigen Anwendungen die natürlichste Darstellungsweise. Da wäre es von Vorteil, wenn man Dokumente und Semantik kombinieren könnte, um real vorhandene Abteilungen mitsamt ihren Beziehungen untereinander äußerst exakt zu modellieren? Und wenn diese Daten gleichzeitig effizient in Tabellen oder Diagrammen darstellbar wären? Dadurch wären Unternehmen in der Lage, tatsächlich über ihre Business Units zu sprechen, und sie wären nicht gezwungen, die Begrifflichkeit zu benutzen, die ihnen ein zerstückeltes relationales Datenbankmodell auferlegt. Gleichzeitig profitieren sie bei Bedarf von den Vorteilen, die mit Tabellendaten verbunden sind.

Es gibt noch weitere Vorteile, die eine moderne, intelligente Datenbank bietet. Entscheidend dabei ist, der Datenbank zusätzliche Informationen in Form von Richtlinien, Absichten und Bedeutung zur Verfügung zu stellen. Mit diesen Attributen gewappnet, kann die Datenbank intelligentere Entscheidungen treffen, z. B. darüber, wie Daten am besten gespeichert, abgefragt und geschützt und auf welche Weise Cloud-Ressourcen am effizientesten genutzt werden. All dies trägt dazu bei, dass die Datenbank für das Unternehmen arbeitet — und nicht umgekehrt.