A) Auftragsanzahl und DISTINCT

Ich möchte in diesem Rahmen gleich nochmals zur Problematik der Zählung der Aufträge zurückkommen. Wie in der LVa besprochen, darf sich ein Unterschied zwischen einer Zählung des Schlüsselelements Auftrag.Nr und der Autragspos.Auftragsnummer ergeben.
Diese differrierenden Ergebnisse sollten sich mittels des Befehls DISTINCT verhindern lassen, da ja hier die Mehrfachnennung der Auftragsnummer in der Tabelle Auftragspos ignoriert werden sollte.

Die neuerlichen Tests mit den 4 möglichen Abfragevarienten liefern aber nicht die logisch-prognostizierten Ergebnisse:


VAR 1: Bezug Auftrag.Nr + DISTINCT

SELECT Auftrag.Kundennummer, Kunde.Vorname, Kunde.Nachname, count(distinct Auftrag.Nr) as Aufträge FROM Auftrag, Kunde WHERE Kunde.Nr=Auftrag.Kundennummer group by Kunde.Nr order by 4 desc

Max Aufträge: 9

Variante 1

VAR 2: Bezug Auftrag.Nr ohne DISTINCT

SELECT Auftrag.Kundennummer, Kunde.Vorname, Kunde.Nachname, count(Auftrag.Nr)as Aufträge FROM Auftrag, Kunde WHERE Kunde.Nr=Auftrag.Kundennummer group by Kunde.Nr order by 4 desc

Max Aufträge: 13

Variante 2

VAR 3: Bezug Auftragspos.Auftragsnummer + DISTINCT

SELECT Auftrag.Kundennummer, Kunde.Vorname, Kunde.Nachname, count(distinct Auftragspos.Auftragsnummer)as Aufträge FROM Auftrag, Kunde, Auftragspos WHERE Kunde.Nr=Auftrag.Kundennummer and Auftrag.Nr=Auftragspos.Auftragsnummer group by Kunde.Nr order by 4 desc

Max Aufträge: 5

Variante 3

VAR 4: Bezug Auftragspos.Auftragsnummer ohne DISTINCT

SELECT Auftrag.Kundennummer, Kunde.Vorname, Kunde.Nachname, count(distinct Auftragspos.Auftragsnummer) as Aufträge FROM Auftrag, Kunde, Auftragspos WHERE Kunde.Nr=Auftrag.Kundennummer and Auftrag.Nr=Auftragspos.Auftragsnummer group by Kunde.Nr order by 4 desc

Max Aufträge: 138

Variante 4

-> hier ergibt sich nach Überprüfung einfach die gleiche Anzahl wie wenn man nach den Auftragspositionen selbst sucht!

Am Ende komme ich hierzu derzeit zu 2 Schlussfolgerungen:

1. da nicht alle Aufträge der Tabelle Auftrag auch in der Tabelle Auftragspos mit aufgeschlüsselten Daten vorhanden sind, ergibt sich bei Einbeziehung der Tabelle Auftragspos eine Abweichung (Auftragszahl, Umsatz pro Auftrag, DB pro Auftrag, …)

2. gibt es ein Problem im Zusammenhang mit der Schlüsselelementfunktion der Auftrag.Nr wenn hier Abfragergebnisse durch DISTINCT abgeändert werden. Die Zählproblematik lässt sich nach genauerer Betrachtung der konkreten Auflistung der Aufträge des Kunden „Kritten“ schnell auf tatsächlich doppelt vorhandene Auftragsnummern auch in der Tabelle Auftrag zurückführen:

Kundennummer	Vorname	Nachname	Nr
160	Raffaela	Kritten	41
160	Raffaela	Kritten	42
160	Raffaela	Kritten	131
160	Raffaela	Kritten	132
160	Raffaela	Kritten	41
160	Raffaela	Kritten	42
160	Raffaela	Kritten	131
160	Raffaela	Kritten	132
160	Raffaela	Kritten	1034
160	Raffaela	Kritten	1168
160	Raffaela	Kritten	1748
160	Raffaela	Kritten	1891
160	Raffaela	Kritten	2127

