Ansatz für Artikeldatenbank mit Artikelgruppen

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo,

ich will mir eine Datenbank mit Kunden, Artikeln und Aufträgen generieren, so dass ich dann aus allen Datensätzen eine Rechnung erstellen kann. Die Rechnung kriege ich mit einfachen Datensätzen hin. Aber nun zum eigentlichen Problem mit den Artikeln:

Ich möchte, dass meine Artikel sich in Artikelgruppen befinden, die eine unterschiedliche Artikelgruppennummer haben. Bsp.:

Artikelgruppennummer-Artikelgruppe-Artikelbezeichnung-Artikelnummer-Preis

100-Getränke-Cola-101-1,50€
100-Getränke-Sprite-102-1,50€
200-Schriebutensilien-Kugelschreiber-201-0,50€
200-Schreibutensilien-Bleistift-202-0,50€
300-Bücher-…usw.

Hatte diese Datensätze auch soweit schon erstellt und zwar jede Artikelgruppe als einzelne Tabelle mit einer laufenden Nummer als Autowert. Diesen Autowert habe ich in einer Abfrage mit der Artiklegruppennummer addiert und so die Artikelnummer bekommen, aus der man ja gleich entnehmen kann zu welcher Gruppe der Artikel gehört (ist mir wichtig). Ist an diesem Ansatz was falsch??? Habe nämlich schon in anderen Foren gelesen, dass man alle Artikel einer Datenbank zusammenfassen sollte.

In meiner einfachen Version (ohne Artiklegruppen, nur einfache Artikel, die per Autowert ihre Artikelnummer zugewiesen bekommen haben) klappte es mit der Erstellung der Rechnung wunderbar, aber wenn ich die Artikel nun in mehreren Tabellen habe, dann meckert er.

Weiß jemand wieseo? Ist an dem Ansatz mehrere Artikel in getrennten Tabellen vielleicht schon was falsch?

Wie könnte ich denn alle Artikel in einer Tabelle einpflegen, aber dennoch für jede Artikelgruppe die laufende Nummer (Autowert) behalten, so daß wenn ich zunächst die Cola anlege und dann den Kugelschreiber, die Sprite nicht die Artikelnummer 103 bekommt sondern 102, weil die Sprite in Gruppe 100 erst das zweite Getränk ist???

Danke für Eure Hilfe! Und das Lesen des Textes:smile:

#2

Moin

Vom Datenmodell her brauchst du im Grunde 3 Tabellen
Tabelle 1 enthält alle Artikelgruppennummern und die Artikelgruppenbezeichnung.
Tabelle 2 Artikelgruppennummer, Artikelnummer und Artikelbezeichnung.
Tabelle 3 Artikelnummer und Artikelpreis.
Das mit dem Autowert würde ich persönlich weglassen oder ggf. nur in Tabelle 2 für die Artikelnummer nutzen. Dann hat man aber vielleicht wieder später Problem mit der referentiellen Integrität ( falls Access sowas kennt ).

Man kann es auch in 2 Tabellen machen, dann nimmt man in die zweite Tabelle den Preis mit auf und läßt die dritte Tabelle weg.

Gruss
DiBo

P.S.: man kann das Datenmodell auch auf 4 Tabellen ausdehnen. Das wäre jetzt aber zuviel des Guten.

#3

Moin, dice,

Weiß jemand wieseo? Ist an dem Ansatz mehrere Artikel in
getrennten Tabellen vielleicht schon was falsch?

so ist es - bereits nach dem ersten Einfügen in jede Tabelle hast Du gleiche Artikelnummern.

die Sprite nicht die
Artikelnummer 103 bekommt sondern 102, weil die Sprite in
Gruppe 100 erst das zweite Getränk ist???

der zweite Konstruktionsfehler ist es, den Artikelnummern eine Bedeutung beizumessen. Mit der Nummer soll ein Artikel wiedergefunden werden, sonst nichts. Oder anders gesagt: Die Artikelnummer darf keinen Rückschluss auf die Gruppe erlauben.

Mein Vorschlag:

**Artikelgruppe** (<u>GruppenId</u>, Bezeichnung, ...)
**Artikel** (<u>ArtikelId</u>, Bezeichnung, ..., FS\_GruppenId)
**Artikelpreis** (<u>PreisId</u>, gültig\_ab, Betrag, ..., FS\_ArtikelId)
**Rechnung** (<u>RechnungsId</u>, Datum, FS\_Kunde, ...) 
**Rechnungsposten** (<u>PostenId</u>, FS\_RechnungsId, FS\_PreisId, Menge, ...)

Mit einem Index sorgst Du dafür, dass das Pärchen (gültig_ab, FS_ArtikelId) eindeutig ist.

