Kauf- und Kontenverwaltung - Datenbank notwendig?

[Asura]

Des Weiteren habe ich mir mal bisschen mehr Gedanken zu der Datenbankmodellierung gemacht und bisschen auch mich weiter informiert über Datenbanken.

Nun möchte ich Fragen, ob hier ein Denkfehler drin ist:

Es existieren 3 Tabellen: Getränke, Bestellungen, Users

Getränke <-- n --- m --> Bestellungen <-- n --- 1 --> Users

Tabelle Getränke hat die Attribute:

Getränkename (Primärschlüssel)
Preis

Tabelle Bestellungen hat die Attribute:

Bestellt_Nr (Primärschlüssel)
Datum (Sekundärschlüssel)
UserID (Fremdschlüssel)
Getränkename (Fremdschlüssel)

Tabelle Users hat die Attribute:

UserID (Primärschlüssel)
User
Guthaben

Ist das so korrekt?

Nun noch eine Frage: Wie löse ich das, dass Bestellungen mehrere Getränke notiert und hierbei die einzelnen Getränke mit Anzahl und Preis berücksichtigt.
Lass mich raten: Mehr Tabellen und Verknüpfungen?

Ich möchte noch mal eventuell kurz Erklären was mein Vorhaben ist, damit man sich besser hineinversetzen kann:
Stellen Sie sich vor, Sie können hier einfach über ein Tablet Ihr Konto auswählen. Daraufhin öffnet sich eine Übersicht, wo verschiedene Getränke zur Auswahl stehen mit Preis (Also Konto, Getränke und Preis können variabel über die Datenbank geändert werden und werden auch so vom Programm immer mit verändert). Daraufhin kann man Beispielsweise: Zwei Bier und Zwei Cola auswählen und es wird in einen virtuellen Warenkorb gelegt. Danach drückt man nur noch Kauf abschließen und das System rechnet automatisch nach der Buchung ein Minusbetrag (Hier in der Tabelle User unter Guthaben) den Preis runter und registriert für eine spätere Einsicht immer noch (unter Tabelle Bestellungen) die komplette Bestellung.
So kann ich durch ein Programm schlichtweg Lagerbestände kontrollieren, der User hat hier immer eine Übersichtsmöglichkeit und die Sicherheit, dass keine Verrechnungen stattfinden.

Hoffe nun kommt mein Vorhaben besser rüber.

[Delphi.Narium]

Du schriebst 16 Nutzer. Folgt daraus 16 Buttons?

Wenn ja, dann sowas? (Dabei gehen wir mal davon aus, dass die Buttons Button1 bis Button16 heißen.)

Delphi-Quellcode:

var
  i   : Integer;
  btn : TButton;
begin
  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username, UserID FROM users') ;
  ADOQuery.Open;
  i := 0;
  while not ADOQuery.EoF Do begin
    i := i + 1;
    // So kurz ist das mutig. Man sollte im "richtigen" Programm dann prüfen,
    // ob die Komponente auch gefunden wurde und ob der Typ passt.
    btn := TButton(Self.FindComponent('Button' + IntToStr(i)));
    if Assigned(btn) then begin
      btn.Caption := ADOQuery.Fields[0].AsString;
      // Nur als Idee: Der Button "weiß" dann direkt die UserID für die weitere Arbeit.
      // Beim Button-Click muss man dann nicht erst aus dem Namen in der Caption    
      // die UserID suchen, um sie für die Tabelle Bestellungen verwenden zu können.
      btn.Tag := ADOQuery.Fields[1].AsInteger;
    end else begin
      // Das sollte nicht vorkommen, aber eine entsprechende Fehlerbehandlung
      // wäre trotzdem nicht schädlich.
    end;
    ADOQuery.Next;
  end;
  ADOQuery.Close;
end;

Zum Datenmodell:

Der Getränketabelle würd' ich zusätzlich eine Getraenke_ID gönnen und die als Primärschlüssel nehmen.

Die Tabelle Bestellungen erhält dann statt des Getränkenamens die Getränkeid.

Mit dem Modell kann man eigentlich schon pro Bestellung mehrere Getränke verwalten. Es werden dann pro Bestellung mehrere Datensätze angelegt. Man könnte, damit es übersichtlicher wird, der Getränketabelle noch eine Spalte Position spendieren. Jedes Getränk zu einer Bestellung bekommt eine eigene Position, so dass man aus Bestellt_Nr und Position einen eindeutigen Schlüssel machen könnte. Auch kann man hierüber die Ausgabe immer sortiert ausgegeben werden und hat immer die gleiche Sortierung, selbst dann wenn man mal die Getränkenamen ändern sollte.