also 13 gelistete Aufträge – aber nur 9 Auftragsnummern!


B) Detailbetrachtung eines Kunden (Erdl)

Zunächst die Grunddaten des Kunden Erdl:

Daten Erdl

Dann die dazugehörigen Auftragsdaten:

Kunden- und Auftragsdaten

Nun die Details der Aufträge des Kunden Erdl:

Details Aufträge

Und jetzt schließlich auch die Daten zu den Auftragspositionen:

Auftragspositionsdaten

Wie schon nach der Analyse in A) vermutet, zeigt sich auch bei der genauen Ansicht eines einzelnen Kunden das Problem der doppelten Auftragsnummer - im konkreten Fall Erdl geht es um 4 exakt gleiche, doppelt in der Datenbank vorhandene, Aufträge.

Mit den exportierten Daten kann man nun die Daten richtig stellen und folgende Analyse erstellen:

KUNDE Erdl (K-Nr 14)		Bücher	Einzelpreis	Gesamtpreis
Summe Gesamt		3538	€  2.120,00	€ 117.726,00
ANr 411		1135	€     713,00	€   41.599,00
ANr 412		629	€     271,00	€   19.787,00
ANr 501		1130	€     671,00	€   30.488,00
ANr 502		644	€     465,00	€   25.852,00
Durchschnitt pro Auftrag		884,5	€     530,00	€   29.431,50

C) Erkenntnisse & Auswirkungen

Nach den bisherigen Erkenntnissen stellt sich die Frage, ob in der Tabelle Auftrag einfach alle Auftragsnumern doppelt vorhanden sind und man somit die Ergebnisse nur absolut korrigieren muss - sie aber relativ gesehen aussagekräftig sind?

Aufträge in der Tabelle Auftrag:

AuftragsNr 4
AuftragsNr 78
AuftragsNr 106
AuftragsNr 284
AuftragsNr 567

Nun kann an also davon ausgehen, dass wirklich alle Aufträge in doppelter Form eingetragen sind - Alle? Nein, die Kunden die nur einen einzigen Auftrag abgebeben haben (ca. 180 Personen) finden sich nur mit einer einfachen Auftragsnummer in der Tabelle Auftrag.

Am Ende stellt sich zB für die KollegInnen die sich mit ABC-Analysen beschäftigt haben, die Problematik, dass die Berechnung des totalen Gesamtumsatzes (Zugriff auf Buch & Auftragspos) und die Berechnungen der einzelnen Kundengesamtumsätze (Zugriff Kunde, Auftrag, Auftragspos, Buch) durch die Problematik der teilweise doppelten Aufträge nicht in Einklang zu bringen sind.

Eine "über den Daumen"-Kalkulation zeigt aber, dass sich bei Halbierung der Kundenumsätze auf Grund der doppelten Auftragszahlen ein doch relativ stimiges Vergleichsergebnis ergibt:

Gesamtumsatz Buchhandel	€ 11.669.890,73
hochgerechnete Kundenumsätze	€ 23.378.280,00
~Halbierung	€ 11.689.140,00

… zu den nun eigentlich angedachten Ausführungen zu den Problemen der Tabelle AUFTRAGSPOS, darf ich hier jetzt zum Kollegen Christian Hackl (Link) verweisen - dem heute auch aufgefallen ist, dass hier gleich alle Daten zu den Aufträgen mit Nummern über 1000 fehlen!

Schöne Grüße, fa

Kunden- und Sortimentsanalyse für Aktionsangebot:

Ich möchte nach einer kleinen Kundenbetrachtung eine Aktionsaussendung mit den auslaufenden Titeln zu einem Sonderpreis an unsere besten Kunden verschicken. Dazu betrachten wir zunächst einmal unsere Kunden unter dem Gesichtspunkt Gesamtumsatz und Region:

Unsere "besten" Kunden 1

