Business und Internet - WS 2009/10
Samstag, 14. Juni 2008
Probeklausur - Ausarbeitung
christian.weinzinger.Uni-Linz, Samstag, 14. Juni 2008, 11:58
Hier meine Ausarbeitung der Probeklausur:

probeklausur (xlsx, 21 KB)

Permalink (0 Kommentare)   Kommentieren



Freitag, 13. Juni 2008
Redesign Geschäftsmodell
christian.weinzinger.Uni-Linz, Freitag, 13. Juni 2008, 16:17
Im Rahmen des Redesigns des Geschäftsmodells des Buchhandels werden ich nun einige Punkte aufgreifen, die ich an der bisherigen Situation ändern würde bzw. die ich (da noch nicht vorhanden) einführen würde.

Der Web-Auftritt:

Der erste Eindruck zählt. Somit ist der Webauftritt und die ersten Ansicht der Website ein sehr wichtiges Mittel um potenzielle Kunden auch auf der Seite zu behalten. Somit wäre es immens wichtig für den Buchhandel ein markantes Logo zu entwerfen, das sich in den Köpfen der Kunden einprägt. Das Logo sollte farbig sein - es sollte allerdings nicht zu verschnörkelt sein. Ein Beispiel für ein markantes Logo, das schlicht gehalten ist ist das von Google.

Des Weiteren sollte die Homepage - abgesehen vom Logo - eher schlicht gehalten werden. Sie sollte somit auch Geschäftskunden ansprechen. Es gibt nämlich nichts schlimmeres als auf eine Homepage zu kommen, die aussieht wie ein Kindergartenmalheft.
Man könnte durch ein ansprechendes blau ein wenig "Kompetenz" (für das steht blau nämlich bei Firmen) hineinbringen.

Unbedingt enthalten sollte die Website Frames, die es ermöglichen wichtige Informationen und Links immer sichbar zu halten immer sichtbar zu halten. (vgl. dazu den Link der Linz AG).

Datenhaltung und -organisation:

Die Datenhaltung sollte weiterhin mittels MySQL-Datenbank realisiert bleiben. Die Anfrage an die Datenbank funktioniert mit verschiedensten SQL-Konnektoren und verschiedensten Programmiersprachen (zu denen komme ich später noch). Weiters stellt die MySQL-Datenbank alle Funktionalitäten zur Verfügung, die für eine effiziente Abfrage und Auswertung von Anfragen via Internet gebraucht werden. Des weiteren kann auf diese Datenbank auch von den Mitarbeiter selbst zugegriffen werden (unabhängig von Internet und Standort). Die Datenbank sollte die operativen Daten für den täglichen Betrieb enthalten, bzgl Abfragemöglichkeiten aus dem Netz aber nur gewisse Informationen preisgeben.
Als Anfragesprache macht in diesem Zusammenhang nur SQL Sinn.

Programmiersprachen:

Als Programmiersprache, in der die Website erstellt wird würde ich (abgesehen von HTML) entweder JSP (Java Server Pages) oder ASP (Active Server Pages) vorschlagen. Diese beiden Konzepte ermöglich die flexible und dynamische Erstellung von Informationen die auf der Website dargestellt werden sollen. Es sind damit auch Prüfungen der Konsitenz der Eingaben etc. im Vorfeld der Anfrage an die Datenbank möglich, was den Netzverkehr extrem einschränkt und zu einer schnelleren und sicherern Nutzung führt.

Ich könnte mir auch noch vorstellen, wenn man JSP oder ASP nicht verwenden möchte, dass man das ganze mit den prozeduralen Programmiersprachen JavaScript oder PHP löst.

Kommunikation mit Geschäftskunden:

