Lösungen

MarkLogic Data Hub-Service

Schnellere Datenintegration + bessere Data Governance und Sicherheit – ohne Infrastruktur, die gekauft oder verwaltet werden muss.

Mehr erfahren

Schulungen

Mit MarkLogic auf dem Laufenden bleiben

Mit News sowie Produkt- und Veranstaltungshinweise direkt in Ihrem Posteingang.

Registrieren

Community

Mit MarkLogic auf dem Laufenden bleiben

Mit News sowie Produkt- und Veranstaltungshinweise direkt in Ihrem Posteingang.

Registrieren

Unternehmen

Mit MarkLogic auf dem Laufenden bleiben

Mit News sowie Produkt- und Veranstaltungshinweise direkt in Ihrem Posteingang.

Registrieren

Entkommen Sie der Matrix

Befreien Sie Ihre Daten mit einer Multi-Modell-Datenbank

Durch relationale Datenbanken stecken Sie in einer fragmentierten Welt aus Zeilen und Spalten fest. Diese starre Matrix kontrolliert Ihr gesamtes Handeln. Sie müssen sich der Datenbank unterordnen, ihre strengen Regeln befolgen und Ihre Welt der Tyrannei der Datenbankstruktur unterordnen. Es ist an der Zeit, der Matrix aus relationalen Datenbanken zu entkommen. Die Zeit ist reif für einen modernen Multi-Modell-Ansatz für die Datenintegration. Befreien Sie Ihre Daten und schaffen Sie unendliche Möglichkeiten.

Sie brauchen eine 360° Sicht auf Ihr Unternehmen

Daten müssen schnell integriert werden

Heutzutage verfügen Sie über mehr Daten und Datenquellen als je zuvor. Aber höchstwahrscheinlich sind diese Daten in Silos verteilt und in relationalen Datenmodellen, wie z. B. Registrierungsdatenbanken, Fulfillment- und CRM-Systemen oder Ad-Servern isoliert. Können Sie diese Daten nicht schnell integrieren, um eine 360° Sicht auf Ihr Unternehmen zu schaffen, sind diese Daten nutzlos.

ETL – Der Feind der Agilität

Jedes Mal, wenn Sie Daten aus verschiedenen relationalen Datenbanken zusammenführen, müssen Sie die Daten extrahieren, umwandeln und laden. Denn genau das bedeutet „ETL“: extract, transform, load. Ein langsamer, komplexer und kostspieliger Prozess.

Daten verändern sich ständig

Eine neue Anwendung erfordert eine einzigartige Sicht auf Ihre Daten. Eine Fusion oder Übernahme verändert die Menge und Art der Daten, die Sie verwalten. Eine neue Compliance-Regel verlangt eine andere Form von Data Governance. Und für die digitale Transformation Ihres Unternehmens ist entscheidend, dass Ihre Daten in Echtzeit genutzt werden können.

Sie müssen das Unternehmen führen und geschäftliche Abläufe beobachten können.

Nie zuvor wurden operative Daten für Betriebsabläufe so stark in Echtzeit genutzt wie in Zeiten der der digitalen Transformation. Diese Daten können mehrere Geschäftsbereiche umfassen und in vielen verschiedenen Datenbanken vorliegen. Können Sie Daten aus diesen operativen Silos nicht schnell oder agil genug integrieren, um neue Geschäftsanforderungen zu erfüllen, kann das für Ihre digitale Transformation fatal sein.

Zugleich wollen Sie Datensilos zur Analyse nutzen, um Geschäftsfunktionen im Blick zu behalten, ohne ständig unzählige Quellen einzeln abfragen zu müssen.

Das Problem ist, dass sich mit relationalen Datenbanken Daten nur schwer und zu hohen Kosten in Echtzeit verwenden und integrieren lassen.

Probleme mit relationalen Daten

Bei relationalen Modellen wird das Einfache oft komplex

