Datenmodell Kleiderkammer

[Felix Spangenberg]

Hallo Zusammen,

ich bin relativ neu mit Access unterwegs und lese gerade das Buch "Keine Angst vor Microsoft Access" von Andreas Stern. Zur praktischen Übung möchte ich gerne eine Datenbank zu Verwaltung der Kleiderkammer meines Arbeitgebers erstellen.

Ein erstes Datenmodell steht schon, doch stehe ich irgendwie auf dem Schlauch, welche Tabellen und Beziehungen ich den nun genau brauche.

Hintergrund ist:
- Wir beschäftigen Mitarbeiter, diese werden mit Produkten ausgestattet (Hosen, Pullover, Jacken, Equipment etc.)
- Die Produkte werden bei uns in einem Lager eingelagert
- Ich möchte jeder Zeit meinen Lagerbestand (Anzahl der Teile und Anzahl*Einkaufspreis = Lagerwert) sehen, unabhängig, ob ein Teil der Produkte sich bei Mitarbeitern befinden oder nicht. Es gibt also immer wieder Einkäufe und auch Entsorgungen (Arbeitskleidung geht mal kaputt), die saldiert den Lagerbestand ergeben.
- Nur das was sich auch im Lager befindet, kann an Mitarbeiter rausgegeben werden. (Logischerweise... Sind keine Arbeitshosen mehr im Lager, kann ich einem neuen Mitarbeiter auch keine geben).

Nun habe ich zu Erfassung der Ein- und Ausgänge von Produkten eine tblLager erstellt, die Verknüpft ist mit der tblProdukte und tblBewegungsart (Unterscheidung ob Einkauf oder Entsorgung)

Mir ist jetzt nicht ganz klar, wie ich die Ausgabe der Kleidung an die Mitarbeiter erfassen soll. Benötige ich eine Zwischentabelle für tblMitarbeiter und tblProdukte? Aber dann habe ich keine Verknüpfung mehr zum Lagerbestand, der sich ja aus der tblLager ergibt, oder?

Vielleicht ist jemand so nett und schaut sich mein Datenmodell einmal an und entwirrt meinen Gedankenknoten?

Vielen Dank schon mal im Voraus!

Gruß, Felix

[Lachtaube]

He Felix,

ein Lager ist nur eine Ortsbeschreibung. Kleidungsstücke gelangen an den Ort, wenn neue Kleider produziert oder eingkauft werden (oder ggf. vom Mitarbeiter zurückgegeben werden). Das wäre dann eine Handlung zu einem Zeitpunkt. Kleidungsstücke verlassen das Lager, wenn sie verkauft oder an Mitarbeiter ausgegeben werden, was auch eine Handlung zu einem Zeitpunkt darstellt. Zusätzlich käme noch die Erklärung eines Mitarbeiters über den untragbaren Zustand eines Kleidungsstücks, sowie Inventur(-Korrekturen durch Mottenfraß, oder falsche Buchführung, o.ä.) hinzu.

Bei nicht allzu großen Bewegungen, kann man die Zu- und Abgänge aus dem Lager dann in einer Tabelle mit Faktor erfassen. Abfragen, am besten ab dem letzten Inventurdatum (, um nicht jedes mal bei Adam und Eva starten zu müssen), sollte dann den theoretischen Istbestand der Kleidungsstücke am Lagers und bei den Mitarbeitern ausgeben können.

[Felix Spangenberg]

Hallo

danke für deinen Input. Aber wie bilde ich diese Zu- und Abgänge konkret ab? Ich habe Produkte, ich habe Mitarbeiter. Reicht es, wenn ich eine verknüpfende Tabelle erstelle, in der die Zu- und Abgänge (Neukauf, Entsorgung) und Ein- und Ausgaben (Mitarbeiter bekommt Kleidung und gibt sie wieder ab) mit Datum, Anzahl und Einkaufspreis pro Stück erfasse?

Ich will ja zukünftig auf Knopfdruck sehen, was ich insgesamt an Bestand habe (in Anzahl und Wert), was davon noch frei verfügbar im Lager liegt und welche Teile jeder einzelne Mitarbeiter hat.

