1 Thema von j|g

  • j|g
  • devshare.de Team
  • Offline
  • Herkunft: München
  • Registrierungsdatum: 13-09-2000
  • Beiträge: 1.653

Thema: Ideen für ein DB-Design

HiHo,

ich bräuchte mal ein paar Anregungen von Euch, bezgl. des Designs einer DB. Die Datenbank selbst ist leider MS Access, aber hilft ja nüx ;o) Es handelt sich bei der DB um eine Verwaltung von Textilartikel.


Die Aufgabenstellung ist die folgende:

1) Artikeltabelle

Die üblichen Informationen soweit klar .. Titel, Beschreibung, etc. Darin enthalten ist eine Farbtabelle, welche auf die Artikelnummer einfluss hat. Also z.B. ein Artikel hat die  Art.Nr. 123 und diesen gibt es in der Farbe rot (01) und schwarz (02), dann bekommt der Artikel für die Farbe rot die Nr. 123-01.


2) Kundentabelle und dgl.

Es soll für spezielle Kunden eine eigene Tabelle geben, in denen gezielt einzelne Produkte aus der Haupttabelle eingetragen werden können. Diese Produkte haben dann neben den gängigen Merkmalen, weitere eigene Merkmale und zusätzlich eigene Preise. Hm .. da braucht man wohl zuvor auch noch ne Tabelle mit Informationen der jeweiligen Kunden ...


3) Die Sache mit den Preisen

Für die Preise sollen Preisgruppen definiert werden können. Also z.B. ne Preisstaffel bei 1-10 Produkten 10%, 11-20 P. 15%, etc. Dies aber für jedes Produkt individuell oder aus einer angebotenen Liste (Untertabelle?).



Jau, dann würde ich mich mal über Anregungen zum Design dieser Aufgabe freuen. Puh, *schweine* warm ist es hier bei mir im Büro ..  *stöhn*.

lg
Hannes

PS. @Tink: Nein, brauchst keine Angst haben .. *g* (insider).

_______________________________________________________________

/-/annes (j|g) ... http://www.jg-webdesign.de

j|g's Webseite

2 Antwort von Tink

  • Tink
  • devshare.de Team
  • Offline
  • Herkunft: München
  • Registrierungsdatum: 18-05-2001
  • Beiträge: 1.398

Re: Ideen für ein DB-Design

@ jg: Bei Access hätt ich Dir auch nich geholfen! <img src="/forum/images/graemlins/smile.gif" alt="" />

Ansonsten würde ich sagen, brauchst Du für die Farben und Artikel zuerst mal 3 Tabellen:

- Artikel (Artikel-ID, Name, Abmessungen etc)
- Farben (Farb-ID, Name, Farbwerte in RGB?)
- Artikel-Farb-Zuordnung (Artikel-ID, Farb-ID)

Dasselbe "Problem" bei den Kunden:
- Artikel (siehe oben)
- Kunde (Kunden-ID, Vorname, Nachname etc)
- Artikel-Kunden-Zuordnung (Artikel-ID, Kunden-ID, Preis)

Wobei in den beiden Zuordnungstabellen jeweils die Artikel-ID und Farb-ID bzw. Kunden-ID als Primärschlüssel
definiert sind.

Bzgl. der Preisnachlässe:
Die Preise sind doch pro Kunde unterschiedlich, oder?
Sind die Nachlässe also für jeden Kunden und jeden Artikel unterschiedlich?

Wenn ja, müsste die entsprechende Tabelle wohl so aussehen:
NACHLÄSSE:
Artikel-ID, Kunden-ID, Anzahl-von, Anzahl-bis, Nachlass-in-Prozent

(wobei in der Verwalungsmaske dann geprüft werden muss, ob sich die "Anzahl-von" und "Anzahl-bis" mit
bereits bestehenden Einträge decken/überschneiden)

HTH, tink

Beleidigungen sind die Argumente derer, die keine Argumente haben

Tink's Webseite

3 Antwort von j|g

  • j|g
  • devshare.de Team
  • Offline
  • Herkunft: München
  • Registrierungsdatum: 13-09-2000
  • Beiträge: 1.653

Re: Ideen für ein DB-Design

Ochhhhh Ihr Access-Hasser *g* ... man kann sichs leider nicht immer aussuchen ;o)

1) Artikel & Farben

Wie verhält es sich aber mit den Zusatzartikel-Nr. bei den Farben. Diese sind ja auch für jedes Produkt indiviudell.

2) Preisnachlässe

Ja, diese sind a) pro/Artikel und b) pro/Kunde möglich.

Ich ahne schon ein leichtes Chaos mit Access ;o)

lg
Hannes

_______________________________________________________________

/-/annes (j|g) ... http://www.jg-webdesign.de

j|g's Webseite

4 Antwort von Tink

  • Tink
  • devshare.de Team
  • Offline
  • Herkunft: München
  • Registrierungsdatum: 18-05-2001
  • Beiträge: 1.398

