Datenbank Model

[r_amse_s]

Hallo,

ich habe eine schwere aufgabe :-)
wer kann mich helfen folgende DB Struktur zu erstellen ?
(datenbank format ist jetzt nicht von bedeutung, wird aber sicher sql kompatibel sein)

ich habe mehrere artikel: z.B. Pizza.
Diese Pizza kann (am Anfang) z.B. 3 Größen haben:

- single Pizza
|___ Margherita (z.B. 4,50 €)
|___ Al Tonno
|___ Diavola

- family Pizza
|___ Margherita (z.B. 8,00 €)
|___ Al Tonno
|___ Diavola

- party Pizza
|___ Margherita (z.B. 23,00 €)
|___ Al Tonno
|___ Diavola

- ...
|___ Margherita (z.B. x,yy €)
|___ Al Tonno
|___ Diavola


1. Bedingung: die Anzahl der Größen muss erweiterbar sein, bzw. selbst von user definierbar sein (er muss auch nur mit eine größe arbeiten können).
2. Bedingung: jede Größe soll einen eigenen Grundpreis haben.

Zu diese Pizzen kann man zusätzlich (wenn man will) bei einer Bestellung noch weitere Zutaten dazu geben.
Darum sind die Zutaten in weitere Gruppen unterteilt.

Erste Ebene (nach qualität) muss auch erweiterbar sein z.B.:

- normale Zutaten
- gourmet Zutaten
- ...

JEDE dieser Ebene ist dann weiter unterteilt (nach Menge, also nach der Größe der ausgewählter Pizza):

- normale Zutaten
|___ single (Menge) - eigener Preis (Keine Preisgruppen !, sonder jede Zutat hat eigenen Preis)
|___ family (Menge) - eigener Preis
|___ party (Menge) - eigener Preis
|___ ...

- gourmet Zutaten
|___ single (Menge) - eigener Preis
|___ family (Menge) - eigener Preis
|___ party (Menge) - eigener Preis
|___ ...

- ...
|___ single (Menge) - eigener Preis
|___ family (Menge) - eigener Preis
|___ party (Menge) - eigener Preis
|___ ...

Es muss auch eine Verknüpfung zwischen Pizzen und Zutaten vorhanden sein, um beim schreiben des Programms kontrolieren zu können, dass nur die entsprechende Preise zu sehen sind:

Also Bestellungsablauf soll so sein:

Pizza Art (z.B. Hawai)
|___ Pizza Grösse (z.B. family)
|___ Normal Zutaten
|___ Gourmet Zutaten
|___ User hat z.B. Gourmet ausgewählt und jetzt soll es möglich sein den user die Zutaten zu presentieren die in der jeweilige Kategorie gültig sind. In den Fall Family/Gourmet.
Allgemein:
Wenn es z.B. 10 Zutaten zur Auswahl gibt, müssen ::: 10 x Größen Anzahl x Zutaten Arten ::: Preise für Zutaten geben. In unser Fall müssen dann 10 x 3 x 2 = 60 Zutaten (einzeln definierbare) preise geben.

Die Frage ist:
Wieviele Tabellen sind notwendig und wie sollen diese untereinander verknüpft sein, um die oben beschriebene Funktionalität zu gewährleisten.

Ich hofe, dass sich jemand findet der mir helfen kann.

[bttb930]

sollen wir diur die tabellen jetzt erstellen?

mach vorschläge

[Leuselator]

Gegen Je eine Pizza von allem Sorten in allen Größen mach ich Dir das Modell :-)
(sorry - der mußte raus)

[MrSpock]

Hallo r_amse_s,

zunächst einmal herzlich willkommen im Delphi-PRAXIS Forum.

Zu deiner Frage gibt es natürlich mehrere Lösungen. Ich würde zunächst einmal mit nur 3 Tabellen anfangen. Nämlich die Pizzen, die Größen und die Zutaten. Ob es dabei um eine gourme oder normale Zutat geht, könnte ein Feld innerhalb der Tabelle festlegen. Damit hättest du wahrscheinlich eine normalisierte Form der Datenbank. Es wäre ansonsten natürlich auch möglich, die Pizzen(art) und die Größe in eine Tabelle zusammenzufassen.

Du kannst dann über eine 1:n Verknüpfung die Pizzen in verschiedenen Größen abbilden.

Schließlich brauchst du noch eine Tabelle für die Bestellung und ggf. Bestellungpositionen, die dann die Bestelldaten und die einzelnen Positionen darstellt. Die Positionen sind dann je eine Pizza einer bestimmten Größe und jede weiter Position eine Zutat.