Warum Primary Key und/oder Foreign Key ?

[mirage228]

Roter Kasten ... -- Egal, vielleicht ists ja auch noch hilfreich

Hm, dann mache ich vielleicht mal ein anderes Beispiel.

Nehmen wir einen Artikel

Code:

*ID   -- Name    -- Beschreibung
-----------------------------------
1     -- Kakao   -- Lecker, lecker

Diesem kannst du beliebig viele Kategorien zuordnen:

Code:

*#ID   -- *#Kategorie
--------------------
1     -- Zuckerhaltig
1     -- Pulver
1     -- Braun

Die Raute # heißt, dass ein FK ist - der Stern, dass es ein PK ist (die "Kategorie"-Tabelle habe ich mal der Einfachheit halber weggelassen).

Löscht Du nun den Kakao:
DELETE FROM Artikel WHERE ID = 1 sind automatisch auch alle Einträge mit ID = 1 aus der Kategorien-Zuordnung weg

Wenn Du schreibst
UPDATE Artikel SET ID = 666 WHERE ID = 1 dann wird auch in der Kategorie-Zuordnung dies angepasst.

Du kannst die Regeln aber auch so festlegen, dass ein Löschen bzw. Update verboten wird, wenn eine ID aus der Artikel-Tabelle irgendwo über einen Fremdschlüssel referenziert wird...

Viele Grüße

[DeddyH]

Vielleicht hilft der Wikipedia-Artikel ja, etwas Licht ins Dunkel zu bringen.

[RWarnecke]

Hallo Detlef,

danke für Deine Antwort. Der Artikel ist ja recht umfangreich. Nur leider verwirrt er mich, werde den Artikel aber zu einem späteren Zeitpunkt nochmals durchlesen. Vielleicht verstehe ich Ihn dann besser.

@Markus & David
Danke für eure Beispiele. Das Beispiel von David konnte ich jetzt entsprechend umsetzen in einer Firebird-Besipieldatenbank. Das Beispiel von Markus habe ich noch nicht geschafft.

Das sind die Vorteile, die ich im Moment von den Schlüsseln ersehe :

• Update der verknüpften Felder über mehrere Tabellen hinweg.
• Löschen von allen Datensätzen über mehrere Tabellen, die über die Felder verknüfpft sind.
• Einträge in der Detail-Tabelle können erst gemacht werden, wenn der verknüpfte Datensatz in der Master-Tabelle eingetragen ist.

Gibt es noch weitere Vorteile und gibt es irgendwelche Stolpersteine, die man beachten sollte ? Wie zum Beispiel das die Änderungsregel und die Löschregel jeweils durchgehend gleich ist.

Edit : Das hätte ich ja beinahe vergessen, müssen eigentlich die verknüpften Felder immer den gleichen Namen haben und als PK deklariert sein ?

[fkerber]

Hi,

Zitat von RWarnecke:

Edit : Das hätte ich ja beinahe vergessen, müssen eigentlich die verknüpften Felder immer den gleichen Namen haben und als PK deklariert sein ?

Weder noch


Liebe Grüße,
Frederic

[mkinzler]

Zitat:

Das hätte ich ja beinahe vergessen, müssen eigentlich die verknüpften Felder immer den gleichen Namen haben und als PK deklariert sein ?

Den gleichen Namen nicht, aber sie müssen PK sein

[fkerber]

Hi!

Zitat von mkinzler:

Zitat:

Das hätte ich ja beinahe vergessen, müssen eigentlich die verknüpften Felder immer den gleichen Namen haben und als PK deklariert sein ?

Den gleichen Namen nicht, aber sie müssen PK sein

Bist du dir da sicher?
Afaik muss es nur ein Kandidatenschlüssel sein (klar), aber eben nicht der PK. Wiki (englisch zumindest) gibt mir da auch recht...


Grüße, Frederic

[RWarnecke]

Stimme hier Frederic mit meinem doch begrenzten Wissen zu dem Thema zu. Habe eben ein Feld als Uniques deklariert und konnte dieses in den FK einfügen und verbinden, zumindest unter Firebird.

[mkinzler]

Zitat:

Dann habe ich glaube ich Dein Beispiel falsch umgesetzt. Denn ich habe in der Tabelle Rechnung nur die Spalte ID und in der Tabelle Rechnungsposition die Spalte Rechnung als PK gesetzt.

Ja den in beiden Tabellen wäre es die Spalte ID. Die Spalte Rechnung der Positionstabelle ist der Fremdschlüssel der den Primärschlüssel der Mastertabelle (Rechnung) referenziert.

Zitat:

Zusätzlich habe ich dann noch den FK in der Tabelle Rechnungsposition gesetzt und damit die beiden PK's verbunden. Ich nehme mal an, das war nicht ganz das was Du mit dem Beispiel erreichen wolltest oder ?

Nein, hatte aber genau geschrieben, was PK und was FK ist.

Zu solltest dir vielleicht im Allgemeinen mal die Grundlagen von relationalen Datenbanksystemen anschauen.

[RWarnecke]

Hallo Markus, Hallo Frederic,

danke für euren Hinweis. Habe auch jetzt das Beispiel von Markus hinbekommen.

Zitat von RWarnecke:

Das sind die Vorteile, die ich im Moment von den Schlüsseln ersehe :

• Update der verknüpften Felder über mehrere Tabellen hinweg.
• Löschen von allen Datensätzen über mehrere Tabellen, die über die Felder verknüfpft sind.
• Einträge in der Detail-Tabelle können erst gemacht werden, wenn der verknüpfte Datensatz in der Master-Tabelle eingetragen ist.

Gibt es noch weitere Vorteile und gibt es irgendwelche Stolpersteine, die man beachten sollte ? Wie zum Beispiel das die Änderungsregel und die Löschregel jeweils durchgehend gleich ist.

Was ist hiermit, gibt es noch weitere Vorteile und gibt es noch Stolpersteine die man beachten muss ?

[mkinzler]

Zitat:

* Update der verknüpften Felder über mehrere Tabellen hinweg.

Jein, bnötigt etwas Mehrarbeit und würde auch ohne Fremdschlüssel gehen, dann aber u.U. mit deutlich mehr Aufwand

Zitat:

* Löschen von allen Datensätzen über mehrere Tabellen, die über die Felder verknüfpft sind.

Oder Verhinderung der Löschung von datensätzen in Mastertabellen, wenn noch Detaildatensätze bestehen

Zitat:

* Einträge in der Detail-Tabelle können erst gemacht werden, wenn der verknüpfte Datensatz in der Master-Tabelle eingetragen ist.

Ja

Zitat:

Gibt es noch weitere Vorteile und gibt es irgendwelche Stolpersteine, die man beachten sollte ?

Bezieht sich deine Frage auf das Konstrukt oder das Prinzip?

Zitat:

Wie zum Beispiel das die Änderungsregel und die Löschregel jeweils durchgehend gleich ist.

Derartige Regeln sollte man sich gut überlegen und ggf durch Rechteverwaltung schützen, denn eine kaskadierender delete eines falschen Datensatzes könnte bei entsprechenden Struktur zum Leeren der gesamten Datenbank führen