Migrationsproblem Access 2003 zu MS SQL Server 2005

[Tarik_BS]

Hallo Allerseits,

Bin ein ziemlicher Anfänger in der Sache SQL-Server, meine Aufgabe ist nun eine Firmendatenbank, deren Tabellenstruktur in Access entworfen wurde (Tabellen mit Testdaten / Definierte Beziehungen und Gültigkeitsregel) auf dem SQL-Server aufzubauen.
Die in Access erstellete Backend habe ich per Upsizing-Assistent auf den Server übertragen, wobei die Integritätsregeln mit automatisch erstellten Triggern definiert wurden.

Problem: Nun werden keine NULLs bei Fremdschlüssel-Felder der Tabellen (ausgerechnet durch Insert- und UpdateTriggers) zugelassen, sollte aber der Fall sein, da die DB-Einträge mit den Daten der verwandten Tabellen später aktualisiert werden. Bei der Tabellendefinition sind die NULLs für diese Felder zugelassen. So etwas hat Access einfach erlaubt.

Allerdings funktioniert das, wenn ich diese Trigger deaktiviere. Ich bin mir aber nicht sicher ob es ein guter Weg ist. Wenn ich die Trigger umprogrammiere, werden jegliche Einträge außer NULL verworfen.

Frage: Brauche ich die Trigger wirklich für die Integritätsüberwachung? , Vielleicht, reichen die durch CONSTRAINTs festgelegte Beziehungsregel bei der Tabellendefinition aus?

Für Eure Antwort und Hilfe wäre ich total dankbar, sitz auf dem Problemchen schon eine Weile.

Schöne Grüße aus Braunschweig

 

[daseddy]

Problem: Nun werden keine NULLs bei Fremdschlüssel-Felder der Tabellen (ausgerechnet durch Insert- und UpdateTriggers) zugelassen, sollte aber der Fall sein, da die DB-Einträge mit den Daten der verwandten Tabellen später aktualisiert werden. Bei der Tabellendefinition sind die NULLs für diese Felder zugelassen. So etwas hat Access einfach erlaubt.

Fremdschlüssel dürfen nicht NULL sein, macht ja auch keinen Sinn, weil NULL ein nicht definierter Zustand ist. Warum das von Access erlaubt wird kann nicht nicht nachvollziehen.
Ich an deiner Stelle würde überlegen ob dein Datenbanklayout in der jetzigen Form richtig ist. Ein Beispiel (Wie ist die Tabellenstruktur?) wäre schon hilfreich. Musst ja nicht das wirkliche Layout verraten.

 

[Tarik_BS]

Fremdschlüssel dürfen nicht NULL sein, macht ja auch keinen Sinn, weil NULL ein nicht definierter Zustand ist. Warum das von Access erlaubt wird kann nicht nicht nachvollziehen.
Ich an deiner Stelle würde überlegen ob dein Datenbanklayout in der jetzigen Form richtig ist. Ein Beispiel (Wie ist die Tabellenstruktur?) wäre schon hilfreich. Musst ja nicht das wirkliche Layout verraten.

Hi, danke für Deine Rückmeldung, an dem layout ist nichts geheimes
In erster Linie geht es um ein Problem der rekursiven Beziehungen. Beispiel:
Gegeben ist eine Tabelle mit folgenden Attributen tbl_Projekte (Projekt_ID/nummerisch, Projektnummer/a-nummerisch, Hauptprojekt_ID / nummerisch, PR_Leiter / nummerisch)

Ein Projekt kann mehrere Unterprojekte haben oder ein Unterprojekt zu anderen sein. Sprich ist die Tabelle an sich über FK Hauptprojekt_ID geschlossen. Wenn das Projekt bereits ein Hauptprojekt ist, bleibt Hauptprojekt_ID NULL. Dies wird von Triggers nicht akzeptiert. Andersherum gilt für den neuen Eintrag Hauptprojekt_ID = inserted.Projekt_ID, so wird die referetielle Integrität verletzt, da die "neue" Projekt_ID noch nicht gespeichert ist.

Grüße aus BS,

 

[daseddy]

Ein Projekt kann mehrere Unterprojekte haben oder ein Unterprojekt zu anderen sein. Sprich ist die Tabelle an sich über FK Hauptprojekt_ID geschlossen. Wenn das Projekt bereits ein Hauptprojekt ist, bleibt Hauptprojekt_ID NULL. Dies wird von Triggers nicht akzeptiert. Andersherum gilt für den neuen Eintrag Hauptprojekt_ID = inserted.Projekt_ID, so wird die referetielle Integrität verletzt, da die "neue" Projekt_ID noch nicht gespeichert ist.

Mhh. Also ich würde daraus zwei Tabellen machen. Eine Projekttabelle(Projekt_ID/nummerisch, Projektnummer/a-nummerisch, PR_Leiter / nummerisch) und eine Tabelle Unterprojekte mit zwei Spalten (Hauptprojekt,Unterprojekt), wobei beide Schlüssel Fremdschlüssel zur Projekttabelle(Projekt_ID) sind. Müsstest Du eigentlich beim "normalisieren" der Tabellen drauf gestoßen sein, da deine Tabelle gegen die zweite(???/bin mir da nicht ganz sicher) Normalform verstößt.

 

[Tarik_BS]

hm, ist mir wirklich nicht aufgefallen, wichtig war auch das ein Projekt nur ein Mutterprojekt besitzt und nicht mehr, kann, natürlich, auch durch Unikat-Index definiert werden.. Aber das NULL-Problem wäre somit vom Tisch!
Danke vielmals, werde die Grundstruktur nochmal durchgehen. Was auf den ersten Blick auffällt - die Abfragen werden demnach anders gestaltet, ich muss erstmal ausprobieren, bin ja kein Profi , bloß ein kleiner naiver Nutzer

Eine Frage bleibt doch : sind die Triggers relevant für die Überwachung von Beziehungen? Denn das Verhalten der Daten und Tabellen ist bereits durch CONSTRAINTs (PK/FK/REFERENCES usw) definiert. Oder sind das gar nicht so gleichwertige Dinge?

 

[daseddy]

Zwischen Trigger und Constraints gibt es ein paar Unterschiede. Die jetzt im genauen zu beschreiben fehlt mir die Motivation.
Allgemein kann man sagen: Constraints sind Beschränkungen der Datenbank und Trigger definierte Funktionen die auf vorgegebene Ereignisse ausgeführt werden.

 

[Tarik_BS]

Hi,
Ich glaube, ich habe es verinnerlicht die Triggers sind ja für Gültigkeitsprüfung der Daten unentbehrlich! Hab den besten Dank!
Wünsche Dir eine angenehme Woche!

Grüße aus Braunschweig