3.6.1 WARM - Model

Folgende Pakete gehören dazu:

• de.ipk.agbi.warm.db.*
• de.ipk.agbi.warm.properties.*

Das Model von WARM teilt sich in zwei Klassen auf: DBObject.java und Model.java. Beide befinden sich im Paket de.ipk.agbi.warm.db.*. Model.java stellt Methoden zur Datenmanipulation und zur Datenbeschaffung bereit. Die Klasse DBObject.java verwaltet die Datenbankverbindung und beinhaltet Methoden für das Absenden von SQL-Befehlen. Die Idee ist, dass der Datenbankzugriff soweit wie möglich abstrahiert wird. Das eigentliche Model soll sich nicht damit beschäftigen wie eine Anfrage an die Datenbank zu richten ist. Es stellt nur die SQL-Abfrage zusammen und übergibt sie DBObject.java. Dieses kümmert sich um eine Verbindung zur Datenbank und setzt den übergebenen Befehl ab. Als Rückgabewert stehen mehrere Möglichkeiten zur Verfügung. Es kann die Menge der verarbeiteten Zeilen oder das Ergebnis in Form eines Java ResultSet zurück gegeben werden. DBObject.java übernimmt außerdem die Fehlerbehandlung.

Tritt ein Fehler bei der Anfrage an das DBMS auf, wird ein Fehlercode generiert und an Model.java zurückgegeben. Listing 3.2 gibt einen Einblick.

Eine weitere Möglickeit zur Interaktion mit der Datenbank sind vorgefertigte SQL-Abfragen. Sie stehen in einer Konfigurationsdatei (Properties- Datei) und können bei Bedarf geholt werden. Alle nötigen Anfragen zur Bearbeitung der Rechteverwaltung stehen in der Datei db.properties. Durch die Properties-Datei kann WARM flexibler auf Änderungen reagieren. Die SQL-Abfragen können verändert werden ohne in den Quellcode gehen zu müssen und damit ein erneutes Übersetzen zu erzwingen. Der allgemeine Aufbau ist eine Schlüssel = Wert Zuweisung. Ein Auszug ist in Listing 3.3 zu sehen.

Die Klasse Model.java bildet die Informationen im VPD Schema ab. Dazu werden die Daten über DBObject angefordert. Bei der anschliessenden Aufbereitung entstehen Java-Objekte. Die Klasse TreeData.java repräsentiert zum Beispiel die strukturelle Abhänigkeit der Nutzer zu Gruppen und umgekehrt. Dazu speichert Model.java das Ergebnis einer Connect-By-Prior-Abfrage in einem zweidimensionalen Stringarray ab. Die Connect-by-Prior-Abfrage (Listing lst:connectby) wird an die Tabelle T003_SUBJECT_TREE gestellt und findet mittels rekursiven SELECT Anfragen einen Abhänigkeitsgraphen. Die Ausgabe ist eine Tabelle, die in einzelne Level unterteilt ist. Der Begriff Level kann ähnlich den einzelnen Schritten einer BFS Suche auf dem Abhänigkeitsgraphen verstanden werden. Für weitere Informationen siehe [4].

Ein weiteres Beipiel ist die Klasse RightTableData.java. Sie speichert alle nötigen Informationen für die Darstellung der Tabellenrechte ab. Den Zugang zu den Daten bilden Getter und Setter Methoden. Die einzelnen Rechte werden in Hashtabellen gespeichert. Als Schlüssel dient entweder der Wert des Primärschlüssel bei Tupelrechten oder der Nutzername bei Tabellenrechten. Weitere Getter und Setter Methoden gibt es für

• die Filterkriterien der einzelnen Spalten.
• die Variablen des Paging.
• den Tabellennamen.
• den Tabelleninhalt.
• die Information welche Spalten einen nicht literalen Datentyp besitzen.

Die im Abschnitt 3.5 gezeigte Darstellungsweise der Tabellenrechte verlangt zum einen den Zugriff auf das ausgewählte Datenbankschema mit seinen Tabellen und zum anderen den Zugriff auf das Rechteschema PDW_SECURE. D.h. es sind immer zwei Datenbankverbindungen nötig, weil aus Sicherheitsgründen das Rechteschema von anderen Schemata abgegrenzt ist und umgekehrt. Aus diesem Gründ erzeugt Model.java zwei Objekte vom Typ DBObject.java. Das eine wird mit dem ausgewählten Schemanutzer initialisiert und das Andere mit den Verbindungsparametern für PDW_SECURE. Außerdem wird der Applikationskontext der Schemanutzerverbindung auf den VPD-User "'admin"' gesetzt.

Die Klasse Model.java übernimmt zusätzlich zur Datenaufbereitung auch die Datenmanipulation. Dafür besitzt sie Methoden, die Veränderungen in PDW_SECURE vornehmen. Listing lst:manipVPD zeigt einige Beispiele.