Brauche hilfe bei einen Lagerdatenbank in Access.
Ich möchte folgendes Verwalten:
Artikel
Größen
Bestand
Eingang
Ausgang
Ich möchte keine Artiklenummer haben.
Wer kann mir helfen?
Danke
Hallo und guten Tag zunächst…
Brauche hilfe bei einen Lagerdatenbank in Access.
Ich möchte folgendes Verwalten:
Artikel
Größen
Bestand
Eingang
AusgangIch möchte keine Artiklenummer haben.
Wenn Artikel verwaltet werden sollen, dann ist zwingend auch eine Artikelnummer von Nöten.
Wer kann mir helfen?
vermutlich alle, wenn Du zunächst die Grundlagen eines relationalen Datenbanksystems durcharbeitest und die Tabellen(!) entspr. den Normalisierungsregeln aufbaust.
btw: Bestände werden nicht in Tabellen gespeichert, sondern anhand einer Bewegungstabelle (Erfassung von Ein- und Ausgängen) berechnet
Gruß
Franz, DF6GL
eine Artikelnummer ist nicht zwingend notwendig wenn das Paar Artikel(name?) und Größe immer eindeutig sind können auch diese beiden Felder gemeinsam als Schlüssel verwendet werden. Mir fällt aber grade kein Grund ein warum man nicht eine Artikelnummer (und sei es nur eine automatisch inkrementierende fortlaufende Nummer) verwenden sollte.
Hallo und Guten Morgen,
danke für die Tipps für meine Datenbank.
Kann mir einer sagen wieviele Tabellen ich brauche um eine saube auswertung fahren kann?
Danke.
Das kann ich so nicht stehen lassen. Wohl wahr, wenn es sich NUR um diese EINE Tabelle handelt (hier wäre ein solcher „Surrogatschlüssel“ tatsächlich überflüssig) , wobei man dann aber auch nicht von einer „Lagerdatenbank“ reden kann.
Spätestens wenn eine „Bewegungstabelle“ zur Erfassung von Lagerein- und -ausgängen hinzukommen soll, (und bei dieser einen Tabelle wird es nicht bleiben, wenn das Ganze nun auch ernsthaft und vernünftig betrieben werden soll), wird es schon schwierig, ref. Integrität einzufordern, geschweige denn „einfache“ SQL-Statements abzusetzen oder auch Auswertungen zu betreiben. Zur Verhinderung von „Dupletten“ (gleicher Artikel(name) und Größe) ist der angesprochene zusammengesetzte Index empfehlenswert.
Weiterhin gibt es viele Argumente für einen daten-unabhängigigen Primärschlüssel, z. B die Vermeidung von gebrochenen Relationen im Fall einer auch nur geringfügigen Änderung des Artikel-Textes (-name,- bezeichnung). Das heißt aber nicht, dass ein solcher Prmärschlüssel („Artikelnummer“) unbedingt numerisch sein muss. Z. B. kann man sich bei einer Fahrzeugkennzeichen-Verwaltungsdatenbank durchaus auf das Kennzeichen selber als Primärschlüssel in der entspr. Tabelle einigen (wenn man gewisse Vereinbarungen einhält, z. B. keine Leerzeichen oder Ähnliches zulässt, was aber halt wiederum den „Aufwand“–> Plausiprüfungen erhöht)
Wie auch immer, die Diskussion um das für und Wider eines Surrogatschlüssels ist schon so alt wie relationale Datenbanksysteme verwendet werden.
Hallo,
Hallo und Guten Morgen,
danke für die Tipps für meine Datenbank.
Kann mir einer sagen wieviele Tabellen ich brauche um eine
saube auswertung fahren kann?
Zunächst solltest Du Dir im Klaren werden/sein, was genau die DB nun leisten soll. D. h. welche Daten gibt es, woher kommen die Daten, in welcher Form liegen die vor, sollen Arbeitsabläufe (Lagerein/ausgänge, Verkäufe, evtl. Bestellungen und Rechnungen) erfasst/behandelt werden und letztendlich: sind alle Daten vorhanden, um die gewünschten „Auswertungen“ (welche sind das genau) auch wirklich zu ermöglichen. Wenn diese Punkte klar geworden sind, dann können/müssen die Daten unter Berücksichtigung der Normalisierungsregeln in einzelne Tabellen überführt werden, die dann unter der Verwendung der ref. Integritätsdefinitonen miteinander verknüpft werden (hier gilt: soviel wie nötig und sowenig wie möglich). Anhand dieser Tabellenkonstruktion werden dann unter Verwendung der Beziehungsdarstellung im Beziehungsfenster fiktiv „Datenverarbeitungen“ simuliert und geprüft, ob die Tabellen(daten) den Anforderungen genügen. Wenn so, kann die Entwicklung der einzelnen Formulare begonnen werden (mindestens ein Formular pro Tabelle, Einzel-oder Endlosform, je nach Tabellenart (Haupt- oder Detailtabelle, —> 1-Tabelle oder n-Tabelle ). Ist das fertiggestellt, können Spieldaten (NUR über die Formulare) eingegeben und die Funktionalität der Datenbeziehungen geprüft werden. Ist auch das alles in Ordnung, dann erfolgt die Überlegung zu Auswertungen und Aufbau entspr. Berichte.
Gruß
Franz,DF6GL
Hallo Franz,
danke für deine erklärung.
In meienr Datendank sollen nur die Verwaltung der Ware im Lager sein.
Ich brauche keine Bestellung und Kunden. Diese laufen über ein anderes System.
Mir geht es nur um die Verwaltung der Ware im Lager.
Die Eingänge und Ausgäne werden per Hand ein und ausgetragen, oder per Code scanner.Da bin ich mir noch nicht so sicher.
Eine Excel datenbank reicht da leider nicht mehr aus.
Gruß Odin
Hallo,
danke für deine erklärung.
In meienr Datendank sollen nur die Verwaltung der Ware im
Lager sein.
Ich brauche keine Bestellung und Kunden. Diese laufen über ein
anderes System.
Mir geht es nur um die Verwaltung der Ware im Lager.
Die Eingänge und Ausgäne werden per Hand ein und ausgetragen,
oder per Code scanner.Da bin ich mir noch nicht so sicher.
Eine Excel datenbank reicht da leider nicht mehr aus.
„Verwaltung“ kann nun Vieles bedeuten…
Stell die Daten zusammen, die Du hast, wie beschrieben. Poste mal die Spaltenüberschriften der vorhandenen Excel-Tabelle mit ein paar ausgefüllten Zeilen …
Weitere Fragen im Moment:
–Welche Daten beinhaltet der Barcode?
–Gibt es verschiedene Lagerorte?
–„über ein anderes System.“ --> SAP?
–Sollen Inventuren erfasst werden?
–Gibt es „Kontierungen“, d. h. die Angabe, WER den Ein-Ausgang buchhalterisch zugeordnet bekommt?
–Gibt es „Reservierungen“ oder ist nur der physikalische Bestand von Bedeutung?
Gruß
Franz, DF6GL
Hallo liebe Forumgemeide
Ich würde mal meine Angefangende Lagerdatenbank jeamden schicken?
Damit ihr seht wie weit ich erst bin
Ich hoffe einer kann mir helfen
Danke Odin
Hallo,
ich schau das mir schon mal an. Adresse ist mein Nickname (d f 6 g l) bei gmx. de