Modellierung meiner Datenbank

[Sophus]

A) Warum führst du für Nationalität eine numerische ID ein?
Die Staaten gehören als Stammdaten vorgesehen und gewartet. (Nur internationale anerkannte Staaten). Somit bitete sich das internationale Kennzeiochen als Primary Key an.
http://www.tabelle.info/kennzeichen_land.htm
oder http://de.wikipedia.org/wiki/ISO-3166-1-Kodierliste

23 D
23 E
23 USA

Warum ich eine nummerische ID benutze? Nun, eine gegebene ID wird vom System aus nur einmal vergeben und nie wieder verändert. Es sei denn die Datenbank wird zerstört oder Datenbestand geht verloren. Dann müssen neue Datensätze in die Datenbank gepflegt werden und die Datensätze bekommen erneut eine (nummerische) ID. Das Problem bei den Landeskennzeichen als ID zu verwenden sehe ich wie folgt: Es ist durchaus und rein theoretisch möglich, dass sich Landeskennzeichen, sowohl national als auch international, sich ändern. Und dann? Angenommen für Deutschland haben wir momentan das Kennzeichen D. So speicher ich es ab, und D ist hier der Primärschlüssel. Nun ändert sich das Kennzeichen von D auf DE. Aber der Fremdschlüssel D liegt nun als Primärschlüssel in der Zwischentabelle/Zuordnungstabelle Nationalität_Person. Und da D nun in DE geändert wurde, kann der Person keine Nationalität zugeordnet werden. Wie denn auch? D ist ist unbekannt. Also müssen sämtliche Änderungen vorgenommen werden. Dies würde ich mir bei einer nummerischen ID sparen.

Grundsätzlich verstehe ich nicht, wieso es "falsch" sein sollte IDs zu verwenden, wo ihr zum Beispiel bei Nationalität darauf verzichten würdet. Erkaufe ich mir da gravierende Nachteile, wenn ich nummerische IDs verwende? Denn man bedenke, dass der Anwender meines Programm nicht sehen wird, was unter der Haube passiert.

 

[Distrilec]

Hierbei überlege ich nur, ob dies über eine Zwischentabelle/Zuordungstabelle gelöst werden soll oder einfach nur eine weitere Tabelle? Denn wir wissen ja, dass viele Personen Klaus heißen können. Und somit hätten wir dann eine Redundanz. Oder zählt die Regel der Redundanz-Minderung bei Namen nicht?

Ich verstehe gerade nicht den Unterschied zwischen "Zwischentabelle/Zuordnungstabelle" und "einfach nur eine [...] Tabelle"... Und inwiefern gibt es da dann Redundante Daten ?
Du hast für jede Person einen Namen + Ordnungsnummer (wenn du nach @ukulele gehst hast du sogar noch mehr Daten). Ich wüsste nicht inwiefern das ganze Redundant ist oder gegen irgendetwas verstoßen soll...

 

[ukulele]

enn ich dich richtig verstanden habe, legst du für Vornamen, Nachnamen, Geburtsnamen, Künstlernamen (hier wieder Vor- und Nachname) und Rufname eine eigene Tabelle an?

Nein, sry wenn das unklar formuliert war. Ich habe eine Tabelle per (für Personen) und eine Tabelle per_namen (für alle Namen zu einer Person) mit einer 1:n Beziehung dazwischen.

[pk]
  ,[bezeichnung]
  ,[typ]
  ,[von]
  ,[bis]
  ,[ungueltig]
  ,[nichtanzeigen]
  ,[fk_per]
  ,[bemerkung]

Diese Tabelle hat einen Fremdschlüssel auf Personen und speichert alle Bestandteile des Namens einzeln ab. Der Typ unterscheidet dabei zwischen z.B. Anrede, Vorname (hier kann es beliebig viele gleichzeitig geben), Rufname, Nachname, Geburtsname etc. und ein Trigger überwacht ob es in dem selben Zeitraum immer nur eine gültige Anrede, Nachname etc. und unabhängig vom Zeitraum immer nur einen Geburtsnamen gibt. Vornamen können mehrfach gleichzeitig vorkommen und werden durchnummeriert (hier aus Vereinfachungsgründen im Typ-Feld). Einen Künstlernamen habe ich bei mir nicht vorgesehen, ist aber problemlos machbar.

Das nichtanzeigen Flag steuert, ob ein Bestandteil in Briefanrede etc. genannt wird oder nicht. Auch das läßt sich differenzierter gestalten.

