Trigger für automatisches Aufüllen

[Dr.Schlumpf]

Hallo zusammen,

ich bräuchte mal eure Hilfe bei der Erstellung eines Triggers. Ich probieren da jetzt schon so lange dran rum und komme einfach auf keinen grünen Zweig.
Also was ich machen möchte:
Ich habe eine Tabelle, in der ein Unternehmen einer bestimmten Kategorie zugeordnet wird. Die Kategorien sind hierarchisch. Lieder ist nicht immer die unterste Kategorie verfügbar und daher wird immer die Kategorie eingetragen, die verfügbar ist:

Tabelle unt_kat
id id_unt nr_kat1 nr_kat2 nr_kat3
--------------------------------------------
1 1 NULL 01 NULL
2 2 NULL NULL 03.1

Ich möchte nun automatisch die fehlenden Werte der übergeordneten Kategorien (nr_kat1 im 1 Fall und nr_kat2 und nt_kat1 im zweiten Fall) auffüllen. Auffüllen will ich über eine Abfrage in der Tabelle, in der die Verknüpfungen stehen:

Tabelle kat2
nr_kat2 beschr nr_kat1
-------------------------------
01 bla A
02 blabla A
03 bbbla B


Tabelle kat3
nr_kat3 beschr nr_kat2
-------------------------------
01.1 xxxx 01
01.2 yyyy 01
03.1 zzzzzz 03


Mein Trigger sieht bisher wie folgt aus:

CREATE OR REPLACE TRIGGER untkat_trg
    BEFORE INSERT ON unt_kat
    FOR EACH ROW
    WHEN ( new.nr_kat1 IS NULL AND new.nr_kat2 IS NOT NULL )
BEGIN
    set nr_kat1 = (SELECT nr_kat1 from kat2  WHERE nr_kat2 = new.nr_kat2);
END;
/

Ich bekommen immer den Fehler:

2/5 PL/SQL: SQL Statement ignored
2/9 PL/SQL: ORA-00922: Fehlende oder ungültige Option
Fehler: Compilerlog prüfen

Ich hoffe, ich konnte verständlich beschreiben, was ich will und freue mich über eure Hilfe.
Ach, und ich hab ne Oracle DB.

Danke

 

[akretschmer]

Ich hoffe, ich konnte verständlich beschreiben, was ich will und freue mich über eure Hilfe.

Nicht wirklich. Ich lese daraus nur, daß rekursive Abfrage gewünscht, aber nicht verstanden sind.

• warum Tabellen wie kat2 und kat3, die identischen Aufbau haben?
• was passiert, wenn es 3, 4 oder 42 Ebenen gibt?
• offensichtlich kranke Datentypen (irgend ein Text-Kram, ...)

Ach, und ich hab ne Oracle DB.

Ja, Du mußt hier nicht um Mitleid betteln ;-) Bekommst Du nicht. Tut mir auch nicht Leid.

 

[castorp]

Das Tabellendesign ist wirklich fragwürdig. Für hierarchische Strukturen bietet sich eine einzige Tabelle mit einem Foreign key auf sich selbst an. Dieser zeigt dann auf die übergeordnete Kategorie

create table kategorie
(
   id integer primary key,
   name varchar(100) not null,
   parent_kat integer references kategorie
);

Zu Deinem Trigger: Du kannst nicht einfach ein SET "motivationslos" in einem Trigger verwenden.

Wenn Du einer Spalte des neu eingefügten Datensatzes einen Wert zuweisen willst, dann geht das ohne SET, z.B. einfach mit new.nr_kat1 := ...

Wenn der Wert aus einer anderen Tabelle kommen soll, musst Du ein SELECT .. INTO verwenden

CREATE OR REPLACE TRIGGER untkat_trg
   BEFORE INSERT ON unt_kat
   FOR EACH ROW
   WHEN ( new.nr_kat1 IS NULL AND new.nr_kat2 IS NOT NULL )
BEGIN
  select nr_kat1
     into :new.nr_kat1
  from kat2
  WHERE nr_kat2 = :new.nr_kat2;
END;
/

Aber wie gesagt: das ist eine wirklich ganz schlechte Idee das so zu machen.

Mit der von mir am Anfang gezeigten Tabelle brauchst Du diesen Trigger überhaupt nicht (und es reicht eine Tabelle)

 

[Dr.Schlumpf]

Danke für die Antworten und die Hilfe.

Nicht wirklich. Ich lese daraus nur, daß rekursive Abfrage gewünscht, aber nicht verstanden sind.

Als ich die DB entworfen habe, hatte ich tatsächlich das erst hierarchisch modelliert, bin aber aus irgendwelchen Gründen wieder davon abgekommen. Aber Danke für die Erinnerung, hatte das irgendwie aus den Augen verloren. Werde das jetzt einfach mal praktisch prüfen. Letztendlich brauche ich die oben modellierte Tabelle (wo ich für jedes Unternehmen alle zugehörigen bekannten Hierachieebenen habe) irgendwie, aber dann wahrscheinlich eher als View.

• was passiert, wenn es 3, 4 oder 42 Ebenen gibt?

• offensichtlich kranke Datentypen (irgend ein Text-Kram, ...)

Es gibt nur 5 Ebenen und ob sie krank sind, weiß ich nicht, sind die Wirtschaftszweigklassifikationen und um die komme ich leider nicht herum.