MS SQL Server - Definition einer rekursiven Beziehung (m:n)

[Tarik_BS]

Seid Ihr gegrüßt, Leute,

Ich wirke noch immer beim Aufbauen einer kleinen Firmendatenbank mit und bin auf ein weiteres Problem gestoßen - wie ich eine m:n Rekursivbeziehung unter MS SQL Server 2005 hinkriege. Hier - ein Beispiel:

Gegeben ist dieselbe Tabelle tbl_Projekt (Projekt_ID int/Primary Key/,Projektnummer,Projektkategorie, ...)

Es gibt 2 Arten von Projekten: Arbeitsprojekt und Akquisitionsprojekt
Alle Arbeitsprojekte sind aus einem oder mehren Akquise-Projekten hervorgegangen (sprich wurden beauftragt), alle Projekte werden in einer Tabelle geführt und haben bloß unterschiedliche Stati und Kategorien, dies ist notwendig, da Akquise-Projekte und "normale" Projekte gleiche Attributten besitzen.

Um diese Beziehung aufzubauen, müsste ich eine 2. Tabelle haben, wo Zuordnung von Projekten zu ihren "Akquise-Eltern" erfolgt: tbl_Projekt_zu_AKQ(Projekt_ID,AKQ_ID), wo beide Attributte auf Projekt_ID geschlossen sind.

Die Frage: Wie lässt es sich im SQL Server realisieren? Wenn ich folgende CONSTRAINTs einfüge - kriege ich eine Fehlermeldung, da die beiden FK auf dieselbe Spalte verweisen:

(...) CONSTRAINT [tbl_P_AKQ_FK00] FOREIGN KEY([Projekt_ID])
REFERENCES [dbo].[tbl_Projekte] ([Projekt_ID])
ON UPDATE CASCADE,

CONSTRAINT [tbl_P_AKQ_FK01] FOREIGN KEY([Akquise_ID])
REFERENCES [dbo].[tbl_Projekte] ([Projekt_ID])
ON UPDATE CASCADE

Ich bin ja nicht vom Fach und schwitze an dem Projekt schon ziemlich lange, möchte aber dies gern durchziehen

Vielen besten Dank!

Grüße aus Braunschweig

 

[Huschi]

Wenn ich diese Datenbankstruktur in die dritte Normalform umwandel erhalte ich 2 Projekt-Tabellen.

Oder anders ausgedrückt:
Warum kompliziert wenn es auch einfach geht?

huschi.

 

[Tarik_BS]

Hallo Huschi,

Sorry für spätere Rückmeldung, war gestern ganzen Tag auswärts.

Das ist ja genau das Problem, dass die Tabelle nicht gegen die 3. NF verstößt, die Projekte werden lediglich einer bestimmten Kategorie über einen FK zugeordnet, der Rest der Daten bleibt davon unbeeinflüßt.

Sollte man die Tabelle aufteileilen, würde das bedeuten das die ganzen 21 Projektattribute wiederholt erstellt werden, außerdem ist der ganze Informationsström der Datenbank an die Projekte gebunden (bei der Zeit- und Kostenerfassung bsp.), sprich muss ich dann jede Tabelle mindestens doppelt verknüpfen, was unterm Strich die Redundanz schlechthin ist.

Drum wollte ich dies über eine rekursive m:n Beziehung lösen, was übrigens im Access durchaus möglich ist - eine Beispieldantenbank ist im Anhang:

, konnte dies aber nicht unter SQL Server 2005 realisieren.
Darum schreie ich um Hilfe, da ich einfach nicht weiterkomme

Danke im voraus,

Grüße aus Braunschweig

 

[Tarik_BS]

Hallo Allerseits!

Meine Frage hat sich erledigt, bei der CONSTRAINT-Definition lasse ich die Anweisung ON UPDATE CASCADE einfach weg bzw. benutze ON UPDATE NO ACTION und schon funktioniert es! Es lag an der Gefahr der Entstehung einer endlosen Schleife bei Aktualisierungsweitergabe, falls die Projekte direkt oder indirekt sich selbst zugeordnet werden. Da schimpfte der Server los
Aber auf jeden Fall danke für Eure Hinweise!

Wünsche Euch allen einen guten Rutsch ins Neue Jahr und schöne (diesmal orthodoxische) Weihnachten!

Schöne grüße aus Braunschweig