Nehmen wir ein simples Entity-Relationship-Diagramm: Ein Kunde schließt eine Transaktion ab, die ein Produkt beinhaltet. Im Prinzip ist dies eine sehr einfache Beziehung verschiedener Entitäten. Aufgrund der Starrheit relationaler Datenbanken können selbst simple Beziehungen komplex werden. In einer relationalen Datenbank können ähnliche Informationen unterschiedlich modelliert werden, was die Datenintegration erschwert.

Nicht alle Verknüpfungen machen Sinn

Ein Blick auf das sehr einfache Schema der Firma ”Blue Gear Auto Parts” zeigt sofort ein Problem. Die Join-Tabelle „Tlines“ bildet unser konzeptionelles Verständnis der Transaktion nicht richtig ab. Da Transaktionen mehrere Produkte umfassen können und Produkte Teil mehrerer Transaktionen sein können, sind zur Speicherung der Produktinformationen getrennte Join-Tabellen erforderlich. Join-Tabellen gibt es nur aus einem Grund: weil relationale Datenbanken unflexibel sind und Daten in Spalten und Zeilen „zwängen“.

Datenschemata sind nicht immer intuitiv

Relationale Schemata lassen sich nicht leicht intuitiv verstehen. Was bedeutet z. B. „Addr“ in dieser Kundentabelle? Sie müssen sich die Tabelle genauer ansehen, um zu verstehen, dass „Addr“ den Straßennamen enthält.

Ändern sich Informationen, wird die starre Natur relationaler Datenmodelle zu einem echten Problem. Angenommen, Sie müssen eine zweite Adresse oder Telefonnummer zu einem Kundendatensatz hinzufügen. Bei einem relationalen Modell brauchen Sie jetzt neue Join-Tabellen, wodurch Ihr Schema noch komplizierter wird.

Starre Schemata können zu fehlerhaften Daten führen

Die mangelnde Flexibilität relationaler Datenmodelle führt zu einem weiteren Dilemma. Sobald Sie ein Schema fertiggestellt haben, können Sie es nur noch ändern, indem Sie es wieder aufbrechen und von vorn beginnen. Wie erstellt man also ein Schema, das Ihre künftigen Anforderungen berücksichtigt? Was, wenn sich Ihr Geschäft ändert und Sie Ihre Daten auf andere Weise modellieren müssen?

Sie können den langsamen, kostspieligen Weg nehmen und ein neues Schema entwickeln, um dann Ihre Daten mithilfe von ETL-Prozessen zu transformieren. Oder Sie nehmen die Abkürzung und zwingen Ihre Daten wie auch immer in das vorhandene Schema. Dadurch erzeugen sie jedoch ein Datenqualitätsproblem, da Ihr Schema nicht mehr mit Ihren reellen Datenstrukturen übereinstimmt.

Dieses Schema erlaubt nur eine Telefonnummer, weil man bei der Firma ”Blue Gear Auto Parts” nicht an Mobiltelefone gedacht hatte. Statt also das Schema von Grund auf neu zu gestalten, haben Entwickler zwei Telefonnummern in das Feld gepresst.

Das zeigt den grundlegende Limitierung relationaler Datenmodelle: Sie sind starr und Resistent gegenüber Veränderung. Dadurch beschränken Sie die Agilität Ihres Unternehmens.

Die unterschiedliche Modellierung der gleichen Beziehungen führt zu Komplexität

Im Gegensatz zu ”Blue Gear Auto Parts” erlaubt das Schema von ”Red Motor Equipment” mehrere Kundentelefonnummern und -adressen. Vielleicht verarbeitet eine Abteilung der Firma ”Red Motor Equipment” Rechnungs- und Lieferdaten und braucht daher beide Adressen, wohingegen “Blue Gear Auto Parts” nur Lieferadressen verarbeitet.

Komplexe Datenschemata

Ein realistischeres Datenschema

Datenschemata sind in der Praxis weitaus komplexer. So könnte ein Schema für eine simple Geschäftsanwendung aussehen. Stellen Sie sich nur die Komplexität eines Schemas für eine ERP-Anwendung mit zehntausenden Tabellen vor.

Integration von Schemata schafft mehr Komplexität

Angenommen, “Blue Gear Auto Parts” übernimmt ”Red Motor Equipment” und will die Daten beider Unternehmen integrieren.