Die Kommunikation mit den Geschäftskunden sollte mittels XML-Schnittstelle abgewickelt werden. Es gibt standardisierte XML-Schemata für den Buchhandel. Somit könnten die Geschäfts- und Großkunden mittels vorgefertigter Eingabemaske schnell und leicht Bestellungen aufgeben, die hausintern nicht mehr geprüft werden müssen, da nur die relavanten Informationen in der richten Form und im richtigen Format als XML-File ankommen. Somit können die Bestellungen ohne Probleme automatisch ins System eingelesen werden. Man müsste aber für die Eingabemaske einen XML-Parser (XML-Übersetzer) implementieren, dir die entsprechenden Eingaben prüft und daraus ein XML-File erstellt.

Besondere Features:

Account
Es MUSS fast schon möglich sein sich an der Homepage als Benutzer zu registieren. Diese Registrierung hat sowohl für den User als auch für uns immense Vorteile.
Zum einen kann der User nur einkaufen, wenn er am System angemeldet ist - weiters würde mir vorschweben, dass nur angemeldete User entsprechende Mehrinformation zu Büchern einsehen können, als nicht registrierte User.

Wir könnten den registrierten Usern auch die Möglichkeit anbieten sie mittels newsletter über neue Bücher in bestimmten vom User ausgewählten Kategorien zu informieren. Die Newsletter-Funktion muss aber auf jeden Fall deaktivierbar sein, da es von manchen User einfach nicht benötigt wird oder als störend empfunden wird.

Die registrierten Benutzer könnten auch mit benutzerbezogener Werbung konfroniert werden, wenn sie sich auf unserer Homepage befinden. Wir wissen ja was sie wann gekauft haben und können entsprechende Angebote zusammenstellen.

Zahlung
Es muss mindestens die Möglichkeit der Zahlung mittels Kreditkarte und mittels Bankeinzug geben. Da nicht alle Benutzer/Käufer eine Kreditkarte besitzen, aber jeder zumindest ein Bankkonto haben muss, schränken wir uns durch diese 2 Möglichkeiten nicht die potenziellen Käufer ein.
Eine weitere Möglichkeit der Bezahlung würde zB PayPal oder PayPerSMS darstellen.

Für die Zahlung im Internet muss auf der Website aber auf jeden Fall ein SSL-verschlüsselter Zugang möglich sein. Das SSL-Protokoll ermöglicht es die Informationen, die eingegeben und übertragen werden bis zu 256 bit zu verschlüsseln und somit für fremde nicht lesbar zu machen.
Der Zugang zum kompletten User-Account wäre dann nur über https:// möglich.

Forum / Kommentierungen
Sinnvoll würde ich erachten bei Büchern, die man auf der Homepage abfragen kann, Kommentare zuzulassen. Somit können auch nicht angemeldete oder registrierte Benutzer Kritiken oder kurze Bewertungen zu Büchern hinterlassen.

Registrierte Benutzer hingegen sollte es möglich sein zu den Büchern auch detailliertere Buchkritiken abfragen zu können. Des weiteren wäre es denkbar den registrierten Benutzern ein Forum zur Verfügung zu stellen, in dem sie sich in bestimmten Gruppen oder Kategorien über bestimmte Bücher etc. unterhalten können.

Somit wären meine Re-Design Vorschläge erschöpft. Ich bin der Ansicht, dass diese Vorschläge sicherlich eine Potenzialsteigerung des Website bzw. des Buchhandels wäre und somit noch mehr Kunden angesprochen werden können.

Hier noch meine Präsentation: praesentation (ppt, 244 KB)

Permalink (0 Kommentare)   Kommentieren



Sonntag, 25. Mai 2008
Hausübung 6 - e-Business
christian.weinzinger.Uni-Linz, Sonntag, 25. Mai 2008, 20:34
E-Business ist laut der Definition von IBM eine "Neugestaltung strategischer Unternehmensprozesse und die Bewältigung der Herausforderungen eines neuen Marktes, der sich zunehmend durch Globalisierung auszeichnet und auf Wissen basiert." [Staudt, 2001, S. 24]

Folgende Grafik habe ich in Wikipedia gefunden. Ich finde, dass sie sehr gut darstellt, wie E-Business verstanden wird bzw. wie es meiner Meinung nach verstanden werden sollte.


[Wikipedia, 2008, Suchbegriff: E-business]

