Modellierung meiner Datenbank

Bevor wir weiter gehen, hätte ich noch ganz kurz eine kleine Verständnisfrage bezüglich der Zuordnungstabelle/Zwischentabelle/Verknüpfungstabelle. Wow, gleich drei Bezeichnungen für solch eine Tabelle. Wir haben nun festgehalten, dass in der Zuordnungstabelle Nationalität_Person ein zusammengesetzter Primärschlüssel vorhanden sein muss, und zwar wie folgt: Person_ID und Nationailität_ID. Was mich nun ein wenig verwirrt, wenn diese IDs nun keine Fremdschlüssel als solche gelten, sondern als Primärschlüssel, dann können keine IDs mehrfach aufkreuzen oder? Wenn Person A mit der ID 23 nun drei Nationalitäten hat, so müsste die ID 23 drei Mal in der Zuordnungstabelle auftauchen.
Dies sähe dann wie folgt aus:

pkk7d9jl5gsm.jpg

Aber durch die Eigenschaft des PKs wird dies doch verhindert? Jetzt weiß ich nämlich wieder, weshalb ich die künstliche und sinnlose ID (Nationalität_Person_ID) genommen habe, aus Angst, mehrere IDs können als PK nicht in einer Tabelle existieren.
 
Zuletzt bearbeitet von einem Moderator:
Werbung:
Wo siehst du drei unterschiedliche Primärschlüssel? Ich lese von links nach rechts, und an erster Stelle tauchen drei Mal die ID 23 auf.
 
Damit ich sicher gehen kann, dass ich dich richtig verstanden habe. Bei einem zusammengesetzten Primärschlüssel muss ich also wie folgt vor gehen: 23 und 4, 23 und 8, 23 und 89? Also dieses und dazwischen legen? Das Problem bei mir ist einfach, dass ich jede Spalte einzeln betrachte. Daher war ich verwirrt, als ich die Spalte der Person_ID in der Zuordnungstabelle Nationalität_Person einzeln betrachtet habe.
 
Super :) Sowohl an dich, und auch an die anderen, die gerne mitmachen möchten. Wenn ihr meint, da könnte man noch bestimmte Personen hinzufügen, dann nur her damit :) vier Augen sehen mehr als zwei, sechs mehr als vier und so weiter. :)

Denn mir ist zum Beispiel noch was bei der Tabelle Person noch was aufgefallen.

xaphusfilmserktoysrpl4z.jpg

Zum Beispiel bei Vornamen. Wir alle wissen das Schauspieler oftmals zwei bis gefühlte 100 Vornamen haben. Darüber hinaus beschmücken sich die Schauspieler auch mit Künstlernamen. Till Schweiger heißt nicht wirklich so oder Ice Cube heißt auch nicht wirklich so. An dieser Stelle könnte ich euren Rat brauchen. Zunächst stehe ich im Zuge der Atomisierung vor einem Problem. Sollte ich mehrere Felder für Vornamen machen? Z.B Vorname1, Vorname2, Vorname3 etc.? Und wie würdet ihr mit den Künstlernamen handhaben?

Bleiben wir beim Beispiel Ice Cube. Sein bürgerlicher Name ist ja O'Shea Jackson oder Nicolas Cage, der eigentlich Nicholas Kim Coppola heißt. Mir fällt gerade kein Schauspieler auf die Schnelle ein, der mehr als zwei Vornamen haben.
 
Zuletzt bearbeitet von einem Moderator:
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

Code:
23 D
23 E
23 USA

B) Woher kommt die Idee, das Geschlecht als Tabelle zu führen?
In 99% der Staaten gibt es nur Männlich/Weiblich, also reicht ein BOOLEAN bei Person.
Eine andere Notwendigkeit sehe ich nur in wenigen Staaten (Nepal/Indien/...) wo ein 3. Geschlecht gesetzlich gültig ist.
Oder Deutschland: https://www.freitag.de/autoren/wolfgang-ratzel/ab-sofort-drei-geschlechter

Die Frage, ob du "Männlich"/"Male"/"Masculino"/ im HumanInterface anzeigen willst, ist ein Problem der Mehrsprachlichkeit, nicht des Geschlechtes, somit nicht der Datenbank.
 
Hallo SirTom60,

