Was ist ein Key-preserved table?

Schonmal mit einer Oracle Datenbank gearbeitet? Und auch schon diesen ORA bekommen?

ORA-01752: cannot delete from view without exactly one key-preserved table

Nun, was hat es damit auf sich?

Eine Tabelle ist dann „key-preserved“ wenn jeder Schlüssel der Tabelle auch der Schlüssel des Joins sein kann. Das bedeutet dass der eindeutige Schlüssel durch einen Join erhalten bleibt. Dies liegt nicht dem Inhalt des Tables zugrunde sondern dem Schema, welchem die Tabelle zugrundeliegt.

Am besten ist das wohl an einem Beispiel erklärt:

create view fehlermeldungen as
select f.id fid, f.name fname, m.id mid, m.name mname
from modul m, fehler f
where f.modul_id = m.id;

Wenn wir die Daten der View aufrufen bekommen wir beispielhaft folgende Werte:

FID        FNAME      MID        MNAME
---------- ---------- ---------- ----------
       101 NULLP              10 MAIN
       102 ARRAY              10 MAIN
       103 STRING             10 MAIN
       104 DATE               20 GUI
       105 STRING             20 GUI
       106 NULLP              20 GUI
       107 NULLP              20 GUI
       108 STRING             20 GUI
8 rows selected.

Der Key der zugrundeliegenden Tabelle fehler blieb erhalten. Anhand dieses Keys kann auch in der View in der der Join erfolgte immernoch ein einzelner Datensatz extrahiert bzw. identifiziert werden. Der Key der Tabelle modul hingegen ist zwar für die Tabelle eindeutig, ist aber kein Key des Joins mehr. In dem Fall ist also f.id key-preserved und m.id nicht.
Die Ursache liegt bereits bei der Verbindung der beiden Tabellen. Die Modul.id wird als Fremdschlüssel auf der Tabelle Fehler geführt und muss dort somit nicht unique sein.

Oracle selbst erlaubt eine Tabelle je View die ihren Schlüssel in der View behält, wenn man auf dieser Datenmanipulationen zulassen möchte. Sind zwei oder mehr schlüssel-erhaltende Tabellen in der View enthalten, gelten für die einzelnen Datenmanipulationsvorgänge spezielle Regeln die befolgt werden müssen. Dazu später mehr.

Um dieses Problem zu umgehen bleiben einem somit nur 3 Möglichkeiten:

1. Die Datenstruktur soweit anpassen oder eine neue View bauen die die Vorraussetzungen erfüllt.
2. Anstatt mit der View direkt mit den Tabellen zu arbeiten.
3. Das Problem umschiffen indem man mit „Instead of“-Trigger an die View gehängt arbeitet.

Was man beachten muss wenn man eine View erstellt und diese für weitere Operationen heranziehen will:

• UPDATE: Alle Spalten, in denen Information upgedated werden soll, müssen von einem key-preserved Table stammen. Wenn in der View die CHECK OPTION gesetzt ist müssen alle JOIN Spalten und Spalten von Tabellen die mehr als einmal referenziert sind, von dem Update geschützt sein.
• DELETE: Es darf nur einen key-preserved Table in der View geben, dieser Table kann zwar mehrfach in der View vorkommen, jedoch nur wenn die View die CHECK OPTION gesetzt hat.
• INSERT: Alle Spalten, in die Information neu eingetragen werden, müssen vom key-preserved Table kommen. Hierbei darf die View nicht die CHECK OPTION gesetzt haben.

Kurz zur WITH CHECK OPTION Klausel:
Ist die View mit dieser Klausel ausgestattet werden schon vor dem Einfügen oder Verändern von Datensetzen die WHERE Klauseln überprüft. Würde ein neuer Datensatz nicht durch die Einschränkungen der WHERE Klausel als gültig erkannt werden, wird die Aktion bereits vor der Ausführung verhindert bzw. nicht durchgeführt.

Quellen:
[1] http://download-west.oracle.com/docs/cd/B10501_01/server.920/a96521/views.htm#4054

[2] http://ora-01752.ora-code.com/

[3] http://www.praetoriate.com/t_grid_rac_admin_db_links.htm

Ähnliche Artikel:

• Gebt Oracle Zeit!