Foreign-Key-Problem in Transaktion

verwendetes Datenbanksystem: SQL-Server 2005

Hallo,

nach einigem Suchen habe ich nichts konkretes gefunden.

Ich habe eine Tabelle die einen zusammengesetzen und damit manuell
gesteuerten PK verwendet.
Eine andere Tabelle verweist auf diesen PK und hat damit einen FK.

Nun mein Problem:

In einer Transaktion möchte ich den PK der ersten Tabelle ändern, wo
nun jedoch gleich eine FK-Verletzung auftritt, so dass ich gar nicht erst
dazu komme den zweiten Teil der Transaktion, nämlich die Aktualisierung
des FK in der verweisenden Tabelle auf den geänderten PK, durchzuführen.

Ich dachte immer, dass Transaktionen dafür da sind, dass innerhalb dieser
inkonsistente Daten bestehen dürfen, nur ausserhalb müssen die Daten
stimmen.

Mache ich da was falsch? Gibt es einen 'Workaround'? Oder macht man sowas
gänzlich anders?

Viele Grüße

interNETt

Da hast du aber etwas grundsätzlich falsch verstanden.
Transaktionen sind dafür da, um zusammengehörige Aktionen abzusichern,
nicht damit darin inconsistentente Daten sein können.

Warum möchtest du denn deinen PK ändern?
Wie auch immer:

Ich würde sagen so lange die Schlüssel in Beziehung miteinander stehen kannst du diese gar nicht ändern...
Höchstens einem anderen bestehenden FK zuweisen, den PK der ersten Tabelle ändern (wenn sie nicht noch in Beziehung mit anderen Zeilen steht) und dann erst den FK entsprechen umsetzen.

Hallo,

habt Dank für die Antworten. Da werde ich wohl nicht drumherumkommen das (PK)-FK constraint zu eliminieren.

@FZelle laut wiki dürfen die Daten durchaus inkonsistent sein während der Transaktion:

Zitat wikibooks.org Transaktionssysteme: Transaktionen: (Abschnitt ACID)
"Konsistenz (consistency): Vor und nach einer Transaktion müssen die Daten in einem konsistenten Zustand sein. Hier wird gefordert, dass eine Transaktion die Daten ebenso „sauber“ hinterlässt, wie sie sie vorfindet. „Konsistent“ bedeutet, dass es keine Widersprüche jedwelcher Art gibt. Dies deckt technische Widersprüche wie mehrfach vorhandene Datensätze oder redundante Datensätze mit widersprüchlichem Inhalt ebenso ab wie inhaltliche Widersprüche, beispielsweise dass in einem geschlossenen Geldkreislauf plötzlich mehr Geld existiert. Wichtig ist festzuhalten, dass der Zustand der Daten während der Ausführung einer Transaktion durchaus inkonsistent sein darf."

Nur leider betrifft die Inkonsistenz wohl nicht die PK/FK-Beziehung, zumindest beim SQL-Server.

edit:

Habe doch noch eine Lösung des Problems gefunden. Und zwar die kaskadierte Schlüsselaktualisierung.
Diese ist definierbar/erreichbar per Tabellen-Designer, unter INSERT- und UPDATE-Spezifikation, Unterpunkt
'Regel aktualisieren'. Dort 'Überlappend' auswählen. Zitat Microsoft: 'Überlappend aktualisiert alle Zeilen,
die Daten enthalten, die an der Fremdschlüsselbeziehung beteiligt sind.'

Also sobald ich den PK an der Haupttabelle ändere, wird der FK an der anderen Tabelle aktualisiert.
Damit spare ich gleich noch die Updateanweisung für die FK-Aktualisierung.

Viele Grüße

interNETt

Ich habe eine Tabelle die einen zusammengesetzen und damit manuell
gesteuerten PK verwendet.

Das ist böse... Nie Informationen im PK verwenden, sondern einfach nur fortlaufende Nummern oder Guids, ohne sachlichen nhalt.

Nun mein Problem:

In einer Transaktion möchte ich den PK der ersten Tabelle ändern, wo
nun jedoch gleich eine FK-Verletzung auftritt

Genau aus dem Grund sollt man das nicht machen.

verwendetes Datenbanksystem: SQL-Server 2005

Da hast du jetzt Glück. Du kannst beim Foreign Key "Cascading Updates" einstellen. Dadurch wird beim Ändern des PK der Mastertabelle dessen Foreign Key in der Detailtabelle mit angepasst. Eine Transaktion dazu brauchts nicht.
Die Update Rule auf "Cascade" setzen.

Hallo Jelly,

danke, bin auch gerade darauf gekommen 😃

Viele Grüße

internett

Ich habe eine Tabelle die einen zusammengesetzen und damit manuell
gesteuerten PK verwendet.
Das ist böse... Nie Informationen im PK verwenden, sondern einfach nur fortlaufende Nummern oder Guids, ohne sachlichen nhalt.

Du meinst die Identität. PK dürfen gern zusammengesetzt sein - sie definieren die Einzigartigkeit eines Datensatzes. Identitäten sind nur eine Eigenschaft eines Datensatzes, deren Einzigartigkeit sich nicht aus ihrer Natur, sondern aus ihrer Behandlung ergibt. Benutzt du sie als PK, ist das semantisch falsch - du gibst deinen Daten eine Struktur, die nicht ihrer Bedeutung entspricht.

Beliebtes Beispiel m:n - Beziehungstabelle, die den jeweils die Identitäten von zwei Tabellen enthält, plus eine eigene Identität. Wäre die Identität der PK, würdest du der Datenbank mitteilen, dass gleiche Einträge mit verschiedenen Identitäten okay wären. Das ist aber nicht der Fall.

LaTino

Du meinst die Identität. PK dürfen gern zusammengesetzt sein - sie definieren die Einzigartigkeit eines Datensatzes.

Ja, genau das meinte ich auch. Es sollte halt eben keine Nutzerinformation im PK liegen. Sorry, wenn ich mich schlecht ausgedrückt habe.