Datenmodellierung problematisch für Ermittlung von Start- und End-Date von Interessebindungen

[knutwannheden]

Da Interessebindungen mehrheitlich "manuell" recherchiert werden müssen und im Internet oft Details fehlen, sind die bei Lobbywatch verzeichneten Interessebindungen oft nur teilweise erfasst. Z.B. gibt es oft kein Start- und End-Date (entspricht in der Datenbank interessebindung.von und interessebindung.bis). Für Auswertungen, welche sich auf das aktuelle Datum ("heute") ist das meist unproblematisch, da man davon ausgehen kann, dass die Interessebindung "gültig" ist auch wenn Start- und End-Date nicht vorhanden sind.

Anders sieht dies bei historischen Auswertungen aus. Ein Beispiel einer historischer Auswertung wäre, wenn man die zeitliche Entwicklung der Anzahl Interessebindungen einer gegebenen Branche, Partei, Rechtsform oder anderer Teilmenge grafisch darstellen will. Hierbei muss jedes Datum auf der Zeitachse als Referenzdatum verwendet werden und die "aktiven" Interessebindungen müssen jeweils aus diesem Blickwinkel zusammengesucht werden.

Es gibt hierbei mehrere Sachen zu beachten:

• Grundsätzlich sind Interessebindungen nur als solche zu betrachten während der Amtszeit des Parlamentariers (siehe parlamentarier.im_rat_seit und parlamentarier.im_rat_bis in der Datenbank).
  D.h. wenn z.B. eine Interessebindung kein End-Date hat, dann ist dieses implizit durch den Rücktritt des Parlamentariers (also parlamentarier.im_rat_bis) gegeben.
• Beim Start-Date ist die Situation etwas komplizierter. Wenn ein Parlamentarier neu erfasst wird, werden dessen Interessebindungen recherchiert und eingetragen. Bei diesen ist dann oft das Start-Date auch nicht bekannt. Man geht aber davon aus, dass der Parlamentarier alle diese Interessebindungen ins Amt "mit sich mitgebracht" hat, da diese Recherche in der Regel sehr zeitnah geschieht. D.h. diese Interessebindungen haben dann auch implizit den Amtsantritt als Start-Date.
  Diese Interessebindungen der ersten Recherche sind aber in der Datenbank nicht speziell gekennzeichnet. Man kann sie indirekt erkennen, da sie alle das selbe Freigabedatum (in der Datenbank interessebindung.freigabe_datum und dies ist ein Datum mit Zeitstempel) aufweisen, welches logischerweise auch das früheste Freigabedatum für den Parlamentarier ist.
• Wenn nun nachträglich (also nach der ersten Erfassung) zusätzliche Interessebindungen auftauchen, dann ist bei diesen oft auch kein Start-Date bekannt. Es ist zwar gut möglich, dass der Parlamentarier diese bereits bei Amtsantritt hatte, aber für Lobbywatch macht es trotzdem Sinn diese als "neue" Interessebindungen zu betrachten und deshalb wird dann das Freigabedatum als Start-Date verwendet.
• Letztlich muss bei diesen historischen Auswertungen auch beachtet werden, dass die parlamentarier.im_rat_seit und parlamentarier.im_rat_bis in der Datenbank dem ersten und letzten Antsantritt bzw. -austritt entsprechen. Wenn der Parlamentarier während dieser Zeitspanne mal "abgewählt" und dann wieder neu gewählt wurde, dann wird dies in der Datenbank als Ratsunterbruch geführt (siehe parlamentarier.ratsunterbruch_von and parlamentarier.ratsunterbruch_bis). Während diesem Ratsunterbruch gilt dann eine Interessebindung auch nicht als "aktiv".

Mit der aktuellen Datenmodellierung sind historische Auswertungen der Interessebindungen komplex zu implementieren, da es schwierig ist zu ermitteln, welches Start- und End-Date für eine Interessebindung gültig sind relativ zu einem gegebenen Referenzdatum. Wie sich aus den Punkten oben ergibt, kann für eine Interessebindung sogar verschiedene Start- und End-Dates gelten, wenn ein Parlamentarier einen Ratsunterbruch hatte: Bei einem Referenzdatum während der ersten Amtszeit sind Amtsantritt und Beginn des Ratsunterbruchs zu beachten (im_rat_seit und ratsunterbruch_von) und während der zweiten Amtszeit gilt es Ende des Ratsunterbruchs und Rücktritt aus dem Parlament zu beachten (ratsunterbruch_bis und im_rat_bis).

Um solche historische Auswertungen einfacher zu machen, sollten wir uns überlegen das Datenmodell anzupassen oder alternativ vielleicht nur mit Views zu unterstützen. Die möglichen Lösungen können im Rahmen dieser Issue diskutiert werden.

[knutwannheden]

/cc @scito

