Universität des Saarlandes Fachrichtung 6.2 Informatik

Datenbereinigung und Datenintegration im Umweltsektor

Diplomarbeit Angefertigt unter der Leitung von: Herrn Prof. Dr.-Ing. Gerhard Weikum (Betreuer) Max-Planck Institut für Informatik und Herrn Prof. Dr. Horst P. Beck (Kobetreuer) Institut für Anorganische und Analytische Chemie und Radiochemie

Vorgelegt von: Andreas Martin April 2005

An dieser Stelle möchte ich mich ganz herzlich bei den Mitarbeitern des Instituts für Anorganische und Analytische Chemie bedanken, die mir bei der fachlichen Konzeption und der Erstellung der Arbeit behilflich waren. Für ihre Unterstützung danke ich weiterhin meinem wissenschaftlichen Betreuer Prof. Gerhard Weikum und Kobetreuer Prof. Horst Beck, meiner Familie und meiner Verlobten Nicole.

Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbst und nur unter der Verwendung der im Literaturverzeichnis angegebenen Quellen erstellt habe.

Saarbrücken, im April 2005

Inhaltsverzeichnis

1 Einführung 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Beitrag der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Analyse und Systemspezifikation 2.1 Grundlagen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Fachliches Umfeld . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2 Datenbanksysteme . . . . . . . . . . . . . . . . . . . . . . . . 2.1.3 Relationales Datenmodell . . . . . . . . . . . . . . . . . . . . 2.1.4 Data Warehouse, Data Cleaning und Data Mining . . . . . . 2.2 Ziele und Rahmenbedingungen . . . . . . . . . . . . . . . . . . . . . 2.3 Nachbarsysteme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Importquellen . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.1.1 Datenloggerwerte aus den Containern . . . . . . . . 2.3.1.2 Lokal ausgelesene Daten . . . . . . . . . . . . . . . . 2.3.1.3 Labordaten . . . . . . . . . . . . . . . . . . . . . . . 2.3.2 Externe Daten . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.2.1 Umweltministerium . . . . . . . . . . . . . . . . . . 2.3.2.2 Daten der französischen Partner . . . . . . . . . . . 2.3.3 Kontrollereignisse . . . . . . . . . . . . . . . . . . . . . . . . . 2.3.3.1 Ereignisliste der einzelnen Sensoren . . . . . . . . . 2.3.3.2 Manuell verursachte Ereignisse . . . . . . . . . . . . 2.3.3.3 Binäre Ereignisse aus dem Datenlogger . . . . . . . 2.3.4 Exportmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . 2.3.5 Webschnittstelle . . . . . . . . . . . . . . . . . . . . . . . . . 2.4 Statische Analyse - Datenmodell . . . . . . . . . . . . . . . . . . . . 2.4.1 Containerdefinition . . . . . . . . . . . . . . . . . . . . . . . . 2.4.2 Korrelationen und Bewertung . . . . . . . . . . . . . . . . . . 2.4.2.1 Bewertung eines einzelnen Sensorwertes . . . . . . . 2.4.2.2 Bewertung von Sensorwerten untereinander . . . . . 2.4.2.3 Bewertung durch Korrelation zwischen den Sensoren 2.4.2.4 Bewertung durch Vergleichsanalysen . . . . . . . . . 2.4.2.5 Bewertung durch Ereignisse . . . . . . . . . . . . . . 2.4.3 Allgemeines . . . . . . . . . . . . . . . . . . . . . . . . . . . .

i

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1 1 2 2 3 3 3 5 6 8 9 10 10 10 11 12 12 12 12 12 13 13 14 14 14 15 15 17 17 18 18 19 19 19

Inhaltsverzeichnis

2.5

2.4.4 Messwerte und ihre Historie . . . . . . . . . . . . . . . . . 2.4.5 Importvorgänge . . . . . . . . . . . . . . . . . . . . . . . . 2.4.6 Ereignisse . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.7 Benutzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.8 Visualisierung . . . . . . . . . . . . . . . . . . . . . . . . . 2.4.9 Rechtestruktur . . . . . . . . . . . . . . . . . . . . . . . . 2.4.10 Externe Darstellung . . . . . . . . . . . . . . . . . . . . . Dynamische Analyse - Prozesse . . . . . . . . . . . . . . . . . . . 2.5.1 Definition von Containern und ihren Sensoren . . . . . . . 2.5.2 Datenimport . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.2.1 Automatisierter Import . . . . . . . . . . . . . . 2.5.2.2 Manueller Import . . . . . . . . . . . . . . . . . 2.5.2.3 Manuelle Eingaben . . . . . . . . . . . . . . . . . 2.5.3 Datenexport . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5.3.1 Externe Datei . . . . . . . . . . . . . . . . . . . 2.5.3.2 Präsentation im WWW . . . . . . . . . . . . . . 2.5.4 Bewertungs- und Änderungsmöglichkeiten von Messwerten 2.5.5 Benutzer- und Rechteverwaltung . . . . . . . . . . . . . .

3 Systemkonstruktion - Technische Konstruktion 3.1 Schichtenmodell . . . . . . . . . . . . . . . . 3.2 Datenhaltungsschicht . . . . . . . . . . . . . 3.3 Datenhaltungszugriffsschicht . . . . . . . . . 3.3.1 XML Mapping . . . . . . . . . . . . 3.3.2 Abfragen . . . . . . . . . . . . . . . 3.3.3 Transaktionen . . . . . . . . . . . . . 3.3.4 Hibernate Synchronizer . . . . . . . 3.4 Fachkonzeptschicht . . . . . . . . . . . . . . 3.5 Präsentationsschicht . . . . . . . . . . . . . 3.5.1 SWT . . . . . . . . . . . . . . . . . . 3.5.2 JFace . . . . . . . . . . . . . . . . . 3.5.3 Forms API . . . . . . . . . . . . . . 3.5.4 Draw2d . . . . . . . . . . . . . . . . 3.6 Hilfsklassen . . . . . . . . . . . . . . . . . . 3.6.1 Mehrsprachigkeit . . . . . . . . . . . 3.6.2 Rechtehandling . . . . . . . . . . . . 3.6.3 Filterklassen . . . . . . . . . . . . . 3.6.4 Logging . . . . . . . . . . . . . . . . 3.6.5 Sonstige Hilfsklassen . . . . . . . . . 3.6.6 Test und Evaluierung der Software . 3.7 Webschnittstelle . . . . . . . . . . . . . . .

ii

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . .

19 21 21 23 23 23 25 26 26 26 28 28 28 28 28 28 28 31

. . . . . . . . . . . . . . . . . . . . .

32 32 33 34 35 37 38 39 42 42 42 43 44 44 44 44 45 45 45 45 45 47

Inhaltsverzeichnis

4 Systemkonstruktion - Anwendungskonstruktion 4.1 Login . . . . . . . . . . . . . . . . . . . . . 4.2 Karteireiter Container und Sensoren . . . . 4.2.1 Container . . . . . . . . . . . . . . . 4.2.2 Sensoren . . . . . . . . . . . . . . . . 4.2.3 Ausprägungen . . . . . . . . . . . . . 4.3 Karteireiter Sichten . . . . . . . . . . . . . . 4.4 Karteireiter Bewertung und Visualisierung . 4.5 Karteireiter Import . . . . . . . . . . . . . . 4.6 Karteireiter Ereignisse . . . . . . . . . . . . 4.7 Karteireiter Meldungen . . . . . . . . . . . . 4.8 Karteireiter Benutzer . . . . . . . . . . . . . 4.9 Karteireiter Administration . . . . . . . . . 4.10 Karteireiter Externe Datentabelle . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

. . . . . . . . . . . . .

48 48 49 50 50 51 51 52 53 54 54 55 55 55

5 Zusammenfassung und Ausblick 58 5.1 Zusammenfassung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 5.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Literaturverzeichnis

59

A Anhang A.1 Systemvoraussetzungen . . . . A.2 Installation . . . . . . . . . . A.3 Datenbankkonfiguration . . . A.4 Datensicherung und Wartung

63 63 63 64 64

. . . .

. . . .

. . . .

. . . .

. . . .

iii

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

Abkürzungsverzeichnis Admin . . . . . . . . . . . . . . . AMD . . . . . . . . . . . . . . . . API . . . . . . . . . . . . . . . . . . Aufl. . . . . . . . . . . . . . . . . . Ausp. . . . . . . . . . . . . . . . . Bewert. . . . . . . . . . . . . . . bzw. . . . . . . . . . . . . . . . . . ca. . . . . . . . . . . . . . . . . . . . CPU . . . . . . . . . . . . . . . . . CSV . . . . . . . . . . . . . . . . . DAO . . . . . . . . . . . . . . . . . DBMS . . . . . . . . . . . . . . . DBS . . . . . . . . . . . . . . . . . DV . . . . . . . . . . . . . . . . . . . edit. . . . . . . . . . . . . . . . . . EPK . . . . . . . . . . . . . . . . . Ereig. . . . . . . . . . . . . . . . . ERM . . . . . . . . . . . . . . . . . et al. . . . . . . . . . . . . . . . . . etc. . . . . . . . . . . . . . . . . . . EU . . . . . . . . . . . . . . . . . . . f. . . . . . . . . . . . . . . . . . . . . . FK . . . . . . . . . . . . . . . . . . . Gb . . . . . . . . . . . . . . . . . . . Ghz . . . . . . . . . . . . . . . . . . GIS . . . . . . . . . . . . . . . . . . GSM . . . . . . . . . . . . . . . . . GTK . . . . . . . . . . . . . . . . . GUI . . . . . . . . . . . . . . . . . . Hrsg. . . . . . . . . . . . . . . . . . HTML . . . . . . . . . . . . . . . IDE . . . . . . . . . . . . . . . . . . IT . . . . . . . . . . . . . . . . . . . JDBC . . . . . . . . . . . . . . . . LFU . . . . . . . . . . . . . . . . .

Administrator Advanced Micro Devices Application Programming Interface Auflage Ausprägung Bewertungen beziehungsweise circa Central Processing Unit Character Separated Values Data Access Object Datenbank-Management-System Datenbanksystem Datenverarbeitung editieren Ereignisgesteuerte Prozesskette Ereignisse Entity Relationship Model und andere et cetera Europäische Union folgende Foreign Key Gigabyte Gigahertz Geoinformationssystem Global System for Mobile Communications GIMP-Toolkit Graphical User Interface Herausgeber Hypertext Markup Language Integrated Development Environment Informationstechnologie Java Database Connectivity Landesamt für Umweltschutz

iv

Abkürzungsverzeichnis

max . . . . . . . . . . . . . . . . . . Mb . . . . . . . . . . . . . . . . . . . min . . . . . . . . . . . . . . . . . . MVC . . . . . . . . . . . . . . . . . NH4 . . . . . . . . . . . . . . . . . NO3 . . . . . . . . . . . . . . . . . organisator. . . . . . . . . . . PC . . . . . . . . . . . . . . . . . . . PDF . . . . . . . . . . . . . . . . . PK . . . . . . . . . . . . . . . . . . . PLQ . . . . . . . . . . . . . . . . . PO4 . . . . . . . . . . . . . . . . . QBC . . . . . . . . . . . . . . . . . RAM . . . . . . . . . . . . . . . . rd. . . . . . . . . . . . . . . . . . . . S. . . . . . . . . . . . . . . . . . . . . s.o. . . . . . . . . . . . . . . . . . . . SAAR-LOR-LUX . . . . SAK . . . . . . . . . . . . . . . . . SQL . . . . . . . . . . . . . . . . . SVG . . . . . . . . . . . . . . . . . SWT . . . . . . . . . . . . . . . . . techn. . . . . . . . . . . . . . . . . TOC . . . . . . . . . . . . . . . . . u.a. . . . . . . . . . . . . . . . . . . u.U. . . . . . . . . . . . . . . . . . . u.ä. . . . . . . . . . . . . . . . . . . UIS . . . . . . . . . . . . . . . . . . UML . . . . . . . . . . . . . . . . . usw. . . . . . . . . . . . . . . . . . v.a. . . . . . . . . . . . . . . . . . . vgl. . . . . . . . . . . . . . . . . . . www . . . . . . . . . . . . . . . . . XML . . . . . . . . . . . . . . . . . z.B. . . . . . . . . . . . . . . . . . . z.T. . . . . . . . . . . . . . . . . . . zw. . . . . . . . . . . . . . . . . . . .

Maximum Megabyte Minimum Model-View-Controller Ammonium Nitrat organisatorische Personal Computer Portable Document Format Primary Key Pluviométrie - Limnimétrie - Qualité des eaux Ortho-Phospat Query by criteria Random Access Memory rund Seite siehe oben Saarland-Lothringen-Luxemburg Spektraler Absorptionskoeffizient Structured Query Language Scalable Vector Graphics Standard Widget Toolkit technische Total Organic Carbon und andere unter Umständen und ähnliche Umweltinformationssystem Unified Modeling Language und so weiter vor allem vergleiche World Wide Web Extensible Markup Language zum Beispiel zum Teil zwischen

v

Abbildungsverzeichnis

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

Aussenansicht und Innenansicht des Containers Niedaltdorf . . Beispiel Relation - Tabelle (Quelle Cordts, 2002, S. 72) . . . . Beispiel Verknüpfung von Tabellen (Quelle Cordts, 2002, S. Darstellung) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Beispielauszug für eine übertragene Datei aus dem Datenlogger Beispielauszug für eine vor Ort ausgelesene Sensordatei . . . . . Beispielauszug für eine Liste mit Niederschlagsdaten . . . . . . Beispielauszug für eine Ereignisliste . . . . . . . . . . . . . . . . Allgemeines ERM . . . . . . . . . . . . . . . . . . . . . . . . . . ERM Container und Sensoren . . . . . . . . . . . . . . . . . . . ERM Sensoren und Korrelationen . . . . . . . . . . . . . . . . . ERM Messwerte und Historie . . . . . . . . . . . . . . . . . . . ERM Importe und Importlog . . . . . . . . . . . . . . . . . . . ERM Ereignisse und Ereignistypen . . . . . . . . . . . . . . . . ERM Benutzer und Partner . . . . . . . . . . . . . . . . . . . . ERM Ansichten . . . . . . . . . . . . . . . . . . . . . . . . . . . ERM Rechtestruktur . . . . . . . . . . . . . . . . . . . . . . . . ERM Externe Datentabelle . . . . . . . . . . . . . . . . . . . . EPK Automatischer Import . . . . . . . . . . . . . . . . . . . . EPK Manueller Import . . . . . . . . . . . . . . . . . . . . . . . EPK Automatische Bewertung . . . . . . . . . . . . . . . . . .

. . . . 71, . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21 22 23 24 25 26 27 28 29 30 31

Mehr-Schichten-Architektur . . . . . . . . . . . . . . . . . . . . Klasse Container, Containerinstanzen und Tabelle Container . Beispielauszug für eine XML Mappingdatei . . . . . . . . . . . Beispielauszug aus der Container- und Sensor-Mappingdatei zur Beispielauszug zur Definition eines HQL Ausdrucks . . . . . . . Beispielauszug zur Benutzung eines Criteria Objekts . . . . . . Ablauf einer Transaktion (Quelle Bauer, King, 2004) . . . . . Beispielauszug zur Nutzung der Transaction API . . . . . . . . Hibernate Synchronizer - erzeugte Klassen . . . . . . . . . . . . Model-View-Controler Architektur . . . . . . . . . . . . . . . . Importfilter-Interface . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . Assoziation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

Login Dialog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

vi

. . . . . . . . . . . . . . geänderte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

4 6 7 10 11 13 14 15 16 18 20 21 22 23 24 25 26 27 29 30 33 35 36 37 38 38 39 40 41 43 46

Abbildungsverzeichnis

33 34 35 36 37 38 39 40 41 42 43

Containerdetails . . . . . . . . . . . . . . Sensordetails . . . . . . . . . . . . . . . . Ausprägungdetails . . . . . . . . . . . . . Karteireiter Sichten . . . . . . . . . . . . . Karteireiter Bewertung und Visualisierung Karteireiter Import . . . . . . . . . . . . . Karteireiter Ereignisse . . . . . . . . . . . Karteireiter Meldungen . . . . . . . . . . . Karteireiter Benutzer . . . . . . . . . . . . Karteireiter Administration . . . . . . . . Karteireiter Externe Datentabelle . . . . .

vii

. . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

49 50 51 52 53 54 55 56 56 57 57

Tabellenverzeichnis

1

Rechtematrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

viii

