Office: (Office 2016) Bestellmenge vom Lagerbestand abziehen

Hallo. Ich bitte hier herzlich um Hilfe. Ich erstelle gerade für die Uni eine Datenbank. Diese soll die Kundendaten, Materialdaten sowie die Bestellungen speichern und verarbeiten.
Ich habe die drei Tabellen tblBestellungen, tblKunden und tblMaterialien erstellt und Probebefühlt. In meiner Abfrage1 möchte ich, dass die jeweilige Bestellmenge vom aktuellen Bestand abgezogen wird.
Ich lade am besten meine bisherige Accessdatei hoch. Wenn jemand hier Zeit findet mir zu helfen wäre es mega nett. Vielen Dank schon mal.

:)

 

Hallo,
in einer Datenbank speichert man keine Bestände. Der Bestand ergibt sich automatisch durch Summierung von Zugang (+) und Abgang (-).
Wenn Du den Bestand verminderst, wie kommen bei Deinen Tabellen wieder Materialien dazu, also dass sich der Bestand erhöht ?
Mir scheint, da fehlen auch noch Tabellen.
Kann ein Kunde bei einer Bestellung immer nur ein Material bestellen ?
So hast Du das nämlich, oder wie hast Du Dir das gedacht.

Nur mal vorab nachgefragt.
Die Datenbank kann ich mir erst später ansehen, da ich im Moment kein Access habe.

 

Vielen Dank für deine Antwort. Zur Zeit befindet sich noch alles im Aufbau. Gegenwärtig wird der Bestand manuell eingetragen. Ich möchte zuerst realisieren, dass wenn ein Kunde in Teil bestellt die Bestellmenge dann vom Bestand abgezogen wird. Nee ein Kunde kann natürlich mehrere Artikel bestellen.

 

Von der theoretischen Seite aus gesehen liegt Klaus mit seiner Aussage richtig - von der praktischen Seite aus gesehen, wird so ein System schnell an seine Grenzen stoßen, wenn man immer bei Adam und Eva anfangen muss, seine Zu- und Abgänge zu verrechnen, um z.B. an den Bestand einer Sache zu gelangen.

In viele Datenbanksysteme werden deshalb Materialized Views (Artikel ist leider nicht in der deutschen Wikipedia vorhanden) aufgesetzt, die in der Regel in vorgegebenen Zeitabständen Fakten (u.a. auch Bestände) abspeichern können. Access kennt so etwas nicht.

Stattdessen kann man in Access wohl-indizierte Tabellen vorhalten, die z.B. bei Geschäftsschluss oder vor Geschäftsbeginn gewisse Aggregatzustände abspeichern. Daraus ergibt sich dann z.B. für eine Bestandsermittlung nur noch die Anforderung in den jüngsten Fakten (z.B. in denen von gestern) nachzuschauen und die aktuellen Transaktionen eines Dings (Ware, Artikel, oder was auch immer) von heute damit nach der Methode von Klaus zu verrechnen. Diese Tabellen werden nie direkt bearbeitet, sondern nur über Aktionsabfragen innerhalb von Transaktionen auf dem laufenden gehalten.

D.h. dann aber auch, dass bei Änderungen an Alt-Daten oder gar beim Löschen von Alt-Daten (muss man sich wohl überlegen, ob so etwas überhaupt zuzulassen ist - oder zumindest über eine Zeitraumbegrenzung einzuschränken ist), die entsprechenden Aktionsabfragen erneut ausgeführt werden müssen, um keine falschen Fakten vorliegen zu haben. Die Problematik falscher Fakten könnte sich aber auch genauso ohne eine Fakten-Tabelle einstellen, wobei hier jedoch jegliche Kontrolle zum Gegenchecken fehlt - es sei denn, man besitzt Hardcopies (auf Papier bzw. als Pdf) oder Backups der Daten bzw. pflegt ein entsprechendes Audittrail.

Ein bekanntes Beispiel für eine Faktentabelle (leider auch nicht auf deutsch) ist z.B. auch eine hier im Forum öfter schon erwähnte Datumstabelle, in der viele redundante Daten (Feiertag, Tag des Jahres, Tag der Woche, Tag des Monats, Tag des Jahres, Kalenderwoche, etc. pp.) vorliegen. Diese Fakten ließen sich auch alle in Abfrage(n) errechnen, beschleunigen jedoch den Datenzugriff bei größerem Datenbestand enorm.

Je nach anfallender Datenmenge sollte man auch in Erwägung zihen, die Fakttabellen in einem separaten Backend zu führen.

Zusammengefasst: Fakt-Tabellen speichern redundant Aggregate ab und beschleunigen dadurch den Datenzugriff, weil sie viele Berechnungen und Joins auf ein Minimum reduzieren oder ganz entbehrlich machen. Sie sollten auch nicht als Bestandteil des Datenmodells aufgefasst werden.

