Datenbank - Beziehungen

Computer: Software & Programmierung Datenbanken allgemein
#1

Hallo zusammen,

ich hab da mal ein paar Fragen…

ich habe zunächst mal ein Tabelle mit Ländernamen

Tab. Länder

 ID, Taylcode, Land

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)

vielen Dank

Enrico

#2

Hallo Enrico,

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.

Peter

#3

Hallo Peter,

vielen Dank erstmal für die Hilfe.
Die Spalte Land hab ich tatsächlich vergessen mit aufzuführen :smile:

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?

lg Enrico

#4

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.

Peter

#5

Hm, dann darf ich das mal kurz wiederkauen…

Die Tabellen dürften dann so aussehen:
Länder(ID, Land(?))
Taylcodes(ID,LänderID,Taycode)
Ländernamen(LänderID,LangID,Land(?))
Lang(LangKürzel,Lang)

Sollte Land nicht unter Ländernamen stehen, es sind da ja mehrere Werte möglich?

Enrico

#6

Ich bin irgendwie davon ausgegangen, dass die Tabelle Länder noch weitere Spalten hat … :wink:

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.

Länder (LänderCode)

Lang (LangKürzel, Lang)

Ländernamen (LänderCode, LangKürzel, Land)

Taylcodes (TaylcodeID, LänderCode, Taylcode)

Peter

#7

vielen vielen Dank

bis zum nächsten mal :smile:

Enrico