Wenn es mehrere Personen gibt, die z.B. Klaus heißen, wird das nicht normalisiert oder abgebildet. Gibt es eben zwei Enträge mit dem selben Namen, der schonmal kürzer ist als jede ID. Eine n:m Beziehung halte ich für übertrieben.

 

[Sophus]

So, ich habe einige Anmerkungen von euch übernommen. Da in meinem Fall kein Serienbrief erstellt wird, sondern Filme verwaltet werden, habe ich einige für mich nicht relevante Felder weggelassen.
Nun sehen wir hier eine Tabelle Namen. In dieser Tabelle habe ich alle Namen, die man einer Person vergeben kann, hinzugefügt - vom Rufname bis zum Künstlername. Und der Schlüssel Name_ID wird in die Tabelle Person als Fremdschlüssel hinterlegt. Sicherlich werdet ihr mich nun fragen, wieso ich einen Schlüssel Name_ID verwende. Das Problem, was ich hierbei sehe, ist, dass ich schlecht sagen kann, die Person_ID soll als Fremdschlüssel in die Tabelle Person hinterlegt werden, wo es ebenfalls den Schlüssel Person_ID gibt. Man kann ja schlecht in einer Tabelle zwei Felder mit gleichen Bezeichnungen anlegen. Aus diesem Grund habe ich erst einmal Name_ID gewählt.

 

[Distrilec]

Die Person_ID (die, die bereits in der Tabelle ist) soll der FK sein.
Und ein Datensatz sollte in deiner Tabelle durch die Kombination Person_ID und Ordnungsnummer bereits einzigartig sein.
Generell würde ich die Tabelle eher so aufbauen:

Person_ID   (FK zur Tabelle Person)
Name TEXT/VARCHAR2/STRING (Einfach nur ein Name)
Typ  INT (Vorname, Nachname, Zweitname, etc.)
Ordnungsnummer INT (In welcher Reihenfolge die Namen stehen (unterteilt pro Typ))

Ansonsten gibt es einige Daten immer wieder doppelt.

Den Künstlernamen würde ich in die Tabelle Person packen. Da gibt es in der Regel ja nur einen... oder ? (Oder soll der auch nochmal in Vor- und Nachname unterteilt werden?)

 

[Sophus]

Die Person_ID (die, die bereits in der Tabelle ist) soll der FK sein.
Und ein Datensatz sollte in deiner Tabelle durch die Kombination Person_ID und Ordnungsnummer bereits einzigartig sein.
Generell würde ich die Tabelle eher so aufbauen:

Person_ID   (FK zur Tabelle Person)
Name TEXT/VARCHAR2/STRING (Einfach nur ein Name)
Typ  INT (Vorname, Nachname, Zweitname, etc.)
Ordnungsnummer INT (In welcher Reihenfolge die Namen stehen (unterteilt pro Typ))

Ansonsten gibt es einige Daten immer wieder doppelt.

Den Künstlernamen würde ich in die Tabelle Person packen. Da gibt es in der Regel ja nur einen... oder ? (Oder soll der auch nochmal in Vor- und Nachname unterteilt werden?)

Zunächst zu der Person_ID. Diese ID soll als Fremdschlüssel wo sein? In der Tabelle Namen? Also nicht so wie in meinem Schaubild, wo die Namen_ID als Fremdschlüssel in der Tabelle Person ist? Also genau umgekehrt? Nun zu dem Aufbau-Vorschlag. Du hast nur ein Feld mit der Bezeichnung Name. Von welchem Namen ist hierbei die Rede? Und im Feld Typ schreibe ich alle Vornamen, Rufnamen, Geburtsname etc rein? Alles in ein Feld namens Typ? Zum Künstlernamen. Ja, ich dachte, wenn ich das schon konsequent durchziehen will, dann sollte ich das bei den Künstlernamen auch tun.

 

[Distrilec]

Person_ID in der Tabelle Namen verweist auf die Person, die in der Tabelle Person steht Damit braucht man keine Namen_ID in der Tabelle Person
Das Feld Typ ist einfach nur eine Beschreibung -> Ist der Wert im Feld Name der Vorname, Nachname, etc.
Und im Feld Name kommt dann wirklich einfach der Name rein, egal ob Vorname, Nachname, Zweitname, Drittname, etc. (Was hier genau reingeschrieben wurde, wird ja im Feld Typ beschrieben)

 

