Grundsatzfrage Tabellen und ER-Modell

[MzKlMu]

Hallo,
ich habe aber auch die Erfahrung gemacht (nicht zuletzt aus verschiedenen Foren), dass man zunächst auf einen expliziten PK verzichten kann und der zusammengesetzte PK aussreicht. Im späteren Verlauf der Entwicklung der DB kommt man aber plötzlich zur Notwendigkeit doch einen eindeutigen PK zu haben. Der dann erforderliche Umbau der DB ist aufwendiger als den PK gleich einzubauen. Daher neige ich aus rein pragmatischen Gründen auch dazu immer einen PK zu erstellen und nie einen zusammengesetzten PK zu verwenden.

Auch unbetrittene Access Gurus (Allen Browne) verwenden diesen künstlichen PK.

Microsoft Access Tips for Casual Users

[Wurliwurm]

Im späteren Verlauf der Entwicklung der DB kommt man aber plötzlich zur Notwendigkeit doch einen eindeutigen PK zu haben.

Der PK ist immer per definition eindeutig, auch wenn er viele Attribute umfasst. Ich meine mit PK den relationalen PK und nicht die technische Umsetzung. Das sind zwei unterschiedliche Ebenen, wo man perfekt aneinander vorbeireden kann, wenn man darüber nicht im klaren ist. Strenggenommen ist der Surrogatschlüssel eine Verletzung der 3. Normalform.

[Josef P.]

Hallo!

Meine Überzeugung ist, daß ein Anfänger in relationalen Datenbanken unbedingt verstehen muß, daß ein Primärschlüssel aus mehreren Attributen zusammengesetzt sein kann.

Dem stimme ich zu 100% zu. Es kommt für mich beim Lesen der obigen Beiträge allerdings so rüber, als wären Surrogatschlüssel "ganz böse" und man darf die niemals einsetzen. ... Das betrachte ich allerdings wiederum als Quatsch. Es kommt einfach darauf an, was man erreichen will. Meiner Ansicht nach kann man keine pauschale - immer gültige - Regel für PK-Bildung (mehrer Attribute vs. Surrogatschlüssel) aufstellen, da das zu sehr von den Anforderungen abhängt, was mit der Tabelle passieren soll.
Das Argument "die Verknüpfung ist bei mehreren Felder umständlicher" sollte meiner Meinung nach aber kein Argument gegen einen FK mit mehreren Attributen sein. Ich vermeide aber z. B. FK mit mehreren Attributen, wenn sich im Lauf der Zeit ein Wert aus diesen Attributen im dazugehörenden eindeutigen Index (muss nicht zwangsweise der PK sein) ändern könnte.

Autowerte (Sequences) verwende ich z. B. gerne, wenn ich es dem Anwendungsuser (bzw. der Geschäftsregel) nicht zutraue eine geeignete eindeutige Kennung für einen Datensatz zu formulieren.
Beispiel "Rechnung": hier ist ja bereits aus gesetzlichen Vorschriften eine eindeutige "Rechnungsnummer" vorgeschrieben => diese kann man auch gleich als PK verwenden, da sie einmal festgelegt und später nie wieder geändert werden wird.
Rechnungspositionen: Sollte man die Rechnungsnummer und die Positionsnummer als PK verwenden? Was ist dann aber mit den davon abhängigen Tabellen, die diese beiden Felder als FK verwenden, wenn der Anwender die Postionen in der Rechnung "umsortiert"? => für diesem Fall setze ich einen Surrogatschlüssel (bzw. eine intern erstelle laufende Nummer je Rechnungsnummer) ein, damit keine Abhängigkeit zu einem vom User änderbaren Attribut entsteht.
Klar, man könnte die Indexänderung übers DBMS weitergeben lassen (update cascade) - damit verliere ich aber die Zugehörigkeit dieses Datensatzes zur DS-Kennung aus früheren Backups. => Surrogatschlüssel bzw. "intern erstellte" laufende Nummer, die nach der Erstellung nicht mehr geändert wird, ist mir lieber.

Die Frage, ob Access für sicherheits- und performancekitische Anwendungen geeignet ist, ist keine Ketzerfrage und muß auch in einem Access-manischen Forum gestellt werden dürfen .

Das ist einfach zu beantworten: Da Access nur eine RAD-Umgebung ist und kein DBMS, kann man jedes andere DBMS für solche Fälle einsetzen.
Das mit Access mitgelieferte DBMS (JET/ACE) ist file-basiert und wird somit in einer Mehrbenutzerumgebung niemals so performat wie ein aktives DBMS (mit genügend Server-Kapazität) sein. Bei überschaubaren Strukturen und lokaler DB-Ablage kann Jet aber sogar schneller als eine aktives DBMS sein - und wenn man das aktive DBMS nicht ausnutzt, wird damit die Performance auch nicht begeistern.  

Im späteren Verlauf der Entwicklung der DB kommt man aber plötzlich zur Notwendigkeit doch einen eindeutigen PK zu haben. Der dann erforderliche Umbau der DB ist aufwendiger als den PK gleich einzubauen.

Das machte ich auch schon öfters. In so einem Fall ergänze ich den Autowert in der Tabelle, stelle dafür einen eindeutigen Index ein und verwende bei Bedarf diesen Index als Fremdschlüssel. Die bereits vorhandenen Tabellen, welche den PK mit mehreren Attributen verwenden, müssen aber deswegen nicht umgestellt werden.

Typischer Fall: n:m-Tabelle
Normalerweise verwende ich in diesen Tabellen die 2 "Verknüpfungsfelder" als PK, wenn die Kombination nur 1x vorkommen darf. Irgendwann erweitere ich aber vielleicht das DB-Modell und erstelle Tabellen, die sich auf so einen DS beziehen. => FK mit 2 Attributen wäre denkbar. Jetzt könnte es aber sein, dass der Anwender eines dieser beiden Attribute nachträglich ändern darf => Damit ich nun trotz Änderung des PK immer erkennen kann, welchem DS das in früheren DB-Backups entspricht, füge ich einen Autowert als weiteren eindeutigen Schlüssel ein und nutze in den abhängigen Tabellen diesen Schlüssel als PK.

mfg
Josef

[Wurliwurm]

Es kommt für mich beim Lesen der obigen Beiträge allerdings so rüber, als wären Surrogatschlüssel "ganz böse" und man darf die niemals einsetzen.

Nein. Ärgern tut mich, wenn ein "Access-Meister" daher kommt und meint, Surrogatschlüssel müsse man immer einsetzen, weil sich "das so gehört". Wie gesagt, für den Anfänger erschwert das das Verständnis des Schlüsselkonzepts.