[PostNAS] PotNAS 0.8 - Datenbank-Schema

Do Sep 11 06:46:51 PDT 2014

Hallo Herr Jäger,

die von Ihnen erwähnte Erweiterung der gml_id um einen Zeitstempel nach 
Einspielung von Fortführungsdaten habe ich bisher nicht feststellen können.
Bei mir hat das alte Objekt und das neue die gleiche gml_id...
Wir verwenden ja die Variante mit Historie. Findet diese Erweiterung 
evtl. nur statt, wenn man keine Historie verwendet?

Gruß,
Stefan Rahn

GDI-Service
Joachim-Jungius-Str. 9
18059 Rostock
Tel: 0381 40344445
E-Mail: stefan.rahn at gdi-service.de
www.gdi-service.de

Am 10.09.2014 15:45, schrieb Jäger, Frank (KRZ):
> Hallo PostNAS-Freunde,
> Astrid hat den bisherigen Stand in den Branch 0.7 kopiert [1].
> Somit konnte ich meine Arbeiten der letzten zwei Wochen in den Trunk hochladen [2].
> Der SVN-Zweig "Version-0.8" wird noch gelöscht. Die nun aktuelle Version 0.8 wird im Trunk weiter geführt.
>
>
> *** Das PostgreSQL/PostGIS-Datenbank-Schema für PostNAS Version 0.8 ***
>
> Die wichtigste Änderung von Version 0.7 auf 0.8 betrifft die Beziehungen (Relationen) zwischen den Objekten. Bisher wurde dazu eine eigene Tabelle geführt, die "alkis_beziehungen". Diese war für fast alle Relationen zuständig, Ausnahmen davon waren reine Schlüsseltabellen z.B. die Verbindung von Lage (Hausnummer) zu Lagebezeichnung-Katalogeintrag (Straßentabelle). Das Zwischenschalten diese Beziehungen-Tabelle zwischen jeweils zwei Objekt-Tabellen machte die Views unnötig lang.
> Das Aktualisieren der Beziehungen-Tabelle beim Konvertieren von Differenzdaten aus dem NBA-Verfahren (Delete, Update, Replace) war kompliziert.
>
> Diese Tabelle "alkis_beziehungen" wird nun ersetzt durch Relationen-Spalten direkt in den Objekt-Tabellen. Diese Änderung ist so durchschlagend, dass alle Teile des Projektes gleichzeitig umgestellt werden müssen. Auswerteprogramme der Version 0.7 funktionieren nicht mit einer Datenbank der Version 0.8 und umgekehrt.
> Da also sowieso eine komplette Überarbeitung notwendig war, habe ich noch einige weitere Verbesserungen eingearbeitet. Die Schema-Version von NorBIT (QGIS) und der ALKIS-Objektartenkatalog wurden mit in diese Überarbeitung einbezogen.
>
> Rückschau zum Verständnis: Das ursprüngliche Schema wurde zu Beginn des Projektes PostNAS ganz pragmatisch erzeugt, indem man PostNAS (ogr2ogr) eine NAS-Datei in eine leere Datenbank konvertieren ließ. Wenn eine Zieltabelle noch nicht vorhanden ist, dann legt ogr2ogr diese Tabelle selbst an. Die Eingabe-Daten werden dazu analysiert.
> Beim NAS-Datenformat ist dies aber für den dauerhaften produktiven Einsatz keine brauchbare Lösung. Die NAS-Dateien können lokal unterschiedliche Inhalte haben, so dass dann jede von PostNAS selbst erzeugte Datenbank anders aussieht. Auch ist die Abgabe eines Gebietes mit dem NBA-Verfahren auf mehrere Dateien aufgeteilt. Die erste Datei (Randlage) würde die Datenstruktur festlegen. Auf dieser Basis kann man schlecht Programme machen.
> Daher wurde aus verschiedenen Konvertierungen und unter Einbeziehung der Dokumentation manuell und iterativ das aktuelle Datenbank-Schema 0.7 entwickelt. Kommentare und Indices wurden hinzugefügt.
>
> Aus dem ursprünglichen, von PostNAS selbst erzeugten Schema, waren bis zur Version 0.7 immer noch einige "Relikte" enthalten:
>    1. Die Sortierung nach Tabellen-Namen
>    2. Datenspalten, in denen nur numerische Inhalte gefunden wurden, wurden von PostNAS als Integer-Werte angelegt.
>
> - Zu 1. Sortierung:
> In der Version 0.7 war begonnen worden, die Tabellen innerhalb der Schema-SQL-Datei nach Objektbereich und Objektartengruppe zu ordnen. Dies war aber nicht fertig geworden. Ich habe dieses nun zu Ende geführt: Die Version 0.8 ist nun komplett nach dem ALKIS-Objektartenkatalog sortiert und gegliedert. Dies ist aber nur rein formal und hat keinen Einfluss auf die daraus generierte Datenbank.
> Beim Abgleich mit dem ALKIS-Objektartenkatalog wurden auch die Beschreibungen der Objektarten in die Kommentare der Tabellen übernommen.
> Der Kommentar zur Tabelle ist nun einheitlich so aufgebaut:  '[Objektartengruppe]: ([N]REO|ZUSO) "Objektname" ist [Beschreibung]'.
> Die Kommentare zu Spalten sind (noch) nicht vollständig.
>
> - Zu 2. Numerische Spalten
> Ein Teil dieser Felder war in der Version von NorBIT von "Integer" nach "Character Varying" geändert worden. Um die beiden Versionen anzugleichen wurde das übernommen.
> Der Abgleich mit dem Objektartenkatalog zeigte weitere Felder, die dort als "Character" (Zeichenkette) dokumentiert sind, die aber im Datenbank-Schema bisher als Integer definiert sind. Diese Felder wurden ebenfalls geändert - wenn nicht jetzt, wann dann.
> Betroffen sind hauptsächlich die Schlüsselfelder von Land, Regierungsbezirk, Kreis, Gemeinde usw. in Tabellen zum Thema Flurstück, Flurstückshistorie und Lagebezeichnung.
> Integer macht da keinen Sinn, weil niemand aus einem Gemeindeschlüssel etwas berechnen will. Andererseits gehen im Integer-Format möglicherweise führende Nullen verloren, die in einem Character-String beibehalten werden.
> Auf die Views und Programme hatte diese Änderung erstaunlich wenig Auswirkungen. Da die Änderung in allen Tabellen gleichartig stattfindet ist ein JOIN weiterhin gültig, z.B.:
>      SELECT ...
>      FROM ax_lagebezeichnungmithausnummer l
>      JOIN ax_gemeinde g ON l.kreis=g.kreis AND l.gemeinde=g.gemeinde  ... ;
> Die Spalten "kreis" und "gemeinde" wurden auf beiden Seiten gleichartig von Integer auch Character geändert, daher ändert sich der View nicht.
>
> In den Programmen für Mapbender-Navigation und Buchauskunft kann der Gemeindeschlüssel per Konfiguration als Filterkriterium verwendet werden. Hier muss der Konfigurationswert nun in Hochkomma gesetzt werden:      ...  WHERE gemeinde = '99';
> Beachten sie dies, wenn sie Views verwenden, die Regionalschlüssel mit eigenen Werten filtern.
>
> Der Wegfall von "alkis_beziehungen" im Datenbank-Schema machte eine Überarbeitung fast aller Komponenten notwendig: Views, Navigation (Mapbender) und Buchauskunft.
> Die "Joins", die den Beziehungen der Objekte folgen, mussten angepasst werden. Aktueller Status: Stabil aber noch nicht komplett ausgetestet.
>
> Im Datenbank-Schema von Norbit waren *alle* ALKIS-Beziehungen als Spalten in den Objekttabellen angelegt worden, auch die sogenannte "inverse Relationsrichtung", also Rückverweise. In der Praxis werden diese Spalten von PostNAS (noch) nicht gefüllt.
> Ich habe diese leeren inversen Relationen und ihre Indices daher im Schema auskommentiert. Sie sind nicht benutzbar und verwirren daher. Wenn sie gefüllt wären, wären sie redundant.
>
> Einige der Relationen-Spalten sind Arrays, die gleich auf mehrere gml_id's einer anderen Tabelle verweisen. Dies ist nicht optimal.
> Die angepasste Version des Post-Prozessing (Nachverarbeitung nach dem Konvertieren) braucht für das Füllen der Tabelle "pp_flurstueck_nr" nun mehrere Minuten statt etwa 20 Sek. wie bisher. Die Ursache vermute ich darin, dass die Relation "ap_pto > dientZurDarstellungVon > ax_flurstueck" nun ein Array ist, dass mit der Function ANY() gejoint werden muss. Vielleicht ist das aber nur ein Problem meiner veralteten Datenbank-Version.
>
> Eine weitere "durchschlagende" Anpassung betrifft die Länge des Haupt-Schlüssels "gml_id" in allen Tabellen.
> In der bisherigen Version 0.7 war die Länge auf 16 Zeichen beschränkt. Diese 16 Zeichen enthalten die einheitliche Kennung des Objektes in einem Bestand ohne Historie ("es kann nur einen geben").
>
> In der Norbit-Version ist die Länge nicht limitiert. Bei Aktualisierungen entstehen so Objekte, die nach der Objekt-Kennung noch einen Zeitstempel der Entstehung enthalten. Diese längere Version der "gml_id" ist dann der Objektschlüssel. Für Sekundär-Bestände mit Historie mag dies nützlich sein. Vielleicht ist das sogar für den historischen Trigger unentbehrlich. In meinem Bestreben, zu einem einheitlichen Datenbank-Schema zu kommen, habe ich diese Anpassung also übernommen.
>
> Heute habe ich allerdings bemerkt, dass die Objekt-Verweise aus den Relationen-Spalten den angehängten Zeitstempel nicht enthalten. Die üblichen Equivalenzen können also nicht mehr verwendet werden.
> Beispiel: Die Relation "ax_flurstueck >IstGebucht> ax_buchungsstelle" lautete bisher in SQL:  ".. ON flurstueck.istgebucht = ax_buchungsstelle.gml_id"
> Da "istgebucht" immer nur die kurze ID enthält, aber die gml_id nun auch verlängerte IDs enthalten kann, muss nun bei allen Relationen generell eine Substring-Function verwendet werden: ".. ON flurstueck.istgebucht = substring(ax_buchungsstelle.gml_id,1,16)".
> Diese Änderung an den Programmen habe ich begonnen, ist aber noch nicht vollständig.
>
> Um die Buchauskunft evtl. auch mal auf einer Datenbank "mit Historie" einsetzen zu können, habe ich nun vermehrt "endet IS NULL" in die Where-Klauseln der Abfragen eingebaut. Auch dies ist noch nicht durchgängig und bisher ungetestet. Ich habe keinen Datenbestand mit Historie.
>
> Wenn die beschriebenen Anpassungen durchgängig realisiert wurden, werden die Programme für Buchauskunft und Navigation flexibler sein. Sie sind dann in Datenbanken mit und ohne Historie und mit kurzen oder langen gml_id's einsetzbar.
> Die 0.7er-Versionen funktionierten nur mit 16-Zeichen-gml_id und ohne beendete Objekte.
>
> Den aktuellen Zwischen-Stand habe ich vor 2 Stunden hoch geladen: [3]
>
> Ich bitte um Unterstützung beim Testen der Version 0.8.
>
> Links:
>
> [1] http://trac.wheregroup.com/PostNAS/browser/branches/0.7
>
> [2] http://trac.wheregroup.com/PostNAS/browser/trunk
>
> [3] http://trac.wheregroup.com/PostNAS/changeset/330
>
>
> Mit freundlichen Grüßen
> Frank Jäger
>
> Kommunales Rechenzentrum
> Minden-Ravensberg/Lippe
> Tel.: 05261 / 252 - 185
>
> mailto:f.jaeger at krz.de
> http://www.krz.de/
>
>
> _______________________________________________
> NAS mailing list
> NAS at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/nas

-------------- nächster Teil --------------
Ein Dateianhang mit HTML-Daten wurde abgetrennt...
URL: <http://lists.osgeo.org/pipermail/nas/attachments/20140911/8624b3e8/attachment-0001.html>