1 Einführung 1.1 Motivation Der Begriff des Data Warehouse bzw. des Data Warehousing wurde gegen Ende der 1980er Jahre zum ersten Mal gebraucht. Im Laufe des darauffolgenden Jahrzehnts gewannen die Begriffe und die hinter den Begriffen liegende Technik immer mehr an Bedeutung, die Fortentwicklung in den zugehörigen Bereichen hält bis heute an. Data Warehouses lassen sich allgemein dem weitreichenden Umfeld der Informationssysteme zuordnen. Der Brockhaus Naturwissenschaft und Technik (2003) beschreibt Informationssysteme als „Systeme zur Speicherung, Verknüpfung, Verarbeitung, Auswertung, Wiedergewinnung [. . . ] und Ausgabe von Informationen, die ein nach organisator. und techn. Prinzipien zusammengefasstes Ganzes von Informations- und Kommunikationsbeziehungen zw. Menschen und Maschinen darstellen.“ Die Besonderheit des Data Warehouse liegt einmal in der Integration verschiedenster Datenquellen in eine gemeinsame Basis. Der Integrationsvorgang ist „besonders schwierig, wenn heterogene Daten unterschiedlichster Qualität in verschiedenen Datenformaten, in heterogenen Datenmodellen und Datenbanksystemen gehalten werden“ (Bauer, Günzel, 2004, S. 6). Es ist erforderlich, die Struktur der Rohdaten zu analysieren, die Daten zu bereinigen und zu transformieren, um für das weitere Vorgehen eine Grundlage mit einheitlicher Struktur und hoher Qualität zu erhalten. Das zweite wichtige Merkmal ist der analytische Aspekt. Im Gegensatz zu operativen Systemen, die im betriebswirtschaftlichen Sinne den laufenden Betrieb unterstützen, steht beim Data Warehouse der analytische Aspekt im Vordergrund. Es wird mehrheitlich lesend auf die Daten eines größeren Zeitraumes zugegriffen, um sie auszuwerten und nach Abhängigkeiten oder Besonderheiten zu suchen. Die vorliegende Arbeit realisiert ein Informationssystem im Sinne eines Data Warehouse im umwelttechnischen Bereich. Die Konzeption und Implementierung erfolgte in einer Zusammenarbeit zwischen dem Institut für Datenbanken und Informationssysteme am Max-Planck Institut für Informatik und dem Institut für Anorganische und Analytische Chemie und Radiochemie an der Universität des Saarlandes im Rahmen des EU-Projektes „LIFE ENV/D/000337 Ferngesteuerte Kontrolle des eutrophierenden Eintrags aus diffusen Quellen in der Region SAAR-LOR-LUX“. Der Schwerpunkt liegt auf der automatisierten Aufnahme von Gewässermessdaten in eine Datenbank und deren Bewertung und Bereinigung, die wiederum als Ausgangsbasis für die weitere Präsentation bzw. Analyse der Messungen dient.

1

1 Einführung

1.2 Beitrag der Arbeit Im Rahmen dieser Arbeit wurde ein Umweltinformationssystem entworfen und realisiert, das als zentrale Datenbasis für die Aufnahme und Verarbeitung verschiedener Ausgangsdaten dient. Es besteht die Möglichkeit, Gewässer- und andere Umweltdaten verschiedener Formate automatisiert oder manuell in eine Datenbank zu integrieren, ihre Qualität zu bewerten und zu visualisieren. Alle Vorgänge und Prozesse werden protokolliert und sind jederzeit nachvollziehbar und reversibel. Weiterhin können Daten in frei definierbaren Formaten exportiert werden, um anderen Organisationen Zugriff auf die Daten zu ermöglichen bzw. mit statistischen Werkzeugen eine weitergehende Analyse durchzuführen.

1.3 Aufbau der Arbeit Im Anschluss beschreibt Kapitel 2 den fachlichen Hintergrund des Projektes, die informationstechnische Basis und erstellt das Fachkonzept, das die Ziele, Anforderungen und Datenstrukturen der Anwendung festlegt. Das dritte Kapitel geht auf die allgemeine technische Realisierung ein. Es werden die einzelnen Schichten der Software von der Datenhaltung über die Prozessschicht bis hin zur Oberfläche beschrieben und die benutzten Werkzeuge vorgestellt. Kapitel 4 gibt einen Überblick über die konkreten Teile des Programmes. Anhand der Struktur der Oberfläche wird grob die Funktionalität der einzelnen Bausteine dokumentiert.

2

2 Analyse und Systemspezifikation Im Kapitel „Analyse und Systemspezifikation“ werden die fachlichen Anforderungen und Inhalte des geplanten Informationssystems analysiert und festgelegt. Sie dient als Vorlage für die folgende Systemkonstruktion. Das Kapitel behandelt, was das System können soll, nicht wie dies konkret realisiert wird. Man spricht auch vom Fachkonzept.

2.1 Grundlagen Das Kapitel „Grundlagen“ gibt zuerst einen Überblick über den fachlichen Kontext, in dem die Arbeit realisiert wurde. Daraufhin werden theoretische Grundlagen der Informationstechnologie beleuchtet, deren Konzepte die Arbeit beeinflusst haben.

2.1.1 Fachliches Umfeld In der im Jahr 2000 vom Europäischen Parlament verabschiedeten Wasserrahmenrichtlinie hält die Europäische Union ihre Mitgliedsstaaten an, eine gemeinsame Gewässerpolitik zu betreiben, da Fließgewässer und deren Einzugsgebiete meistens nicht politischen Grenzen folgen, sondern benachbarte Staaten gleichzeitig betreffen. Daher sollen Maßnahmen und Projekte zum Gewässerschutz einem länderübergreifenden Ansatz folgen. Im Rahmen dieser Richtlinie wurde das Projekt „Ferngesteuerte Kontrolle des eutrophierenden Eintrags aus diffusen Quellen in der Region SAAR-LOR-LUX“ durchgeführt. Wichtigster Gesichtspunkt des Projekts ist die Erfassung und Beurteilung von Einträgen aus nicht direkt lokalisierbaren (diffusen) Quellen in Gewässer. Lokalisierbare oder punktuelle Einträge erfolgen beispielsweise durch Kläranlagen oder industrielle Einleitungen. Im Gegensatz dazu versteht man unter diffusen Einträgen Auswaschungen aus den umliegenden Bereichen oder der Atmosphäre. Je nach Nutzung des Einzugsgebietes eines Gewässers kann es sich bei den Einträgen unter anderem um Nährstoffe wie Stickstoff- oder Phosphorverbindungen, die z.B. aus Düngemitteln oder undichten Kanalisationsrohren stammen, handeln. Diffuse Verschmutzungen können empfindlich auf das ökologische Gleichgewicht in Gewässern Einfluss nehmen. Eine zu hohe Nährstoffkonzentration kann zu einem verstärkten Algenwachstum führen, was im Endeffekt einen Sauerstoffmangel im Wasser und damit ein Fischsterben verursachen kann. Der Fachbegriff für diesen Vorgang lautet Eutrophierung. Aus diesem Grund ist die ständige Überwachung in Hinsicht auf negative Veränderungen im Wasserhaushalt von großer Bedeutung. Durch verschiedene Maßnahmen konnten die punktuellen Einleitungen in den letzten Jahren deutlich reduziert werden. Die diffusen Einträge verharren dagegen auf gleich hohem Niveau. Jedoch können die diffusen Belastungen kaum durch manuelle Messungen erfasst werden. Diesem Aspekt trägt das initiierte Projekt Rechnung, indem ein System kontinuierlich und auto-

3

2 Analyse und Systemspezifikation

Abbildung 1: Aussenansicht und Innenansicht des Containers Niedaltdorf nom arbeitender Messstationen entwickelt und realisiert wurde. Dabei ermöglichen die hohe zeitliche Auflösung der gewonnenen Daten sowie der Vergleich unterschiedlicher Parameter eine Unterscheidung von diffusen und punktuellen Einleitungen sowie in vielen Fällen auch eine Abschätzung ihrer Herkunft. Das betrachtete Gebiet umfasst das Einzugsgebiet der Flüsse Nied auf französischer und deutscher Seite und Attert auf luxemburgischer Seite. Dementsprechend nehmen am Projekt Institutionen aller drei Nationen teil. Insgesamt wurden fünf Messcontainer konstruiert, die mit Analysegeräten für diverse Gewässerparameter (z.B. Nitrat, Sauerstoff, pH-Wert) ausgerüstet sind. Abbildung 1 zeigt das Innere und die Aussenansicht des Messcontainers am Standort Niedaltdorf. Die Analysegeräte arbeiten automatisch und messen in einem festen Intervall die entsprechende Kenngröße. Die gemessenen Daten werden in einem gemeinsamen Datenspeicher gesammelt, der seit Anfang 2005 eine Kapazität von ca. 20 Tagen für Messdaten besitzt. Dieser Speicher lässt sich per Datenfernübertragung über eine Kontrollsoftware abfragen, die Verbindungen wurden wenn möglich über übliche Telefonleitungen, andernfalls per GSM Funkübertragung realisiert. Ist der Speicher komplett gefüllt, werden die bisher gesammelten Daten von Beginn an überschrieben und gehen somit verloren. Das Auslesen der Daten kann entweder direkt vom Benutzer angestoßen werden, oder geschieht bevorzugt automatisch zu einer festgelegten Uhrzeit. Dies soll sicherstellen, dass die bereits gesammelten Daten nicht verloren gehen, auch wenn keine Person am Steuer-PC die Daten abruft. Weiterhin besitzen manche Sensoren zusätzlich einen internen Speicher, der jedoch nur vor Ort mit einer Direktverbindung zu einem PC ausgelesen werden kann. Das größte Problem bei der Sammlung der Daten liegt in der Sicherstellung, dass die gemessenen Werte auch korrekt sind. Aufgrund der technischen Umsetzung kann es an diversen Stellen im Messprozess zu Fehlfunktionen kommen. Beispielsweise müssen sich die Messsonden in einer Mindestmenge an Wasser befinden. Tritt aber an der Pumpe, die das Wasser vom Fluss in den Container befördert, eine Fehlfunktion auf, so werden inkorrekte Werte erfasst. Weiter-

4

2 Analyse und Systemspezifikation

hin kann es vorkommen, dass die Daten nicht korrekt in den Datenlogger übertragen werden bzw. Werte beim Auslesen verloren gehen. Neben diesen nicht steuerbaren Vorfällen, die die Messgüte beeinflussen können, existieren planbare Vorgänge wie das Neukalibrieren der Sensoren oder die manuelle Wartung der Container. All diese Möglichkeiten wirken sich negativ auf die Datenqualität aus und daraus resultierende falsche Messwerte müssen gekennzeichnet werden. Neben dieser Datenquelle existieren weitere Informationen wie Niederschlagsmengen oder Abflussdaten, die von externer Seite aus bereitgestellt werden. Diese Zahlen sind für die weitere Interpretation ebenfalls von Bedeutung. Aufgrund der enormen Anzahl der erhobenen und zusätzlich benötigten Daten, der Bedeutung des Vergleiches verschiedener Parameter oder unterschiedlicher Standorte sowie der Plausibilisierung der einzelnen Werte wurde eine Datenbank und Software benötigt, die die Wissenschaftler bei der Integration und Verwaltung aller Daten unterstützt. Für nähere Informationen zum fachlichen Hintergrund siehe Beck (2004).

2.1.2 Datenbanksysteme Grundlage der Datenhaltung der meisten Programme bilden sogenannte Datenbanksysteme (DBS). Ein Datenbanksystem setzt sich nach Cordts (2002) zusammen aus dem DatenbankManagement-System (DBMS) und einer oder mehrerer Datenbanken. Das DBMS dient der Verwaltung der einzelnen Datenbanken. Eine Datenbank „stellt den zusammengehörigen Datenbestand dar (z.B. alle Daten der Abteilung Personal oder alle Adressdaten eines Unternehmens)“ (Cordts, 2002, S. 19). Laut Balzert (1999, S. 304f) müssen Datenbanksysteme folgende Eigenschaften erfüllen: Persistente Speicherung der Daten, d.h. die Daten gehen nicht bei Programmende verloren, sondern sie stehen solange zur Verfügung, bis sie explizit gelöscht oder überschrieben werden. Zuverlässige Verwaltung der Daten, d.h. das Datenbanksystem stellt die Konsistenz, Integrität und Unversehrtheit der Daten sicher. Im Falle eines Hardwareoder Softwareausfalls ermöglicht das Datenbanksystem einen Wiederanlauf (recovery). Unabhängige Verwaltung der Daten, d.h. die in der Datenbank gespeicherten Daten werden einheitlich beschrieben. Dadurch werden die Anwendungsprogramme, die ein Datenbanksystem benutzen und das Datenbanksystem weitgehend unabhängig voneinander. Komfortable Verwendung der Daten, d.h. der Benutzer muss sich nicht um Details - z.B. Speicherung der Daten - kümmern, sondern kommuniziert über eine höhere, abstrakte Schnittstelle mit der Datenbank. Flexibler Zugang zu den Daten, d.h. mit Hilfe geeigneter Anfragesprachen und anderer Hilfsmittel kann der Benutzer ohne prozedurale Programmierung ad hoc auf die Daten zugreifen. Datenschutz, d.h. Daten können vor unberechtigtem Zugriff geschützt werden.

5

2 Analyse und Systemspezifikation

Verwaltung großer Datenbestände, d.h. die Datenbank kann nicht vollständig im Arbeitsspeicher gehalten werden. Integrierte Datenbank, d.h. alle Daten werden redundanzarm gespeichert, selbst wenn sie von verschiedenen Anwendungen stammen bzw. von verschiedenen Anwendungen benötigt werden. Das hat zur Folge, dass nicht jedes Anwendungsprogramm alle Daten benötigt, sondern nur bestimmte Ausschnitte. Mehrfachbenutzung der Datenbank, d.h. auf die Daten können mehrere Anwendungen - u.U. auch gleichzeitig - zugreifen. Der parallele Zugriff mehrerer Anwendungsprogramme oder Benutzer muß koordiniert werden. Jedes Datenbanksystem folgt einem bestimmten Datenmodell, welches den Aufbau der einzelnen Datenelemente festlegt und die Zugriffsoperationen auf ein Element vorgibt. Man unterscheidet heutzutage vor allem das relationale und das objektorientierte Datenmodell. Dementsprechend spricht man auch von relationalen und objektorientierten Datenbanksystemen. Ein objektorientiertes System ermöglicht die direkte Speicherung von Objekten, die von einer objektorientierten Programmiersprache wie Java erzeugt werden können. Benutzt man eine solche Programmiersprache in Verbindung mit einem relationalen Datenbanksystem, ist eine objekt-relationale Abbildung erforderlich. Dieser Ansatz wird auch in der vorliegenden Arbeit verfolgt.

2.1.3 Relationales Datenmodell Das relationale Datenmodell wurde 1970 von E.F. Codd entwickelt. Es basiert auf dem mathematischen Modell von Mengen oder Relationen. Für eine genauere Beschreibung siehe Balzert (1999). Eine Relation läßt sich anschaulich als Tabelle darstellen, wobei die Spalten einzelne Attribute beinhalten und eine Zeile einem Element der Tabelle entspricht (vgl. Abbildung 2).

Abbildung 2: Beispiel Relation - Tabelle (Quelle Cordts, 2002, S. 72)

6

2 Analyse und Systemspezifikation

Abbildung 3: Beispiel Verknüpfung von Tabellen (Quelle Cordts, 2002, S. 71, geänderte Darstellung) Jede Zeile der Tabelle muss durch einen eindeutigen Schlüssel, den Primärschlüssel, eindeutig identifizierbar sein. Er kann aus einem oder mehreren Attributen bestehen. Falls speziell für den Primärschlüssel ein eigenes Attribut hinzugefügt wird. spricht man von einem künstlichen Schlüssel. Eine Verknüpfung oder Assoziation zwischen zwei Tabellen wird gebildet durch eine Schlüssel-Fremdschlüssel-Beziehung. Im Beispiel in Abbildung 3 wird die Tabelle Abteilung mit der Tabelle Mitarbeiter verknüpft, indem zu jeder Abteilung der Abteilungsleiter aus der Mitarbeiterliste gespeichert wird. Dazu enthält jede Zeile, die eine Abteilung repräsentiert, ein Attribut „Abteilungsleiter“, welches den Primärschlüssel eines Eintrags der anderen Tabelle enthält. Dieses Feld beinhaltet damit einen Fremdschlüssel. Wichtiges Merkmal einer Assoziation ist deren Kardinalität. Darunter versteht man, wie viele Einträge der einen Tabelle in Beziehung mit Einträgen einer anderen Tabelle stehen. Man unterscheidet folgende Typen: 1:1 Genau ein Element der einen Tabelle ist mit genau einem Element der anderen Tabelle verknüpft. 1:n Einem Element der einen Tabelle sind beliebig viele Einträge der zweiten Tabelle zugeordnet. Im Beispiel zur Verknüpfung von Tabellen besitzt eine Abteilung genau einen Abteilungsleiter, ein Mitarbeiter kann umgekehrt beliebig viele Abteilungen führen. n:m Beliebig viele Elemente der einen Tabelle sind mit beliebig vielen der anderen Tabelle verbunden. Ein Beispiel wäre eine Verknüpfung einer Kundentabelle mit einer Artikeltabelle über die Bestellungen. Ein Kunde kann beliebig viele Artikel kaufen, ein Artikel kann von beliebig vielen Kunden gekauft werden. Als Standardsprache zur Erstellung von Tabellen und Zugriff auf Tabellen hat sich die Struc-

