Schritt-für-Schritt: Konvertieren einer Klasse

Folgende Schritte sind für die Definition einer Konvertierung zu erledigen:

  1. Die Zielklasse der Konvertierung (obj) auswählen.
  2. Eine Quelltabelle (q), deren Daten für die Konvertierung benutzt werden sollen, auswählen.
  3. (optional) einen Filter definieren.
  4. Eine Aktualisierungsstrategie für die Konvertierung festlegen.
  5. Die Konvertierung möglichst genau beschreiben.
  6. Konvertierungen für die Standardfelder definieren.
  7. Die Konvertierung durchführen und das Ergebnis kontrollieren.

Diese Schritte werden im Folgenden anhand des Beispiels durchgegangen. Am Ende des Kapitels findet sich ein Schema des Ablaufs der Konvertierung.

Voraussetzungen

  • Als Grundlage einer Objektkonvertierung muss eine Quelltabelle existieren, die mit Daten gefüllt ist. Im vorliegenden Beispiel liegt eine solche Quelltabelle vor, wie im Tutorial zum Rohdatenimport beschrieben.
  • Außerdem muss eine Klasse definiert worden sein.

Start

Ausgangspunkt ist das Menü der Klasse "Gemeinden", für welche die Konvertierung angelegt werden soll.

Es folgt eine Übersicht über bereits definierte Konvertierungen. Dabei werden neben Objektkonvertierungen auch Konvertierungen für Sachattribute und Verbindungen angezeigt, die mit dieser Klasse zusammenhängen. Die Übersicht ist aktuell leer.

Mittels "create new object conversion" kann eine neue Objektkonvertierung gestartet werden.

1. Die Zielklasse der Konvertierung (obj) auswählen

Wie in 0. bereits deutlich wurde, ist die Zielklasse dieser Konvertierung die Klasse Gemeinden, d.h. es wird nun darum gehen, einzelne Klassenobjekte aus einer noch festzulegenden Quelltabelle zu erzeugen.

Sie ist im Formular als "Class" bereits gesetzt, ebenso ihre Quelle (hier als "Source").

Zur Klasse Gemeinden mit der ClassId 100 gehört datenbankseitig die Objekttabelle bsr0000000900100. Einige der wichtigsten Standardfelder, sind im folgenden schematisch abgebildet. Aktuell ist die Tabelle leer, da noch keine Konvertierung ausgeführt, ja noch nicht mal eine definiert wurde.

Die Objekttabelle bsr0000000900100, schematisch dargestellt
Die Objekttabelle bsr0000000900100, schematisch dargestellt

2. Eine Quelltabelle (q), deren Daten für die Konvertierung benutzt werden sollen, auswählen

Als nächstes muss eine Quelltabelle für die Konvertierung ausgewählt werden. Dies geschieht durch ein Dropdown-Menü im Feld "Source Table". Im Dropdown sind sämtliche in Simplex4Data verfügbaren Quelltabellen aufgelistet.

An dieser Stelle wird die Quelltabelle q_00000000900008 ausgewählt, ein Beispieldatensatz von destatis, dessen Import im Artikel zum Rohdatenimport beschrieben wurde. Sie ist die Datenlieferantin der Konvertierung, aus ihr sollen Gemeindeobjekte erzeugt werden (d.h. ihre Zeilen sollen Zeilen in der Objekttabelle werden).

Spalten dieser Tabelle können innerhalb der gesamten Definition der Konvertierung mittels "q.[spaltenname]" referenziert werden (vgl. z.B. den Filter).

Einige der für das folgende relevanten Spalten sind im folgenden schematisch abgebildet, die Tabelle hat erheblich mehr Zeilen als hier zu sehen.

Die Quelltabelle q_00000000900008 mit ihren ersten Zeilen, schematisch dargestellt
Die Quelltabelle q_00000000900008 mit ihren ersten Zeilen, schematisch dargestellt

3. (optional) einen Filter definieren

Bei der Objektkonvertierung wird die Quelltabelle zeilenweise eingelesen und versucht, aus jeder Zeile ein Objekt der Zielklasse zu erzeugen. Mittels des Filters auf "q" können Regeln festgelegt werden, um bestimmte Zeilen zu überspringen.

