Lokaler Webshop

Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.

Nur wenige Web-Applikationen kommen ohne eine zugrundeliegende Datenbank aus. Ob CMS-Systeme oder eCommerce-Anwendungen, alle speichern unter der Haube ihre Daten in DBMS-Servern, wie etwa MySQL. Wie stellen in dieser Ausgabe einen unter Access nachgebildeten Shop vor, der ähnliche Features aufweist, wie seine Vorbilder im Internet. Zwar nützt eine solche Anwendung reell wohl für nur wenige Einsatzbereiche, dafür aber lässt sich an ihr eine Menge demonstrieren.

Beispieldatenbank

Die Beispiele dieses Artikels finden Sie in der Datenbank 1608_Webshop.zip.

Demo-Webshop

Vorstellbar wäre etwa der Einsatz auf Messe- oder Verkaufsstandrechnern, wo Kunden nicht vorrätige Artikel über den lokalen Shop beziehen könnten. Weniger auf dem Praxiseinsatz liegt unser Augenmerk hier jedoch, als vielmehr auf der Darstellung des Datenmodells und dem, was sich aus ihm herausholen lässt.

Unsere einfache alte Kundendatenbank hat zunächst ausgesorgt. Dennoch bildet sie die Basis für die Kundenverwaltung des Shops. Angedockt ist an sie eine Bestellverwaltung, wie sie ebenfalls schon mehrfach in unseren Beiträgen verwendet wurde und in der ehrwürdigen Nordwind-Datenbank ihr Vorbild hat. Neuer hingegen ist ein Teil zur Verwaltung von Artikeln und Produktkategorien. Wie auch immer: Das Hauptformular der Anwendung zeigt sich, wie in Bild 1, in dem Hardware-Produkte über die virtuelle Firma ABasics Computer GmbH bezogen werden können. Hier wählen Sie Artikel über das Kombinationsfeld mit den Hauptkategorien oben links und weiter mit dem Listenfeld links und dessen Produktunterkategorien aus. Die Spezifikation des Produkts inklusive eines Vorschaubilds wird dann rechts im Formular eingeblendet. Der Artikel kann schließlich über den grünen Button rechts unten in den Warenkorb gelegt werden. Auf den weiteren Bestellvorgang kommen wir später noch zu sprechen.

Bild 1: So präsentiert sich der Webshop nach dem Start des Formulars frmShop mit eingestellten Kategorien und einem Produkt

Selbstverständlich ist dies nur ein stark vereinfachtes Muster, denn echte Webshop-Systeme weisen meist über hundert verknüpfte Tabellen auf und stellen in der Regel ausgewachsene Warenwirtschaftsanwendungen dar. Dennoch zeigt sich hier das Prinzip. Die Demodatenbank enthält übrigens über 10.000 existierende Artikel, die zumeist mit Vorschaubildern abgespeichert sind. Auf größere Produktbilder musste verzichtet werden, da dies den Download auf einige Gigabyte vergrößert hätte.

Datenmodell des Shops

In Bild 2 sind die Beziehungen zwischen sämtlichen Tabellen der Datenbank dargestellt. Ganz links finden sich die bekannten Kundentabellen im hellblauen Bereich. Die daran angeflanschten Bestelldaten sind gelb hinterlegt. Rechts finden Sie die zu Artikeln gehörigen Tabellen.

Bild 2: Layout des von einer Bestelldatenverwaltung abgeleiteten neuen Datenmodells des Webshops im Beziehungsfenster

Die Kundentabelle tblKunden hat nun ein zusätzliches Feld Login bekommen. In diesem Textfeld wird für einen im Shop registrierten Kunden dessen Passwort gespeichert. Die Verbindung von Kunden zu Bestellungen passiert über das Schlüsselfeld KundeID der Tabelle tblBestellungen über eine 1:n-Beziehung mit Referenzieller Integrität. Das Löschen von Kunden zieht damit automatisch das Entfernen der zugehörigen Bestelldatensätze nach sich.

Bestellungen

Eine Bestellung wird über die vier Felder der Tabelle tblBestellungen identifiziert. Ihr Primärschlüssel ID (Autowert) dient gleichzeitig als Bestellnummer. Das Bestelldatum gibt den Zeitpunkt der Bestellaufgabe wieder. IDStatus bezieht sich auf ihren Bearbeitungsstatus, dessen Text aus der Nachschlagetabelle tblBearbeitungsstati kommt.