Dafür müsste “Blue Gear Auto Parts” ein einziges Schema erstellen, das alle Daten aus den Quell-Schemata beider Unternehmen aufnehmen kann. Hierdurch entsteht ein noch komplizierteres „Über-Schema“. Zudem muss “Blue Gear Auto Parts” entscheiden, welche Information beibehalten werden soll und welche nicht.

“Red Motor Equipment” verfügt über mehr Informationen als “Blue Gear Auto Parts”. Möglicherweise werden Rechnungsadressen im Augenblick noch nicht benötigt. Aber was ist, wenn sich das ändert?

Komplexität ist unvermeidbar

So könnte das „Über-Schema“ aussehen. Wie Sie sehen, enthält dieses Schema mehr Tabellen und Verknüpfungen (Joins), wodurch es wesentlich komplexer wird.

Tatsächlich möchte aber “Blue Gear Auto Parts” dieses „Über-Schema“ vereinfachen, um es überschaubarer zu gestalten. Dies kann jedoch nur erreicht werden, wenn Schemata für bestimmte Anwendungsfälle entworfen werden. Sollte “Blue Gear Auto Parts” diese Richtung einschlagen, hätte das einen endlosen Zyklus von ETL-Prozessen und Datensilos zur Folge.

Wie entstehen Datensilos?

Verändert sich Ihr Geschäft, muss sich auch die Sicht auf Ihre Daten anpassen

Mit relationalen Datenbanken erhalten Sie verschiedene Versionen Ihrer Daten in getrennten Silos: Ihre ursprünglichen Quelldaten, geänderte Versionen Ihrer Quelldaten und weitere Anpassungen Ihrer Daten für jede einzelne Geschäftsanforderung. Zudem geht jede Datenänderung mit einem Informationsverlust einher, wodurch sich die Herkunft der Daten nur schwer nachverfolgen lässt.

Zurück zu unserem einfachen Beispiel aus der Welt der Autoersatzteile. Beim Kauf von “Red Motor Equipment” durch “Blue Gear Auto Parts” ist eine Konsolidierung der Daten sinnvoll. Da ETL-Prozesse kostspielig und komplex und Systemausfallzeiten nicht zu vermeiden sind, erfolgt die Zusammenführung von Daten erst dann, wenn es für eine bestimmte Anwendung notwendig ist.

Aufgrund enormer ETL-Kosten werden nur die wichtigsten Daten übernommen

Nehmen wir an ”Blue Gear Auto Parts” möchte nun eine Ansicht auf Kundendaten erstellen, um ihr Kundenprofil besser zu verstehen. Dafür müssen zuerst Kundendaten von “Blue Gear Auto Parts” und ”Red Motor Equipment” einen ETL-Prozess durchlaufen. Danach möchte man möglicherweise Produkte und Käufer analysieren, um das Kaufinteresse besser einschätzen zu können. Zusätzlich muss “Blue Gear Auto Parts” die Verkaufsdaten aus regulatorischen Gründen konsolidieren. Daher müssen diese einen weiteren ETL-Prozess durchlaufen, um Informationen zu entfernen, die die Regulierungsbehörde nichts angehen. Abschließend gibt es einen weiteren ETL-Prozess, um für den Umsatz relevante Daten in einem Dashboard zur Verfügung zustellen.

Kein Unternehmen plant Datensilos

Wie geht es weiter? Bei jeder Änderung von Geschäftsprozessen muss ”Blue Gear Auto Parts” die Daten mit einem weiteren ETL-Prozess aufbereiten. Das bremst das Geschäft aus.

Verschiedene Datenquellen existieren, weil relationale Modelle zu unflexibel sind

Mit jedem ETL-Prozess entsteht ein neues Datensilo. Infolgedessen gibt es keine zentrale Datenquelle. Es gibt unternehmensweit verschiedenste Versionen Ihrer Daten: Ihre ursprünglichen Quelldaten, geänderte Versionen Ihrer Quelldaten sowie weitere Anpassungen für jeden einzelnen Anwendungsfall. Data Governance wird damit zum Alptraum, da der Ursprung, die Herkunft und die Qualität der Daten übergreifend über die verschiedenen Silos nicht nachzuverfolgen ist.