Re: Ideen für ein DB-Design

zu 1)
die ergibt sich direkt aus den beiden Spalten Artikel-ID | Farb-ID der Tabelle "Artikel-Farb-Zuordnung" <img src="/forum/images/graemlins/smile.gif" alt="" />

2)
Dann passt das ja schon so in etwa wie ich das vorgeschlagen hatte denk ich ;-)

Beleidigungen sind die Argumente derer, die keine Argumente haben

Tink's Webseite

5 Antwort von gi

  • gi
  • Mitglied
  • Offline
  • Herkunft: kv2k (Freilassing
  • Registrierungsdatum: 19-11-2001
  • Beiträge: 571

Re: Ideen für ein DB-Design

Mein Vorschlag:

"Artikel"
- AID (ID, Primärschlüssel)
- Farbtabelle
- Titel
- Beschreibung

"Kunden"
- KID (Primärschlüssel)
- Name
- Vorname
- Adresse
- PLZ
- Ort
- Tel.
- eMail
- Ranking?!

"Wünsche"
- WID (Primärschlüssel)
- KID (Fremdschlüssel)
- Sonderkonditionen, etc.

Zusätzlich wirst du eine Hilfstabelle brauchen, für die N:M Beziehung
Kunde - Artikel (Ich würde deshalb noch eine Tabelle "Rechnungen" einführen)

Wie willst du das mit den Preisen machen, wenn ein Preis einen Rabatt bekommt, und der Kunde auch. Wer bekommt vorrang?!

Liebe Grüsse
-- gi

Nun freilich starren Sinnes zu behaupten, daß das, was ich gesprochen habe, auch unbedingte Wahrheit sei, das schickt sich nicht für einen, der zu denken pflegt. - Platon

gi's Webseite

6 Antwort von Basti

  • Basti
  • Ehrenmitglied
  • Offline
  • Registrierungsdatum: 27-09-2001
  • Beiträge: 2.126

Re: Ideen für ein DB-Design

Hi j|g,

Das mit den Farben ist leicht zu lösen (ich bin nicht sicher, ob Tink nicht genau das meinte, ich schreibs einfach nochmal):

Die Farb Tabelle enthält die verfügbaren Farben aller Artikel. Die Zuordnungstabelle "Artikel-Farben" legt fest, welche Artikel in welchen Farben erhältlich sind und vergibt darüberhinaus jedem Zuordnungspaar den Artikelnummer-Zusatz. So erhält das Hemd in rot den Zusatz 05, die CD in rot (*g) jedoch den Zusatz 07.

Und zu den Preisnachlässen wäre es geschickt, wenn du einwenig mehr Infos machen könntest. Wenn z.B. jeder Artikel ab 10 Stück einen bestimmten, individuellen Nachlass erhält, dann könnten diese Stufen fix in die Preistabelle rein. Wenn es z.B. preislich fixe Stufen gibt, also z.B. man für alle Artikel sagen könnte: Ab n Stück gibt es 10%, dann könnte man diese Stufen fix einbauen. Wenn das alles völlig gemischt ist, aber du z.B. festlegen kannst, dass es maximal 5 Nachlassstufen gibt, dann kannst du 10 Attribute vergeben: Preis für Preisstufe 1, max. Stückzahl für Artikel 1, Preis für Stufe 2, max. Stückzahl für Artikel 2 usw. bis 5. Am variabelsten fährst du, wenn du eine Preis-Tabelle einrichtest, in der du die Attribute: Preis-ID, Artikel-ID, (ev. Kunden-ID,) Stüch (min.), Stück (max.), Preis. So kannst du beliebige Preisstufen definieren. Musst halt schauen, wie du eine saubere Query hinbekommst, ohne den Maximal-Stück-Wert bei der höchsten Rabatt-Stufe angeben zu müssen.

Prinzipiell macht es Sinn, die Preise von den Artikeln (Artikelbeschreibungen) zu trennen, was hier ohnehin noch naheliegender ist als sonst, da du ja eben für verschiedene Kunden (vielleicht Kundengruppen) verschiedene Preise hast.

Zu den Extra-Merkmalen der Artkel für bestimmte Kunden kannst du auch, falls diese sehr variable und vielleicht noch nicht von Anfang an kalkuliert werden können, eine einfache Tabelle anlegen mit einer "Spezial-Attribut-ID", der Kunden-ID, der Artikel-ID, dem Namen des Attributes und dem Wert. So kannst du jeder Kunde-Artikel-Beziehung beliebig Attribute beifügen.

@gi:
Vorrang bekommt der spezielle Kundenpreis, ist doch klar, denn sonst bräuchte man diesen ja nicht zu definieren und zu speichern. Möglich wäre natürlich, dass es ein spezielles Preisvergabe-System gibt, dass ermöglicht, dass ein regulärer Preis z.B. zum SSV unter den, bei diesem Rabatt nicht berücksichtigten Kunden-Rabatt fällt. Dann wäre es natürlich nur fair, wenn nicht der Kundenpreis Grundlage wäre, sondern pauschal der niedrigste Preis. Das allserdings ist schon sehr speziell und dann wohl auch eher unsauber programmiert, denn natürlich sollten sich auch die individuellen Kunden-Preise ändern, wenn sich der "Grund"-Preis des Produktes ändert.

Also hier nochmal ein komprimierter Vorschlag:

Kunden (spezifische Kundendaten),
Artikel (Artkeldaten ohne Preise),
Preise (Preise nach bestimmten Preisstufen),
Farben (jede Farbe aller Artikel);

Artikel-Preise (die normal-Preise),
Artikel-Kunde-Preise (spezielle Kunden-Preise),
Artikel-Farben (jeder Beziehung ein Art.-Nr.-Zusaztz zugeordnet);

Kunden-Artikel-Spezialattribute (je nach Varianz).

Ev., wie gesagt, macht auch die Zusammenfassung von Kunden zu Kundengruppen Sinn. Musst du mal prüfen.

Liebe Grüße,
Basti

7 Antwort von gi

  • gi
  • Mitglied
  • Offline
  • Herkunft: kv2k (Freilassing
  • Registrierungsdatum: 19-11-2001
  • Beiträge: 571

Re: Ideen für ein DB-Design

Wenn es so ist, wie Basti gesagt hat, brauchst du für die Rabatte noch eine Hilfstabelle.
(Wegen N:M Beziehung)

Nun freilich starren Sinnes zu behaupten, daß das, was ich gesprochen habe, auch unbedingte Wahrheit sei, das schickt sich nicht für einen, der zu denken pflegt. - Platon

gi's Webseite

8 Antwort von j|g

  • j|g
  • devshare.de Team
  • Offline
  • Herkunft: München
  • Registrierungsdatum: 13-09-2000
  • Beiträge: 1.653

Re: Ideen für ein DB-Design

Ich mach mir morgen mal in Ruhe gedanken und poste hier mein Ergebnis ;o) Danke schon mal für die Anregungen!

_______________________________________________________________

/-/annes (j|g) ... http://www.jg-webdesign.de

j|g's Webseite

9 Antwort von Basti

  • Basti
  • Ehrenmitglied
  • Offline
  • Registrierungsdatum: 27-09-2001
  • Beiträge: 2.126

Re: Ideen für ein DB-Design

@gi:

Die m:n-Beziehung zwischen Artikeln und Preisen bzw. eben Preis-"Komplexen" (Preise in den verschiedenen Rabattstufen) ist in meinem Beispiel durch die beiden Tabellen "Artikel-Preise" und, Kundenabhängig in "Artikel-Kunde-Preise" bereits abgebildet.

Allerdings kann man sich das auch sparen, wenn man die Tabelle folgendermaßen gestaltet:

 +------------+-----------+------------+------------+--------+  
 | Artikel-ID | Kunden-ID | min-Stueck | max-Stueck |  Preis |
 +------------+-----------+------------+------------+--------+ 
 |      34518 |      2518 |          1 |          9 | 100,00 |
 |      34518 |      2518 |         10 |         24 |  90,00 |
 |      34518 |      2518 |         25 |         49 |  75,00 |
 |      34518 |      2518 |         50 |        n+1 |  60,00 |
 |      53678 |      NULL |          1 |        n+1 |  37,55 |
 |      53678 |      2518 |          1 |        n+1 |  34,27 |
 +------------+-----------+------------+------------+--------+

...natürlich noch mit je einer ID versehen.

Hier sind also einmal die Preise (incl. Rabattstufe), die der Kunde 2518 für den Artikel 34518 zahlen würde abgebildet und zum zweiten die Preise für den Artikel 53678, für den es keine Rabatt-Stufen gibt, für den aber Kunde 2518 weniger zahlt, als der Kunde "nobody" (Kd.-Nr. = NULL). Das n+1 bedeutet eben unendlich. Für n Arikel, die gekauft werden, gibt es einen Wert n+1, der die Obergrenze für die höchste Rabattstufe bildet. Wie das eben als Query abzubilden ist, weiß ich nicht, vielleicht muss man da nochmal abstrahieren.

Die normale Abfrage lautet dann eben z.B. (falls immer der geringste Preis eroiert werden soll): Gib mir den kleinsten Wert des Attributes Preis, der einem Artikel x, einem Kunden y oder NULL zugeordnet ist und dessen min-Stueck-Wert unter n und dessen max-Stueck-Wert über n liegt.

Hier wird allerdings schon deutlich, dass das das eine ziemliche Datenflut gibt, die sich eben ev. durch eine Kapselung der Benutzer in Gruppen reduzieren lässt.

Basti