[PostNAS] PostNAS 0.8 - Datenbank-Schema

[Jäger, Frank (KRZ)]

Hallo,
ich fasse mal den aktuellen Stand zusammen:

Die von mir gemachten Programme (Mapbender-Navigation, Buchauskunft) arbeiteten bis Version 0.7 nur in der Umgebung:
- gml_id fix 16
- Datenbank enthält nur aktuelle Objekte (Abgabeart 1000, Trigger "kill). 

Nach Anpassung des Datenbankschemas der Version 0.8 an die Norbit-Version habe ich auch diese Programm überarbeitet. 
Sie sind nun flexibler und arbeiten *auch* in folgendem Umfeld:
1. gml_id varschar (mit teilweise angehängten Timestamps)
2. die Datenbank darf auch historische Objekte enthalten

Zu 1:
Die Felder werden bei Bedarf auf 16 Stellen gekürzt. Theoretisch (ich habe es noch nicht getestet) könnten also auch wieder die fix-16-Felder eingeführt werden. Es sind dann zwar einige Funktionen in den Programmen und Views sinnlos aber nicht schädlich.

Zu 2.
Die historischen Objekte werden jetzt konsequent mit "endet IS NULL" heraus gefiltert.
D.h. man hat keinen Zugriff auf die Objekt-Historie (nicht verwechseln mit Flurstücks-Historie!) und kann diese noch nicht nutzen.
Die historischen Objekte führen aber nicht mehr zu einer falschen Auskunft wie es vorher war. Da standen dann z.B. alte und neue Eigentümer in einer Grundbuch-Auskunft wenn die Namensnummern nur ein Ende-Datum bekommen hatten, aber noch in der Datenbank waren.

Gestern Abend habe ich den letzten Stand der Programme, der auch hier bereits produktiv genutzt wird, ins SVN hochgeladen.
Das Mapfile für den WMS enthält noch keine Filter für historische Objekte und muss noch angepasst werden.  


Was man nun als nächstes tun könnte:

Die beiden Trigger zusammen führen, die derzeit über Einträge in die Delete-Tabelle die Fortführung der Objekt-Tabellen erledigen.
Der Historie-Trigger beherrscht alle Funktionen (delete, replace, update) und ist somit für alle Abgabearten des NBA-Verfahrens brauchbar.
Der Kill-Trigger kann nur die Abgabeart 1000 verarbeiten. Im Gegensatz zu Hist setzt er Objekte nicht auf "endet" sondern löscht sie gleich ganz aus der Datenbank, daher der Name.

Die Verarbeitung der Abgabeart 1000 mit dem Historie-Trigger erzeugt eine Datenbank, die eine "unvollständige Historie" enthält, immer nur die Stände von einem zum nächsten Abgabezeitpunkt, die Zwischenzustände fehlen. 
Die Programme können nun diese Inhalte ausblenden. Mit der Funktion "alkis_delete_all_endet()" kann diese unvollständige Historie entfernt werden.
Mit Aufruf dieser Funktion nach einer Aktualisierung mit dem Historie-Trigger erzielt man also das gleiche Ergebnis wie mit dem Kill-Trigger. Dieser wird also entbehrlich.

Ohne die Notwendigkeit über einen Symlink eine der beiden Versionen in neuen Datenbanken zu installieren, ist eine Stolperfalle für Einsteiger abgebaut. Es ist na nicht ganz leicht zu verstehen, was die einzelnen Abgabearten und Trigger so machen. Wenn man eine Abgabeart "3100 fallbezogen (mit Historie)" in eine Datenbank konvertiert, die mit dem Symlink auf das Kill-Trigger-Script angelegt wurde, dann kommt Mist raus. Welcher NAS-Neuling soll das begreifen? Keep it Simple!
Die Kombi Hist-Trigger + (bei Bedarf) delete-Function erscheint mir sicherer im Betrieb.

Das Schema kann auf "gml_id character(16)" zurück gebaut werden. Die Indices auf Substring sollten aus formalen Gründen zunächst drin bleiben, weil die Programme und Views bis auf weiteres so zugreifen.

In den DATA-Statements der Mapfiles sollte man ebenfalls auf "endet IS NULL" filtern wenn Objekttabellen direkt verwendet werden.
Wenn Views oder Tabellen des Post-Prozessing (pp_*) verwendet werden, kann der Filter an anderer Stelle angewendet werden.


Meinungen?


MfG
F. Jäger


> -----Ursprüngliche Nachricht-----
> Von: nas-bounces at lists.osgeo.org [mailto:nas-bounces at lists.osgeo.org] Im
> Auftrag von Jürgen E. Fischer
> Gesendet: Montag, 15. September 2014 18:31
> An: NAS Schnittstelle via ogr2ogr
> Betreff: Re: [PostNAS] PostNAS 0.8 - Datenbank-Schema
> 
> Moin Frank,
> 
> On Mon, 15. Sep 2014 at 14:06:02 +0000, Jäger, Frank (KRZ) wrote:
> > Ursprünglich waren die "gml_id" in unserem Schema im PostNAS-SVN
> > http://trac.wheregroup.com/PostNAS/browser/trunk  bis zur Version 0.7
> > alle Fix 16.  In der Norbit-Version
> > https://github.com/norBIT/alkisimport waren die gml_id dann alle auf
> > varchar geändert worden. Ich bin davon ausgegangen, dass diese
> > Änderung für die sichere Fortführung mit dem Historie-Trigger (z.B. für die
> Update-Funktion) zwingend benötigt wird.
> 
> Ich auch - meine Annahme, dass die langen Schlüssel überall notwendig wären,
> war nur schlicht und ergreifend falsch.
> 
> Anscheinend gibt es die nur, damit man bei Fortführungen einen gewissen
> Schutz dagegen hat, dass Fortführungen in Datenbanken eingespielt werden zu
> denen sie eigentlich nicht passen.  Mit dem Timestamp kann nämlich geprüft
> werden, ob es genau die Version, die fortgeführt werden soll auch in der
> Datenbank gibt.  Zu mehr braucht man sie nicht und die langen Schlüssel
> dürfen auch gar nicht in die Datenbank.
> 
> Das habe ich allerdings erst festgestellt, nachdem Du die kaputten Relation
> erwähnt hast.
> 
> > Die Inhalte der gml_id als Hauptindex jeder Tabelle waren dann
> > manchmal mit und manchmal ohne Zeitstempel hinter der 16stelligen
> > Basis-ID.  Die Verweise aus Relationen aus anderen Tabellen aber immer nur
> 16stellig.
> 
> Das war mir nicht aufgefallen.  Wir haben allerdings auch kaum Fortführungen
> 
> Allerdings wird bei mir auch nirgends (außer im Löschtrigger vielleicht) auf 16-
> Zeichen abgeschnitten.  Wäre ich darauf gestoßen, dass das notwendig ist,
> wäre das für mich ein Hinweis gewesen, das ganze nochmal zu überprüfen.
> 
> 
> > Auf Dauer halte ich es für sinnvoll in den beiden divergierenden
> > Entwicklungszweigen zumindest ein einheitliches Datenbankschema zu haben.
> 
> Natürlich.  Deswegen habe ich die verbleibenden Unterschiede ja auch
> aufgelistet.
> 
> Ich habe übrigens auch die Funktion alkis_update_schema() aufgebohrt, damit
> Sie die Änderungen nachgezogen werden.  Vielleicht hilft das ja einwenig...
> 
> 
> Jürgen
> 
> --
> Jürgen E. Fischer           norBIT GmbH             Tel. +49-4931-918175-31
-------------- 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/20140916/0fe0e878/attachment.bin>