[PostNAS] PostNAS 0.8 - Datenbank-Schema

[Frank J.]

Am 15.09.2014 um 14:33 schrieb Jürgen E. Fischer:
> Moin Frank,
>
> On Thu, 11. Sep 2014 at 15:14:28 +0000, Jäger, Frank (KRZ) wrote:
>> Die Relationen-Spalten enthalten aber leider immer nur Verweise auf die
>> kurzen IDs.
>
>> Datenbanktechnisch ist das also eigentlich eine kaputte Relation weil das
>> Feldformat auf beiden Seiten nicht zusammen passt.
>
> Das ist ein Argument.  Die langen Schlüssel haben aber nur unmittelbar bei der
> Fortführung Sinn.  ...
>
> Daher habe ich jetzt alle gml_id und Relation wieder auch character(16)
> gestellt ([1]).  ...
>
> Jürgen


So, es geht weiter mit PostNAS Version 0.8 ...


1.  ... raus ausse Kartoffeln:

Im Datenbankschema des PostNAS-SVN [1] habe ich auch die "gml_id" wieder 
auf "character(16)" zurück geändert. Dabei wird es dann wohl bleiben.

Nebenbei: Für bessere Massen-Edits habe ich nun auf Tab-ausgerichten 
SQL-Code verzichtet und die Tabellen-Definitionen auf das PG-Dump Format 
umgestellt. Das sieht jetzt im Diff des SVN einmal grausam aus.


2. Trigger für Historie:

Bisher habe ich fast ausschließlich die NBA-Abgabeart 1000 (ohne 
Historie) erhalten und das mit der Trigger-Variante "Kill" verarbeitet.

Für eine Stadt liegt mir jedoch Abgabeart 3100 (Vollhistorie) vor, die 
mit dem Kill-Trigger fehlerhaft verarbeitet wird, weil der (noch) gar 
kein "replace" kennt.

Da die Auskunft-Programme, Views und Mapfiles nun mit historischen 
Objekten in der Datenbank umgehen können, spricht nichts dagegen, dazu 
jetzt den Trigger in der Variante "hist" zu verwenden. Mit dem hatte ich 
noch keine Erfahrungen.
Meine Tests ergaben, dass der vorliegende Hist-Trigger, auch die 
frischeste Norbit-Version aus github, mit meinen Daten nicht funktioniert.

Ich habe mich an die Reparatur gemacht. ...
Donnerwetter!  Schweres Gelände.
Ich habe noch nie so viel Hirnschmalz für so wenige Zeilen Code gebraucht.
Das vorläufige Ergebnis habe ich heute Mittag hoch geladen [2].

Der bisherige Trigger-Code geht offensichtlich von der klassischen 
Situation einer Aktualisierung aus. In der Datenbank liegt nur eine alte 
Version des bearbeiteten Objektes mit "ended IS NULL". Das ist die 
bisher gültige Version.
Dann kommt eine NAS-Datei mit EINEM Replace zu dem Objekt, auch "endet 
IS NULL". Das ist die neue aktuelle Version.
Der Trigger wird aufgerufen, nimmt den Beginn der neuen Version und fügt 
das als Ende der alten Version ein.
Die hat nun "NOT endet IS NULL" und wird von den Programmen nicht weiter 
beachtet, sie ist historisch.

Die Aufgabe des Triggers ist es, die alte und neue Version des gleichen 
Objektes in Verbindung zu setzen.
Dass beide Versionen "endet NOT NULL" haben wird dabei vorausgesetzt.

Ich habe aber folgende Situation vorgefunden:
Eine einzige NAS-Datei einer Erstabgabe mit Abgabeart 3100 enthält 
bereits mehrere Versionen eines Objektes. Es wird ja dessen komplette 
Historie mit transportiert.
Die erste Objekt-Version kommt noch mit "insert" und hat - obwohl auch 
schon historisch - noch kein Ende-Datum in den Daten. Insert sieht das 
wohl nicht vor.
Die folgenden Versionen kommen mit "replace" und haben bereits ein 
Ende-Datum, das gleich mit übernommen wird.
Die letzte Version mit "replace" hat kein Ende Datum, das ist die 
aktuellste Version.
Alle Versionen werden zunächst in die Objekt-Tabelle geladen.
Dann läuft PostNAS noch mal durch die Datei und erzeugt dabei die 
Einträge in der Delete-Tabelle, also einen Trigger-Aufruf für jeden 
Replace-Satz.

Dieser Trigger findet nun NICHT genau ein Paar Vorgänger-Nachfolger vor, 
die beide "endet NOT NULL" haben.

Mal hat der Vorgänger "endet IS NULL", der aus dem Insert.
Mal haben beide bereits ein Ende, aus mittlerem "replace".
Mal hat der Nachfolger kein "endet", aber der Vorgänger.

Der alte Trigger nahm den "beginn" der letzten Objekt-Version (NOT NULL) 
um damit das allererste (NOT NULL) zu beenden.
Die mittleren Versionen wurden nicht gefunden und führten zu 
Fehlermeldungen im Logfile.

Ich habe diese  Abläufe, unter denen der Trigger arbeiten soll, als 
Kommentar in der Datei [2] ab Zeile 297 dokumentiert.

Was mich ein wenig wundert: Ich habe von mehren Seiten schon gehört, 
dass Datenbanken mit Historie benutzt werden.
Warum läuft das bei mir schief und andere haben keine Probleme?
Hatte denn noch niemand eine Erstabgabe in der es mindestens 3 Versionen 
eines Objektes gibt?

Die aktuellen NBA-Daten wurden folgendermaßen erzeugt:
Software: ibR
Bundesland : NRW
Die Erstabgabe wurde zurück datiert auf einen Stichtag in 1950 um 
wirklich die ganze Historie zu bekommen.
Die erste automatisch generierte Ausgabe ist entsprechend leer.

Die erste abgerufene Aktualisierung ist dann die eigentliche Erstabgabe, 
die die komplette Lebensgeschichte der Objekte mitbringt.
Dabei kracht es dann  ...

Ich habe noch nicht viel testen können, nur dies eine NBA-Verfahren.
Also los: andere Bundesländer, andere Software, ...

Frank Jäger


[1] 
http://trac.wheregroup.com/PostNAS/export/336/trunk/import/alkis_PostNAS_schema.sql

[2] 
http://trac.wheregroup.com/PostNAS/browser/trunk/import/alkis-functions.sql