Tabellendesign, allgemeine Fragen zu Datenbanken

[stOrM]

Moin,
ich würde gerne eine Art Bestellsystem (minimal) entwickeln, ich hab mich allerdings noch nie wirklich mit Datenbaken auseinandergesetzt von daher denke ich mir, wäre es wohl sinnvoll erst einmal ein paar grundlegende Fragen zu klären bevor ich mich ans Werk mache.

So hatte ich mir in etwa das System vorgestellt:

Tabelle Users
Anmeldename,
Email,
Passwort

Tabelle Artikel
Artikel,
Artikelnummer,
Beschreibung,
Preis

Tabelle Lieferanten
Name,
Plz,
Strasse,
Ort,
Telefon,
Fax,
Sachbearbeiter,
Kundennummer,
Email

Tabelle Bestellungen
Auftragsnummer,
Benutzer,
Artikel,
Menge,
Beschreibung,
Datum,
Zeit,
Kontaktemail,
KontaktTelefon,
KontaktFaxLieferadresseStrasse,
LieferadressePlz,
LieferadresseOrt,
KontaktpersonName,
KontaktpersonTelefon,
LieferzeitpunktZeit,
LieferzeitpunktDatum

So in etwa hatte ich mir die einzelnen Tabellen vorgestellt.
Jetzt hab ich ein paar Dinge gelesen bezüglich Insert, Delete, Update Anomalien, also ist es vermutlich erst einmal wichtig die Tabellen untereinander sinnvoll zu verknüpfen um genau dies zu vermeiden, Da fängt aber schon das erste Problem an, bzw. taucht die Frage auf Was ist sinnvoll?

Im Grunde soll halt später folgendes passieren:

Der Benutzer meldet sich am System an (Nur Lokal eine ausführbare Datei, kein Server schnick schnack)
Passwort wird validiert, Login erfolgreich oder nicht.

Nach dem erfolgreichen Login, (keine Einschränkung, jeder Benutzer darf alles: update, delete, insert usw.)

Der Benutzer darf also Artikel anlegen, verändern usw.

Der Benutzer klickt auf Bestellung Neu, die Eingabemaske zum Erstellen einer neuen Bestellung erscheint, hier sollte der Benutzer dann seine Artikel aus der Tabelle Artikel auswählen können (schön wäre natürlich noch ein Filtern der Artikel aber das ist jetzt nicht von belang) mehrfach Selektion verschiedener Artikel sollte möglich sein, die benötigte Anzahl auswählen bzw. eingeben werden pro Artikel, dann müsste noch der Händler von wem bestellt werden soll ausgewählt werden und die Lieferadresse sowie Lieferdatum usw. eingegeben werden.

Beim Absenden, Report als PDF generieren.

Wie gesagt um erst einmal dahinter zusteigen was sinnvoll ist und was nicht wäre es sehr hilfreich wenn mir jemand mal erklären könnte, wie man die Tabellen miteinander verknüpft.
Worauf ich beim insert, update,delete achten muss.
Welches Datenbanksystem eventuell für so etwas am besten geeignet wäre (vielleicht auch wenn möglich on the fly er / entschlüsselung der Datensätze)
Threading?
Gibt es (da ich nicht der SQL Master bin, eventuell Möglichkeiten später visuell SQL Querys zu erstellen die in Delphi verwendet werden können? Ich erinnere mich an früher da hatte ich schon diverse Probleme wegen extrem langer Strings New Line usw...)

Viele Grüsse
s!

[jobo]

Tja wo soll man da anfangen?
Hier:
https://de.wikipedia.org/wiki/Normal...28Datenbank%29

Du schreibst etwas von Anomalien. Gemäß Deiner ersten Datenmodellbeschreibung wirst Du sie bald kennenlernen.

In welcher Tabelle werden bei Deinem Modell die einzelnen Bestellpositionen gespeichert. Scheinbar nicht in "Bestellungen" oder willst Du den Schmonz für jede Bestellposition eintragen?
Ok, damit bist Du mitten im Thema.

Welche DB ist erstmal egal. Die Theorie zur Normalisierung ist grundsätzlicher Natur.

Verschlüsselung ist noch mal ein eigenes Thema.
Per Suchfunktion findest Du hier eine Reihe Tutorials, die das Thema Delphi und Datenbank nahe bringen.

[stOrM]

Hi,

"In welcher Tabelle werden bei Deinem Modell die einzelnen Bestellpositionen gespeichert. Scheinbar nicht in "Bestellungen" oder willst Du den Schmonz für jede Bestellposition eintragen?
Ok, damit bist Du mitten im Thema."

Ja stimmt, an die Tabelle hatte ich noch gar nicht gedacht, macht aber Sinn, eventuell kann man über diese Tabelle dann ggf. auch definieren ob ein Auftrag erledigt ist oder noch offen?!

Das mit der Verschlüsselung, war noch sehr allgemein, ob ich das jemals brauche steht auf einem anderen Blatt, ich hab nur im Vorfeld dran gedacht, dass dies eventuell Sinn machen könnte, nicht das ich hinterher feststellen muss falsche DB...

Mir geht es wie gesagt erst mal um das richtige verknüpfen der ganzen Tabellen. Da steig ich noch so gar nicht durch.

Danke für den Link!

[baumina]

Verknüpft werden Tabellen meist über eindeutige Datensatz-IDs (AutoInc-Felder).

