BVA-System

Auch wenn die Arbeit am Administrationtool zu den unangenehmeren Programmieraufgaben gehört, so ist diese trotzdem sehr wichtig. Schließlich können damit administrative Aufgaben erledigt werden, ohne das man ein „Datenbankguru“ sein muss. In den letzten Wochen habe ich mich um eine Funktion gekümmert, die ich bisher schlichthin einfach vergessen bzw. nicht gebraucht hatte: das Löschen einer BVASystem-Datenbank. Aber wie immer wurde auch dieses mal aus einer (aus datenbanktechnischer Sicht) Kleinigkeit ein größeres Unterfangen.

Datenbankstruktur löschen

Aus Benutzersicht habe ich einen neuen Dialog geschaffen, in dem das zu löschende Datenbankschema ausgewählt werden kann. Natürlich mit einer Sicherheitsfrage, damit eine noch benötigte Datenbank gelöscht wird. Die Daten lassen sich nach dem Löschen nämlich nicht wieder herstellen.  Bis hier war alles kein Problem und recht schnell implementiert. Arbeit machte dann das eigentliche Löschen. Vor allem, weil die Funktion gleich 3 mal für die Datenbanken Oracle, Firebird und MySQL implementieren musste. Zum Glück konnte ich allerdings einen Teil der Funktionen nutzen, mit denen ich Datenbanken aktualisiere. Es existiert nun also für jeden Datenbanktyp ein Löschscript, welches mit dem Administrationstool ausgeführt werden kann. Ein kleiner Nachteil der Vorgehensweise ist allerdings, das nur aktuelle Datenbankschemas gelöscht werden können. Um ältere Strukturen zu löschen, muss diese erst auf die neuste Datenbankversion aktualisiert werden.

Ausblick

Neben der Programmiererei habe ich in der letzten Woche damit begonnen das BVASystem verstärkt zu testen. Einige Fehler habe ich dabei bereits gefunden und zum Teil auch schon korrigiert. Viel interessanter ist dabei allerdings, das man dabei auch Funktionen entdeckt, die nicht da sind, aber irgendwie schon benötigt werden. Vor mir auf dem Schreibtisch habe ich eine Liste liegen, wo ich mir diese Funktionen kurz skizziert habe. Lasst euch überraschen, was ich davon in der nächsten Zeit umsetzen werde,

Jetzt ist es endlich auch möglich Lesezeichen auf Ordner in der Datenbank zu setzten und zu benutzen. Es war nochmal einiges an Arbeit notwendig um die Funktion zu implementieren. Problem war, das die Einträge im Datenbankbaum mit einer einzelnen ID verknüpft sind. Dadurch ist es nämlich nicht möglich, auf die Elternknoten des Eintrages zu schließen. Bei einer Pfadangabe,  die einen Ordner auf der Festplatte beschreibt, ist dies hingegen ohne Probleme möglich. Daher habe ich mich entschlossen, für die Datenbank eine ähnliche Struktur aufzubauen.

Lesezeichen im Datenbank-Modus

Ein einzelnes Lesezeichen für einen Datenbank-Ordner sieht wie folgt aus:

[{436AFE34-ABED-40ED-B50C-BD11069673E7}]

TYP=DB

CAPTION=12.2014

TREEITEM=DBDatumRoot\DBDatumJahr:60\DBDatumMonat:133\

Der eigentlich interessante Eintrag ist die Zeichenkette hinter dem Schlüssel „TREEITEM“. Diese sieht einer Pfadangabe recht ähnlich. Der erste Teil DBDatumRoot entspricht quasi einer Laufwerksangabe und entspricht hier dem Wurzelknoten des Aufnahmedatum-Zweiges. Der zweite Eintrag „DBDatumJahr:60“ entspricht einem Jahreseintrag im Baum. 60 ist dabei die Datenbank-ID des dazugehörigen Datensatzes. Der letzte Eintrag steht dementsprechend für einen Monatseintrag im Baum, der die ID 133 besitzt. Würde das Lesezeichen auf einem Tageseintrag liegen, würde hier noch ein weiterer Eintrag folgen.