zunächst vielen Dank für deine Anmerkung. Da ich zur Zeit unterwegs bin, werde ich mir deine Anmerkungen später noch einmal genauer zu Gemüte führen. Jedoch möchte ich mich zum Thema Geschlecht äußern. Neben den gänglichen Situationen möchte ich auch "Rand-Situationen" mit berücksichtigen. Dazu gehört also, dass ein Mensch eben drei Geschlechter haben kann. Die gängliche Situation, dass ein Mensch entweder männlich oder weiblich sein kann, wird ja sowieso berücksichtigt. Aus diesem Grund habe ich eine Tabelle dafür angelegt, weil hier ein BOOLEAN nicht ausreicht. Dabei ist es zunächst unwichtig, in welchem Land es gesetzlich das dritte Geschlecht erlaubt sei. Mit meinem Programm sollte man Daten verwalten können, unabhängig davon, wie die politische Sachlage ist. Außerdem ist es auch ein Ausdruck von Professionalität, wenn man das dritte Geschlecht "zulässt". Ich will den Leuten bei der Verwaltung von Stammdaten, darunter zählte ich auch das Geschelcht, die freie Hand geben, und mich so wenig wie möglich auf etwas beschränken.

Aber zu meiner anderen Frage: Würdet ihr den Künstlernamen und die Vornamen der Schauspieler weiterhin atomisieren? Wir wissen ja, dass recht viele Schauspieler mehrere Vornamen hat, und dass die Küsntlernamen sich aus mehreren Elementen zusammen setzt. Beispiel ist "Atze Schröder" ein Künstlername. Wäre hierbei eine Atomisierung notwenidig, wie KünstlerVorname, KünstlerNachname etc? Oder Vorname1, Vorname2, Vorname3 etc?
 
Wenn du so viel Wert darauf legst, würde ich die Vornamen in einer Tabelle speichern und mit einer Ordnungsnummer versehen (Reihenfolge)... Finde ich besser als 10 Spalten...
Also so in etwa: PersonID, Ordnungsnummer, Vorname


P.S. hatte noch keinen Kaffee
 
Also eine zusätzliche Tabelle wie bei der Nationalität? Und die Person_ID sollte dann hier als Fremdschlüssel in diese Tabelle hinterlegt werden, damit zu der Person mit der ID 23 auch die Vornamen zugeordnet werden kann? Was aber meinst du mit der Ordnungsnummer?
 
Angenommen Person 1 heißt Karl Michael Herbert Müller.
Dann sollten die Einträge so aussehen
Person_ID | Ordnungsnummer | Vorname
1 | 1 | Karl
1 | 2 | Michael
1 | 3 | Herbert
Somit behält man sich auch die "Reihenfolge" bzw. "Sortierung" der Namen
 
Ich habe es in unserem CRM auch so gemacht das es für jeden Namen (Vorname1-n, Nachname, Geburtsname, Rufname, etc.) einen eigenen Eintrag gibt und eine Ordnungsnummer die Reihenfolge festlegt. Der Nachname kann ja auch durch Änderung offiziell ungültig werden, also hat jeder Eintrag auch einen Gültigkeitszeitraum. Außerdem wird über ein Flag festgelegt, welche Namen in der Briefanrede, in einer Kurz- und einer Langbezeichnung für die Darstellung im Programm berücksichtigt werden.

Ich verweise nur auf unseren Freund Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz Joseph Sylvester Freiherr von und zu Guttenberg. :)
 
Werbung:
Angenommen Person 1 heißt Karl Michael Herbert Müller.
Dann sollten die Einträge so aussehen
Person_ID | Ordnungsnummer | Vorname
1 | 1 | Karl
1 | 2 | Michael
1 | 3 | Herbert
Somit behält man sich auch die "Reihenfolge" bzw. "Sortierung" der Namen
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 habe es in unserem CRM auch so gemacht das es für jeden Namen (Vorname1-n, Nachname, Geburtsname, Rufname, etc.) einen eigenen Eintrag gibt und eine Ordnungsnummer die Reihenfolge festlegt. Der Nachname kann ja auch durch Änderung offiziell ungültig werden, also hat jeder Eintrag auch einen Gültigkeitszeitraum. Außerdem wird über ein Flag festgelegt, welche Namen in der Briefanrede, in einer Kurz- und einer Langbezeichnung für die Darstellung im Programm berücksichtigt werden.

Ich verweise nur auf unseren Freund Karl-Theodor Maria Nikolaus Johann Jacob Philipp Franz Joseph Sylvester Freiherr von und zu Guttenberg. :)
Ist schon Wahnsinn wie viele Vornamen ein Mensch haben kann. Aber zurück zu deiner Ausführung. Wenn 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?

Ich werde mich mal gleich an die Arbeit machen, und dies mal umsetzen.
 
Zurück
Oben