Definition der Schlüssel

[Jor]

Hallo zusammen,
ich möchte euch um eure Meinung zu folgender Problemstellung bitten:
Beim Datenbankdesign, unter Berücksichtigung der Normalisierung, habe ich folgendes Prob (beispielhaft als Buchverwaltung [ohne ISBN ;-)]) :
Den Primary-Key in der übergeordneten Tabelle Buch habe ich aus zwei Spalten zusammen gesetzt, Bandnummer und Auflage. Dadurch bekomme ich ja pro Bandnummer nur eine Auflage hin, und ist somit eindeutig. Jetzt soll jedes Buch X Kapitel haben, über die ich dann auf das Buch referenzieren möchte. Meine SQL's laufen zwar, ich denke man könnte das aber verbessern.

Muss ich nun in jeden Kapiteldatensatz den zusammengesetzten Schlüssel (Bandnummer und Auflage) eintragen, oder ist es akzeptabel (gängig) über einen zweiten Schlüssel (wird automatisch in der Buchtabelle erstellt und hochgezählt) die Referenz zwischen Kapitel und Buch herzustellen?


Wie würdet ihr das umsetzen? Danke schonmal.

[Christoph]

Verstehe ich nicht, warum der Teilschlüssel reichen sollte: der identifiziert doch gar nicht eindeutig ein Buch, oder? Zwischen verschiedenen Auflagen ändern sich doch im allgemeinen die Inhalte und auch die Anzahl und Abfolge der Kapitel.

[jan61]

...Den Primary-Key in der übergeordneten Tabelle Buch habe ich aus zwei Spalten zusammen gesetzt, Bandnummer und Auflage. Dadurch bekomme ich ja pro Bandnummer nur eine Auflage hin, und ist somit eindeutig. Jetzt soll jedes Buch X Kapitel haben, über die ich dann auf das Buch referenzieren möchte. Meine SQL's laufen zwar, ich denke man könnte das aber verbessern.

Muss ich nun in jeden Kapiteldatensatz den zusammengesetzten Schlüssel (Bandnummer und Auflage) eintragen, oder ist es akzeptabel (gängig) über einen zweiten Schlüssel (wird automatisch in der Buchtabelle erstellt und hochgezählt) die Referenz zwischen Kapitel und Buch herzustellen?...

Moin,

Bandnummer + Auflage als PK? Bei einem Buch? Kann ich mir nicht vorstellen ;-) Und dann gibts ja noch Serien, Reihen, ...

Ich würde als Primary Key einen Serial, also eine eindeutige, vom DBMS automatisch generierte Nummer, in einer zusätzlichen Spalte nutzen (eigentlich jedes DBMS bietet diese Möglichkeit, auch wenn es - wie bei Oracle - manchmal umständlich ist) und den bisherigen zusammengesetzten Primary Key in einen Unique Index verwandeln. Damit hast Du EINE Spalte, auf die Du referenzieren kannst (erleichtert den Aufbau von Foreign Key Constraints ungemein) und trotzdem die fachliche Anforderung (Buch + Band + Auflage muss eindeutig sein) umgesetzt.

Meiner Meinung nach sollte man immer dann, wenn man Fremdschlüssel auf eine Tabelle setzt, bei der sich die Eindeutigkeit aus mehreren Spalten ergibt, einen solchen Serial als PK einfügen. Ein zusammengesetzter PK sollte nur dann genutzt werden, wenn auf die Tabelle nicht referenziert wird. Es mag sicher Ausnahmen geben, aber in dem von Dir angeführten Anwendungsbeispiel wäre das die beste Variante.

Die Inserts in die Kapitel-Tabelle sind damit auch relativ leicht gemacht:

INSERT INTO kapitel (buch_id, kapitel_name, kapitel_nummer)
  SELECT buch.id, '1. Kapitel', 1
    FROM buch 
      WHERE buch.titel='Hurra, ich nutze einen SERIAL'
        AND buch.band='4711'
        AND buch.auflage='42';

Jan

P.S.: Ich habe mal ein paar Jahre lang Software für einen Buchimporteur geschrieben - die ISBN ist IIRC nicht als PK geeignet, die ist nämlich z. B. bei Novitäten noch gar nicht bekannt und bei Serien oder Reihen immer die Gleiche (weiß aber nicht mehr, bei wem nun). Aber in die Tabellen solltest Du sie unbedingt mit reinnehmen, was Wichtigeres gibts ja gar nicht im Buchhandel - außer den Rabatten und Remittenden-Regelungen ;-)