Ausblick

Als nächstes habe ich mir vorgenommen, einige Änderungen am Administrationstool vorzunehmen. Zum einen fehlt dort bisher die Möglichkeit, ein komplettes BVASystem Datenbankschema zu löschen und zum zweiten plane ich eine weitere Datenbankaktualisierung. Diese benötige ich für die Umsetzung einiger geplanter Funktionen. Für die erste Teilaufgabe habe ich auch bereits die erste Aufgabe abgearbeitet: Die Scriptdateien zum Löschen eines Datenbankschemas habe ich erstellt und in die Installationssoftware integriert.

So langsam macht sich bei mir die Erleichterung breit, da ich gerade eben das komplette alte Modul, welches für die Worker-Datenbankfunktionen genutzt wurde, aus dem Projekt entfernt habe. Es sind nun also alle Datenbankfunktionen auf die generalisierten Datenbankkomponenten umgestellt. Die letzten beiden Tasks, der Bildimport und das Löschen von Bildern, waren allerdings noch zwei schwierige Baustellen. Beide Tasks bestehen aus einer Vielzahl von einzelnen SQL-Befehlen. Beim Bildimport kamen neben der Speicherung der ganzen Daten noch die automatischen Zuordnungen mit Hilfe des Entscheidungsbaumes dazu. Beim Löschen der Bilder liegt die Komplexität in der Aktualisierung der Schlagworte. Mit jedem gelöschten Bild muss die Schlagwortmatrix angepasst werden, damit die häufig zusammengenutzten Schlagworte auch weiterhin richtig ermittelt werden können.

BVASystem Version 2.2.1.97-dev

Ausblick

In den nächsten Tagen werde ich versuchen, hier auf der Homepage eine BVASystem-Testdatenbank zu installieren. Außerdem möchte ich testen, ob die Datenbank korrekt angesprochen werden kann. Ich hoffe, das ich die zum Teil bisher ungetesteten WebDB-Funktionen korrekt umgesetzt habe. Sofern dem so ist, befinde ich mich jetzt auf der Zielgeraden und kann mich bald wieder anderen Dingen widmen. Und eins weiß ich jetzt schon, nach den umfangreichen internen Änderungen möchte ich jetzt unbedingt wieder etwas machen, wo man die Änderungen sofort erkennen kann.

Durch die Konzentration auf die internen Umstellungen geht es echt viel schneller voran. Gestern Abend habe ich die Umstellung aller Schlagwort-Worker-Tasks auf die neuen Datenbankkomponenten fertiggestellt. Damit habe ich ein weiteres Zwischenziel erreicht. Es war also wieder einmal an der Zeit, eine neue Entwicklerversion zusammenzustellen. Übrig bleiben jetzt „nur“ noch die beiden komplexesten Tasks. Der Datenbankimport von Fotos und das Löschen von Bildern aus der Datenbank warten noch auf ihre Umsetzung. Und damit verbunden ist noch die Umstellung der automatischen Zuordnungen, welche direkt beim Bildimport mit ausgeführt wird.

Ich möchte heute hier den Versuch starten, euch zahlenmäßig näher zu bringen, wie groß die interne Umstellarbeit eigentlich gewesen ist und wie groß sie aktuell noch ist. Ich bin mir bewusst, das die folgenden Zahlen nicht sehr viel aussagen. Aber ich denke, das sie einem Laien doch helfen können, um sich die Umstellarbeiten besser vorzustellen. Bisher hatte ich alle Worker-Tasks in einem zentralen Datenmodul zusammengefasst, in dem die notwendigen Datenbankkomponenten integriert waren. Die dazugehörige Quelltextdatei war rund 120 kb groß und umfasste rund 2800 Quellcodezeilen. Nach der Umstellung befinden sich die Funktionen zwar immer noch an einer zentralen Stelle, aber da ich die Datenbankkomponenten nun bei Bedarf dynamisch erzeuge, brauche ich nun kein Datenmodul mehr. Es reicht eine einfache Klasse aus. Diese ist nun aktuell 24 kb groß und umfasst 800 Quellcodezeilen. Während das alte Datenmodul auf 60 kb und rund 1400 Quellcodezeilen zusammengeschmolzen ist. Ich habe also knapp die Hälfte geschafft und bisher meinen Quelltext um rund 600 Zeilen vereinfacht.