7

2 Analyse und Systemspezifikation

tured Query Language (SQL) durchgesetzt. Sie beinhaltet vielfältige Befehle und Optionen zum Erstellen, Löschen und Auswählen von Tabelleneinträgen. Für SQL existieren mehrere offiziell verabschiedete Standards, welche von den konkreten Datenbanksystemen mehr oder weniger genau umgesetzt werden.

2.1.4 Data Warehouse, Data Cleaning und Data Mining Für den Data Warehouse Begriff existiert keine eindeutige Definiton. Je nach Kontext und Sichtweise kann sich das Verständnis dafür ändern. Eine der ersten Definitionen für den Begriff lieferte William Inmon: „A data warehouse is a subject oriented, integrated, non-volatile, and time variant collection of data in support of management’s decisions.“ (Bauer, Günzel, 2004, S.7) Unter den in der Definition genannten Eigenschaften ist Folgendes zu verstehen (vgl. Bauer, Günzel, 2004, S.7): Fachorientierung Der Zweck der Datenbasis liegt nicht mehr in der Erfüllung einer Aufgabe wie eine Personaldatenverwaltung, sondern auf der Modellierung eines spezifischen Anwendungsziels. Integrierte Datenbasis Die Datenverarbeitung findet auf integrierten Daten aus mehreren Datenbanken statt. Nicht flüchtige Datenbasis Die Datenbasis ist als stabil zu betrachten. Daten, die einmal in das Data Warehouse eingebracht wurden, werden nicht mehr entfernt oder geändert. Historische Daten Die Verarbeitung der Daten ist so angelegt, dass vor allem Vergleiche über die Zeit stattfinden. Es ist dazu unumgänglich, Daten über einen längeren Zeitraum zu halten. Bauer und Günzel üben Kritik an dieser Definition und liefern ihrerseits folgenden Versuch: „Ein Data Warehouse ist eine physische Datenbank, die eine integrierte Sicht auf beliebige Daten zu Analysezwecken ermöglicht.“ (Bauer, Günzel, 2004, S.7) Nach dieser Aussage verfügt die hier realisierte Software über die Eigenschaften eines Data Warehouse. Wie bereits in der Einleitung gesagt, wird ein Data Warehouse einmal vom integrativen und einmal vom analytischen Aspekt geprägt. Bei der Aufnahme oder Integration von neuen Daten in die Datenbasis sind Begriffe wie Data Cleaning und Data Preparation von Bedeutung. Man versteht darunter die Prozesse, die durchgeführt werden, um aufzunehmende Daten vorzubereiten, anzupassen und deren Qualität zu bewerten. Sind die Daten einmal im Data Warehouse vorhanden, dienen sie als Ausgangsbasis für weitere Analyseprozesse. Dies wird mit dem Ausdruck Data Mining bezeichnet, worunter man „eine Suche nach unbekannten Mustern oder Beziehungen im Datenbestand des Data Warehouse“ (Bauer, Günzel, 2004, S. 8) versteht. Den gesamten Vorgang von der Datenbeschaffung, der -bereinigung, der

8

2 Analyse und Systemspezifikation

-speicherung und der anschließenden Analyse wird Data Warehouse Prozess oder Data Warehousing genannt. Ein Großteil der Anwendungsbereiche liegt im betriebswirtschaftlichen Sektor. Es existieren jedoch auch Anwendungen auf wissenschaftlichen und technischen Gebieten wie im vorliegenden Fall.

2.2 Ziele und Rahmenbedingungen Ziel der Arbeit ist die Konzeption und Implementierung eines Umweltinformationssystems, das alle anfallenden Daten in eine gemeinsame Basis integriert. Das Lexikon Geoinformatik (2004) der Universität Rostock definiert ein Umweltinformationssystem wie folgt: „Ein Informationssystem, das Umweltinformationen bereitstellt. [. . . ] Es bietet leistungsfähige Zugriffs- und Auswertemethoden zur Ableitung von Umweltinformation. [. . . ] Ein UIS ist ein erweitertes GIS, das der Erfassung, Speicherung, Verarbeitung und Präsentation von raum-, zeit- und inhaltsbezogenen Daten zur Beschreibung des Zustandes der Umwelt hinsichtlich Belastungen und Gefährdungen dient und Grundlagen für Maßnahmen des Umweltschutzes bildet.“ Im vorliegenden Fall sollen verschiedenste Arten an Datenquellen und deren Formate analysiert und ein passendes Datenmodell zur Speicherung in einer Datenbank erstellt werden. Außerdem soll ein Bewertungssystem zur Qualität der Messdaten entworfen werden, welche jedem Messwert automatisiert anhand bestimmter Regeln und Abhängigkeiten der Sensoren untereinander zugewiesen wird. Dazu soll eine Datenbank angelegt werden, in welche alle anfallenden Daten anhand des Modells abgespeichert werden. Weiterhin soll eine Software geplant und implementiert werden, welche den automatisierten und manuellen Import aller Datenformate ermöglicht. Die Software soll Schnittstellen bieten, um die vereinheitlichten Daten weiteren Analyseprozessen zur Verfügung stellen zu können bzw. den Datenaustausch mit anderen Organisationen zu unterstützen. Dazu soll die Software die Möglichkeit bereitstellen, die verschiedenen technischen Konfigurationen der Container zu verwalten, ebenso wie die Regeln, mit deren Hilfe die automatische Qualitätsbewertung stattfindet. Darüber hinaus soll die Software die eingelesenen Daten sowohl in tabellarischer als auch in graphischer Form in beliebigen Kombinationen zugänglich machen, um den Anwender bei der endgültigen manuellen Festlegung der Werteplausibilität zu helfen. Die Benutzeroberfläche soll dabei multilingual aufgebaut sein und auch im Nachhinein neue Sprachkonfigurationen unterstützen. Aus technischer Sicht besteht der Wunsch, dass die Verwaltungssoftware ebenso wie die Datenbank möglichst betriebssystemunabhängig sowie auch unabhängig voneinander realisiert werden, um eine potentielle Nutzung in einem anderen Kontext sicherzustellen, der auf bisher nicht genutzte technische Plattformen aufbaut. Zuletzt soll die Software eine Rechteverwaltung beinhalten, die einzelnen Nutzern verschiedenen Stufen der Nutzung erlaubt. Neben der Verwaltungssoftware soll eine Webseite erstellt werden, die den kontrollierten Zugriff auf validierte und korrekte Daten ermöglicht.

9

2 Analyse und Systemspezifikation

2.3 Nachbarsysteme Das geplante Informationssystem besitzt Schnittstellen von und zu anderen Systemen. In den folgenden Abschnitten wird näher darauf eingegangen, welche Daten als Input zur Verfügung stehen und inwiefern das System wiederum seine Daten als Output an andere Systeme weitergeben kann.

2.3.1 Importquellen In diesem Abschnitt werden alle Datenquellen beschrieben, die analysiert und in die Datenbank aufgenommen werden sollen. Dabei wird unterschieden zwischen reinen Messdaten und Kontrolldaten, die Einfluss auf die Datenqualität besitzen. 2.3.1.1 Datenloggerwerte aus den Containern Die Datenloggerwerte aus den Containern stellen den Großteil der anfallenden Daten dar. Die Kontrollsoftware, mit der die Container per Modem ausgelesen werden, erstellt jeden Tag eine CSV Datei, normalerweise mit fünfminütiger Zeitauflösung der Messungen. Die implementierte Software kann diesen Dateibaum automatisch auf neu hinzugekommene Dateien durchsuchen und bei einwandfreier Analyse die Inhalte importieren. Der Benutzer wird über solche Vorgänge in dem entsprechenden Bereich nach erfolgreicher Anmeldung im System informiert.

* Name: Messwertarchiv 15 Min Mittel * Pfad: E:\pools\unisb\anlagen\cont1\archive\mean15\j2003\m11_Nov\t031128.csv * erstellt am: 28.11.2003 05:02 Datum;Zeit;Modul 2;Modul 3;Modul 4;Modul 5;Modul 6;Modul ... Datum;Zeit;NH4-N (mg/l);Gesamt P (mg/l);Ortho Phosphat P (mg/l); ... 28.11.2003;00:00; 0,035; 0,310; 0,258; 6,768; 17,123; 3,370; ... 28.11.2003;00:05; 0,035; 0,310; 0,258; 6,768; 17,123; 3,371; ...

Abbildung 4: Beispielauszug für eine übertragene Datei aus dem Datenlogger

Das Format einer Datenzeile hat den Aufbau „Datum;Uhrzeit; Wert von Sensor 1; Wert von Sensor 2; usw.“ (vgl. Abbildung 4). Ein Messwert liegt als Dezimalzahl vor. Eine Zeile, die nicht mit einem gültigen Datum beginnt, ist eine Kommentarzeile. Die letzte Kommentarzeile vor den Datenzeilen beschreibt den Inhalt der einzelnen Datenspalten. Jeder Spaltentext wird mit einem in der Sensordefinition gespeicherten Muster verglichen, um festzustellen, um welchen Sensor es sich handelt. Misslingt diese Erkennung, versucht die Software den Sensor anhand der Spaltennummer zu identifizieren. Ist eine solche textuelle Definitionszeile nicht vorhanden, muss die inhaltliche Interpretation vollständig anhand der Reihenfolge der Spalten durchgeführt werden. Weiterhin beinhalten die übertragenen Dateien auch Datenspalten ohne Belegung, welche bei der Analyse einfach ignoriert werden können.

10

2 Analyse und Systemspezifikation

Der sich im Einsatz befindliche Chlorophyllsensor misst insgesamt zwölf Kanäle, von denen aber nur zwei am Datenlogger anliegen und damit auch übertragen werden. Zu Anfang wurden dabei z.T. nicht sinnvolle Werte übertragen, so dass benutzbare Chlorophylldaten nur direkt im Container ausgelesen werden konnten. Die verschiedenen Chlorophyllsensoren werden in der Software als unabhängige Einzelsensoren angesehen. 2.3.1.2 Lokal ausgelesene Daten Parallel zu der Speicherung im Datenlogger besitzen manche Sensoren auch einen internen Speicher. Dieser kann nicht direkt zum Kontrollrechner übertragen, sondern muss vor Ort ausgelesen werden. Zur Verarbeitung dieser Daten wird eine weitere Software benötigt, die wiederum den Export als Excel- oder Textdatei erlaubt. Eine Datei repräsentiert dabei einen einzigen Sensor, der Zeitraum ist nicht festgelegt, er richtet sich nach der Größe des internen Speichers eines Sensors und dem Zeitpunkt des letzten manuellen Auslesens.

E:\Pegel\02_11_05\NO3_02_11_05 Textexportdatei Viewtax für Windows NITRATAX 1055298 1.9.02 01:55 1.9.02 02:00 1.9.02 02:05

Anzeige 10,960938 11,000000 11,000000

EM 261,000000 271,000000 261,000000

ER 50,125000 50,125000 50,125000

Abbildung 5: Beispielauszug für eine vor Ort ausgelesene Sensordatei

Eine solche Datei hat ein anderes Format als eine Datei, die aus dem Datenlogger stammt (siehe Abbildung 5). Die Software unterstützt die Formate folgender Sensoren, die eine direkte Auslesemöglichkeit bieten: • Chlorophyll / Transmission • Trübung • TOC • SAK • P O4 • N O3 • N H4

11

2 Analyse und Systemspezifikation

2.3.1.3 Labordaten Von Zeit zu Zeit werden an den Containerstandorten Wasserproben entnommen und im Labor analysiert. Diese punktuellen Stichproben werden ebenfalls in die Datenbank aufgenommen, um einen Vergleich zwischen diesen Referenzwerten und den automatisch von den Geräten ermittelten bilden zu können. Dazu besteht die Möglichkeit, auch einzelne Werte manuell einzugeben mit Angabe des Entnahmezeitpunkts und Geltungsbereichs für Vergleiche.

2.3.2 Externe Daten Neben den auf deutscher Seite ermittelten Messwerten erfolgt parallel eine Aufnahme von Werten der übrigen Partner und anderer externer Stellen. 2.3.2.1 Umweltministerium Aus dem saarländischen Landesamt für Umweltschutz werden per Email oder Internetseite Daten über folgende Sachverhalte geliefert: • Niederschläge (vgl. Abbildung 6) • Durchflussmengen • Pegelstände • Im Labor analysierte Proben Diese Daten können ebenfalls importiert werden, jedoch ist hier im Gegensatz zu den selbst erstellten Messungen eine Beurteilung der Richtigkeit und ein Abweisen von Werten nicht erforderlich. Die Informationen werden ungeändert übernommen und stehen somit für eine spätere Analyse zur Verfügung. 2.3.2.2 Daten der französischen Partner Zugriff auf die gemessenen Werte der französischen Partner erfolgte während des Projektes durch einen direkten Zugriff auf den Datenspeicher in den Containern per Modem analog zur Abfrage auf deutscher Seite. Unterschiede ergaben sich durch die dortige Verwendung des PLQ2000 Protokolls, da sich hierdurch der technische Aufbau des Datenloggers und die Zusammenarbeit mit der Kontrollsoftware anders gestaltet hat. Parallel zur der in dieser Arbeit entwickelten Lösung wurde von den dortigen Teilnehmern eine eigene Bewertungssoftware erstellt, um die Möglichkeiten von PLQ2000 evaluieren zu können.

2.3.3 Kontrollereignisse Neben den reinen Sensormessungen werden weitere Informationen erfasst, die Hinweise auf die Güte der Messungen geben können.

12

2 Analyse und Systemspezifikation

Niederschlags-Summenliste ------------------------Stations-Nr. : 3000665 Ort : Gisingen Zeitraum : 1.02.2003 bis 8.05.2003 Summenwerte : Letzte Bearbeitung : 12.06.2002/RO4;6 2.02.2003-03:00-04:00 o,2 mm 2.02.2003-04:00-05:00 o,7 mm 2.02.2003-05:00-06:00 o,7 mm 2.02.2003-06:00-07:00 o,6 mm 2.02.2003-07:00-08:00 o,2 mm 2.02.2003-08:00-09:00 o,1 mm 2.02.2003-09:00-10:00 o,2 mm 2.02.2003-15:00-16:00 o,2 mm 2.02.2003-16:00-17:00 o,7 mm 2.02.2003-17:00-18:00 o,3 mm

Abbildung 6: Beispielauszug für eine Liste mit Niederschlagsdaten 2.3.3.1 Ereignisliste der einzelnen Sensoren Neben den eigentlichen Messdaten speichern manche Sensoren zusätzlich Ereignislisten. Hierin werden Gerätezustände wie Störungsbeginn und -ende oder Kalibrierungsstart und -ende verzeichnet. Diese Listen müssen auch direkt vor Ort am Gerät ausgelesen werden. Die enthaltenen Informationen liefern Kriterien, um den Status der in diesem Zeitraum aufgenommenen Daten bewerten zu können. Die Software analysiert dazu anhand von gespeicherten Mustern solche Ereignislisten und nutzt diese zur weiteren Validierung der Messwerte. 2.3.3.2 Manuell verursachte Ereignisse Neben der Ereignisliste der intelligenten Sensoren gibt es auch die Möglichkeit, weitere Ereignisse, die Einflüsse auf die Richtigkeit eines Sensorwertes haben können, in die Datenbank einzubinden. Dazu gehören entweder sich wiederholende Einträge, z.B. dass ein Sensor täglich in einem gewissen Zeitraum kalibriert oder sich reinigt. Außerdem können auch manuelle Arbeiten an einem Sensor, wie der Austausch von Chemikalien im Container, in die Datenbank eingepflegt werden. Dazu stellt die Software eine entsprechende Verwaltungsoberfläche bereit, in der man solche Einträge für beliebige Sensoren verwalten kann.

13

2 Analyse und Systemspezifikation

