Primärschlüssel-Datentyp

[Leyyin]

Hallo,

eine neue Frage:
Man muss den Primärschlüssel-Datentyp nicht immer integer wählen oder?
Obwohl meine alle Tabellen jeweils einen integer-Prim.schl. namens "id" haben,
würde ich gerne eine davon als VARCHAR ändern.

Der Grund:
Nun habe ich drei Tabellen. (Natürlich habe ich auch noch andere Tabellen aber
es reicht nun aus, dass wir nur diesen drei betrachten)

• person
• institut
• job

Die beiden Tabellen "person" und "institut" haben jeweils einen integer-Primärschlüssel "id"
und haben einen Many-to-Many-Beziehung.
Daher existiert die dritte Tabelle "job", deren Primärschlüssel sich aus den Primärschlüsseln der beiden anderen Tabellen bildet.

Meine Frage ist nun folgendes:

Geht irgend etwas bei der Beziehung der drei Tabellen kaput,
wenn ich den Schlüssel von Institut "id" lösche und
stattdessen die Institutname als Primärschl. wähle?

Das möchte ich deswegen tun, weil

1. Duplikate bei der Instutname nicht erwünscht sind.
2. somit die Normalisation verletzt wird. (oder?)

Denn die Tabelle hat ja eine andere minimale Schlüssel-Kandidat außer der "id"; nämlich die "name"...

Was würdet ihr mir nun empfehlen?
den jetzigen Primärschl. behalten und die "name" indizieren,
oder jetzigen Primärschl. vernichten und stattdessen die "name" als Prim.schl. definieren?

[Leyyin]

Wird niemand etwas sagen?
Oder bin ich sehr ungeduldig? :-)

Was ich gerne wissen möchte ist eigentlich das, ob ein Schlüssel,
der für einer anderen Tabelle ein Fremdschlüssel oder Teil der Primärschlüsse ist,
unbedingt einen Integer-Wert haben muss.

Ausserdem würde ich gerne wisse, ob es logisch ist oder
-besser gesagt- nicht verletzlich für die Normalisation ist,
dass eine Tabelle, eine anderes Feld sogar vielleich zwei seperate Felderausser dem Prim.schl. id hat, das jeweils ein Primärschlüsselkandidat ist.

z.B.

TabelleA
id Feld1 Feld2
1 a w
2 b x
3 c y
4 d z

Was meint ihr? Ist das ok so?
Wenn nicht, wie kann es anders machen?

[cortex]

Zitat von Leyyin

Wird niemand etwas sagen?
Oder bin ich sehr ungeduldig? :-)

ja, das bist du wohl... threads bitte nicht pushen; das wird nicht so gern gesehen.

Zitat von Leyyin

[...] ob ein Schlüssel [...] unbedingt einen Integer-Wert haben muss.

nein, ein schlüssel muss kein integer sein. integers sind jedoch performanter hinsichtlich indizierung und damit bei jeder abfrage, die (wünschenswerterweise) indizies nutzt. siehe dazu auch: Using CHAR keys for joins.

Zitat von Leyyin

ob es logisch ist oder [...] nicht verletzlich für die Normalisation ist [...] Primärschlüsselkandidat ist.

Primärschlüssel: Ein ausgewählter Schlüsselkandidat. Die Werte dieses Schlüssels können in einer anderen Tabelle als Fremdschlüssel verwendet werden.

[quelle: Schlüssel (Datenbank)]

cx

[Leyyin]

Hmm...
ok... Dann nur noch eine Frage zu dem Thema, um nur sicher zu sein:

Bei der Relation

A(a_id, a_name, a_art)

sind die Attributen a_id und a_name Schlüsselkandidaten.

Davon habe ich a_id als Primärschlüssel gewählt.

"Die dritte Normalform ist erreicht, wenn sich das Relationenschema in 2NF befindet, und jedes Nichtschlüsselattribut von keinem Schlüsselkandidaten transitiv abhängt."

Somit ist bei meiner Relation die 3.NF nicht verletzt,
da a_art von keinem der Schlüsselkandidaten transitiv abhängt, oder?

Zitat von cortex

[quelle: Schlüssel (Datenbank)]
cx

Diese Quelle hat mir sehr geholfen, danke.

Und für die Normalformen das hier:

http://de.wikipedia.org/wiki/Normali...form_.281NF.29