Über die neue BVASystem Version, die ich heute online gestellt habe, gibt es eigentlich wenig zu berichten. Denn ich habe mich entschlossen, ausschließlich an den internen Änderungen zu arbeiten. Zum einen macht es mir aktuell richtig Spaß, die Worker-Tasks nach und nach auf die generalisierten Datenbankkomponenten umzustellen und zum zweiten bringt mich diese Vorgehensweise nun schneller zum eigentlichen Ziel. Sehr schön finde ich es, das ich bei der Umstellung einige Fehler finden konnte. Diese kamen zwar nur zum Tragen, wenn die Ausführung eines Tasks scheitert, aber sie führten dazu, das der Anwender unter Umständen gar nicht über den fehlgeschlagenen Task informiert werden würde.

Am meisten erfreut mich allerdings, das die neuen Implementationen viel kürzer und übersichtlicher sind. Bisher war für jede Ausführung eines SQL-Befehls folgende Befehlsfolge notwendig:

if QSelectData.Active then QSelectData.Close;

QSelectData.SQL.Clear;
QSelectData.SQL.Add(Format(CSELECT_KEYWORDS,[AImageID]));
QSelectData.Open;

Nun kann ich es bei einfachen Abfragen mit einer einzigen Zeile errreichen:

FCon.SelectList(ResultList,Format(CSELECT_KEYWORDS,[AImageID]),'CAPTION');

Brauche ich bei komplexeren Abfragen dann SQL-Parameter, werden es einige Zeilen mehr. Aber auch im alten Quelltextbeispiel sind die Parameter nicht enthalten.

Ausblick

Ich denke, das ich mit der Strategie, möglichst viele interne Änderungen abzuarbeiten, weitermachen werde. So langsam aber sicher möchte ich euch endlich die Demo-Datenbank zur Verfügung stellen können. Daher möchte ich den Zeitplan bis dorthin nicht noch unnötig mit vielen neuen Filtern aufblähen. Bisher habe ich alle Worker-Tasks der Fotoalben und der Schlagwortkategorien umgestellt. Weitermachen werde ich gleich mit den Tasks, die für die Speicherung von Metadaten benötigt werden. Anschließend werde ich mich daran setzen, die Schlagwort-Tasks umzustellen. Zum Schluss sind dann noch die wichtigsten Tasks zum Bildimport übrig.

Das neue Jahr beginnt genauso, wie das alte Jahr geendet ist. Es gibt wieder eine neue Entwicklerversion vom BVASystem mit einem neuen Filterkriterium. Hinzugekommen ist dieses mal das Kritierium ISO-Empfindlichkeit, welches bei der Bildfilterung genutzt werden kann. Für dieses Kriterium musste ich allerdings weit mehr Aufwand investieren, als ich eingeplant hatte. Ich finde nämlich die doppelte Schiebereglerkomponente mit logarithmischer Einteilung, wie sie bereits bei der Brennweite eingesetzt wurde, nicht schlecht. Es lag nahe, sie auch für die ISO-Empfindlichkeit einzusetzen. Dafür waren allerdings einige Modifikationen notwendig.

Natürlich wurde als offensichtliches Merkmal eine andere Beschriftung benötigt . Ebenso offensichtlich ist es, das andere Wertebereiche notwendig waren. Dann fiel mir allerdings auf, das es bei der ISO-Empfindlichkeit keinen Sinn macht, nach ISO 317 zu filtern, da bei Kameras nur gängige Werte wie ISO 200 oder ISO 300 eingestellt werden können. Nachdem ich kurz über dies Problem nachgedacht hatte, entschied ich mich, das es bei der Brennweite auch sinnvoll ist, wenn nicht alle „krummen“ Werte eingestellt werden können. Suche ich nach Bildern, die ich mit einem bestimmten Objektiv fotografiert habe, so muss ich eben den Brennweitenbereich des Objektives auswählen. Dieser liegt dann aber beispielsweise zwischen 70 und 200 Millimeter und nicht zwischen 67 und 143 Millimeter. Bei beiden Filterkriterien können nun also nur noch fest vordefinierte Werte eingestellt werden. Ich hoffe, das ich dabei keine gängigen Werte ausgeschlossen habe.

