SQL frgae zu Relationen (ForeignKey) ?

Computer: Software & Programmierung SQL & Datenbank - Programmierung
#1

Hallo,

ich habe eine große Frage bezüglich Relationen von anderen Tabellen:

Wenn ich eine Tabelle habe die bei einer 1:1 Relation eine andere referenziert gibt es (ist mir jetzt aufgefallen!) ja theoretisch zwei Möglichkeiten dieses in der Datenbank umzusetzen.

Tabelle-A:
Spalte_PK
Spalte1
Spalte2
Spalte_FK (diese enthält dann den primary Key von TabelleB)

Tabelle-B
Spalte_PK
Spalte1
Spalte2

Wie schon geschrieben referenziert dann die Spalte_FK von Tabelle-A die Tabelle B und dort die Spalte Spalte_PK.

ODER

Tabelle-A:
Spalte_PK
Spalte1
Spalte2
–> Lasse diese Spalte_FK ganz weg

Tabelle-B
Spalte_PK (und trage hier den Primary Key von Tabelle-A Spalte_PK ein)
Spalte1
Spalte2

Hier wird auf diese Spalte_FK verzichtet (spart speicherplatz?) und dafür nutze ich in der Referenzierten Tabelle einen Primary Key der genau dem von Tabelle-A entspricht. Damit habe ich eine 1:1 Verbindung zwischen beiden Tabellen.

Nur was ist da jetzt die Datenbanktheoretisch richtige Lösung???
(Anomalien etc… Performance, Vor-Nachteile, usw. Wer kann mir das erklären)

Vielen Dank
Julian

#2

hallo julian

also, was die „saubere“ theorie betrifft, kenne ich die fachausdrücke nicht so genau. ich komme eher von der praktischen seite…

eine relation über zwei identische primary keys abzubilden (dein zweites beispiel) bietet sich für mich nur dann an, wenn in beiden tabelle im prinzip das selbe „objekt“ beschrieben wird, wobei die erste tabelle nur jene daten aufnimmt, die immer (oder meistens) vorkommen, die zweite tabelle aber nur die eher selten vorkommenden daten. man könnte also beide tabellen zu einer kombinieren, hätte dann aber den nachteil, dass man ständig selten verwendete attribute mitschleppt.

beispiel: bei einer person hat man ständig einen namen, ein geburtsdatum etc. diese daten braucht man auch praktisch in jedem modul, dass mit personen zu tun hat. jede person hat auch genau einen geburtsort, nur wird der seltener gebraucht, bzw. ist nicht immer bekannt. um also die personentabelle schlank und performant zu halten, kann man nun z.b. den geburtsort in eine zweite tabelle auslagern.

handelt es sich hingegen um tabellen zu zwei getrennten objekten, die lediglich in einer 1:1 beziehung stehen (blödes beispiel: jede person hat genau eine leibliche mutter), würde ich IMMER jeder tabelle einen eigenen primary key geben und dann über einen foreign key referenzieren. das kostet zwar etwas speicherplatz, der aber bei den heutigen festplattenpreisen fast egal ist. dafür hat man den vorteil, dass man jeden primary key immer genau einem objekt zuordnen kann (ausser du arbeitest pro tabelle mit fortlaufenden primary keys).

kurzfassung:

  • werden in beiden tabellen attribute zum selben objekt gespeichert, dann einen gemeinsamen pk
  • sind es zwei getrennte objekte in 1:1 beziehung, dann verknüpfen über fk

de fakto ist das aber eine glaubensfrage. je nach anwendungsgebiet, speziellen anforderungen an die software etc. kann man sich da relativ flexibel entscheiden. mitunter hängt es auch von der programmiersprache ab - möglicherweise gibt es eine komfortable unterstützung für klassische master-detail-beziehungen (mit fk) sodass der programmieraufwand für pk-pk-lösungen nicht sinnvoll erscheint…

erwin

#3

Hallo,

in einem streng normierten Modell sehe ich den Sinn zweier identischer Tabellen nicht.
Sollte B lediglich eine Teilmenge von A sein, so genügt es doch eigentlich die Attribute von B in A ‚anzuhängen‘.
Falls es Performance-Probleme gibt, kannst Du ja immernoch via Trigger diese Datensätze in eine andere Tabelle rdundant wegschreiben.

Ist B jedoch nur eine bestimmte Ausprägung von A,
dann ist PK_B natürlich ein Attribut in A,
insbesondere falls es (vielleicht später einmal) mehrere Ausprägungen gibt.

Gruss
Thomas