Mit der Konstruktion haben Gruppen und Artikel Idents, die eigenständig und unabhängig sind. Preise ändern sich im Lauf der Zeit, deshalb wird vom Rechnungsposten auf den zum Datum der Rechnungslegung gültigen Artikelpreis verwiesen.

Gruß Ralf

#4

Hallo,

bzgl. der Frage „Bedeutung der Artikelnummer“ stimme ich nicht so ganz mit Dir überein. Sicherlich ist als Primärschlüssel eine interne (technische) Artikelnummer mit automatischer Nummerierung sinnvoll. Nach außen hin zur tatsächlichen Verwendung sollte man sich aber den Weg offen halten, Nummern nach freiem Muster vergeben zu können, in die verschiedene Dinge eingeschlüsselt sein können. Das ist in der Industrie und im Handel eher Standard als Ausnahme.

Ebenso würde ich bzgl. der Generierung der Vorgänge einen anderen Weg gehen. Hierbei sind die Artikelpositionen in eine Vorgangspositionentabelle zu kopieren, wo sie dann vorgangsspezifisch verändert werden können, ohne den Stammsatz hierdurch zu ändern.

Nur so bin ich frei im konkreten Vorgang nahezu beliebige Änderungen am Artikel vorzunehmen, der aber immer noch der selbe Artikel bleibt.

Die Artikelgruppen können als eine zusätzliche Tabelle verwaltet werden, die eigentlich nur die wiederum rein technische automatisch fortlaufende interne Nummer, die nach außen hin tatsächlich verwendete Nummer, und die Bezeichnung enthält. So kann in die nach außen hin sichtbare Nummer auch wieder beliebig etwas eingeschlüsselt, und notfalls auch mal nachträglich verändert werden.

Gruß vom Wiz

#5

Man kann es auch in 2 Tabellen machen, dann nimmt man in die
zweite Tabelle den Preis mit auf und läßt die dritte Tabelle
weg.

Den Ansatz mit 2 Tabellen habe ich schon gehabt und es klappt ja dann auch mit der Rechnungserstellung nur weiß ich dann immer noch nicht, wie ich jedem Artikel eine Nummer vergeben kann, die mit der Gruppe in Verbindung steht (also Artikelnummer 101, 102, 201, 301, 202, 302 usw.).

Ich meine ich könnte das alles ja auch manuell bereits in der richtigen Reihenfolge eingeben, aber wenn dann irgendwann in 3 Jahren ein neuer Artikel aus der Gruppe 100 hinzukommen würde, müßte ich erstmal nachschauen wieviele Artikel in Gruppe 100 bereits vorhanden sind. Wenn es 43 sind dann müßte ich dem neuen Artikel die Nummer 144 zuweisen.

Es wäre der einfachste aber nicht eleganteste Weg.

#6

Die Artikelgruppen können als eine zusätzliche Tabelle
verwaltet werden, die eigentlich nur die wiederum rein
technische automatisch fortlaufende interne Nummer, die nach
außen hin tatsächlich verwendete Nummer, und die Bezeichnung
enthält. So kann in die nach außen hin sichtbare Nummer auch
wieder beliebig etwas eingeschlüsselt, und notfalls auch mal
nachträglich verändert werden.

Wenn ich das richtig verstanden habe, dann ist die technische Nummer ein ganz normaler Autowert (fortlaufende Nummer) und die nach außen sichtbare Nummer die Artikelnummer in der Form, wie ich sie gerne hätte 101, 102, 201, 301 usw., die dann auch auf der Rechnung erscheinen soll und bei Bedarf auch verändert werden kann?

Falls ja, dann stellt sich ja nur noch die Frage, wie ich das mache? Ich meine ich kann ja zuerst ein Artikel aus der Gruppe 100 eingeben dann einen aus der 200 und dann wieder einen aus der 100. Die fortlaufende technische Nummer wäre dann 1, 2, 3, aber wie kann ich das einschlüsseln, dass daraus 101, 201 und 102 wird?

Sorry wenn ich so dämlich frage aber ich kenne mich mit Access leider nicht so gut aus. Die Basics kriege ich einigermaßen hin (wie gesagt, Rechnung kann ich mir erstellen lassen) aber wenn ich das ganze etwas auf meine Bedürfnisse anpassen will, dann klappt es nicht mehr.

Gruß

#7

Moin, Wiz,

gegen sprechende Schlüssel spricht nichts, solange sie nicht als Schlüssel verwendet werden :smile:)) Ob allerdings eine Oberklasse „Vorgang“ eingeführt werden sollte, unter der dann Rechnungen und was auch immer hängen, ist Geschmackssache. Wichtig ist nur, dass der Artikel unabhängig von allen Vorgängen seine eigene Identität und seine Attribute hat.

