[PostNAS] SQL-Abfrage / csv-Datei erzeugen

[Frank]

Am 11.04.2012 16:08, schrieb David.Mau at stadt.mainz.de:
> Hallo PostNAS-Gemeinde,
>
> ich möchte eine csv-Datei mit folgenden Kriterien aus einer PostGIS-DB
> (PostNAS_06-Schema) erzeugen:
>
> 1) Eigentümerbezogene Auswertung (ax_person) mit
> 2) Angaben zum Flurstück (ax_flurstueck)
> 3) Angaben zur Adresse des Eigentümers (ax_anschrift)
> 4) Angaben zum Eigentüner (ax_namensnummer)
> 5) Angaben zum Buchungsblatt (ax_buchungsblatt)
> 6) Angaben zur Buchungstelle (ax_buchungsstelle)
> 7) Angaben zum historischen Flurstück (ax_historischesflurstueck)
> 8) Angaben zum historischen Flurstück-ALB (ax_historischesflurstueckalb)
>
> Die SQL-Abfragen für die Views "flurstuecke_eines_eigentuemers",
> "rechte_eines_eigentuemers" und "adressen_zum_flurstueck" kommen meinen
> Anforderungen schon recht nah.
>
> Kann man das irgendwie zusammenbringen? Über Lösungsansätze von Euch
> würde ich mich sehr freuen.
>
> Vielen Dank für Eure Unterstützung.
>
> Mit freundlichen Grüßen
> i.A.
>
> David Mau

Ja ääähh jein,
natürlich kann man das irgendwie mit ein wenig Fleiß alles in eine 
lineare Struktur quetschen, die dann als cvs-Datei ausgegeben werden kann.
Ich bezweifle aber, dass irgend jemand mit dem Ergebnis etwas anfangen 
kann. Die Frage ist aus meiner Sicht weniger, WIE das geht, sondern 
eher, WARUM man das tun sollte.
Es hat schon seiner Grund, dass ALKIS-Daten als XML (NAS) ausgeliefert 
und dann in eine relationale Datenbank gespeichert werden. Dort werden 
die Relationen (1:N) passend abgebildet.
Durch die Auskunft-Programme werden dann jeweils verbundene Gruppen von 
Tabellen zusammen lesbar angezeigt. Dazu werden z.B. noch zusätzliche 
Schlüsseltabellen hinzugezogen, die in der Frage noch gar nicht erwähnt 
wurden, die aber auch benötigt werden um die Daten zu interpretieren.
Über einen Link geht es dann zur nächsten Gruppe von Tabellen.

Beispiel:
- Ein Format zeigt alles zum Flurstück,
- ein anderes Format zeigt alles zum Grundbuch.
- Ein drittes Format kann die Historie Schritt für Schritt nachverfolgen.

Die Historie muss ja manchmal über mehrere Zwischenschritte analysiert 
werden, z.B. wenn zunächst mehrere Flurstücke verschmolzen wurden um sie 
dann in anderer Geometrie wieder neu zu teilen.

Einige der Beziehungen sind von der Art "1:N", z.B. ein Flurstück kann 
mehrere Buchungen (auf verschiedenen Grundbüchern) haben (Wohnungseigentum).
Natürlich können auch auf einem GB-Blatt mehrere Buchungen (also 
Flurstücke) sein.
Zwischen GB-Blatt und Flurstück ergibt sich somit eine N:N-Beziehung.

Andere Beziehungen sind 1:N wobei N auch 0 sein darf.

Was würde also passieren, wenn wir alles mit einer Equivalenzanfrage 
linearisieren würden?
Es werden Zeilen gebildet. Damit keine Felder leer bleiben, wird bei 1:n 
der 1-Anteil wiederholt. Mal kommt also das Flurstück mehrfach vor, mal 
das Grundbuch.
Gibt es es zum Grundbuch dann noch 10 Eigentümer wird alles noch 10 mal 
wiederholt, jeweils mit verschiedenen Namen in der Zeile.
Auswerten kann man das nicht mehr. Wenn z.B. die Flächensumme gebildet 
werden soll, dürfte die Fläche ja nur einmal vorkommen.

Dann kommt die Historie, die ja auch noch mit drin sein soll:
  Da ist die Tabelle mit sich selbst verknüpft um Schritt für Schritt 
abbilden zu können. Wie viele Generationen sollen maximal möglich sein?
5, 10, 100?
So oft müsste die Spalte wiederholt werden.

Das WIE wird dann noch dadurch erschwert, dass verschiedene Rechtsformen 
über verschiedene Verbindungen laufen.
Erbbaurecht: Recht einer Buchung an einer anderen Buchung.
Dies auch noch mit in die lineare Tabelle?
Bitteschön. Und - noch den Überblick?

Wollen sie wirklich so eine Struktur?
Wenn ja - Wozu?

--

Frank