NITRATAX 1055298 9:51 5.11.02 0.00 2. 9.2002 14.40 2. 9.2002 14.40 2. 9.2002 14.48 2. 9.2002 14.58 2. 9.2002 0.00 3. 9.2002 0.00 4. 9.2002 0.00 5. 9.2002 13.55 5. 9.2002 13.58 5. 9.2002 14.27 5. 9.2002 14.27 5. 9.2002 14.41 5. 9.2002 14.42 5. 9.2002

Nitratax

V3.10

Zeit Power Down Power Up Power Down Power Up Zeit Zeit Zeit Bedienvorgang Bedienvorgang Power Down Power Up Power Down Power Up

Loggerbetrieb Wiederaufnahme Meßbetr.

Abbildung 7: Beispielauszug für eine Ereignisliste 2.3.3.3 Binäre Ereignisse aus dem Datenlogger In den übertragenen Dateien aus dem Datenlogger befinden sich weitere Spalten mit binären Informationen zum technischen Zustand des Containers. Beispielsweise wird das Signal „Störung Förderpumpe“ geliefert, welches besagt, dass die Pumpe nicht korrekt funktioniert, daher kein neues Wasser zur Messung in den Container befördert wird und somit keiner der Sensoren aktuelle Daten liefert.

2.3.4 Exportmöglichkeiten Um die weitere Analyse zu ermöglichen, bietet die Software die Möglichkeit, beliebige Kombinationen von Daten zu exportieren. Um die Kompatibilität zu zukünftigen Anwendungen zu gewährleisten, können nachträglich neue Datenformate definiert werden. Anfangs können Exporte in einem CSV Format und einem Format kompatibel zur Auswertungssoftware der französischen Partner getätigt werden.

2.3.5 Webschnittstelle Neben der Hauptsoftware besteht ein kontrollierter Zugriff auf die Daten über eine Webschnittstelle. Diese besitzt gegenüber dem eigenständigen Programm einen viel geringeren Funktionsumfang. Hauptgewicht liegt auf dem lesenden Zugriff auf validierte Daten von externer Seite, ohne dass eine Software installiert werden muss.

14

2 Analyse und Systemspezifikation

2.4 Statische Analyse - Datenmodell Im Kapitel „Statische Analyse - Datenmodell“ werden die statischen Elemente, also das Datenmodell, beschrieben. Die graphische Darstellung erfolgt als Entity-Relationship-Diagramm (siehe Cordts, 2002) in der min-max Notation.

Abbildung 8: Allgemeines ERM

Abbildung 8 zeigt ein allgemeines Beispiel von zwei verknüpften Tabellen. Der Primärschlüssel jeder Tabelle steht in der ersten Zeile und ist mit einem Schlüssel gekennzeichnet. Ein Fremdschlüsselfeld ist gekennzeichnet durch eine rote Raute, sonstige Attribute durch eine blaue. Eine Assoziation wird dargestellt durch die größere Raute in der Mitte. Die Kardinalitäten sind im vorliegenden Fall folgendermaßen zu lesen: Ein Element aus Tabelle 1 besitzt kein bis zu beliebig vielen Elementen aus Tabelle 2, ein Element von Tabelle 2 gehört minimal einem, maximal einem, also genau einem einzigen Element aus Tabelle 1. Die folgenden Abbildungen enthalten jeweils Ausschnitte aus der vollständigen Darstellung. Assoziationen, die nicht zum erklärten Kontext gehören, werden weggelassen. Demzufolge fehlen in den Darstellung die Fremdschlüsselattribute der weggelassenen Verknüpfungen. Genaue Angaben zur Bedeutung jedes einzelnen Attributes sind den XML Mappingdateien zu entnehmen, in denen die Datenstrukturen definiert werden (siehe 3.3.1).

2.4.1 Containerdefinition In einem Messcontainer befinden sich normalerweise mehrere Sensoren. Die Konfiguration kann sich dabei von Zeit zu Zeit ändern, neue technische Geräte werden eingebaut oder vorhandene ersetzt. Dies wird in Abbildung 9 deutlich. Einem Container können beliebig viele Sensoren zugeordnet werden, welche mindestens ein Datum, das den Beginn der Messungen anzeigt, und ein Endedatum haben können, sofern der Sensor nicht mehr benutzt wird. Andernfalls wird davon ausgegangen, dass das Ende offen ist und der Sensor bis auf weiteres arbeitet. Ein Sensor kann einen Wert in verschiedenen Ausprägungen liefern, d.h. ein Sensor kann die gleiche Kenngröße in verschiedenen Maßeinheiten messen. Beispielsweise kann die Information über Nitrat als N O3 oder alternativ als N O3 − N geliefert werden. In der Datenbank werden die Werte in einer Basiseinheit gespeichert und alle weiteren Ausdrucksmöglichkeiten können daraus berechnet werden. Diese Berechnung erfolgt über eine Lineartransformation Wert in Hauptausprägung = Faktor * Wert in Unterausprägung + Summand,

15

2 Analyse und Systemspezifikation

Abbildung 9: ERM Container und Sensoren

16

2 Analyse und Systemspezifikation

wobei in der Datenbank alle alternativen Ausdrucksmöglichkeiten mit den Parametern zum Umrechnen gespeichert werden. Der Zusammenhang zwischen einer Ausprägung und ihrer zugehörigen Hauptausprägung wird dargestellt durch die rekursive Beziehung der Tabelle „auspraegung“ zu sich selber. Weiterhin kann man sowohl einem Container als auch einem Sensor einen sogenannten Parser zuordnen. Damit ist ein Filter gemeint, der eine zu importierende Datei des Containers oder Sensors analysieren kann. Diese Information ist erforderlich, um der Software nachträglich neue Filter hinzufügen und zuordnen zu können.

2.4.2 Korrelationen und Bewertung Ein Hauptziel der Software ist ein automatisierter Import von in den Containern ausgelesenen Daten und eine Bewertung, inwieweit man der Richtigkeit einer Messung vertrauen kann oder nicht. Zu einer solchen Bewertung ist eine Einteilung in verschiedene Bewertungsklassen erforderlich. Im einfachsten Fall würde ein Wert die zwei Zustände „ist korrekt“ oder „ist nicht korrekt“ besitzen. Auf der anderen Seite könnte man eine weiche Bewertung einführen, so dass beispielsweise eine Zahl aus einem Intervall zwischen 0 und 1 eine Wahrscheinlichkeit angibt, inwiefern ein Wert als korrekt anzusehen ist oder nicht. Diese Zahl müsste nach verschiedenen Kriterien automatisch berechnet werden. Es hat sich jedoch gezeigt, dass dieser Weg zu weit führen würde, die erforderliche Arbeit zum Aufstellen der Regeln würde den Nutzen bei weitem übersteigen. Daher wird eine Mischform mit den Möglichkeiten „inkorrekt“, „vielleicht korrekt“, „korrekt“ jeweils in Kombination mit „manuell zugewiesen“ oder „automatisch zugewiesen“ genutzt. Zusätzlich zu den Statusänderungen, verursacht durch eine der in den nächsten Abschnitten erläuterten Korrelationen, speichert die Software auch bei Bedarf nur den Hinweis darauf, dass eine Korrelation zutreffen würde, ändert den Status aber nicht. Für die externe Repräsentation freigegebene Datenbestände sollten normalerweise als „manuell zugewiesen korrekt“ gelten. Abbildung 10 veranschaulicht diesen Zusammenhang. Über die Tabelle „korrelation“ sind jeweils der kontrollierende Sensor und der Sensor, der kontrolliert wird, verknüpft. Dabei können der kontrollierende und der zu kontrollierende Sensor auch identisch sein, wenn z.B. die Korrelation eines Sensors zu sich selber für die Überprüfung des korrekten Wertebereichs abgelegt werden soll. Zu einer Korrelation können Einträge der Tabelle „grenze“ gehören. In einer „grenze“ werden die Intervalle angegeben, in denen ein zu kontrollierender Wert liegen muss, damit ihm ein bestimmter Status bzw. nur ein Hinweis zugeordnet werden kann. 2.4.2.1 Bewertung eines einzelnen Sensorwertes Zu den meisten Sensoren gibt es bestimmte grundsätzliche Schranken, in denen sich die Messwerte bewegen müssen, um als glaubwürdig zu gelten. Zu einer Einteilung in die Kategorien „korrekt“, „vielleicht korrekt“, „inkorrekt“ können zu jedem Sensor bestimmte Grenzwerte gespeichert werden. Hierbei wird unterschieden in bestimmte Fehler- und Warnbereiche. Die ph-Wertskala erstreckt sich beispielsweise über einen Bereich von 0 bis 14. Für Sensorwerte des pH-Wert-Sensors sind dabei z.B. Bereiche von 6,8 bis 7,2 üblich und liefern keinen Hinweis auf eine falsche Messung. In diesem Fall würden Messwerte in diesem Bereich als korrekt

17

2 Analyse und Systemspezifikation

Abbildung 10: ERM Sensoren und Korrelationen angesehen werden. In den Bereichen 6,3 bis 6,8 und 7,2 bis 7,7 sind Messwerte möglich, aber eher unwahrscheinlich. In diesem Warnbereich liegende Werte sollen demnach als „vielleicht korrekt“ gekennzeichnet werden. Alles außerhalb dieser Grenzen gilt als Fehlerbereich und markiert einen Wert als „nicht korrekt“. 2.4.2.2 Bewertung von Sensorwerten untereinander Gerade genannte Grenzen betreffen einen einzigen Wert ohne Korrelation zu anderen Werten desselben Sensors. Nimmt man zeitlich benachbarte Messwerte hinzu, so gilt es drei Fälle zu unterscheiden. Zum ersten bewegen sich Änderungen nur in bestimmten Bereichen. Kommt es zu extremen Ausreißern nach oben oder unten weist dies auf eine mögliche Fehlfunktion hin. Zum zweiten wird das umgekehrte Verhalten betrachtet, wenn eine Wertereihe über einen zu langen Zeitraum in gewissen Grenzen konstant ist und damit auf einen Sensorausfall hindeutet. Bei beiden Fällen wird getestet, ob die Änderung zwischen zwei benachbarten Wertepaaren in einem gewissen Warn- oder Fehlerbereich liegt. Zum letzten wird getestet und darauf hingewiesen, wenn die zeitlichen Abstände zwischen zwei Messungen gewisse Intervalle überschreiten. 2.4.2.3 Bewertung durch Korrelation zwischen den Sensoren Verschiedene Sensoren sind abhängig voneinander. Insbesondere Sensoren, die Luft- oder Wassertemperaturen im Quelltopf oder im Container messen, können Hinweise auf die Zuverlässigkeit bzw. Probleme anderer Sensoren geben. Die Datenbank ist so aufgebaut, dass beliebige Korrelationen zwischen Sensoren möglich sind. Hierbei wird unterschieden, ob es sich bei dem

18

2 Analyse und Systemspezifikation

Kontrollsensor um ein binäres Signal handelt, das nur die Zustände korrekt oder nicht liefert wie „Untergrenze Füllstandswächter bei defekter Pumpe unterschritten“ oder „Chemikalienvorrat leer“, oder ein Signal, das auch mit einem Warn- und Fehlerbereich verglichen werden muss wie oben angeführte Temperatursensoren. Die Bewertung ist dabei nur sinnvoll, wenn die Vergleichsdaten in einem gewissen Intervall um den Messzeitpunkt vorliegen. 2.4.2.4 Bewertung durch Vergleichsanalysen Die eingelesenen Daten werden im Labor analysierten Wasserproben gegenüber gestellt. Dieser Sachverhalt wird behandelt wie eine Beziehung zwischen automatischen Sensoren untereinander. Zusätzlich zu den ermittelten Werten können Informationen gespeichert werden, ob diese Messungen auch zur Bewertung anderer Daten in einem gewissen Zeitraum herangezogen werden sollen wie bei oben genannter Korrelationen zwischen Sensoren. 2.4.2.5 Bewertung durch Ereignisse Sensoren befinden sich zeitweise in Zuständen wie Wartung oder Kalibrierung oder es kommt zu einer Fehlfunktion, in denen sie keine korrekten Messwerte liefern. Teilweise liegt diese Information in den im Sensor gespeicherten Ereignislisten vor, teilweise müssen die Informationen über regelmäßige Kalibrier- sowie Reinigungszeiten oder manuelle Wartungen durch den Benutzer ins System eingespeist werden (vgl. Kapitel 2.3.3). Diese Informationen stellen eine wichtige Quelle dar, um Bewertungen zur Datenqualität machen zu können.

2.4.3 Allgemeines Alle Korrelationen, die sich auf die Validierung anhand von Regeln beziehen, die nur die Werte eines einzelnen Sensors an sich betreffen ohne Vergleich mit anderen Sensoren, werden unter dem Begriff „lokale Validierung“ zusammengefasst. Nimmt man die Korrelationen hinzu, die mithilfe von Werten anderer Sensoren oder durch Ereignisinformationen ihre Entscheidungen treffen, spricht man von „globaler Validierung“. Die endgültige Entscheidung über die Richtigkeit einer Messung liegt jedoch beim Nutzer des Systems. Damit ergeben sich die Stufen „frisch importiert“, „lokal validiert“, „global validiert“ und zum Ende „manuell validiert“, die ein Messwert im Normalfall durchläuft.

2.4.4 Messwerte und ihre Historie Jeder Messwert wird beim Import in die zu diesem Zeitpunkt gültige Hauptmaßeinheit umgerechnet, was durch die Verknüpfung der Tabellen „messwert“ und „auspraegung“ in Abbildung 11 gezeigt wird. Ein Messwert besitzt Attribute, die seinen aktuellen Validierungsstand und weitere möglicherweise irreguläre Besonderheiten speichern. Eine Änderung an den Eigenschaften eines Werte wird immer durch eine Korrelation verursacht. Jede Veränderung wird dabei in der Tabelle „historie“ aufgeführt, welche Felder zur Speicherung der Werte vor und nach der Änderung besitzt. So können zu jedem Messwert alle Änderungen im Prozessverlauf angezeigt und bei Bedarf auch revidiert werden. Weiterhin wird über die Assoziation zur Tabelle „imports“ gespeichert, aus welcher Importdatei der Wert ursprünglich stammt.

19

2 Analyse und Systemspezifikation

Abbildung 11: ERM Messwerte und Historie

20

2 Analyse und Systemspezifikation

2.4.5 Importvorgänge Jeder erfolgreiche Import in die Datenbank wird über die Tabelle „imports“ aus Abbildung 12 realisiert. Hierbei werden Attribute der importierten Datei gespeichert, sowie zusätzlich eine Verknüpfung, für welchen Container oder Sensor importiert wurde. Jedem Eintrag sind weiterhin alle beinhalteten Messwerte und erkannten Kommentare aus der Ursprungsdatei zugeordnet. Um jedem Benutzer einen Überblick über getätigte wie auch mißglückte Importversuche zu geben, wird eine Liste erfolgreicher und nicht erfolgreicher Vorgänge in der Tabelle „log“ geführt. Damit wird aufgezeigt, welche Vorgänge seit der letzten Programmnutzung durchgeführt worden sind.

Abbildung 12: ERM Importe und Importlog

2.4.6 Ereignisse Bei der Ereignisbehandlung wird unterschieden zwischen einmaligen Ereignissen und Serienereignissen. In Abbildung 13 wird dies dargestellt durch die mögliche Verknüpfung der Tabelle „ereignis“ mit „intervallbasis“. Wird ein Serienereignis erzeugt, werden für den geplanten

21

2 Analyse und Systemspezifikation

Zeitraum entsprechend viele einzelne Ereignisse erzeugt, die über einen Intervallbasiseintrag zusammenhängen. Ein einzelnes Ereignis besitzt keine Basis.

Abbildung 13: ERM Ereignisse und Ereignistypen

Ein Ereignis kann auf einem bestimmten Ereignistyp beruhen. Dies ist für zwei Aspekte erforderlich. Zum einen werden in der Tabelle „ereignistyp“ die Muster festgelegt, nach denen eine Ereignisdatei analysiert wird. Beispielsweise enthalten die Felder “starttext“ und „endetext“ die Werte „power down“ und „power up“. Wird ein solches Paar beim Parsen einer Datei entdeckt, wird ein neues Ereignis entsprechenden Typs angelegt. Zum anderen dienen Ereignistypen der Komfortsteigerung bei der manuellen Erzeugung von Ereignissen. Immer wiederkehrende Tätigkeiten wie „Container warten“ werden somit einmalig definiert und konkrete Ereigniseinträge können so durch bereits vorbelegte Felder einfacher erzeugt werden.

22

2 Analyse und Systemspezifikation