Für die Objektkonvertierung zu Gemeinden sollen nur die Zeilen herangezogen werden, die auch tatsächlich Daten zu Gemeinden enthalten (und nicht etwa zu Landkreisen oder Bundesländern) . Deswegen wird der Filter auf "q.gemeinde is not null" gesetzt. Damit werden alle Zeilen, die für die Spalte "gemeinde" keinen Wert aufweisen, von der Konvertierung ausgenommen. Im der abgebildeten Tabellenausschnitt sind das die Zeilen Nr.1, 2, 4 und 6.

4. Eine Aktualisierungsstrategie für die Konvertierung festlegen

Zuletzt muss auch für Verbindungen eine Aktualisierungsstrategie ausgewählt werden, die für die zukünftige Verwaltung der Daten relevant ist, siehe dazu den Artikel zum Datenmodell, in dem die Aktualisierungsstrategien beschrieben und erklärt werden.

Für diese Konvertierung wird der default B1, C2, D2 and archived A1, C1 gewählt, aus folgenden Gründen:

  • Es kann davon ausgegangen werden, dass künftige Aktualisierungen einen vollständigen neuen Datensatz enthalten (d.h. den dann gültigen Stand aller dann existierenden Landkreise bzw. Gemeinden abbilden). Deswegen sind nicht im neuen Stand enthaltene Objekte sicher nicht mehr aktuell.
  • Da es sich um sehr basale Objekte mit potentiell vielen Verbindungen handelt, ist eine Archivierung nicht mehr aktueller Objekte dem Weglöschen vorzuziehen, da dabei wichtige Informationen verloren gehen können.

5. Die Konvertierung möglichst genau beschreiben

Es stehen die Felder "Name" und "Comment" zur Verfügung, um die Konvertierung zu beschreiben. Um langfristig den Überblick zu behalten, lohnt sich eine aussagekräftige Beschreibung. Diese beiden Felder sind u.a. in der Übersicht aller Konvertierungen zu einem Objekt (vgl. oben, Abschnitt 0) zu sehen. gerade wenn mehrere Konvertierungen definiert werden (was aus verschiedenen Gründen sinnvoll ist und häufig passiert), sind diese beiden Felder wertvoll, um die Konvertierungen auseinander halten zu können.

Ausgefüllt sieht die Oberfläche nun folgendermaßen aus:

6. Konvertierungen für die Standardfelder definieren

In der Klassenkonvertierung werden in der Klassendefinition beschriebenen Standardfelder aus den Quellstrukturen befüllt. Dazu wird nun - in derselben Syntax wie für "Filter" - für jedes Standardfeld eine Regel aufgestellt, wie es zu befüllen ist.

Es müssen nicht alle Standardfelder befüllt werden, ebenfalls können Standardfelder auch nur für manche Objekte befüllt werden und für andere nicht.

Für Felder, die nicht befüllt werden, weil es (a) keine Regel zur Befüllung definiert wird oder (b) die Regel für die aktuelle Zeile der Quelltabelle kein Ergebnis liefert, wird automatisch der PostgreSQL-Datentyp null eingetragen, um zu markieren, dass zu ihnen keine Informationen vorliegen.

Einzig und allein das Standardfeld "ndx" muss für jedes einzelne Objekt gesetzt werden, da es eine eindeutige Identifizierung des Objekts ermöglichen muss.

Im vorliegenden Beispiel werden die Felder folgendermaßen befüllt:

Die Konvertierung wird gespeichert und erscheint nun in der bisher leeren Liste der Konvertierungen für die Klasse Gemeinden. Sie ist an ihrem Namen und der ausgewählten Quelltabelle zu erkennen. Wie die Übersicht ebenfalls zeigt, sind mit ihr keine Attributs- oder Verbindungskonvertierungen verbunden.

7. Die Konvertierung durchführen und das Ergebnis kontrollieren

7.1. Durchführen, Prozessergebnis der Konversion