Filterkriterium ISO-Empfindlichkeit

Des weiteren habe ich natürlich wieder relativ viel Zeit in die internen Änderungen gesteckt. So habe ich zum Beispiel eine Transaktionssteuerung in meinem WebDB-Paket implementiert. Auch habe ich bereits ein Script geschaffen, mit dem ihr euch  später für den Zugang zur BVATestdatenbank registrieren könnt.  Außerdem habe ich hoffentlich das Problem gelöst, welches ich mit Blob-Parametern hatte. Diese lassen sich nämlich nicht direkt in den SQL-Befehl integrieren, da die Binärdaten höchstwahrscheinlich unzulässige Zeichen enthalten werden. Am schwierigsten war hier die Lösung für die WebDB. Dort habe ich mich entschieden, die Binärdaten Base64 codiert in eine XML-Datei zu schreiben.

Ausblick

Als nächstes steht nun an, das ich die ersten Worker-Funktionen des BVASystems auf die generalisierten Datenbankfunktionen umstelle. Wichtig ist mir dabei vor allem erstmal, das die bestehende ADO Implementation wieder funktioniert. Als Nebeneffekt erhoffe ich mir, das es eine vollständigere Logfunktion gibt. Bisher habe ich es nämlich nicht geschafft, überall Logging-Befehle einzupflegen. Des weiteren habe ich mir überlegt, ein Filterkriterium zu implementieren, welches die Bildgröße benutzt. Es wird also bald möglich sein, große und kleine Bilder voneinander zu trennen.

Seit einiger Zeit interessierte es mich, ob ich die Datenbank vom BVASystem hier auf meinem Webspace erstellen kann und vor allem wie schnell der Zugriff auf die Fotos ist, wenn sie nicht mehr im lokalen Netzwerk liegen. Nachdem ich mit dem letzten Update einen größeren Versionssprung vollzogen hatte, erschien es mir sinnvoll dies jetzt einmal ausprobieren. Leider verlief der Test alles andere als geplant, im Gegenteil, er war ziemlich unbefriedigend. 

Gleich beim Einloggen auf das Datenbanksystem gab es die ersten Probleme. Mir fehlten die Rechte, um alle auf der Datenbank angelegten Nutzer abzufragen. Da das Administrationstool diese nur für die Drop-Down-Listen benötigt, ignorierte ich diesen Fehler einfach. Allerdings gab es dann bei der Ausführung des ersten Scripts beim ersten Befehl wieder einen Fehler. Abermals fehlten die notwendigen Rechte, um den Befehl zur Erzeugung des Datenbankschemas auszuführen. Anschließend brach das Administrationstool die Strukturerzeugung ab, da ein sehr wichtiger Befehl nicht ausgeführt werden konnte. Da ich am Administrationstool keine Änderungen vornehmen wollte, war das doch schon sehr frustrierend.

Aber ich werde nicht aufgeben. Ich werde definitiv einen Weg suchen, wie ich auch ohne Systemrechte auf dem Datenbanksystem die Datenbank erzeugen kann. Allerdings sind dann jetzt doch andere Sachen wichtiger, so das ich die Problemlösung nach hinten verschieben werde.

Ich versuche gerade, das geplante Feature „Schlagwortkategorien“ konkreter zu durchdenken. Dabei ist mir aufgefallen, das ich beim letzten Datenbankstruktur-Update einen konzeptionellen Fehler gemacht habe. Sicherlich könnte ich mit der jetzigen Struktur arbeiten, aber ich denke, das es einfacher ist, die jetzt noch fast ungenutzten Tabellen zu korrigieren. Daher wird es mit dem nächsten Programm-Update notwendig sein, die Datenbankstruktur zu aktualisieren.

