{"id":55000330,"date":"2017-04-01T00:00:00","date_gmt":"2020-01-24T15:59:40","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=330"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Lokaler_Webshop","status":"publish","type":"post","link":"https:\/\/access-basics.de\/index.php\/Lokaler_Webshop.html","title":{"rendered":"Lokaler Webshop"},"content":{"rendered":"

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.<\/p>\n

Beispieldatenbank<\/h2>\n

Die Beispiele dieses Artikels finden Sie in der Datenbank 1608_Webshop.zip<\/b>.<\/p>\n

Demo-Webshop<\/h2>\n

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.<\/p>\n

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 <\/b>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.<\/p>\n

\"So<\/a><\/p>\n

Bild 1: So präsentiert sich der Webshop nach dem Start des Formulars frmShop mit eingestellten Kategorien und einem Produkt<\/p>\n

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.<\/p>\n

Datenmodell des Shops<\/h2>\n

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.<\/p>\n

\"Layout<\/a><\/p>\n

Bild 2: Layout des von einer Bestelldatenverwaltung abgeleiteten neuen Datenmodells des Webshops im Beziehungsfenster<\/p>\n

Die Kundentabelle tblKunden<\/b> hat nun ein zusätzliches Feld Login<\/b> 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<\/b> der Tabelle tblBestellungen <\/b>ü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.<\/p>\n

Bestellungen<\/h2>\n

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

Die möglichen Werte sind hier:<\/p>\n

0 - Bestellung noch nicht abgeschickt\r\n1 - Bestellung aufgegeben\r\n2 - Bestellung versandt\r\n3 - Bestellung abgeschlossen<\/pre>\n
Der Vorgabewert 0<\/b> bedeutet dabei, dass eine Bestellung angelegt wurde, indem Artikel temporär in den Warenkorb gelegt wurden, dieser jedoch noch nicht zur Kasse gelangte.<\/p>\n
Nicht ganz einleuchtend mag das Feld Gesamtsumme<\/b> 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<\/b> 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<\/b> ausreicht. Im Interesse erhöhter Performance ist so eine Denormalisierung deshalb durchaus statthaft.<\/p>\n
Die einzelnen Artikel einer Bestellung listet die 1:n-Tabelle<\/b> tblBestelldetails<\/b> auf. Die BestellID<\/b> jedes Datensatzes bezieht sich auf die Bestellnummer ID<\/b> in tblBestellungen<\/b>. 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.<\/p>\n
Die ArtikelID<\/b> verweist auf einen der Shop-Artikel in der Tabelle tblArtikel<\/b>. 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.<\/p>\n
Zu einer Bestellposition gehört weiterhin die gewünschte Anzahl<\/b> des Artikels. Sein Preis wird im Währungsfeld Netto<\/b> verewigt, die angesetzte Umsatzsteuer im Double<\/b>-Feld Ust<\/b>, das als Prozentzahl formatiert wird. Auch hier scheint mangelhafte Normalisierung vorzuliegen, denn die gleichen Felder finden sich auch beim Produkt in der Tabelle tblArtikel<\/b> 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<\/b>, 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.<\/p>\n
Das Feld Brutto<\/b> 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<\/b> eingeführte Berechnete Feld<\/b>. Hier ist eine Formel hinterlegt, die sich in Bild 3 aus der Feldeigenschaft Ausdruck<\/b> ergibt. Als Ergebnistyp ist Double<\/b> eingetragen. Für absolut korrekte Summenbildung in Abfragen wäre dieser Typ allerdings auf Währung zu ändern.<\/p>\n
\"Die<\/a><\/p>\n
Bild 3: Die Formel für das Berechnete Feld Brutto in der Tabelle tblBestellDetails<\/p>\n
Bliebe noch das Ja\/Nein-Feld Bearbeitet. Dieses bekommt der Kunde im Shop nicht zu Gesicht, denn hier handelt es sich um ein Hilfsfeld für den Vertrieb. Beim Packen einer Bestellung setzt der Bearbeiter für die jeweilige Bestellposition den Wert in einem noch zu besprechenden Bearbeitungsformular auf Ja, um die übersicht zu behalten.<\/p>\n
Produktkategorien<\/h2>\n
Bevor wir zu Artikeln und deren Detailtabellen kommen, seien noch die Kategorien des Shops erläutert. Sie teilen sich in die zwei Tabellen tblKategorien<\/b> und tblHauptkategorien<\/b> auf. Eine Hauptkategorie wären zum Beispiel Drucker<\/b>. Deren Unterkategorien wäre Laserdrucker<\/b>, Multifunktionsdrucker<\/b>, Tintenstrahldrucker<\/b>. Letztere verzeichnet die tblKategorien<\/b>, wobei hier zu jedem Datensatz die ID<\/b> der Hauptkategorie im Feld IDHauptkategorie<\/b> abgespeichert ist. In der Artikeltabelle wiederum verweist der Long-Wert IDKategorie<\/b> auf einen Datensatz in tblKategorien<\/b>.<\/p>\n
Im wahren Leben käme diese Kombination eher nicht zum Einsatz. Stattdessen verwendete man eine Rekursive Tabelle<\/b>, die sowohl über- wie untergeordnete Kategorien enthielte. Eine Eltern-ID<\/b> eines Datensatzes bezöge sich dann auf einen weiteren Datensatz der Tabelle. Derlei wurde in Ausgabe 09\/2105<\/b> ausführlicher dargestellt. Der Vorteil wäre eine beliebige Schachtelungstiefe von Kategorien, wie diese auch tatsächlich in vielen Webshops anzutreffen ist. Der Nachteil ist die wesentlich komplexere Auswertung solcher Tabellen und deren Darstellung in der Benutzeroberfläche. Deshalb wurde für unsere Demo davon Abstand genommen.<\/p>\n
Artikel<\/h2>\n
Der Primärschlüssel ID<\/b> der Tabelle tblArtikel<\/b> ist ein Autowert<\/b>, auf den sich eine Bestellposition in tblBestelldetails<\/b> bezieht. Zu den weiteren Features eines Artikels in tblArtikel<\/b> zählen seine Bezeichnung im Feld Produkt<\/b>, die Artikelnummer in Textfeld ArtNr<\/b>, sein Nettopreis im Währungsfeld Netto<\/b> und die vorgeschriebene Mehrwertsteuer im Prozentfeld Ust<\/b>. Daneben kann für ein Produkt auch ein Rabatt<\/b> im gleichnamigen Prozentfeld angesetzt werden. Der Standardwert beträgt hier 0<\/b>. Welche Menge des Artikel sich im Lager befindet, verzeichnet das Long<\/b>-Feld Lagerbestand<\/b>. Anzeigen<\/b> ist ein Ja\/Nein-Feld<\/b>, welches nur zu Verwaltung des Shops gedacht ist. Der Standardwert True<\/b> führt dazu, dass der Artikel im Shop aufgelistet und angezeigt wird. Ein Filter in den dafür vorgesehenen Datenquellen sorgt hierfür.<\/p>\n
Einige Nachschlagefelder und deren Tabellen vervollständigen den Entwurf. Die ID<\/b> zu einer Produktkategorie in tblKategorien<\/b> hatten wir ja schon. IDHersteller verweist auf einen Datensatz der Tabelle tblHersteller<\/b>. Und IDVerfuegbarkeit<\/b> steht in Beziehung zur Nachschlagetabelle tblVerfuegbarkeit<\/b>, welche folgende Datensätze enthält:<\/p>\n
-3    (leer)\r\n-2    Aktuell nicht lieferbar\r\n-1    Sofort (Auf Lager)\r\n0    In 2-4 Tagen\r\n1    In 5-7 Tagen\r\n2    In 8-14 Tagen\r\n3    Kann bestellt werden<\/pre>\n
Der Standardwert steht in tblArtikel zunächst auf -1<\/b>. Jeder neu eingefügte Artikel bekommt damit die Eigenschaft Sofort (Auf Lager)<\/b>.<\/p>\n
Nun soll jeder Artikel auch ein Vorschaubild zeigen. Dieses könnte man  als Anlagefeld<\/b> direkt in die Tabelle tblArtikel<\/b> aufnehmen. Tatsächlich verwenden Webshops häufig aber ein und dasselbe Thumbnail<\/b> mehrfach für unterschiedliche Produkte. Das machen auch wir. Die Bilder sind in die Tabelle tblBilder<\/b> ausgelagert, die neben dem Autowert-Primärschlüsselfeld ID<\/b> noch das Anlagefeld Bildanlage<\/b> aufweist. Die Verbindung zwischen Artikel und Bild kommt nun jedoch nicht direkt zustande – man könnte dies durchaus tun! -, sondern über die n:m-Tabelle<\/b> tblArtikelBilder<\/b>. Damit können einem Artikel optional auch mehrere Bilder zugeordnet werden. IDProdukt<\/b> verweist dabei auf den Artikel, IDBild<\/b> auf die Anlage.<\/p>\n
ähnlich verhält es sich mit den Produkteigenschaften. Die Liste der Eigenschaften befindet sich in der Tabelle tblEigenschaften<\/b> (Auszug in Bild 4).  Die Verknüpfungstabelle tblArtikelEigenschaften<\/b> verweist mit IDProd<\/b> einerseits auf die ID<\/b> eines Artikels in tblArtikel<\/b>, andererseits mit IDProp<\/b> auf eine Produkteigenschaft. Im Unterschied zum Entwurf mit den Vorschaubildern findet sich hier jedoch noch das Textfeld val<\/b>, welches den eigentlichen Wert der Eigenschaft aufnimmt. Bild 5 demonstriert, wie diese Kombination funktioniert.<\/p>\n
\"Mögliche<\/a><\/p>\n
Bild 4: Mögliche Artikeleigenschaften<\/p>\n
\"Artikeleigenschaften<\/a><\/p>\n
Bild 5: Artikeleigenschaften und Werte<\/p>\n
Obwohl das Feld IDProp<\/b> vom Typ Zahl ist, wird hier der Textwert angezeigt, weil für das Feld als Datenblattanzeigetyp ein Kombinationsfeld vorgesehen ist, das die Nachschlagetabelle tblEigenschaften<\/b> verwendet.<\/p>\n
Ein Artikel kann somit eine beliebige Anzahl von Eigenschaften und Werten für sie aufweisen. Aus deren Gesamtheit soll sich später dann das Produktdatenblatt ergeben. Für den Artikel mit der ID<\/b> 25<\/b>, ein RAM-Speichermodul, gibt es etwa die drei Eigenschaften, welche in der Abbildung ganz oben stehen. Soweit das Wesentliche zum Datenmodell des Webshops.<\/p>\n
Shop-Funktionen<\/h2>\n
Möchten Sie weiterlesen? Dann lösen Sie Ihr Ticket!<\/span>
\nHier geht es zur Bestellung des Jahresabonnements des Magazins Access [basics]<\/strong>:<\/span>
\nZur Bestellung ...<\/a><\/span>
\nDanach greifen Sie sofort auf alle rund 400 Artikel<\/strong> unseres Angebots zu - auch auf diesen hier!<\/span>
\nOder haben Sie bereits Zugangsdaten? Dann loggen Sie sich gleich hier ein:<\/span><\/p>\n<\/div>\n\n\t\n\t
\n\n\t\t\n\t\t