Ich beschäftige mich seit mehr als 30 Jahren mit der Modellierung von Daten und habe eine Vielzahl von Datenmodellen (3NF, dimensional, Ensemble (Anker, Data-Vault), Graphen usw.) hauptsächlich für analytische Systeme erstellt. Viele dieser Modelle sind jedoch auch allmählich veraltet oder überholt. Manchmal fühlt man sich wie der unglückliche Sisyphos, der seinen Felsbrocken beharrlich den Berg hinaufrollt, nur um irgendwann festzustellen, dass es wieder umsonst war.
Lange Zeit war ich davon überzeugt, dass es möglich sein muss, eine gemeinsame und vollständige Sicht auf die geschäftlichen Belange eines Unternehmens zentral zu modellieren. Schließlich wissen langjährige Geschäftsleute, die an der Modellierung beteiligt waren, was im Unternehmen vor sich geht, oder? Nun, je kleiner das Unternehmen war, desto näher kam ich dem Ziel. Aber um ganz ehrlich zu sein, am Ende blieb jedes Modell nur eine Annäherung – eine statische Ansicht, die versuchte, die sich ständig verändernde Realität widerzuspiegeln.
Aber auch wenn es recht mühsam ist, ein solches Modell zu erstellen, können wir ohne es absolut nicht erfolgreich sein. Das moderne datengesteuerte Unternehmen basiert auf dem Kerngedanken, aus Daten einen Wert zu schöpfen. Tatsache ist jedoch, dass Daten für sich genommen keinen Wert haben. Wir müssen Daten in verschiedenen Geschäftskontexten nutzen, kombinieren, integrieren und anwenden, um letztendlich einen Wert aus ihnen zu ziehen.
Aber ohne ein echtes Verständnis der Informationen und des geschäftlichen Kontextes in unseren Daten können wir, ehrlich gesagt, nichts daraus ableiten. Wir können versuchen, im Vorfeld eine Datenstruktur zu erstellen, indem wir beim Schreiben ein Schema verwenden, oder wir können sie beim Lesen ableiten, indem wir ein Schema beim Lesen verwenden. Wie auch immer, nur mit einer klaren Struktur und detaillierten Beschreibungen der Dinge und der bekannten Beziehungen zwischen diesen Dingen sind wir in der Lage, Intelligenz anzuwenden und abzuleiten, was noch unbekannt ist. Ohne Struktur werden wir im Datensumpf des unstrukturierten Datensees versinken.
Von Daten zu Informationen
Bei einem unstrukturierten Text zu einem beliebigen Thema verstehen wir den Inhalt erst, wenn wir den Text vollständig gelesen haben. Während wir lesen, erstellen wir ein mentales Modell der Informationen, die im Text verborgen sind. Bei längeren Texten werden wir wahrscheinlich auch Notizen machen, die einen Teil des mentalen Modells auf Papier festhalten.
Etwas Ähnliches passiert, wenn ML-Modelle Texte lesen. Nehmen wir Large Language Models (LLM), denn das Interesse an ihnen wächst derzeit explosionsartig. LLMs verstehen nicht viel, solange sie den Text nicht vollständig gescannt haben – wobei wir für einen Moment ignorieren, dass diese Modelle ohnehin nichts wirklich verstehen. Während diese LLMs den Text scannen, leiten sie ein Modell ab, das Wörter (oder Token) nimmt, sie mit anderen Wörtern vor und nach dem fraglichen Wort in Beziehung setzt, Einbettungen erstellt und das Ergebnis als Vektoren in einer Datenbank speichert – ähnlich wie wir lesen und uns Notizen auf Papier machen, eigentlich.
Was ist das Problem mit traditionellem Data Modeling?
Ohne weiter auf die Details von LLMs und die Algorithmen einzugehen, die sie zur Ableitung von Modellen aus unstrukturiertem Text verwenden, wollen wir die Bottom-up-Natur dieses Prozesses untersuchen.
Wir könnten theoretisch alle Informationen, die von Geschäftsanwendungen erzeugt werden, als Text in natürlicher Sprache speichern. Diese Texte könnten dann durch unsere LLMs geschickt werden, um ein Modell aus diesen Geschäftsdaten abzuleiten. Dies wäre ein ziemlich langwieriger und kostspieliger Prozess, der aber auch Vorteile bringen könnte. Leider ist das Modell, das bei diesem Prozess entsteht, kein aussagekräftiges semantisches Modell für uns Menschen, das direkt zum Verständnis der Daten beiträgt. Aber das in einer Vektordatenbank persistierte Modell in Kombination mit einem intelligenten Client wie ChatGPT würde es Ihnen wahrscheinlich ermöglichen, Abfragen durchzuführen, um unbekannte Dinge über Ihre Daten aufzudecken.
Gleichzeitig verfügen wir in den meisten Unternehmen über Unternehmensdatenmodelle, die im besten Fall eine oft veraltete Übersicht über Ihr Unternehmen darstellen. Eine Sichtweise, die in der Regel von oben nach unten mit viel menschlicher Arbeit erstellt wurde. Leider sind diese Modelle in den meisten Fällen weder vollständig noch vollständig konsistent mit den anderen, detaillierteren Modellen, die für die Geschäftsanwendungen im Unternehmen erstellt wurden. Das Modell kann sogar physisch in Form eines Unternehmens-Data-Warehouses implementiert werden – oder mehrerer solcher Data-Warehouses, um die Realität abzubilden.
Aber ich wage zu behaupten, dass es heute kein einziges Unternehmen gibt, das über ein vollständiges und aktuelles Datenmodell der in allen seinen Anwendungen und Datenbanken enthaltenen Informationen verfügt – und damit meine ich ausdrücklich die gesamte operative und analytische Ebene. Und ich bin noch mehr davon überzeugt, dass kein Unternehmen ein Enterprise Data Warehouse mit einer implementierten Version dieses Modells besitzt, das vollständig mit Daten aus allen Anwendungen bestückt und ständig auf dem neuesten Stand gehalten wird.
Selbst Datenmodelle, die für eine einzelne Anwendung entwickelt werden, sind in der Regel eine partielle Top-Down-Sicht auf Geschäftsobjekte und Beziehungen, die für die Anwendung zu einem bestimmten Zeitpunkt relevant sind. Aber die Realität ändert sich natürlich ständig mit jedem neuen Produkt, das definiert wird, mit jeder neuen Anwendung (oder sogar Microservice), die eingeführt wird, und generell mit kontinuierlichen Änderungen an den Geschäftsprozessen des Unternehmens.
Es ist unmöglich, die sich ständig ändernde Art und Weise, wie ein Unternehmen Geschäfte tätigt, in einem statischen Top-down-Datenmodell abzubilden. Selbst wenn man theoretisch alle Geschäftsobjekte und Beziehungen zu einem bestimmten Zeitpunkt korrekt erfassen könnte, wäre das Modell schnell veraltet.
Transitional Modeling to the Rescue
Wenn diese arbeitsintensive Top-Down-Modellierung unseren Anforderungen nicht vollständig gerecht wird, warum nicht einen Bottom-Up-Modellierungsansatz hinzufügen? Lassen Sie uns einen neuen Blick auf die Datenmodellierung werfen, indem wir einen Ansatz verfolgen, den Lars Rönnbäck in seinem faszinierenden Aufsatz über die Modellierung widersprüchlicher, unzuverlässiger und schwankender Informationen als Übergangsmodellierung bezeichnet.
Vergleichbar mit dem LLM-Ansatz zur Ableitung eines Modells aus natürlichem Sprachtext (leicht strukturiert durch Wörter und Sätze), können wir unser Datenmodell aus Datenatomen oder Posits, wie Lars Rönnbäck sie nennt, ableiten. Datenatome sind so etwas wie standardisierte Informationshäppchen über das Geschäft in der Organisation. Wir werden sie später in diesem Artikel genauer untersuchen.
Der Unterschied zum natürlichsprachlichen Text ist das minimale, starre Schema, nach dem Datenatome definiert und kombiniert werden, im Gegensatz zu der unstrukturierten Art und Weise, wie Wörter zu Sätzen kombiniert werden. Mit diesem minimalen Schema erhalten wir die Möglichkeit einer vereinfachten Verarbeitung, während wir gleichzeitig die Flexibilität eines natürlichsprachlichen Textes beibehalten, um hochkomplexe Fakten und vielschichtige Beziehungen auszudrücken. Auf diese Weise können wir das Modell aus den Daten selbst ableiten, ähnlich wie der LLM sein Modell aus den Wörtern im natürlichsprachlichen Text ableitet, aber effizienter und einfacher.
Die Umwandlung des Inhalts einer Datenbank in Datenatome ist eigentlich ein recht einfacher Prozess und kann viel effizienter durchgeführt werden als die Umwandlung in einen aussagekräftigen natürlichsprachlichen Text. Und jeder IT-Geschäftsbereich kann seine geschäftlichen Kontextinformationen einfach als zusätzliche Datenatome zu den automatisch aus Datenbanken abgeleiteten Informationen hinzufügen. Dieser Gesamtstrom von Datenatomen enthält alle notwendigen Informationen, um jederzeit ein aktuelles Datenmodell ableiten zu können. Jede Änderung des Domänenmodells kann leicht veröffentlicht werden, indem zusätzliche Datenatome in diesen Strom eingespeist werden.
Ein Strom von Datenatomen ist der ideale Input für das, was wir als ereignisgesteuerte Datenarchitektur bezeichnet haben. Dabei handelt es sich um ein Systemdesign, bei dem die Verarbeitung durch bestimmte Ereignisse oder Zustandsänderungen (hier die Datenatome) ausgelöst wird, was Interaktionen zwischen Anwendungen im Unternehmen in Echtzeit ermöglicht.
Bei jeder Einführung einer neuen Anwendungsfunktion, die höchstwahrscheinlich auch das Unternehmensdatenmodell ändert, kann die Änderung als Datenatome in der ereignisgesteuerten Architektur veröffentlicht werden. In der Praxis bedeutet dies, dass jede andere Anwendung im Unternehmen direkt auf das geänderte Modell reagieren und Visualisierungen oder abhängige nachgelagerte Verarbeitung entsprechend aktualisieren kann. Insgesamt können sich Ihre Systeme auf diese Weise dynamisch weiterentwickeln und sehr flexible Möglichkeiten zur Darstellung von Informationen bieten.
Jedes andere Datenmodell kann aus dem Grundmodell einer zeitlich geordneten Reihe von Datenatomen abgeleitet werden.
Diese Tatsache können wir effektiv nutzen, um Unternehmensdatenmodelle zu erstellen, die immer aktuell bleiben. Und mehr noch, jedes andere Datenbankmodell, das für eine bestimmte Anwendung optimiert ist, kann effizient aus dem Unternehmensmodell abgeleitet werden. Wir können Anwendungen entwickeln, die in der Lage sind, den Strom der Datenatome automatisch umzuwandeln, z. B. in einen Datentresor, ein Graphenmodell oder ein leistungsoptimiertes Sternschema für eine relationale Datenbank, die in einem Data Warehouse verwendet werden soll.
Dabei ist zu beachten, dass diese Datenatome nicht nur die Semantik der Daten für die Ableitung von Modellen kodieren, sondern auch den kompletten Geschäftsinhalt. Ein unveränderlicher Strom von Datenatomen ist daher das optimale Modell für eine verlustfreie Aufzeichnung aller Informationen, die im Laufe der Zeit im Unternehmen entstanden sind. Dies ist vergleichbar mit dem, wofür eine relationale Datenbank ihr Commit-Log verwendet, um z.B. ACID-Garantien zu implementieren und alle Arten von Beziehungen aus den in die Datenbank übertragenen Transaktionen abzuleiten. Aber hier nutzen wir dies auf Unternehmensebene, um alle Anwendungen zu integrieren, anstatt in einem einzigen Datenbankmanagementsystem gefangen zu sein.
Daten-Atome
Das klingt zu schön, um wahr zu sein, also lassen Sie uns diese Datenatome erforschen. Der einfache und offensichtliche Prozess der Bildung komplexer Organismen aus einfacheren Atomen und Molekülen ist eine weitere intelligente Erfindung von Mutter Natur. Wir können das gleiche Prinzip anwenden, um unsere Modelle von unten nach oben aus Datenatomen zu bilden.
Lassen Sie uns also ein wenig in der Ursuppe rühren und Datenatome definieren, die kombiniert werden können, um hochkomplexe Fakten auszudrücken. Lars Rönnbäck hat eine farbenfrohe und schöne Beschreibung der Struktur erstellt, die unsere Datenatome bilden. Ein wenig Scala-Code kann vielleicht helfen, die Struktur noch prägnanter zu beschreiben und erlaubt es Ihnen, mit dem Konzept zu spielen:
// === THE BASIC STRUCTURE ===
// An Appearance can be identified with any type I
// and can have a role of any type R
case class Appearance[I,R](id: I, role: R):
override def toString(): String = s"($id,$role)"
// A DataAtom as a set of Apearances and a value (of type V)
// as of one particular point in time (type T)
// override toString to mimic Lars Rönnbäcks compact way to write Posits
case class DataAtom[I, R, V, T](appearances: Set[Appearance[I,R]], value: V, timestamp: T):
private var id: java.util.UUID = scala.compiletime.uninitialized
override def toString(): String = s"[${appearances.toString.replace("Set(","{").replace("))",")}")}, $value, $timestamp]"
def infoId(): String =
if (id == null) then id = java.util.UUID.randomUUID()
id.toString()
// === Create a simple model ===
// The classes defined in the ontology
val customerType = DataAtom(
Set(Appearance("Ontology.Customer", "class")),
"Customer", java.time.LocalDateTime.MIN)
val carType = DataAtom(
Set(Appearance("Ontology.Car", "class")),
"Car", java.time.LocalDateTime.MIN)
// Define the customer John Wayne with id 4711
val customer4711 = DataAtom(
Set(Appearance("4711", "thing"), Appearance("Ontology.Customer", "class")),
"official", java.time.LocalDateTime.now())
val customer4711LastName = DataAtom(
Set(Appearance("4711", "last name")), "Wayne", java.time.LocalDateTime.now())
val customer4711FirstName = DataAtom(
Set(Appearance("4711", "first name")), "John", java.time.LocalDateTime.now())
// Define the car with red color and VIN 0815 to be owned by customer 4711
val car0815 = DataAtom(
Set(Appearance("0815", "thing"), Appearance("Ontology.Car", "class")),
"official", java.time.LocalDateTime.now())
val car0815VIN = DataAtom(
Set(Appearance("0815", "vehicle identification number")),
"0815", java.time.LocalDateTime.now())
val car0815Red = DataAtom(
Set(Appearance("0815", "color")),
"red", java.time.LocalDateTime.now())
val carOwned = DataAtom(
Set(Appearance("4711", "owns"), Appearance("0815", "registered with")),
"officially registered", java.time.LocalDateTime.now())
// create a stream of DataAtoms
val stream = Seq.empty[DataAtom[?,?,?,?]] :+
customerType :+ carType :+
customer4711 :+
customer4711LastName :+
customer4711FirstName :+
car0815 :+
car0815VIN :+
car0815Red :+
carOwned
////////////////////////////////////////////////////////////////////////////////////////
// Change the ontology
// Define a new vehicle type for bicycles, cars and other vehicles
val vehicleType = DataAtom(
Set(Appearance("Ontology.Vehicle", "class")),
"Vehicle", java.time.LocalDateTime.now().plusYears(3))
// The car will be repainted in blue one year later
val colorChange = DataAtom(
Set(Appearance("0815", "color")),
"blue", java.time.LocalDateTime.now().plusYears(1))
// The customer Herold Ford appears with id 4712 two years later
val customer4712 = DataAtom(
Set(Appearance("4712", "thing"), Appearance("Ontology.Customer", "class")),
"official", java.time.LocalDateTime.now().plusYears(2))
// John Wayne sells his car to Herold Ford
val carOwnedNow = DataAtom(
Set(Appearance("4712", "owns"), Appearance("0815", "registered with")),
"officially registered", java.time.LocalDateTime.now().plusYears(2))
// The fact that customers can own bicycles gets tracked
val customer4711withBicycle = DataAtom(
Set(Appearance("4711", "owns bicycle")),
true, java.time.LocalDateTime.now().plusYears(2))
// John Wayne asserts one year after he sold his car, that he thinks with 80%
// percent confidence he sold it to Herold Ford the year before
val assertion = DataAtom(
Set(Appearance(carOwnedNow.infoId(), "ATOM"),
Appearance("4711", "determines confidence")),
0.8, java.time.LocalDateTime.now().plusYears(3))
// the car is redefined as a vehicle with a new attribute: type
val carNowVehicle = DataAtom(
Set(Appearance("0815", "thing"), Appearance("Ontology.Vehicle", "class")),
"official", java.time.LocalDateTime.now().plusYears(3))
val carVehicleType = DataAtom(
Set(Appearance("0815", "type")),
"Car", java.time.LocalDateTime.now().plusYears(3))
// create another stream of DataAtoms
val newStream = Seq.empty[DataAtom[?,?,?,?]] :+
vehicleType :+
colorChange :+
customer4712 :+ carOwnedNow :+
customer4711withBicycle :+
assertion :+
carNowVehicle :+ carVehicleType
val overallStream = stream ++ newStream
// As one tiny example let’s query the stream to
// get all the entities in the model as a
// set of (entity-name, valid-from) tuples
val entities = overallStream.filter(_.appearances.map {
role => role match {
case Appearance(_,"class") => true
case _ => false
}}.reduceLeft( (acc,b) => acc && b )
).sortBy(_.timestamp.asInstanceOf[java.time.LocalDateTime]).map {
a => (a.value, a.timestamp)
}.toSetDas kleine Beispiel verdeutlicht hoffentlich das Potenzial dieses Ansatzes. Er ermöglicht es, dass Ihre Unternehmensmodelle aktuell, vollständig und vollständig mit allen detaillierten Modellen, die von Ihren Anwendungen dargestellt werden, abgestimmt sind. Wenden Sie diesen Ansatz auf Unternehmensebene an, um Informationen zu kodieren, die in Ihren Geschäftsanwendungen erstellt wurden und in großem Maßstab gemeinsam genutzt werden müssen. In Datenatomen kodierte Informationen können das Rückgrat der modernen Datenmodellierung bilden. Gleichzeitig kann dieser Ansatz auch für das verwendet werden, was ich als universelle Datenversorgung bezeichne – eine Unternehmensdatenarchitektur, die darauf abzielt, das datengesteuerte Wertversprechen zu erfüllen, indem sie die verlustfreie gemeinsame Nutzung von Daten für alle Anwendungen im Unternehmen ermöglicht.
Eine Ontologie als Leitfaden für Ihre Datenatome
Wie so oft gilt auch hier der Grundsatz, das eine zu tun, ohne das andere zu vernachlässigen. Auch wenn unser Top-Down-Modellierungsansatz allein nicht erfolgreich sein kann, kann er unsere Übergangsmodellierung erheblich vereinfachen.
Ich habe in Teil 3 meiner dreiteiligen Serie über Datennetze ausführlicher über eine Ontologie und deren Erstellung geschrieben. Aber hier nur eine kurze Zusammenfassung der Kernidee: Bei einer Ontologie geht es um das große Ganze und das konzeptionelle Verständnis des Geschäfts auf einer hohen Ebene, das eine Orientierung für die in den Geschäftsbereichen entwickelten anwendungsspezifischen Modelle bietet.
Die moderne Datenmodellierung geht das Problem von oben nach unten mit der Ontologie und von unten nach oben an, indem sie einfache Datenatome erstellt, die mit der Ontologie verknüpft werden. Dies ermöglicht den Aufbau von vollwertigen Unternehmensdatenmodellen, die aktuell und vollständig bleiben können.
Das bedeutet nicht, dass die Modellierung praktisch zu einem automatisierten Prozess geworden ist. Es kann immer noch widersprüchliche und unterschiedliche Informationen geben, die harmonisiert und vereinbart werden müssen. Es ist nur so, dass wir jetzt jedem im Unternehmen die Möglichkeit geben, sich aktiv zu beteiligen. Wir verteilen den Datenmodellierungsprozess effektiv, was eine offene und fruchtbare Debatte über das Unternehmensdatenmodell auslöst.
Der Prozess wird nicht mehr von einer theoretischen Top-down-Sicht auf das Unternehmen zu einem bestimmten Zeitpunkt bestimmt. Die Kombination aus einer Ontologie und einer Übergangsmodellierung bietet den Rahmen für eine echte Zusammenarbeit im gesamten Unternehmen. Diskussionen und unterschiedliche Standpunkte sind zu jedem Zeitpunkt völlig transparent. Dies gibt uns zumindest die Werkzeuge an die Hand, um letztendlich einen Konsens über ein unternehmensweites Datenmodell zu erreichen. Mit den richtigen Governance-Prozessen, die diese kollaborative Modellierung leiten, haben wir eine gute Chance, die Datenmodellierung auf die nächste Evolutionsstufe zu heben.
Quelle: medium.com