Umlaute in Tabellen- und Spaltennamen finde ich kritisch. Man weiß nie genau, ob man das auch (wenn nötig) auf eine andere Datenbank übertragen kann. Persönlich nehme ich nur (auch wenn Datenbanken was anderes können) nur die Buchstaben A bis Z, die Ziffern 0 bis 9 und den Unterstrich _. (Mag altmodisch sein, aber bisher hat noch jeder Datenbankwechsel ohne Programmänderungen oder Änderungen am Datenmodell funktioniert. Tabellen und Spaltennamen sind bei mir maximal 30 Zeichen lang. In der Regel reicht das auch aus.

[mkinzler]

Statt

Delphi-Quellcode:

  ADOQuery.Close;
  ADOQuery.SQL.Clear;
  ADOQuery.SQL.Add('SELECT username, UserID FROM users') ;

kann man auch kurz

Delphi-Quellcode:

ADOQuery.SQL.Text := 'SELECT username, UserID FROM users;';

schreiben.

[mkinzler]

Zitat:

Tabelle Getränke hat die Attribute:

Getränkename (Primärschlüssel)
Preis

Tabelle Bestellungen hat die Attribute:

Bestellt_Nr (Primärschlüssel)
Datum (Sekundärschlüssel)
UserID (Fremdschlüssel)
Getränkename (Fremdschlüssel)

Tabelle Users hat die Attribute:

UserID (Primärschlüssel)
User
Guthaben

Ich würde es eher so machen

Getraenke:

ID (Primärschlüssel)
Name

Preise:

ID (Primärschlüssel)
getraenk (Fremdschlüssel)
von (Datum)
[bis (datum)]
Preis

Bestellungen:

ID (Primärschlüssel)
Nr
Datum
UserID (Fremdschlüssel)
Getraenk (Fremdschlüssel)

Users:
ID (Primärschlüssel)
Name
[Guthaben]

So kann man Preisänderungen besser protokollieren.

[Asura]

Zitat von Delphi.Narium:

Du schriebst 16 Nutzer. Folgt daraus 16 Buttons?
Wenn ja, dann sowas? (Dabei gehen wir mal davon aus, dass die Buttons Button1 bis Button16 heißen.)

An sich funktioniert das System, jedoch wenn er auf den Namen des Benutzers zugreifen will, gibt er mir eine Fehlermeldung aus. mit der ID funktioniert es aber.
Ich habe mal ein DBGrid in die Form gelegt und dort die Tabelle reingeladen. Er lädt in das Feld User überall das Wort "WIDEMEMO", ich gehe mal davon aus, das ist der Grund, warum er die Fehlermeldung rauswirft, die ich weiter oben angegeben habe?

Zitat von mkinzler:

Ich würde es eher so machen

Was bedeuten die Attribute mit den eckigen Klammern?
Warum existiert bei Tabelle Bestellungen einmal ID und einmal Nr. Ist beides nicht eineindeutig? BestellNr kann doch auch nur einmal in Tabelle Bestellungen vorkommen?

Ich verstehe auch noch nicht so ganz, wie eine Bestellung mehrere Getränke enthalten kann und wie berechnet er den Gesamtwert einer Bestellung?

Bis jetzt lese ich die Datenbank wie folgt:
Es existieren zwei Getränke (Beispielsweise) in der Tabelle Getraenke.
und es sind jeweils zwei Einträge in Preise für Getraenke hinterlegt.
Es existiert ein Benutzer mit einem Guthaben von +10€. Nun bestellt er über die Software etwas, und es wird ein Eintrag mit der Bestell Nur, Datum, dann der UserID und von nur einem Getränk der Name genommen.
Die Kosten zu dem Datenmodell einer Bestellung kann man ja aus dem Preis des einen Getränks aus der Tabelle Preise beziehen.

Deswegen meine Frage: Wie kann eine Bestellung mehrere Getränke enthalten und somit einen Gesamtpreis?

Mir ist ebenfalls noch eine Frage eingefallen:
Wenn das Programm fertig ist und auf das Tablet übertragen wird und dort auch die Datenbank hinterlegt wird, muss das Tablet auch über Access verfügen, in hinblick auf Treiber bzw. der Möglichkeit, dass das Programm nichts mit der Datenbank dann anfangen kann?

[mkinzler]

Zitat:

Was bedeuten die Attribute mit den eckigen Klammern?

Felder sind nicht unbedingt notwendig.

Für das snowflaking des Datums reicht das Beginndatum (Enddatum = Beginndatum nächste Presiperiode)
Da Guthaben ist auch berechenbar (Problem Redundanz)

Zitat:

Warum existiert bei Tabelle Bestellungen einmal ID und einmal Nr. Ist beides nicht eineindeutig? BestellNr kann doch auch nur einmal in Tabelle Bestellungen vorkommen?

Ich bevorzuge synthetische Schlüssel, BestellNr ist Teil der Nutzdaten.

Zitat:

Es existiert ein Benutzer mit einem Guthaben von +10€. Nun bestellt er über die Software etwas, und es wird ein Eintrag mit der Bestell Nur, Datum, dann der UserID und von nur einem Getränk der Name genommen.
Die Kosten zu dem Datenmodell einer Bestellung kann man ja aus dem Preis des einen Getränks aus der Tabelle Preise beziehen.

Es gilt der jeweilig gültige Preis zum Bestelldatum (aus Tabelle Preise). Bei einer Preisänderung wird ein neuer Eintrag in der Tabelle Preise mit dem Datum der Preisänderung und dem neuen Preis erzeugt.

Zitat:

Deswegen meine Frage: Wie kann eine Bestellung mehrere Getränke enthalten und somit einen Gesamtpreis?

Dann würde ich eine weitere Detailtabelle für die Bestellpositionen verwenden. Gesamtpreis einer Bestellungen dann die Summe der Positionen (berechnet) also jeweils Anzahl * (aktueller) Preis.

was für ein Tablet?

[Asura]

Gut, denke das habe ich nun alles verstanden, dankeschön!

[QUOTE=mkinzler;1388680]

Zitat:

was für ein Tablet?

Zur Bestellabwicklung soll mein Programm auf ein Tablet übertragen werde. Bis jetzt existiert das Tablet noch nicht, ich werde es dann zu gegebenen Zeitpunkt kaufen. Wird natürlich ein Tablet mit Windows werden.
Meine Frage bezog sich darauf, ob das Programm später bei dem Release eine Access Version benötigt, bezüglich Treiber, um auf die Datenbank auf dem Tablet zuzugreifen.

[jobo]

Zum Datenmodell noch einige Anmerkungen:
Feldnamen in einheitlicher Sprache, Englisch ist quasi Standard
Bei Feldnamen einer einheitlichen Nameskonvention für Schlüsselfelder, Flags, Logikattributen folgen
Primärschlüssel wie schon genannt als Zahlwert, Namen (änderbar) als separates Feld, ebenfalls unique
Tabellen und Feldbezeichnungen möglichst passend, aber allgemein wählen. Spätestens wenn die Leute auch Snickers und Twix bestellen, ist Getränkename unglücklich gewählt, also z.B. Tabelle "Produkt", Feld "Name"
Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.
Datenmodel-Constraints (unique, not null, ref constraints, ..) möglichst eng fassen und bei Bedarf lockern oder Ausnahmen definieren.
Cascading Constraints mit Vorsicht (oder gar nicht einsetzen), bwahrt Entwickler/Anwender vor Datenverlust.

16:
Ich hoffe, es werden nicht 16 Buttons!
Man braucht viele z.B. 27 Buttons für die Buchstaben einer virtuellen Tastatur, 10 für die Ziffern des Nummernblocks usw., aber nicht für verschiedene User. Bitte diese Zahl vergessen - auch wenn sie eine Marke für die "Dimension" des Projekts ist!
In dem Moment, wo man in solchen Kategorien denkt, geht das Design (des Datenmodells oder der GUI/der Logik) leicht in die Hose.

[mkinzler]

Ware statt Getränke, Vorgang statt Bestellungen ( dann kann man auch "Guthabenzugänge" modellieren und das aktuelle Guthaben berechnen)

Zitat:

Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.

Oder pro Tabelle. Bei Access geht dies ja sowiso auch nicht anders.

[Asura]

Zitat von jobo:

Zum Datenmodell noch einige Anmerkungen:

Schlüsselwerte am besten für alle Tabellen über eine zentrale Sequenz erzeugen.


16:
Ich hoffe, es werden nicht 16 Buttons!
Man braucht viele z.B. 27 Buttons für die Buchstaben einer virtuellen Tastatur, 10 für die Ziffern des Nummernblocks usw., aber nicht für verschiedene User. Bitte diese Zahl vergessen - auch wenn sie eine Marke für die "Dimension" des Projekts ist!
In dem Moment, wo man in solchen Kategorien denkt, geht das Design (des Datenmodells oder der GUI/der Logik) leicht in die Hose.

Was ist mit einer zentralen Sequenz gemeint, also diese Aussage verstehe ich nicht.

Bezüglich der 16:
Mir fällt aber keine andere Möglichkeit ein, die eine schnelle Auswahl ermöglicht. Weil ich habe es mir zurzeit so gedacht: Tablet an, Benutzer auswählen (1. Klick), Getränke auswählen (Mind. 1 weiterer Klick) und Kauf bestätigen (3. Klick).
Also, dass der Käufer hier ganz einfach ein Kauf abwickeln kann.

Zur Zeit läuft es über die gute alte Methode: Zettel, Strich unter Getränk und Namen machen und ich darf das dann alles zusammenrechnen, buchen etc. Also: Umständlich für mich, deswegen eine Software.
Jedoch soll sie für den Anwender in Gegensatz zu der Strichliste ebenfalls kein großen Mehraufwand haben, sonst würde die Frage der Käufer aufkommen: Wieso ein neues System, was für mich einen Mehraufwand und Zeit kostet, wenn die Strichliste genauso gut funktioniert. Also eventuell können sie das das nachvollziehen, dass ich hier auch bisschen auf Attraktivität in Hinblick auf Schnelligkeit und "Leichtigkeit" aus bin.