Thema - bei der LISt Gesellschaft für Verkehrswesen und ...
Thema - bei der LISt Gesellschaft für Verkehrswesen und ... Thema - bei der LISt Gesellschaft für Verkehrswesen und ...
Anhang Anhang A1 mögliche Geodateninfrastruktur der Sächsischen Straßenbauverwaltung Der Infrastrukturplan wurde als faltbares Poster beigelegt. A2 PostgreSQL Rechteverwaltung Die Umsetzung der Rechteverwaltung unter PostgreSQL-PostGIS ist im Folgenden dargestellt. Der Unterschied zur Oracle Spatial Umsetzung besteht im Wesentlichen in der Programmierung der Trigger des zentrales Views, welche durch den Einsatz von Regeln realisiert wurden. Der zentrale Datenview wurde lediglich bei der Auswahl des aktuellen Nutzers angepasst. Die Änderung ist in nachfolgendem Ausschnitt zu sehen. CREATE OR REPLACE VIEW VIEW as (… WHERE … AND n.DBAnmeldename = (SELECT CURRENT_USER) … UNION ALL (… WHERE a.id NOT IN ( … WHERE …n.DBAnmeldename = (SELECT CURRENT_USER) … Abbildung 18: PostgreSQL zentraler Datenbank-View der Rechteverwaltung 51
Anhang Der Trigger zur Prüfung der Schreibrechte wurde wie folgt umgesetzt: CREATE TRIGGER TRI_Datentabelle_BEFU BEFORE UPDATE ON Datentabelle FOR EACH ROW EXECUTE PROCEDURE function_tri_Datentabelle(); Abbildung 19: PostgreSQL Before Update Trigger der Datentabelle Die ursprüngliche Funktionalität musste dabei in eine externe Funktion ausgelagert werden: CREATE OR REPLACE FUNCTION Datentabelle RETURNS trigger AS $BODY$ DECLARE anz integer; BEGIN SELECT INTO anz count(d."Daten_ID") FROM Nutzer n, Daten_Nutzer d WHERE d.Daten_ID=old.id AND d.Nutzer_ID=n.ID AND n.DBAnmeldename= (SELECT CURRENT_USER); IF tg_op = 'UPDATE' THEN IF old. id new.id THEN RAISE EXCEPTION 'Id darf nicht verändert werden ID % ',old.id; END IF; IF anz = 0 THEN RAISE EXCEPTION 'KEINE RECHTE'; END IF; END IF; RETURN NEW; END;$BODY$ LANGUAGE plpgsql VOLATILE Abbildung 20: PostgreSQL Triggerfunktion der Datentabelle Die Realisierung der Befehle Insert, Update und Delete auf dem zentralen View wurden durch Rules implementiert. Diese sind im Folgenden abgebildet: 52
- Seite 9 und 10: HTTP Hypertext Transfer Protocol IN
- Seite 11 und 12: 1. Einleitung Verwaltungs- und Funk
- Seite 13 und 14: 2. Grundlagen 2 Grundlagen 2.1 Defi
- Seite 15 und 16: 2. Grundlagen 2.3 INSPIRE Die Richt
- Seite 17 und 18: 2. Grundlagen 2.4 Webservices Nachf
- Seite 19 und 20: 2. Grundlagen Die Datenbasis bilden
- Seite 21 und 22: 2. Grundlagen 2.4.5 WCS Durch den E
- Seite 23 und 24: 3. Ausgangssituation in der LISt Gm
- Seite 25 und 26: 3. Ausgangssituation in der LISt Gm
- Seite 27 und 28: 3. Ausgangssituation in der LISt Gm
- Seite 29 und 30: 4. Konzept einer möglichen Geodate
- Seite 31 und 32: 4. Konzept einer möglichen Geodate
- Seite 33 und 34: 4. Konzept einer möglichen Geodate
- Seite 35 und 36: 4. Konzept einer möglichen Geodate
- Seite 37 und 38: 4. Konzept einer möglichen Geodate
- Seite 39 und 40: 4. Konzept einer möglichen Geodate
- Seite 41 und 42: 5. Teilweiser Aufbau einer prototyp
- Seite 43 und 44: 5. Teilweiser Aufbau einer prototyp
- Seite 45 und 46: 5. Teilweiser Aufbau einer prototyp
- Seite 47 und 48: 5. Teilweiser Aufbau einer prototyp
- Seite 49 und 50: 5. Teilweiser Aufbau einer prototyp
- Seite 51 und 52: 5. Teilweiser Aufbau einer prototyp
- Seite 53 und 54: 5. Teilweiser Aufbau einer prototyp
- Seite 55 und 56: 5. Teilweiser Aufbau einer prototyp
- Seite 57 und 58: 6. Zusammenfassung 6 Zusammenfassun
- Seite 59: 7. Ausblick Softwarelösungen exist
- Seite 63 und 64: Anhang Damit ist die Konfiguration
- Seite 65 und 66: Anhang layer="LAYERS=Sachsen_1,Sach
- Seite 67 und 68: Anhang sowie die erhaltenen Kartena
- Seite 69 und 70: Bibliographie Internet Zeitpunkt de
- Seite 71: Bibliographie [i12] Gesetz über da
Anhang<br />
Der Trigger zur Prüfung <strong>der</strong> Schreibrechte wurde wie folgt umgesetzt:<br />
CREATE TRIGGER TRI_Datentabelle_BEFU<br />
BEFORE UPDATE<br />
ON Datentabelle<br />
FOR EACH ROW<br />
EXECUTE PROCEDURE function_tri_Datentabelle();<br />
Abbildung 19: PostgreSQL Before Update Trigger <strong>der</strong> Datentabelle<br />
Die ursprüngliche Funktionalität musste da<strong>bei</strong> in eine externe Funktion ausgelagert<br />
werden:<br />
CREATE OR REPLACE FUNCTION Datentabelle RETURNS trigger AS<br />
$BODY$<br />
DECLARE<br />
anz integer;<br />
BEGIN<br />
SELECT INTO anz count(d."Daten_ID")<br />
FROM Nutzer n, Daten_Nutzer d<br />
WHERE d.Daten_ID=old.id AND d.Nutzer_ID=n.ID AND n.DBAnmeldename=<br />
(SELECT CURRENT_USER);<br />
IF tg_op = 'UPDATE' THEN<br />
IF old. id new.id THEN<br />
RAISE EXCEPTION 'Id darf nicht verän<strong>der</strong>t werden ID % ',old.id;<br />
END IF;<br />
IF anz = 0 THEN<br />
RAISE EXCEPTION 'KEINE RECHTE';<br />
END IF;<br />
END IF;<br />
RETURN NEW;<br />
END;$BODY$<br />
LANGUAGE plpgsql VOLATILE<br />
Abbildung 20: PostgreSQL Triggerfunktion <strong>der</strong> Datentabelle<br />
Die Realisierung <strong>der</strong> Befehle Insert, Update <strong>und</strong> Delete auf dem zentralen View wurden<br />
durch Rules implementiert. Diese sind im Folgenden abgebildet:<br />
52