Datenbank Planung

[myGil]

Liebe DB-Leute!

Arbeite gerade ein einem Bestellsystem für Kleidungen. Jetzt stoße ich auf ein Problem wo ich mir nicht sicher bin wie ich das am besten und vor allem korrekt lösen könnte:

Bis jetzt habe ich für alle Kleidungsstücke eine Tabelle: [Artikel] die folgende Spalten beinhaltet:

[ArtikelNr] <- Primarykey

[ArtikelName]

[Einzelpreis]

So jetzt muss ich jedoch die Kleidungsstücke auch in unterschiedliche Größen unterteilen!

(z.b: Jean Gr45, Jean Gr46, Jean Gr47, Jean Gr48, Bluse Gr66, Bluse Gr67, Bluse Gr68 ...)

Wie mache ich das jetzt am besten?

Meine erste Überlegung war, einfach eine Spalte [Grösse] hinzufügen:

[ArtikelNr] <- Primarykey

[Grösse]

[ArtikelName]

[Einzelpreis]

Vorteil: Jeder Artikel wäre anhand seiner ArtikelNr eindeutig.

Nachteil: Jetzt muss jeder Artikel in jeder nur erdenklichen Größe angelegt werden – das wäre Wahnsinn!! :old

Meine zweite Überlegung war, dass ich die Artikel-Tabelle nicht ändere uns wie folgt belasse:

[ArtikelNr] <- Primarykey

[ArtikelName]

[Einzelpreis]

Und stattdessen meine Bewegungstabelle [ArtikelBewegungen] wie folgt abändere:

[ArtikelNr]

[Grösse] <- NEU

[Menge]

[bewegungsdatum]

[LieferantID]

Vorteil: So müsste ich jeden Artikel nur einmal anlegen!

Nachteil: So hat natürlich jeder Artikel egal in welcher Größe denselben Preis (von mir aus kein problem) und der Artikel wäre nicht mehr anhand seiner ArtikelNr. eindeutig!

Wie falsch wäre das bzw. wie wird das korrekt gelöst?

Danke im Voraus für eure Ratschläge!

[Der Kleine]

Mit Hilfe der Normalisierung?

Haben gleiche Artikel unterschiedlicher Größe (Farbe etc) die gleiche Artikelnummer?

Dann eine Tabelle mit Artikelnummer, eine Tabelle mit Größen (eine Tabelle mit farben) und jeweils die

Bewegungstabelle aus beiden (drei), mit Artikelnummer und Größe (und Farbe) als Keys.

Dort kann dann auch der Preis einzelnd eingetragen werden.

(ob du die trivialen Tabellen mit Farbe und Größe anlegst, bleibt dir überlassen. Ich würde dieses tun, damit du den Überblick nicht verlierst (es sind ja Stammdaten, keine bewegungsdaten) , also bei drei Größen stehen halt nur 3 Datensätze in dieser Tabelle, bein 2 Farben halt nur 2 Datensätze in der anderen Tabelle)

Haben gleiche Artikel unterschiedlicher Größe (Farbe etc) die gleiche Artikelnummer?

Falls nein, so ist jede Artikelnummer separat anlegen.

[myGil]

Danke für deine Antwort!

Habe im Access gleich einen Erstentwurf versucht:

http://members.chello.at/gz/db.jpg

Kannst du dir das bitte ansehen und mir sagen ob du das so gemeint hast?

Bzw. habe ich das richtig verstanden: Die Grössentabelle gibt an, welcher Artikel in welcher Grösse erhältlich ist?

Danke!!!

Bearbeitet 6. April 2010 von myGil

[Der Kleine]

Warum hast du die Artikelnummer in der Größentabelle drin?

Ob ein Artikel mit einer Größe existiert, kannst du aus der Tabelle Bewegungen entnehmen.

[myGil]

Interessanter Gedanke, aber warum habe ich dann überhaupt eine Grössentabelle?

Ich habe mir das so überlegt:

Die Anwender erstellen einen neuen Artikel, anschließend klickst er mit der rechten Maustaste drauf und kann z.b. in einem Textfeld mit Beistrich getrennt die gängigsten Größen für diesen Artikel definieren.

(Dieser werden dann samt der Artikel-Nr. in der Größen Tabelle gespeichert.)

Sobald der Anwender anschließend eine Bewegung erstellt, wird ihm nach der Artikel Auswahl gleich die gängigsten Größen für diesen Artikel vorgeschlagen.

