DWB ─ GUC

Es findet sich in den verlinkten Dokumenten die gesamte Dokumentation zum Datenmodell der DWB (34 Tabellen). Es ist jedoch für das LfU/die GUC nicht möglich, die komplette Datenbank der DWB mitsamt Codeplänen und Verwaltungstabellen parallel zur zentralen ASK-/Artendatenbank nachzubilden. Das LfU/die GUC wollen eigentlich nur die reinen Beobachtungsdaten mit zur ASK kompatiblen Codeplaneinträgen in die zentrale ASK-/Artendatenbank übernehmen. Es werden also nur die Daten zu den Fundorten und die Daten zu den einzelnen Artnachweisen in einem vereinfachten Auswerteformat benötigt.

Es muss ein Weg gefunden werden, wie die Daten aus der DWB in ein ASK-kompatibles Format gebracht werden. Eine direkte Datenübernahme ohne den Umweg über ein vereinfachtes Datenübernahmeformat dürfte hierbei nicht zielführend sein, da ja dann jede Strukturänderung auf Seiten der DWB oder auf Seiten der ASK sofort wieder die Übernahme behindern würde. Benötigt wird ein relativ flaches Austauschformat mit wenigen Tabellen und nur mit den Fachdaten ohne interne Verwaltungsdaten und Codeplänen. Dies müsste ja bei der DWB auch vorgesehen sein, da sonst eine dezentrale Auswertung mit einem GIS-System (z.B. ArcGIS) praktisch unmöglich wäre, da hier vielen Nutzern schon mehr als zwei verknüpfte Tabellen Probleme bei Auswertungen bereiten.

Daher wird als dauerhafte Lösung wahrscheinlich gemeinsam ein vereinfachtes fachliches Austauschformat definiert werden müssen, in welches von der DWB die reinen Fachdaten exportiert werden und dann auf Seiten von FIS-Natur wieder importiert werden können. Dieses „fachliche“ Austauschformat ist dabei zuerst einmal vom technischen Format völlig unabhängig, also ob csv-Dateien, DB-Dumps, DBase- oder ein XML-Format verwendet werden. Für ein allgemein definiertes Austauschformat zwischen Behörden wäre wahrscheinlich ein XML-Schema verpflichtend, aber wenn die Schnittstelle nur bilateral zwischen den beiden Einzelsystemen definiert wird, könnte auch ein komprimierteres Format wie csv verwendet werden. Hierbei wäre aber für das LfU/die GUC wichtig, dass alle Datensätze möglichst schon in Ihrer Datenbank eine eindeutige und sich nicht mehr ändernde ID bekommen haben und zudem jeder Datensatz ein Attribut auf die Herkunft (z.B. Biotopkartierung) besitzt. Nur dadurch können bei wiederholten Datenübernahmen bereits vorhandene Datensätze zugeordnet und beispielsweise die Daten der Biotopkartierung unterdrückt werden, da diese Daten gleich direkt aus der Biotopkartierung importiert werden.

Da es sich bei dem aktuell zur Verfügung gestellten Datenbestand nur um einen Teilbestand zum Testen der Datenübernahme handelt, würde ich hier folgendes Vorgehen vorschlagen:

1. Wir stellen Ihnen eine Definition für zwei Tabellen (Fundortangaben, Artbeobachtungen an diesen Fundorten) zur Verfügung, welche von den Feldern weitgehend kompatibel zur ASK ist.

2. Bei Ihnen werden mittels zweier SQL-Exportkommandos aus den entsprechenden Feldern in Ihren Tabellen diese Inhalte gemäß unserer Definition in zwei csv-Dateien ausgegeben. Dies dürfte unproblematisch sein, da bei Ihnen ja jetzt schon csv-Dateien exportiert werden können und Sie daher lediglich die Felder in der richtigen Reihenfolge rausschreiben müssen. Manche wenige Felder, die in der ASK in einer zusätzlichen Relation angelegt sind, aber in der Regel nur in zwei oder drei Ausprägungen vorkommen dürfen, würden wir einfach in der flachen Austauschstruktur als zwei oder drei hintereinander folgende Felder definieren.

3. Dies zwei csv-Dateien versuchen wir anschließend bei uns in eine Testdatenbank einzuspielen. Damit dies gelingt, dürften Sie aber für Felder, wofür in der ASK-Codepläne hinterlegt sind, auch nur gültige Codes ausspielen. Ansonsten würde die Einspielung dieser Datensätze bei uns scheitern. Falls damit wertvolle Datensätze entfallen würden, müssten wir abklären, ob anstelle einer vorhergehenden Codeplanabstimmung bei diesen Feldern auch nur Langtexte ohne Codes übernommen werden können. Sind die Codepläne des LfUs für bestimmte Felder verwendet worden – Fr. Socher hat sie zumindest mal für Herrn Ahlmer bereitgestellt?

Dieses Vorgehen dürfte relativ schnell und einfach auf beiden Seiten umgesetzt werden können.

Weiterhin wäre damit auch schon der Weg bereitet für einen dauerhaften Datenaustausch, da beide Seiten dann unabhängig von der jeweiligen eigenen Datenstruktur nur weiterhin dieses Austauschformat bedienen müssen. Eventuell muss das Format bei einigen nicht direkt kompatiblen Feldinhalten oder falls doch noch eine weitere Relation erforderlich wird, noch nachgebessert werden.

Lediglich bei wirklich gravierenden Neustrukturierungen in den Datenbanken wäre dann vielleicht eine Anpassung des Austauschformates nötig. Falls nur ein paar neue Felder hinzukommen, können diese relativ einfach nach gegenseitiger Abstimmung an das Ende der csv-Datensätze angehängt werden.