Laden...

Probleme mit Beziehungen

Erstellt von thomas.at vor 14 Jahren Letzter Beitrag vor 14 Jahren 1.194 Views
T
thomas.at Themenstarter:in
111 Beiträge seit 2005
vor 14 Jahren
Probleme mit Beziehungen

verwendetes Datenbanksystem: <SQL2008>

Hallo Leute

ich habe 3 Tabellen (Tabelle1, Tabelle2 und Tabelle3). Tabelle1 hat eine Beziehung auf Tabelle2 und Tabelle3 (auf das gleiche Feld). Ich möchte nun die entsprechenden Beziehungen setzen:

Tabelle1/Feld -> Tabelle2/Feld (Delete = No Action Update = Cascade)
Tabelle1/Feld -> Tabelle3/Feld (Delete = No Action Update = Cascade)

Wenn ich diese Beziehungen dann speichern möchte, kommt folgende Fehlermeldung:


'Table1' table saved successfully
'Table2' table
- Unable to create relationship 'FK_Table2_Table1'.  
Introducing FOREIGN KEY constraint 'FK_Table2_Table1' 
on table 'Table2' may cause cycles or multiple cascade paths. 
Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, 
or modify other FOREIGN KEY constraints.
Could not create constraint. See previous errors.

Wenn ich in einer der beideb Beziehungen das Update=Cascade auf No Action umstelle, dann kann ich das speichern. Dann müsste ich mich aber selbst darum kümmern, wenn sich in der Tabelle1 der Wert im Feld ändert, das in der entsprechenden Tabelle der Wert nach gezogen wird.
Wo mache ich da den Fehler?

lG
Thomas

P.S. Tabelle2 und Tabelle3 stehen über eine weitere Tabelle (Tabelle4) in Beziehung. Bei dieser sind die Update und Delete-Regeln auf Cascade eingestellt.
Ich hoffe die Beschreibung ist halbwegs verständlich.

J
1.114 Beiträge seit 2007
vor 14 Jahren

Dann müsste ich mich aber selbst darum kümmern, wenn sich in der Tabelle1 der Wert im Feld ändert

Ich glaube, genau DA liegt ein Denkfehler deinerseits vor. Cascading Updates bedeutet in deinem Fall nicht, wenn sich der Wert in Tabelle1 ändern, dass dann der Wert in Tabelle2 + 3 mit geupdated werden soll. Es ist genau die andere Richtung zu verstehen. Ein Update vom Primary Key Feld in Tabelle2 (oder Tabelle3) würde bei Cascading Updates alle referierenden Datensätze aus Tabelle1 anpassen.

Bsp.: In einer Tabelle Artikel gibt es einen Artikel mit einer ArtikelId 4911. Eine andere Tabelle Rechnung referenziert auf diesen Artikel 4911 indem in Spalte ArtikelId die 4911 steht. Ein Update der ArtikelId IN DER ARTIKEL Tabelle auf 0815, würde bei Cascading Updates alle Records in Tabelle Rechnung, die auf die alte ArtikelId 4711 referenzieren updaten, indem der Wert durch 0815 ersetzt wird.

T
thomas.at Themenstarter:in
111 Beiträge seit 2005
vor 14 Jahren

Hallo

genauso soll es ja auch sein. Tabelle1 sind die Artikel, Tabelle2 die Stücklisten und Tabelle3 die Rechnungen. Wenn sich jetzt eine Artikelnummer ändert, dann sollen in den anderen Tabellen diese Änderung mitgezogen werden. Und hier kann ich eben nur entweder auf die Stücklisten oder die Rechnungen das Cascade machen, aber nicht auf beide.

Die Stücklisten sind noch über die Tabelle "Geräte" mit den Rechnungen verknüpft, wobei es hier eben das Cascade auch auf das Delete gibt. (d.h. wenn es keine Stückliste mehr gibt, dann auch kein Gerät und keine Rechnung mehr)

lG
Thomas

J
1.114 Beiträge seit 2007
vor 14 Jahren

Poste doch mal ein Diagrammschema der Tabellenstruktur, damit ich mal klarer seh, wie das alles in Beziehung zueinander steht

1.564 Beiträge seit 2007
vor 14 Jahren

Hi

Nur so aus Neugier. Warum sollte sich der Primärschlüssel eigentlich jemals ändern?
?(

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.

T
thomas.at Themenstarter:in
111 Beiträge seit 2005
vor 14 Jahren

Hallo

@Flo
leider ist es so, das die Konstrukteure die Artikel mal als Dummy anlegen und erst später die richtige Artikelnummer eingetragen wird.

@Jelly
ich habe mal in VS ein abgespecktes Schema erstellt, in dem die ganzen Beziehungen eingezeichnet sind. Vielleicht hilft Dir das ja etwas weiter.

Vielen Dank im Vorraus
Thomas

1.564 Beiträge seit 2007
vor 14 Jahren

Hallo Thomas

@Flo
leider ist es so, das die Konstrukteure die Artikel mal als Dummy anlegen und erst später die richtige

Ganz ganz ganz dringende Empfehlung: Niemals einen Business-Schlüssel als Datenbank-Identität verwenden!

Grüße
Flo

Blog: Things about Software Architecture, .NET development and SQL Server
Twitter
Google+

Je mehr ich weiß, desto mehr weiß ich was ich noch nicht weiß.