Worum geht es konkret?

Meine Idee ist es, das ähnlich wie bereits bei den Fotoalben, vom Anwender beliebige Schlagwortkategorien angelegt werden können. Nachdem eine Kategorie angelegt wurde, kann sie mit Schlagworten verknüpft werden. Sobald man dann im Rubrikenbaum eine Schlagwortkategorie auswählt, sollen alle Fotos angezeigt werden, bei denen mindestens eines der verknüpften Schlagworte gesetzt wurde.  Es entsteht also eine weitere Möglichkeit, eine Bildliste zusammenzustellen. 

Mögliche Schlagwortkategorien

Warum das Datenbankupdate?

Ursprünglich hatte ich geplant, das ein Schlagwort immer genau zu einer Kategorie gehören muss und maximal einer Kategorie zugeordnet werden kann. Dies erschien mir damals als ausreichend. Bei dem auf dem Bild gezeigten Beispiel reicht dies allerdings nicht aus. Das Schlagwort „Lange Anna“ würde ich der Kategorie „Nordsee – Helgoland“ und auch der Kategorie „Sehenswürdigkeiten – Deutschland“ zuordnen wollen. Es muss also möglich sein, das ein Schlagwort auch mehreren Kategorien zugeordnet werden kann. Dieses werde ich nun mit dem Update korrigieren. 

Da die Änderung auch in dem frühen Entwicklungsstadium einen ganzen Sack von Anpassungen notwendig macht, bin ich gerade nicht sicher, ob ich mein gestecktes Ziel für die nächste Version rechtzeitig erreiche. Es ist also durchaus möglich, das auf die nächste Programmversion etwas länger gewartet werden muss.

Prinzipiell versuche ich ja, so lange wie möglich mit einer bestehenden Datenbankstruktur zu arbeiten. Aber irgendwann kommt einfach der Punkt, an dem es nicht mehr ohne geht. Ich würde fast sagen, das mich die alte Datenbankstruktur eine Zeit lang gelähmt hat, da die Möglichkeit zur Aktualisierung per Administrationstool fehlte.  Jetzt wo das Administrationstool die Funktion besitzt, kommt eine Art kleiner Befreiungsschlag, denn ich habe gleich für fünf neue Funktionen die Datenbankänderungen vorgenommen.

Speicherung der Bildbewertung

Die Bildbewertung habe ich in den letzten beiden Artikeln ja bereits ausführlich vorgestellt. Mit der neuen Datenbankstruktur habe ich nun alle Voraussetzungen geschaffen, um die Bildbewertungen speichern zu können.

Speicherung der berechneten Bildparameter

Um die Metadatenzuordnungen zu prüfen, ist es sinnvoll, das die genutzten Bildparameter für jedes Bild in der Programmoberfläche angezeigt werden. Daher habe ich eine Tabelle in der Datenbankstruktur vorgesehen, die die Belichtungsbewertung, den Tonwertumfang und die mittlere Helligkeit speichern kann.

Speicherung des Aufnahmeortes eines Fotos

Vor einigen Monaten habe ich mir eine neue Digitalkamera gekauft, die in der Lage ist, per GPS den Aufnahmeort mit in der Bilddatei abzulegen. Ich denke, das der Aufnahmeort ein tolles Metadatenelement für die automatischen Zuordnungen ist. Beispielsweise könnten so alle Fotos, die im Berliner Zoo aufgenommen wurden, dem Album „Berliner Zoo“ zugeordnet werden. Gleichzeitig wäre es möglich alle entsprechenden Fotos automatisch mit dem Schlagwort „Berliner Zoo“ zu taggen. Als Grundvorraussetzung hierfür habe ich die Datenbank nun so erweitert, das alle GPS-EXIF-Tags gespeichert werden können.

Speicherung der gängigen IPTC-Datenfelder

