Beispiel für virtuelle Metadaten

Indem Sie einige der Informationen extern speichern und dann virtuell darauf zugreifen, können Sie eine vollständige Ansicht Ihres Kunden erhalten. Gleichzeitig können Sie den Bedenken bezüglich der Duplizierung von Daten im Data Hub entgegenwirken.

Das Data Hub-Modell

Sie verfügen über ein vorhandenes Modell mit zwei Entitätstypen: Customer und CustomerMaster mit der Beziehung HasMasterRecord.

Das folgende Bild zeigt ein Modell, das mit diesen Metadaten erstellt wurde. Beachten Sie, dass George und Martha Washington separate Customer-Entitäten haben. Sie teilen sich jedoch die gleiche CustomerMaster-Entität, weil die Master-ID einen Haushalt und keine Person darstellt.

Die externen Tabellen

Wir möchten die Kunden mit ihrem Kaufverlauf verknüpfen. Dafür verwenden wir drei externe Tabellen: eine für Kunden, eine für Käufe und eine für Produkte.

Wir verwenden die gleichen Informationen für die Tabelle Kunden, die wir auch zum Ausfüllen der Customer-Entitäten verwendet haben:

Die Tabelle Käufe enthält Bestellnummern, Produkt-IDs und Kaufdaten und gibt an, ob der Kauf online erfolgt ist. Sie bindet diese Daten an die Kunden-ID, die auch in der Tabelle „Kunden“ verwendet wurde.

Die Tabelle Produkte enthält Produktnamen, Modellnummern und Beschreibungen. Sie bindet diese Daten an die Produkt-ID, die auch in der Tabelle „Käufe“ verwendet wurde.

Die Tabelle „Kauf“ dient als Join-Tabelle, die Verbindungen zwischen Datensätzen in den Tabellen „Kunden“ und „Produkte“ herstellt. Die folgende Abbildung zeigt die Beziehungen zwischen den verschiedenen Feldern in den drei externen Tabellen.

Verknüpfen von physikalischen und virtuellen Daten

Um Beziehungen zwischen Entitäten im Data Hub-Modell und Datensätzen in den externen Tabellen zu erstellen, müssen die Data Hub-Entitäten Eigenschaften aufweisen, die auf die externen Daten verweisen. Für eine Verknüpfung vom Data Hub-Modell zu den Datensätzen in der Tabelle „Kunden“ muss eine Eigenschaft in der externen Tabelle vorhanden sein, die die gleichen Werte enthält, die im Feld „CustomerID“ der Entitäten gespeichert sind. In der folgenden Abbildung können Sie sehen, dass die Entität „Martha Washington“ eine Eigenschaft namens CustRef hat, die in der Tabelle „Kunden“ denselben Wert wie das Feld „CustomerID“ enthält.

Um die Verbindung zwischen der Entität „Customer“ und der externen Tabelle herzustellen, müssen wir zunächst eine virtuelle Entität für die Tabelle „Kunden“ erstellen. Die Anweisungen dazu beginnen mit Schritt 5 des vorherigen Themas „Verwenden von virtuellen Metadaten in Modellen“. Die folgende Abbildung zeigt den ausgefüllten Bildschirm für den neuen Entitätstyp. Beachten Sie, dass „CustomerID“ als Primärschlüssel ausgewählt ist. Dies ist die Eigenschaft, die die virtuellen und physischen Entitäten verknüpft.

Nach dem Hinzufügen der virtuellen Entität müssen wir eine Beziehung hinzufügen, die diese Entität mit der physikalischen Entität verbindet, die sich bereits im Modell befindet. Die Anweisungen dazu beginnen mit Schritt 14 des vorherigen Themas. Die folgende Abbildung zeigt den ausgefüllten Bildschirm für den neuen Beziehungstyp. Beachten Sie, dass sich die Quellentitäts-ID auf die Eigenschaft „CustRef“ und die Zielentitäts-ID auf die Eigenschaft „CustomerID“ bezieht; dies ist die Verknüpfung, die die virtuelle Entität an die physikalische Entität bindet, da beide Eigenschaften die Kunden-ID enthalten.