Um unser Buchhandelsmodel ins das E-Business einzubinden bzw. es darin fit zu machen müssen wir es genau an der Schnittstelle zwischen Kunden, Lieferanten und Internet positionieren.

_____________________________________________
Die Plattform muss sowohl von Kunden als auch von Lieferanten gut und leicht verständlich bedienbar sein und sollte wesentliche Informationen in strukturierter Form darstellen.

_____________________________________________
Weiters sollte es möglich sein auf der Homepage interaktiv navigieren zu können oder zB Hörproben und Hintergrundinformationen zu den Autoren abrufen zu können.

_____________________________________________
Ebenfalls sinnvoll erscheinen mir Leseproben im PDF-Format oder online als Bild. Ich benutze absichtliche nicht den Begriff Web 2.0, da ich finde, dass dies nur ein Modewort ist. Ein interaktiver Zugang trifft den Gedanken von Web 2.0 sicherlich besser als dieses (wie ich meine) "Unwort".

_____________________________________________
Was die Homepage auf jeden Fall beinhalten muss – da betrachte ich als Grundvoraussetzung für einen erfolgreichen Webauftritt – ist eine Buchdatenbank im Hintergrund, die eine Abfrage (Suche) über verschiedene Kriterien zulässt und auch gleicht den Lagerstatus der entsprechenden Bücher anzeigt.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Das erfordert die Einbindung von einem Datenbankkonnektor und einer Programmiersprach, die dies unterstützt.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Weiters muss es die Möglichkeit geben online zu bezahlen (entweder per Kreditkarte oder zB per pay-pal). Dadurch muss auch eine SSL-Verbindung zur Homepage hergestellt werden können.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Diese online-Bezahlmöglichkeit setzt aber auch voraus, dass es die Möglichkeit gibt sich ein Account auf der Homepage einzurichten. Man muss sich also anmelden können und es muss eine Accountverwaltung geben. Diese setzt wiederum einen Mail-Server voraus, der wiederum auch in die Homepage eingebunden werden muss.

_____________________________________________
[Laudon et Laudon, S. 175] konstituieren, dass Unternehmen ein erfolgreiches Geschäftsmodell für das Internet finden müssen. Diese Aussage muss auf der Homepage insofern umgesetzt werden, als dass der komplette Geschäftsprozess des Unternehmens sich in der Homepage wieder finden sollte.

Angefangen von der Verwaltung und Abwicklung der Einkäufe bzw. der Lieferanten über die Präsentation der Bücher bis hin zum Verkauf der Bücher an die Kunden, sollten sich alle Tätigkeiten mit der Homepage bewältigen lassen.

_____________________________________________
Es ist auf jeden Fall wichtig die Homepage so zu gestalten, dass sie benutzerfreundlich und ohne große Einarbeitungszeit sofort bedienbar ist.

_____________________________________________
Die Homepage sollte von der Geschäftskundenseite auch die Möglichkeit bieten standardisiert Einkäufe durchzuführen. Dafür ist eine XML-Schnittstelle mit Anbindung an die Buchdatenbank nötig, die nach Abschicken der Bestellung auch gleich über einen Lieferstatuts bzw. voraussichtliche Lieferzeiten etc. Auskunft geben kann.


All diese Technologien in ein sinnvollen uns effektives Zusammenspiel zu bringen fordert sicherlich entsprechenden Aufwand und sollte einem Profi überlassen werden.

_____________________________________________
Sobald die Homepage dann einmal online gegangen ist, sollten in Printmedien Inserate geschalten werden, die die Adresse der Homepage zeigen.

Dann sollte es nur noch eine Frage der Zeit sein, bis sich die ersten Kunden bei uns anmelden und die ersten Bestellungen online eingehen.

Permalink (0 Kommentare)   Kommentieren



Montag, 14. April 2008
XML-Grundlagen. Erfassen eines Kunden
christian.weinzinger.Uni-Linz, Montag, 14. April 2008, 09:27
Meine MatrikelNr: 0557311

