Warum Primary Key und/oder Foreign Key ?

[RWarnecke]

Hallo zusammen,

ich lese immer wieder das man die beiden Key's aus dem Titel setzen soll. Mir erschliesst sich nur noch nicht, warum ich diese Key's setzen soll. Ich habe jetzt schon mehrere Beiträge und Anleitungen gelesen. Aber so richtig verstehen tue ich es trotzdem nicht. Ich habe jetzt schon mehere kleine Projekte mit Datenbanken gemacht, zum Beispiel Code-Orakel. Hier habe ich auch keine Key's gesetzt.

Nun zu meinen Fragen :
Worin besteht nun der Vorteil einen Primary Key und oder einen Foreign Key zusetzen ?
Ab wann macht es Sinn diese Key's zu benutzen ?
Würdet Ihr egal, wie groß die Datenbank wird immer einen oder beide Key's setzen ?
Hängt auch vielleicht das Design der Tabelle davon ab, ob ich einen Key setze oder nicht ?

Edit: Wo können Stolpersteine entstehen, wenn ich keinen Key setze ?

[mkinzler]

Zitat:

Worin besteht nun der Vorteil einen Primary Key und oder einen Foreign Key zusetzen ?

Es wird dann ein Index erzeugt.
Primärschlüssel sind Voraussetzung für Fremdschlüssel.
fremschlüssel haben den Vorteil, dass man nur vorhandene Masterwerte in einer Detailtabelle auswählen kann. es sind auch Delete-Rules möglich

[RWarnecke]

Zitat:

Zitat von mkinzler (Beitrag 1033417)

Es wird dann ein Index erzeugt.Primärschlüssel sind Voraussetzung für Fremdschlüssel.

Das würde also heißen, dass die Suche in einer Datenbank beschleunigt.

Zitat:

Zitat von mkinzler (Beitrag 1033417)

fremschlüssel haben den Vorteil, dass man nur vorhandene Masterwerte in einer Detailtabelle auswählen kann. es sind auch Delete-Rules möglich

Da sprichste in einem Rätsel. Kannste mir das bitte an einen Beispiel erklären. Ich kann mir darunter nichts vrostellen.

[mirage228]

Zitat:

Zitat von RWarnecke (Beitrag 1033423)

Zitat:

Zitat von mkinzler (Beitrag 1033417)

fremschlüssel haben den Vorteil, dass man nur vorhandene Masterwerte in einer Detailtabelle auswählen kann. es sind auch Delete-Rules möglich

Da sprichste in einem Rätsel. Kannste mir das bitte an einen Beispiel erklären. Ich kann mir darunter nichts vrostellen.

Stell die eine Tabelle mit Mitarbeitern vor und dazu eine Tabelle mit irgendwelchen Meta-Daten über diesen Mitarbeiter. Die beiden Tabellen sind mit einem Fremdschlüssel (Mitarbeiter ID) verknüpft. Nun kannst Du es so einrichten, dass wenn die Mitarbeiter ID aktualisiert wird in der Mitarbeiter-Tabelle sind die Mitarbeiter-ID der anderen Tabellen auch mit aktualisiert wird. Oder wenn ein Mitarbeiter aus der Mitarbeitertabelle gelöscht wird, die entsprechenden Datensätze aus der anderen Tabelle automatisch mit gelöscht werdne...

[mkinzler]

Zitat:

Das würde also heißen, dass die Suche in einer Datenbank beschleunigt.

Wenn nach dem Primärschlüssel gesucht wird

Zitat:

Da sprichste in einem Rätsel. Kannste mir das bitte an einen Beispiel erklären. Ich kann mir darunter nichts vrostellen.

Welchen Teil meinst du ( der 2. wurde schon erklärt)
Ohne Fremdschlüsselbeziehung könnten auch in der Mastertabelle nicht vorhandene Werte verwendet werden.

[RWarnecke]

Hallo David, Hallo Markus,

erstmal danke für eure Erklärungen.So ganz kann ich noch nicht folgen. Ich versuche es mal so zu erklären, wie ich es verstanden habe. Korrigiert mich wenn irgendwas falsch ist.

Code:

Tabelle mit Mitarbeitern:
+---------------+---------+----------+-----------+---------+
+ MitarbeiterID + Vorname + Nachname + Abteilung + Telefon +
+---------------+---------+----------+-----------+---------+
+ 1000          + Hans    + Meier    + Einkauf   + -1234   +
+---------------+---------+----------+-----------+---------+

