Aufbau eines Einkaufspreis-Vergleiches

Hallo zusammen,

ich möchte mich privat etwas in Access einarbeiten, da ich einige Dinge habe, bei denen ich in Excel an meine Grenzen stoße.
Zur Verfügung habe ich Access 2021 (und auf einem 386er Access 2.0)

Als Übungsprojekt dachte ich mir einen Vergleich der Einkaufspreise von Lebensmittel, etc., also die Erfassung und Auswertung meiner Einkäufe.
Sinnbildlich: heute kaufe ich z.B. 1kg Mehl in Laden A und nächste Woche in Laden B.

Mir geht es weniger um die Bedienung des Programmes, sondern welche Tabellen brauche ich und was muss in welcher eingetragen werden.
Sprich den Aufbau des Grundgerüsts.

Die "Bedienung" stelle ich mir so vor:
Ich habe ein Formular zur Eingabe des Ladens (hier reicht eine Zeile für Laden A, Laden B, etc.),
eines für die Produkte (z.B. Mehl, Hersteller, Typ)
und die Einkäufe (Datum, Laden und Produkt [evtl aus Dropdown-Liste] und den Preis.

Bei der Auswertung möchte ich dann wissen, nehmen nochmal das Mehl, welchen Preis ich wann bei welchem Laden bezahlt habe.

Ich hoffe, ich konnte mein Anliegen einigermaßen verständlich ausdrücken und bedanke mich schon mal für Eure Hilfe.

Gruß
Robert

Viel brauchst Du dafür nicht, Du hast es schon beschrieben. Aber der Appetit kommt beim Essen.

Die Tabelle mit den einzelnen Einkäufen:
ID
ShopRefID
Hersteller
Produktbezeichnung
Produktname
Verpackungseinheit
Menge
Preis

Wenn Du das ein paar Tage gemacht hast, willst Du vielleicht das Produkt auch wählbar machen und brauchst wie für den Shop auch eine Tabelle für die Produkte.
Wenn ich sowas machen würde, würden mich auch bestimmte Produktmerkmale interessieren.
Salami, italienische Salami, Aufschnitt, abgepackt, usw.
Ohne die ist ein Produktvergleich nicht so aussagekräftig finde ich.

Servus,

schonmal Danke für die Antwort.

Das mit den Merkmalen ist schon richtig, spielt für mich aber nur eine untergeordnete Rolle.
Es ist so, ich mache meinen Wocheneinkauf meist Freitags nach der Arbeit und habe meine 2-4 Läden in denen ich je nach Produktangebot und -Bedarf einkaufe. Wenn ich mal nicht so viel brauche, gehe ich manchmal nur in einen Laden, auch wenn jetzt mir, um Dein Beispiel zu nehmen, die Salami aus einen anderen Laden besser schmeckt. Nur fahre ich nicht wegen "einer Wurst" ans andere Ende der Stadt.

Daher reicht es mir, wenn ich weiß, aha, Salami hat hier xx,xx€ und woanders so viel, ob das nun Marke A oder Marke B ist.
Klar, hier werden Äpfel mit Birnen verglichen, aber hauptsache Obst, wenn Du verstehst was ich meine.

Wenn Du das ein paar Tage gemacht hast, willst Du vielleicht das Produkt auch wählbar machen und brauchst wie für den Shop auch eine Tabelle für die Produkte.

Zum Vergrößern anklicken....

Genau das habe ich gemeint, wie muss der Aufbau sein.

Ich habe mir natürlich schon ein paar Tutorials, Videos und Beschreibungen angesehen.
Aber bei einem war das so kompliziert aufgebaut, jeder Eintrag in eine eigene Tabelle und zig-fach verknüpft um möglichst viele Filtermöglichkeiten zu erhalten. Deshalb habe ich mich an das Forum gewendet.

Mir ist halt der Zusammenhang nicht so ganz klar, bzw. die "Mechanik" dahinter.
Es ist im Prinzip so ähnlich wie bei einem Rechnungsprogramm, denn da habe ich auch schon geschaut und versucht zu verstehen.
Für eine Rechnung habe ich eine Rechnungsnummer (in meinem Fall das Datum) einen Kunden (bei mir die Läden), aber mehre Einträge für die Produkte. Da habe ich eben noch den Knoten im Kopf.

Hallo Bobby85cr,
wie dabadepdu schon schreibt, kommt der Appetit meistens mit dem Essen.
Wenn es Dir hauptsächlich um die schnelle Umsetzung deiner Anwendung geht findest Du bei den Standardvorlagen sicher etwas, was Du für deine Zwecke nutzen kannst: Access-Vorlagen

Geht es Dir um das Lernen von Access, so ist das nicht mal eben so gemacht. Die Lern- und Erfahrungskurve ist bei Datenbanken eine andere als z.B. bei Excel. Wie Du schon sagtest, verheddert man sich schnell in zig Tutorials und Videos, weshalb hier systematisches Vorgehen Sinn macht. Dass Du bereits eine konkrete Vorstellung Deiner Anforderungen hast, gibt der ganzen Sache schon mal einen roten Faden. Aber, um nachher nicht ein wirres Knäuel daraus zu machen ist etwas Grundlagenwissen unentbehrlich. Zu empfehlen ist dabei das Access-Tutorial. Es ist nicht zu langatmig, gut verständlich und geht in der richtigen Reihenfolge vor.

Das A und O ist die Struktur der Tabellen und ihrer Beziehungen zueinander. Dazu solltest Du Dir Begriffe wie "Normalisierung einer Datenbank", "Index/Primärindex (Schlüssel und Fremdschlüssel" und "referentielle Integrität" ansehen.
Gut ist auch die verschieden Datentypen zu kennen (String, Integer, Datum usw.)

Vermeide bei der Anlage Deiner Tabellen "Nachschlagefelder" und den Datentyp "berechnetes Feld". (Wer das in Access gefriemelt hat gehört heute noch ....naja.) Da veranstalltet Acces intern dann Dinge, die sich nicht unbedingt immer nachvollziehen lassen. Das macht man alles nachgelagert in Abfragen und dann Formularen/Berichten.
Noch ein Begriff: Alle Daten in den Tabellen sollten "atomar" sein, also nur an einer Stelle in der Datenbank gespeichert sein. Es macht also keinen Sinn bei jedem Einkauf den Namen und die Strasse des Ladens einzutragen. Sondern dafür gibts eben eine Tabelle "Läden". Das Gleiche gilt für die Produkte als solche: Apfel ist Apfel, Wurst ist erstmal Wurst usw.. Und dann wirds schon interessant. Nicht jedes Produkt gibts in jedem Laden. Da kommen dann Tabellenbeziehungen ins Spiel (1:n, m:n).
Deine eigentliche Tabelle "Einkäufe" benötigt dann nur noch wenige Felder: LadenID, ProduktID, Datum, Preis und Menge (Menge, damit der Gesamteinkaufswert später berechnet werden kann.)

Dann würde ich ein paar Testdaten in die Tabellen eintragen. (Formulare zur Erfassung kommen später, weil dort dann auch zusätzliche Prüfungen, über die eigentliche Integritätsprüfungen hinaus, gemacht werden.)

Dann frage dich, welche Auswertungen du möchtest. Erzeuge dazu nicht schon Berichte oder Formulare, sondern trage die gewünschten Datenergebnisse über Abfragen zusammen.

Erst dann macht man die DB anwenderfreundlich. Soll heißen, Fehlervermeidung und Komfort bei der Dateneingabe über Formulare. Übersichtliche Berichte erzeugen.

Ich hoffe das hilft ein wenig weiter. Wenn Du Deine ersten Versuche gestartet hast lade ruhig mal das Ergebis hier hoch oder melde Dich, wenn es Probleme gibt.

Hallo andyfau,

auch Dir vielen Dank für Deine Antwort.

Datentypen an sich sind mir schon bekannt, da ich gerne an meinen alten Kisten (C64, 286er, 386, 486er, habe ein halbes PC-Museum) u.a. mit Basic programmiere und rumexperimentiere.

Auch klar ist, wie bei Programmiersprachen, man wächst mit seinen Aufgaben. Es ist ja kein Schulprojekt, dass in 2 Wochen fertig sein muss.
Mir denoch wichtig, wie Du auch geschrieben hast, nicht einfach "loszuwurschteln" und 1000x neu anfangen, sondern gleich saubere Strukturen zu lernen. Deshalb wende ich mich an Euch.

Das von Dir verlinkte Tutorial gehe ich mal durch, denn ganu das ist ja mein Anliegen um nicht nach dem Motto "bringt mir bitte programmieren bei" zu handen und gar nicht zu wissen was man eigentlich will.

Noch ein Begriff: Alle Daten in den Tabellen sollten "atomar" sein, also nur an einer Stelle in der Datenbank gespeichert sein. Es macht also keinen Sinn bei jedem Einkauf den Namen und die Strasse des Ladens einzutragen. Sondern dafür gibts eben eine Tabelle "Läden". Das Gleiche gilt für die Produkte als solche: Apfel ist Apfel, Wurst ist erstmal Wurst usw.. Und dann wirds schon interessant. Nicht jedes Produkt gibts in jedem Laden. Da kommen dann Tabellenbeziehungen ins Spiel (1:n, m:n).
Deine eigentliche Tabelle "Einkäufe" benötigt dann nur noch wenige Felder: LadenID, ProduktID, Datum, Preis und Menge (Menge, damit der Gesamteinkaufswert später berechnet werden kann.)

Zum Vergrößern anklicken....

So ist es. Wie ich eingangs geschrieben habe, möchte ich später Läden und Produkte aus einem Auswahlfeld hinzufügen können.

Menge und Gesamtsumme sind für mich auch nicht so relevant, da ich dann nur Einzelpreise erfassen möchte.
Angenommen die Datenbank besteht sauber seit einigen Jahren und ich kaufe heute einen Apfel und eine Dose Kokosmilch.
Da gebe ich dann kg bzw. Liter-Preis ein.

Zur Auswertung möchte ich eine Liste haben, in der steht, z.B. innerhalb des letzten Jahres habe ich für ein kg Äpfel (egal ob Golden Delicious oder Fiesta) zu diesem Zeitpunkt in diesem Laden gekostet.
Habe schnell in Excel ein kleines Beispiel zusammengezimmert (siehe Screenshot) was so meine Intension ist.

Beispiel Datenbanken habe ich schon einige angesehen, bin aber nicht so recht damit klargekommen, sie auf meine Bedürnisse anzupassen.

Mir ist schon klar, was Du möchtest. Die Aufgabe ist geradezu prädestiniert sie mit Hilfe einer kleinen Datenbankanwendung zu lösen. Der Aufwand dafür ist in Access minimal, wenn die Grundkenntnisse vorhanden sind und die notwendigen Konventionen eingehalten werden. Aber es bringt ja nun nichts jetzt hier eine schnelle Lösung zusammen zu bauen. Anfangen musst DU in Access und mit Access. Der Ausbau läuft dann, vielleicht mit ein paar Tipps hier im Forum, von selbst.
Für den Anfang, definiere doch erstmal Deine Tabellen und zeige dann hier das Beziehungsfenster oder lade den ersten Versuch hier hoch. Dann hat man was, was kommentiert und ggf. berichtigt werden kann.

aye aye Kapitän

So, da bin ich wieder.

Ich habe das Tutorial für die Tabellen durchgelesen und mal ein noch nicht ganz vollständiges Grundgerüst entwickelt.

Die Eingabe der Läden und Produkte kann, denke ich, rein über die Tabelle erfolgen.
Ist am Anfang zwar nicht so komfortabel, aber wenn mal alle relevanten Produkte meines wöchentlichen Bedarfs erfasst sind, sollte das eine untergeordnete Rolle spielen.

Allerdings ist mir noch nicht klar, wie ich das mit dem Einkauf realisieren soll.
Zur Erfassung des Einkaufs stelle mir ein Formular vor, oben das Datum, darunter ein Listenfeld für den Laden, darunter evtl. eine Tabelle für die Produkte.
Produkt (aus Listenfeld), Einheit (mit Produkt verknüpft), Preis (manuelle Eingabe)

Schön wäre, wenn ich das Datum nur einmal pro Einkauf und den Laden einmal für alle dort gekauften Produkte eingeben müsste.
Habe dazu einen Screenshot zusammengebastelt, damit man sich das besser vorstellen kann.

Aber über Formulare & Co. können wir uns später unterhalten, jetzt müssen erstmal die Tabellen sauber angelegt werden.

Es übersteigt immer noch meine Vorstellungskraft wie ich im einzelnen die Tabellen anlegen muss um die Daten wie im zweiten (etwas unprofessionellen) Screenshot einzugeben, bzw, wie sie verlinkt werden müssen.

Ich kann deine Datenbank leider nicht öffnen. Ich habe Access 2016. Du wahrscheinlich 365 oder 2024 und benutzt Features, die 2016 noch nicht hatte. Kannst Du sie in einer älteren Version speichern?

Guten morgen,

sodele, die 11 Uhr Runde auf Kurzwelle ist beendet.


Das ist natürlich blöde.

Meine Version siehe Screenshots.
Leider lässt sich das nicht runterspeichern, da die Primärschlüssel long integer verwenden. Oder hast Du mir eine Idee?
Weil Berechnungen, Makros, etc. hab ich ja noch nicht drin

OK, dann hier mal ein Beziehungsfenster mit den Tabellen und ein paar Beispieldaten.

Diese Version erzwingt, dass bei der Eingabe eines Einkaufs der Laden, das Produkt und die Mengeneinheit hinterlegt sein müssen. Über die Tabelle Sortimente wird zusätzlich erzwungen, dass es das jeweilige Produkt auch in dem jeweiligen Laden gibt. Dies geschieht durch die Doppelbeziehung zwischen Sortimente und Einkaufs_Positionen. Da lässt sich dann diskutieren, ob eine Tabelle Einkaufskopf überhaupt notwendig ist. Die Felder sind in den Positionen ja redundant notwendig, um diesen Sortimentszwang zu erzielen. Willst Du diesen Zwang nicht, lösche die Beziehungen zwischen Sortimente und Einkaufspositionen. Dann würde ich aber zumindest jeweils eine 1:n-Beziehung zwischen tbl_Einkaufe_Kopf.LadenID und tbl_Laeden.LadenID, sowie zwischen tbl_Einkaufe_Positionen.ProduktID und tbl_Produkte.ProduktID herstellen, damit zumindest die Laden-, bzw. Produktexistens geprüft wird.


Die Tabellen stellen sich dann so dar, wobei es nicht möglich ist nicht vorhandene Laden/Produkt-Kombinationen zu erfassen.

Über den Formularassistenten läßt sich dann im Handumdrehen ein Erfassungsformular erstellen, welches dann um die Klartexte und Berechnungen ergänzt werden kann. Mit den ganzen ID-Feldern ist das noch nicht wirklich handhabbar. Aber dazu später mehr. Schau erstmal, ob das so für dich nachvollziehbar ist.

Hallo Andreas,

vielen Dank für Deine Ausführungen.

Habe die Datei nochmal neu in einer älteren Version angelegt.
So ganz ist mir das noch nicht klar, auch das mit mehreren Schlüsselsymbolen.

Die Produktverknüpfung zum Laden brauche ich nicht, hat z.B. ein Laden ein Produkt mal im Angebot, was er sonst nicht hat, wäre das zu kompliziert. Z.B. Werkzeuge im Lebensmitteldiscounter o.ä..

Bin mit meiner Datei zwar noch nicht so weit wie in Deinen Screenshots, aber evtl. kannst mal drüberschauen, ob das grundsätzlich passt.
Hab auch noch nicht alle Eigenschaften gesetzt, falls ich doch nochmal von vorne anfangen muss.

Vorab: die Präfixe vor den Tabellennamen (tbl) und später vor den Abfragen (q=query) , Formularen (fm) und Berichten (rep=report) sehe ich als durchaus sinnvoll an, weil man dann immer sofort sieht an welchem Objekt man arbeitet. Präfixe vor Feldnamen in den Tabellen halte ich für kontraproduktiv, erst recht, wenn dann z.B. ein txt... davor steht, ob wohl es sich um ein numerisches Feld handelt. Den Suffix ...ID verwende ich nur für Felder, die einen (numerischen) Primärindex beinhalten. Dieser ist in der Regel auch vom Feldtyp Autowert. Außnahme ein kombinierter Primärindex wie hier in der tblEinkPos. Da muss manuell (oder per Programmfunktion) sichergestellt werden, dass die Positionen einer EinkaufID numerisch aufsteigend vergeben werden.

Wobei wir bei der ersten, größeren Baustelle in deiner DB wären. Das Prinzip von Schlüsseln(Indexe) und Fremdschlüsseln. Ein Primärindex ist immer eindeutig. Deshalb bevorzuge ich diese. In der Positionstabelle habe ich einen kombinierten Primärschlüssel angelegt. Dieser ist immer in seiner Kombination eindeutig. Über die Fremdschlüssel finde ich immer automatisch den Weg zu korrospondierenden Daten, wie z.B zur ProduktID die Produktbezeichnung oder zur MengeneinheitID die Mengeneinheit. So muss ich in der Positionstabelle nur die ID ablegen und nicht die langen Textfelder, was in großen Datenbanken ein großer Performancevorteil ist. Die Verarbeitung von Integerwerten erfolgt wesentlich schneller als die von Strings.

Mit der obigen Struktur lässt sich nun eine Abfrage erzeugen die als Grundlage eines Erfassungsformulars und späterer Auswertungen dienen kann. Wenn Du damit mal rumspielst wirst Du am Verhalten merken welche Restriktionen nun aufgrund der Konstruktion vorhanden sind. Z.B. erhält man immer eine neue EinkaufsID, wenn man nicht explizit eine vorhande ID angibt. Doppelte PositionsIDs innerhalb einer EinkaufID sind nicht möglich. Ein Produktname erscheint automatisch wenn eine vorhandene ProduktID eingegeben wird.
Achtung, überschreibt man nun die Produktbezeichnung wird sie u.U. in der Tabelle tblProdukte überschrieben, wenn in den Beziehungen Aktualisierungsweitergabe gewählt wurde. Noch fataler kann es sein wenn man in den Beziehungen Löschweitergabe an untergeordnete Tabellen gewählt hätte. Löscht man aus der Tabelle Laeden einen Laden werden dann z.B. alle Einkäufe des Ladens auch gelöscht! Also immer genau die Beziehungseigenschaften anschauen! Bei der Beziehung Einkaufskopf zu den Positionen ist dagegen eine Löschweitergabe durchaus sinnvoll. Denn soll ein Einkauf gelöscht werden, müssen natürlich auch alle Positionen dieses Einkaufs mit gelöscht werden, damit die Datenbank konsistent bleibt.
Die Eingabe über das Datenblatt einer Abfrage ist aber genauso wenig im Sinne des Erfinders, wie auch die Eingabe von Daten direkt in Tabellen.


Der nächste Schrit ist dann der Bau von entsprechenden Erfassungsformularen.....

Hallo Andreas,

ich denk, nun bin ich mal ein ganzes Stück weiter, auch was das Verständnis angeht.
Die "txt"-Präfixe habe ich entfernt, hatte das vom Tutorial übernommen.

Für die Eingabe von Läden, Mengeneinheiten und Produkten habe ich mal einfache Formulare erstellt, die meinen Anforderungen fürs Erste genügen sollten.

Bei den Beziehungen habe ich die "Updates" deaktiviert, macht auch Sinn so wie Du das beschrieben hast.

In den Tabellen habe ich noch sämtliche Zeilen-Eigenschaften gesetzt, welche zwingend erforderlich und indiziert (mit und ohne Duplikate) sein sollen.

Es sind noch Fehler in den Tabellen:
-Zuerst musst Du alle Beziehungen zwischen den Tabellen nochmal löschen,
-Lösche dann aus ALLEN Tabellen alle Indizes, außer dem Primärindex. Gehe dazu in die Entwurfsansicht der Tabelle / Entwurf/Indizes.


Gebe beim Feld EinkDatum das Format "Datum, kurz" und Standardwert "Datum ()" vor.


Die Tabelle tblEinkPos benötigt den kombinierten Primärkey:


Die Felder sollten auch in der o.g. Reihenfolge sein und ein Mengenfeld sollte doch rein, oder?

In der Tabelle tblProdukte solltest Du das Feld Mengeneinheit in MengenID umbenennen, denn es ist ja der Fremdschlüssel zur ID in der tblMengeneinheiten.

Dann die Beziehungen wieder neu einrichten. Alle mit referentieller Integrität und Aktualisierungsweitergabe. Nur die Beziehung zwischen Einkäufe und EinkPos zusätzlich mit Löschweitergabe anlegen.



Die Abfrage qEinkauf muss neu erstellt werden, weil sich in den Tabellen Indizes und Beziehungen geändert haben.

Die vorhandenen Formulare können als Grundlage erstmal bleiben.

Spannend wird es nun mit der Erstellung eines Erfassungsformulars für Einkäufe.
Versuche es einfach mal mit dem Generator.....