Gruß Ralf

#9

Hallo,

bzgl. der Schlüssel die klare Trennung zwischen technischer, interner Artikelnummer (=Schlüssel, unveränderlich) und nach außen hin in Erscheinung tretender Artikelnummer (kein Schlüssel, änderbar). So kann man nicht nur herrlich sprechende Artikelnummern bauen, sondern wenn man sich dabei vertan hat, diese auch problemlos noch mal für die Zukunft ändern.

Was die Positionen in den Vorgängen angeht, so geht es mir weniger um die Vorgänge, als vielmehr darum, nicht nur die Preisgültigkeit aus dem Artikelstamm (wobei man da dann natürlich eine Historie führen müsste) zu übernehmen, sondern wirklich den kompletten Artikel aus dem Artikelstamm in eine Vorgangsposition zu kopieren. Denn es kommt täglich vor, dass man in einem einzelnen Vorgang eine Position in der ein oder anderen Form ändert (z.B. einmaliger Sonderpreis zur Erprobung/für beschädigtes Teil, bei dem man dies dann auch in den Text schreibt, …). Diese Flexibilität bekommst Du nur bei kompletter Kopie des Artikels in die Position, wo Du an diesem dann für diesen einen Vorgang beliebig rumspielen kannst, im Vorgang diese Änderungen dann auch erhalten bleiben, aber ohne den Artikelstammsatz dauerhaft zu verändern.

Was im Übrigen die Sache mit den Vorgangstypen angeht: Die Leute denken bei solchen Aufgabenstellungen regelmäßig zu kurz. Heute meinen sie nur Rechnungen zu brauchen, morgen will aber jemand ein Angebot oder eine Gutschrift, … Alle besseren käuflich zu erwerbenden Warenwirtschaftssysteme sind daher hin der Lage mit jedem sinnvollen Vorgangstyp eine Kette von Vorgängen beginnen zu lassen, und dann die Positionen von einem Vorgang in den nächsten kopieren zu können. Und daher macht es Sinn, dies gleich vorzusehen. Und zwar nicht nur bzgl. der Artikelpositionen, sondern auch bzgl. der Kopfpositionen. So kann man schnell mal ein Angebot mit abweichender Lieferadresse schreiben, die dann automatisch auch in den Lieferschein und die Rechnung übernommen wird, genauso wie der Sonderpreis für einen Artikel, den man „mal zum Ausprobieren“ angeboten hat.

Gruß vom Wiz, der früher mal ERP-Software verkauft und eingerichtet hat, und daher die praktischen Anforderungen und technischen Lösungsansätze hierzu noch ganz gut kennt.

#10

Ok, verstehe.

Dann werde ich die Vorschläge mal umsetzen.

@Wiz
Ich weiss, dass es zu kurz gedacht ist und man später noch weitere Funktionen mit Sicherheit gebrauchen wird aber für den Anfang reicht es mir, wenn ich damit NUR Rechnungen schreiben kann. Felder für Sonderregelungen, Rabatte etc. habe ich auch. Sollte sich das alles gut entwickeln, dann wird schon irgendwann eine richtige Software gekauft. Aber im moment ist alles noch überschaubar (ca. 60 Artikel insgesamt aus unterschiedlichen Kategorien) und das kann man noch per Hand eintippen, ohne dass sie abfällt. Aber es werden halt langsam mehr Bestellungen, weshalb ich das schon gerne „automatisieren“ möchte.

Danke an Alle für die Links, Tipps und überhaupt die Unterstützung.

#11

Hi Wiz,

Gruß vom Wiz, der früher mal ERP-Software verkauft und
eingerichtet hat

mit Verlaub, das war vermutlich genau die Software, vor der sich die Kunden gefürchtet haben: Dermaßen raffiniert, dass sie ohne Beratung des Verkäufers nicht zu betreiben ist. Da kommt Kohle rein :wink: Aber was willst Du als Kunde machen, 1000 Manager können nicht irren.

Gruß Ralf

#12

Hallo,

mit Verlaub: Jede anständige ERP-Software ist so komplex, umfangreich und anpassbar, dass sie nur in einem mehr oder weniger großen Projekt von entsprechenden Fachleuten in einem Unternehmen implementiert werden kann. Aber man kann natürlich das entsprechende Knowhow auch im eigenen Haus aufbauen, und dann nach Jahren zu x-fachen Kosten so eine Lösung irgendwie ans Laufen bekommen.

Aber ich kenne die Sprüche natürlich zur Genüge: „Wir kaufen jetzt einen PC, damit läuft dann alles wie von selbst“

Gruß vom Wiz