Durch Anklicken der Auswahl neben dem Button "Convert all" öffnet sich die Möglichkeit, "Convert objects only". Diese wird hier genutzt. Für den vorliegenden Fall wäre sie streng genommen nicht nötig, da keine Attributs- oder Verbindungskonvertierungen mit der Objektkonvertierung verbunden sind.

Das Interface leitet auf eine neue Seite um, die das Ergebnis der durchgeführten Objektkonvertierung anzeigt:

Die Angaben haben folgende Bedeutung:

  • source count: So viele Zeilen hat die Quelltabelle.
  • target count: So viele Zeilen hat die Objekttabelle, nachdem die Konversion gelaufen ist, d.h. so viele Gemeindeobjekte gibt es nun im Simplex4Data.
  • converted objects: So viele Objekte der Zielstruktur wurden neu eingelesen ("insert"), aktualisiert oder neu eingelesen ("upsert"), durch Aktualisierungen überschrieben und als altes Ergebnis archiviert ("archive")

Daraus lassen sich u.a. folgende Sachverhalte ablesen:

  • Da der target count  exakt dem "upsert"-Wert entspricht, war die Objekttabelle vor der Ausführung der Konvertierung leer. Alle nun im Simplex4Data enthaltenen Gemeindeobjekte stammen aus dieser einen Konvertierungsausführung.
  • Für 16072 - 10997 = 5075 Zeilen der Quelltabelle wurden keine Objekte angelegt. Das liegt im vorliegenden Fall daran, dass sie durch den gesetzten Filter aussortiert wurden.
  • Es wurden 0 existierende Gemeindeobjekte archiviert, was nicht überrascht, da es bisher keine Gemeindeobjekte gab.

Eine tiefergreifende Qualitätsanalyse kann von diesen Ergebnissen ausgehen und sie weiter vertiefen.

7.2. fertige Gemeindeobjekte

Im Klassenmenü kann über den Knopf "Betrachten" eine Tabellenansicht der aktuellen Objekte der Klasse angezeigt werden.

Beispiel: Detaillierter Ablauf der Konvertierung

Um das Beschriebene noch einmal zu veranschaulichen, hier ein schematischer Ablauf, wie die Konvertierung der ersten Elemente der Quelltabelle mit der oben definierten Konvertierung abläuft:

1. Start

Die Objekttabelle ist zu Beginn leer, denn die Klasse ist neu definiert und es wurde noch keine Konvertierung durchgeführt. Die Quelltabelle steht zur Verfügung, im folgenden wird je Iteration eine Zeile der Quelltabelle herangezogen.

2. Iteration 1

Die erste Zeile der Quelltabelle passiert den Filter nicht. Dementsprechend wird kein Objekt der Zielklasse angelegt.

3. Iteration 2

Auch die zweite Zeile der Quelltabelle passiert den Filter nicht. Dementsprechend wird kein Objekt der Zielklasse angelegt.

4. Iteration 3: ndx

Die dritte Zeile passiert den Filter, nun wird ein Gemeindeobjekt angelegt.

Das Objekt erhält als ndx einen Wert, der nach genau definierten Regeln aus fünf Spalten der Quelltabelle zusammengesetzt wird.

5. Iteration 3: nam

Weiter erhält das entstehende Objekt als nam einen Wert, der direkt aus einer Spalte der Quelltabelle übernommen wird.

6. Iteration 3: typ

Weiter erhält das entstehende Objekt als typ den Wert "Stadt". Dieser wird nicht direkt aus einer Spalte der Quelltabelle übernommen, stattdessen sind in der Konvertierung des Feldes "typ" mehrere Konstanten (unter anderem "Stadt") eingetragen, aus denen abhängig von der Spalte "textkennzeichen" der Quelltabelle eine ausgewählt wird.

7. bisheriges Ergebnis

Als Ergebnis der ersten drei Iterationen ist ein Eintrag in die Objekttabelle entstanden, d.h. es wurde ein Objekt angelegt, die Gemeinde "Brunsbüttel, Stadt". Es schließen sich so viele Iterationen an, wie die Quelltabelle weitere Zeilen hat.