ACL An­a­lyt­ics™ – Re­la­tio­nen: Un­ter­schied­liche Be­zieh­ungs­typen mit ihr­en Vor­teil­en und Tü­cken

Im letzten Eintrag dieser ACL Analytics™ Blogreihe werde ich noch etwas tiefer in den Bereich der Relationen einsteigen und die im vorherigen Artikel (Relationen: Einfach, indirekt und mittels kombiniertem Textfeld) beschriebenen Möglichkeiten genauer erläutern.

Zunächst werden wir die unterschiedlichen Beziehungstypen kennenlernen und erfahren welche Fragestellungen mittels Relationen sehr einfach beantwortet werden können. Anschließend zeige ich Ihnen welche Fehler passieren können, wenn Sie mit Relationen arbeiten und wie sich diese am besten vermeiden lassen. Wie Sie bereits wissen, ist es in ACL™ problemlos möglich Daten aus mehreren Tabellen gemeinsam für Auswertungen zu verwenden. Eine wichtige Rolle spielen hierbei allerdings die in der Datenmodellierung eingesetzten Beziehungstypen (Kardinalitäten). Diese beschreiben wie die zwei Tabellen zu einander stehen, bzw. genauer gesagt die Datensätze der Tabellen (Primärtabelle und Sekundärtabelle). Dazu benötigen die Tabellen ein Schlüsselfeld, wodurch ein Datensatz eindeutig bestimmt werden kann. (Auch ein zusammengesetzter Schlüssel aus mehreren Feldern ist möglich) Dies klingt erst einmal sehr technisch, ist aber im Grunde genommen ganz einfach, wenn man sich drei grundlegende Arten mit einfachen Beispielen verdeutlicht:

In den meisten Fällen werden Sie es mit 1:n – Beziehungen zu tun haben, so wie es auch in unserem Beispiel im letzten Blogeintrag der Fall war. Dort haben wir Beziehungen dazu genutzt, um weiterführende Informationen aus anderen, über Schlüsselfelder verbundenen Tabellen hinzuzufügen (Beispiel: Einkaufsbelege um die Namen des entsprechenden Lieferanten erweitert).

Für die Arbeit mit ACL™ ist es wichtig zu beachten, von welcher Tabelle man aus startet, wenn man eine solche Beziehung festlegt. In diesem Zusammenhang haben Sie auch bereits eine Art Faustregel von mir erhalten. (Relationen stets beginnend von den Bewegungsdaten aus definieren) Das bedeutet, Sie sollten immer von der Tabelle mit mehreren Einträgen pro Schlüsselfeld zur Tabelle mit dem eindeutigen Eintrag pro Schlüsselfeld verbinden.

An unserem Beispiel wäre dies:

Eigentlich gar nicht so schwer, oder? Aber was ist, wenn sich nicht so einfach bestimmen lässt, welche der Tabellen Stamm- bzw. Bewegungsdaten enthält oder wenn sich die Daten erst gar nicht nach dieser Systematik einordnen lassen, wie es z.B. bei den Tabellen Einkaufsbeleg_Kopf und Einkaufsbeleg_Position der Fall ist? Möchte man diese Tabellen verbinden (um z.B. die Zahlungsbedingungen aus der Kopftabelle kombiniert mit den Mengen und Preisen aus der Positionstabelle zu analysieren) muss genau überlegt werden, wo man mit der Relation ansetzt und die Primärtabelle (n-Tabelle) auf Basis des gemeinsamen Schlüsselfeldes ermitteln.

Ein Tipp, wie Sie den Status des Schlüsselfelds (eindeutig oder ob es mehrfach vorkommen kann) ganz einfach vor dem Erstellen einer Relation überprüfen können - Verwenden Sie den ACL™ Befehl für die Duplikaten-Suche:

Die Tabelle mit den Duplikaten (Im Beispiel: Einkaufsbeleg_Position) ist Ihre Ausgangstabelle zu der Sie weitere Tabellen verknüpfen können, solange das gemeinsame Schlüsselfeld (Im Beispiel: Einkaufsbelegnummer, in der zu verknüpfenden Tabelle nur einmal vorkommt, also keine Duplikate enthält).
Im vorherigen Blogeintrag haben wir diese Verbindung bereits richtig gemacht und mit der Positionstabelle begonnen, um diese um Informationen aus der Kopftabelle zu erweitern. (Oder um genauer zu sein, wurde ein Schlüsselfeld der Kopftabelle dazu genutzt auf eine weitere Tabelle zu verknüpfen – indirekte Relation).
Aber was wäre wenn man die zwei Tabellen falsch herum verknüpft? Lassen Sie uns das probieren uns sehen was passiert:

Verknüpft man die zwei Tabellen über die Einkaufsbelegnummer ausgehend von den Kopfdaten und fügt anschließend Felder hinzu (Im Beispiel Werk und Nettopreis), um damit weiter für Summen oder Klassifizierungen zu arbeiten. So muss einem im Klaren sein, dass hier jeweils immer nur die Informationen der ersten Position zu der entsprechenden Einkaufsbelegnummer übertragen werden und alle anderen Positionen (Zeilen) verloren gehen. Angenommen, die Kopftabelle beinhaltet 10 Bestellungen, die zugehörige Positionstabelle 30 Bestellpositionen. Die Anzahl der Datensätze der Kopftabelle ändert sich durch die Relation nicht, d.h. den 10 Bestellungen wird jeweils eine Bestellposition zugeordnet. Immer dann, wenn es aber mehrere Positionen zu einer Bestellung gibt, muss ACL™ entscheiden, welcher Eintrag dafür verwendet werden soll und überträgt deshalb immer nur den ersten aus der Positionstabelle. Von den 30 Bestellpositionen werden also nur 10 verbunden und werden demzufolge berücksichtigt, die restlichen 20 gehen verloren und stehen für Analysen in der Kopftabelle nicht zur Verfügung. Am einfachsten lässt sich das beim Vergleich der zwei Tabellen feststellen.

An diesem Beispiel können Sie erkennen wie wichtig es ist mit der richtigen Tabelle zu starten. Um diesen Fehler nicht zu begehen, sollte man sich deshalb vor jedem Verbinden von Tabellen überlegen, welche denn die richtige Ausgangstabelle ist. Damit keine Informationen verloren gehen muss immer mit der Tabelle, die mehrere Einträge zu dem gemeinsamen Schlüsselfeld pflegt begonnen werden. (Mit der n-Tabelle unserer 1:n Kardinalität). In unserem abstrakten Beispiel würden dann den 30 Bestellpositionen jeweils die Informationen aus der Kopftabelle zugeordnet – bei Bestellungen mit mehr als einer Position auch redundant. Informationen gehen auf diese Art aber nicht verloren.

Neben dieser sehr nützlichen Einsatzmöglichkeit von Relationen - Erweitern der Tabellen um Felder aus anderen, über ein Schlüsselfeld verbunden Tabellen - können Relationen auch dazu genutzt werden, um Fragestellungen nach nicht in einer Tabelle aufgeführten Verbindungen zu beantworten: Gibt es Einträge (Schlüsselfelder) in Tabelle A, die nicht in Tabelle B vorkommen? An einem konkreten Beispiel könnte das die Frage nach Lieferanten, bei denen keine Einkäufe getätigt wurden sein (Evlt. wollen Sie die Lieferantenstammbasis bereinigen und bei nicht mehr relevanten Lieferanten den Löschvermerk setzen). Um das zu erreichen, müssen wir jedoch entgegen der allgemeinen Faustregel mit der Stammdatentabelle der Lieferanten starten und über die Lieferantennummer eine Beziehung zur Tabelle Einkaufsbeleg_Kopf aufbauen. Was nach einem Workaround aussieht, ist in Wahrheit ein gültiger Ansatz in der Datenanalyse, um Einträge (Schlüsselfelder) zu ermitteln, die in der Primärtabelle enthalten sind, aber in der Sekundärtabelle fehlen.