Der MarkLogic-Ansatz

Ein flexibles Datenmodell

Dokumentdatenbanken wie MarkLogic haben ein flexibleres Datenmodell. Links sehen Sie ein relationales Datenmodell: Der Kundendatensatz wird hier in zwei starre Zeilen und Spalten aufgeteilt.

Rechts sehen Sie den gleichen Kundendatensatz, wie er in einem JSON-Dokument dargestellt wird. Dazu gehört die hierarchische Struktur eines Dokumentmodells, welches Daten auf natürliche Weise organisiert – wie in einem Dokument. Es beinhaltet Arrays (wie die Liefer- oder Rechnungsadresse) sowie geschachtelte Arrays (wie z.B. die Telefonnummer).

MarkLogic ist unglaublich flexibel

Bei MarkLogic können Sie jederzeit problemlos Information hinzufügen oder die Information, die Ihnen nicht vorliegt, weglassen. Sie können sich wiederholende hierarchische Attribute wie Telefonnummern und Adressen natürlich repräsentieren, ohne dafür gesonderte Tabellen anlegen zu müssen. Und weil MarkLogic die Daten unmittelbar beim Hinzufügen indiziert, ist diese Information sofort abfragbar.

Datenharmonisierung leicht gemacht

Statt herkömmliche ETL-Prozesse zum Transformieren von Daten vor dem Laden in eine Datenbank zu verwenden, können Sie mit dem flexiblen Dokumentdatenmodell von MarkLogic Ihre Daten nach Bedarf harmonisieren. Diese Harmonisierung erfolgt in einer vollständig transaktionalen Datenbank, in der Daten nachverfolgt und verwaltet werden können.

In diesem Beispiel wird die Postleitzahl harmonisiert. In dem harmonisierten kanonischen Modell sind beide Datenmodelle einheitlich benannt („Postal“).

Mit MarkLogic können Sie einfach Daten in ein kanonisches Modell ziehen, um diese einheitlich abfragbar zu machen. Sie können Ihr Modell im Laufe der Zeit weiterentwickeln, sobald sich Ihre Geschäftsanforderungen ändern. Zu keinem Zeitpunkt müssen Sie dabei Ihre Rohdaten zerstören.

Werden Sie der Herkunft Ihrer Daten bewusst

MarkLogic verwendet das sogenannte „Envelope Pattern“ um Metadaten dem Dokument direkt anzufügen. Dadurch bleiben Datenursprung und -herkunft erhalten. Sie Können Metadaten, Quelldaten und kanonische Daten gemeinsam in einem einzigen Dokument speichern.

Entitäten = Dokumente

Das Dokumentenmodell bietet den flexibelsten und iterativsten Ansatz zur Geschäftsdatenmodellierung.

Relationale Datenbanken verringern die Aussagekraft

Relationale Datenbanken können nur schlecht die Bedeutung Beziehung zwischen Objekten (Entity Relationship) aufzeigen. Beispielsweise zeigt der Kundendatensatz von “Red Motor Equipment” zahlreiche Joins, die auf Beziehungen zwischen Tabellen hinweisen. Doch die Bedeutung dieser Beziehungen lässt sich nur schwer nachvollziehen.

Beziehung zwischen Objekten in MarkLogic

Das hier ist der gleiche Kundendatensatz in MarkLogic.

Wie Sie sofort sehen, hat der Kunde eine Transaktion abgeschlossen, die eine „Batterie“ und ein „Starthilfekabel“ umfasste. Objektbeziehungen sind sehr viel einfacher zu verstehen.

Mehr Information durch Semantik

Entdecken Sie Zusammenhänge durch Semantik

Relationale Datenmodelle verlangen, dass Sie Ihr Schema genau kennen und verstehen, um überhaupt Daten abfragen zu können. Nicht bei MarkLogic.

