DWB ─ GUC - Revision history

Leininger at 12:35, 17 December 2014

2014-12-17T12:35:03Z

Leininger at 11:52, 17 December 2014

2014-12-17T11:52:16Z

Leininger at 11:41, 17 December 2014

2014-12-17T11:41:24Z

Leininger: Created page with '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 Dat…'

2014-12-17T11:38:52Z

Created page with '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 Dat…'

New page

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.

Also muss jetzt 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 werden wir als dauerhafte Lösung wahrscheinlich gemeinsam ein vereinfachtes fachliches Austauschformat definieren 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 uns 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 wir bei wiederholten Datenübernahmen bereits vorhandene Datensätze zuordnen und beispielsweise die Daten der Biotopkartierung unterdrücken, da wir diese Daten gleich direkt aus der Biotopkartierung importieren.

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.

@@ Line 12: / Line 12: @@
 Da es sich bei dem aktuell zur Verfügung gestellten Datenbestand nur um einen Teilbestand zum Testen der Datenübernahme handelt, wird folgendes Vorgehen vorschlagen:
+<br><br>
-# Das LfU/die GUC 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.
+#Das LfU/die GUC 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.<br><br>
+#In der DWB werden mittels zweier SQL-Exportkommandos aus den entsprechenden Feldern in der Tabellen diese Inhalte gemäß der Definition in zwei csv-Dateien ausgegeben. Dies dürfte unproblematisch sein, da in der DWB jetzt schon csv-Dateien exportiert werden können und daher lediglich die Felder in der richtigen Reihenfolge rausgeschrieben werden 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 einfach in der flachen Austauschstruktur als zwei oder drei hintereinander folgende Felder definiert werden.<br><br>
-# In der DWB werden mittels zweier SQL-Exportkommandos aus den entsprechenden Feldern in der Tabellen diese Inhalte gemäß der Definition in zwei csv-Dateien ausgegeben. Dies dürfte unproblematisch sein, da in der DWB jetzt schon csv-Dateien exportiert werden können und daher lediglich die Felder in der richtigen Reihenfolge rausgeschrieben werden 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 einfach in der flachen Austauschstruktur als zwei oder drei hintereinander folgende Felder definiert werden.
+#Es wird versucht dies zwei csv-Dateien anschließend bei uns in eine Testdatenbank einzuspielen. Damit dies gelingt, dürfte die DWB 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 LfU/GUC 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.<br/>
+<br>
 Sind die Codepläne des LfU für bestimmte Felder verwendet worden – Fr. Socher hat sie zumindest mal für Herrn Ahlmer bereitgestellt?

← Older revision		Revision as of 11:41, 17 December 2014
Line 3:		Line 3:


−	~~Also~~ muss ~~jetzt~~ 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.	+	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 ~~werden wir~~ als dauerhafte Lösung wahrscheinlich gemeinsam ein vereinfachtes fachliches Austauschformat ~~definieren~~ 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 ~~uns~~ 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 ~~wir~~ bei wiederholten Datenübernahmen bereits vorhandene Datensätze ~~zuordnen~~ und beispielsweise die Daten der Biotopkartierung ~~unterdrücken~~, da ~~wir~~ diese Daten gleich direkt aus der Biotopkartierung ~~importieren~~.	+	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.

@@ Line 11: / Line 11: @@
-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:
+Da es sich bei dem aktuell zur Verfügung gestellten Datenbestand nur um einen Teilbestand zum Testen der Datenübernahme handelt, wird folgendes Vorgehen vorschlagen:
-.       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.
+# Das LfU/die GUC 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.
-.       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.
+# In der DWB werden mittels zweier SQL-Exportkommandos aus den entsprechenden Feldern in der Tabellen diese Inhalte gemäß der Definition in zwei csv-Dateien ausgegeben. Dies dürfte unproblematisch sein, da in der DWB jetzt schon csv-Dateien exportiert werden können und daher lediglich die Felder in der richtigen Reihenfolge rausgeschrieben werden 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 einfach in der flachen Austauschstruktur als zwei oder drei hintereinander folgende Felder definiert werden.
-.       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?
+# Es wird versucht dies zwei csv-Dateien anschließend bei uns in eine Testdatenbank einzuspielen. Damit dies gelingt, dürfte die DWB 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 LfU/GUC 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.<br/>
 Dieses Vorgehen dürfte relativ schnell und einfach auf beiden Seiten umgesetzt werden können.
@@ Line 26: / Line 26: @@
 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.