2.4.7 Benutzer Die Tabelle „benutzer“ in Abbildung 14 beinhaltet Einträge zu allen Nutzern des Programmes. Sie wird benötigt zur Zugriffskontrolle und zur Bestimmung, welcher Nutzer wann welche Prozesse durchgeführt hat. Dazu wird zu jedem Eintrag aus „historie“, „log“ und „imports“ ein Benutzereintrag gespeichert. Jeder Benutzer gehört weiterhin zu einer Organisation, die in der Tabelle „partner“ gespeichert ist. Dies soll eine mögliche Erweiterung des Rechtesystems auf Gruppen und Rollen bereitstellen, sofern dies eine höhere Benutzerzahl erforderlich machen würde.

Abbildung 14: ERM Benutzer und Partner

2.4.8 Visualisierung Das Informationssystem soll alle importierten Daten auch veranschaulichen können. Hierzu lassen sich verschiedene Sensoren gemäß Abbildung 15 zu einer Sicht kombinieren. Die Tabelle „ansicht“ enthält Attribute wie den zu betrachtenden Zeitraum oder das Intervall zur Unterteilung der tabellarischen Darstellung. Alle darzustellenden Sensoren werden durch Ansichtsbeziehungen gespeichert. In dieser Tabelle werden zusätzlich Attribute gespeichert, wie die graphische Darstellung erfolgen soll.

2.4.9 Rechtestruktur Unterschiedliche Benutzer der Software sollen nur auf bestimmte Funktionalitäten zugreifen dürfen. Dazu ist eine Zuweisung bestimmter Rechte an einen Benutzer erforderlich. Die Rechte beziehen sich immer auf einen kompletten Container. In den Gesprächen über die Granularität wurde festgestellt, dass eine Rechtezuweisung auf Sensorebene nicht erforderlich ist. Die Verbindung zwischen einem Benutzer und einem Container erfolgt nach Abbildung 16 über die Tabelle „recht“. Im Feld „rechtetyp“ wird gespeichert, welche Funktion dieses Recht dem Benutzer in der Software zugänglich macht. Zusätzlich zu diesen Möglichkeiten wird über das

23

2 Analyse und Systemspezifikation

Abbildung 15: ERM Ansichten

24

2 Analyse und Systemspezifikation

Attribut „admin“ der Tabelle „benutzer“ noch ein globales Recht zur Kontrolle über das komplette Programm eingeräumt, um auch Einstellungen zu tätigen, die sich nicht direkt auf einen Container beziehen. Für eine genauere Erläuterung der Rechtestruktur siehe Abschnitt 2.5.5.

Abbildung 16: ERM Rechtestruktur

2.4.10 Externe Darstellung Für die Darstellung der Daten auf einer Webseite wird nicht auf die Tabelle „messwert“ zugegriffen, als korrekt validierte Werte werden falls erforderlich in einer weiteren Tabelle „messwertextern“ redundant gehalten (siehe Abbildung 17). Diese Tabelle besitzt eine flache Struktur, es bestehen direkte Verknüpfungen zum Ursprungscontainer, dem Sensor und der Ausprägung, in der gespeichert wurde. Auf diese Tabelle wird über eine Webseite nur lesend zugegriffen, durch ihren Aufbau soll die Geschwindigkeit der Lesezugriffe gesteigert werden. Außerdem erhöht diese Tabelle die Sicherheit der Daten, da nicht auf die eigentliche Arbeitstabelle zugegriffen werden kann, die dadurch vor unbefugtem Zugriff geschützt bleibt.

25

2 Analyse und Systemspezifikation

Abbildung 17: ERM Externe Datentabelle

2.5 Dynamische Analyse - Prozesse Im Kapitel „Dynamische Analyse - Prozesse“ werden Abläufe und Funktionen beschrieben, die die Arbeitsschritte und Anwendung der Software repräsentieren. Die Darstellung erfolgt als ereignisgesteuerte Prozesskette (EPK). Eine EPK besteht aus Funktionen (grün, abgerundete Rechtecke), Ereignissen (rot, sechseckig) und logischen Konnektoren. Eine Prozesskette beschreibt die Schritte zur Erreichung eines bestimmten Zieles unter Berücksichtigung verschiedener Alternativwege.

2.5.1 Definition von Containern und ihren Sensoren Zur Benutzung der Software ist es erforderlich, zuerst die Containerkonfigurationen festzulegen, denn die unterste Stufe der Hierarchie ist immer der Container. Auch externe Datenlieferanten wie das LFU werden behandelt wie ein Messcontainer. Jedem Container können dann verschiedene Eigenschaften wie beispielsweise „Automatische Suche aktiv“ zugewiesen werden. Daraufhin werden zu jedem Container die zugehörigen Sensoren definiert. Jeder Sensor wiederum benötigt mindestens eine Hauptausprägung, welche optional nochmals Unterausprägungen enthalten kann.

2.5.2 Datenimport Der Import von Daten kann auf drei verschiedene Arten erfolgen. Entweder wird automatisch nach neuen Dateien gesucht oder man bestimmt neue Dateien manuell bzw. kann auch einzelne Wertereihen von Hand eintragen.

26

2 Analyse und Systemspezifikation

Abbildung 18: EPK Automatischer Import

27

2 Analyse und Systemspezifikation

2.5.2.1 Automatisierter Import Die EPK in Abbildung 18 beschreibt den Prozess des automatischen Dateiimports. Nach dem Programmstart prüft ein Timer in einer einstellbaren Periode, ob die Frist für einen neuen Suchlauf für einen Container abgelaufen ist. Wenn ja, wird im gespeicherten Datenpfad nach einer noch nicht importierten Datei gesucht. Wurde eine Datei gefunden, wird versucht, diese zu importieren. Dies wird genauer im rechten Teil der Abbildung verdeutlicht. Tritt bei der Datenanalyse eine Unklarheit auf, wird die Datei abgelehnt und es werden nur Informationen über den Versuch gespeichert. 2.5.2.2 Manueller Import Beim manuellen Import hat der Benutzer im Gegensatz zur automatischen Integration die Möglichkeit, bei Unklarheiten in den Prozess einzugreifen. Zum einen gibt es den Fall, dass eine Datei bereits importiert wurde. Falls ja, hat der Benutzer die Wahl, die Daten nochmals ohne weitere Berücksichtigung der Daten aus der alten Datei zu speichern, Werte der alten Datei mit identischem Messzeitpunkt durch neue Werte zu ersetzen oder zuerst alle alten Daten zu löschen und dann einen normalen Import durchführen. Der zweite Fall kommt vor, wenn Spalten der Datei nicht erkannt werden. Dies wird in der rechten EPK in Abbildung 19 dargestellt. Der Nutzer kann erst eine manuelle Zuordnung der Spalten zu Sensoren vornehmen. 2.5.2.3 Manuelle Eingaben Über die Integration von Dateien besteht die Möglichkeit, Werte direkt in die Software einzutragen. Dies ist besonders für den Fall manueller Labormessungen sinnvoll.

2.5.3 Datenexport 2.5.3.1 Externe Datei Das System erlaubt einen Export aller integrierten Daten in eine Datei. Die Ausgabe orientiert sich dabei an den Sichten wie in Abschnitt 2.4.8 definiert. Die dort dargestellten Daten werden an einen Exportfilter übergeben, der für die Erstellung der Datei verantwortlich ist. Ein Exportfilter kann zu jeder Zeit nachträglich hinzugefügt werden. 2.5.3.2 Präsentation im WWW Zur Bereitstellung der Daten über eine Webseite werden Messwerte aus der Arbeitstabelle in die Tabelle „messwertextern“ kopiert. Zur Auswahl, welcher Bereich kopiert werden soll, wird analog zum Dateiexport eine Sicht benutzt. Alle dort dargestellten Kombinationen können direkt in die Externtabelle kopiert werden.

2.5.4 Bewertungs- und Änderungsmöglichkeiten von Messwerten Bei jedem Importvorgang wird nach dem Speichern der Werte aus einer Datei für jeden Sensor, für den Werte importiert wurden, geprüft, ob eine lokale bzw. globale Validierung erfolgen soll (siehe Abbildung 20) und bei Bedarf entsprechend durchgeführt. Die endgültige

28

2 Analyse und Systemspezifikation

Abbildung 19: EPK Manueller Import

29

2 Analyse und Systemspezifikation

Abbildung 20: EPK Automatische Bewertung

30

2 Analyse und Systemspezifikation

Bewertung trifft der Anwender manuell. Im Nachhinein ist es immer möglich, alle Teilstücke des Validierungsprozesses nochmalig manuell zu starten, falls beispielsweise nachträglich neue Vergleichsdaten hinzugekommen sind.

2.5.5 Benutzer- und Rechteverwaltung Bei Neuinstallation des Systems steht anfangs nur ein initialer Benutzer zum ersten Login zur Verfügung. Mithilfe dieses Benutzers werden dann die Konten für die tatsächlichen User angelegt. Ein Nutzer kann entweder den globalen Status eines Administrators besitzen, der auf alle Funktionalitäten Zugriff hat bzw. eingeschränkte Rechte, unterschieden nach dem jeweiligen Container. Tabelle 1 erläutert, welches Benutzerrecht welche Funktionalität verfügbar macht. Die Spalten entsprechen einem Recht, die Zeilen geben jeweils an, welches Recht eine bestimmte Funktion beinhaltet. Generell gilt, dass ein Administrator Zugang zu allen Funktionen hat.

Cont. erstellen Cont., Sensor, Ausp. ansehen Cont., Sensoren, Ausp. edit. Importe und Ereig. ansehen Importe und Ereig. edit. Sichten ansehen Sichten und Bewert. edit. Alle Werte in Sicht zeigen

Cont. ansehen

Cont. edit.

X

X X X X

X X

Tabelle 1: Rechtematrix

31

Sichten, Bewert. edit.

Alle Werte

X X X

X

3 Systemkonstruktion - Technische Konstruktion Im Gegensatz zur Systemspezifikation, welche festgelegt, was das System können soll, wird in der Systemkonstruktion beschrieben, wie die vorgegebenen Ziele realisiert werden sollen. Sie beschreibt die Konstruktion aus technischer, implementierungsorientierter Sicht, man spricht vom IT-Konzept oder DV-Konzept. Die vorliegende Systemkonstruktion setzt sich zusammen aus diesem Kapitel und Kapitel 4. Zuerst wird in den folgenden Abschnitten die technische Konstruktion dargestellt, also der grundlegende Aufbau der Software, die Beschreibung einzelner Anwendungsschichten, die genutzten Architekturen für Datenhaltung oder Oberflächengestaltung und die verwendete technische Infrastruktur. Am Ende des Kapitels wird noch kurz auf die alternative Zugriffsmöglichkeit auf Daten über eine Webschnittstelle eingegangen.

3.1 Schichtenmodell Die Erstellung der meisten Informationssysteme erfolgt mindestens in einer Zwei-SchichtenArchitektur, geteilt in Anwendungs- und Datenhaltungsschicht. In der Anwendungsschicht sind Benutzeroberfläche und Fachkonzept in einem Baustein vereint. Die Fachkonzeptschicht „modelliert [dabei] den funktionalen Kern der Anwendung“ (Balzert, 1999, S. 372), die Datenhaltungsschicht kümmert sich um die dauerhafte Datenspeicherung. Die vorliegende Arbeit wurde in einer vierschichtigen Architektur realisiert (siehe Abbildung 21). An oberster Stelle steht die Präsentationsschicht oder GUI, welche die Benutzeroberfläche mit allen Programmfenstern, Dialogen und Menüs enthält. Eine Stufe darunter liegt die Fachkonzeptschicht, die die fachlich bedingte Programmlogik enthält. Die Fachkonzeptschicht kommuniziert wiederum nur mit der Datenhaltungszugriffsschicht. Dadurch wird der Zugriff auf die Datenhaltungsschicht abstrahiert und man gewinnt eine Unabhängigkeit vom verwendeten Datenbanksystem (DBS). Dieses wird im Schaubild durch die unterste Stufe, die Datenhaltungsschicht, repräsentiert. Als Vorteil dieses Aufbaus ergibt sich die Unabhängigkeit der Schichten untereinander, jede Schicht kommuniziert streng genommen nur mit direkt benachbarten Schichten. Somit wirkt sich eine Änderung in der Datenhaltung beispielsweise nicht auf die Oberfläche aus, da Zugriffe auf die Datenbank in der Datenhaltungszugriffsschicht gekapselt sind. Als nachteilig erweist sich die höhere Komplexität des Gesamtsystems und ein potentieller Geschwindigkeitsnachteil. Man spricht von einer flexiblen Mehr-Schichten-Architektur, wenn die GUI auch direkten Zugriff auf die Datenhaltungszugriffsschicht besitzt, was in bestimmten Fällen zu einer sinnvollen Steigerung der Flexibilität führen kann. Als Mittel zur Implementation der Schichten wurde die objektorientierte Programmiersprache Java in der Version 5.0 gewählt. Ein Java Programm wird vom Compiler nicht in einen betriebssystemspezifischen Bytecode umgewandelt, sondern in ein Zwischenformat. Es

32

3 Systemkonstruktion - Technische Konstruktion

Abbildung 21: Mehr-Schichten-Architektur existiert auf vielen Plattformen eine Laufzeitumgebung, die den Zwischencode endgültig ausführen kann. Damit ist maximale Portabilität ohne notwendiges Rekompilieren gesichert. Für weitere Ausführungen zu den Vorteilen der Programmiersprache siehe Krüger (2004, Kapitel 1) und zur Einführung in die objektorientierte Programmierung siehe Krüger (2004, Kapitel 7). In den nächsten Abschnitten wird näher auf den Aufbau der einzelnen Stufen eingegangen.

3.2 Datenhaltungsschicht Als Datenbank zur Speicherung aller vorkommenden Daten wurde die frei verfügbare Datenbank MySQL1 gewählt. Sie zeichnet sich durch eine Verfügbarkeit auf diversen Plattformen und einer weitreichenden Verbreitung aus. Sie gilt als effizientes und schnelles Produkt und verfügt in der zur Zeit stabilen Version 4.1 über Transaktionsunterstützung (siehe 3.3.3), welche zur Realisierung des Projekts erforderlich ist. Die Nutzung und Zugriffe werden bewusst einfach gehalten: Auf Möglichkeiten wie Trigger, Stored Procedures oder spezielle Fähigkeiten von MySQL wird verzicht, da sich dadurch ein Austausch des DBS am einfachsten bewerkstelligen lässt. Außerdem verfügt MySQL über kostenlose Verwaltungsprogramme wie den MySQLAdministrator2 , der Zugriff auf die Laufzeitparameter der Datenbank und Möglichkeiten zur einfachen Datensicherung bietet, oder das MySQL Control Center3 , das einen interaktiven Zugriff auf Tabellen erlaubt und ein Interface zum direkten Absetzen von SQL Kommandos bietet. Die Datenbank wurde einmal zum Entwickeln unter Windows XP genutzt und läuft auf dem Produktivsystem unter Suse Linux 9.0. Zur Kommunikation mit den darüberliegenden Schichten kommt MySQL Connector/J desselben Herstellers wie MySQL zum Einsatz. Er

1

verfügbar unter http://www.mysql.com http://www.mysql.com/products/administrator 3 http://www.mysql.com/products/mysqlcc 2

33

3 Systemkonstruktion - Technische Konstruktion

dient dazu, die JDBC Aufrufe in für MySQL verständliche Kommandos zu transformieren. Dazu mehr im folgenden Abschnitt.