[scito]

Bei den Interessenbindungen finde ich es gut, wenn wir unterscheiden können, ob eine Interessenbindung "mitgebracht" oder nach dem Amtsantritt gekommen ist. Dies finde ich politisch relevant.

Views finde ich eine sehr gute Idee.
Beim Datenmodell sehe ich gerade nicht, was verbessert werden könnte. Zumal die Eingabemasken von den Tabellen abgeleitet sind.

Der Ratsunterbruch ist eine vereinfachte Modellierung. Es können auch nicht alle Fälle sauber abgebildet werden, z.B. 2 Ratsunterbrüche.

Bei den Views können wir bestimmte Annahmen treffen und dann die Auswertungen über diese Views fahren.

Für alle Tabellen gibt es schon Views. Ich denke dort könnte man bei den Interessenbindungen und Mandanten zusätzliche Felder für Start- und Ende hinzufügen.

@knutwannheden Willst Du eine PR machen?

[knutwannheden]

Ja, ich finde es wäre auch wichtig, dass man "mitgebrachte" und dadurch bereits ab Amtsantritt gültige Interessebindungen klar identifizieren könnte durch ein dediziertes Attribut.

Das Problem mit mehreren Ratsunterbrüchen ging mir auch durch den Kopf, aber habe noch nicht angeschaut, ob es bereits solche Fälle gab. Wenn man die Modellierung aber umstellen würde wie mit der in_kommission Tabelle, könnte man dies sauber lösen und es würde auch die historischen Abfragen vereinfachen, da man dort nicht künstlich Rows splitten muss, sondern gleich mehrere hat. Dies würde dann auch den Ratswechsel Fall sauberer modellieren. Aber natürlich hat es Konsequenzen für die UI Masken.

Ich habe bei mir eine View erstellt, welche sauber "abgegrenzte" Interessebindungen (wie oben beschrieben) liefert und dann Auswertungen vereinfacht. Ich weiss nicht genau wo die aktuellen Views überall eingesetzt werden, aber ich würde dazu tendieren eine separate View anzulegen, da diese auch etwas komplex ist.

[scito]

Ja, ich finde es wäre auch wichtig, dass man "mitgebrachte" und dadurch bereits ab Amtsantritt gültige Interessebindungen klar identifizieren könnte durch ein dediziertes Attribut.

Sollte dieses bei der Recherche von Hand ausgefüllt werden oder sollte man es berechnen?

Ich habe bei mir eine View erstellt, welche sauber "abgegrenzte" Interessebindungen (wie oben beschrieben) liefert und dann Auswertungen vereinfacht. Ich weiss nicht genau wo die aktuellen Views überall eingesetzt werden, aber ich würde dazu tendieren eine separate View anzulegen, da diese auch etwas komplex ist.

Kannst ja mal Deinen Ansatz als PR machen. Ich werde es dann anschauen. Dann können wir beim PR dann diskutieren.

[knutwannheden]

Sollte dieses bei der Recherche von Hand ausgefüllt werden oder sollte man es berechnen?

Eine GENERATED AS Column geht bei MySQL nicht, wenn ich das richtig verstehe. Ich hätte vorgeschlagen, dass man eine Column hinzufügt, welche dann vom System gesetzt wird bei der Freigabe.

[scito]

GENERATED AS Column gibt es in MySQL. Ich habe diese für Indexe mit NULL-Values gebraucht.
Aber vielleicht gibt eine Spalte, welche mit Triggern ausgefüllt wird mehr Möglichkeiten.
Allenfalls könnte man es auch über eine View lösen. Dieser Ansatz verlangt aber gewisse Garantien, so dass z.B. das Freigabedatum nicht verändert wird.

Wir müssen mal die genauen Kriterien festlegen. Auch würde es sich lohnen mal mit Thomas und Otto zu reden, was sie dazu meinen.

[knutwannheden]

Kannst ja mal Deinen Ansatz als PR machen. Ich werde es dann anschauen. Dann können wir beim PR dann diskutieren.

Ich habe mal einen PR erstellt (#19) mit der View drin. Ich habe nun erst mal keine Rücksicht auf den Code Style genommen, damit wir das Ganze zuerst inhaltlich diskutieren können. (Ich glaube das Ding funktioniert so sowieso nicht unter MySQL 5.7 aufgrund der Lateral Derived Table, aber da würde sich bestimmt eine Alternative finden lassen.)

Was hältst du von der Idee die Modellierung der "Amtszeit" mit einer zusätzlichen Tabelle abzubilden (ähnlich in_kommission)? Ich denke dagegen spricht vermutlich vor allem der Aufwand (kann ich nicht abschätzen, da ich den Code bisher nicht wirklich angeschaut habe) und die Veränderungen in den UI-Masken. Rein von der Modellierung her sehe ich nur Vorteile.