PS: bei nur ca. zehn Warenbewegungen je Tag kann man auch lange Zeit ohne diese Tabelle(n) performant in Access arbeiten.

 

Vielen Dank für die ausführliche Erklärung. Jedoch benötige ich es nicht so ausführlich. Wie gesagt ist nur eine Hausaufgabe für die Uni. Ich benötige eher Unterstützung bei der technischen Realisierung. Wie oben beschrieben.

 

Moin,

auch wenn es nur eine Hausaufgabe ist, wird wohl kein Weg dran vorbeiführen, die Bestandsänderung an einem Ereignis festzumachen. Dieses Ereignis ist übrigens nicht der Aufruf einer Abfrage, sondern der Versand respektive der Wareneingang.

An Deinem Muster ist übrigens sehr schön zu sehen, welch Quark entsteht, wenn Beziehungen nicht mit Bedacht aufgebaut werden: In der Bestellung taucht 3mal der Name "Muster" für den Besteller auf, allerdings ohne den Vornamen. Sowas nützt dem Sachberbeiter nichts.

Bau Dir eine Tabelle namens Lagerbewegung, in die trägst Du pro Artikel alle Wareneingänge und Auslieferungen mit einem Kennzeichen +/-, Zugang/Abgang o.ä. ein. Der Bestand ergibt sich dann aus der Summe der Bewegungen.

Jede Bestellung hat Positionen, die müssen in eine eigene Tabelle, Fremdschlüssel Bestellnummer und Artikelnummer.

 

Nun, eine Bestellung ist zuerst einmal nur eine Anforderung (demand), die keinen Bestand beeinflußt. Erst eine Auslieferung (delivery, shipment) würde eine Bestandsmenge reduzieren. Tja, und ohne Datum sind Bestell- bzw. Auslieferdaten eher als bescheiden einzustufen. Und zum Anderen wird eine Auswahlabfrage allerhöchstens den Bestand nach der Bestellung anzeigen können - für eine permanente Änderung müsste eine Aktualisierungsabfrage verwendet werden.

PS: Hausaufgaben sollte man besser selbst lösen und ggf. bei einem Tutor/Assistenten Hilfe erbitten - oder hast Du die entsprechende(n) Vorlesung(en) versäumt?

 

Ich schleppe das Fach seit dem 2.Semester mit mir. Eine Aktualisierungsabfrage probiere ich auch. Habe auch schon was im Netz gefunden nur funktioniert das nicht. Deshalb hier das Thema mit der Bitte um Lösung.

 

Dir eine Lösung zu basteln, grenzt an Betrug. Ich schlage vor, dass Du die Vorlesung(en) noch einmal besuchst.

 

Es ist doch keine Lösung. Ich habe doch nur um eine Detailsache hier gebeten. Die Aufgabe ist damit nicht gelöst. Momentan ist die hier hochgeladene Datei nur ein Entwurf von mir und hat mit der Aufgabe nichts zu tun. Ich möchte nur wissen wie es technisch geht.

 

Zur Aktualisierungsabfrage: Nur bei Vorliegen entsprechender Datensätze in anderer Tabelle Änderungen vornehmen.

 

Das würde dann bei jedem Aufruf der Abfrage passieren.

 

Wenn der Fragesteller sich im Zustand größerer Unklarheit befindet, ist es doch nur allzu gerecht, auch die anderen im Trüben fischen zu lassen. So kann man schön aneinander vorbeireden - bspw. ist ein wirkliches weil inhaltliches Feedback auf die sehr ausführlichen Hinweise von Nouba nicht wahrnehmbar - und einen Never-Ending-Thread gestalten.

Zur Kenntnis von Techniken (auch): Sql-Tutorial: Lernen Sie Sql

 

Ok, das mit SQL habe ich verstanden. Wie schreibe ich den die SQL-Anweisung wenn die Datensätze in verschiedenen Tabellen sind? Also als Beispiel:
In der Tabelle Material ist der Bestand
In der Tabelle Bestellungen steht die Anzahl der Bestellungen.
Beim Aufruf von einer Abfrage soll vom Bestand die Anzahl der Bestellungen abgezogen werden.

 

Hallo,
Du machst hier schon weitere Schritte, obwohl das Datenmodell noch völlig untauglich ist.Du bist mit den 3 Tabellen gar nicht in der Lage zu einer Bestellung mehrere Materialien zu erfassen. Weiterhin fehlt noch (mindestens) eine Tabelle zur Erfassung der Zugangsmengen.
Und bei der relativ einfachen Aufgabe würde ich keinen Bestand speichern, sondern den Bestand aus Zugang und Abgang errechnen. Vereinfacht sieht das so aus:

Code:

Da wird auch keine Aktualisierungsabfrage benötigt, es gibt ja kein Feld für den Bestand. Das kann alles ohne VBA mit SQL Auswahlabfragen in der Entwurfsansicht realisiert werden. Mit ganz normalen Bordmitteln von Access.