Daher die Größentabelle mit Artikel-Nr.

Ergibt das Sinn?

Nochmals Danke für deine Zeit!!!

Bearbeitet 6. April 2010 von myGil

[Der Kleine]

Interessanter Gedanke, aber warum habe ich dann überhaupt eine Grössentabelle?

Weil die größen stammdaten sind. Sollte sich die Bezeichnung einer Größe mal ändern (weil wir ab sofort nur noch chinesische Größen annehmen) dann musst du dieses genau einmal in dieser Tabelle größe pflegen, und nicht 100.000 Mal in der Bewegungstabelle.

(Prinzip verstanden?)

Ich habe mir das so überlegt:

Die Anwender erstellen einen neuen Artikel, anschließend klickst er mit der rechten Maustaste drauf und kann z.b. in einem Textfeld mit Beistrich getrennt die gängigsten Größen für diesen Artikel definieren.

(Dieser werden dann samt der Artikel-Nr. in der Größen Tabelle gespeichert.)

Sobald der Anwender anschließend eine Bewegung erstellt, wird ihm nach der Artikel Auswahl gleich die gängigsten Größen für diesen Artikel vorgeschlagen.

Daher die Größentabelle mit Artikel-Nr.

Ergibt das Sinn?

Kann sein. trenne bitte gedanklich ganz scharf den physischen Aufbau der Datenstruktur von der Art und Weise der Nutzeroberfläche. Einen Fehler im Aufbau deiner Struktur wirst du so schnell nicht beseitigen können. Über die Nutzerstruktur und die damit verbundene Programmierung der Manipulation der daten kannst du dann alles ins richtige Schubfach schmeissen, ohne das der Nutzer deine Schubfächer kennt. Was bei der navigation wann wie sinnvoll ist, läßt sich IMO erst im zweiten Schritt ermitteln, wenn die Struktur steht. Diese sollte normalerweise bei der Programmierung der Anwenderoberfläche gar nicht mehr oder nur minimlistisch geändert werden. (Natürlich wenn die Grundfunktionen getestet sind)

Was der Nutzer wann zu machen hat, ist dann erstmal nebensächlich und hängt von deinem Geschick ab.

[robotto7831a]

Vielleicht ein anderer Ansatz aus der Schuhbranche. Es gibt eine Tabelle Größen mit folgenden Feldern: Größen-ID, Größe-von, Größe-bis.

1, 21, 35

2, 36, 44

3, 38, 47

Dann gibt es eine Tabelle Artikel mit folgenden Feldern: Art-ID, Name, Preis, Größen-ID

Jeder Artikel wird einer Größentabelle zugeordnet. Und wenn es einen Artikel z.B. Kinderschuh von 30-38 gibt, dann hat dieser zwei Artikelnummern. Artikelnumme 4711 mit Größen-ID 1 und Artikelnummer 4712 mit Größen-ID 2.

Ein Grund für diese Aufteilung ist, dass ab bestimmten Größen der Artikel teurer wird.

Frank

[flashpixx]

Weil die größen stammdaten sind. Sollte sich die Bezeichnung einer Größe mal ändern (weil wir ab sofort nur noch chinesische Größen annehmen) dann musst du dieses genau einmal in dieser Tabelle größe pflegen, und nicht 100.000 Mal in der Bewegungstabelle.

Bei chinesischen Größen sollte man auf die Unicode-Codierung achten :floet:

[myGil]

Hallo "Der Kleine"

Das Prinzip der Stammdaten habe ich jetzt verstanden, so gibt auch die Größentabelle ohne Artikel-Nrn Sinn, danke! Und werde auch meine Gedanken bezüglich der DB-Struktur und dem letzendlichem Frontendprogrammierung strikt trennen - Danke!

Kannst du nochmals bitte einen Blick auf meiner echte aktuelle DB werfen:

http://members.chello.at/gz/sqldb.JPG

Denke das ein oder andere müsste ich noch ausbessern aber was mich eben jetzt schwer beschäftig ist das korrekte darstellen der Größen!

Würdest du das wie folgt machen?

http://members.chello.at/gz/sqldb2.JPG

Wie du siehst habe ich jetzt das Feld Grössen nicht mehr in der ArtikelStammliste sonder bei den Bewegungen!

Nochmals danke für deine tipps!

Bearbeitet 6. April 2010 von myGil

[myGil]

Dank auch den anderen Antwortern!

lg myGil