Bei meinem Resümee der in der Lehrveranstaltung behandelten Themen wurde ich besonders auf jene Gebiete aufmerksam, welche sich mit Zusatzleistungen für Kunden und Interessenten beschäftigten. Um diese Aspekte angewendet auf das Geschäftsmodell des fiktiven Schulbuchhandels umzulegen habe ich einige Überlegungen angestellt die ich in diesem Beitrag erläutern möchte.


Peer Review

Um den Informationsgehalt unseres Buchhandels für die Kunden zu erhöhen, wäre es sicher von Vorteil diesen ein so genanntes Peer Review zu ermöglichen. Dabei handelt es sich um die Bewertung der verschiedenen Bücher durch unsere Kunden (Schulen, Lehrer) welche für alle anderen Interessenten zur Verfügung gestellt werden. Angenommen man interessiert sich für das Buch „Welt der Chemie“, weiß aber nicht genau wie hochwertig der qualitative Inhalt des Buches ist. In diesem Fall wäre es für den Interessenten äußerst nützlich, wenn er die Kritik von Kollegen und anderen Schulen als Hilfestellung heranziehen könnte. Um dies gewährleisten zu können müsste der Schulbuchhandel um eine Plattform erweitert werden, auf der eine solche Bewertung online Möglich ist (Homepage). Das Internet hat ja die zu früheren Zeiten ausschließende Beziehung zwischen Informationsgehalt und Breitenwirkung entschärft und mit Hilfe von Multimediafähigkeit von Internet und Web können Unternehmen, wie auch der Schulbuchhandel kundenspezifische und detaillierte Produktinformationen gleichzeitig einer sehr hohen Anzahl von Personen zugänglich machen. So auch beim Peer Review, welches ermöglicht für jedes Produkt eine gezielte Kritik zu erreichen. Natürlich setzte ich voraus, dass die Kunden in unserem Netzwerk nicht nur die Kritiken abrufen sondern auch selbst die jeweiligen von Ihnen gekauften Bücher beurteilen und dies kundtun. Das Peer Review sollte dann als roter Faden für die Kunden dienen, um diesen eine Orientierung und Hilfestellung beim Kauf zu ermöglichen.


Add-On

Bei einem weiteren Aspekt, welcher mir im Zusammenhang mit den Zusatzleistungen für Abnehmer eingefallen ist handelt es sich um so genannte Add-Ons. Ich verstehe in diesem Zusammenhang zusätzliche Leistungen wie eine Schülerliste, welche alle Schüler enthält die das jeweilige Buch bekommen sollen. Wir müssten unsere Datenbank um die gesamten Schüler erweitern, damit eine solche Zusatzleistung möglich ist. Wenn die Namen aber einmal in der Datenbank gespeichert sind, ist es für die Lehrkräfte eine wesentliche Erleichterung, wenn sie bei der Lieferung nur mehr die mitgeschickte Liste zur Hand nehmen brauchen und auf einen Blick wissen, wer das Buch bekommt und wer nicht. Die Lehrer ersparen sich dadurch viel Zeit und haben durch die Add-Ons alles unter Kontrolle. Die Zusatzleistung bedarf wie schon angesprochen der Ermittlung der Schülernamen und die Speicherung dieser in unserer Datenbank, was rechtlich in Ordnung geht da wir ja einen genauen Grund für diese Erhebung angeben können.


Newsletter bzw. Forum

Auch ein so genannter Newsletter könnte als Zusatzleistung angeboten werden. Alle speziellen Angebote und Neuerungen würden in diesem zusammengefasst und per Mail versandt. Die Kunden wären so immer am aktuellen Stand und für all jene die noch Zusatzinfos oder ähnliches brauchen könnte darüber hinaus ein Forum auf der Homepage eingerichtet werden. So würde auch ein direkter Kontakt zwischen den Kunden entstehen der eine sinnvolle Ergänzung zum Peer Review bietet. Wenn beispielsweise ein Buch sehr gut bewertet wurde, man aber von Kunden die dieses bereits verwendet haben noch genauere Kritikpunkte (positiv wie negativ) einholen möchte.

Bei meinem Resümee wurde ich also auf Informationslücken bzw. die Verbesserung der Information aufmerksam und denke mit den gesetzten Schritten (Peer Review, Add-On, Newsletter bzw. Forum) ein gutes Upgrade bewirkt zu haben.


Kosequenzen für den Buchhandel

Um die angesprochenen Zusatzleistungen zu ermöglichen müsste unser Schulbuchhandel angepasst werden. Für das Peer Review wäre eine Plattform sprich Homepage von Nöten, von der aus man dann auch die Newsletter und Foren bereitstellen könnte. Darüber hinaus müsste das ER-Modell um eine Entität erweitert werden. Ich würde diese Entität "Schüler" nennen und in diese Attribute wie Name der Schüler, Klasse, Schulstufe, Schule usw. aufnehmen. Dadruch wäre es möglich, für die jeweiligen Lehrer eine Liste zu erstellen, auf der alle Schüler angeführt sind, die das jeweilige Buch bekommen, also ein Add-On (Zusatzleistung) bei der Lieferung. In die Entität könnte man auch Attribute wie Präferenzen der Schüler aufnehmen, um die richtigen Newsletter an die jeweiligen Lehrer weiterzuleiten die diese dann den Schülern bei Interesse weiterleiten können. Es wäre also eine enorme Verbesserung der Zusatzleistungen für unsere Kunden, also Lehrer und auch Schüler!