3.3 Datenhaltungszugriffsschicht Um von einem Java Programm auf eine relationale Datenbank zuzugreifen, wird die Java Database Connectivity API benutzt. Sie ermöglicht es, eine Verbindung zu einem relationalen Datenbanksystem aufzubauen und reine SQL Statements an die Datenbank zu schicken, die zuvor von der Software erzeugt wurden. Wird dabei ein „select“ Befehl zur Abfrage einer Datenbank abgesendet, wird eine Ergebnismenge, das sogenannte „Resultobjekt“, zurückgeliefert, das einen Ausschnitt der Tabelle repräsentiert. Man kann über die Ergebnisse iterieren und auf jedes einzelne Attribut eines Ergebnisses zugreifen. Diese Vorgänge laufen noch auf einem eher niedrigen Abstraktionslevel ab und widersprechen dem objektorientierten Paradigma. In der objektorientierten Programmierung steht das Konzept der Objektklassen und Objektinstanzen im Vordergrund. Bei einer Klasse handelt es sich um einen Bauplan, der die Attribute und Funktionen eines Objektes beschreibt. Unter der Instanz einer Klasse versteht man eine konkrete Ausprägung einer Klasse, die nach diesem Bauplan erzeugt wurde. Einzelne Objekte können untereinander in Beziehung stehen, sie bilden dann einen Objektgraph. Wünschenswert wäre eine direkte Speicherung des Objektgraphen und seiner Knoten als dauerhafte oder persistente Objekte. Obwohl auch objektorientierte Datenbanken existieren, ist es durchaus von Vorteil, eine relationale Datenbank zu benutzen. Man muss je nach Art und Einsatzzweck abwägen, welche Art von Persistenzrealisierung genutzt wird. Wegen der großen Zahl an Einträgen, beispielsweise in der Messwert- oder Historientabelle, und einer insgesamt eher flachen Hierarchie des Datenmodells überwiegen hier die Vorteile der relationalen Speicherung. Daraus resultiert jedoch die Problematik in der Verknüpfung zwischen relationaler und objektorientierter Modellierung. Abbildung 22 veranschaulicht diese Problematik. Auf der linken Seite im oberen Teil befindet sich eine Definition der Klasse Container mit ihren Attributen und Methoden und darunter zwei Objektinstanzen vom Typ Container mit jeweiliger Belegung der Attribute mit konkreten Werten, wie sie in Java genutzt werden. Auf der rechten Seite ist die relationale Datenbanktabelle Container dargestellt mit den beiden Einträgen, ihren Primärschlüsseln und Eigenschaften. Dort sollen die Attribute dauerhaft gespeichert werden, während eine Objektinstanz nur während der Laufzeit des Programmes existiert. Die Darstellung der Klasse und Instanzen erfolgt nach UML Notation (vgl. Balzert, 1999, S. 228-254). Es stellt sich die Frage, wie aus Einträgen der Tabelle Container Instanzen der Klasse Container erzeugt werden. Um dieses Problem zu lösen, wird eine Schicht zwischen die Objekte der Fachkonzeptebene und der Datenbank angelegt, die die direkten SQL Statements vor Objekten des Fachkonzepts abschirmt und die Persistenzverwaltung abstrahiert. Man spricht hierbei von objektrelationalem Mapping. Zuerst wurde hierbei eine Eigenimplementierung in Betracht gezogen. Es stellte sich jedoch heraus, dass diese Aufgabe schnell an Komplexität und Umfang zunahm. Daher habe ich entschieden, das Persistenzframework Hibernate4 einzusetzen. 4

http://www.hibernate.org

34

3 Systemkonstruktion - Technische Konstruktion

Container -Bezeichnung : String -Suchintervall : Integer +erstelleContainer() +loescheContainer() +getBezeichnung() : String +setBezeichnung(ein/aus bezeichnung : String) +getSuchintervall() : Integer +setSuchintervall(ein/aus intervall : Integer)

Container 1 : Container Bezeichnung : String = Container Niedaltdorf Suchintervall : Integer = 4

Id Standort Suchintervall 1 Container Niedaltdorf 4 2 Container Attert 2

Container 2 : Container Bezeichnung : String = Container Attert Suchintervall : Integer = 2

Abbildung 22: Klasse Container, Containerinstanzen und Tabelle Container Hibernate realisiert den gewünschten Übergang von Tabellen zu Java-Objekten. Das Framework arbeitet generell mit allen von JDBC unterstützen Datenbanken zusammen und bietet vielfältige Möglichkeiten, die Transformation zu definieren und Objekte persistent zu machen und mit ihnen zu arbeiten. In den nächsten Abschnitten werden einige wichtige Aspekte von Hibernate beleuchtet. Hierzu zählen die Definition der Mappingregeln, die Abfragemöglichkeiten und die Transaktionsunterstützung.

3.3.1 XML Mapping Um die Regeln für die oben gewünschte Transformation zu definieren, wird in Hibernate für jede Klasse und ihre korrespondierende Tabelle eine XML Datei angelegt, die die entsprechenden Verknüpfungsregeln enthält. Unter der Extensible Markup Language (XML) versteht man eine Auszeichnungssprache, die es möglich macht, strukturierte Informationen nach eigenen Regeln als reine Textdatei abzulegen. Eine XML Datei hat ein ähnliches Aussehen wie eine HTML Datei, jedoch mit benutzerdefinierten Tagelementen. Sofern bereits eine relationale Datenbank oder Javaklassen bestehen, bietet Hibernate verschiedene Hilfsmittel, um die vorhandenen Strukturen zu extrahieren und das Mapping sowie das jeweils fehlende Ziel der Transformation automatisch zu generieren. Im vorliegenden Fall wurde die Datei jedoch manuell erzeugt. Abbildung 23 zeigt einen Ausschnitt der Mappingdatei für die Klasse Container. Die Datei ist folgendermaßen zu interpretieren: Im umschließenden „class“-Tag wird definiert, dass die Klasse „Container“ auf die Tabelle „container“ abgebildet werden soll. Innerhalb dieses Tags wird als Erstes der Schlüssel zur Objektidentifizierung angelegt. In der Tabelle enthält die Spalte „containerId“ den Primärschlüssel, das passende Attribut in der Javaklasse trägt die Bezeichnung „Id“. Der Wert „identity“ im Tag „generator“ besagt, dass die Datenbank beim Anlegen eines neuen Objekts selbstständig einen neuen Primärschlüssel generieren soll. Danach folgen zwei „property“-Tags, die die restlichen Attribute definieren. Die Tabellenspalte

35

3 Systemkonstruktion - Technische Konstruktion





Abbildung 23: Beispielauszug für eine XML Mappingdatei

36

3 Systemkonstruktion - Technische Konstruktion

„bezeichnung“ speichert den Inhalt des Attributs „Bezeichnung“ der Klasse. Über das Attribut „type“ wird angegeben, um welchen Datentyp es sich handelt.





Abbildung 24: Beispielauszug aus der Container- und Sensor-Mappingdatei zur Assoziation Um eine Assoziation zwischen zwei Tabellen zu erzeugen, wie in Kapitel 2.4 beschrieben, kann man vorgehen wie in Abbildung 24 gezeigt. Der obere Tag stammt aus der Containerdatei und besagt, dass zu einem Container beliebig viele Sensoren gehören können und dies über den Fremdschlüssel „containerId“ in der Tabelle Sensor gespeichert wird. Im unteren Teil wird die umgekehrte Richtung aus Sicht eines Sensors definiert. Diese beiden Definitionen ermöglichen zum einen, von einem Container die Menge seiner Sensoren abzufragen und umgekehrt von einem Sensor zu erfahren, zu welchem Container er gehört. Eine Verknüpfung wäre schon mit einer der beiden Definitionen erzeugt, die Abfrage wäre dann aber nur in einer Richtung durchführbar.

3.3.2 Abfragen Hibernate bietet mehrere Möglichkeiten eine Suchanfrage abzusetzen, um bestimmte Objekte aus der Datenbank zu selektieren. Zum einen besitzt Hibernate eine als Hibernate Query Language bezeichnete Anfragesprache. Der in Abbildung 25 gezeigte Ausdruck ist auf folgende Art und Weise zu lesen: „Suche alle Objekte des Typs Auspraegung geordnet nach dem Attribut Bezeichnung, welche zu einem Sensor gehören, der im Container mit der Id :containerId definiert ist, und deren Start und Ende um einen Zeitpunkt „:zeitpunkt“ liegen. „:containerId“

37

3 Systemkonstruktion - Technische Konstruktion

und „:zeitpunkt“ sind dabei Parameter, die dynamisch während der Laufzeit gesetzt werden. Im Anschluss daran wird die Anfrage ausgeführt.



Abbildung 25: Beispielauszug zur Definition eines HQL Ausdrucks

Criteria crit = createCriteria(); crit.add(Expression.eq("Sensor", sensor)); crit.add(Expression.eq("Typ", korrelationTyp)); ArrayList list = (ArrayList)crit.list();

Abbildung 26: Beispielauszug zur Benutzung eines Criteria Objekts

Eine weitere Möglichkeit bietet Hibernate mit der query by criteria API. Ein Beispiel zeigt Abbildung 26. Zuerst wird ein Criteria Objekt erzeugt. Diesem werden dann verschiedene Expressions als Filterbedingungen hinzugefügt und letztendlich wird die Anfrage ausgeführt, die eine Liste von Korrelationen zurückliefert. QBC besitzt gegenüber HQL einen eher objekt“orientierten Ansatz und bietet den Vorteil, dass bereits während des Kompilierens getestet wird, ob den Expressions auch passende Datentypen als Argument mitgeliefert werden, während HQL Ausdrücke erst zur Laufzeit analysiert werden. Eine genaue Beschreibung der vielfältigen Anwendungsmöglichkeiten der Anfragesprachen findet sich in Bauer, King (2004, Kapitel 7).

3.3.3 Transaktionen Unter einer Datenbanktransaktion versteht man eine Menge von gemeinsam auszuführenden Befehlen an eine Datenbank. Wie man in Schaubild 27 sieht, hat eine Transaktion immer zwei mögliche Ausgänge, entweder sie gelingt, oder sie schlägt fehl. Die Teile einer Transaktion werden entweder alle zusammen korrekt ausgeführt oder gar nicht. Dies bedeutet, sofern eine Teiloperation misslingt, werden alle bisherigen Änderungen der Transaktion wieder rückgängig gemacht, es erfolgt ein sogenannter rollback. Für den Fall des Gelingens erfolgt ein commit, die Änderungen werden endgültig in der Datenbank sichtbar. Man spricht in diesem Zusammenhang davon, dass eine Transaktion immer atomar abläuft.

38

3 Systemkonstruktion - Technische Konstruktion

Abbildung 27: Ablauf einer Transaktion (Quelle Bauer, King, 2004) Hibernate unterstützt diese Funktionalität in der Hibernate Transaction API. In ihr werden alle nötigen Methoden zur Transaktionsabwicklung bereitgestellt. Abbildung 28 gibt ein Beispiel für die Nutzung der API in Java.

3.3.4 Hibernate Synchronizer Zur Programmierung der Software wurde die Open Source IDE Eclipse eingesetzt. Diese IDE zeichnet sich duch ihren modularen Aufbau aus, durch den es problemlos möglich ist, externe Erweiterungen hinzuzufügen. Auf diesem Gebiet findet eine sehr rege Entwicklung statt. Zur Einbindung des Hibernate Frameworks in Eclipse existiert mit dem Hibernate Synchronizer ein Plugin, das die Arbeit mit Eclipse sehr erleichtert, da hiermit automatisch aus den Mappingdateien Javaklassen generiert werden können. Weiterhin erstellt das Plugin diverse Hilfsfunktionen zur Arbeit mit dem Framework, wie z.B. die Funktion „findAll“, die eine Liste aller gespeicherten Instanzen einer Klasse liefert. Abbildung 29 zeigt grob die erzeugten Strukturen als Klassendiagramm mit einigen exemplarischen Attributen und Funktionen am Beispiel der Containerklasse. Die gelb markierten Klassen stehen dabei für eigene Erweiterungen zur Verfügung, alle anderen sollen nicht von Hand erweitert werden, da der Hibernate Synchronizer diese bei Änderungen an der Mappingdatei immer neu erstellt. Alle Klassen auf der linken Seite tragen das Kürzel DAO in ihrem Namen. Die Abkürzung bedeutet in diesem Fall Data Access Objects und bedeutet, dass Instanzen dieser Klassen alle datenbankbezogenen Aufrufe an die Hibernate API enthalten, die wiederum die Anweisungen per JDBC an die Datenbank weitergibt. Die Klasse „_BaseRootDAO“ auf der linken Seite bildet die oberste Schicht der Hierarchie, dort werden die für alle DAOs allgemeingültigen Funktionen definiert. Über die Klasse „_RootDAO“, in der eigene allgemeingültige Funktionen definiert werden können, ist dann die Klasse „BaseContainerDAO“ abgeleitet. Dies bedeutet, dass „BaseContainerDAO“ über alle Attribute und Funktionen der beiden über ihr liegenden Klassen verfügt und zusätzliche Elemente enthält, die sich nur auf das Containerhandling beziehen. Von dieser Klasse ist wiederum „ContainerDAO“ abgeleitet, welche z.B. die benutzerdefinierte Funktion „getAlleContainer“ beinhaltet. Auf der rechten Seite ist die Hierarchie der eigentlichen Containerklasse abgebildet. Auf unterster Stufe steht die Klasse Container. Diese enthält beispielsweise die selbst erstellte

39

3 Systemkonstruktion - Technische Konstruktion

// Erstelle eine neue Datenbanksession Session session = new Session(); // Reserviere Variable t für neue Transaktion Transaction t = null; try{ t = session.beginTransaction(); // fuehre die Datenbankoperationen aus // falls kein Fehler auftritt, uebernehme Aenderungen t.commit(); } // fange alle Fehler ab catch (Exception e){ // mache Aenderungen rueckgaengig t.rollback(); } // schliesse Session unabhängig davon // ob commit oder rollback ausgefuehrt wurde finally{ session.close() }

Abbildung 28: Beispielauszug zur Nutzung der Transaction API

40

3 Systemkonstruktion - Technische Konstruktion

Abbildung 29: Hibernate Synchronizer - erzeugte Klassen

41

3 Systemkonstruktion - Technische Konstruktion

Funktion „zaehleImporte“. Die Klasse „Container“ ist abgeleitet von der übergeordneten Klasse „BaseContainer“. Dort werden die „set“- und „get“-Methoden für alle im Mapping enthaltenen Attribute definiert. Die rechte Seite enthält keine direkten Aufrufe an die Hibernate API.

3.4 Fachkonzeptschicht Die Fachkonzeptschicht enthält die fachlich bezogene Programmlogik. Bedingt durch den Klassenaufbau, den der Hibernate Synchronizer liefert, bietet sich die Lösung, die erforderliche Funktionalität in den Klassen der untersten Hierarchiestufe (Abbildung 29) zu integrieren. In diesem Beispiel bilden dann Instanzen von „ContainerDAO“ und „Container“ die Fachkonzeptschicht, die darüberliegenden Klassen Teile der Datenhaltungszugriffsschicht.

3.5 Präsentationsschicht Der Präsentationsschicht werden alle Programmteile zugeordnet, die für die Darstellung der Benutzeroberfläche zuständig sind. Dazu zählen alle Fenster, Dialogboxen, Menüs, Buttons, Eingabefelder, Tabellen oder sonstige Bauelemente (Widgets) zusammen mit der zugehörigen Ereignisbehandlung. Unter der Ereignisbehandlung versteht man das Abarbeiten der Benutzereingaben wie beispielsweise ein Doppelklick auf ein Fensterelement oder das Drücken einer bestimmten Tastenkombination. Eine Grafikbibliothek, die die gerade genannten Widgets bietet und deren Ereignisbehandlung unterstützt, wird als widget toolkit bezeichnet. Mit der Programmiersprache Java wird das Swing Toolkit mitgeliefert. Die Komponenten des Swing Toolkits werden als lightweight components bezeichnet. Dies bedeutet, dass ein Swing Programm auf allen von Java unterstützten Plattformen ein identisches Aussehen besitzt, da alle Fensterelemente von Swing selbst gezeichnet werden ohne Nutzung der vom Betriebssystem bereitgestellten nativen Widgets. Vorteil davon ist die volle Plattformunabhängigkeit. Nach anfänglicher Implementierung in Swing habe ich mich jedoch entschieden, das alternative Standard Widget Toolkit (SWT) zu benutzen. Zur Erleichterung der Oberflächengestaltung wurde das Produkt „SWT-Designer“ 5 der Firma Instantiations erworben.

3.5.1 SWT Die vorliegende Software wurde mithilfe der Open Source IDE Eclipse entwickelt, die ebenfalls in Java programmiert ist. Die Programmierer der IDE haben zur Entwicklung ihrer IDE ein neues Grafiktoolkit als Alternative zu Swing entwickelt, da sie mit dessen Leistung nicht zufrieden waren. Größter Unterschied zu Swing liegt in der Nutzung nativer Widgets des Betriebssystems. Ein SWT Programm ist von einem Programm, das rein für eine bestimmte Plattform entwickelt wurde, nicht zu unterscheiden. Es existieren zu Swing zwar gewisse Pakete, um das Aussehen des jeweiligen Betriebssystems nachzuahmen, doch eine hundertprozentige Anpassung gelingt damit nicht, es existieren immer noch Unterschiede im „look-andfeel“ zwischen einem Swing- und einem nativen Programm. Aufgrund der guten Erfahrungen und der gezeigten Geschwindigkeit in Eclipse, wurde Swing durch SWT ersetzt. Als Nachteil 5

http://www.swt-designer.com

42

3 Systemkonstruktion - Technische Konstruktion

könnte man anfügen, dass damit keine absolute Plattformunabhängigkeit mehr gegeben ist, da jedes Betriebssystem eine eigene SWT Version erfordert, die die Verbindung von Java zu den Betriebssystemwidgets herstellt. Es existieren jedoch Portierungen für mindestens zwölf Plattformen, darunter alle Windowsversionen seit Windows 98, Linux mit den Bibliotheken Motif oder GTK2 und Mac OS X. Ein Javaprogramm an sich muss für die Benutzung auf einer anderen Plattform nicht angepasst werden, es muss nur das passende SWT verfügbar sein.