Dank der Integration von Semantik sind Objektbeziehungen in MarkLogic leicht zu verstehen. Das gestaltet Abfragen und das Auffinden von Daten wesentlich einfacher.  Semantische Beziehungen in MarkLogic sind aussagekräftig: Sie können Beziehungen exakt definieren und deren Bedeutung direkt abfragen. Sie können Sie Rückschlüsse aus der Bedeutung von Beziehungen ziehen, um neue Erkenntnisse zu erlangen.

Semantische Tripel gestalten die Beziehung zwischen Entitäten und sog. Concepts

Eine relationale Datenbank stellt Daten anhand von Primär- un Fremdschlüsselbeziehungen dar. Diese Beziehungen sagen jedoch nichts über die tatsächliche Bedeutung dieser Beziehung aus. Die wahre Natur der Beziehung wird im Anwendungscode vergraben. Einige Joins repräsentieren echte Beziehungen, wie wir Sie im geschäftlichen Kontext verstehen würden. Andere Joins zeigen scheinbare Beziehungen, die es lediglich aufgrund von Beschränkungen im relationalen Datenmodell gibt, welches nur Zeilen in Tabellen verwalten kann. Woran erkennen wir nun die Natur einer Beziehung? Ohne etwas über die Semantik des Modells zu wissen? Überhaupt nicht!

Mit Semantik können wir jedoch den Kontext und die explizite Bedeutung dieser Transaktion bereitstellen. Beispielsweise können in MarkLogic die gleichen Daten als „Karin Becker“, „Kunde 2001“, „kaufte Produkt 7001“, eine „Batterie“ definiert werden.

Semantische Tripel eignen sich ideal um Beziehungen innerhalb Ihrer Daten zu modellieren. Tripels bestehen aus Subjekt, Prädikat und Objekt. Fremdschlüssel, geschachtelte Abfragen oder komplexe Joins werden hiermit überflüssig. Wenn Sie ein Dokumentenmodell mit Semantik kombinieren, erhalten Sie einen Multi-Modell-Ansatz für alle Daten.

Semantische Beziehungen in MarkLogic sind aussagekräftig. Sie können diese Bedeutung genau definieren und direkt abfragen Sie können somit Rückschlüsse aus dieser Bedeutung ziehen und so neue Informationen ableiten.

Semantik lässt sich vielfältig anwenden

Semantik verschafft Ihnen eine intelligente Sicht auf Daten und lässt Sie diese auf völlig neue Weise nutzen. Ein Beispiel:

Mit Semantik lassen sich Konzepte definieren, die vielleicht identisch sind, aber in unterschiedlichen Datenquellen anders benannt werden. “Blue Gear Auto Parts” bezeichnet z.B. ein Starthilfekabel als „Jump Starter“ bezeichnet werden, während “Red Motor Equipment” das gleiche Bauteil „Jumper Pack“ nennt. Mithilfe von Semantik lassen sich diese Konzepte als identisch definieren. Wenn Karen eine Online-Bestellung einer Batterie auslöst kann nach der Fusion von ”Blue Gear Auto Parts” mit “Red Motor Equipment” im Online-Shop ein Starthilfekabel von beiden Anbietern als Kaufempfehlung angezeigt werden.

Sie können Informationen – z.B. über zugehörige Produkte – in Beziehung setzen, um ein Empfehlungssystem zu erstellen oder Kundenkäufe besser nachzuvollziehen. Beispielsweise können Sie für “Blue Gear Auto Parts” die Batterie und das Starthilfekabel als zwei sich ergänzende Produkte festlegen. Mit Semantik lässt sich diese Beziehung herstellen. Wenn dann z.B. Karen im Online-Shop eine Batterie kauft, kann ihr dabei der Kauf eines Starthilfekabels empfohlen werden.

Diese beiden Beispiele zeigen nur einen kleinen Teil der Möglichkeiten, die Semantik eröffnet. Sie können mit Semantik auch Informationen abgrenzen oder zueinander in Beziehung setzen, z.B. um Ihre Daten grafisch darzustellen oder Alarme auszulösen usw.

Relationale Technologie im Vergleich zu MarkLogic

Mit relationalen Datenbanken

Schritt 1
Stellen Sie alle Schemata zusammen, die Sie integrieren wollen. Finden Sie heraus, was diese bedeuten, wie sie funktionieren und was sie gemeinsam haben.

