Nachdem nun in der Vergangenheit willkürliche SQL-Abfragen getätigt wurden, möchte ich in diesem Beitrag einige Abfragevarianten vorstellen, die in der Betriebswirschaft durchaus Relevanz besitzen.
Es handelt sich dabei um die Abfrage bestimmter Kennzahlen, denen ein bestimmter Hintergrund zugrunde liegt und die dazu verwendet werden können, um etwaige Marketingmaßnahmen abzuleiten, seine Position gegenüber Lieferanten zu stärken oder bestimmte Umsatzkennzahlen für spezielle Regionen zu ermitteln.

Nach jeder SQL-Abfrage werde ich den theoretischen Background erklären, um die Sinnhaftigkeit der Abfrage zu untermauern.

ANMERKUNG: Da ich im letzten Tutorium leider nicht anwesend sein konnte, weil ich arbeiten musste, habe ich versucht, die SQL-Einbindung anhand des HTML-Formates auf der IDV-HP einzubinden. Ich habe diese HTML-Formatierungen der Abfrage in den Webblog kopiert und nur die Abfragen geändert. Dennoch funktionieren die Abfragen per Button-Click nicht. Die Ursache hierfür konnte ich nicht ermitteln.
Es ist dennoch möglich die Abfrage zu tätigen, indem man die angeführten SQL-Abfragen in die Lehrdatenbank kopiert und so deren Ausführung überprüft.

Und nun viel Spass bei den nachfolgenden Abfragen:

Abfrage 1: Umsätze der einzelnen Kunden in absteigender Reihenfolge

Select Vorname, Nachname, Strasse, Plz, sum(Preis*Menge)as Umsatz from Kunde, Auftrag, Auftragspos, Buch where Kunde.Nr = Auftrag.Kundennummer and Auftrag.Nr = Auftragspos.Auftragsnummer and Auftragspos.Buchnummer = Buch.Nr group by Kunde.Nr order by Umsatz desc

Diese Abfrage dient dazu, um die Umsätze der einzelnen Kunde in absteigender Reihenfolge zu ermitteln. Dies kann z.B. dazu genutzt werden, um die besten Kunden mit einem Treuebonus zu belohnen.

Abfrage 2: Anzahl der verkauften Exemplare je Buch absteigend

Select Buch.*, count(Menge) as Anzahl from Buch, Auftragspos, Auftrag where Auftragspos.Buchnummer = Buch.Nr and Auftrag.Nr = Auftragspos.Auftragsnummer group by Auftragspos.Buchnummer order by Anzahl desc

Diese Liste kann dazu genutzt werden um Bestseller bzw. Ladenhüter zu eruieren. Ladenhüter könnten entweder komplett aus dem Sortiment entfernt werden oder um deren Verkauf durch adequate Marketing-Maßnahmen anzukurbeln.

Abfrage 3: Umsatzstärkste Bundesländer absteigend

select Region, sum(Menge*Preis) as Umsatz from PLZ, Kunde, Auftrag, Auftragspos, Buch where PLZ.Plz=Kunde.Plz and Kunde.Nr=Auftrag.Kundennummer and Auftrag.Nr=Auftragspos.Auftragsnummer and Auftragspos.Buchnummer=Buch.Nr group by PLZ.Region order by Umsatz desc

Diese Abfrage dient der Ermittlung der Umsatzstärke in den einzelnen Bundesländern. Bei den Schwächeren könnte man z.B. die Marketingaktivitäten ausweiten, da hier das Potential vermutlich noch nicht ausgeschöpft ist.

Abfrage 4: Anzahl der Aufträge je Kunde absteigend

select Vorname, Nachname, count(Auftrag.Nr)as "Anzahl der Aufträge" from Kunde, Auftrag where Kunde.Nr=Auftrag.Kundennummer group by Kunde.Nr order by "Anzahl der Aufträge" desc

Hier ist deutlich ersichtlich, welche Kunden die meisten Aufträge an uns erteilen. Auch hier könnte man gegebenenfalls bei den Stärksten ein Belohnungssystem einführen, bzw. bei den Schwächeren durch besondere Angebote versuchen, die Auftragsanzahl zu erhöhen.

Abfrage 5: Die stärksten Kunden je Region absteigend

select Vorname, Nachname, max(Menge*Preis) as Umsatz, Region from Kunde, Auftrag, Auftragspos, Buch, PLZ where PLZ.Plz=Kunde.Plz and Kunde.Nr=Auftrag.Kundennummer and Auftrag.Nr=Auftragspos.Auftragsnummer and Auftragspos.Buchnummer=Buch.Nr group by PLZ.Region order by Umsatz desc

