tabellen-Relationen

Es muss unbedingt beachtet werden, dass das Selligent Campaign Setup nur mit einem Sternschema funktioniert (nicht mit einem Schneeflocken-Schema). Beim Umgang mit Ihren Daten in der Selligent Campaign Umgebung ist es sehr wichtig zu verstehen, wie die Daten zur Verwendung innerhalb von Journeys strukturiert werden müssen. Ja nach Struktur können manche Aktionen ausgeführt werden und manche nicht.

Bei gängigen Datenbankmodellen - wie zum Beispiel für eine CRM-Plattform - wird eine solche Struktur verwendet:

Im obigen Beispiel sind verschiedene Tabellen vorhanden, von denen jede verschiedene Informationsbrocken enthält. Wenn Sie wissen wollten, welcher Kunde eine bestimmtes Produkt gekauft hat, müssten Sie die Daten aus 4 verschiedenen Tabellen kombinieren (Benutzer Einzelhändler, Bestellungen, Auftragspositionen & Produkte). Diese Art der Datenzusammenführung ist in Selligent Campaign nicht möglich. Das System kann nur auf Daten in Tabellen zugreifen, die direkt mit Ihrer Master-Tabelle verknüpft sind. Bei Journeys ist das immer die Zielgruppentabelle. Das beinhaltet, dass das Selligent-Datenbankmodell immer ein „Stern“ sein sollte, bei dem die Zielgruppentabelle im Mittelpunkt steht. Es gibt zwar Ausnahmen, aber das ist die generelle Richtlinie.

Im obigen Beispiel würde USERS_RETAILER im Zentrum stehen, und es könnte nur auf Daten aus DATA_ORDERS zugegriffen werden. Die Daten müssen zuerst verarbeitet werden, damit Informationen aus der Produkt-Tabelle abgerufen werden können. Auswahlen aus der Bestell-Tabelle sind zwar möglich, können jedoch nicht zur Personalisierung in Journeys verwendet werden, weil sie über eine 1-zu-Vielen-Relationen (1:N) verknüpft ist. Selligent Campaign kann nicht schätzen, welcher Datensatz zur Personalisierung eines Kontaktes ausgewählt werden sollte. Wenn Sie Auftragsdaten zu Personalisierungszwecken verwenden wollen, so müssen die Daten in einer 1-zu-1 mit Zielgruppentabelle verknüpften tabelle zusammengefasst werden. Zum Beispiel die Anzahl an Bestellungen (Bestell-Datensätze), in einem ORDER_COUNT-Feld in einer 1:1 verknüpften „ORDER_INFO“-tabelle.

Die folgenden 2 Relationen werden hauptsächlich verwendet:

  • 1:1 (Profilerweiterungen), verwendet für Auswahl und Personalisierung. Diese Relation kann praktisch als Erweiterung Ihrer Zielgruppentabelle betrachtet werden.
  • 1:N (Suchtabellen), nur für Auswahlen, nicht zur Personalisierung. Datensätze können bis auf benutzerdefinierte Komponenten für Gespeicherte Verfahren nicht über die Verwendung von standardmäßigen Journey-Komponenten aktualisiert werden.

 

Die Registerkarte „Relationen“ zeigt alle Abhängigkeiten an, die unter der ausgewählten tabelle und anderen tabellen bestehen.

Über einen Doppelklick auf eine bestehende Relation öffnet sich der Eigenschaften-Dialog für diese Relation. Beim Erstellen einer neuen Relation wird derselbe Dialog angezeigt.

  • Bereich: Der Name der Relation, der im Editor und im Abschnitt Journey verwendet wird, um die verknüpfte tabelle zu identifizieren. Bei der 1:1-Relation können Felder aus der verknüpften tabelle zur Personalisierung und Segmentierung im Editor verwendet werden. Z.B. ~LOYALTY_CARD.POINTS~
  • Beschreibung: Eine Zusammenfassung der Relation
  • Master-Tabelle: Die aktuell ausgewählte tabelle. Das ist normalerweise die Zielgruppentabelle.
  • Relation: Die Art der Relation zwischen Master und Slave. 1:1, 1:N, und- eher selten verwendet - N:1, N:N
  • Slave-Tabelle: Die tabelle, die von der Relation targetiert wird. Das Dropdown-Menü, vom dem aus eine tabelle ausgewählt werden kann, bietet Informationen zum tabellentyp und Tabellennamen.
  • Abgleichsschlüssel: Ein Abgleich zwischen den Schlüsselfeldern beider tabellen; abgeglichen wird hier der Datensatz in der Slave-tabelle (Fremdschlüssel) mit dem Datensatz in der Master-tabelle.
    Müssen mehrere Felder abgeglichen werden, erfolgt dies über die manuelle Eingabe eines SQL-Statements vom Feld „Benutzerdefinierte Relation“ aus. Wenn zum Beispiel eine Gewinnspiel-tabelle mehrere Gewinnspiel-Datensätze für einen Kontakt enthält (normalerweise 1:N), können Sie eine 1:1 Relation mit Abgleichsschlüsseln für ID zu USERID erstellen, und die benutzerdefinierte Relation CONTEST3.CONTESTID=3, wobei "CONTEST3" die Bereichsbezeichnung ist.

Technischer Hinweis zu Relationstypen:
(Schreibkonvention Master-tabelle: Slave-tabelle)
1:1 Relation wird auch als Profilerweiterung bezeichnet. Beispiel: Ein Kontakt kann an einem Gewinnspiel teilnehmen
1:n: Eine Master-tabelle ist mit mehreren Einträgen der Slave-tabelle verknüpft. Beispiel: Ein Kontakt kann mehrere Produkte kaufen
n:n: Mehrere Einträge in der Master-tabelle sind mit mehreren Einträgen der Slave-tabelle verknüpft. Beispiel: Mehrere Produkte können von mehreren Kontakten gekauft werden
n:1: Mehrere Einträge in der Master-tabelle sind mit dem einen Eintrag in der Slave-tabelle verknüpft. Beispiel: Es können mehrere Kontakte mit derselben Adresse verknüpft sein.