Warum Primary Key und/oder Foreign Key ?

[RWarnecke]

Zitat von mkinzler:

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 von mkinzler:

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 von RWarnecke:

Zitat von mkinzler:

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

[RWarnecke]

Zitat von 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.

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

Zitat von mkinzler:

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

[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 ?