[Sophus]

Welche Funktion hat denn das Feld Name? Was mich auch noch verwirrt, ist, wieso sämtliche Vornamen, Nachnamen, Rufnamen, Geburtsnamen etc. in nur ein Feld untergebracht werden? Nur aus reiner Neugier. Was spricht dagegen, diese Sachen aufzudröseln, so wie ich es tat?

 

[Distrilec]

Beispiel:
Person_ID | Name | Typ | Ordnungsnummer
1001 | Herbert | Vorname | 1
1001 | Günnewig| Nachname| 1
1001 | Klaus | Vorname | 2


Ich hoffe das macht es etwas deutlicher

 

[Sophus]

Dein Beispiel bringt in der Tat etwas mehr Licht ins Dunkle. Gibt es tatsächlich mehrere Nachnamen? Ich frage nur, weil in deinem Beispiel der Nachname ebenfalls eine Ordnungsnummer bekommt. Jetzt muss ich mir einmal gedanklich überlegen, wie ich dein Beispiel in meinem Programm-Oberfläche unterbringen würde. Aber dazu erst später, denn eine Datenbankstruktur verändert sich ja im Laufe der Modellierung.

 

[Distrilec]

Das ist nur eine Idee... Quasi "On-the-fly"... Hat bestimmt noch ein paar Kinderkrankheiten

 

[Sophus]

Das ist ja auch in Ordnung Das Problem ist einfach, dass ich nicht weiß wieweit man atomisieren soll und ab wann es keinen Sinn ergibt. Das ist ja hier bei den Namen der Fall. Viele Verwaltungs-Programme werfen das alles in eine Zeile. Also die ganzen Vornamen in eine Zeile.

 

[Hony%]

Aber der Fremdschlüssel D liegt nun als Primärschlüssel in der Zwischentabelle/Zuordnungstabelle Nationalität_Person. Und da D nun in DE geändert wurde, kann der Person keine Nationalität zugeordnet werden. Wie denn auch? D ist ist unbekannt. Also müssen sämtliche Änderungen vorgenommen werden. Dies würde ich mir bei einer nummerischen ID sparen.

Dafür gibt es CASCADE ON UPDATE.

Änderungen am Schlüssel werden automatisch an alle per definiertem Fremdschlüssel referenzierenden Tabellen übertragen.

Das ist ja auch in Ordnung Das Problem ist einfach, dass ich nicht weiß wieweit man atomisieren soll und ab wann es keinen Sinn ergibt.

Was ist daran nicht zu verstehen? Ein atomarer Wert ist immer unteilbar.

 

[Sophus]

Dafür gibt es CASCADE ON UPDATE.

Änderungen am Schlüssel werden automatisch an alle per definiertem Fremdschlüssel referenzierenden Tabellen übertragen.

Das heißt jedoch, dass ich auf der Seite meines Programms CASCADE ON UPDATE "ansprechen" muss? Denn von allein kommt die Datenbank sicherlich nicht auf die Idee dies auszuführen. Diesen Weg würde ich mir aber generell sparen, wenn ich mit nummerischen IDs arbeiten würde. Solange wie die Datenbank besteht wird die ID niemals angefasst werden. Zumal diese CASCADE ON UPDATE-Funktion nicht von allen bzw. von den meisten DBMS unterstützt werden. Ich denke das mit der IDs ist "universeller".

Was ist daran nicht zu verstehen? Ein atomarer Wert ist immer unteilbar.

In meinem Fall ist der Vorname noch längst nicht atomisiert, zumindest nach meinem Verständnis, da man auch noch die Vornamen zerlegen kann, sobald jemand mehrere Vornamen hat. Und genau da frage ich mich, inwieweit es sinnvoll wäre den Vornamen zu atomisieren. Ob man da nicht "übertreibt"? Meine Frage ist einfach, ob man sämtliche Vornamen einfach unatomisiert in eine Zeile verlegen soll oder diese zerlegen soll?

 

[Distrilec]

@Sophus In meinem Beispiel ist auch der Vorname atomisiert. Du kannst ja soviele Namen vom Typ "Vorname" angeben wie du willst Oder willst du das ganze auf die einzelnen Buchstaben runterbrechen ?

Und generell würde ich sagen mach es einfach. In einem Jahr kommt dann jemand auf die Idee irgendeine Abfrage auf Vornamen laufen zu lassen und du musst dein Design wieder ändern