In diesem Blogbeitrag wird das OLAP-Modell der Beispieldatenbank Wide World Importers von Microsoft vorgestellt. Dies umfasst einen Überblick über die Komponenten von Wide World Importers, der Installation der relationalen und multidimensionalen Datenbank, die Analyse des von Microsoft bereitgestellten Modells, die Modellierung mit DeltaMaster ETL und eine Sammlung von Beispielberichten.
Thema und Installation
Einleitung
Artikel: SQL Server Samples Repository
Microsoft (MS) führt auf der Entwicklungsplattform GitHub ein Repository mit Beispieldatenbanken und Skripten zu Microsoft SQL Server, Azure-SQL-Datenbanken und Azure-SQL-Data-Warehouses. Dieses Repository kann frei heruntergeladen und die darin verwendeten Dateien zum Arbeiten verwendet werden. Im Ordner samples\databases befinden sich vier Beispieldatenbanken:
- Wide World Importers: Zur Demonstration der wesentlichen Kapazitäten von SQL Server 2016 und Azure SQL Database
- Contoso Data Warehouse: Beispiel für das Laden von Daten in ein Azure SQL Data Warehouse
- Adventure Works: Beispieldatenbanken und Analysis Services-Modelle mit SQL Server
- Northwind und Pubs: alte Beispieldatenbanken von Microsoft
Dieser Blogbeitrag untersucht einen Teil der Möglichkeiten, die das Modell Wide World Importers (WWI) bietet und verwendet die Release-Version 1.0.
Thema
Artikel: Wide World Importers sample databases for Microsoft SQL
WWI ist ein Modell eines fiktiven Konsumgüter-Importeurs und -Händlers an der US-Westküste. Im Unternehmen fallen verschiedene Workflows an, z. B. die folgenden:
- WWI bestellt bei seinen Lieferanten und bestätigt die Bestellungen.
- Lieferanten senden Produkte, WWI erhält und lagert sie ein.
- Kunden bestellen Produkte und WWI kommissioniert die Artikel. Sind sie nicht vorhanden, werden sie von den Lieferanten bezogen. Unvollständige Lieferungen werden nachgesendet.
- Bestellungen werden zu Rechnungen, Kunden bezahlen Rechnungen.
- WWI stellt die Produkte mit eigenen oder fremden Lieferfahrzeugen zu.
- Lieferanten werden periodisch bezahlt.
Ein Teil der anfallenden Daten werden zu Analysezwecken in das Data Warehouse transportiert.
Voraussetzungen
Artikel: Download and install SQL Server Data Tools (SSDT) for Visual Studio
Dieser Blogbeitrag setzt sich nur mit dem multidimensionalen Modell auseinander, für dieses reichen die folgenden Komponenten:
- Eine MS SQL Server 2017 Enterprise Edition-Datenbank, in der ein Datenbank-Backup wiederhergestellt werden kann und in dem die notwendigen Rechte zum Erzeugen einer MS Online Analytical Processing (OLAP)-Datenbank bestehen.
- Microsoft Visual Studio Data Tools (SSDT), das kostenfrei in dem oben genannten Artikel heruntergeladen werden kann.
Installation
Wide World Importers relationale Datenbank
Artikel: Wide World Importers sample database v1.0
Das WWI-Thema umfasst viele Komponenten, von denen im Rahmen des Beitrags nur diejenigen zum Aufbau des multidimensionalen Modells näher betrachtet werden. Dafür reicht es aus, die Datenbank-Sicherung WideWorldImportersDW-Full.bak herunterzuladen und die Sicherung als SQL-Server-Datenbank wiederherzustellen.
Wide World Importers multidimensonale Datenbank
Artikel: SSAS Multidimensional Project for WideWorldImporters
Für die Erstellung der multidimensionalen Datenbank kann die Visual-Studio-Solution aus dem Artikel verwendet werden. Eine Möglichkeit, Zugang zu den Dateien zu erhalten, liegt darin, das gesamte Repository herunterzuladen. Hierzu muss auf die höchste Ebene des Repositories navigiert werden, auf der die Download-Funktion gegeben ist.
Ist eine lokale Kopie des Verzeichnisses vorhanden, kann mit der mitgelieferten SSDT-Solution die OLAP-Datenbank erzeugt werden. Dazu öffnet man die Datei wwi-ssasmd.sln mit einem Doppelklick. Auf der rechten Seite ist dann die Projektmappe zu sehen.
Gemäß der Anleitung des Artikels kann die OLAP-Datenbank erzeugt werden.
OLAP-Modell
In diesem Kapitel wird das OLAP-Modell der WWI von Microsoft (MS-WWI-OLAP-Modell) beleuchtet. Dabei werden die Dimensionen, die MeasureGroups, die Verwendung der Dimensionen in den MeasureGroups und die berechneten Kennzahlen untersucht.
Dimensionen
In dem Modell existieren zehn Dimensionen. Über die Attributbeziehungen lassen sich die Hierarchien und Ebenen der Dimensionen kompakt abbilden, wie die folgenden Ausschnitte zeigen. Dabei entsprechen die untersten Ebenen fast immer dem Dimensionsnamen. Ausnahmen bilden lediglich die zwei Dimensionen Transaction Finalized und Purchase Finalized, deren einzige Ebenen Date Transaction Key und Date Purchase Key sind.
Die Themen und Beziehungen sind überwiegend selbsterklärend: neben den klassischen relevanten Vertriebsmerkmalen eines Handelsunternehmens wie Kunde, Produkt und Zeit sind auch der Lieferant (Supplier) wie auch die Transaktionen abgebildet. Dabei bestehen die folgenden Auffälligkeiten:
- Keys werden oftmals über eine sonst gleichnamige darüberliegende Ebene zusammengefasst (z. B. bei Employee und Customer)
- Die Ebenen Date Transaction Key und Date Purchase Key sind nicht sichtbar. Stattdessen existieren für die Attribute flache Hierarchien.
- Obwohl Microsoft die Dimensionseigenschaft Type anbietet, die verschiedene Ausprägungen wie Geography, Accounts und Customers kennt, werden diese nicht verwendet. Selbst der Typ Zeitdimension ist nicht festgelegt.
MeasureGroups
In der Würfelstruktur sind die fünf MeasureGroups wie auch die beinhalteten Kennzahlen zu finden. Diese sind Vertrieb (Sale), Lagerhaltung (Stock Holding), Transaktionen (Transaction), Kunden-(Order) und Lieferantenbestellungen (Purchase).
Alle MeasureGroups haben einen Zähler und über die Gruppen hinweg vergleichbare Kennzahlen, z. B. Mengen und/oder Umsätze (inkl. & exkl. Umsatzsteuer).
Dimensionsverwendung
Mit der Dimensionsverwendung des Würfels lässt sich ein guter Überblick über das gesamte Modell gewinnen. Dieses entspricht der oft verwendeten Visualisierungsform der Dimension-Measure-Matrix.
Dabei ist bemerkenswert:
- Dimensionen (Employee, Customer, Date) werden in mehreren Rollen verwendet.
- Für Sale wie auch Order wird der Sales Person Key verwendet, einmal jedoch auf die Dimension (Employee) und einmal auf die Rolle (Employee (Salesperson)).
- Bill To Customer ist sowohl eine höhere Ebene von Customer wie auch eine Rolle der Dimension Customer.
- Obwohl modelliert, wird die Dimension Purchase Finalized nicht verwendet.
Berechnete Kennzahlen und KPIs
Neben diesen Kennzahlen existieren 40 berechnete Kennzahlen. Diese umfassen YTD-Werte der Basis-Kennzahlen, YTD-Summen des Vorjahreselements sowie Planzahlen, die den Vorjahreswert mit 1.10 multiplizieren.
Die definierten KPIs geben Aufschluss über potenzielle Fragestellungen. Dabei gibt es drei Bereiche, die durch Multiplikatoren mit dem Plan-Wert beschrieben werden: Wird der Plan-Wert mit dem Positiv-Multiplikator durch den Ist-Wert überschritten, ist der Indikator 1. Wird der Plan-Wert mit dem Negativ-Multiplikator unterschritten, ist der Indikator -1. In dem Bereich dazwischen ist er 0. Verschiedene Formen von Indikatoren werden angewandt.
Blick auf das Modell mit DeltaMaster
Im Unterschied zu vorherigen Beispieldatenbanken von Microsoft (z. B. Adventure Works) existiert keine Perspektive für das Management, das nur einen Ausschnitt des Datenmodells verwendet.
Die Datenbank hat den Titel „WWI-SSASMD“, der vorhandene Cube „Wide World Importers“. Eine Verbindung mit DeltaMaster auf das Modell erlaubt einen grafischen Überblick über die Dimensionen und eine Auswahl der Kennzahlen. Einem Teil der Kennzahlen wird basierend auf Schlüsselwörtern wie „Cost“ eine negative betriebswirtschaftliche Bedeutung zugemessen.
Mit Hilfe des Perspektiven-Konzepts kann eine fachliche Ordnung umgesetzt werden. Beim Modellieren kann z. B. eine Sale-Perspektive angelegt werden, die nur die Kennzahlen und verwendeten Dimensionen der Sale-MeasureGroup verwendet. Zudem kann der Parameter der Zeit-Dimension auf die Hierarchie Invoice Date.Calendar gesetzt werden, um den Magic Button Delta VJ nutzen zu können.
Unter Verwendung der Magic Buttons lässt sich mit wenigen Klicks der folgende Bericht erstellen. Der Filter ist auf den Dezember 2015 gesetzt. Die Sparklines können nicht verwendet werden, da mehrere Zeit-Elemente auf der Spaltenachse gesetzt sind. Dies ist der Fall, da die Vergleichs-Elemente wie ∆VJ in der Zeit-Dimension verwendet werden.
Die Kennzahlen haben unterschiedliche Zahlenformate, zu sehen an dem Sales Unit Price.
Das von Microsoft verwendete KPI-Konzept wird in DeltaMaster nicht genutzt.
Modellierung in DeltaMaster ETL
Das vorgestellte Modell wird nun mit Hilfe von DeltaMaster ETL mit den folgenden Änderungen nachgebaut:
- Die von DeltaMaster ETL mitgelieferten Dimensionen (Periode, Wertart, Kumulation, Periodenansicht) werden verwendet.
- Die KPIs werden in einer DeltaMaster-Anwendung mit Filterkennzahlen umgesetzt.
Das finale Modell (DMETL-WWI-OLAP) ist in den nächsten Abbildungen dargestellt.
Vorbereitungen
Die relationale WWI-Datenbank bleibt unberührt, indem eine neue Datenbank WideWorldImportersDW_DMETL erstellt wird. In diese wird das Metamodell erzeugt.
Das Datenmodell kennt Werte von 2013 bis 2016. Das Jahr 2017 wird hinzugefügt, da die Ist-Werte des Vorjahres die Plan-Werte des nächsten Jahres darstellen.
Nach Ausführung der Schritte der Erzeugung des Metamodells sind die vier Standarddimensionen Periode, Wertart, Periodenansicht und Kumulation angelegt und befüllt. In der DeltaMaster-ETL-Anwendung sind die Connection Properties und Parameters auf die Modellierung mit DeltaMaster ETL gemünzt.
Dimensionen
Nach Analyse der zugrunde liegenden relationalen Tabellen ergibt sich folgendes Bild über die Dimensionen:
Dazu die folgenden Anmerkungen:
- Die durch DeltaMaster ETL mitgelieferten Dimensionen haben die Nummern 1 bis 4. Anstatt der sehr umfangreichen Datumsdimension von Microsoft wird die schlankere Dimension von DeltaMaster ETL verwendet, die die Unterscheidung zwischen Monaten und Kalenderwochen kennt.
- Wertansicht und Kumulation sind bei allen MeasureGroups mit dem Element „aktuell“ besetzt.
- Die Dimensionen aus dem WWI-Modell haben die Nummern 10 bis 19.
- Die relationale Tabelle der Transaktionen kann noch zwischen Kunden- und Lieferantentransaktionen unterschieden werden, da diese unterschiedliche Dimensionalitäten aufweisen. Mit diesem Hintergrund werden zwei Dimensionen für die Angabe, ob Transaktionen finalisiert sind, verwendet.
- Content ist der Dimension Type in den Data Tools. Während er dort nicht verwendet wird, wird er hier zur Orientierung ausgefüllt. DeltaMaster verwendet diese Einstellung bei den mitgelieferten Dimensionen, um die Konfigurationen im Modellieren automatisch auszufüllen.
Die Dimension Period wird von den MeasureGroups standardmäßig verwendet, was eine leichtere Vergleichbarkeit zwischen MeasureGroups ermöglicht. Hat eine MeasureGroup mehrere Datumsangaben, werden die weiteren als Role Playing Dimensions abgebildet. Dies sind insgesamt vier:
Um dem Beispiel von Microsoft zu folgen, wird die PurchaseFinalized-Dimension als eine Unlinked Cube Dimension behandelt.
Ein Blick lohnt sich auf einen Ausschnitt der verkürzten Darstellung der Level Source Columns:
- Die Hilfsdimensionen sind per Standard befüllt.
- In der Quelle kann unter Verwendung des Datenbanknamens (hier abgekürzt als WWIDW) und des Schemas (Dimension) auf die Tabelle einer anderen Datenbank verwiesen werden. Dadurch kann das Modell in der Datenbank WideWorldImportersDW_DMETL aufgebaut werden, während die Quelldatenbank unberührt bleibt.
- Für die Ebene Continent ist die ID der Bezeichner, dadurch braucht die Name-Spalte nicht ausgefüllt werden. Zudem ist für diese Ebene kein Long Name Attribute vorhanden.
- Für Felder mit Leerzeichen ist es notwendig, eckige Klammern zu setzen.
- Die Ebene CityKey ist nicht sichtbar. Die MeasureGroups verbinden sich aber dennoch über diese Ebene.
- Die Dimension PurchaseFinalized befüllt sich aus Werten der Faktentabelle, keiner Dimensionstabelle. Zudem kennt sie nur zwei Werte, die in lesbare Texte umgewandelt werden.
MeasureGroups
Fünf MeasureGroups existieren im MS-WWI-OLAP-Modell. Dabei zeigt sich jedoch, dass die Transaktionen zwischen Rechnungen an den Kunden und die Lieferanten unterschieden werden können und unterschiedliche Dimensionalitäten aufweisen. Innerhalb des Kunden hängt die betriebswirtschaftliche Bedeutung vom Transaktionstyp ab und ist entweder positiv oder negativ. Manche Kennzahlen existieren auch nur für bestimmte Transaktionstypen. Für die Lieferantentransaktionen gilt dasselbe, wobei diese Zahlen kumuliert vorliegen. Insgesamt bietet es sich an, aus der Transaktion-Dimension des MS-WWI-OLAP-Modells vier eigenständige MeasureGroups zu erstellen: Transaction Customer Invoice (TransCustInv), Transaction Customer Payment (TransCustPay), Transaction Supplier Invoice (TransSuppInv) und Transaction Supplier Payment (TransSuppPay).
- Wie zuvor bei den Dimensionen, kann auch hier als Quelle eine Tabelle einer anderen Datenbank angegeben werden.
- Sale und Order werden darüber hinaus zweimal angelegt: einmal für die Ist- und einmal für die Plan-Werte.
Der letzte Spiegelstrich verdeutlicht sich, wenn man den folgenden Ausschnitt der Kennzahlen-Quellen betrachtet:
- Die Anzahl der Zeilen bleibt dieselbe, doch wird die Spalte der relationalen Tabelle mit 1.10 multipliziert, um so einen Planwert zu erhalten.
- Dies bringt auch den Vorteil mit sich, dass keine neue relationale Tabelle erstellt oder eine vorhandene angepasst werden muss.
Dimensionsverwendung
Den Abschluss der Modellierung in DeltaMaster ETL findet in diesem Fall wie zuvor mit der Dimensionsverwendung statt. Als Beispiel dient hier wieder ein Ausschnitt die MeasureGroup Sale.
- Sowohl Sale wie auch Order verwenden den Salesperson Key, um mit der Dimension Employee verbunden zu werden.
- Die Role-Playing-Dimension DeliveryDate wird angesprochen. Da NULL-Werte vorhanden sind, wird in diesen Fällen der Invoice Date Key
- Die Planzahlen sind die Vorjahreswerte für das kommende Jahr. In diesem Fall kann somit das Datum um ein Jahr nach vorne geschoben werden (DATEADD).
- Die Wertart der Planzahlen ist die 2. Periodenansicht und Kumulation bleiben 1.
- Auch bei dem DeliveryDate wird das Datum um ein Jahr erhöht.
DeltaMaster-Berichte zu WWI
Übersichtsberichte
Unter Verwendung der Magic Buttons, der Auswahl von aussagekräftigen Kennzahlen wie auch der Erstellung von berechneten Kennzahlen kann in wenigen Minuten ein Übersichtsbericht mit den Vorjahresabweichungen erstellt werden. Der Bericht ist auf Dezember 2015 gefiltert.
In diesem Bericht ist Folgendes zu sehen:
- Im Dezember 2015 betrug das gesamte Bestellvolumen 5,3 Mio.$. Davon wurden 5,1 Mio.$ fakturiert und 5,0 Mio.$ durch die Kunden bezahlt.
- Die Steuern auf die Kundenrechnungen betrugen insgesamt 669 Tsd.$. Ohne Steuern liegt das Volumen bei 4,5 Mio.$.
- Der Profit beträgt 2,2 Mio.$. Die Total Costs sind errechnet und betragen ebenso 2,2 Mio.$. Der relative Profit ist ebenso aus dem Verhältnis zum Volumen ohne Steuern errechnet und beträgt 50%.
- Die kumulierte Abweichung zum Vorjahr beträgt +9% und ist die Wetterzelle des Berichts, die auch die Kachel der Anwendung einfärbt.
Mit den Magic Buttons lässt sich komfortabel auch die Planabweichung erstellen. Der Vollständigkeit wegen ist sie auch noch aufgeführt. Da die Planzahlen +10% zum Vorjahr sind, muss die Abweichung des kumulierten Sales Profit -1% betragen.
Begibt man sich in den Präsentationsmodus und öffnet den Hyperbrowser, bekommt man einen Überblick über das Datenmodell.
Die Ist-Daten reichen bis zum Mai 2016.
Beispiel-Berichte zu Fachbereichen
Die weiteren Berichte gewähren einen tieferen Einblick in die Daten.
Mit der Kachelnavigation können bis zu drei Kennzahlen auf einer Kachel platziert werden. Eine Möglichkeit ist hier, die absolute und relative Abweichung zum Vorjahr anzuzeigen. Die Kachelfärbung findet entweder durch den Verlauf der letzten zwölf Monate (Wetterfärbung) oder im Vergleich zu den anderen Kacheln (Business Colors) statt.
Im Folgenden sind die Einkaufskennzahlen gemäß ihrem Verlauf der letzten zwölf Monate eingefärbt und sind allesamt tief blau.
Für die OrderedOuters stimmen die Zahlen exakt mit den ReceivedOuters überein. Im Folgenden sind die OrderedOuters und die Anzahl der Datensätze nach den Lieferanten aufgeteilt:
Offenbar hat die Anzahl der Bestellungen nur für einen Lieferanten zugenommen.
Fokussiert man sich auf die Verkäufe, zeigen Small Multiples der Buying Groups über das Standardschema, dass die Daten offenbar für jede Buying Group mit einem anderen Faktor multipliziert wurden.
Zu guter Letzt kann ein Ranking der Mitarbeiter über das Auftragsvolumen zeigen, dass doch eine gewisse Bewegung in den Daten ist:
Fazit
Dieser Artikel gewährt einen Einblick in das multidimensionale Datenmodell der Wide World Importers. Durch die Abbildung verschiedener Themen (MeasureGroups) können wichtige Funktionsweisen wie der Vergleich von Kennzahlen aus diesen unterschiedlichen Themen demonstriert werden. Die vielen Dimensionen öffnen viele Analysemöglichkeiten. Die Modellierung von Microsoft wurde zum großen Teil für das durch DeltaMaster ETL erzeugte Modell übernommen, wobei Komfortfunktionen wie die integrierten Hilfsdimensionen genutzt werden, um so auch ein aufwendigeres Modellieren von Kennzahlen zu reduzieren. Die hier dargestellten Ausschnitte aus den Berichten regen hoffentlich die Inspiration von Datenmodellierer und Berichtsersteller an.
Der Autor spricht die Empfehlung aus, sich zu Übungszwecken mit dem WWI-Modell auseinanderzusetzen.
Ausblick
Weitere Workflows von Wide World Importers
Artikel: Wide World Importers sample databases for Microsoft SQL
Neben den vorgestellten Themen existieren noch weitere Workflows in dem vollständigen WWI-Modell:
- WWI erstellt Gutschriften (negative Rechnungen).
- WWI führt Inventuren durch.
- Verderbliche Ware wird in Kühlräumen gelagert, deren Sensordaten Auskunft über die Temperatur geben und überwacht werden.
- Fahrzeuge transportieren Artikel und sind ebenso mit Sensoren ausgestattet, die z. B. die Position des Fahrzeugs verfolgen.
Das Geschäftsjahr startet zum ersten September des Kalenderjahres.
Technische Komponenten von Wide World Importers
Artikel: WideWorldImporters Sample Database for SQL Server and Azure SQL Database
Zur Demo-Datenbank WWI gibt es weitere Bestandteile, darunter auch ein SQL-Server-Integration-Services (SSIS)-Paket, um die Daten des Quellsystems, das relationale WWI Enterprise Resource Planning System (ERP), in eine für das multidimensionale Modell passende weitere relationale Datenbank des Data Warehouse zu überführen. Dieses SSIS-Paket verwendet Prozeduren des WWI-ERPs, um die relevanten Datensätze zu ermitteln, in das Data Warehouse (DW) in Staging-Tabellen zu übertragen und anschließend unter Aufruf weiterer Prozeduren in die Fakten- und Dimensionstabellen zu kopieren.
Neben dieser weiteren Komponente für den Aufbau der OLAP-DB gibt es unter anderem noch die folgenden, um einen Teil des Funktionsumfangs des SQL Server 2016 zu demonstrieren:
- Sample Scripts: Beispiele für SQL-Server-Funktionen
- Workload Drivers: Simulationen für die WWI-Datenbank
Potenzielle Erweiterungen des OLAP-Modells
Das MS-WWI-OLAP-Modell deckt nur einen Teil der in der relationalen Datenbank des Data Warehouse vorhandenen Tabellen ab. So gibt es noch die Faktentabelle Movement, die im MS-WWI-OLAP-Modell nicht in der Data Source View angebunden ist. Die folgende Tabelle zeigt die Anzahl von Zeilen jeder Tabelle sowie bei den Dimensions-Tabellen die Anzahl der einzigartigen Elemente an Hand des WWI-Schlüssels. Dies unterscheidet sich, da die Dimensionen vom Typ Slowly-Changing sind und so Änderungen an den Attributen (z. B. bei Payment Method eine Umbenennung von „Credit Card“ zu „Credit-Card“) neue Zeilen generieren, die Elemente aber dieselben bleiben. Schlussendlich sind nicht alle Elemente in den Fakten vorhanden, insbesondere dann, wenn Stammdaten z. B. von externen Quellen kopiert werden, wie es womöglich mit den geographischen Daten der Fall ist.
Die Dimension City wiederum enthält die Kennzahl Latest Recorded Population und inspiriert zur Modellierung der Dimension auch als Faktentabelle, um z. B. Umsätze je Einwohnerzahl ermitteln zu können. Darüber hinaus verfügt jede Stadt über eine Location, die den geography-Datentyp aufweist und räumliche Ergebnisse ermöglicht.
Tabelle 9 zeigt die Tabellen der relationalen Datenbank des WWI-ERP wie auch das WWI-DW. Ein Blick auf die relationale Datenbank des WWI-ERP zeigt, dass weitere potenzielle Themen bestehen: So gibt es noch Delivery Methods, Special Deals, Cold Room Temperatures, Package Types, Stock Groups und Vehicle Temperatures. Es ist nicht unwahrscheinlich, dass bei einer näheren Betrachtung der einzelnen Tabellen noch weitere relevante Daten für das Analysemodell ausgemacht werden können.
Tabelle 10 zeigt eine Dimension-Measure-Matrix, die weitere potenzielle Dimensionen und Kennzahlen-Gruppen enthält. Die Darstellung weicht dabei in zweierlei Hinsicht vom Standard ab: Zur Reduktion der Komplexität wird eine Verbindung nur grundsätzlich gesetzt und nicht die genaue Ebene benannt, auch wenn diese Unterscheidung relevant ist. Unterschieden wird dabei lediglich noch, ob die Verbindung einer MeasureGroup zu einer Dimension direkt oder mit Hilfe einer Bridge-MeasureGroup geschieht, wie es für die Stock Group der Fall ist. Zum anderen sind die Role Playing Dimensions eingerückt, nicht die Dimensionsebenen.
Abschließend seien noch Fragen formuliert, die durch weitere Analysen beantwortet werden könnten:
- Wie viele Aufträge werden zu Rechnungen?
- Werden alle Rechnungen bezahlt?
- Besteht ein Zahlungsverzug von Kunden?
- Gibt es geographische Auffälligkeiten?