Bei dieser Abfrage erhält man den sog. Topseller je Bundesland. Diese Information kann für Aussendienstmitarbeiter wichtig sein.

Abfrage 6: Welcher Verlag hat die meisten Bücher im Sortiment absteigend

select Verlag.*, count(Buch.Nr) as Anzahl from Verlag, Buch where Buch.Verlag=Verlag.Kurzbezeichnung group by Verlag.Kurzbezeichnung order by Anzahl desc

Diese Abfrage zeigt die Anzahl der Bücher pro Verlag, welche wir in unserem Sortiment führen. Dies kann wichtig sein für unsere Verhandlungsmacht mit dem Lieferanten. Es können bessere Konditionen für uns verhandelt werden, wenn wir sagen können, dass wir so und soviele Bücher regelmäßig bei diesem Beziehen und somit einen wichtigen Kunden für ihn darstellen.

Überlegungen zum ER-Modell

Um das ER-Modell diskutieren zu können, ist es zunächst einmal essentiell, dieses kurz zu skizzieren und dessen Zweck zu erläutern, um den anschließenden Gedankengängen folgen zu können.
Dabei werde ich versuchen, dieses so einfach wie möglich abzuhandeln und mit Beispielen zu unterlegen, um das Verständnis desselben zu erleichtern.

Erklärung des ER-Modell
Die Bezeichnung ER-Modell leitet sich aus den englischen Begriffen Entity (= Entität) und Relationship (= Beziehung) ab. Es handelt sich hierbei um die graphische Umsetzung des Aufbaus einer Datenbank. Die betrieblichen Abläufe werden dabei, in einem ersten Schritt, von Wirtschaftlern analysiert, da diese mit den Abläufen im Betrieb vertraut sind und danach von Informatikern in eine relationale Datenbank umgesetzt.
Ziel ist es eine Datenbank zu generieren, bei der die Redundanzen (= Mehrfacheinträge inhaltsgleicher Bedeutung) minimiert werden, um bei eventuellen Änderungen (z.B. Änderung einer Wohnadresse) diese Änderung nur 1x in der Datenbank verändert werden muss und danach automatisch auf alle Datenbereiche übertragen wird.
Es könnte sonst vorkommen, dass z.B. beim Schreiben einer Rechnung die Adresse zwar geändert wird , aber bei einer darauf folgenden Mailing-Aktion die alte Adresse wieder in der Adressatenliste aufscheint, weil die Redundanz nicht gegeben war. Dies soll ein ER-Modell vermeiden.
Die nachfolgende Grafik veranschaulicht ein solches Modell anhand eines Buchhandels.



Auf die einzelnen graphischen Elemente des ER-Modell wird nun nachfolgend näher eingegangen.

Entität
Als Entität bezeichnet man hierbei Objekte der Wirklichkeit in Form materieller oder immaterieller (abstrakter) Art. Entitäten könnten beispielsweise folgende Bezeichnungen tragen: Buch, Kunde, Verlag, Angestellter, Auftrag, Projekt, etc. Die Entitäten sind als rechteckige Kästchen gekennzeichnet.

Attribute
Jede Entität ist durch bestimmte Attribute gekennzeichnet, welche Elementarinformationen derselben darstellen. Dies können z.B. bei der Entität „Verlag“ folgende Informationen sein: Ort, PLZ, Straße, Kundennummer, Name, Kurzbezeichnung. Gekennzeichnet werden diese Attribute mit einer ovalen Blase.

Jeder der Entitäten besitzt mindestens einen Primärschlüssel (=Schlüsselattribut). Dies ist eine Eigenschaft, durch welche sich die Entität eindeutig identifizieren lässt. Als Beispiele können hier unter andere folgende Beispiele herangezogen werden (vgl. obige Grafik).

Entität „Kunde“: Kundennummer als Primärschlüssel
Jeder Kunde hat eine eigene Kundennummer, welche nur ein einziges Mal an einen Kunden vergeben wird. Er ist dadurch eindeutig identifiziert.

Die Attribute Ort, PLZ, Straße, Nachname und Vorname eignen sich aus den folgenden Gründen nicht als Primärschlüssel.

Ort: Verschiedene Kunden können im gleichen Ort wohnhaft sein.
Straße: Verschiedene Kunden können in der gleichen Straße wohnhaft sein.
PLZ: Verschiedene Kunden können unter der gleichen PLZ wohnhaft sein.
Vorname: Mehrere Kunden können den gleichen Vornamen besitzen.
Nachname: Mehrere Kunden können den gleichen Nachnamen besitzen.