Code:

Tabelle mit Metadaten von Mitarbeitern:
+---------------+-------+------------+-------------+
+ MitarbeiterID + Alter + Geschlecht + Geburtsort  +
+---------------+-------+------------+-------------+
+ 1000          + 43    + männlich   + Musterstadt +
+---------------+-------+------------+-------------+

In beiden Tabellen ist der Primary Key auf das Feld MitarbeiterID gesetzt. Bei dieser Voraussetzung, wenn ich es richtig verstanden habe, könnte ich jetzt bei beiden Datensätzen die MitarebiterID von 1000 auf 1001 ändern, richtig ?

Wenn ja, wie müsste ich da den SQL-Befehl schreiben ? Wenn nein, was habe ich falsch gemacht ?

[mkinzler]

Jein.
Besseres Beispiel

Rechnung:

Code:

ID    Kunde Datum
...
1087  156   02.01.2010
1088  154   02.01.2010
...

Rechungspositionen:

Code:

ID    Rechnung  Artikel Anzahl EP
...
7654  1087      1567    2      1,5
7655  1087      1876    3      0,99
7656  1087      765     1      2
7657  1088      1567    1      1,5
7658  1088      2345    6      0,2
...

Die ID Felder sind PK
Kunde, Rechnung Artikel sind PKs ( hiewrbei betrachte ich aber nur die Master/Detail Beziehung zwischen REechnungsposition und Rechnung.
Alle Positionen mit dem selben Wert in Rechnung gehören zu einem Eintrag in der Rechnugstabelle
Für rechnung sind nur Werte in der Tabelle Rechnung möglch. Wenn man ein delete-On-Cascade als Löschregel deklariert, werden alle Rechnungspositionen zur einer rechnung mitgelöscht, wenn diese aus der rechnungstabelle entfernt wird
-> Löscht man den Datensatz mit der ID 1087 aus der Tabelle Rechnung werden die Datensätze mit den IDs 7654, 7655, 7656 aus der Tabelle Rechnungspositionen mitgelöscht

[mirage228]

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

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:

SQL-Code:

DELETE FROM Artikel WHERE ID = 1

sind automatisch auch alle Einträge mit ID = 1 aus der Kategorien-Zuordnung weg :)

Wenn Du schreibst

SQL-Code:

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:

Zitat von RWarnecke (Beitrag 1033479)

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

[RWarnecke]

Hallo Markus, Hallo Frederic,

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

Zitat:

Zitat von RWarnecke (Beitrag 1033479)

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

[RWarnecke]

Zitat:

Zitat von mkinzler (Beitrag 1033488)

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

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. 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 ? Siehe Beispiel von David.

Zitat:

Zitat von mkinzler (Beitrag 1033488)

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?

Auf beides. Wo gibt es welche und worauf sollte man achten ?

Zitat:

Zitat von mkinzler (Beitrag 1033488)

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

Wie sieht das hier aus mit SET DEAFULT und SET NULL ?

Ein weiterer Vorteil ist, dass ich immer eine sortierte Tabelle nach dem PK habe.

[fkerber]

Hi!

Zitat:

Zitat von mkinzler (Beitrag 1033481)

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]

Zitat:

Zitat von mkinzler (Beitrag 1033500)

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.

In dem Beitrag mit Deinem Beispiel steht leider nichts vom FK drin. Werde es aber nochmals mit der jetzigen Bemerkungen versuchen umzusetzen.

Zitat:

Zitat von mkinzler (Beitrag 1033500)

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

Hättest Du dazu ein paar gute Links ?

[mkinzler]

Zitat:

In dem Beitrag mit Deinem Beispiel steht leider nichts vom FK drin.

Doch

Zitat:

Die ID Felder sind PK
Kunde, Rechnung Artikel sind PKs ( hiewrbei betrachte ich aber nur die Master/Detail Beziehung zwischen REechnungsposition und Rechnung.

Zitat:

Hättest Du dazu ein paar gute Links ?

http://de.wikipedia.org/wiki/Relationale_Datenbank
http://v.hdm-stuttgart.de/~riekert/lehre/db-kelz/
http://www.ib.hu-berlin.de/~is/rel-db2.htm