Folglich habe ich Aufgabe 1 zu bearbeiten. Diese ist:
einen Kunden erfassen.

Die Aufgabe besteht darin einen Kunden in der Lehrdatenbank unter http://sql.idv.edu zu erfassen. Es sollen keine bestehenden Kunden erfasst werden.

Ich werde zuerst das XML-Dokument programmieren. Anschließend werde ich das Dokument um die DTD erweitern. Für die gestellte Aufgabenstellung erscheint es mir eher sinnvoll eine interne DTD-Deklaration zu verwenden.

Erste Überlegungen:
Das Dokument sollte sinnvollerweise die Struktur haben, die auch die Datenbank verlangt. Ein Kunde hat eine Kundennummer, einen Vornamen, einen Nachnamen, wohnt in einer Straße und an einer bestimmten Postleitzahl.

Also würde ich mal so beginnen:


<kunde>
<nr> 9999 </nr>
<vorname> Franz </vorname>
<nachname> Huber </nachname>
<strasse> Gutshofstraße </strasse>
<plz> 4060 </plz>
</kunde>


Die Datei sieht in einer ersten Vorversion mal so aus:
newclient.xml (xml, 0 KB)

Um nun die die entsprechende DTD-Deklaration in die Datei einzubauen muss zuerst der Standard und anschließen die Deklaration der Tags erfolgen.

Der Standard ist folgender Maßen deklariert:
<?xml version="1.0" encoding="ISO-8859-1" ?>