Die möglichen Werte sind hier:

0 - Bestellung noch nicht abgeschickt
1 - Bestellung aufgegeben
2 - Bestellung versandt
3 - Bestellung abgeschlossen

Der Vorgabewert 0 bedeutet dabei, dass eine Bestellung angelegt wurde, indem Artikel temporär in den Warenkorb gelegt wurden, dieser jedoch noch nicht zur Kasse gelangte.

Nicht ganz einleuchtend mag das Feld Gesamtsumme sein, welches den Bruttogesamtbetrag aller Artikel enthält. Tatsächlich ergibt sich dieser ja aus den Artikelpreisen, deren Anzahl und Steuersätzen. Das wiederspricht scheinbar den Regeln der Normalisierung von Datenbankmodellen. Tut es auch, doch ganz so akribisch muss man nicht vorgehen. Denn bei der Berechnung etwa von Umsatzstatistiken fallen die benötigten Abfragen einfacher aus, weil dafür nun die eine Tabelle tblBestellungen ausreicht. Im Interesse erhöhter Performance ist so eine Denormalisierung deshalb durchaus statthaft.

Die einzelnen Artikel einer Bestellung listet die 1:n-Tabelle tblBestelldetails auf. Die BestellID jedes Datensatzes bezieht sich auf die Bestellnummer ID in tblBestellungen. Auch hier ist Referenzielle Integrität mit Lösch- und Aktualisierungsweitergabe eingestellt. Das Löschen einer Bestellung löscht damit auch alle bestellten Positionen. Und damit führt das Löschen eines Kunden automatisch sowohl zum Entfernen all seiner Bestellungen und zusätzlich aller zugehörigen Bestellpositionen. Um verwaiste Datensätze müssen Sie sich deshalb nicht sorgen.

Die ArtikelID verweist auf einen der Shop-Artikel in der Tabelle tblArtikel. Die Beziehung zwischen beiden ist ebenfalls referenziell, jedoch ist hier keine Löschweitergabe festgelegt. Schließlich soll das Entfernen eines Artikels aus dem Produktsortiment ja nicht die auf diesen bezogenen Bestellungen durcheinanderbringen. Die Referenzielle Integrität sorgt hier im Gegenteil dafür, dass ein Artikel gar nicht gelöscht werden kann, wenn mit ihm Bestellungen verbunden sind. Die Datenbank-Engine verhindert dies nun automatisch und gibt gegebenenfalls einen entsprechenden Hinweis aus.

Zu einer Bestellposition gehört weiterhin die gewünschte Anzahl des Artikels. Sein Preis wird im Währungsfeld Netto verewigt, die angesetzte Umsatzsteuer im Double-Feld Ust, das als Prozentzahl formatiert wird. Auch hier scheint mangelhafte Normalisierung vorzuliegen, denn die gleichen Felder finden sich auch beim Produkt in der Tabelle tblArtikel wieder. Dem ist jedoch nicht so! Denn die Produktpreise werden ja fortwährend dem Markt angepasst. Entnähme man die Preise lediglich der Tabelle tblArtikel, so wiese die Rechnung nach Warenversand eventuell falsche Preisangaben aus. Die Preise müssen daher an dieser Stelle fest abgespeichert werden, damit sie die gleichen Werte haben, wie zum Bestelldatum, was dann sowohl in der Rechnung zum Ausdruck kommt, wie auch in der Bestellübersicht eines Kunden.

Das Feld Brutto ist eigentlich überflüssig, vereinfacht jedoch Abfragen auf die Tabelle. Es handelt sich bei ihm nicht um ein Eingabefeld, sondern um das in Access 2010 eingeführte Berechnete Feld. Hier ist eine Formel hinterlegt, die sich in Bild 3 aus der Feldeigenschaft Ausdruck ergibt. Als Ergebnistyp ist Double eingetragen. Für absolut korrekte Summenbildung in Abfragen wäre dieser Typ allerdings auf Währung zu ändern.

Bild 3: Die Formel für das Berechnete Feld Brutto in der Tabelle tblBestellDetails

Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...

Testzugang

eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel

diesen und alle anderen Artikel mit dem Jahresabo