Adaptive Informationskontext-Management-Systeme (ICMS) und die CortexDB als erste ihrer Art
Die hochagile Wiederverwendung von Informationen wird erst durch die unabhängige und integrierte Verwaltung von Daten und Kontext ermöglicht. Diese ist von zentraler Bedeutung für verschiedene Geschäftszwecke und die Migration von Altsystemen. Die CortexDB zählt zu den ersten einer neuen Klasse von Informationsmanagement-Tools, die diese Art der Verwaltung ermöglichen.
Eine neue Definition von "Datenbank"
In mehr als dreißig Jahren als Vordenker im Informationsmanagement stelle ich fest, dass die meisten Fortschritte inkrementell sind und auf bestehenden Ideen aufbauen. Ich habe wirklich neuartiges Denken nur selten erlebt. Daher hat es mich sehr gefreut, ein kleines deutsches Softwareunternehmen zu treffen, das innovative und potenziell revolutionäre Ideen in sein Produkt integriert hat.
Die Cortex AG bezeichnet den Kern oder ihr Produkt CortexDB als Datenbank und als nicht weniger als ein "Multi-Model NoSQL DBMS". Ich glaube, sie verkaufen ihre Arbeit unter Wert. Der Fokus liegt auf Daten- und Datenbankmodellen, und die interne Struktur der Datenbank lenkt von dem grundlegenden Unterschied zwischen dem ab, was CortexDB tut, und dem, was alle früheren Datenbanken tun.
Die CortexDB ist das erste Beispiel für eine neue Klasse von Informationsmanagement-Tools, die es ermöglicht, Daten und Kontext unabhängig und integriert zu verwalten, eine Funktion, die für die Wiederverwendung von Informationen für verschiedene Geschäftszwecke von zentraler Bedeutung ist. Ich glaube, dass CortexDB das erste einer neuen Art von Produkten sein könnte: ein adaptives Informationskontext-Management-System (ICMS).
Um zu verstehen, warum und was das bedeutet, müssen wir uns die Geschichte der Datenbanken ansehen und auf eine alte Debatte zurückgreifen: den Unterschied zwischen Daten und Informationen – als Auftakt zur Neudefinition dessen, was CortexDB ist und kann [1].
Mitte der 1960er Jahre begannen die Forscher, Daten-Banken (aus dem engl. Data Bases) als Datensätze zu definieren, die von mehr als einer Anwendung verwendet werden konnten, anstatt für jede Instanz einen bestimmten Datenbestand zu verwenden [2]. Wenn Daten nur von einer Anwendung besessen und verwendet werden, können sie einfach und effizient als sequentielle Wertefolge gespeichert werden (wie eine CSV-Datei ohne Header). Wenn Sie Daten gemeinsam nutzen möchten, müssen Sie zumindest die einzelnen Felder benennen. Im Idealfall benötigen Sie auch eine Vorstellung von den logischen Zusammenhängen zwischen einzelnen Feldern. Datenspeicher wurden so zu Datenbanken, da diese "nackten" Datenwerte benannt, beschrieben und in hierarchische und später relationale Strukturen gegliedert wurden.
Diese Namen, Beschreibungen und Beziehungen sind kontextbezogene Informationen (context-setting information – CSI), auch Metadaten genannt. CSI bildet die Brücke zwischen Daten und Informationen. Ich verwende die folgenden Definitionen:
- Informationen: die aufgezeichneten und gespeicherten Symbole und Zeichen, mit denen wir die Welt und unsere Gedanken darüber beschreiben und miteinander kommunizieren. Informationen bestehen aus Daten und CSI. Es sind Informationen, die wir wirklich brauchen und als Menschen und Unternehmen nutzen.
- Daten: "Fakten"-Messungen, Statistiken, die Ausgabe von physikalischen Sensoren usw. – in Form von numerischen oder einfachen Textwerten. Ich setze "Fakten" in Anführungszeichen, um zu zeigen, dass Fakten selten so hart oder fixiert sind, wie wir annehmen; sie sind stark abhängig vom Bezugsrahmen derjenigen, die sie erschaffen und/oder speichern. Daher liegt CSI – als Darstellung dieses Bezugsrahmens – auch in der Verantwortung dieser Datenersteller.
Datenbank vs. Informationsbasis
Die obige Diskussion legt nahe, dass jede Datenbank irgendwo auf dem Spektrum von Daten bis Informationsmanagement liegt. Ein Key-Value-Speicher ist viel näher an den Daten. Eine relationale Datenbank mit einem vollständig ausgefüllten Satz von Beschreibungs-Tabellen ist den Informationen viel näher. Und weil Informationen das sind, was wir als Menschen brauchen, haben relationale Datenbanken die Informatik dominiert.
Es gibt jedoch eine zusätzliche Überlegung. Der Kontext – und damit die Bedeutung – jeder Information in einer Datenbank ist genau und nur das, was von ihrem/ihren Ersteller(n) beabsichtigt ist, einschließlich der Ingenieure, die die Daten verstehen, und der Business-Experten, die die beabsichtigte Nutzung (CSI) dieser Daten kennen. Die Verwendung der resultierenden Informationen für einen anderen Zweck kann zu Fehlern führen, wenn die von der zweiten Anwendung angenommene Bedeutung schlecht mit der für die erste Anwendung definierten übereinstimmt.
Genau das ist die Herausforderung, wenn wir Informationen aus dem operativen Umfeld in die Welt von BI bringen, obwohl beide auf relationalen Datenbanken basieren. Das grundlegende Problem ist, dass eine relationale Datenbank nur einen Kontext auf einmal darstellen kann: den ihres Erstellers. Infolgedessen müssen wir in der Welt von BI eine zweite Datenbank aufbauen und füllen, die den für analytische Aufgaben erforderlichen Kontext enthält. Tatsächlich stellen wir fest, dass wir mehrere Datenbanken für viele verschiedene analytische Zusammenhänge aufbauen müssen.
Ein zweites und dringenderes Problem für das moderne digitale Geschäft ist das Einbinden von extern bezogenen Daten. Hier werden Informationen aus dem externen Umfeld oft weitgehend de-kontextualisiert (z. B. in einer CSV-Datei), wenn sie über das Internet an das empfangende Unternehmen weitergegeben werden. Data-Wrangling ist in der Tat die Wiederherstellung des Kontextes, der für die Interpretation und Nutzung der eingehenden Daten erforderlich ist.
Das zugrundeliegende Problem ist in beiden Fällen das gleiche: Wir haben nicht erkannt, dass es mehrere Nutzungskontexte für denselben Basisdatensatz gibt. Der Datenbankersteller bettet den CSI (context-setting information) für sein ursprüngliches Nutzungsszenario in das Datenbankdesign ein. Darauffolgende Nutzungsszenarien stellen ein unterschiedliches Maß an Diskrepanz zu diesem ursprünglichen Design dar. Da die Nutzungsszenarien immer vielfältiger und komplexer werden, brauchen wir etwas mehr als eine traditionelle Datenbank, um den Mix und die Übereinstimmung der Nutzungen zu verwalten.
Ein Informationskontext-Management-System (ICMS)
Hier setzt die CortexDB an. Sie bietet ein System, das die Verwaltung von "nackten Daten" fast vollständig vom Management der CSI trennt und zudem sicherstellt, dass die beiden Bereiche bei Änderungen an dem einen oder anderen vollständig synchronisiert werden. Ich nenne dies ein adaptives Information Context Management System (ICMS).
CortexDB speichert die nackten Daten in einer Dokumentenablage, in der die einzige CSI die Namen der Felder und Datensatz-IDs für die Dokumente sind (Dies ist natürlich die Mindestanforderung für den Einstieg in die erweiterten CSI). Während dessen befindet sich die CSI in der 6. Normalform einer relationalen Struktur (6NF).
Im Falle unterschiedlicher Anwendungsbedürfnisse, die widersprüchliche Möglichkeiten der Datenbereitstellung erfordern, können mehrere CSI-Sets, die den Datenzugriff und die Verwendung auf inkompatible Weise strukturieren, problemlos parallel erstellt und gepflegt werden. Wenn Anwendungen Informationen auf die gleiche Weise verwenden, verwenden sie natürlich alle den gleichen Satz CSI.
Durch die Bereitstellung eines einzigen Speichers nackter Daten, der von mehreren CSI-Sets unterstützt wird, kann CortexDB sowohl operative/transaktionale Anwendungen als auch informationelle/analytische Anwendungen auf denselben Daten unterstützen (vorausgesetzt natürlich, dass die nackten Daten auf dem entsprechenden atomaren Detaillierungsgrad gespeichert werden).
Im Falle der Integration extern bezogener Informationen kann der anfängliche Datenspeicher mit nur minimalem Wissen darüber entworfen und erstellt werden, wie die eingehenden Daten intern miteinander verknüpft sind oder wie sie sich auf bestehende interne Daten beziehen. Diese Elemente von Kontext und Struktur können später und schrittweise hinzugefügt werden, wenn sich das Verständnis und die Verwendung dieser integrierten Daten weiterentwickelt.
Da die Programmierwelt die Regeln der agilen Entwicklung übernommen hat, muss nun auch die Datenverwaltung erfolgen.
Dieser letztgenannte Fall ist ein wichtiges Beispiel dafür, wie der vom Datenersteller (z. B. im Internet der Dinge) behauptete Kontext / die Bedeutung den späteren Nutzern der Daten (in diesem Fall innerhalb des empfangenden Unternehmens) weitgehend unbekannt sein kann. Hier bietet das ICMS die Möglichkeit, mehrere Möglichkeiten der Interpretation und Verwendung schlecht beschriebener Informationen zu definieren und zu erforschen. Da digitale Unternehmen immer mehr Daten erstellen und austauschen, wird dieses Problem immer häufiger auftreten.
Diese beiden wichtigen Bereiche der Informationsverarbeitung – und andere – vereinen sich darin, dass sie weitaus mehr und viel tiefere Agilität bei der Erstellung, Strukturierung und Nutzung von Daten erfordern als die traditionelle Datenverarbeitung. Da die Programmierwelt die Regeln der agilen Entwicklung übernommen hat, muss nun auch die Datenverwaltung erfolgen.
Agile Datengestaltung für das digitale Geschäft
Im oben beschriebenen Abschnitt schlug ich vor, dass CortexDB eher mehr als eine Datenbank ist. Vielmehr sehe ich sie als erstes Beispiel für ein adaptives Information Context Management System (ICMS).
Aus technologischer Sicht verwendet CortexDB eine Kombination aus SQL und NoSQL, um sowohl die Struktur als auch die Flexibilität, die Planung und die Agilität zu unterstützen, die ein ICMS auszeichnen. Auf diese Weise bietet sie den Unternehmen die Freiheit zu völlig flexiblen Arbeitsabläufen und die Fähigkeit, ihre Grundlagen zu verwalten.
Wie unser Gehirn, von dem das Produkt seinen Namen hat, ist CortexDB konzeptionell einfach. Die semantische Struktur aller Datentypen bleibt in einem document store erhalten [3], der automatisch in einer integrierten, relationalen sechsten Normalform (6NF) – einem mehrdimensionalen Index [4] – beschrieben und modelliert wird, der auf jedes Datenelement in jedem Dokument in der Ablage zeigt.
Im Gegensatz zu einer relationalen Datenbank bietet ein document store ein unendliches Spektrum an Strukturierung. Ein klassisches, einfaches Textdokument besteht aus Buchstaben, die in Wörtern und Sätzen angeordnet sind. Eine Video- oder Audiodatei ist ein binäres großes Objekt mit einigen Metadatenfeldern. Ein E-Mail-Dokument besteht aus einigen definierten und benannten Feldern und deren Werten (Schlüssel-Wert-Paare), wie z. B. Absender und Betreff, sowie dem Textkörper der E-Mail, der ein einfacher Text ist. Ein feldbasiertes Dokument, wie XML oder JSON, besteht aus einem beliebigen Satz von Schlüssel/Wertpaaren, wie z. B. Vorname: "John", GebDat: "19451123", und so weiter. Ein document store kann jeden dieser Datentypen und mehr enthalten.
Offensichtlich bestimmt der Strukturierungsgrad eines document store die Verarbeitbarkeit. In einer einfachen Textdokumentenablage können wir alle Vorkommen eines Wortes wie "Macintosh" finden und zählen. Nur wenn das Dokument definierte und benannte Felder enthält, können wir jedoch zwischen "Macintosh" als Computermodell, einer Art Mantel oder schottischem Nachnamen unterscheiden und sie separat finden und zählen.
Das Auffinden und Zählen (und in der Tat alle Arten von komplexeren Datenverarbeitungen) führt dazu, dass eine Indexierung erforderlich ist, um den Zugriff zu beschleunigen. Ein einfacher Text-document-store wird über einen invertierten Index verarbeitet, bei dem es sich einfach um eine geordnete Liste aller nicht trivialen Wörter in der Ablage handelt. Zusammen mit Verweisen auf die Dokumente, in denen die Wörter erscheinen und ihre Positionen innerhalb dieser Dokumente. In einem document store, der strukturiertere Dokumente enthält, kann der Inhalt jedes einzelnen Feldes auf ähnliche Weise indiziert werden.
CortexDB bietet einen invertierten Index von jedem Wert aller Felder im document store, so dass jede Instanz von "Macintosh" als Nachname z. B. leicht in dieser Datensatzablage gefunden werden kann. Dadurch können diese Indizes für Prozessdaten – Anzahl, Durchschnitt, Maximum und Minimum, etc. – in jedem Feld verwendet werden. Interessanterweise stellt der komplette Indexsatz für eine Dokumentenablage die größtmögliche Modellstufe (6. Normalform; "6NF") dar, die für die Felder und Inhalte der Dokumentenablage möglich ist. Einfache Mengenoperationen wie Vereinigungs-, Schnitt- und Komplementärmengen können so einfach durchgeführt werden. Auf 6NF-Ebene bilden solche Mengenoperationen direkt die vertraute Sprache select und join in der SQL-Terminologie ab, so dass alle Macintoshes (jeder Art) in London lokalisiert werden können. Darüber hinaus ist dies der richtige Grad der Normalisierung, um zeitliche Konzepte, Graph-Strukturen und andere grundlegende Datenmanagement-Ansätze anzuwenden [5].
Die Konsequenz eines solchen multidimensionalen Indexes mit 6NF kann für Daten-Designer, die in traditionellen Modellierungsmethoden ausgebildet sind, überraschend sein. Da 6NF die grundlegendste und einfachste Darstellung von Daten ist, können alle anderen Normalisierungsstufen nachträglich daraus aufgebaut werden. In einer traditionellen relationalen Datenbank ist die Verwendung von 6NF jedoch komplex und umständlich, da die Anzahl der Joins von sehr kleinen Tabellen benötigt wird und dies die Leistung der Abfragen verschlechtert.
Die Verwendung des 6NF invertierten Indexes durch die CortexDB überwindet diese Probleme und unterstützt die volle Leistungsfähigkeit des 6NF-Ansatzes. Beim Entwurf und beim ersten Laden des Datenspeichers reduziert sich die Modellierung auf die Identifizierung, Benennung und Typisierung der einzelnen Felder. Alle anderen komplexeren Modellierungen, die erforderlich sind, wie z. B. die Definition von Dimensions- oder 3NF-Strukturen, die Erstellung von temporalen Datenbanken usw., können in einer späteren Entwurfsphase durchgeführt werden.
Diese Trennung von Designzeit- und Laufzeitproblemen macht CortexDB zu einem kontextabhängigen System und erhöht ihre Sicht von Daten zu Informationen, einem adaptiven Information Context Management System (ICMS). Das ist auch die Bedeutung von echter Datenagilität. Jede erforderliche geschäftliche Nutzung der Daten kann definiert und umgesetzt werden kann, nachdem die Daten gespeichert wurden, wobei der anfängliche Datensatz verwendet wird. Aufgrund der Leistungsmerkmale der 6NF-Struktur ist es selten notwendig, weitere Kopien der Daten in verschiedenen Formaten zu erstellen.
Für Business-Insight-Anwendungen wie Business Intelligence und Analytics, die das Herzstück der digitalen Transformation bilden, wird der Bedarf an mehreren Kopien derselben Daten in verschiedenen Strukturen deutlich reduziert oder sogar eliminiert, was zu einer neuen Agilität und Geschwindigkeit der Bereitstellung in der IT führt. Ähnliche Überlegungen gelten für die neuen operativen Anwendungen, die das digitale Geschäft erfordert.
Dieser neuartige Ansatz der Datenstruktur ermöglicht neue Denkweisen über Daten, die eine Fokussierung auf die Geschäftsanforderungen und nicht auf Datenbankbeschränkungen ermöglichen, und verbessert die IT-Produktivität sowie die Time-to-Market für neue Anwendungen. Diese Datenagilität ist das Herzstück des digital business. In meinem nächsten Artikel werde ich daher auf die Vorteile dieses neuen Ansatzes gegenüber herkömmlichen Datenbankmanagementsystemen eingehen und einige Praxisbeispiele erläutern.
Eine englische Version dieses Artikel finden Sie hier:
CortexDB Reinvents the Database
- Dr. Barry Devlin, 2013: Business unIntelligence: Insight and Innovation beyond Analytics and Big Data
- CiteSeer: Data Base Technology
- Wikipedia: Dokumentenorientierte Datenbank
- Wikipedia (engl.): Sixth normal form
- Thomas Kalippke: Die Architektur der CortexDB im Vergleich