3.5.2 JFace Das Standard Widget Toolkit bietet eine Vielzahl von Widgets, Layoutmöglichkeiten und Gestaltungselementen. Die API von SWT erlaubt einen direkten Zugriff auf die Methoden der Widgets. So existiert z.B. eine Funktion, um einer Tabelle eine neue Spalte oder Zeile hinzuzufügen. JFace legt eine Abstraktionsebene über die SWT API und fügt Elemente hinzu, die der Model-View-Controller Architektur folgen. Unter der MVC Architektur versteht man die Trennung der Daten (model), der Präsentation der Daten (view) und der Manipulation der Daten (controler).

LableProvider : TableLableProvider

ContentProvider : TableContentProvider

View

Imports 1 : Imports Dateiname : String = Cont1_031128.CSV Groesse : Integer = 34123

CellEditor : TableCellEditor

Controler

Model Abbildung 30: Model-View-Controler Architektur

43

3 Systemkonstruktion - Technische Konstruktion

Abbildung 30 gibt ein Bespiel, wie JFace die MVC Architektur umsetzt. Die Tabelle, die importierte Dateien anzeigen soll, wird nicht direkt manipuliert. Ohne JFace müsste man manuell die Spalten der Tabelle erzeugen und jeder einzelnen Zelle ihren Inhalt zuweisen. In JFace dagegen weist man der Tabelle über ihren ContentProvider zu, welche Importe angezeigt werden sollen. Der LabelProvider kümmert sich darum, welche Attribute aus einem Importobjekt, das das Modell darstellt, in welcher Spalte dargestellt werden. Editiert der Benutzer ein Element der Tabelle, so wird die Änderung über einen CellEditor am Modell durchgeführt.

3.5.3 Forms API Seit Version 3 beinhalt Eclipse die neue Forms API. Neben neuen Layouts und einem modernen, flachen Design der Widgets enthält die API eine Vereinfachung in der Benutzung von Haupt- und zugehörigen Unterformularen. Ein solcher master/details block besteht einerseits aus einem Baumwidget, dem „master“-Teil, und mehreren Unterformularen, dem „details“-Teil, die die Attribute des im Baum angewählten Astes anzeigen. Die API bietet vorgefertige Klassen, die sich leicht an die eigenen Bedürfnisse anpassen lassen. Ein Beispiel wäre der Windows Explorer, der in der linken Hälfte den Festplatteninhalt als Baum darstellt und in der rechten Hälfte je nach angewähltem Verzeichnis dessen Inhalt. Für eine genauere Einführung siehe Eclipse Forms Programming Guide (2004).

3.5.4 Draw2d Die Eclipse Bibliothek Draw2d dient zum freien Zeichnen von geometrischen Objekten. Sie wird im vorliegenden Fall genutzt, um eine graphische Darstellung der Messwerte zu verwirklichen.

3.6 Hilfsklassen Im Abschnitt „Hilfsklassen“ werden einige Programmelemente beschrieben, die sich nicht klar einer genannten Schichten zuordnen lassen.

3.6.1 Mehrsprachigkeit Eine Forderung der Konzeption war die Verfügbarkeit der GUI in mehreren Sprachen. Dazu wurden alle Strings, die im Programmcode der Oberfläche vorkamen, in eine separate Datei extrahiert und durch einen Funkionsaufruf der Form Messages.getString("Schluesselwert") ersetzt. Es existiert momentan eine deutsche und eine englische Begriffsdatei. Über die Klasse „Messages“ wird je nach Einstellung im Benutzerprofil bzw. der Ländereinstellung des Betriebssystems entschieden, aus welcher Sprachdatei der Rückgabestring geliefert wird. Eine neue Sprachdatei läßt sich im Programmverzeichnis unter „gui“ ablegen.

44

3 Systemkonstruktion - Technische Konstruktion

3.6.2 Rechtehandling Die Rechtekontrolle wurde direkt in die GUI Klassen integriert. Dort werden je nach Rechtvergabe an den aktuell angemeldeten Benutzer Funktionen ausführbar geschaltet oder nicht. Mit dem Test if (StaticContent.activeUser.viewContainer(cont) || \\ StaticContent.activeUser.editContainer(cont) || \\ StaticContent.activeUser.isAdmin()) wird beispielweise getestet, ob der aktive Benutzer am Container „cont“ Lese- oder Schreibrechte bzw. Administratorstatus besitzt.

3.6.3 Filterklassen In diesem Abschnitt wird erklärt, wie man der Software nachträglich neue Filter hinzufügen kann, um auch bisher unbekannte Dateiformate importieren zu können. Normalerweise müssen in Java alle genutzten Klassen zum Zeitpunkt der Kompilierung bekannt sein. Diese Einschränkung umgeht die Java Reflection API. Mit ihr ist es möglich, Klassen dynamisch nachzuladen. Die Software nutzt diese Möglichkeit und arbeitet mit allen Klassen zusammen, die das Interface in Abbildung 31 implementieren. Für die Software ist es unerheblich, wie der neue Importfilter im Detail arbeitet, er muss sich nur an die im Interface aufgestellten Definitionen halten. So kann man jedem Container und jedem Sensor nachträglich einen neuen Filter zuordnen.

3.6.4 Logging Alle Debugausgaben und Ausgaben, die vom Hibernate Framework stammen, werden mithilfe der Log4J API6 verarbeitet. Log4J ermöglicht es durch eine Einstellungsdatei, die Anzahl der Debugausgaben zu steuern. Man kann bestimmen, ab welcher Schwelle eine Ausgabe getätigt wird und wohin die Ausgabe erfolgen soll. Als Ziel sind beispielsweise die Konsole oder ein Datenpfad wählbar. Log4J besitzt weiterhin vielfältige Möglichkeiten zur Ausgabeformatierung.

3.6.5 Sonstige Hilfsklassen Die Hilfsklasse „Util“ enthält alle Funktionen zur Verwaltung von Ressourcen wie Schriftarten, Farb- oder Bildobjekten. Außerdem existieren Hilfsfunktionen zum Speichern eines dargestellten Graphen in einer Bilddatei sowie verschiedene Funktionen zur Datumsumrechnung.

3.6.6 Test und Evaluierung der Software Um die beste Zuverlässigkeit der Software zu gewährleisten, wurde zu Anfang der Implementierung gleichzeitig zu einer programmierten Funktion eine entsprechende Testfunktion implementiert. Mithilfe des JUnit Frameworks, einer API zur Qualitätskontrolle von Java Programmen, ist es dadurch möglich, nach Änderungen an der Software automatisierte Tests 6

http://logging.apache.org/log4j/docs/index.html

45

3 Systemkonstruktion - Technische Konstruktion