Hieraus ergibt sich keine klare Verteilung der wichtigen Kunden in bestimmten Bundesländern, aber eine klare Reihung nach dem bisher getätigten Gesamtumsatz.
Der Gesamtumsatz soll mir hier aber nicht als Kennzahl reichen, ich möchte die Kunden eher nach der Menge ihrer Aufträge (Loyalität) und den dabei durchschnittlich getätigten Einkaufsvolumina (nachhaltige Umsätze) bewerten:

Unsere "besten" Kunden 2

Nachdem sich hier eine, für die aktuellen Zwecke eines Aktionsangebots, relativ lange Liste ergibt, füge ich nun noch eine kleine Einschränkung auf Kunden die bisher zumindest 50 Aufträge ersteilt haben ein:

Unsere "besten" Kunden 3

Nun habe ich also die potenziellen Kunden für die "Ladenhüter-Aktion" gefunden, und es fehlen nur noch die passenden Bücher für die Aktion.
Nach kurzer Ansicht des Bücherbestands beschränke ich mich auf alle auslaufenden Werke von denen mindestens 50 Stück lagernd sind:

Unsere Ladenhüter

Nun haben wir eine große Auswahl and "Ladenhütern" gefunden, die wir in einem Aktionsangebot zu einem Sonderpreis an unsere ausgewählten Kunden bringen können.

"Als Datenbank ist eine organisierte Zusammenstellung von Daten zu verstehen."
( http://www.computerlexikon.com/begriff-datenbanken, dld 19.102007)

"Die Organisation der Daten umfasst deren Speicherung, Formatierung, Verwaltung, Zugriff, Manipulation und Darstellung in konsistenter Form."
( http://www.itwissen.info/?id=31&ano=01-004121, dld 20.10.2007)

Ein solches elektronisches Datenarchiv, das sich durch einen raschen Zugriff und eine Platz sparende Aufbewahrung großer Datenmengen auszeichnet, kann nach variablem Ordnungsschema einzeln oder verknüpft sowohl für den Dialogbetrieb als auch für die Stapelverarbeitung ausgelegt sein. Man unterscheidet die Anordnung der Daten unter Berücksichtigung der optimalen Speichernutzung und die logische Datenstruktur, die sich aus der Beziehungen zwischen zusammengehörigen Daten ergibt. Dadurch werden Daten unabhängig von den Anforderungen an ihre jeweilige Anwendung nach einheitlichen Gesichtspunkten verwaltet.
Eine Datenbank kann von mehreren Anwendern und Programmen gemeinsam genutzt werden und je nach Strukturierung und Anwendung der Datenbank kann zB zwischen verteilten Datenbanken, relationalen Datenbanken, öffentlichen oder objektorientierten Datenbanken unterschieden werden.
(vgl http://www.itwissen.info/?id=31&ano=01-004121, dld 20.10.2007)

Mit dem Einzug der Informationstechnologie in die verschiedensten Bereiche wirtschaftlicher Organisationen entwickelte sich ein individualistisches System einzelner Datensysteme mit starker Redundanz bei grundlegenden Daten. Moderne relationale Datenbanken und komplexe Datenbankmanagementsysteme ermöglichen es nun Doppelgleisigkeiten zu vermeiden, einen gemeinsamen Datenstock zur Verfügung zu stellen und trotzdem dem Anwender eine individuell zugeschnittene Frontend-Benutzeroberfläche zu bieten. Gerade bei den klar strukturierten und linearen Prozessen eines Betriebes (Rechnungslegung, Kundeninformationen, Lagerhaltung, …) entstehen so große Kosten-, Zeit- und damit Effizienzvorteile.

Mit der zunehmenden Bedeutung derartiger DB-Lösungen in den unterschiedlichsten Bereichen des Wirtschaftslebens ist es allerdings auch wichtig sich im Klaren zu sein, dass es Informationen, Prozesse, .. gibt die nicht (vollständig) in Form einer Datenbank erfasst werden können und sich zB ein DBMS dem Unternehmen und nicht umgekehrt anpassen sollte.