Das in der Lehrveranstaltung bearbeitete ER(Entity Relationship)-Diagramm ist ein Modell, welches mit Hilfe eines fiktiven Buchhandels den Aufbau einer relationalen Datenbank und die dafür benötigten Daten beschreibt.




In diesem Modell gibt es verschiedene Elemente die gegenseitig in Beziehung stehen. Zunächst benötigt man einmal Entitäten, die hier mit Hilfe von Rechtecken dargestellt sind. Die verwendeten Entitäten im Modell des Buchhandels sind Kunde, Auftrag, Buch und Verlag.

Jeder dieser vier Entitäten sind Attribute zugeordnet, die in einem Oval dargestellt werden. Die Attribute dienen dazu, die jeweiligen Entitäten besser zu beschreiben. Bei der Entität Kunde sind dies Dinge wie Vorname, Nachname, die Adresse und die Kundennummer. Würde man genauere Information des Kunden benötigen könnte man weitere Attribute hinzufügen. Ich denke in diesem Zusammenhang an Dinge wie das Geschlecht oder vielleicht das Geburtsdatum. Das Ganze würde ich für eine sehr sinnvolle Erweiterung halten. Solche Informationen könnten verwendet werden, wenn man mit einem Buch zum Beispiel eine gewisse Generation ansprechen möchte. Wäre die Entität Kunde um diese Attribute erweitert, könnte man beispielsweise auch alle Kundinnen herausfiltern, wenn man nur diese braucht. Weitere Attribute könnten auch Dinge wie Handy- oder Festnetznummer sein, um den Kunden auch telefonisch kontaktieren zu könne. Dies sind nur einige Beispiele die ich in diesem Zusammenhang nennen möchte, natürlich könnte man jede Entität x-beliebig erweitern. Eine Frage die sich hier stellt ist, wie gern die Kunden solche, teilweise eher persönliche Daten hergeben.

Die einzelnen zuvor beschriebenen Entitäten sind mit Hilfe von so genannten Beziehungen miteinander verbunden, welche als Rauten dargestellt werden. Unterschieden werden im Modell des Buchhandels die „erteilt“, „über“ bzw. die „verlegt“ Beziehung. Die 1:n Beziehung „verlegt“ zwischen den Entitäten Verlag und Buch sagt beispielsweise aus, dass jedem Verlag (1) beliebig viele Bücher (n) zugeordnet sein können. Umgekehrt ist dies logischerweise nicht möglich, denn wie sollte es funktionieren wenn jedes Buch verschiedenen Verlagen zugeordnet werden könnte. Es würde zu Problemen führen, denn für gewöhnlich kommt es nicht vor, dass zwei verschiedene Verlage ein und dasselbe Buch verlegen. Dasselbe ist es bei der Beziehung „erteilt“ zwischen den Entitäten Kunde und Auftrag. Es kann jeder Auftrag auch immer nur einem Kunden zugewiesen sein während es umgekehrt natürlich möglich ist, dass ein und derselbe Klient mehrer Aufträge tätigt.

Zwischen den Entitäten Auftrag und Buch herrscht überhaupt eine n:m Beziehung, welche bedeutet, dass sowohl mehrere Bücher in einem Auftrag enthalten sein können als auch umgekehrt mehrere Aufträge einem Buch zugeordnet sein können.


Um die Beziehungen zu prüfen habe ich im vorliegenden Fall auf SQL.IDV.EDU folgenden Befehl eingegeben:

Select a.Nr,count(b.titel)
from Auftrag a, Buch b, Auftragspos au where a.Nr=au.Auftragsnummer and au.Buchnummer=b.Nr
group by a.Nr

Das Ergebnis zeigt, dass beispielsweise dem Auftrag Nr. 1 nicht nur ein Titel sondern wie der n:m Beziehung entsprechend mehrere, genauer gesagt im betreffenden Fall 14 verschiedene Titel zugeordnet sind.

Um die angesprochene Beziehung auch umgekehrt zu prüfen verwendete ich folgende Abfrage

Select b.Nr,count(a.Nr)as "Anzahl der Aufträge"
from Auftrag a, Buch b, Auftragspos au
where a.Nr=au.Auftragsnummer
and au.Buchnummer=b.Nr group by b.Nr

Diese zeigt deutlich, dass auch jeder Buchnummer mehrere Aufträge zugeordnet sein können. Bei der Buchnummer 5 sind es beispielsweise 6 zugeordnete Aufträge. Die n:m Beziehung zwischen den Entitäten Auftrag und Buch hat also funktioniert.