Weiterhin fehlte im BVASystem bisher die Möglichkeit, einige Bilddaten zu erfassen, die normalerweise im IPTC-Header gespeichert werden können. Zu den Feldern zählen Beispielsweise: Fotograf, Bildtitel, Bildbeschreibung, Copyright und zu guter letzt die Schlagworte. Damit sich auch in diesem Bereich etwas ändern kann, habe ich die entsprechenden Datenfelder angelegt.

Speicherung der Originalbildgröße

Bisher ist es so, das das BVASystem fast ausschließlich mit dem erstellten Vorschaubild arbeitet. Für die normale Anzeige ist dieses, in der Standardeinstellung 800 Bildpunkte hohe Bild, völlig ausreichend. Verlässt man die angepasste Darstellung, fällt aber schnell auf, das die Originalbildgröße nicht zur Verfügung steht. Längerfristig ist geplant, das das Originalbild beim Zoomen nachgeladen wird. Als ersten Schritt dorthin möchte ich erst einmal die Größe der 100% Ansicht korrigieren. Dazu benötige ich natürlich die Originalbildgröße, die ich erfahren möchte, ohne das ich das Originalbild bereits laden muss. 

Durchführung der Datenbankaktualisierung

Die Durchführung der Datenbankaktualisierung wird mit dem BVASystem Administrationstool durchgeführt. Alle dafür notwendigen Datenbankscripte werden bei der Programminstallation mit auf dem Rechner kopiert. Der Ablauf der Aktualisierung ist genauso, kann aus der Installationsanleitung entnommen werden. Ich empfehle, bevor das Update durchgeführt wird, die Datenbank mit dem entsprechenden Tool des Datenbanksystems zu sichern.

Ich hoffe, das ich alle Datenbankänderungen inhaltlich korrekt vorgenommen habe, so das bitte möglichst viel Zeit vergeht, bis es heißt „Neue Datenbankstruktur (Version 3)“

Denen, die das BVASystem schon länger kennen, sollte bekannt sein, wie kompliziert es bisher war, die Datenbankstruktur zu aktualisieren. Ab heute ist alles viel einfacher, denn alle zukünftigen Datenbankupdates werden mit dem Administrationstool durchgeführt. Dazu müssen nur noch eine handvoll Parameter, wie zum Beispiel das Datenbankadministratorlogin, eingegeben werden. Der Rest läuft dann quasi nach einem einzigen Klick automatisch ab.

BVAAdmin – Datenbankstruktur aktualisieren

Damit dies möglich ist, arbeitet das Administrationstool mit einem relativ einfachen System. In der Datenbankstruktur gibt es seit einiger Zeit eine Tabelle „bva_version“, in der die jeweils vorhandene Datenbankversion gespeichert ist. Wenn der Aktualisierungsprozess angest0ßen wird, so wird als erstes in diese Tabelle geschaut. Anschließend werden nacheinander die notwendigen Aktualisierungsscripte ausgeführt. In den Scripten werden schrittweise neue Datenbanktabellen angelegt oder neue Datenfelder zu bestehenden Datenbanktabellen hinzugefügt. Bestehende Datenbankfelder, die nicht mehr benötigt werden, werden niemals gelöscht, weil damit Nutzerdaten gelöscht werden könnten. Nachdem die Aktualisierungsscripte ausgeführt wurden, wird die Datenbankversion in der Tabelle „bva_version“ aktualisiert.

Mit dem aktuellen Administrationstool kann der Ablauf noch gefahrlos getestet werden, da keinerlei Änderungen an der Datenbankstruktur vorgenommen werden. Das Updatescript für Version 2 besteht aktuell nur aus einem einzigen Dummy-Befehl. Auch das herraufsetzen der Datenbankversion ist noch deaktiviert. Mit der nächsten Version in etwa 2-3 Wochen wird allerdings das erste „scharfe“ Datenbankupdate kommen. Spätestens dann ist es ratsam, vor dem Update die bestehende Datenbank mit dem jeweiligen Tool des Datenbanksystems zu sichern.