Danach deklariere ich die entsprechenden Tag, die gebraucht werden:
<!DOCTYPE kunde [
<!ELEMENT kunde (nr, vorname, nachname, strasse, plz)>
<!ELEMENT nr (#PCDATA)>
<!ELEMENT vorname (#PCDATA)>
<!ELEMENT nachname (#PCDATA)>
<!ELEMENT strasse (#PCDATA)>
<!ELEMENT plz (#PCDATA)>
]>


Der Datentyp #PCDATA steht für 'Parsed Character Data'. Dieser Datentyp beschreibt den Inhalt eines Tags. Es kann nicht unterschieden werden, ob es sich um eine Zahl, einen Text oder ein Datum handelt.

Die genaue Deklaration der Datentypen müsste im Rahmen eines XSD-Files passieren. Das XSD (XML Schema Description) ist eine andere Möglichkeit die Datentypen zu deklarieren.
Eine genaue Erklärung was XSD ist und wozu sie verwendet werden kann gibts unter:
http://www.w3schools.com/schema/

So und jetzt ist es so weit. Ich habe mich doch entschlossen keine interne sondern eine externe DTD-Deklaration zu erstellen. Das erscheint mir hier doch der bessere Weg zu sein.

Im XML-Dokument muss man zuerst den Pfad der externen DTD-Datei angeben. Mit dem Schlüsselwort SYSTEM wird mal automatisch im gleichen Ordner nachgesehen, in der auch das XML-File liegt. Der Header der XML Datei sieht dann bei mir so aus:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE kunde SYSTEM "newClient.dtd">


Das ganze XML-File sieht nun so aus: (Leider zeigt dieser XML-Editor die Kopfzeilen nicht an - die Kopfzeilen sind oben - fett dargestellt - ersichtlich. Genau so sind sie auch im XML-Dokument drinnen)
newclient_excl_dtd.xml (xml, 0 KB)
Die dazugehörige DTD so:
<!ELEMENT kunde (nr, vorname, nachname, strasse, plz)>
<!ELEMENT nr (#PCDATA)>
<!ELEMENT vorname (#PCDATA)>
<!ELEMENT nachname (#PCDATA)>
<!ELEMENT strasse (#PCDATA)>
<!ELEMENT plz (#PCDATA)>

Permalink (0 Kommentare)   Kommentieren



Mittwoch, 2. April 2008
SQL-Problem vom 02. April 2008
christian.weinzinger.Uni-Linz, Mittwoch, 2. April 2008, 12:02
Betrifft Punkt 1 der Aufgabenstellung:
Meiner Ansicht nach ist die folgende SQL-Anweisung, diejenige welche den gefragten Sachverhalt beschreibt.

SELECT Kunde.Nr, Kunde.Nachname, Count(Auftrag.Nr) As Anzahl, Sum(Auftragspos.Menge*Buch.Preis) as Auftragssumme
FROM Kunde, Auftrag, Auftragspos, Buch
WHERE Kunde.Nr = Auftrag.Kundennummer
AND Auftrag.Nr = Auftragspos.Auftragsnummer
AND Auftragspos.Buchnummer = Buch.Nr
AND Auftrag.Datum > '2001-01-01'
GROUP BY Kunde.Nr


Sie liefert als Ergebnis 24 Tupel.

Sie liefert nämlich aus das gleiche Ergebnis wie folgende Abfrage. Es wurden aber die Summe bzw. die beiden Tabellen Buch und Auftragspos entfernt. Würde die vorige Abfrage falsch sein, dann würden durch die 2 weggefallenen Joins andere Ergebnistupel geliefert werden --> man erwartet aber, dass das gleiche Ergebnis zurückkommt (wenn man annimmt, dass die erste Abfrage, dass gleiche Ergebnis geliefert hat)
Das Ergebnis sind 24 Tupel mit den gleichen Werten und Namen

SELECT Kunde.Nr, Kunde.Nachname, Count(Auftrag.Nr) As Anzahl
FROM Kunde, Auftrag
WHERE Kunde.Nr = Auftrag.Kundennummer
AND Auftrag.Datum > '2001-01-01'
GROUP BY Kunde.Nr


Geht man nun auf die höchste Ebene der Auswertungsmöglichkeit - nämlich der Abfrage wie viele Aufträge nach dem 01. Jänner 2001 eingegangen sind - dann erhält man als Ergebnis 24!!

select count(Auftrag.Nr) from Auftrag where Auftrag.Datum > '2001-01-01'


Somit ist bewiesen, dass die Abfragen richtig sind.

edit - korrigierte Aufgabenstellung -----------------

ausgehend von dieser Abfrage:

SELECT Kunde.Nr, Kunde.Nachname, COUNT(Auftrag.Nr)
FROM Kunde, Auftrag
WHERE Kunde.Nr = Auftrag.Kundennummer
GROUP BY Kunde.Nr
ORDER BY Kunde.Nr

sollte eine Weiterentwicklung der Abfragen stattfinden.

1)
Es soll der Umsatz noch zusätzlich zur Anzahl der Aufträge in die Abfrage eingebaut werden.
Ich habe das mit dieser Abfrage bewerkstelligt. Das Ergebnis (=Anzahl Tupel) ist das gleich wie vorhing.

SELECT Kunde.Nr, Kunde.Nachname, COUNT(Auftrag.Nr) as Anzahl, sum(Auftragspos.Menge*Buch.Preis) as Auftragssumme
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 Kunde.Nr


2) und 3)
Als nächstes sollte eine Verteilung über die Zeit stattfinden (ohne Anzahl und Umsatz der Aufträge).
Ich habe eine Verteilung der Aufträge in Jahr vorgenommen. Eine Verteilung über Einschränkungen in der Where-Klausel sind weiter oben zu sehen. Diese wollte ich nun komprimieren und erweitern.

Da die Lehrdatenbank leider keine gängige SQL-Syntax wie zB in Oracle SQL oder MySQL (nämlich die Durchführung von SubQueries) zulässt, musste ich diese Abfrage etwas komplizierter gestalten.
Da ich bei SubQueries immer eine Fehlermeldung 'use joins to connect all tables' erhalten habe und ich nicht weiß wie man mittels joins in einer Abfrage 2 mal die gleiche Tabelle mit unterschiedlichen Spalten referenzieren soll, half ich mir mit Funktionen.
Ich wollte nämlich in 2 getrennten Spalten die Anzahl der Aufträge je Jahr angezeigt haben.
Also nam ich die Funktion Year(<Date>), die mir das jeweilige Jahr des Datums liefert und zählte für die Spalte 2000 das Vorkommen des Jahres 2000 bzw. für 2001 das Vorkommen des Jahres 2001.

Die folgende Anweisung erzeugt genau das gewollte Ergebnis:

SELECT Kunde.Nr, Kunde.Nachname,
sum(year(Auftrag.Datum)=2000) as Aufträge2000, sum(year(Auftrag.Datum)=2001) as Aufträge2001
FROM Kunde, Auftrag, Auftragspos, Buch
WHERE Kunde.Nr = Auftrag.Kundennummer
AND Auftrag.Nr = Auftragspos.Auftragsnummer
AND Auftragspos.Buchnummer = Buch.Nr
GROUP BY Kunde.Nr
having Aufträge2001>0 or Aufträge2000>0


Wiederum ändert sich die Anzahl der Tupel nicht. Als nächstes habe ich noch die Anzahl aller Aufträge und den Gesamtumsatz eingebunden.

SELECT Kunde.Nr, Kunde.Nachname,
sum(year(Auftrag.Datum)=2000) as Anzahl2000, sum(year(Auftrag.Datum)=2001) as Anzahl2001,
count(Auftrag.Datum) as Gesamtanzahl,
sum(Auftragspos.Menge*Buch.Preis) as Gesamtumsatz
FROM Kunde, Auftrag, Auftragspos, Buch
WHERE Kunde.Nr = Auftrag.Kundennummer
AND Auftrag.Nr = Auftragspos.Auftragsnummer
AND Auftragspos.Buchnummer = Buch.Nr
GROUP BY Kunde.Nr
having Anzahl2001>0 or anzahl2000>0


4)
Als nächstes sollten noch die durchschnittliche Anzahl von Aufträge ausgewertet werden. Ich muss gestehen, dass die Aufgabenstellung für mich sehr unverständlich geschrieben ist, da weder ein Zeitraum angegeben ist noch angegeben ist welcher Durchschnitt berechnet werden soll.
Der Durchschnitt aller Aufträge, die je gegeben wurden macht eher wenig Sinn. Durchschnittlicher Umsatz je Auftrag macht schon Sinn, aber nicht im Zusammenhang mit oben angeführter Auswertung. Es bringt nämlich nicht, wenn in jeder Zeile zusätzlich noch der durchschnittliche Umsatz je Auftrag angeführt wird. Der ist nämlich logischerweise in jeder Zeile gleich.
Ich habe mich also dazu entschlossen den durchschnittlichen Umsatz je Kunde zu errechnen. Ich hab diese Abfrage nicht mit der AVG() Funktion durchgeführt, da sonst ein falsches Ergebnis geliefert wird.

SELECT Kunde.Nr, Kunde.Nachname,
sum(year(Auftrag.Datum)=2000) as Anzahl2000, sum(year(Auftrag.Datum)=2001) as Anzahl2001,
count(Auftrag.Datum) as Gesamtanzahl,
sum(Auftragspos.Menge*Buch.Preis) as Gesamtumsatz,
(sum(Auftragspos.Menge*Buch.Preis) / count(Auftrag.Datum)) as Durchschnittsumsatz
FROM Kunde, Auftrag, Auftragspos, Buch
WHERE Kunde.Nr = Auftrag.Kundennummer
AND Auftrag.Nr = Auftragspos.Auftragsnummer
AND Auftragspos.Buchnummer = Buch.Nr
GROUP BY Kunde.Nr
having Anzahl2001>0 or anzahl2000>0


Zuletzt zeige ich noch, dass die Abfragen auch stimmen. Ich filtere jetzt nur jene Kunden, die in beiden Jahren Aufträge an uns gegeben haben. Dazu ändere ich in der letzte Zeile (=HAVING-Klausel) das OR zu einem AND.

SELECT Kunde.Nr, Kunde.Nachname,
sum(year(Auftrag.Datum)=2000) as Anzahl2000, sum(year(Auftrag.Datum)=2001) as Anzahl2001,
count(Auftrag.Datum) as Gesamtanzahl,
sum(Auftragspos.Menge*Buch.Preis) as Gesamtumsatz,
(sum(Auftragspos.Menge*Buch.Preis) / count(Auftrag.Datum)) as Durchschnittsumsatz
FROM Kunde, Auftrag, Auftragspos, Buch
WHERE Kunde.Nr = Auftrag.Kundennummer
AND Auftrag.Nr = Auftragspos.Auftragsnummer
AND Auftragspos.Buchnummer = Buch.Nr
GROUP BY Kunde.Nr
having Anzahl2001>0 and anzahl2000>0


Schränkt man die HAVING-Klausel auf nur Anzahl2001>0 ein, dann erhält man wieder 24 Tupel. Genau wie in allen Abfragen davor, die 2001er Aufträge abgefragt haben.

Permalink (0 Kommentare)   Kommentieren



Donnerstag, 20. März 2008
SQL ist SUPER
christian.weinzinger.Uni-Linz, Donnerstag, 20. März 2008, 07:30
Der folgende Beitrag deckt die 2. Aufgabe der Vorlesung IV 2 ab.
Es sollen auf einem Web-Datenbank SQL abfragen durchgeführt werden. Diese Abfragen sollen beschrieben werden und die entsprechenden SQL statements sollen auch veröffentlicht werden.
Anbei meine Einfälle für Abfragen inkl. entsprechender Dokumentation.

1. Um einen ersten groben Überlblick zu erhalten werde ich als erstes einmal abfragen wieviele Kunden überhaupt in der Datenbank sind. Das heißt wieviele Kunden hab ich (als Unternehmen).

Das funktioniert folgender Maßen:

SELECT COUNT(*) FROM Kunde


2. Da ich jetzt einmal weiß wieviele Kunden ich hab, möchte ich als nächstes wissen welche Kunden mehr als 5 Bestellungen offen haben. Mit dieser Information kann ich meine Logistik und mein Bestellwesen entsprechend steuern und so versuchen eine möglichst kurze Durchlaufzeit von Bestellungen zu erreichen, damit die Kunden nicht ewig auf die Bestellung warten müssen

Ich habe die Info mit folgender SQL-Anweisung aus der Datenbank ausgelesen:

SELECT Kunde.Nr, Kunde.Vorname, Kunde.Nachname, COUNT(Auftrag.Nr) AS Anzahl
FROM Kunde, Auftrag
WHERE Kunde.Nr=Auftrag.Kundennummer
GROUP BY Kunde.Nr
HAVING(Anzahl) > 5


3. Meine nächste Abfrage beschäftigt sich damit welcher Verlag wie viele Bücher zur Verfügung stellen kann. Dabei sollen die Bücher, die der Verlag im Programm hat aufsummiert werden (Anzahlen). Diese sollen dann absteigend (die größte Anzahl zuerst) ausgegeben werden. Somit kann man feststellen welcher Verlag der am stärksten vertretene ist.
Es sollen Name (LangName) des Verlags plus die Anzahl der Bücher ausgegeben werden.

Das ensprechende Statement für diese Aufgabe ist:

SELECT Verlag.Name AS Verlag, COUNT(Buch.Nr) AS Anzahl_Buecher
FROM Buch, Verlag
WHERE Buch.Verlag = Verlag.Kurzbezeichnung
GROUP BY Verlag
ORDER BY Anzahl_Buecher DESC


4. Als nächstes möchte ich die größten Kunden wissen, die uns aktuell Bestellungen (Aufträge) gegeben haben. Dabei sollen die Kundennummer, Name , Summe der bestellten Bücher und Auftragssumme (Buch*Preis) der Bestellungen ausgegeben werden.
Es werden vorerst einmal alle Kunden ausgegeben, deren Auftragswert über EUR 100.000,00 ist. Mit dieser Abfrage kann ein eventuelle Klumpenrisiko ermittelt werden. (Ein Klumpenrisiko zeigt jene Kunden , die eine sehr große Auftragssumme offen haben. Damit kann man sehen, bei welchen Kunden es besonders wichtig ist, dass sie nicht ausfallen)

Folgendes Statement liefert das entsprechende Ergebnis:

SELECT Kunde.Nr, Kunde.Vorname, Kunde.Nachname, SUM(Auftragspos.Menge) AS Summe_Buecher, SUM(Buch.Preis*Auftragspos.Menge) AS Auftragssumme
FROM Kunde, Auftrag, Auftragspos, Buch
WHERE Kunde.Nr=Auftrag.Kundennummer
AND Auftrag.Nr=Auftragspos.Auftragsnummer
AND Auftragspos.Buchnummer=Buch.Nr
GROUP BY Kunde.Nr
HAVING Auftragssumme > 100000
ORDER BY Auftragssumme DESC


5. Welcher Kunde hat Bücher bestellt, die nicht auf Bestand sind oder auslaufen und der Kunde mehr bestellt hat als auf Lager sind. Diesen Kunden muss natürlich eine Nachricht geschrieben werden, in der sie darauf aufmerksam gemacht werden, dass die Bücher nicht mehr (zur Gänze) oder mit Verspätung lieferbar sind.

Statement:

SELECT Kunde.Nr AS KNr, Kunde.Nachname, Auftrag.Nr AS Auftrag, Buch.Nr AS BuchNr, Buch.Titel, Buch.Auslaufend, Buch.Bestand, Auftragspos.Menge
FROM Kunde, Auftrag, Auftragspos, Buch
WHERE Kunde.Nr=Auftrag.Kundennummer
AND Auftrag.Nr=Auftragspos.Auftragsnummer
AND Auftragspos.Buchnummer=Buch.Nr
AND (Buch.Bestand=0
OR (Auftragspos.Buchnummer=Buch.Nr
AND Buch.Auslaufend="y"
AND Auftragspos.Menge > Buch.Bestand))


6. Als letztes möchte ich wissen bei welchen Büchern ich generell einen Engpass habe (Aber nur bei jenen Büchern, die auslaufen). In der letzten Abfrage sind Bücher durch den Rost gefallen, wo Kunden zwar weniger als die auf Bestand liegenden bestellt haben, in Summe über alle Bestellungen aber auch mehr Bücher bestellt wurden als auf Lager sind.

Die Engpässe ermittle ich mit folgender Anweisung:

SELECT Buch.Nr, Buch.Titel, Buch.Bestand, Buch.Auslaufend, SUM(Auftragspos.Menge) AS Menge_Bestellung
FROM Auftragspos, Buch
WHERE Auftragspos.Buchnummer=Buch.Nr AND Buch.Auslaufend="y"
GROUP BY Buch.Nr
HAVING(Menge_Bestellung)>Buch.Bestand

Permalink (0 Kommentare)   Kommentieren



Samstag, 8. März 2008
First Entry
christian.weinzinger.Uni-Linz, Samstag, 8. März 2008, 11:53
This is my first entry for IV 2 Webblog.
Hallo mein Name ist Christian Weinzinger. Ich studiere Wirtschaftsinformatik in Linz. Mittlerweile bin ich im 2. Abschnitt und hoffe in 2,5 Jahren fertig zu sein.

Ich mache diesen Kurs als freies Wahlfach für Wirtschaftsinformatik. Eventuell habe ich auch vor Wirtschaftswissenschaften fertig zu machen, da ich sehr viele Kurse von WiWi für WIN auch brauche und ich somit schon viel von Wiwi gemacht habe.

Besonders freue ich mich auf die SQL und XML Aufgaben (hoffentlich in Verbindung mit Java Script), die ich als Auffrischung des Stoffs aus WIN sehe.

In diesem Sinne:
SELECT * FROM iv2 INTO NEW TABLE class;

for all names in class {
system.out.println("Ciao");
}

Falls jemand obigen Code nicht versteht verlinkt mich auch Eurer Seite und schreibt mir dann einen Kommentar!!

Chris

Permalink (0 Kommentare)   Kommentieren