Nachdem ich eigentlich für die IV2-Einheit am letzen Mi einiges zum Thema Datenschutz vorbereitet gehabt hätte, uns aber dann ja leider der Herr Prof. Mittendorfer krank aus Berlin heimgekommen ist, will ich nun einige der aktuellen Links und Infos hier zur Verfügung stellen.

"Speed kills Datenschutz" - Eingriffe in ein Menschenrecht

In der letzten Zeit wird in D und Ö viel um das Thema Datenschutz im Bezug auf die Vorratsdatenspeicherung, den sog. "Bundestrojaner" und die Zugriffsrechte der Exekutive diskutiert.
In diesem Zusammenhang möchte ich auf eine rechtliche Grundlage des Datenschutzes in Europa kommen - die Europäische Menschenrechtskonvention (EMRK).

Hier heißt es in Artikel 8 Abs 1: „Jedermann hat Anspruch auf Achtung seines Privat und Familienlebens, seiner Wohnung und seines Briefverkehrs.“

Weiters finden wir in Absatz 2 einen sog. „formellen Eingriffsvorbehalt“, was bedeutet, dass Eingriffe in dieses Grundrecht auf persönlichen Schutz der Privatsphäre (Datenschutz) nur aufgrund eines Gesetzes geschehen dürfen. Grundsätzlich ist - wie bei vielen ähnlichen Gesetzesgrundlagen - davon auszugehen, dass diese Notwendigkeit Eingriffe in das Grundrecht vorzunehmen prinzipiell sehr restriktiv zu interpretieren ist.

Mit Blick auf diese Tatsache ist es nun sehr interessant, dass in den letzten Tagen und Wochen doch schon sehr viele neue Zugriffsrechte im Bezug auf den persönlichen Datenschutz mit dem neuen Sicherheitspolizeigesetz (SPG) geschaffen wurden - ohne zu erklären wo jetzt genau die besondere kritische Notwendigkeit des Eingriffs in ein EU-Grundrecht liegt, bzw. teilweise sogar ohne ausführliche politische oder öffentliche Diskussion oder sogar auch ohne Kontrolle durch die Datenschutzkommission (DSK).

Hierzu einige Links:

ORF - Datenschützer warnen

ORF - SPG erlaubt Zugriff auf die Standortdaten

ORF - Regierung will Zugriff auf die IP

ORF - SPG-IP-Zugriff an den Kontrollinstanzen vorbei

HEISE - Neue Überwachungsrechte für Polizei in Österreich (sogar in D bemerkt man das hier etwas "besonderes" passiert)

HEISE - Neues SPG in Ö in der Kritik

passende Links zu Kollegen-Blogs bei Collabor:

Hans Mittendorfer - Privacy

Elisabeth Schachtner - Datenschutz und Urheberrecht

Martin Reiter - Social Networking

Carina Binder - Verschlüsselung mit PGP

Andrea Guschlbauer - Der gläserne Mensch

Milan Vidovic - Sicherheitspolizeigesetz

Bernhard Kellner - Datenschutz

...
Teil II folgt dann entweder auch hier oder in einer der Jänner-LVas, schöne Grüße, fa

Nachdem es nun in der neuen Datenbank vollständige Auftragsdaten für das Geschäftsjahr 2006 gibt , wollen wir uns hier einmal einige Informationen ansehen:

(Achtung: man muss sich bei der 1. Abfrage mit BN und PW an der neuen DB anmelden)

Kundenumsätze 2006
Umsatz Bundesländer 2006
Umsatz Monate 2006

Nun noch eine individuell zu konfigurierende Abfrage zu den Monats- und Jahresumsätzen der Bundesländer:

Geben Sie das gewünschte Jahr (zB 2006) ein [Sollten Sie die Werte aller Jahre wünschen, geben Sie bitte % ein]

Geben Sie das gewünschte Monat (zB 01) ein [Sollten Sie die Werte aller Monate wünschen, geben Sie bitte % ein]

und das gewünschte Bundesland
Tirol
Vorarlberg
Kärnten
Oberösterreich
Niederösterreich
Wien
Steiermark
Salzburg
Burgenland


und dann

... to be continued ...

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