[PostNAS] Relationen-Spalten, Vereinheitlichen der Entwicklungs-Zweige

[Jäger, Frank (KRZ)]

Moin!
Nachdem PostNAS nun die Relationen direkt in den Objekt-Tabellen ablegt, wird die Tabelle "alkis_beziehungen" hyperliquid.

Die Aktualisierung dieser Tabelle über Datenbank-Trigger hat sich als schwierig erwiesen, es hat lange gebraucht bis das halbwegs fehlerfrei lief (ganz sicher bin ich mir immer noch nicht).
Außerdem waren SQL-Abfragen, die mehrere Tabellen verbinden, durch das Zwischenschalten dieser ausgelagerten Relation immer viel aufwändiger zu codieren; aus jedem JOIN wurden zwei.

Somit denke ich, dass die neue Lösung über direkte Relationen zwischen den Tabellen, ein wichtiger Schritt ist.

Allerdings war das nun lange Zeit der Stand der Dinge und somit basieren alle bisher entstandenen Views und Programme auf dieser Tabelle. Eine komplette Überarbeitung des gesamten ALKIS-PostNAS-Umfeldes wird also notwendig.
Wenn man nun schon alles überarbeiten muss, dann kann man eine andere Aufgabe dabei gleich mit ins Auge fassen:

Die Erweiterungen der Firma Norbit arbeiten oft anders, als die Teile des Projektes, die von mir und anderen im SVN bereit gestellt wurden. Um nicht für QGIS und Web-GIS zwei ganz verschiedene Datenbank-Versionen laden zu müssen, sollte das wieder zu einer gemeinsamen Lösung zusammen geführt werden.

Skizze der Unterschiede:

krz:
- Konvertierung per Shellscript
- Nur aktueller Bestand (Trigger-Function "delete_feature_kill", "ended IS NULL")
- Postprozessing mit Shell/SQL speziell für Muster-Mapfile und PHP-Auskunft
- Auskunft über Feature-Info und PHP-Script basiert auf dieser Struktur
- Mapfile aus Muster basiert auf dieser Struktur

Norbit:
- Konvertierung über Python-Oberfläche
- Historisierter Bestand (Trigger-Function "delete_feature_hist")
- Postprozessing für QGIS und QGIS-Export-Mapfile (ganz andere Tabellen)
- Auskunft über QGIS-Plugin
- Mapfile aus QGIS-Export

Um zu einer Annäherung zu kommen habe ich mal "unten angefangen": Beim Einbau der Relations-Spalten in das Datenbank-Schema habe ich einen kompletten Abgleich mit dem Norbit-Datenbank-Schema vorgenommen, das von der Python-Oberfläche von Norbit generiert wird.

Zwei Probleme, die mir daraus entwachsen sind, will ich hier erwähnen, damit man sieht, wie sehr hier mal wieder der ALKIS-Teufel im Detail steckt:


1. Die "gml_id" ist die Standard-Objektkennung bei Relationen. Sie wird auch als Parameter beim Aufruf der PHP-Scripte (Auskunft, Mapbender-Navigation) häufig benutzt. Dieses Feld war in allen Tabellen im krz-Schema bisher "character (16)", hatte also immer eine feste Länge.
Die Objekt-Kennung passte hinein, ein angehängter Zeitstempel bei Fortführungen wurde abgeschnitten. Wenn zu jedem Objekt nur die aktuelle Version vorhanden ist, braucht man das nicht.
Im Norbit-Schema ist dies Feld durchgängig formatiert als "character varying" ohne Längenbegrenzung.
Bei Aktualisierungen entstehen dann Objekte mit einer gml_id, die aus Kennung *und* Zeitstempel bestehen (lange ID).

Die Verlängerung der gml_id auf "character varying" führte bei ersten Tests zu Fehlern bei der Aktualisierung. Objekte waren danach doppelt. Das liegt daran, dass der Trigger "delete_feature_kill" bisher davon ausgeht, dass die alten und neuen Versionen eines Objektes die gleichen 16stelligen IDs haben. Der Trigger muss überarbeitet werden, wenn zukünftig mehr als 16 Zeichen vorkommen. (Übrigens: Die kill-Function in den Norbit-DBs ist eine veraltete Version).


2. Das Feld "identifier" halte ich für entbehrlich. Es ist redundant zur "gml_id". Der ID-Teil in Stelle 1-16 der gml_id wiederholt sich ab Stelle 13 des Identifiers. Davor steht immer nur die Zungenbrecher-Konstante "urn:adv:oid:".
Da das Feld "identifier" aber im Trigger "delete_feature_hist" verwendet wird - den wir nicht benutzen-  habe ich es nun zunächst drin gelassen.
Frage: Könnte man im Trigger nicht statt dessen die redundante gml_id verwenden?
Dann könnten wir "identifier" entsorgen?


Des Weiteren haben die ersten Tests mit dem überarbeiteten Schema gezeigt:

Hin-Relationen werden gefüllt. Inverse Relationen hingegen nicht. Das ist auch nicht notwendig, weil das auch redundant wäre.
Allerdings könnten alle leeren Spalten wieder entfernt werden, die ausschließlich für inverse Relationen vorgesehen sind (und ihre Indices).

Viele dieser Relationen-Felder sind Arrays. Der JOIN muss die ANY-Funktion verwenden. Ich bin mir nicht sicher, ob das performant verabeitet und ordentlich indiziert wird. 
Die postgresql-Doku sagt dazu (http://www.postgresql.org/docs/9.1/static/arrays.html):
  "Arrays are not sets; searching for specific array elements can be a sign of database misdesign.
Consider using a separate table with a row for each item that would be an array element.
This will be easier to search, and is likely to scale better for a large number of elements."

Frage an die PostNAS-Entwickler: Kann man bei 1:N-Relationen nicht generell auf der Seite referenzieren, wo es kein Array ergibt, also performanter zu Joinen ist. Bisher scheint sich das eher an Invers/nicht-Invers zu entscheiden, wo die Relation abgelegt wird.

Im nächsten Schritt werde ich alle SQL-Scripte überarbeiten mit dem Ziel die "alkis_beziehungen" nicht mehr zu verwenden. Dann die PHP-Scripte für Auskunft usw.

Das überarbeitete Datenbank-Script habe ich noch nicht veröffentlicht, weil das Gesamtsystem damit noch nicht fehlerfrei funktioniert.
Wer mit helfen möchte, die divergenten Versionen wieder zusammen zu bringen, kann gerne meinen aktuellen Zwischenstand bekommen.

PS.
Bei den Arbeiten habe ich noch das Post-Processing verbessert, das die Straßennamen für das Mapfile aufbereitet.
Einerseits gab es darin einen Fehler beim Zusammenführen von "Standard-Schreibweise" und "Schreibweise an dieser Stelle der Karte" (Grüße an Cuxhaven), anderseits tauchen in unseren Beständen nun auch Präsentationsobjekte auf, die auf einer Linie positioniert sind statt mit Punkt und Drehwinkel. Das hat Auswirkungen bis ins Mapfile (neuer Layer).


Mit freundlichen Grüßen
Frank Jäger

Kommunales Rechenzentrum
Minden-Ravensberg/Lippe
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : smime.p7s
Dateityp    : application/pkcs7-signature
Dateigröße  : 7599 bytes
Beschreibung: nicht verfügbar
URL         : <http://lists.osgeo.org/pipermail/nas/attachments/20140827/d7d2c3b6/attachment-0001.bin>