Aber ich glaube, ich komme langsam dahinter.... Es reicht tatsächlich eine Tabelle. Darin wird erfasst Art der Bewegung (Einkauf, Entsorgung, an Mitarbeiter, von Mitarbeiter) die Anzahl und der Einkaufspreis. Verknüpft mit tblProdukt und tblMitarbeiter. Die Zuordnung zum Mitarbeiter dient dabei nur als Ortsangabe. Ist das Equipment bei keinem Mitarbeiter, muss es im Lager sein (steht der Zuordnung also zu Verfügung).
Ich möchte ja erfassen können, dass 5 Hosen am 01.01. ins Lager kommen, dann 15 Hosen am 01.02. In meiner Tabelle sind das dann zwei Zeilen. Saldiert habe ich dann richtigerweise 20 Hosen. Nun gehen 2 Hosen am 01.03. an Mitarbeiter XYZ. (dritte Zeile). Saldiert habe ich dann noch 18 Hosen im Lager und immer noch 20 im Gesamtbestand.

Über Abfragen kann ich dann doch jeweils ausgeben, welcher Mitarbeiter wie viele und welche Produkte hat, wie viele im Gesamtbestand sind und was deren Gesamtwert ist, oder?

Also eine Tabelle für alles... richtig?

Gruß, Felix

[Lachtaube]

Eine Tabelle stellt den Idealfall dar. Für Wertfindungn im Sinne der Vermögenssteuer müssten die guten Stücke zumindestest etikettiert sein, denn es kann ja sein, dass gleiche Stücke zu unterschiedlichen Preisen eingekauft wurden. Ob (z.B.für Ladenhüter) Abschreibungskosten geltend gemacht werden können, kann ich nicht beurteilen.

[Felix Spangenberg]

Ich weiß nicht, was du mit Vermögenssteuer und Abschreibungen mir sagen willst. Die Arbeitskleidung, die unsere Firma kauft, wird natürlich abgeschrieben.

Was meinst du mit "eine Tabelle stellt den Idealfall dar"?.

Ich habe meine Datenmodell nochmals überarbeitet (siehe Anhang). Aus der tblLager ist die tblBestand geworden. Dort werden alle Ein- und Ausgänge reingeschrieben. Ich stelle es mir dann so vor, dass ich mittels Abfragen dann sagen kann "Zeig mir alle Anzahl aller Produkte die eingegangen sind abzüglich der Anzahl der entsorgten Produkte (=Gesamtbestand)", "Zeig mir die Anzahl aller Produkte, die an Mitarbeiter XYZ übergeben wurden abzüglich derer, die er schon wieder zurückgegeben hat (= Welche Produkte hat Mitarbeiter XYZ aktuell), "Zeig mir die Anzahl der Produkte die Eingegangen sind, abzüglich der entsorgten, die bisher noch keinem Mitarbeiter zugeordnet wurden (= Produkte die im Lager liegen und einem Mitarbeiter zugeordnet werden könnten)"... etc. pp.

Gehe ich da den richtigen Weg?

Wie gesagt, ich kenne mich mit Access noch nicht so aus und möchte erstmal grundsätzlich wissen, ob das mit meinem Datenmodell so funktionieren kann.

Ich habe die Datei nochmals angehängt. Ist es richtig, dass man keine accdb-Dateien hochladen kann?

Nochmals Danke, Felix

[MzKlMu]

Hallo,
was willst Du mit dem Stückpreis beim Bestand ?
Der Stückpreis gehört doch zum Produkt ?

In der Tabelle für die Bewegungsart fehlt ein Feld für den Faktor (-1 oder 1) um automatisch das Vorzeichen für die Summierung zu setzen.

PS:
Alle Dateien die man hier hochläd sollte man aus Platzgründen Zippen. Auch eine MDB. Eine ACCDB muss gezippt werden.

[Lachtaube]

Nun Felix, ich habe mir die Datei jetzt zwar nicht angesehen, aber das Geschilderte sollte realisierbar sein.

Zum Namen; den würde ich anders wählen, denn eine Bestandsaufnahme wäre nur eine Handlung von vielen, die zu Änderungen der errechneten Menge führen kann. Ein Name wie LagerBewegung, LagerTransaktion, o.ä. lässt IMO erkennen, dass hier etwas bewegt wird. Die Art der Bewegung kann ja über eine weitere Tabelle in Form eines Fremdschlüsselfelds identifiziert werden.

PS: Du hast zuerst den Begriff Wert verwendet, der vielerlei Interpretationen erlaubt. Darüber, dass Wert und Preis unterschiedliche Begriffe sind, sollte Einigkeit bestehen.