Lieferant:
LieferantID
Lieferantnummer
Name
etc.

Bestellung:
BestellID
Bestellnummer
LieferantID
etc.

Bestellposition:
BestellPosID
BestellID
Positionsnummer
ArtikelID
etc.

Artikelstamm:
ArtikelID
Artikelnummer
etc.

[stOrM]

Ah ok Danke Dir,
ich lese gerade dazu, mir ist nur nicht ganz klar in welcher Form die Verknüpfung nun stattfinden muss lt. https://de.wikipedia.org/wiki/Normal...28Datenbank%29 da gibt es ja verschiedene Fälle, bei deinem Beispiel ist ja zu sehen welche Tabellen wie verknüpft sind ich versteh nur grad nicht die ganzen Unterschiede sprich 1NF 2NF usw. da wird man ja schwindelig.

Deine Tabelle BestellPosition ist für was zuständig?
Hm und so wie du jetzt verknüpft hast ist das für meine Anwendung jetzt die richtige Form? Ganz schön verwirrend das ganze...

[p80286]

Zitat von stOrM:

Da fängt aber schon das erste Problem an, bzw. taucht die Frage auf Was ist sinnvoll?

Das ist eine gute Frage! für einen größeren Adressbestand ist es bestimmt sinnvoll Adressen in Orte,PLZ... zu zerlegen. Für 10 oder 20 Datensätze wäre das Overkill. Da Du aber das SuperDuperBestelltool schreiben wirst, wäre es nicht sinnvoll, diese Fragestellung zu ignorieren.

Wie solltest Du vorgehen?
Zunächst was willst du mit dieser Datenbank erledigen. Bestellungen! ist klar, aber für welche Vorgänge sollen hier die Daten bevorratet werden?
Wie ist ein Bestellvorgang aufgebaut?
1) Brief/Mail/Telefonat über Gegenstand,Menge,Liefertermin,Zahlungsbedingegen mit/an den Lieferanten. (Wer ist eigentlich der Besteller und wer ist der Lieferant?)
2)Warten auf die Lieferung (wann sollte nochmals was geliefert werden? Haben wir eigentlich genug Platz im Lager?)
3) Die Lieferung trifft ein. Stimmt die Menge, ist der Termin eingehalten worden? wurde überhaupt das richtige geliefert? Gibt es mehrere Orte an denen angeliefert werden könnte und ist am richtigen angeliefert worden?
4) eine Notiz/Mail.. an die Buchhaltung über die erfolgte Lieferung, damit sie weiß was mit der Rechnung die demnächst kommt, zu passieren hat.

Und jetzt ist die Frage, welche Daten fallen an? z.B. Lieferantenadresse. Reicht da Kautschuk und Co und Hintertupfingen oder hängen da vielleicht noch ein paar Angestellte dahinter, die eine Neujahrsgruß erhalten sollen? Reicht für diese Angestellten ein Memofeld oder sollen es doch eigenständige Datensätze sein?

Und so oder so ähnlich solltest Du Dich mit Bleistift und Papier durch Dein Problem hangeln.
Und immer wenn Du Daten, die du an mehr als einer Stelle benötigst, erkennst, dann hast Du Futter für die DB gefunden.

Und wenn Du dann weißt welche Daten in Deiner DB zu finden sein sollen, dann machst Du Dir Gedanken über die Datenorganisation (Tabellen und Inhalte)

und dann...
dann suchst Du Dir eine DB aus und fängst an zu programmieren.

Gruß
K-H

[mkinzler]

Zitat:

Deine Tabelle BestellPosition ist für was zuständig?

In ihr stehen die Positionen (aller) Bestellungen. Über die BestellId sind diese mit der jeweiligen Bestelung verknüpft.

[stOrM]

p80286:

Zur Frage wie der Bestellvorgang aufgebaut ist:

Im Grunde sehr einfach, Kunde ruft an benötigt einen bestimmten Artikel, der wird bestellt über das Formular was ich erstellen muss, die eigentliche Bestellung erfolgt über Fax / EMail.
Die Kunden die bestellen interessieren nicht, wirklich im "Normalfall" ist es immer die gleiche Lieferadresse (Lager) von da aus findet der Versand zum Kunden statt. Es kann mal sein, dass die Lieferadresse abweicht das wäre dann ein "Ausnahmefall" somit müsste dann die Adresse des Kunden erfasst werden. Notfalls kann das aber, da der Fall äusserst selten eintritt, manuell eingegeben werden ohne Bindung an die Datenbank. Dies muss halt dann nur im Report auftauchen der gefaxt, bzw. per Email versandt wird.

Also was für den Report von Nöten ist wären folgende Felder (zwingen erforderlich)

Kundennr. (hier ist nicht die Kundennummer für die einzelnen Kunden gemeint, sondern die Kundennr die die Firma beim Großhändler besitzt, bei der das Bestellformular eingeht, da gibt es maximal 15 verschiedene Nummern ges.)

Datum, Uhrzeit, Name des Bestellers, Rückrufnummer, Fax, welcher Artikel wird bestellt, Artikelnummer, sowie Menge und Artikelbeschreibung, Faxnummer Grosshändler, Telefon, Ansprechpartner, Email, Lieferadresse, Ansprechpartner vor Ort, Ggf. Telefon des Ansprechpartners.

Das ist eigentlich schon alles was auf das Bestellformular muss,

Danke mkinzler für die Erläuterung