Verwechslungen könnten daher nicht ausgeschlossen werden.

Entität „Auftrag“: Nr als Primärschlüssel
Jeder Auftrag trägt eine fortlaufende Nummer, welche nur ein einziges Mal vergeben werden kann. Auch hier wird die eindeutige Identität gewahrt.

Die Attribute Kundennummer und Datum erscheinen hierbei als Schlüsselattribute ungeeignet.

Kundennummer: Es können mehrere Aufträge von ein und demselben Kunden in Auftrag gegeben werden.
Datum: Es können mehrere Aufträge zum selben Datum eingehen.

Entität „Buch“: Nr als Primärschlüssel
Jedes Buch bekommt eine fortlaufende Nummer, sobald es in das Sortiment aufgenommen wird. Diese wird, genauso wie bei den beiden vorangegangenen Beispielen, nur ein einziges Mal vergeben, d.h. es kann ausgeschlossen werden, dass zwei verschiedene Bücher die gleiche Buchnummer besitzen. Auch hier wird eine eindeutige Identifikationsmöglichkeit gegeben.

Die Attribute Autor, Titel, Preis, Verlag, Auslaufend und Bestand sind aus den nachfolgend angeführten Begründungen nicht als Primärschlüssel geeignet.

Autor: Es können mehrere Bücher von ein und demselben Autor existieren.
Titel: Es könnte vorkommen, dass zwei oder mehrere Autoren ein Buch mit demselben Titel auf den Markt bringen (vom Copyright-Schutz mal abgesehen).
Preis: Es besteht die Möglichkeit, dass verschieden Bücher einen identischen Preis aufweisen.
Verlag:Es besteht die Möglichkeit, dass ein und dasselbe Buch von mehreren Verlagen bezogen werden kann.
Auslaufend: Die Anzahl der auslaufenden Bücher ist variabel, wodurch die Zuordnung auf ein bestimmtes Buch nicht mehr gegeben ist.
Bestand: Auch der Bestand ist variabel und es kann vorkommen, dass von verschiedenen Büchern die gleiche Anzahl vorhanden ist.

Entität „Verlag“: Kurzbezeichnung als Primärschlüssel
Es wird davon ausgegangen, dass an jeden Verlag eine einzigartige Kurzbezeichnung vergeben wird, welche kein anderer Verlag besitzt.

Kritische Anmerkung: Hier wäre vielleicht die Vergabe einer Nummer, wie bei den anderen Entitäten, eine adäquatere Methode, da es eventuell passieren kann, dass zwei verschiedenen Verlagen, welche eine ähnlich Namensgebung aufweisen, die gleiche Kurzbezeichnung zuerkannt wird, sofern dies (z.B. EDV-mäßig) nicht überprüft wird.

Die Attribute Name, Kundennummer, Straße, PLZ, Ort sind aus folgenden Gründen nicht als Schlüsselattribut geeignet:

Name: Es können mehrere Verlage mit dem gleichen Namen existieren. Dies könnte im Speziellen dann sein, wenn ein Verlag mehrere Niederlassungen besitzt.
Kundennummer: Jeder Verlag besitzt in der Regel mehrer Kunden und daher auch mehrere Kundennummern.
Straße: Es besteht die Möglichkeit, dass zwei oder mehrere Verlage in der gleichen Straße angesiedelt sind.
PLZ: Es besteht die Möglichkeit, dass zwei oder mehrere Verlage unter der gleichen PLZ angesiedelt sind.
Ort: Es besteht die Möglichkeit, dass zwei oder mehrere Verlage im gleichen Ort angesiedelt sind.

Aus den Erläuterungen wird nun klar, dass als Primärschlüssel bzw. Schlüsselattribut nur jene Eigenschaften herangezogen werden können, welche eine Entität eindeutig beschreiben können. Sie sind daher, genauso wie die Attribute, streng mit der Entität verknüpft. Gekennzeichnet werden diese Attribute als eine ovale Blase mit einem Unterstrich, welcher die Eigenschaft als Schlüsselattribut hervorheben soll.

Merksatz: Schlüsselattribute können nur jene Attribute sein, welche eine Entität auf eindeutige Art und Weise beschreiben können.

Beziehungen
Beziehungen dienen dazu, um Entität miteinander zu verknüpfen, d.h. sie stehen in einer bestimmten Beziehung miteinander. In unserem Buchhandelsbeispiel könnten die Beziehungen folgendermaßen formuliert werden:

Kunde erteilt uns einen Auftrag: Die Beziehung zwischen Kunde und Auftrag ist die „Erteilung“ desselben.

Der Auftrag lautet 1 Stück des Buches „X“: Die Beziehung zwischen Auftrag und Buch ist die Order „über“ 1 Buch X.

Das Buch X wird vom Verlag Y verlegt: Die Beziehung zwischen Buch und Verlag ist dessen „Verlegung“.

Auch Beziehungen können Attribute aufweisen, welche die Beziehung näher erklären sollen. In unserem Beispiel hat die Beziehung „über“ die Attribute Menge und Nr. Ob eine Beziehung Attribute enthält oder nicht, ergibt sich aus dem logistischen Ablauf der Unternehmung.
Die Menge kann sich hierbei z.B. auf die Anzahl eines georderten Buches in der Auftragsposition 1 beziehen und die Nr auf eine gegebenenfalls erwünscht Reihenfolge.

Arten von Beziehungen
Entitäten können auf verschieden Arten miteinander in Beziehung stehen. Die nachfolgenden Erklärungen sollen dies zum besseren Verständnis erläutern.

1:1 Beziehung: Eine Entität 1 steht einer Entität 2 gegenüber (E1:E2 = 1:1)

In diesem Beispiel gibt es keine 1:1 Beziehung, aber man könnte z.B. ein Preisausschreiben anführen. Jeder Teilnehmenden darf nur mit einer Karte am Preisausschreiben mitmachen und jede Karte kann daher auch nur einem Teilnehmenden zugeordnet werden.

1:n Beziehung: Eine Entität 1 steht n Entitäten 2 gegenüber (E1:E2 = 1:n)

Als Beispiel sei hier auf den Buchhandel Bezug genommen:
Ein Kunde (1) kann mehrere Aufträge (n) in Auftrag geben und mehrere Aufträge (n) können von einem Kunden (1) kommen.

n:m Beziehung: Mehrere (n) Entitäten 1 stehen mehreren (m) Entitäten 2 gegenüber (E1:E2 = n:m)

Beispiel Auftrag und Buch:
Mehrere Aufträge (n) können sich auf mehrere Bücher (m) beziehen und mehrere Bücher (m) können auf mehreren Aufträgen (n) aufscheinen.

Gekennzeichnet werden Beziehungen mit Rauten.
Nachfolgende Grafik fasst diese Darstellungsformen noch einmal zusammen.



Kritischer Diskurs zum ER-Modell

Redundanzen
Wie in der Einleitung erwähnt ist es das Ziel Redundanzen zu minimieren. Im vorliegenden Beispiel befinden sich jedoch noch einige Mehrfachnennungen (z.B. PLZ, Ort). Diese könnten gegebenenfalls noch in eine extra Tabelle ausgelagert werden, da die PLZ direkt mit dem Ort verknüpft ist. Auch die Straße kommt doppelt vor. Hier muss aber kritisch darauf hingewiesen werden, dass es Straßennamen gibt, welche in mehreren Gemeinden, Städten und Orten, gleich lauten!!

Normalisierung von Beziehungen
Im gegebenen Beispiel gibt es noch n:m Beziehungen. Ziel ist es aber, ein Datenbank-Modell zu generieren, bei welchem n:m Beziehungen vermieden werden. Hier könnte gegebenenfalls noch etwas geändert werden.

Zusätzliche Attribute
Zusätzliche Attribute bei einigen Entitäten könnten noch mehr Möglichkeiten der Datenabfrage ermöglichen. Dies hängt natürlich immer mit dem Zweck (welche Informationen brauch ich unbedingt). Zusammen. Je mehr Daten natürlich verwaltet werden, desto arbeitsintensiver ist auch die „Wartung“ der Datenbank. Ich möchte dennoch ein paar Beispiele erwähnen:

Entität Buch: z.B. das Gewicht für Transportkosteninformationen
Entität Kunde: z.B. Geburtsdatum für kleine Geburtstagspräsente
Entität Verlag: z.B. die Dauer der der Zusammenarbeit für etwaige Dankeschön-Präsente

Willkommen auf meinem persönlichen Webblog!

Dieser wurde im Zuge der LVA "Informationsverarbeitung 2" im WS 2006/07 eingerichtet und dient zum Publizieren der dort abgehandelten Themen.

Viel Spass beim Durchlesen :-)

Jürgen