Schritt 2
Entscheiden Sie, welche Daten ignoriert werden können. Entwerfen Sie ein neues Schema, das alle zu integrierenden Daten berücksichtigt.

Schritt 3
Schreiben Sie den notwendigen ETL-Code, um Daten aus der Quelle zu extrahieren. Wandeln Sie diese für Ihr Schema passend um und laden Sie sie in das Zielschema einer Datenbank.

Schritt 4
Erstellen Sie Indizes für die Suchabfragen.

Schritt 5
Programmieren Sie die Anwendung.

Wiederholen Sie Schritt 1-5
Und das jedes Mal, wenn sich Geschäftsprozesse ändern.

Mit MarkLogic

Schritt 1
Wählen Sie zu Beginn einige Quell-Schemata aus und testen Sie sie mit Beispieldatensätzen.

Schritt 2
Laden Sie Daten direkt egal in welchem Format in MarkLogic und verwenden Sie die integrierte Suchfunktion, um diese genauer zu verstehen.

Schritt 3
Nehmen Sie sukzessive die Harmonisierung vor und entwickeln Sie ein agiles Modell.

Schritt 4
Greifen Sie bei Bedarf auf die Daten zu.

Die MarkLogic-Datenbank

Sofort für Ihr Unternehmen einsetzbar. Unvergleichbare Flexibilität.

Mit MarkLogic entwickeln Sie nicht nur eine Anwendung, Sie schaffen eine Plattform für alle Ihre Daten mit endlosen Möglichkeiten. Auch wenn Sie mit einem konkreten Anwendungsfall beginnen, stehen Ihnen Ihre Daten dennoch für vielfältige Anwendungsfälle zur Verfügung. Weil Sie kein Datensilo anlegen, welches nur für einen einzigen Anwendungsfall funktioniert.

Der Operational Data Hub von MarkLogic

Hier sehen Sie, wie der MarkLogic Operational Data Hub (ODH) in Ihre Architektur integriert werden kann, um Daten aus unterschiedlichsten Datenquellen aufzunehmen und so einen Mehrwert zu schaffen. MarkLogic nimmt verschiedenste Datentypen wie JSON, XML, Text, Geodaten und semantische Tripel auf und und indiziert diese unmittelbar für sofortige Suchabfragen. Darüber hinaus bietet MarkLogic API-Schnittstellen für den schnellen Datenzugriff und die Anwendungsentwicklung, damit Sie unmittelbar einen Mehrwert für Ihr Unternehmen schaffen können. Mit einem MarkLogic ODH wird Ihr Unternehmen nicht länger durch sich ändernde Datenstrukturen ausgebremst.

Eine 360° Sicht auf Ihr Unternehmen

MarkLogic bietet marktführende Sicherheits-, Datenschutz-, Compliance- und Lifecycle-Management-Funktionen, damit Ihre Data-Governance-Regeln auch sicher umgesetzt werden können. Sie erhalten zudem ein zuverlässiges, ausfallsicheres System, das lückenlose ACID-Transaktionen über mehrere Dokumente hinweg bietet. Ob on-premise oder in der Cloud – MarkLogic bietet Hochverfügbarkeit und Replikationsfunktionen, damit Ihre Daten selbst in anspruchsvollsten Umgebungen jederzeit sicher von A nach B gelangen.

Mit MarkLogic können Sie Ihre Daten im Laufe der Zeit bei Bedarf ändern. Dadurch können Sie Projekte schneller und zugleich mit geringerem Risiko voranbringen. Und das Beste daran: Nach Projektende verfügen Sie über eine neue, wertvolle Lösung, die problemlos an Ihre Geschäftsprozesse angepasst und weiterentwickelt werden kann.

Ihre Daten haben Besseres verdient

Mit dem flexiblen Datenmodell von MarkLogic wird die Datenintegration schneller und kostengünstiger. Befreien Sie Ihre Daten mit MarkLogic.

MarkLogic kostenlos herunterladen

Mehr über die Lösungen von MarkLogic

E-Book zum Thema herunterladen