Aktuelles

Chasm Trap

Für Analysten und Reportersteller aus den Fachabteilungen gibt es auch mit BusinessObjects 4.1 viele Fallen, in die sie bei der Analyse und Darstellung von betriebswirtschaftlichen Kennzahlen oder anderen Key Performance Indicators geraten können. Als Ersteller von BusinessObjects Universen, Datengrundlagen und Business-Schichten kann man die Anwender vor einigen dieser Fallen schützen. Eine dieser Fallen ist die Chasm Trap, in die Analysten und Reportersteller immer wieder bei der Summierung von Kennzahlen geraten. Was ist das? Und wie kann man jemanden davor schützen?

Schaut man in ein Wörterbuch, so findet man die folgenden Übersetzungen von Chasm (kä – zum)

  • Loch in der Erde, Abgrund, Schlucht
  • Unterbrechung der Kontinuität, Lücke
  • Meinungsdifferenz, Interessenunterschied

Dieses hilft uns im Moment noch nicht so richtig weiter. Wo sollen denn bei der Summierung von Kennzahlen Schluchten, Lücken oder Meinungsdifferenzen sein? Am besten lässt sich die Chasm Trap an einem Bespiel erklären. Betrachten wir ein einfaches Beispieluniversum für Bestellungen von Kunden mit 

  • jeweils einer Bestellungsposition für ein Produkt
  • Bestellmenge
  • einem in Rechnung gestellten Produktpreis
  • dem Preis für eine Bestellungsposition zum Zeitpunkt der Bestellung
  • einer Beschreibung für ein Produkt
  • historische Preisen für Produkte.

Betrachten wir die folgenden Beziehungen der Daten zueinander genauer.

  • Jeder Produktbeschreibung können mehrere Bestellungspositionen aus unterschiedlichen Bestellungen zugeordnet werden. Der Sinn dieser Relation ist es für jede Bestellungsposition eine Produktbeschreibung zuordnen zu können.
  • Zu jeder Produktbeschreibung existiert eine Preishistorie. Sinn dieser Relation ist es für jede Produktbeschreibung eine Historie von Preisvorgaben liefern zu können.

Welche Beziehung besteht zwischen der Datenbanktabelle Produktpositionen und der Datenbanktabelle Preise?

Zwischen den beteiligten Datenbanktabellen besteht bzgl. der Kardinalitäten eine n:1:n Beziehung vergleichbar mit einer Lücke oder einer Schlucht zwischen zwei Bergen.

Diese n:1:n Beziehung zwischen den beiden Datenbanktabellen ist für Auswertungen nicht ohne weiteres „sinnvoll“ nutzbar. Die Daten aus beiden Datenbanktabellen bzgl. eines Produktes haben unterschiedliche Bedeutungen.

Wenn wir eine Abfrage mit Objekten aus allen drei Datenbanktabellen durchführen und eine Gesamtsumme über die Preise für Bestellpositionen einer Bestellung bilden, so ist diese Gesamtsumme falsch , bzw. nicht die Summe, die für eine Bestellung gezahlt wurde - wir sind in die Chasm Trap gefallen! Die Summe ist falsch, weil es für jeden in Rechnung gestellten Preis über die Produkt_id mehrere historische Einkaufspreise aus der Datenbanktabelle Preise gibt. So oft es einen historischen Einkaufspreis für ein Produkt gibt, so oft wird auch der Preis für Bestellungspositionen in der Gesamtsumme berücksichtigt.

Genaugenommen ist es nicht sinnvoll in einer Berichtstabelle alle historischen Einkaufspreise für die Produkte einer Bestellung zusammen mit dem in Rechnung gestellten Preis darzustellen. Ohne das Objekt Einkaufspreis in der Datenbankabfrage aus der Preishistorie wird die Gesamtsumme korrekt gebildet.

Ziel ist es zu verhindern, dass man auf die Chasm Trap hereinfällt. Bei der Erstellung von BusinessObjects Universen können wir mit Hilfe von Kontexten verhindern, dass die Datenbanktabellen Produktpositionen und Preise in einer Abfrage mit einem einzigen SQL Statement miteinander in Beziehung gebracht bzw. abgefragt werden können. Dabei ist in BusinessObjects ein Kontext eine Untermenge von Joins in einem Universum. Jeder BusinessObjects Kontext stellt dabei einen Bedeutungszusammenhang dar. Im obigen Universum können zwei unterschiedliche Bedeutungszusammenhänge bzw. Kontexte mit Produkten identifiziert werden:

  • Historische Preise für Produkte
  • Bestellungen von Produkten 

Das Information Design Tool von BusinessObjects kann in unserem Beispiel auf Knopfdruck automatisch zwei Kontexte auf Grundlage der n:1:n Beziehung ermitteln und erstellen.

Was bewirken die beiden Kontexte? Ohne Kontexte wird von BusinesssObjects für unsere Abfrage der Objekte aus den drei Datenbanktabellen nur ein Select Statement erzeugt, welches die falsche Summierung in der WEBI Tabelle ermöglicht.

Mit Kontexten wird von Business Objects je Kontext ein Select Statement erzeugt. Zum einen für die historischen Preise für Produkte.

Zum anderen für Bestellungen von Produkten.

Kommt der Berichtsersteller auf die Idee, in einer Berichtstabelle alle historischen Einkaufspreise für die Produkte einer Bestellung zusammen mit dem in Rechnung gestellten Produkt Preis darzustellen, so erhält er mit den Objekten, die aus den zwei Select Statements stammen, die folgende Berichtstabelle.

Fazit: In dieser WEBI Tabelle ist es nicht mehr möglich, die falsche Gesamtsumme zu bilden. Man ist vor der Chasm Trap geschützt.