08_Pruefungen der Regeln 1_15 und Zusammenfassungen

Seite 1 von 32
Verifizieren der Geschäftsregeln (Schritt 4.1)
Die Abarbeitung der bekannten Geschäftsregeln kann jetzt auf der Basis der bereits vollzogenen
Erfahrungen mit dem Datenmodell und dem Datenbestand erfolgen. Es werden überwiegend Data
Rules bzw. View-Definitionen sein, mit denen man die Regeln überprüft. Die Ergebnisse aller
Analysen sind am Ende der Regelüberprüfung in der Template-Liste T2.50 zusammengefasst.
Regel R1
R1: Produkte_Stamm: Bestand muss immer größer sein als Min_Bestand
Für die Regel wird eine Data Rule erzeugt und angewendet. Die Regel sieht wie folgt aus:
Die Regel R1 im Expression-Editor der Data Rule Definition
Die Zuordnung der Spalten der Tabelle PRODUKTE_STAMM zu den Parametern der Data Rule:
Die Regel-Parameter
Das Ergebnis zeigt, dass die Regel nur zu 20,55 % befolgt wurde.
Auswertung der Data Rule zur Überprüfung der Geschäftsregel 1. Nur etwa 20 % der Sätze erfüllen
diese Regel.
Seite 2 von 32
Regel R2
R2:
Wenn Artikelnr = NULL dann Produktnummer NOT NULL und (Status = 2 oder Status =3)
oder
Wenn Artikelnr NOT NULL dann Produktnummer = NULL und Status = 1
Auch hier wird wieder eine Data Rule definiert:
Data Rule-Definition Regel R2
Das Ergebnis für die Regel R2
Die Regel ist zu 84,55 % erfüllt. Das bedeutet bei ca. 15% aller verkauften Objekte der Service GmbH
gibt es eine Grauzone, in der nicht gemessen werden kann, ob es sich bei den Verkäufen um Artikel,
Dienstleistungen oder Finanzangebote handelt.
Regel R3
R3: Wenn Kundenkarte = 1 dann Status = ‚P‘
Die Data Rule hierzu:
Die Regel R3
Seite 3 von 32
Das Beispiel zeigt, dass die Regel „komplett“ definiert werden muss. „Komplett“ bedeutet hier, dass
auch die Gegenaussage miteinbezogen werden muss. Betrachtet man sich das Ergebnis, so erfüllen
nur 19,19 % diese Bedingung, es wird gleichzeitig eine Aussage darüber getroffen, warum die übrigen
diese Bedingung nicht erfüllen. Wenn die Bedingung nicht erfüllt ist, dann müsste in dem Feld
Kundenkarte eine 1 stehen und in dem Feld Status ein „F“. Alles andere wäre gültig.
Das Ergebnis von R3
Die Regel ist nur zu 19,19 % erfüllt.
Der Grund für diese hohe Zahl an Defekten ist bereits bei der Analyse zur 1. Normalform sichtbar
geworden: Das Feld Status wird sehr stark noch für andere Zwecke verwenden, nämlich zur
Darstellung der Qualität der Kundenbeziehung. Damit kann die Anforderung des Marketing nach der
Messbarkeit des Erfolgs der Kundenkarte nicht erfüllt werden.
Regel R4
R4:
Wenn Zahlungsziel in der Vergangenheit überschritten wurde, dann max. 1000€ sonst 2000€.
Bei Jahresumsatz > 10000 € / Jahr Kreditlimit 4000 €
Die Abarbeitung dieser Regel ist recht komplex und wir werden sie aufgrund mehrerer Umstände auch
nicht lösen können.
Zur Lösung diese Regel könnte man eine View-Definition verwenden. Aber weil sie so komplex ist,
sollte man die Lösung in mehrere Teilschritte gliedern. Dafür bietet sich dann wieder ein klassisches
Mapping des Warehouse Builders an.
1. Zunächst einmal muss festgestellt werden, ob ein Kunde sein Zahlungsziel bereits einmal
überschritten hatte. Um die Prüfung überschaubar zu halten würde man das Ergebnis sogar zunächst
in einer temporären Tabelle ablegen (bei einer View-Definition in einem Zwischen-Set als Sub-Query
formuliert). Um das herauszufinden muss man die Bestelldaten aller Käufe mit den
Zahlungseingängen abgleichen und feststellen, ob die Frist, die für den Kunden gilt, einmal
überschritten worden ist. Diese Frist hängt natürlich, wie wir bereits wissen, von dem Feld Status (P
oder F) und dem Besitz einer Kundenkarte ab.
2. In einem zweiten Set hält man dann fest, wie hoch die säumigen Zahlungen des Kunden sind, und
ob der Kunde sich noch innerhalb der laufenden Zahlungsfrist befindet.
3. In dem letzten Schritt führt man beide Sets zusammen.
Seite 4 von 32
Die vorherigen Analysen haben jedoch bereits ergeben, dass wichtige Voraussetzungen nicht erfüllt
sind:
- Das Feld für die Kundenkarte nicht immer gepflegt (nur zu ca. 20%)
- Das Statusfeld in der Kundentabelle entspricht nicht der 1. Normalform
- Die Zahlungen sind nicht auf Positionslevel heruntergebrochen. Damit kann gar nicht vollständig
geprüft werden, wann ein Kunde überhaupt gezahlt hat und ob er bereits säumig gewesen ist.
Resümee: Die Regel ist nicht prüfbar.
Regel R5
R5: Firmenrabatt darf nur gefüllt sein, wenn Status = ‚F‘
Die wird wieder über eine Data Rule geprüft:
Die formulierte Data Rule
Das Ergebnis von Regel R5
Die Regel ist nur zu 59.30 % erfüllt. Zu berücksichtigen ist, dass das Feld
Normalform entspricht.
Status nicht der 1.
Regel R6
R6:
Wenn Kundenkarte = 1 und Status = ‚P’ dann Zahlungsziel = Lieferdatum + 20
Wenn Kundenkarte = 0 und Status = ‚P’ dann Zahlungsziel = Lieferdatum + 10
Wenn Status = ‚F’ dann Zahlungsziel = Lieferdatum + 30
Die Regel birgt ähnlich wie die Regel 4 eine besondere Schwierigkeit. Der zu prüfende Gegenstand ist
an keiner Stelle in den Daten nieder gelegt, sondern ist von Zuständen in den Bewegungsdaten
abhängig. Die Tatsache, ob jemand sein Zahlungsziel eingehalten hat oder nicht, hängt von dem
Zeitpunkt seiner Bezahlung ab. Es gibt lediglich eine allgemeine Regel, die angewendet werden kann.
das Zahlenmaterial, das zu prüfen ist muss berechnet werden.
Auch das ist ein Fall, für den man die Integration des Profiling in die Datenbank bzw. in OWB nutzen
kann. Es wird zunächst eine View-Definition erzeugt. Diese wirkt wie eine Entscheidungstabelle, auf
die dann eine Data Rule angesetzt werden kann.
Seite 5 von 32
create view VW_Regel_6 as
select B.bestellnr Bestnr,
sum(B.bestell_total) Rechnung ,
NVL(sum(z.bestell_total),0) zahlung,
(sum(B.bestell_total) - NVL(sum(z.bestell_total),0)) offen,
NVL(max(z.Zahltag -z.Bestelldatum-15),999) Zahlzeit,
b.kundencode,
ks.status Status,
KS.Kundenkarte Karte
from bestellung B,
Zahlung z,
Kunden_Stamm KS
where b.kundencode= z.kundencode (+) and
b.Kundencode = KS.kundennr (+)
group by (B.bestellnr,B.kundencode,ks.status,KS.Kundenkarte)
order by B.bestellnr
Wenn die View-Definition ausgeführt wird, erscheint die folgende Relation:
Ergebnis der View-Definition
Die Regel, die jetzt auf diese Definition angewendet werden kann lautet:
View Definition
Ergebnis von Rule_6
Das Zahlungsziel ist von nur 10,64 % der Kunden eingehalten worden.
Seite 6 von 32
Dieses Ergebnis müsste noch weiter daraufhin überprüft werden, ob es sich ändert, wenn das
fehlerhafte Status-Feld korrigiert wird? Grundsätzlich gelten hier die Bedenken die bereits zu Regel 4
genannt wurden.
Regel R7
R7: Bestellung / Best_Position: Die einzelnen Positionswerte müssen aufaddiert den gleichen Wert
ergeben wie der komplette Bestellwert
Diese Regel kann in zwei Varianten überprüft werden.
Die erste arbeitet wieder mit Hilfe einer View-Definition, deren Ergebnis allerdings mit anderen
Analyse-Techniken im Profiliner ausgewertet werden kann, z. B. mit Aggregation oder Domain.
Die View-Definition:
Create view VW_REGEL_7 as
Select
case B.bestell_total - sum(p.gesamt_pos_preis)
when 0 then 'Rule_7_OK'
else 'Rule_7_Falsch'
end rule_7,
B.BESTELLNR bestellnr,
B.bestell_total Total,
sum(p.gesamt_pos_preis) sum_Pos
from Bestellung B,
Best_Position P
where
B.BESTELLNR = P.BESTELLNR
group by B.bestellnr,B.bestell_total
Das Ergebnis der View-Definition:
Ergebnis der View-Definition
Dieses Zwischenergebnis kann man jetzt leicht auswerten, indem man die View-Definition als solche
in z. B. in der Aggregation anzeigt:
Seite 7 von 32
Ergebnis der Regel 7 . Bei 1,8 % stimmt die Summe der Positionswerte nicht mit dem Bestell_TotalWert in der Parent-Tabelle überein
Die zweite Variante kommt ohne eine View-Definition aus. Hier definierte man eine Data Rule und
verwendet eine SQL-Abfrage innerhalb der Regel. Für jeden „THIS-Wert“ innerhalb der Regeldefinition
wird eine SQL-Abfrage abgesetzt. Die Data Rule wird später auf die BESTELLUNG-Tabelle angesetzt
und dort werden für jede Bestellnummer die abhängigen Sätze der BEST_POSITION über die SQLAbfrage ermittelt.
Data Rule mit eingebundener SQL-Query
Seite 8 von 32
Ergebnis der Data Rule mit eingebetteter SQL-Abfrage
Das Ergebnis dieser Variante ist natürlich das gleiche wie zuvor. Diese Lösung hat allerdings den
Reiz, dass sie vollständig mit Bordmitteln des Profilers auskommt und sie zeigt die Mächtigkeit der
Data Rule-Technik, die nur durch den Datenbankkontext möglich ist.
Regel R8
R8: Orphans: Bestellpositionen müssen einer Bestellung zugeordnet werden können.
Hier hilft die Referential-Analyse, denn sie zeigt in der Spalte „Orphans“ den Wert für die Anzahl der
„Waisenkinder“, in diesem Fall 0.
Zu allen Bestellungen gibt es abhängige Bestellpositionssätze und es gibt keine einzelnen
Positionssätze als sog. „Waisen“ (Orphans)
Die manuelle Kontroll-Nativ-SQL-Abfrage:
select Anz_Pos_Pro_Best, count(Anz_Pos_Pro_Best) from
(select count(*) Anz_Pos_Pro_Best from
(Select B.BESTELLNR A,P.Posnummer B from Bestellung B,Best_Position P
where
B.BESTELLNR = P.BESTELLNR group by B.bestellnr,P.Posnummer)
group by A)
group by Anz_Pos_Pro_Best order by Anz_Pos_Pro_Best
Regel R9
R9: Childless Parents: Bestellungen müssen mindestens eine Position haben.
Seite 9 von 32
Diese Regel kann leicht über eine Referential-Analyse überprüft werden, bei der die Bestelltabelle als
„Lokale“ Tabelle gewählt wird und die abhängige die Remote-Tabelle darstellt. Sie ist zu 100% erfüllt.
Regel R10
R10: Bestellung (Wert, Produkte) = Lieferung (Wert, Produkte)
Diese Regel betrifft 2 Tabellen. Zunächst kann festgestellt werden, dass sich beide Tabellen auf der
selben Granularitäts-Ebene befinden, also beide auf dem Level von Bestellungen bzw.
Bestellnummern.
Es gilt BESTELLUNG.Bestellnr = LIEFERUNG.Bestellnr.
Auch diese Regel kann man wieder mit einer Data Rule und einer eingebetteten SQL-Abfrage
überprüfen. Die Regel wird so formuliert, dass sie an eine Tabelle angehängt werden kann und die
SQL-Subquery auf die andere Tabelle zielt.
Data Rule für Regel 10
Das Ergebnis besagt, dass nur für
aufzeigen.
45.45 % der Bestellungen die Lieferungen analoge Werte
Regel R11
R11: Einkaufsmenge = Absatzmenge + Lagerbestand
Diese Regel kann nicht überprüft werden, weil es in dem Datenmaterial keine Informationen über die
Einkaufsaktivitäten gibt. Es wurde bereits durch die Vollständigkeitsanalyse festgestellt, dass Daten zu
dem Geschäftsobjekt „Beauftragung / Order“ fehlen.
Regel R12
R12: Wenn Bestell_Position für Produkt mit Status 2 oder 3, dann 1:1 Beziehung zwischen Bestellung
und Bestell_Position.
Dienstleistungen dürfen also nur einzeln als Position auftreten.
Dieser Punkt ist schwieriger zu ermitteln, denn es sind 3 Aspekte zu prüfen:
- eine Feldabhängigkeit zwischen zwei Tabellen (PK/FK-Prüfung)
- eine bestimmte Kardinalität (es darf nur einen abhängigen Satz geben),
- eine bestimmte Kardinalität ist nur in definierten Fällen richtig (bei Status = 2 oder 3, das sind
Dienstleistungen).
Die Komplexität sollte man mit den zusätzlichen Datenbank-Mitteln innerhalb des OWB minimieren.
Zunächst kann man über eine View-Definition einen Zusammenhang zwischen der Anzahl von
Positionssätzen zu den jeweiligen Bestellungen herstellen.
-
Seite 10 von
32
create view Best_Anz_Pos as
select Bestellnummer , count(B) Anzahl_Pos from
(Select B.BESTELLNR Bestellnummer ,P.Posnummer B
from Bestellung B,Best_Position P where
B.BESTELLNR = P.BESTELLNR)
Group by Bestellnummer;
Diese View kann man selbst wieder profilen.
Eine Domain-Analyse zu der neu erstellten View-Definition zeigt bereits, dass es in dem Datenbestand
nur wenige Bestellungen mit nur einer Position gibt. D. h. entweder sind kaum Dienstleistungen
verkauft worden, oder die Regel wurde nicht eingehalten.
Die „signifikant“ geringe Häufigkeit von nur einer Position lässt einen Fehler vermuten, denn es
kann aufgrund der Erwartung der Fachmitarbeiter nicht sein, dass es so wenige Dienstleistungen im
Vertrieb gegeben hat. Weitere Nachforschungen müssen her.
Ergebnis einer Domain-Analyse auf die View-Definition. Häufigkeit der Bestell_Positionen pro
Bestellung. Es gibt nur 4 Bestellungen mit einer Position. Laut Regel müssten dies die
Dienstleistungen sein. Dieser Wert ist viel zu gering. Hier kann ein Fehler vermutet werden.
Eine alternative Darstellung zeigt den Zustand noch deutlicher:
Die Verteilung der Häufigkeit von Positionssätzen zu Bestellungen. Es fehlt der Wert 0 und 1weil ihr
Vorkommen zu gering ist. Hier wurde die graphische Auswertung alternativ zur Tabellendarstellung
gewählt.
Um auch die letzte offene Frage zu klären, wird die View-Definition um eine weitere Spalte ergänzt.
Seite 11 von
32
Verkaufte Dienstleistungen sind an dem Status-Feld in der Child-Tabelle BEST_POSITION zu
erkennen. Status 2 und 3 bedeutet Dienstleistung. Das ist zusätzlich abzufragen und in einer weiteren
Spalte in der View-Definition zu vermerken.
Die erweiterte View-Definition:
create view Best_Anz_Pos_Status as
select Bestellnummer ,
count(B) Anzahl_Pos,
sum(Dienstleistung) DL
from
(Select
B.BESTELLNR Bestellnummer ,
P.Posnummer B,
(case P.status
when 2 then 1
when 3 then 1
else 0
end)
Dienstleistung
from Bestellung B,Best_Position P
where
B.BESTELLNR = P.BESTELLNR )
Group by Bestellnummer order by Bestellnummer ;
Zum Verständnis der View-Definition:
In der View-Definition wurde auf der Positions-Ebene das Status-Feld ausgewertet und das Flag „1“
gesetzt, wenn es sich um eine Dienstleistung handelt (also bei Status = 2 oder 3 -> CASEAnweisung). Das Flag wird auf der Gruppen-Ebene addiert und darf in der Summe nie höher als 1
ergeben, wenn die Regel „Pro Bestellung nur 1 Dienstleistung und sonst nichts anderes“ erfüllt sein
soll.
Diese neue View-Definition kann zwar ebenfalls mit dem Profiling-Verfahren gemessen werden, aber
die SUM()-Operation in der View-Definition ergibt noch falsche Werte. Sie ergibt nur in der
gemeinsamen Betrachtung mit der Anzahl der Positionen Sinn. Wir müssen also eine
Spaltenübergreifenden Bewertung durchführen, was wir am leichtesten über ein Rule-Objekt im
Warehouse Builder erreichen. Mit den Rules kann man bequem Bedingungen mit AND / OR
verknüpfen.
Die Regel (Rule_Objekt) hat die Form:
Rule zur Prüfung dass bei Dienstleistungsverkäufen nur eine Bestell_Position pro Bestellung
aufgeführt werden darf.
Die Anwendung des Rule-Objektes zeigt, dass nur 0,4 % der Sätze die Bedingung erfüllen, obwohl
es wesentlich mehr verkaufte Dienstleistungen geben müsste.
Seite 12 von
32
Nur 0,4 % aller Bestellungen erfüllen die Regel „nur 1 Position im Fall von Status = 2 oder 3“
Die Verteilung der Häufigkeit der verkauften Diensstleistungen wenn nach Status = 2 und Status = 3
(Domain-Analyse)
Damit ist die Regel 12 nur zu 0,4 Prozent erfüllt.
Regel R13
R13: Verkaufspreis – Rabatt > Einkaufspreis wenn Status (Kunde) = ‚P’ und
Verkaufspreis – Kundendiscount > Einkaufspreis wenn Status = ‚F’
Diese Regel kann nicht überprüft werden, da keine Einkaufsdaten vorliegen.
Regel R14
R14: Eine Bestellung muss immer eindeutig einem Kunden zuzuordnen sein.
Diese Regel ist über die Referential-Analyse überprüfbar und zu 100% richtig.
Die Überprüfung der Regel 14 über die Referential Analyse
Regel R15
R15:
Seite 13 von
32
Wenn Artikelnr in Bestell_Pos not NULL und Status (Kunde) = ‚P’ dann Status (Produkte_Stamm = 1
oder 3.
Wenn Produktenummer in Bestell_Pos not Null und Status (Kunde) = ‚F’ dann Status
(Produkte_Stamm) = 2
Wenn Produktenummer in Bestell_Pos not Null und (Produkte_Stamm) = 3 dann Status (Kunde) = ‚F’
oder ‚P’
Diese Regel will prüfen, ob die verschiedenen Produktgattungen auch wirklich für die entsprechenden
Zielgruppen verkauft wurden.
Die Lösung gelingt auch hier wieder über eine View-Definition.
Die View Definition
Create VIEW VW_REGEL_15 as
Select
substr(p.artikelnummer,1,10) Artikelnummer,
substr(p.produktnr,1,15) Produktnummer,
substr(p.status,1,5) Produkt_Status,
substr(k.status,1,5) Kunden_Status
from
Bestellung B,
Best_Position P,
kunden_Stamm k
where
B.BESTELLNR = P.BESTELLNR and
B.kundencode = K.kundennr
Das Ablaufergebnis der Viewdefinition:
Ergebnis der View-Definition VW_Regel_15
Auf diese View-Definition wird die folgende Data Rule angewendet:
Data Rule zum Prüfen der Verwendung von Artikelnummer und Produktenummer
Seite 14 von
32
Die Auswertung zur Regel 15. Nur 21 % kommen mit dem verwirrenden Vertauschspiel von
Artikelnummer und Produktnummer zurecht.
Nur 21,47 % der Verkaufsdaten erfüllen die Regel 15. Auch hier sollte wieder das fehlerhafte
Statusfeld in der Kundentabelle berücksichtigt werden.
Prüfungen der Geschäftsregeln
15/32
Abarbeitung der benannten Schwachstellen
(Schritt 4.2)
Bildung von Problem-Komplexen und Priorisierung (Schritt 4.2.2)
T1-7-Bekannte Probleme und Schwachstellen
Proble
m
benann
t von
Vertrieb
Marketi
ng
Buchhal
tung
Controlli
ng
Beschreibung
Problem-Komplex
ProblemKomplexe
Priorität
keine Zahlen über „sich
lohnende Produkte“.
keine oder falsche
artikelgruppenbezogenen
Berichte
Korrekte
Artikelgruppenberichte sind
nur mühsam erstellbar
Auswertungen über Sparten
sind nicht möglich
zu wenig Daten über Kunden
trotz Kundenkarte
Kundenkarte ist sinnlos.
Verkaufszahlen und
Kundenkarte ohne
Zusammenhang
Umsatz / Produkt
2
Umsatz
/Artikel_Gruppe
1
Gewährung von Rabatten und
Discounts ist nicht
nachvollziehbar
Warum werden offene
Rechnungen nicht gezahlt
Lieferungen können nicht
nachverfolgt werden
Spediteursrechnungen sind
nicht nachvollziehbar
Retouren können nicht
nachvollzogen werden
Zusammenhänge von
Bestellung, Zahlung und
Lieferung sind nicht klar
Ganze Produktmengen
verschwinden einfach
Es fehlt eine einfache
Auswertmöglichkeit
Einzelne Produkte liefern sehr
hohe Verluste, obwohl sie zu
den Rennern gehören
Auswertungen über Sparten
sind nicht möglich
mühsam erstellte Listen zu
Einkaufs- und Verkaufspreisen
auf Produktebene
Zuordnung von Produkten zu
Lieferanten ist nicht möglich
Kunde / Discount
LösungsStrategie
Umsatz
/Artikel_Gruppe
Umsatz / Sparte
Kunde /
Kundenkarte
Gewinn / Kunde
Rechnungen +
Zahlungen
Lieferungen
5
4
Spediteursrechnun
gen / Detaillierung
Lieferungen /
Retouren
Lieferung,
Rechnungen,
Zahlungen
Lagerlogistik
3
Auswertung zu
Verkäufen und
Einkäufen
Auswertung
Einkaufsdaten und
Produkte
°°°°°°°°(wegkopierte Problemkomplexe)
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
16/32
Problemkomplex 1 – Fehlerhafte Auswertungen aufgrund fehlerhafter ProduktHierarchie °°°° + alter Komplex 2
Das Orphans-Problem
Bereits bei der Analyse von Hierarchien (Phase 3) wurden Orphans festgestellt. Es gab Produkte, die nicht auf der
Artikelgruppenebene vertreten sind und auch Artikelgruppen, die nicht auf der Ebene der Artikelsparten zu sehen sind.
Das führt automatisch zu falschen Auswerteergebnissen. Das wurde durch die Referential Analyse festgestellt.
Eine Lösung besteht natürlich in der Ergänzung der jeweiligen Parent-Tabellen.
Zu Testzwecken kann man sich eine View-Definition erstellen, mit der man die korrekte Situation simulieren kann.
Diese Arbeit mit SQL hat lediglich den Zweck herauszufinden, wie groß die nicht erkannten Werte in Auswertungen
durch fehlerhafte Daten sind. Das Verfahren wird hier einmal durchgespielt, um den möglichen Weg zu zeigen. Die
Entwicklung der SQL-Kommandos ist natürlich nur möglich, weil durch die vorher gemachten Analysen die Struktur
der Defekte bekannt ist. Ohne die vorherigen Analysen zu Kardinalitäten und Orphans wären die komplexen SQLs
sicher nicht denkbar.
Eine Fehlerbehebung in Form von SQL sähe etwa so aus:
Create View VW_Sparte_Ersatz as
Select Artikelspartennr,ARTIKELSPARTENNAME from artikelsparte
union
select Artikelspartennr,'--> Sparte noch nicht erfasst <--' from artikel_gruppe
where Artikelspartennr not in (select Artikelspartennr from artikelsparte);
Das Ergebnis liefert z. B.
ARTIKELSPARTENNR ARTIKELSPARTENNAME
---------------- ------------------------------------1 Nonfood
2 Food
3 Dienstleistung
4 --> Sparte noch nicht als erfasst <--
Die gleiche Ersatz-View-Definition muss auch auf der Artikelgruppenebene erfolgen:
Create view vw_Gruppe_Ersatz as
Select
substr(ARTIKELGRUPPENNR,1,14) Artikelgruppe,
substr(ARTIKELGRUPPENNAME,1,20) Gruppenname,
ARTIKELSPARTENNR
from artikel_gruppe
union
select substr(ARTIKELGRUPPENNR,1,14) ,
'--> Gruppe nicht erfasst <--',
0
from Produkte_Stamm
where
ARTIKELGRUPPENNR not in
(select ARTIKELGRUPPENNR from artikel_gruppe);
Ersatz-View-Definition für die Gruppenebene
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
17/32
Man erhält eine Auswertung wir diese:
ARTIKELGRUPPE GRUPPENNAME
ARTIKELSPARTENNR
-------------- ---------------------------- ---------------1
Haushaltswaren
1
10
Sonst_Finanzdienstle
3
100
--> Gruppe nicht erfasst <-0
11
Vermietungen
4
2
Heimwerker
1
3
Gartenbedarf
1
4
KFZ-Zubehoer
1
5
Computerteile
1
6
Elektroartikel
1
7
Vermittlung_Darlehen
3
8
Vermittlung_Handwerk
3
9
Vermittlung_Sonst_Di
3
Durch diese neue Ersatz-View-Definition ist jetzt eine neue Sparte entstanden, die natürlich auch auf der
Spartenebene sichtbar sein muss. Also wird die Ersatz-View-Definition für die Sparten nocheinmal verändert:
Create View VW_Sparte_Ersatz as
Select Artikelspartennr,
ARTIKELSPARTENNAME
from artikelsparte
union
select Artikelspartennr,
'--> Sparte noch nicht erfasst <--'
from vw_Gruppe_Ersatz
where Artikelspartennr not in
(select Artikelspartennr from artikelsparte)
Modifizierte Ersatz-View-Definition für die Spartenebene
Jetzt erhält man ein korrektes Bild aller Artikelgruppen und Sparten, wie sie in der Tabelle PRODUKTE_STAMM
genutzt werden kann:
ARTIKELSPARTENNR ARTIKELSPARTENNAME
---------------- --------------------------------0 --> Sparte noch nicht erfasst <-1 Nonfood
2 Food
3 Dienstleistung
4 --> Sparte noch nicht erfasst <--
Auswertungen können jetzt über diese Ersatz-View-Definitionen stattfinden. Die Auswertung vor der Korrektur hatte
folgendes Ergebnis:
select
sum(P.gesamt_pos_Preis) Gruppensumme,
G.Artikelgruppennr Gruppennummer,
substr(G.Artikelgruppenname,1,20) Gruppenname,
G.ARTIKELSPARTENNR Spartenr
from
best_Position P ,
Produkte_Stamm S,
Artikel_gruppe G
where
(p.produktnr = s.Produktnummer or P.Artikelnummer = S.Artikelnr)
and
(s.Artikelgruppennr = G.Artikelgruppennr)
group by G.Artikelgruppennr,G.Artikelgruppenname,G.ARTIKELSPARTENNR
Auswertung auf Artikelgruppen-Ebene vor Korrektur
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
18/32
GRUPPENSUMME GRUPPENNUMMER GRUPPENNAME
SPARTENR
------------ ------------- -------------------- ---------0
10 Sonst_Finanzdienstle
3
4866
2 Heimwerker
1
19444
4 KFZ-Zubehoer
1
19096
1 Haushaltswaren
1
0
7 Vermittlung_Darlehen
3
34697
3 Gartenbedarf
1
15187
6 Elektroartikel
1
1476000
5 Computerteile
1
Und mit dieser Korrektur:
select
sum(P.gesamt_pos_Preis) Gruppensumme,
G.ARTIKELGRUPPE Gruppennummer,
substr(G.GRUPPENNAME,1,20) Gruppenname,
G.ARTIKELSPARTENNR Spartenr
from
best_Position P ,
Produkte_Stamm S,
vw_Gruppe_Ersatz G
where
(p.produktnr = s.Produktnummer or P.Artikelnummer = S.Artikelnr)
and
(s.Artikelgruppennr = G.ARTIKELGRUPPE)
group by G.ARTIKELGRUPPE,G.GRUPPENNAME,G.ARTIKELSPARTENNR
Die korrigierte Auswertung über die Ersatz-View-Definition
Das korrigierte Ergebnis, das auf der Ersatz-View-Definition basiert lautet:
GRUPPENSUMME
-----------19096
34697
0
0
4866
1476000
19444
15187
8236
GRUPPENNUMMER
-------------1
3
7
10
2
5
4
6
100
GRUPPENNAME
SPARTENR
-------------------- ---------Haushaltswaren
1
Gartenbedarf
1
Vermittlung_Darlehen
3
Sonst_Finanzdienstle
3
Heimwerker
1
Computerteile
1
KFZ-Zubehoer
1
Elektroartikel
1
--> Gruppe nicht erf
0
Man sieht, dass die Gruppennummer 100 zusätzlich in dem Gesamtergebnis auftaucht.
Die Auswertung eine Ebene höher auf den Sparten:
select
ARTIKELSPARTENNAME,
sum(P.gesamt_pos_Preis) Spartensumme,
G.ARTIKELSPARTENNR Spartenr
from best_Position P ,
Produkte_Stamm S, Artikel_gruppe G, artikelsparte S
where
(p.produktnr = s.Produktnummer or P.Artikelnummer = S.Artikelnr)
(s.Artikelgruppennr = G.Artikelgruppennr)
and
G.ARTIKELSPARTENNR = S.ARTIKELSPARTENNR
group by S.ARTIKELSPARTENNAME,G.ARTIKELSPARTENNR
and
Das Ergebnis:
ARTIKELSPARTENNAME SPARTENSUMME
Stand/letzte Änderung 07.04.2017
SPARTENR
257773842
Prüfungen der Geschäftsregeln
19/32
------------------ ------------ ---------Nonfood
1569290
1
Dienstleistung
0
3
select
substr(SE.ARTIKELSPARTENNAME,1,15) Sparte,
sum(P.gesamt_pos_Preis) Spartensumme,
G.ARTIKELSPARTENNR Spartenr
from
best_Position P ,
Produkte_Stamm S,
vw_Gruppe_Ersatz G,
vw_Sparte_Ersatz SE
where
(p.produktnr = s.Produktnummer or P.Artikelnummer = S.Artikelnr)
and
(s.Artikelgruppennr = G.ARTIKELGRUPPE)
and
(g.ARTIKELSPARTENNR = se.ARTIKELSPARTENNR)
group by SE.ARTIKELSPARTENNAME,G.ARTIKELSPARTENNR
Das korrekte Spartenergebnis:
SPARTE
SPARTENSUMME
SPARTENR
--------------- ------------ ---------Nonfood
1569290
1
Dienstleistung
0
3
--> Sparte noch
8236
0
Man erkennt den in den Gesamtauswertungen noch nicht berücksichtigten Wert für die noch nicht richtig erfasste
Sparte, hier 8236.
Fehler aufgrund unterschiedlicher Herleitungsmethoden
Die Auswertung zeigt für die Sparte Dienstleistungen den Wert 0. Bereits bei der Auswertung auf Gruppenebene
konnte für den Wert 7 und 10, das sind Finanzdienstleistungen, der Wert 0 erkannt werden. Das würde bedeuten,
dass keine Dienstleistungen verkauft worden sind. Die Finanzdienstleistungen haben die Produktnummern K5000
/K10000 / K15000 und S10000 wie ein Blick in die PRODUKTE_STAMM-Tabelle zeigt (Domain-Analysen bzw.
Anzeigen der Tabelle). Für diese Produktnummern kann man sich die Domain-Analyse für die Tabelle
BEST_POSITION ansehen, und wird feststellen, dass doch welche verkauft wurden.
Ein Blick in die PRODUKTE_STAMM-Tabelle zeigt die Nummern der Finanzdienstleistungen.
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
20/32
Domain-Analyse zu den verkauften Produkten. Die Finanzdienstleistungen sind im Bereich von 1,3 bis 1,6 % aller
verkauften Produkte verkauft worden. Sie erscheinen aber nicht in den Auswertungen auf Produktgruppen- und
Spartenebene.
Die Ursache für das Problem kann man an der PRODUKTE_STAMM-Tabelle über die Felder Stueckpreis und
Einzelpreis ablesen. Der Umsatz-Wert in den oben gemachten Auswertungen wird in der Tabelle BEST_POSITION
über das Feld Gesamt_Pos_Preis ermittelt. Dieses Feld ist in den Positionssätzen durch die Multiplikation von Menge
und Preis entstanden. Das hat bereits die Analyse zur funktionalen Abhängigkeit ergeben (3. Normalformprüfung in
Phase 3). Hier liegt das Problem. Bei den Finanzdienstleistungen gibt es keinen Einzelpreis. Das Feld ist leer. Also
gibt es auch in der Tabelle BEST_POSITION keinen Wert. Die Ursachen sind sicher in der operativen Anwendung zu
suchen. Offensichtlich sind die Finanzdienstleistungen später in das Firmenportfolio übernommen worden. Für die
Berechnung des Preises gibt es einen anderen Algorithmus. Da diese Darlehen über ein separates Verfahren
abgearbeitet werden, ist es nur für Auswertungen ein Problem, wenn das Feld Gesamt_Pos_Preis leer bleibt.
Der Gewinn bei den Darlehen kommt über den Jahreszins zustande und muss über eine Zinsberechnung ermittelt
werden.
Numerische Daten müssen auch rechenbar sein
Bei dem Versuch die Umsätze der Finanzdienstleistungen im nachhinein zu berechnen, tritt eine weitere Schwierigkeit
auf. Die Werte in dem Feld Stueckpreis sind für Finanzdienstleistungen nicht rechenbar, denn ein „%“-Zeichen folgt
dem Wert.
Eine Pattern-Analyse zeigt die Verhältnisse deutlich auf. Hier sind zwei Informationen in einem Feld zu finden: Einmal
der Wert und zum zweiten die Einheit bzw. die Art des Wertes. Diese zweite Information sollte in einem zweiten Feld
(z. B. Einheit) zu finden sein.
Diese Konstruktion stellt eine Hürde für einfache Zugriffe dar, die Information ist nicht leicht zugreifbar.
Erst über eine aufwendige Umwandlung steht der Wert zur Verfügung.
Die Patternanalyse zeigt für das Feld Stueckpreis in der Tabelle PRODUKTE_STAMM, dass dieses Feld nicht
„rechenbar“ ist. Das „%“-Zeichen führt zu einem alphanumerischen Wert.
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
21/32
Auch für dieses Problem wieder eine Alternativermittlung, um die Konsequenzen für Auswertungen zu bewerten.
Die Ermittlung der Umsätze über die Finanzdienstleistungen kann über diese SQL-Abfrage erfolgen:
Select sum(F.preis) Gruppensumme,
substr(F.artikelgruppennr,1,10) Gruppennummer,
F.Gruppenname Gruppenname,
substr(F.Sparte,1,25) Spartenr
from VW_Finanz_Produkte F,
BEST_POSITION P
where P.produktnr in ('K5000','K10000','K15000','S10000') and
P.produktnr = f.Produkt
group by f.artikelgruppennr,F.Gruppenname,F.Sparte
Die komplette Abfrage für alle Artikelgruppen, also jetzt inklusive der Finanzdienstleistungen, lautet jetzt:
Select * from (
(Select sum(F.preis) Gruppensumme,
substr(F.artikelgruppennr,1,10) Gruppennummer,
F.Gruppenname Gruppenname,
substr(F.Sparte,1,25) Spartenr
from VW_Finanz_Produkte F,
BEST_POSITION P
where P.produktnr in ('K5000','K10000','K15000','S10000') and
P.produktnr = f.Produkt
group by f.artikelgruppennr,F.Gruppenname,F.Sparte
)
UNION
(select
sum(P.gesamt_pos_Preis) Gruppensumme,
substr(G.ARTIKELGRUPPE,1,10) Gruppennummer,
substr(G.GRUPPENNAME,1,20) Gruppenname,
substr(G.ARTIKELSPARTENNR,1,25) Spartenr
from
best_Position P ,
Produkte_Stamm S,
vw_Gruppe_Ersatz G
where
(p.produktnr = s.Produktnummer or P.Artikelnummer = S.Artikelnr)
and
(s.Artikelgruppennr = G.ARTIKELGRUPPE)
and
(G.ARTIKELGRUPPE not in (7,10))
group by G.ARTIKELGRUPPE,G.GRUPPENNAME,G.ARTIKELSPARTENNR
)
)
Das Ergebnis im Beispieldatenbestand liefert
GRUPPENSUMME
-----------4866
8236
15187
19096
19444
34697
GRUPPENNUM
---------2
100
6
1
4
3
Stand/letzte Änderung 07.04.2017
GRUPPENNAME
------------------------Heimwerker
--> Gruppe nicht erf
Elektroartikel
Haushaltswaren
KFZ-Zubehoer
Gartenbedarf
SPARTENR
-------------------1
0
1
1
1
1
257773842
Prüfungen der Geschäftsregeln
66000 10
128500 7
1476000 5
22/32
Sonst_Finanzdienstleistun 3
Vermittlung_Darlehen
3
Computerteile
1
Auf die Summierung auf Spartenlevel kann hier verzichtet werden. Die Gruppen 7 und 10 ergeben zusammen ~
195000 €. Das sind fast 10% des gesamten Umsatzes. Dieser Wert wäre ohne eine genaue Analyse zu den
Basisdaten in den Auswertungen nicht erschienen. Diese Berechnung wurde an dieser Stelle durchgeführt, um die
Auswirkungen von fehlerhaften Basisdaten auf aggregierte Auswerteergebnisse aufzuzeigen. Auch das noch so
schöne Business Intelligence Tool hat hier keine Chance solche Fehler zu eliminieren. Die Ursachen für die Probleme
sind erkannt. Gelöst werden kann dies nur, indem die Ertragssumme auch Produktgruppen gerecht ermittelt werden.
Hierzu ein Zitat aus dem (CIO Magazin, 2007)
„Dass aber die Ergebnisse von BI-Lösungen immer nur so gut sein können, wie die der verarbeiteten Daten, setzt sich
.... nur langsam durch.“
Problemkomplex 2 – Meßbarkeit des Absatzes einzelner Produkte
Durch die Übernahme von anderen Unternehmen und den Ausbau der Geschäftsbereiche, sind neue Produktarten in
das Portfolio hinzugekommen. Allerdings lebten die Originalnummerierungen fort. So gibt es das Feld „Artikelnr“ und
das Feld „Produktnummer“. Damit man dennoch mit den Produktinformationen arbeiten kann, hat man ein Status-Feld
eingeführt, in dem festgehalten wird, welches Nummernfeld gilt.
Allein diese Konstruktion stellt einen Datenqualitätsmangel dar. Sie widerspricht der Anforderung der Handhabbarkeit.
von Daten.
Es wurde bereits eine Geschäftsregel (R2) formuliert, um den Umgang mit den unterschiedlichen Nummern zu
steuern.
R2:
Wenn Artikelnr = NULL dann Produktnummer NOT NULL und (Status = 2 oder Status =3)
oder
Wenn Artikelnr NOT NULL dann Produktnummer = NULL und Status = 1
Bei der Überprüfung dieser Regel ist deutlich geworden, dass diese Regel nur zu ~85% eingehalten wird. Die weitere
Überprüfung dieses Zusammenhangs ergibt:
Das Statusfeld ist für alle Produkte mit einem Wert gefüllt. Das zeigt die Domain-Analyse auf das Statusfeld:
Domain-Analyse für Produkt-Status
Die Data-Rule-Analyse (Rule R2) findet zwei Probleme: Einmal sind es die bereits bekannten Finanzdienstleistungen
('K5000','K10000','K15000','S10000'), die unter Produktnummer erfasst sind und dennoch unter Status den Wert 1
verzeichnet haben. Zum anderen gibt es 7 Sätze, die weder eine Produktnummer noch eine Artikelnummer haben.
Data-Rule-Analyse für den Zusammenhang Produktnunner / Artikelnr / Status
(Überschriften sind korrigiert, da sie im Tool falsch angezeigt werden)
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
23/32
Hier schließt sich die Frage an, wie sind diese Produkte in den Bestellungen behandelt worden. D. h. die Regel R2
darf nicht nur auf die PRDOKTE_STAMM-Tabelle angesetzt werden. Mit ihr sind auch die Bewegungsdaten, also
BEST_POSITION, zu prüfen.
Zudem kann man noch eine Reihe weiterer Regeln formulieren, um die Situation der Verwendung von Produkt/Artikelnummern in den Bestelldaten zu verifizieren.
Hilfsmittel: Entscheidungstabellen
An diesem Fall kann die Verwendung von Entscheidungstabellen in der Kombination mit den Data Rules gut
demonstrieren.
Die unterschiedlichen Kombinationsmöglichkeiten der Felder „Artikelnr“, „Prodnr“ und „Status“ lassen sich als
Entscheidungstabelle formulieren. Damit wird mit Sicherheit jede Fehlervariante erfasst. Eine solche
Entscheidungstabelle sieht für den hier betrachteten Problemkomplex so aus:
Entscheidungstabelle für die möglichen Regelverletzungen in der BEST_POSITION-Tabell bei der Verwendung der
unterschiedlichen Artikelnummierung (Felder Artikelnr/Prodnr/Status)
Für jede Entscheidungszeile definiert man eine Data Rule. Für die Benennung der Data Rules sollte die
Namensvergabe sprechend gewählt werden. Die Namen erscheinen in der Rules-Sektion des Profile Result-Fensters
und man kann die Werte entsprechend leicht ablesen bzw. vergleichen. Achtung bei der Namensvergabe stehen nur
30 Zeichen zur Verfügung, man muss also z. T. stark gekürzte Namensteile nutzen.
Auswertung der Data Rules zu den verschiedenen Varianten in der Entscheidungstabelle
Hier gibt es eine Reihe von Ergebnissen:
 Für 10,38 % der Bestell-Positionen sind keine Umsatz-Messungen möglich, weil weder Artikelnr noch Produktnr
gepflegt sind. Sie lassen sich nicht auf die Produkt-Stammdaten zurückführen und tauchen daher auch später
nicht
mehr
in
produktbezogenen
Umsatzauswertungen
auf.
Um dennoch eine Zuordnung für Auswertezwecke zu erreichen, müssten die entsprechenden Werte manuell
nachgetragen werden. Andere Spalten müssten Hinweise auf die richtigen Nummern geben.
 Aus dem Vorpunkt kann geschlossen werden, dass die Summe aller Best_Positionen mit Artikelnr = NOT NULL
und Best_Positionen mit Produktnr = NOT NULL kleiner sein müsste, als die Komplettsumme. Eine Überprüfung
mit reinem SQL ergibt, dass das nicht der Fall ist. Für diesen Effekt kann es zwei Ursachen geben:
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
o
o
24/32
Es gibt Sätze in denen Artikelnr und Prodnr gleichzeitig gefüllt sind. Das ist nicht der Fall, wie die
entsprechende Data Rule zeigt.
Es gibt doppelte Produktnummern in der PRODUKTE_STAMM-Tabelle. Das ist der Fall, wie die
Domain-Analyse zur PRODUKTE_STAMM-Tabelle zeigt. Damit werden automatisch bestimmte
Umsätze verdoppelt. Hier hilft nur eine Dublettenbereinigung in den Produktstamm-Daten.
Doppelte Produktnummern
 Das dritte erkannte Problem sind die BEST_POSITIONEN, die unter Produktnr einen Eintrag besitzen aber unter
Status den Wert 1 tragen. Das sind die Finanzdienstleistungen. Hier sollten die Stammdaten einfach manuell
korrigiert werden.
Problemkomplex 3 – Vergleichbarkeit von Daten
(Ein-/Verkaufsdaten)
Bei der Bearbeitung dieses Komplexes gilt der erste Blick wieder den Stammdaten. Hier betrachtet man die
eingetragenen Einkaufs- und Verkaufspreise, weil sie die Grundlage für die Bewegungsdaten darstellen. Um das zu
klären, muss zunächst jedoch eine Art Bestandsaufnahme gemacht werden.
Hilfsmittel: Fragen formulieren
Im folgenden wird ein weiteres Verfahren vorgestellt. Um Sachzusammenhänge, die man prüfen will, griffiger zu
machen, formuliert man zunächst Fragen. Diese Fragen sollten einfache Aussagen gebildet werden. Man kann sie
bereits so wählen, dass im Folgenden Data Rules sehr leicht daraus abgeleitet werden können.
Zu dem gestellten Problem formuliert man also die Frage:
Liegen alle Stammdaten vor?
Das sind Einkaufsstueckpreis, Einkaufseinzelpreis, Stueckpreis und Einzelpreis.
Bereits ein Blick in die Aggregation-Analyse zeigt, dass ein großer Teil der Daten unbrauchbar ist. Allerdings zeigt die
Aggregation-Analyse für Einkaufsstueckpreis und Einkaufseinzelpreis die gleiche Häufigkeit von NULLs, also
fehlenden Werte. Das lässt vermuten, dass es hier einen Zusammenhang zu einer anderen Größe geben muss. Die
Zahl 76,7% wird auch bei anderen Attributen wieder gefunden.
Daraufhin kann eine weitere Frage formuliert werden:
-> Um welche Art von Produkten handelt es sich, wenn diese Felder nicht ausgefüllt sind?
und
- > Wenn Spalten ausgefüllt sind, sind sie in einer bestimmten Häufigkeit ausgefüllt?
Dahinter steckt der Versuch herauszufinden, ob zumindest für einen Teil der Produkte gültige Preisaussagen getroffen
werden können.
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
25/32
Blick auf die Stammdaten zu den Einkaufs- und Verkaufspreisen
Ein Indikator hierfür kann wieder das Status-Feld sein, das ja mal eingeführt wurde, um Artikel und Produkte zu
unterscheiden. Hier helfen Rules.
Überprüfung der Abhängigkeit bei den Vorkommen von Einzelpreis und Stückpreis
Die erste Regel (EINZEL_AND_ESTUECK_NULL_ST_1) überprüft das gleichzeitige Fehlen von Werten bei beiden
Preisarten und gleichzeitigem Statuswert 1. Das Vorkommen von 57,53 % bestätigt die Vermutung, dass es sich hier
um Artikel mit Artikelnummern handelt. Alles andere sind Varianten mit Produkt-Status 2 oder 3 oder einfach nur
abweichende Werte. D. h. bei Artikeln mit einer Artikelnummer fehlt der Einzelpreis.
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
26/32
Ein Ergebnis hier ist, dass für die mit einer Artikelnummer gekennzeichneten Einträge nicht überprüft werden können,
denn es liegen keine Einkaufspreise vor. Für eine weitere Analyse kann man sich also auf die Einträge mit Status 2
oder 3 beschränken.
Die Regel E_EINZEL_AND_E_STUECK_P_NULL bestätigt mit 76,71%, dass tatsächlich beide Felder immer
gleichzeitig leer sind.
Aus der Functional Dependency – Analyse wissen wir bereits, dass es innerhalb der Tabelle BEST_POSITION eine
funktionale Abhängigkeit zwischen der verkauften Menge und dem Preisfeld der Tabelle gibt. Diese Functional
Dependency – Analyse kann man über eine View-Definition und unter Berücksichtigung der vorher festgestellten
fehlerhaften Produktdaten auch auf die PRODUKTE_STAMM-Tabelle ausweiten.
create view VW_EV_Preis_Check as select
substr(p.produktnummer,1,25) Produktnummer,
substr(p.EINKAUFS_STUECKPREIS,1,15) E_stueckpreis
,
substr(p.EINKAUFS_EINZELPREIS,1,15) E_einzelpreis ,
substr(p.STEUCKPREIS,1,15) V_stueckpreis ,
substr(p.EINZELPREIS,1,15) V_einzelpreis ,
b.PREIS pos_EInzel_Preis,
b.GESAMT_POS_PREIS,
b.BESTELLMENGE POS_BESTELLMENGE
from produkte_Stamm p, best_position b
where artikelnr is null and b.PRODUKTNR = p.Produktnummer
Die View-Definition zum Vergleichen von Einkaufs und Verkaufspreisen
Zur Sicherheit wird zunächst eine Data Type-Analyse zu der neuen View-Definition vorgenommen: Es fällt auf, dass
einzelne Werte in den Stammdaten nicht „rechenbar“ sind. In dem Verkaufsstückpreis sind %-Werte enthalten. Das
sind die Finanzprodukte, der entgültige Umsatz muss hier über eine zusätzliche Formel zunächst ermittelt werden.
Nicht rechenbare Daten in den Preisfeldern.
Diese View-Definition bietet diese zusammenhängende Sicht auf Produkt und Bewegungsdaten. Auch diese ViewDefinition wird dem Profiling-Vorgang mit dem Ziel der Erkennung von Abhängigkeiten unterworfen.
Zusammenführung von Ein- und Verkaufsdaten in einer View-Definition
Doppelte Stammdatendatensätze
Die Functional Dependency – Auswertung zeigt dann ganz beiläufig die nächste Unsauberkeit:
Offensichtlich gibt es in den Stammdaten nicht nur doppelte Produktsätze, sondern auch doppelte Produktsätze mit
unterschiedlichen Preisangaben. Das Produkt „20557-Fischer-Buesum“ ist mit zwei unterschiedlichen
Einkaufs_Stueckpreis- und Einkaufs_Einzelpreis-Angaben vorhanden. Das könnte auch noch richtig sein, wenn sich
der Preis zwischenzeitlich geändert hätte. Aber dann müsste sich auch der Gesamt_Pos_Preis in Abhängigkeit von
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
27/32
der Menge ebenfalls ändern. Diese Änderung findet aber nicht statt. Der teuere Einkaufspreis ist zwar als
Verkaufspreis übernommen worden, die Berechnung des Gesamtpreises, also Verkaufspreis mal Menge, ist falsch.
Als Ursache kann man vermuten, dass bei der Berechnung des Gesamtpreises auf die Stammdaten zurückgegriffen
wurde, aber aufgrund des nicht eindeutigen Zugriffsverfahrens der „falsche“ Satz erwischt wurde.
Zur Lösung müsste in den Produktstammdaten gekennzeichnet sein, welcher Preis für eine jeweilige Verkaufsaktion
gilt.
Functional Dependency Ausschnitt. „20557-Fischer Buesum“ ist zweimal, allerdings mit unterschiedlichen
Verkaufspreisen, jedoch mit gleichen Gesamt-Positions-Werten, vorhanden.
Betrachten wir noch ein weiteres Phänomen:
Gefunden wird eine Abhängigkeit zwischen der Bestellmenge und dem Einzel_Preis deren Multiplikation zu 100% den
Gesamt_Preis pro Position ergeben. Das ist sicher richtig. Betrachten wir jedoch den Verkaufs_Einzelpreis, also die
Information, die über den View aus den Stammdaten kommt, dann finden wir zwar auch eine Abhängkeit, allerdings
nur zu 85,1 %. Bei der Suche nach den abweichenden Werten, entdecken wir auch hier, dass zwischen dem
Einzelpreis in den Bewegungsdaten (BEST_POSITION) und dem Verkaufseinzelpreis in den Stammdaten
(PREDUKTE_STAMM) bei einzelnen Produkten Unterschiede bestehen. Und zwar genau bei 14,9 % aller
Bestellpositionen.
Die Functional Dependency Analyse zeigt Unterschiede in den Beziehungen von Bestellmenge und Einzelpreisen.
Die Data Drill-Anzeige für die von der Abhängigkeitsregel abweichenden Sätze zeigt, wo die Unterschiede liegen. In
den Bewegungsdaten sind andere Einzelpreise verwendet worden, als in den Stammdaten
Mit der hier genutzten View-Definition kann jetzt auch sehr leicht überprüft werden, ob sich Einkaufs- und
Verkaufspreise in einer entsprechenden Relation befinden. Hier definiert man wieder eine einfache Data Rule, die
misst, wie oft der Verkaufspreis wirklich höher als der Einkaufspreis ist.
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
28/32
Das Ergebnis listet tatsächlich einige Ausreißer auf. Bei über 34 % der messbaren Bewegungsdatensätze wurden
offensichtlich Dinge verkauft, deren Einkaufspreis höher als der Verkaufspreis lag. Die Zahl erscheint zunächst sehr
hoch. Es sollte jedoch berücksichtigt werden, dass bei dieser Messung nur die Produkte mit einer eingetragenen
Produktnummer in der Betrachtung enthalten sind. Bei den mit einer Artikelnummer gekennzeichneten Produkten, gibt
es keine dokumentierten Ein- und Verkaufspreise.
In über 34% der mit einer Produktnummer dokumentierten Produkte liegen die Verkaufspreise höher als die
Einkaufspreise.
Um eine Kommastelle vertan
Hier lohnt ein Blick in das Data Drill Panel, denn die Unterschiede zwischen Ein- und Verkaufspreisen fallen nicht
immer gleich gravierend aus. Es gibt 3 Fälle, bei denen es sich offensichtlich um ein verschobenes Komma und damit
um eine 10ner Potenz handelt
Das Produkt „20556-Fischer-Buesum“ ist ein solcher Fall. Tatsächlich wurde hier mit dem um eine Stelle
verschobenen, falschen Verkaufspreis multipliziert, so dass der Gesamtpositions_Preis auch falsch ist. Hier geht sehr
viel Geld verloren.
Überlagerte Defekte verstecken sich gegenseitig
Bei dem Produkt „20557-Fischer-Buesum“ haben wir wieder die Situation, dass die Einzel-Positions-Werte (POSEINZEL_PREIS), also der Einzelpreis aus den Bewegungsdaten nicht dem Einzelpreis aus den Stammdaten
(V_EINZELPREIS) folgt. Das Phänomen hatten wir oben bereits festgestellt. Hier ist es jedoch noch zusätzlich durch
das Problem mit dem verschobenen Komma überlagert.
Die Folgen der Fehler wirken sich in zwei Richtungen aus und heben sich gegenseitig auf
Die übrigen Fälle sind nicht so gravierend aber dennoch falsch. Ein kurioser Fall zeigt, dass sich die Bilanz auch
wieder in die entgegengesetzte Richtung drehen kann. Das Produkt „4432-Knoll-Hannover“
besitzt als
Verkaufs_Einzelpreis den Wert 0 und im Einkauf steht eine Zahl 1300. Aber bei der Berechnung des tatsächlichen
Gesamtwertes der Position (POS_GESAMT_PREIS) entsteht wieder ein fast verdoppelter Einkaufswert.
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
29/32
Kurioser Fall: Zu seinen Gunsten verrechnet
Hilfsmittel: Regeln ableiten
Komplexe Zusammenhänge, an denen mehrere Faktoren beteiligt sind, löst man zunächst, indem man eine klare
Definition der beteiligten Größen festlegt. Die Größen erhalten Namen und man schreibt sie nebeneinander. Daraus
leitet man dann Formeln ab, mit denen man die Abhängigkeit zwischen diesen Größen nachbildet.
Letztlich läuft die Analyse des aktuellen Problems auf den rechnerischen Vergleich der folgenden 7 Größen hinaus:
Einkaufs
einzelpreis
Einkaufs
Stueckpreis
Verkaufseinzelpreis
Verkaufsstückpreis
Verkaufsmenge
Stückzahl
Verkaufspreis
EEP
bezogen
auf
die
handelbar
e Einheit
ESP
Das ist der
tatsächliche
Einzelpreis
des
jeweiligen
Handelsgut
es.
Er dient als
Rechenbasi
s, wenn auf
sich
ändernde
Handelsein
heiten
umgerechn
et werden
muss.
VEP
Das
ist
wieder
der
Einzelpreis
pro
Handelseinh
eit.
VSP
Das ist der
tatsächliche
Einzelpreis
unabhängig
von
Handelseinheit
en
VM
Das ist die
Menge der
Verkauften
Handelsein
heiten.
SZ
Anzahl
Stück pro
Handelsein
heit
VP
Rechnungs
-preis
aus Menge
mal
Verkaufseinzelpreis
Tabelle zur Verdeutlichung der Einflussfaktoren zur Berechnung des Endpreises
Diese Größen müssten im Unternehmen dokumentiert sein. Das Beispiel zeigt, dass dies nicht immer der Fall war.
Denn in einigen Rechenergebnisse konnte man bereits anhand der Zahlenwerte sehen, dass zur Berechnung des
Rechnungswertes für den Kunden der Stueckpreise zu Grunde gelegt wurde. Nicht aber der wesentliche höhere
Einzelpreis, der ja eine Obermenge des Stückpreises darstellt. Im Verlauf der Analyse sollte aber zu einem
bestimmten Zeitpunkt Klarheit über diese Größen sein.
Aus dieser Tabelle kann man schließlich leicht die gültigen Regeln bzw. Formeln ableiten: z. B.:
EEP >= ESP
EEP < VEP
VP = VM * VEP
VEP= VSP*SZ
VP = VSP*SZ*VM
Diese Regeln lassen sich wieder wie oben gezeigt in Data Rules formulieren, und über das Profiling prüfen.
Problemkomplex 4 – Liefervorgänge
Folgende Fragestellungen sollten hier beantwortet werden:
-> Wird bei einer Bestellung auch geliefert?
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
30/32
-> Werden gelieferte Waren auch gezahlt?
Zur Überprüfung kann man wieder eine Data Rule in Verbindung mit einer View-Definition nutzen.
Die View-Definition:
create view VW_Best_Lief as
select
b.Bestelldatum best_Bestelldatum,
L.Bestelldatum Lief_Bestelldatum,
L.Lieferdatum Lief_Lieferdatum,
B.Bestell_Total best_Bestell_Total,
L.Bestell_Total Lief_Bestell_Total,
L.Lieferkosten Lief_Lieferkosten,
L.Brutto_Betrag Lief_Brutto_Betrag
from bestellung B,
lieferung L
where
b.Bestellnr = L.Bestellnr
Diese View-Definition liefert die folgenden Werte:
Die View-Definition zur Analyse der Zusammenhänge von Bestellungen und Lieferungen.
Die Data Rules können fast 1:1 zu den oben formulierten Fragen definiert werden. Danach wird festgestellt:
Allen Bestellungen folgt auch eine Lieferung. Zumindest gibt es einen entsprechenden Liefersatz.
Alle Bestellungen sind auch geliefert worden
Die weitere Überprüfung läuft jetzt wie in den Beispielen zuvor.
Über eine Domainanalyse auf die View-Definition stellt man fest, dass bei 14,9 % keine Zahlungen vorliegen. Bei einer
weiteren Analyse dieser Nicht-Zahler wird man auf Reklamationen stoßen, die nicht im System enthalten sind. Diese
können auch nicht als Datenqualitätsmängel identifiziert werden. Die Daten sind einfach nicht da und die Lieferung
erscheint als eine zu zahlende Lieferung. Hier müsste der Lieferprozess verbessert werden.
Um weitere Prüfungen durchzuführen stellt man auch hier wieder Datenregeln auf, um Abhängigkeiten zu prüfen.
Problemkomplex 5 – Kundenkartenauswertungen
Die Auswertungen rund um die Kundenkarte erfolgt nach den gleichen bereits vorgestellten Verfahren.
Zunächst stellt man die interessierenden Fragestellungen auf:
-> Wie viele Kunden besitzen eine Kundenkarte?
-> Erzielt man mit Kartenbesitzern mehr Umsatz, als mit Kunden ohne Karten?
-> Was sind hilfreiche Informationen über Kunden?
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
31/32
-> Liegen diese hilfreichen Informationen bei Kundenkartenbesitzern vor?
Dann wird man wieder passende View-Definitionen und Data Rules formulieren.
Das ist aber eine Wiederholung der Verfahren von zuvor und wird hier nicht mehr vorgestellt.
Zusammenfassung der Ergebnisse der Analyse der Problemkomplexe (PK 1-4)
Zusammenfassung zu den Problemkomplexen und Lösungen
Aspekt
PK 1
Orphans in Artikelgruppen und Artikelsparten
Die Einnahmen für Finanzdienstleistungen können nicht
richtig gemessen werden
Orphans in Produktestamm
Maßnahmen
Fehlende
Artikelgruppen
definieren
Fehlende
Spartennummern
definieren
Erfassen der Einnahmen von
Finanzdienstleistungen
mit
separaten
Spalten
in
den
entsprechenden Tabellen
Feld
Stueckpreis
in
Produkte_Stamm in zwei Felder
auflösen: in ein Wertefeld und ein
Einheitenfeld.
Artikelgruppennummern pflegen
PK 2
Es gibt doppelte Produktnummern. Dies führt bei
Auswertungen zu diesen Produkten zu doppelten
Umsätzen, die in Wirklichkeit nicht da sind.
Finanzdienstleistungen haben den Produkt_Status-Wert
von 1, obwohl sie einen Wert von 3 haben müssten. Das
führt zu verfälschten Auswerten. Finanzdienstleistungen
werden als solche nicht erkannt.
Deduplizieren
Produktstammdaten
von
Für Artikel mit Artikelnummern und Status = 1 lassen
sich keine Preisherleitungsregeln überprüfen, da es
hierfür in den Daten keine Einkaufspreise gibt.
Bei doppelten Produkte-Stammsätzen ist nicht klar
erkennbar, ob diese Sätze einfach nur doppelt sind, oder
ob es sich um eine Variante mit einem anderen Preis
handelt. Unabhängig davon, wird dennoch der Preis von
immer nur einem Satz für die Berechnung
herangezogen.
Bei
etwa
einem
Drittel
der
Produkte
mit
Produktnummern werden die Waren zu niedrigeren
Preisen verkauft, als sie eingekauft wurden. Die
Differenzen sind unterschiedlich stark. Durch weitere
Rechenfehler zu Gunsten des Unternehmens wird der
entstandene Verlust wieder minimiert.
Preise nachpflegen
Fehlende Zahlungen entpuppen sich als Reklamationen,
die jedoch nicht gemessen werden können, da sie
nirgends erfasst sind.
Erfassung von Reklamationen
und Zuordnung zu Bestellungen
auf Positionsebene.
Korrektur des Status-Wertes bei
Finanzprodukten von 1 auf 3
PK 3
Berechnung
von
Gesamt_Pos_Preis überprüfen.
Alle Algorithmen, die diesen Wert
berechnen,
müssen
ihre
Grunddaten
aus
identischen
Quellen beziehen.
Auf korrektes Beziehen von
Grunddaten bei der Berechnung
achten.
Klare Definition von Kenngrößen
z. B. Einzelpreis und Stueckpreis.
PK 4
Stand/letzte Änderung 07.04.2017
257773842
Prüfungen der Geschäftsregeln
32/32
Zusammenfassung der Erfahrungen mit der Service GmbH (Phase 4)
Abschließend sollte man die gesammelten Analyseergebnisse zusammenfassen. Dies geschieht u. a. in einem
allgemeinen Bericht, in dem die gefundenen Problembereiche skizziert werden. Ein solcher Bericht ist für das
verantwortliche Management geeignet und sollte auch Aussagen über das Ausmaß der Qualitätsprobleme beinhalten.
Wirklich hilfreich sind natürlich die Einzelergebnisse, da nur durch sie konkrete Korrekturmaßnahmen gefunden
werden können. Das ist eine Zusammenstellung der Templates, der Abarbeitung der Geschäftsregeln und schließlich
die Ergebnisse aus der Bearbeitung der Problemkomplexe. Das muss in dieser Unterlage nicht noch einmal
aufgelistet werden.
Generelle Empfehlungen
Die Produkte_Stamm-Verschlüsselung muss komplett überarbeitet werden. Es sollten neue, über alle Produktgurppen
hinweg eindeutige Schlüssel vergeben werden. Wenn dies aus unterschiedlichen Gründen nicht gelingt, so sollte es
möglich sein über eine entsprechende Konkatenierung von historischen Schlüsseln und einer Referenznummer diese
Eindeutigkeit herzuleiten.
Eine Data Warehouse kann helfen
Ein einfache Lösung kann für viele Bedürfnisse aus den Fachabteilungen erstellt werden. Es ist die Erstellung einer
separaten Datenhaltung in Form eines Data Warehouses. Ein solches Data Warehouse müsste in seinen
Auswertedatenmodellen folgende Informationen liefern.
Alternatives Datenmodell speziell für Auswertezwecke optimiert. Die grauen Kästen sind die Bewegungsdaten
Das hier abgebildete Datenmodell ist zunächst redundanzfrei (mit Ausnahme der denormalisierten Strukturen in den
Produkte- und Kundenstammdaten). Die Bewegungsdaten befinden sich Ausnahmslos auf dem Level von
Bestellpositionen. Die zentrale Tabelle, die alle Informationen zusammenhält ist die Bestelltabelle.
Stand/letzte Änderung 07.04.2017
257773842