public interface IImportsParser { // Gib Dateiname an und analysiere public void start(String fileName); // Kommentare public ArrayList getComments(); // Liste mit erkannten Daten public ArrayList getData(); // Liste mit Zeitpunkten public ArrayList getTimes(); // Datum der letzten Dateiaenderung public Calendar getFileLastModified(); // Dateiname public String getFileName(); // Mutterverzeichnis public String getFileParent(); // Dateigroesse public long getFileSize(); // Dateiname mit Pfad public String getFilePath(); // erkannte Sensorueberschriften public String[] getSensorInfo(); }

Abbildung 31: Importfilter-Interface

46

3 Systemkonstruktion - Technische Konstruktion

ablaufen zu lassen. Diese prüfen, ob Änderungen an einer Stelle vielleicht Fehler an anderer Stelle verursachen, die man als Fehlerort möglicherweise garnicht in Betracht gezogen hat. Die Implementierung dieser Testfunktion kostet jedoch sehr viel Zeit, da ihr Umfang z.T. größer ist als der Umfang der zu testenden Funktion. Daher musste von dieser sinnvollen Herangehensweise Abstand genommen werden. Die Funktionen der Software wurde jedoch gegen Ende von mehreren Personen manuell durchgetestet. Wenn weitere Fehler auftauchen, werden sie entsprechend behoben.

3.7 Webschnittstelle Um die gesammelten und bereinigten Daten einem größeren Benutzerkreis zugänglich zu machen, wurde neben der Standalone-Software eine Webseite gebaut, die Zugriff auf die Elemente der externen Datentabelle bietet. Die Seite arbeitet passwortgeschützt und ermöglicht die Auswahl eines Zeitraums und einer Kombination von Sensoren. Die Ausgabe erfolgt tabellarisch bzw. in Form einer SVG Datei. Bei SVG handelt es sich um eine Sprache zur Beschreibung zweidimensionaler Vektorgrafiken in XML. Alternativ wird ein Download als PDF angeboten. Zur technischen Umsetzung wurde der in Python geschriebene Web Application Server Zope7 benutzt zusammen mit der Erweiterung Plone8 . Zope dient als Basis zur Erstellung beliebiger Webapplikationen und bietet eingebaute Möglichkeiten zum Sessionhandling und zur Rechteverwaltung und läßt sich durch eigene Module einfach erweitern. Es existiert eine mächtige Templatesprache zur dynamischen Generierung von Webseiten. Der Content Management Aufsatz Plone dient hier als Basis zur Generierung der eigenen Seiten, da er bereits ein lauffähiges Usermanagement beinhaltet und die Seitenerstellung durch leichte Anpassbarkeit an eigene Vorstellungen vereinfacht sowie Konformität zu den neuesten Standards der Webseitengestaltung beachtet. Außerdem bietet diese Lösung eine sehr gute Grundlage, um die mit wenig Funktionalität ausgestattete Webschnittstelle in Zukunft zu erweitern.

7 8

http://www.zope.org http://www.plone.org

47

4 Systemkonstruktion Anwendungskonstruktion Im Kapitel „Systemkonstruktion - Anwendungskonstruktion“ wird im Gegensatz zur technischen Konstruktion näher auf die konkreten, anwendungsspezifischen Bausteine der Software eingegangen. Die meisten Klassen zur Implementierung der Hauptoberfläche benutzen die in Abschnitt 3.5.3 vorgestellte master/details Architektur. Die Oberfläche wird durch ein Karteireiter-Widget strukturiert. Über die Reiter am oberen Rand des Programmfensters gelangt man zu den einzelnen Unterseiten, die im Folgenden kurz vorgestellt werden. Eine genaue Erläuterung der Funktionsweise befindet sich in der Programmhilfe, die über die Fragenzeichensymbole im ganzen Programm verfügbar ist.

4.1 Login Wenn das Programm gestartet wird, erscheint ein Loginfenster dargestellt in Abbildung 32.

Abbildung 32: Login Dialog

48

4 Systemkonstruktion - Anwendungskonstruktion

Der Benutzer muss sich hier am System mit seiner Loginkennung und seinem Passwort anmelden. Außerdem kann der Benutzer sein vom einem Administrator angelegtes initiales Passwort ändern. Somit wird sichergestellt, dass nur berechtigte Personen die Daten einsehen dürfen und dass der Urheber aller Arbeiten mit importierten Dateien und Messwerten nachverfolgt werden kann.

4.2 Karteireiter Container und Sensoren Im Karteireiter „Container und Sensoren“ werden alle statischen Einstellungen für Container, Sensoren und deren Ausprägungen getätigt. In Abbildung 33 erkennt man den Aufbau nach Haupt- und Unterformular. Auf der linken Seite wird eine Baumhierarchie von Containern und Sensoren dargestellt. Der Typ eines Sensor ist am entsprechenden Symbol erkennbar. Ein Sensor der nicht mehr aktuell im Container arbeitet, wird schwarz-weiß dargestellt. Über ein Kontextmenü hat der Nutzer die Möglichkeit, neue Geräte hinzuzufügen und die Anzeige zu sortieren oder zu filtern. Je nach Wahl eines Objektes im Baum wird das rechte Unterformular gewechselt. Über die drei Symbole am rechten, oberen Rand kann man die Darstellung so ändern, dass die Unterteilung des Fensters von senkrecht auf waagerecht wechselt bzw. der Unterformularbereich maximiert wird.

Abbildung 33: Containerdetails

49

4 Systemkonstruktion - Anwendungskonstruktion

4.2.1 Container Abbildung 33 zeigt gleichzeitig des zum einem Container gehörende Unterformular. Es können hier Einstellungen getätigt werden wie den Pfad, in dem nach neuen Importdateien gesucht werden soll, welcher Importfilter genutzt wird bzw. ob die automatische Suche für diesen Container aktiv ist.

4.2.2 Sensoren In Abbildung 34 ist das Unterformular bei Auswahl eines Sensors dargestellt. Im Detailsbereich kann man ähnliche Einstellungen wie auf der Containerseite tätigen. In der unteren Hälfte sieht man den Bereich, in dem man die Regeln zur Validierung der Messwerte dieses Sensors eintragen kann. Aufgeklappt sind die Teilstücke zur Eingabe der Wertebereiche und Status, der entsprechend zugeordnet werden soll, und zur Eingabe der Abhängigkeit von einem anderen Sensor. Eine neue Abhängigkeit kann durch einfaches Herüberziehen eines Sensors aus der Navigation per Drag and Drop in die Sensorliste am unteren Rand erstellt werden.

Abbildung 34: Sensordetails

50

4 Systemkonstruktion - Anwendungskonstruktion

4.2.3 Ausprägungen Abbildung 35 zeigt einmal in der Navigation, dass unter einem Sensor eine Hauptausprägung vorhanden ist, die selber wiederum eine alternative Ausprägung besitzt. Im rechten Unterformular zur gewählten Ausprägung existieren Felder zur Eingabe der Umrechnungsfaktoren in die übergeordnete Maßeinheit. Wichtig ist auch des Feld „Muster“. Der dort gespeicherte String wird genutzt, um in einer Importdatei zu erkennen, welche Spalte diese Ausprägung enthält.

Abbildung 35: Ausprägungdetails

4.3 Karteireiter Sichten Über den Karteireiter „Sichten“ in Abbildung 36 werden Kombinationen von Sensoren angelegt, die man darstellen möchte. Es lassen sich Start- und Endzeitpunkt definieren, die Intervalleinteilung der tabellarischen Darstellung sowie weitere Einstellungen. Im unteren Teil sieht man die Liste, die die zu dieser Sicht gehörenden Sensoren enthält. Man kann auch hier neue Sensoren einfach per Drag and Drop in die Liste herüberziehen. Dort werden zusätzlich Einstellungen getätigt, die die graphische Darstellung betreffen.

51

4 Systemkonstruktion - Anwendungskonstruktion

Abbildung 36: Karteireiter Sichten

4.4 Karteireiter Bewertung und Visualisierung Auf der nächste Seite „Bewertung und Visualisierung“ erfolgt die hauptsächliche Tätigkeit. Hier wird eine Sicht sowohl tabellarisch als auch graphisch dargestellt. Der Nutzer erhält Informationen über alle Statuszustände und Validierungshinweise der dargestellten Messwerte. In der ausgeblendeten Sektion unten links werden alle Details eines Wertes zusammen dargestellt sowie seine Änderungshistorie. Über ein Kontextmenü eröffnen sich dem Benutzer die Funkionalitäten, Werte manuell zu ändern, sie durch Teile einer anderen Spalte zu ersetzen sowie alle Statusattribute von Hand zu setzen. Er kann Werte filtern, sie vor Veränderung schützen und eine erneute lokale oder globale Validierung anstossen. Außerdem kann man an dieser Stelle die angezeigte Tabelle in eine Datei exportieren oder sie in die Tabelle zur Darstellung im Internet verschieben. Im rechten Teil des Fenster erfolgt die Darstellung der Wertetabelle als Graph. Man kann stufenlos ein- und auszoomen, die dargestellten Graphen ausdrucken oder sie als Grafikdatei abspeichern. Zur Erleichterung der Navigation kann man optional ein Übersichtsfenster einblenden, dass den gerade angezeigten Ausschnitt im Überblick zeigt.

52

4 Systemkonstruktion - Anwendungskonstruktion

Abbildung 37: Karteireiter Bewertung und Visualisierung

4.5 Karteireiter Import Der folgende Karteireiter „Import“ beinhaltet alle Funktionen im Zusammenhang mit dem Einfügen neuer Werte in die Datenbasis. Man hat dort die Möglichkeit, manuell Werte einzugeben bzw. eine vorhandene Datei für einen Container oder Sensor zu importieren. Abbildung 38 zeigt einen Schritt im Importassistent, der den Anwender durch den Importvorgang leitet. Es wurde an dieser Stelle festgestellt, dass bereits eine Datei mit gleichem Namen für den Container importiert wurde. Daher wird abgefragt, wie mit den vorhandenen Werten weiterverfahren werden soll.

53

4 Systemkonstruktion - Anwendungskonstruktion

Abbildung 38: Karteireiter Import

4.6 Karteireiter Ereignisse Der Karteireiter „Ereignisse“ gibt einen Überblick über die einen Container oder Sensor betreffenden Ereignisse. Es existieren Funktionen, um neue Ereignisdateien einzulesen bzw. einzelne Einträge von Hand zu erstellen. Schaubild 39 stellt ein Serienereignis dar, das besagt, dass einmal in der Woche von 10 bis 12 Uhr eine Wartung durchgeführt wird und so alle in dieser Zeit ermittelten Werte des Ammoniumsensors als falsch anzusehen sind.

4.7 Karteireiter Meldungen Die Liste im Reiter „Meldungen“ (siehe Abbildung 40) gibt dem Nutzer einen Überlick über die zuletzt ausgeführten Importversuche. Er erhält Informationen darüber, wer wann eine Datei eingefügt hat oder ob diese automatisch importiert wurde und ob der Importvorgang erfolgreich war.

54

4 Systemkonstruktion - Anwendungskonstruktion

Abbildung 39: Karteireiter Ereignisse

4.8 Karteireiter Benutzer Im darauffolgenden Karteireiter „Benutzer“ wird die Oberfläche zur Benutzer- und Rechteverwaltung dargestellt (vgl. Abbildung 41). In der linken Hälfte erkennt man die Hierarchie der Projektpartner und den zum Partner gehörenden Benutzern. Im rechten oberen Teil kann man das Login, Passwort und die bevorzugte Sprache der Benutzeroberfläche einstellen. Darunter befindet sich die Tabelle, mit der man dem Benutzer gewissen Rechte an den Containern einräumen kann.

4.9 Karteireiter Administration Der vorletzte Teilstück „Administration“ dient dazu, globale Programmeinstellungen zu tätigen. Im obersten Teil des Fensters in Abbildung 42 kann man die gewünschte Größe des Programmfensters festlegen oder die standdardmäßige Platzverteilung zwischen Haupt- und Unterformularen auf den Karteireitern. Die beiden mittleren Teilstücke ermöglichen das nachträgliche Hinzufügen von neuen Import- und Exportformaten. Eine neue Klasse muss dazu im Programmverzeichnis unter „importfilter“ bzw. „exportfilter“ abgelegt und danach ein neuer Eintrag in der jeweiligen Liste erzeugt werden. Nach Neustart der Software steht der neue Filter zur Auswahl zur Verfügung.

4.10 Karteireiter Externe Datentabelle Der letzte Reiter „Externe Datentabelle“ aus Abbildung 43 zeigt eine Tabelle aller Werte an, die zur Repräsentation nach außen freigegeben sind. Einzige Funktionalität auf dieser Seite ist die Auswahl eines anderen Datumsbereichs zur Anzeige und ein Löschen von Einträgen.

55

4 Systemkonstruktion - Anwendungskonstruktion

Abbildung 40: Karteireiter Meldungen

Abbildung 41: Karteireiter Benutzer

56

4 Systemkonstruktion - Anwendungskonstruktion

Abbildung 42: Karteireiter Administration

Abbildung 43: Karteireiter Externe Datentabelle

57

5 Zusammenfassung und Ausblick 5.1 Zusammenfassung In dieser Arbeit wurde ein Umweltinformationssystem zur automatischen Verarbeitung und Verwaltung von Gewässermessdaten geschaffen. Dazu wurde in mehreren Interviews eine Anforderungsanalyse erstellt, die aufzeigt, welche Funktionalität das Informationssystem beinhalten soll. Als wichtigste Aufgaben haben sich dabei herauskristallisiert, dass das System beliebige Eingabedateien erfassen, die enthaltenen Messwerte anhand bestimmter Regeln auf ihre Plausibilität prüfen und als integrierte Datenbasis zur weiteren Analyse mit statistischen Softwarepaketen dienen soll. Diese Anforderungen entsprechen gerade den grundlegenden Eigenschaften eines Data Warehouse. Um das Projekt umzusetzen, wurde zuerst ein Datenmodell entwickelt, das alle erforderlichen Datenstrukturen abbildet. Gleichzeitig wurden die vorkommenden Prozesse analysiert und mit diesen Erkenntnissen das von der konkreten Technik unabhängige Fachkonzept entwickelt. Aus den Vorgaben des Fachkonzepts wurde in der Systemkonstruktionsphase eine Entscheidung über die verwendete Programmiersprache, die Art der Datenhaltung und die Auswahl einer Grafikbibliothek getroffen. Nach dieser Entscheidung wurden die konkreten Klassen zur Umsetzung geplant. Als nächster Schritt erfolgte die eigentliche Implementierungs- und danach die Testphase der Software. Zusätzlich zu dem implementierten Paket wurde eine Schnittstelle geschaffen, um über einen Internet Browser Zugriff auf einen Teil der Daten zu erhalten.

5.2 Ausblick Aus technischer Sicht stehen als nächster möglicher Schritt ein Update auf aktuellere Versionen der benutzten Bibliotheken an. Im Juni wird die endgültige Version der Eclipse IDE in Version 3.1 freigegeben werden und damit auch eine neue Version von SWT/JFace. Dies kann zu einer weiteren Verbesserung der Stabilität und Ausführungsgeschwindigkeit führen. Ebenso ist gegen Ende der Arbeit das objekt-relationale Mapping-Framework Hibernate in der stabilen Version 3 erschienen. Vom fachlichen Standpunkt her gesehen ist eine Ausdehnung der Software in Richtung eigener Analysefunktionen denkbar, die bisher komplett fehlen. Dadurch würde der Schritt der Übernahme der Daten in andere Systeme zwecks Analyse teilweise überflüssig und die Arbeit weiter erleichtern. Als zweiten Punkt bietet sich eine Erweiterung der Webschnittstelle an, so dass auch über diesen Weg Änderungen am Datenbestand möglich werden anstatt nur lesend darauf zugreifen zu können.

58

Literaturverzeichnis Arnold, Ken; Gosling, James (2002): The Java Programming Language, 2.Auflage. Addison-Wesley, München, 2002. Balzert, Heide (1999): Lehrbuch der Objektmodellierung. Analyse und Entwurf. Spektrum Akademischer Verlag, Heidelberg, 1999. Bass, Len; Clements, Paul; Kazman, Rick (2003): Software Architecture In Practice, 2.Auflage. Addison-Wesley Longman, Amsterdam, 2003. Bauer, Andreas; Günzel, Holger (Hrsg.)(2004): Data-Warehouse-Systeme. Architektur, Entwicklung, Anwendung. dpunkt.verlag, Heidelberg, 2004. Bauer, Christian; King, Gavin (2004): Hibernate in Action. Manning, Greenwich, 2004. Baur, Werner (1980): Gewässergüte bestimmen Und beurteilen. Paul Parey, Hamburg Berlin, 1980. Beck, Kent; Gamma, Erich (2003): Contributing To Eclipse. Addison-Wesley, München, 2003. Beck, Horst Philipp, Klein, Christina, Meyer, Angelika (2004): LIFE000 ENV/D/000337 Ferngesteuerte Kontrolle des eutrophierenden Eintrags aus diffusen Quellen in der Region SAAR-LOR-LUX. Endbericht August 2004. Universität des Saarlandes, Institut für Anorganische und Analytische Chemie und Radiochemie, Saarbrücken, 2004. Bernstein, Michael R.; Robertson, Scott (1998): Zope Bible. Addison-Wesley, München, 1998. Burke, Eric M.; Coyner, Brian m. (2003): Java Extreme Programming Cookbook. O´Reilly, Sebastopol, 2003. Celko, Joe (1999): Data and Databases: Concepts in Practice. Morgan Kaufmann Publishers, San Francisco, 1999. Cordts, Sönke (2002): Datenbankkonzepte in der Praxis. Addison-Wesley, München, 2002. Cornell, Gary; Horstmann, Cay S. (2001): Core Java 2. Prentice Hall, New Jersey, 2001. Dasu, Tamrapami; Johnson, Theodore (2000): Exploratory Data Mining and Data Cleaning. Academic Press, San Diego, 2000.

59

Literaturverzeichnis

Bibliographisches Institut & F. A. Brockhaus AG (Hrsg.) (2003): Der Brockhaus Naturwissenschaft und Technik CD-ROM, Bibliographisches Institut & F. A. Brockhaus AG, Mannheim und Spektrum Akademischer Verlag, Heidelberg, 2003. Dunham, Margaret: Data Mining Introductory And Advanced Tropics. Prentice Hall, New Jersey, 2003. Eckstein, Robert; Loy, Marc; Wood, Dave (1998): JAVA Swing. O´Reilly, Sebastopol, 1998. Eclipse Forms Programming Guide (2004), http://dev.eclipse.org/viewcvs/index. cgi/\%7Echeckout\%7E/pde-ui-home/working/EclipseForms/EclipseForms.html, letzter Zugriff 04/2005. Elliott, James (2004): Working with Hibernate in Eclipse, http://www.onjava.com/pub/ a/onjava/2004/06/23/hibernate.html, letzter Zugriff 04/2005. Friedl, Jeffrey E.F. (2003): Reguläre Ausdrücke, 2. Auflage. O´Reilly, Köln, 2003. Gallardo, David; Burnette, Ed; McGovern, Robert (2003): Eclipse In Action. Manning, Greenwich, 2003. Gehtland, Justin; Tate, Bruce A. (2004): Better, Faster, Lighter Java. O´Reilly, Sebastopol, 2004. Guelcue, Ceki (2002): log 4j, The Complete Manual. Prentice Hall, New Jersey, 2002. Hand, David; Mannila, Heikki; Smyth, Padhraic (2001): Principles of Data Mining. MIT Press, Cambridge, 2001. Holzner, Steve (2004): Eclipse. O´Reilly, Sebastopol, 2004. Professur für Geodäsie und Geoinformatik: Lexikon Geoinformatik, http://www. geoinformatik.uni-rostock.de/einzel.asp?ID=1705, letzter Zugriff 04/2005. Universität Rostock. Kantardzic, Mehmed (2003): Data Mining: Concepts, Models, Methods and Algorithms. Wiley, New Jersey, 2003. Knudsen, Jonathan (1999): Java 2D Graphics. O´Reilly, Sebastopol, 1999. Krüger, Guido (2004): Handbuch der Java Programmierung, 4. Auflage. Addison-Wesley, München, 2004. Mark, Humphries; Hawkins, Michael W.; Dy, Michelle C. (2003): Data Warehousing Architecture and Implementation. Prentice Hall, New Jersey, 2003. Matthews, Mark; Cole, Jim; Gradecki, Joseph D. (2003): MySQL and Jata Developer´s Guide. Wiley, Indianapolis, 2003.

60

Literaturverzeichnis

Moore, Bill ; Dean, David; Gerber, Anna; Wagenknecht, Gunnar; Vanderheyden, Philippe (2004): Eclipse Development Using The Graphical Editing Framework And The Eclipse Modeling Framework Moore. ibm.com/redbooks, Greenwich, 2004. Oak, Harshad (2004): Pro Jakarta Commons. Apress, Berkeley, 2004. Ponniah, Paulraj (2002): Data Warehousing Fundamentals. Wiley & Sons, New York, 2002. Pyle, Dorian (2003): Data Preparation for Data Mining. Manning, Greenwich, 2003. Reese, George (2000): Database Programming with JDBC and Java, 2.Auflage. O´Reilly, Sebastopol, 2000. Robinson, Matthew; Vorobiev, Pavel (2002): Swing Second Edition. Updated for J2SE 1.4. Hungry Minds, New York, 2002. Scarpino, Matthew; Holder, Stephen; Ng, Stanford; Mihalkovic, Laurent (2005): SWT/JFace in Action. Manning, Greenwich, 2005. Siedersleben, Johannes (2003): Software-Technik. Praxiswissen für Softwareingenieure. Hanser, München Wien, 2003. Warner, Rob; Harris, Robert (2004): The Definitive Guide To SWT And JFace. Apress, Berkeley, 2004.

61

Literaturverzeichnis

Sonstige Internetadressen

http://java.sun.com Programmiersprache Java von Sun http://www.binamics.com/hibernatesynch Hibernate Synchronizer für Eclipse http://www.eclipse.org Open Source IDE Eclipse http://www.hibernate.org Persistenzframework Hibernate http://www.javabuch.de Frei verfügbare Ausgabe des Handbuchs der Java-Programmierung http://logging.apache.org/log4j/docs/index.html Log4J Logging API http://www.mysql.com Freie Datenbank MySQL http://www.mysql.com/products/administrator MySQL Administrator http://www.mysql.com/products/mysqlcc MySQL Control Center http://www.plone.org Content Management System Plone http://www.python.org Programmiersprache Python http://www.swt-designer.com SWT GUI Design Plugin für Eclipse http://www.zope.org Wep Application Server Zope Alle genannten Adressen wurden zuletzt im April 2005 abgerufen.

62

A Anhang A.1 Systemvoraussetzungen Die Software wurde auf einem Rechner AMD Athlon 3000+ CPU und 1 Gb RAM und auf einem Rechner mit Pentium 4 mit 3 Ghz und 512 Mb Hauptspeicher entwickelt. Dabei lief die MySQL Datenbank während der Implementierung gleichzeitig auf denselben Rechnern. Unter dieser Konstellation gab es keine Geschwindigkeitsprobleme. Der dedizierte Datenbankserver läuft als Produktivsystem mit einer fast ebenso schnellen Pentium 4 CPU und 512 Mb RAM. Die Clientsoftware läuft im produktiven Betrieb unter einem älteren Windows 2000 Rechner, jedoch liegt auch hier die Geschwindigkeit im akzeptablen Bereich. Die Software wurde auf dem Entwicklungsrechner in einer Betriebssystemsimulation unter Windows 2000 und Suse Linux 9.2 gestartet, auch hier war ein problemloses Arbeiten möglich. Insgesamt wird empfohlen, die Client Software auf einem Rechner mit mindestens 128 Mb Hauptspeicher auszuführen, um ein flüssiges Arbeiten zu ermöglichen. Die Hardwarevoraussetzungen für den Datenbankserver liegen im Ermessen des betreuenden Administrators in Abhängigkeit der in Zukunft zu erwarteten Datenmenge. Als Softwarevorraussetzungen muss genereller Zugriff auf ein von JDBC und Hibernate unterstütztes relationales Datenbanksystem mit Transaktionsunterstützung bestehen, um die zentrale Datenspeicherung zu gewährleisten. Als Voraussetzung auf den Clientrechnern ergibt sich die Forderung, dass eine aktuelle Java 5.0 Runtime Environment zur Verfügung steht sowie eine passende Version der SWT Bibliothek. Eine Version zu Windows, Linux GTK2 und Motif liegt der Software bei.

A.2 Installation Zur Installation der Software genügt es, das entsprechende Verzeichnis auf die Festplatte zu kopieren und unter Windows mit der Datei „run.bat“ bzw. unter Linux mit der Datei „run.sh“ das Programm zu starten. Um Verbindung zur Datenbank aufnehmen zu können, ist ein Anpassen der Datenbankkonfigurationsdatei „hibernate.config.xml“ direkt im untersten Programmverzeichnis vorzunehmen, in der die Adresse des Servers, ein zugriffsberechtiger Nutzer und der datenbankspezifische JDBC Treiber eingestellt wird. Ausserdem existiert dort die Datei „log4j.properties“, mit der die Ausgabe der Debuginformationen kontrolliert werden kann.

63

A Anhang

A.3 Datenbankkonfiguration Um die Datenbankstruktur auf dem Server anzulegen, ist eine neue, leere Datenbank mit einem Benutzer, der volle Lese- und Schreibrechte besitzt, anzulegen. Dies muss datenbankabhängig vom Administrator durchgeführt werden. Diese Daten werden in einer Clientinstallation in der Datenbankkonfigurationsdatei eingetragen. Daraufhin können mit dem mit mitgelieferten Hilfstool „AdminDB“ die neuen Tabellen in der Datenbank angelegt werden.

A.4 Datensicherung und Wartung Die Datensicherung und Wartung der Datenbank liegt in der Hand des Systemverwalters. Im vorliegenden Fall muss der Administrator darauf achten, dass die InnoDB Parameter von MySQL je nach Auslastung der Datenspeicherdatei angepasst werden. Ein Backup der Daten ist hier über das Programm „MySQL Administrator“ möglich. Ansonsten erfordern die Wartung, Anpassung der Laufzeitparameter und eine systematisches Backupvorgehen entsprechende Kenntnisse des Administrators über das genutzte Datenbanksystem.

64