pro Land können mehrere Taylcodes vorhanden sein was eine weiter tabelle notwendig macht, würde dann meiner Meinung nach so aussehen:
Tab. Länder
ID, Land
Tab.Taycodes
ID,LänderID,Taylcode
nun soll man sich den Landnamen auch in weiteren Sprachen anzeigen lassen können was mich zu folgendem führt:
Tab. Länder
ID
Tab.Taylcodes
ID,LänderID,Taylcode
Tab.Ländernamen
ID,LänderID,LangID
Tab. Lang
ID, LangKürzl, Lang
was dann dazu führt das meine Haupt-Tabelle nur noch aus einer ID besteht. Irgendwie hab ich hier einen knoten im Kopf, ich denke ich mach dabei etwas prinzipiell falsch.
für hilfe wäre ich sehr Dankbar
(Der Grundsätzliche aufbau einer Datenbank und der Normalisierung is mir eigentlich klar)
Kann es sein, dass du bei Tab.Länder die Spalte Land vergessen hast? Sie taucht nämlich nicht mehr auf.
Die Tab.Ländernamen bräuchte nicht zwingend eine Spalte {ID} (wohl als Primärschlüssel), da {LänderID, LangID} als Primärschlüssel genügt. Wird das nämlich nicht der Primärschlüssel, wären auch Duplikate der (LänderID, LangID)-Kombination möglich.
In Tab.Lang wäre auch {LangKürzl} als Primärschlüssel geeignet.
vielen Dank erstmal für die Hilfe.
Die Spalte Land hab ich tatsächlich vergessen mit aufzuführen
Also ist das richtig das die Haupttabelle nur aus der ID besteht? Das sieht echt komisch aus.
Eine weitere Frage hätte ich dazu noch.
Beispielsweise bei einer Artikeldatenbank wäre die Art.Nr der Primärschlüssel. würden sich jetzt Preise ändern steht man vor dem Problem, dass, wenn man einer ältere Rechnung/Lieferschein drucken möchte dann immer den neuen Preis erhält statt den zu der Bestellung gültigen Preis. Wie löst man das am besten ohne allzuiel Datensalat zu produzieren? Sollte in dem Fall eine zusätzliche ID als Primärschlüssel dienen?
Die Spalte Land hab ich tatsächlich vergessen mit aufzuführen
-)
Also ist das richtig das die Haupttabelle nur aus der ID
besteht? Das sieht echt komisch aus.
Wenn die Spalte Land wieder mit im Spiel ist, sollte die Tabelle so aussehen:
Länder (ID, Land)
Insofern gibt es keine Tabelle mit nur einer ID-Spalte. Das wäre auch reichlich sinnfrei.
Beispielsweise bei einer Artikeldatenbank wäre die Art.Nr der
Primärschlüssel. würden sich jetzt Preise ändern steht man vor
dem Problem, dass, wenn man einer ältere Rechnung/Lieferschein
drucken möchte dann immer den neuen Preis erhält statt den zu
der Bestellung gültigen Preis. Wie löst man das am besten ohne
allzuiel Datensalat zu produzieren? Sollte in dem Fall eine
zusätzliche ID als Primärschlüssel dienen?
Oft speichert man den Rechnungspreis in der Rechnung bzw. die Einzelpreise in den Rechnungsdetails. Das ist allerdings redundante Datenspeicherung.
Aus kaufmännischer Sicht dürfte man Artikelpreise, die in Rechnungen auftreten, nicht nachträglich verändern. Ändern sich die Preise, muss man sowohl alte als auch neue Preise speichern und die Gültigkeit mit einer zusätzlichen Datumsspalte angeben. Diese ist dann auch bei Auswertungen mit einzubeziehen.
Hierzu kann man entweder die alten Artikeldaten in einer Historientabelle speichern oder die Preise in eine eigene Tabelle auslagern. In eine Historientabelle könnte man auch alle Artikel auslagern, die nicht mehr im Bestand sind, hergestellt oder geliefert werden. Eine extra Preistabelle würde nur die Preise enthalten. Primärschlüssel wären die ArtikelID (auch Fremdschlüssel zu Artikel) und das Datum, ab dem der Preis gültig ist. In der Artikeltabelle selbst würde dann kein Preis gespeichert.
Ich bin irgendwie davon ausgegangen, dass die Tabelle Länder noch weitere Spalten hat …
In der gegebenen Form sollten es trotzdem 4 Tabellen sein. Ich habe die Spaltenbezeichner zum besseren Verständnis mal angeglichen und die Primärschlüssel unterstrichen.
Wenn Tab. Länder nur die beiden ursprünglich angegebenen Spalten enthält, könnte man auf die Idee kommen, auf die Tabelle zu verzichten, da alle Daten auch in Ländernamen gespeichert sind. Aber dann würde man sich ein anderes Problem einhandeln: Der Fremdschlüssel in Taylcodes müsste dann {LänderID, LangKürzel} sein, was wahrsch. nicht gewollt ist. Das Ersetzen von {LänderID, LangKürzel} in Ländernamen durch eine Spalte {ID} würde das Problem nur verschleiern.
In Länder kann man auf die Spalte Land verzichten, da sie auch in Ländernamen gespeichert ist. Um die Lesbarkeit der Tab. Länder zu erhöhen, würde ich anstelle einer ID einen Code nach ISO 3166 verwenden, wie er auch bei Top-Level-Domains zum Einsatz kommt. Alternativ könnte in Länder auch die Standardbelegung von Land gespeichert werden. Das wär zwar redundant, würde aber das Verständnis erhöhen.
