21.07.2015
Anton Grening
Autor: Anton Grening

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:

 

 

1:1

Jeder Datensatz der ersten Tabelle kann nur einem Datensatz der zweiten Tabelle zugeordnet werden und umgekehrt.

Beispiel (Lieferantenstammdaten | Lieferantenbewertungen): Jeder Lieferant aus der ersten Tabelle, hat nur eine Lieferantenbewertung in der zweiten Tabelle. Gleichzeitig gehört eine Lieferantenbewertung genau zu einem Lieferanten.

1:n

Einem Datensatz der ersten Tabelle können mehrere Datensätze in der zweiten Tabelle zugeordnet werden, aber einem Datensatz der zweiten Tabelle ist nur ein Datensatz in der ersten Tabelle zuordenbar oder umgekehrt.

Beispiel (Lieferantenstammdaten | Einkaufsbelege): Ein Einkaufsbeleg gehört zu genau einem Lieferanten (= die Ware wurde von diesem Lieferanten bezogen). Dieser Lieferant kann aber mehreren Einkaufsbelegen zugeordnet werden (evlt. wurden hier ja schon 10 Einkäufe dieses Jahr getätigt)

n:m

Den Datensätzen der ersten Tabelle können mehrere Datensätze der zweiten Tabelle zugeordnet werden und umgekehrt.

Beispiel (Liste mit benötigten Materialien | Liste mit Lieferanten und ihren verfügbaren Materialien): Ein Material kann von mehreren Lieferanten bezogen werden und ein Lieferant liefert mehrere Materialien.

 

 

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:

 

 

Kardinalität1:n
TabellentypStammdaten:Bewegungsdaten
TabelleninhaltLieferant:Einkaufsbeleg(e)
Gemeinsames SchlüsselfeldLieferantNr:Lieferantennr
Schlüsselfeldstatus

eindeutig

(Jeder Lieferant kommt in der Tabelle nur einmal vor)

:

kann mehrfach vorkommen

(Ein Lieferant kann keine Einkaufsbelege, einen Einkaufsbeleg oder viele Einkaufsbelege haben)

 

 

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:

Relationen ACL Analytics™

Abbildung1: ACL™ Duplikaten-Suche für die Überprüfung der Schlüsselfelder

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:

Positionstabelle

Abbildung2: Verbinden von Kopf- und Positionstabelle falsch herum

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.

Kopf-und Positionstabelle Vergleich

Abbildung3: Vergleich von Kopf- und Positionstabelle nach dem Hinzufügen der Felder

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.

Lieferantenstammdaten verbinden

Abbildung 4: Verbinden der Lieferantenstammdaten mit den Kopfdaten der Einkaufsbeläge

Durch das Erzeugen der Beziehung allein, kann die Frage nach den fehlenden Verbindungen noch nicht beantwortet werden. Wie Sie noch aus dem ersten Beispiel wissen, ändern sich die Anzahl der Einträge in der Primärtabelle nicht, egal ob und wie viele Verbindungen zur Sekundärtabelle existieren. Um die Frage zu beantworten müssen wir das Schlüsselfeld „Einkaufsbelegnummer“ aus der Tabelle Einkaufsbeleg_Kopf zu unserer Primärtabelle hinzufügen. Dadurch können Zeilen identifiziert werden, die eine Verbindung aufweisen, also mindestens ein Einkaufsbeleg zu dem Lieferant existiert. Dadurch kann abgeleitet werden, dass bei Lieferanten, bei denen das Feld leer bleibt, auch keine Einkäufe getätigt wurden, da sich kein Eintrag für diesen Lieferanten in der Bestelltabelle befindet. I.d.R. eignet sich das Schlüsselfeld am besten für diese Überprüfung, denn es muss sichergestellt sein, dass das Feld auch tatsächlich gefüllt sein müsste – andernfalls ist unsere Überprüfung auf leere Feldinhalte möglicherweise nicht ganz trennscharf. Relationen sind in ACL Analytics™ ein mächtiges Werkzeug und können vielfältig eingesetzt werden, allerdings muss man dabei sehr überlegt vorgehen. Fehler können unbemerkt passieren und unter Umständen Ergebnisse verfälschen. Beachtet man aber die in diesem Blogeintrag erläuterten Tipps und Beispiele, wie die Faustregel (Relationen stets aus den Bewegungsdaten bzw. der n-Tabelle definieren) oder die Überprüfung der Tabellen mittels der Duplikaten-Suche, so können Tabellen ohne Bedenken verbunden und Felder gemeinsam ausgewertet werden.
Damit beende ich diese ACL Analytics™ Blogreihe und hoffe ich konnte Ihnen einige Tipps für das Arbeiten mit ACL™ geben.

Bei Fragen und Anregungen für weitere Themen die Sie hier gerne als Blogeintrag lesen würden, schreiben Sie uns einfach an info@dab-gmbh.de


Kommentare (0)
Sei der erste, der diesen Blog-Beitrag kommentiert.
Blog Anmeldung

Sie sind nicht angemeldet. Bitte melden Sie sich an um diesen Blogbeitrag zu kommentieren.

anmelden