Außerdem ist in diesem Beispiel die Beziehung zwischen den Kunden eine 1:1-Beziehung. Das bedeutet, dass für jede physikalische Entität höchstens eine virtuelle Entität und für jede virtuelle Entität höchstens eine physikalische Entität vorhanden sein sollte. Bei 1:1-Beziehungen und 1:n-Beziehungen besteht keine Notwendigkeit für eine echte Join-Tabelle. Deshalb wählen wir die Tabelle „Kunden“ aus, die ebenfalls zur Definition der virtuellen Entität verwendet wurde.

Die Metadaten für das Modell enthalten nun einen Link zu den virtuellen Daten. Beachten Sie den blauen Stern neben der Entität „ERP_Customer“. Dies bedeutet, dass die Entität virtuell ist.

n:n-Beziehungen

Jetzt, da wir den virtuellen Kunden mit dem physischen Kunden verbunden haben, müssen wir auch Käufe und Produkte verbinden. Optimal ist die Erstellung einer virtuellen Entität für Produkte und einer virtuellen Beziehung zwischen physikalischen Kunden und virtuellen Produkten, die die Tabelle „Käufe“ Join-Tabelle verwenden. Zuerst müssen wir eine virtuelle Entität für die Tabelle „Produkte“ erstellen, die „ProductID“ als Primärschlüssel verwendet.

Anschließend wird eine neue Beziehung hinzugefügt, die die Tabelle „Käufe“ als eine Join-Tabelle verwendet, um eine n:n-Beziehung zu erreichen. Die Entitäten „Customer“ werden mit den Entitäten „Product“ auf der Grundlage von Informationen der Tabelle „Käufe“ verknüpft. Beachten Sie, dass die Eigenschaft „CustomerID“ als Link-ID für die Entitäten „Customer“ und die Eigenschaft „ProductID“ als Link-ID für die Entitäten „Product“ verwendet wird. Die Tabelle „Käufe“ enthält beide dieser Eigenschaften, so dass sie Informationen von „Customer“ zu „Product“ zuweisen kann.

Die Quellentitäts-ID (CustRef) ist die Eigenschaft der Entität „Customer“, die mit der Spalte „Quell-Link-ID“ (CustomerID) in der Tabelle „Käufe“ verglichen wird. Die Ziel-Link-ID (ProductID) ist die Spalte in der Tabelle „Käufe“, die an die Eigenschaft „Zielentitäts-ID“ (auch ProductID) der Entität „Product“ angepasst wird. Das folgende Diagramm veranschaulicht, wie jedes Feld zur Verknüpfung von „Customer“ zu „Product“ verwendet wird.

Erweiterte Konfiguration

Eine Alternative zu dem hier gezeigten Ansatz besteht darin, die Tabelle „Käufe“ zu verwenden, um die n:n-Beziehung zwischen dem virtuellen Kunden und den virtuellen Produktentitäten zu erstellen. Dazu gehört ein zusätzlicher und unnötiger virtueller Sprung vom physikalischen Kunden zum virtuellen Kunden. Der Data Hub ist beim Durchlaufen von Beziehungen viel effizienter als SQL-Datenquellen, da er auf einer Graphdatenbank basiert. Daher sollte der Extrasprung möglichst vermieden werden.

Eine zweite Alternative ist die Erstellung virtueller Entitäten für die Tabelle „Käufe“ zusätzlich zu denen für die Tabelle „Produkte“. Dieser Ansatz würde eine Beziehung zwischen physikalischen Kundenentitäten und virtuellen Käufen sowie eine Beziehung zwischen virtuellen Käufen und virtuellen Produkten erfordern. Dies ist ineffizient, weil unnötige virtuelle Sprünge erzeugt werden, um vom physikalischen Kunden zum virtuellen Produkt zu gelangen. Es gibt keinen Vorteil bei der Darstellung eines Kaufs als eine Entität, da die Beziehung alle Felder „Käufe“ als Eigenschaften enthalten kann. Der einzige Grund, eine Entität für Käufe zu erstellen, besteht darin, dass sie mehr als zwei Entitätstypen miteinander verbindet. Dies wäre so, als gäbe es einen dritten Fremdschlüssel in der Tabelle, der die Käufe mit einem Geschäft verknüpft.