Aber auch diesmal muss ich das Metadatenelement ein wenig erklären, da es wieder ein Element ist, welches vom Programm errechnet wird.

Wie definiert sich die Belichtungsbewertung?

Wie auch der Tonwertumfang basiert die Belichtungsbewertung auf dem Histogramm des Fotos. Im letzen Blog habe ich versucht zu erklären, das ein perfektes Bild alle möglichen Tonwerte nutzt. Es dürfen allerdings keine Farbwerte außerhalb des möglichen Tonwertumfangs liegen. Alle Bildpunkte, die dunkler als der kleinstmögliche Tonwert sind, werden von der Kamera ebenfalls auf den kleinstmöglichen Tonwert gesetzt. Analog gilt das gleiche für Bildbereiche die heller sind, als der größtmögliche Tonwert. Im Bild äußert sich das dadurch, das größere Flächen entstehen, die komplett schwarz bzw. komplett weiß sind. Im Histogramm erkennt man ebenfalls eine Häufung beim kleinstmöglichen bzw. größtmöglichen Tonwert. Für die Belichtungsbewertung zählt das BVASystem nun die weißen bzw. die schwarzen Bildpunkte und setzt sie im Verhältnis zur Gesamtbildgröße. Je mehr Prozent der Bildfläche komplett weiß bzw. schwarz sind, desto größer ist der fehlbelichtete Bildbereich.

Wozu kann sie genutzt werden?

In erster Linie ist die Belichtungsbewertung dazu gedacht, damit fehlbelichtete Bilder erst garnicht in das jeweilige Fotoalbum eingefügt werden. Aber auch der umgekehrte Fall, das nur fehlbelichtete Bilder einem Album zugeordnet werden, erscheint mir sinnvoll, da man beispielsweise so gezielt alle fehlbelichteten Bilder betrachten kann.  So kann man schnell entscheiden, ob das Bild mit Photoshop noch zu “retten” ist oder ob es besser gelöscht werden sollte. Natürlich kann man die Belichtungsbewertung auch nutzen, um Fotos die bewusst unter- oder überbelichtete Bildbereiche (z.B Sternenhimmel) besitzen von anderen Fotos zu trennen.

Um möglichst viele verschiedene Definitions-Möglichkeiten zu bieten, können auch nur unterbelichtete oder nur überbelichtete Bildbereiche ausgewertet werden. Gerade im Fall des Sternenhimmels wird einem wahrscheinlich nur der unterbelichtete Bildbereich interessieren. Standardmäßig sind bei der Definition des Metadatenelements Belichtungsbewertung unter- und überbelichtete Bildbereich ausgewählt.

Metadatenelement Belichtungsbewertung

Welche weiteren Änderungen wurden am Programm umgesetzt?

In der Bildinformationen-Ansicht hat sich auch einiges getan. Auffällig sollte sein, das sich nun nicht mehr 2 sondern 3 kleine Fensterchen auf der Ansicht befinden. Außerdem sollte auffallen, das jedes dieser 3 Fenster auch eine Funktion hat. Das erste der Fenster dient zur Navigation innerhalb der aktiven Bildliste. Das Foto-Fenster zeigt logischerweise das aktuell aktive Bild an und das Kamera-Fenster zeigt aktuell die EXIF-Daten des Bildes an, wie es auf dem Bildinformationspopup bekannt sein sollte.

Des weiteren habe ich  daran gearbeitet, das alle Funktionen zur Bildveränderung in der ImgFkt.dll ausgelagert sind. Neu ist diesmal, das die Funktion zur Umwandlung eines Bildes in ein Graustufenbild ausgelagert wurde. Scheinbar mag dies zu keiner Änderung für den Anwender führen, aber intern erhalte ich dadurch eine viel klarere Struktur. Und vielleicht ergibt sich auch einmal die Gelegenheit die Funktionsbibliotek für ein anderes Projekt zu verwenden.

Wie geht es weiter?

Weiterarbeiten werde ich nun an 2 weiteren Metadatenelementen, deren Umsetzung sich einfacher gestalten dürfte. Es geht dabei um die Blende und die Belichtungszeit, die von der Kamera in der Bilddatei abgelegt wurde. Mein Ziel ist es dabei, zu ermöglichen, Fotos, bei deren Aufnahme ähnliche Lichtbedingungen herschten, zu filtern.

Die Schwierigkeit bei der Entwicklung der beiden Metadatenelemente liegt ganz klar in der Benutzeroberfläche. Sowohl Blende als auch Belichtungszeit werden in der Bilddatei als reine Gleitkommazahl gespeichert. Angezeigt wird die Belichtungszeit aber  beispielsweise als  “1/250 sec” und nicht als  “0,004 sec”. Ich muss also einen Weg finden, wie die Belichtungszeit für den Anwender bequem eingstellt werden kann,.

Außerdem werde ich wieder an der Bildinformationsansicht weiterarbeiten. Diesmal wird es darum gehen, das der Anwender zwischen verschiedenen Ansichten wechseln kann. Außerdem möchte ich die Funktion zur Definition eigenener Ansichten vorbereiten.

Was ist der Tonwertumfang eines Bildes?

Der Tonwertumfang eines Bildes gibt an, wieviele Farbinformationen (Tonwerte) ein Bild besitzt. Ein Graustufenbild mit einer Farbtiefe von 8bit besitzt beispielsweise 2^8 = 256 mögliche Grautöne. Werden von diesen 256 möglichen Grautönen nur die Hälfte (128) im Bild genutzt, so beträgt der Tonwertumfang 50%.

Ein ideales Bild nutzt alle möglichen Tonwerte. Generell ist es so, das je weniger Tonwerte ein Bild nutzt, desto kontrastärmer bzw. flauer wirkt es. Daraus folgt nun auch der bewertende Charakter des Tonwertumfangs. Je kleiner der Tonwertumfang eines Bildes ist, desto weiter ist das Foto von einem idealen Bild entfernt und desto “schlechter” ist das Bild. Aber Vorsicht: Eine generelle Aussage, ob das Bild schlecht ist, ist nicht möglich, da ein reduzierter Tonwertumfang auch als gestalterisches Mittel eingesetzt werden kann.

Wie wird der Tonwertumfang innerhalb der Metadaten umgesetzt?

In der Metadatendefinition gibt man für den Tonwertumfang eine untere und obere Grenze an. Liegt der Tonwertumfang des Fotos zwischen den beiden Grenzen, so wird das Bild dem Album zugeorndet. Damit wird ein recht guter Freiheitsgrad erreicht, da sowohl gute Bilder (Beispielsweise Tonwertumfang zwischen 80% und 100%) als auch schlechte Bilder (Beispielsweise Tonwertumgang zwischen 0% und 25%) zugeordnet werden können. Wie immer lassen sich weitere Elemente mit dem Tonwertumfang kombinieren, so dass dann alle Elemente erfüllt sein müssen. Auch kann das Metadatenelement Tonwertumfang mehrfach genutzt werden, um mehrere Tonwertbereiche abzudecken.

Metadatenelement Tonwertumfang

Welche Änderungen gibt es außerdem an der Bilddatenbank?

Neben dem neuen Metadatenelement habe ich damit begonnen, einen vierten Ansichtsmodi in das Programm zu integrieren. Der neue Modus soll dazu genutzt werden, um die erfassten Informationen zu einem Bild anzuzeigen. Aktuell stört es mich schon sehr, das nicht einsehbar ist, wie groß beispielsweise der Tonwertumfang eines Fotos ist. Ein überprüfen, ob die Zuordnung zu einem Fotoalbum formal korrekt gewesen ist, ist also leider noch nicht möglich. Aktuell ist ein Stand erreicht, in dem 2 kleine Bildinformationsfenster ein- und auch wieder ausgeblendet werden können. Da noch keinerlei Informationen in diesen Fenstern stehen, ist der Nutzen des ganzen quasi noch nicht vorhanden.

Wie gehts weiter?

Heute abend werde ich daher gleich an dieser Ansicht weiterentwickeln. Ziel ist es, das zumindest ein Teil der aktuell erfassten Informationen visualisiert werden können. Sobald die Ansicht für den Anwender einen Nutzen hat, werde ich mein Konzept hinter dieser Ansicht näher erläutern. Außerdem werde ich in den nächsten Wochen wieder ein neues Metadatenelement implementieren. Auch dieses wird wieder einen bewertenden Charakter haben.

Aktuell ist mein Ziel zu demonstrieren, was mit dem Metadatensystem alles erreicht werden kann. Dafür ist es natürlich am wichtigsten, weitere Metadatenelemente zu schaffen, die beliebig mit den bereits vorhandenen Elementen kombiniert werden können. Langfristig möchte ich die Metadaten noch an andere Verwaltungselemente, wie zum Beispiel die Schlagworte, binden.

Den ersten abgesteckten Entwicklungsschritt habe ich nun auch bereits erreicht. Das Metadatenelement „Mittlere Helligkeit“ ist in der Version 2.1.1.41 nun zum ersten Mal enthalten. Das Besondere dabei ist, dass der Helligkeitswert nicht aus dem Header des Fotos ausgelesen werden kann. Es handelt sich vielmehr um einen Wert, der direkt aus dem Foto errechnet wird. Das BVASystem ist damit also in der Lage, helle und dunkle Fotos zu unterscheiden.

Weiterhin habe ich das Metadatenelement “Aufnahmedatum” verbessert, in welchem nun auch die Uhrzeit eingestellt werden kann. Bisher war es so, das man nur tageweise definieren konnte. War man beispielsweise vormittags wandern und nachmittags auf einer Familienfeier, waren die Fotos automatisch nicht voneinander trennbar. Nun können auch beliebig viele Fotoalben angelegt werden, welche alle Fotos enthalten, die an dem gleichen Tag aufgenommen wurden.

Veränderte Metadatenelemente der Version 2.1.1.41-dev

Als dritte kleine Verbesserung habe ich die Metadatenelemente in der Auswahlliste gruppiert. Damit sollte es, auch wenn es mal mehrere Dutzend Metadatenelemente werden, trotzdem übersichtlich bleiben. Die 3 nun verwendeten Gruppen lauten:

• EXIF: Hier werden alle Elemente zusammengefasst, die auf dem EXIF-Header eines Fotos basieren
• DB: Hier werden alle Elemente zusammengefasst, die sich direkt aus der Datenbank ableiten lassen
• BV: Hier werden alle Elemente zusammengefasst, die mittels Bildverarbeitung direkt am Foto errechnet werden

Auch in der nächsten Version werde ich mich um die Metadaten kümmern. Ziel ist es das erste bildbewertende Metadatenelement zu schaffen. Damit soll es dann möglich sein, das nur gelungene Bilder den Weg in ein Fotoalbum finden. Außerdem werde ich damit beginnen, einen vierten Ansichtsmodi „Bildinformationen“ in das Programm zu integrieren.

Neuerungen am Programm

Die größte Veränderung am Programm ist sicher die Unterstützung von den Datenbanksystemen MySQL, Firebird und Oracle. Bisher war es nur möglich, MySQL als Datenbanksystem zu verwenden. Die Installation war aufwendig und wahrscheinlich nicht immer leicht. Hier konnte ich definitiv eine Verbesserung erreichen, indem die notwendige Datenbankstruktur nun durch ein Administrationstool erstellt werden kann. Es sind hier weit weniger Benutzereingaben bzw. -aktionen notwendig um ans Ziel zu gelangen.

Aber auch am Hauptprogramm gab es Veränderungen. Das Modul zum Auslesen der EXIF-Bildinformationen wurde erweitert, die neu erfassten Daten werden beim Bildimport  in der Datenbank gespeichert und sie können in einem Bildinformationspopup-Fenster jederzeit angezeigt werden.

Ausblick

Ich hoffe, das ich bis zur nächsten stabilen Softwareversion wieder einen ähnlichen Zeitrahmen benötigen werde. Vorgenommen habe ich mir, das ich die Metadaten-Funktionalität verstärkt erweitere. Ich denke, das diese Funktionalität das BVASystem am stärksten von anderen Bildverwaltungssystemen unterscheidet. Darum denke ich, das die Entwicklungszeit hier gut investiert ist.

Als erstes möchte ich ein neues Metadatenelement implementieren, welches nicht auf dem EXIF-Header basiert. Dieses Metadatenelement wird die mittlere Bildhelligkeit sein. Damit wird es dann beispielsweise möglich sein, Nachtaufnahmen von Tagaufnahmen zu unterscheiden, auch wenn sie am gleichen Tag aufgenommen wurden. Mehr dazu werde ich hier berichten, sobald die neue Funktionalität in einer Entwicklerversion getestet werden kann.

Außerdem habe ich mir vorgenommen, einen vierten Anzeigemodi zu schaffen, auf dem alle Bildinformationen zusammenhängend angezeigt und später auch editiert werden können. Und auch am Administrationstool werde ich weiterarbeiten. Wichtig ist zum Beispiel die Möglichkeit zur Aktualisierung einer veralterten BVASystem Datenbankstruktur.

Wie kann ich die Datensatz-ID des zuletzt gespeicherten Datensatzes erhalten?

Fügt man in eine beliebige Tabelle mit Hilfe eines “INSERT INTO …”-Befehls einen Datensatz hinzu, so weiß man im Normalfall nicht, welcher Wert per Autoincrement/Trigger für das ID-Feld generiert wurde. Diesen Wert benötigt man allerdings, wenn weitere Daten in einer abhängigen Tabelle (foreign keys) gespeichert werden sollen.

Eine Lösung wäre, das man den gerade eingefügten Datensatz wieder selektiert und das ID-Feld ausliest. Dies ist aber nicht notwendig, da alle 3 Datenbanksysteme für diesen Fall eine einfachere Lösung bieten.

MySQL

MySQL besitzt eine Funktion, mit der man die zuletzt hinzugefügte ID erfragen kann. Der Funktionsaufruf ist per SELECT-Befehl möglich und sieht wie folgt aus:

SELECT LAST_INSERT_ID() AS ID

Wichtig ist hier, das der Befehl gleich nach dem INSERT aufgerufen wird, da sich der Wert bei einem weiteren INSERT ändert.

Firebird

Bei Firebird kann man den zur Datenbanktabelle gehörenden Generatorwert erfragen. Es ist ein wenig aufwendiger als bei MySQL, da man für unterschiedliche Tabellen unterschiedliche Generatoren abfragen muss. Die Abfrage sieht wie folgt aus:

SELECT gen_id(GEN_BVA_CREATIONTREE, 0) AS ID from rdb$Database

Vorteil ist hier, das der Generatorwert jederzeit abgefragt werden kann. Auch ohne INSERT kann der aktuelle Wert des Generators abgefragt werden.

Oracle

Mit einer ähnlichen Abfrage kommt man bei Oracle zu seinem ID Wert.  Sie sieht wie folgt aus:

SELECT GEN_BVA_CREATIONTREE.CURRVAL AS ID FROM DUAL

Was ist ein Trigger?

Ein Datenbanktrigger ist eine Datenbankfunktionalität, die in eigentlich jedem größeren Datenbanksystem integiert ist. Man kann sich einen Trigger wie ein kleines Programm vorstellen, das bei bestimmten Datenbankaktionen ausgeführt wird. Beispielsweise kann vor dem Einfügen eines Datensatzes geprüft werden, ob die Daten valide sind. Oder es wird ein Trigger erstellt, der das Erstellungsdatum des Datensatzes speichert.

Genau so ein Trigger soll mein Beispiel für den Vergleich zwischen MySQL,Firebird und Oracle sein. In der Tabelle bva_image speichert der Trigger in dem Feld mod_date das aktuelle Systemdatum ab, sobald ein Datensatz in der Tabelle hinzugefügt wird.

Trigger unter MySQL

CREATE TRIGGER  bva_image_insert_timestamp
 BEFORE INSERT on bva_image
 FOR EACH ROW
  SET NEW.mod_date = NOW();

Trigger unter Firebird

CREATE TRIGGER bva_image_insert_timestamp FOR bva_image
 BEFORE INSERT
 AS
 BEGIN
  NEW.mod_date = CURRENT_TIMESTAMP;
 END

Trigger unter Oracle

CREATE OR REPLACE TRIGGER IMAGE_INSERT_TIMESTAMP
 BEFORE INSERT ON BVA_IMAGE
 FOR EACH ROW
 BEGIN
  :new.mod_date := SYSDATE;        
 END;

Probleme mit Firebird

Schon zu Beginn der Arbeiten zur neuen Version des BVASystems gab es die ersten Probleme. Firebird nutzt ein komplett anderes System um eine Datenbankverbindung aufzubauen als MySQL oder Oracle. Firebird benötigt den Pfad und Dateinamen der Datenbankdatei, um eine Verbindung herzustellen. Da ich Pfad und Dateiname im Administrationstool nicht erfasst habe, war es mir nicht möglich, für alle 3 Datenbanksysteme den gleichen Einstellungsdialog zu verwenden. Also musste ich in den sauren Apfel beißen und einen weiteren Einstellungsdialog entwickeln.

Das zweite Problem war, das auch später im BVASystem immer wieder der Pfad und der Dateiname der Datenbank benötigt wird. Da ich dies absolut nicht wollte, habe ich recht lange nach einer Lösung gesucht und auch eine gefunden. Die Lösung heißt: “aliases.conf” Im Programmverzeichnis von Firebird liegt eine aliases.conf, in der ein Alias für eine Kombination aus Pfad und Dateiname angelegt werden kann. Das BVASystem Administrationstool legt den benötigten Alias, bei der Erstellung der Datenbankstruktur, mit an. Die einzige Aufgabe, die manuell ausgeführt werden muss, ist ein Neustart des Datenbankservers. Ohne Neustart steht der neue Alias noch nicht zur Verfügung und die Datenbankverbindung schlägt fehl.

Probleme mit Oracle

Auch Oracle erwies sich als nicht weniger störrisch. Die notwendigen Datenbankscripte waren relativ schnell entwickelt, aber bei der von mit genutzten Version 9 lassen sich absolut keine Trigger erzeugen. Per SQLPlus funktionieren die einzelnen Befehle der Scripte wunderbar, aber beim Administrationstool werden vom ODBC-Treiber die Zeilenwechsel durch einen doppelten Wagenrücklauf (#13) ersetzt. Oracle schimpft dann bei der Übersetzung der Trigger, das ein ungültiges Zeichen gefunden wurde. Tests mit der Version 10 funktionierten dagegen einwandfrei. Daher habe ich mich entschlossen, die Unterstützung von Oracle 9 wieder zu entfernen bzw. sie durch Version 11 zu ersetzten. Da ich dafür allerdings mindestens 1 Woche benötige, habe ich entschieden, Oracle auf die nächste Programmversion zu verschieben. Ich hoffe, das dies dann das letzte Problem war, auf dem Weg zur Unterstützung von 3 Datenbanksystemen.

Ausblick

Neben der Oracle Unterstützung habe ich vor, noch einen Programmfehler aus dem BVASystem zu entfernen. Zum Beispiel stürzt das Programm leider ab, wenn ein Bild mit fehlerhaften Exif-Header geladen wird. Außerdem habe ich vor, die Installationsanleitung anzupassen, da nun die Erstellung der Datenbank mit dem Administrationstool einfacher geworden ist.

Auto-ID Feld unter MySQL

Wie einfach es ist, unter MySQL ein Auto-ID Feld zu erzeugen, hatte ich bereits im Teil 1 erwähnt. Man muss nur bei der Erzeugung einer Tabelle beim gewünschten Feld das Schlüsselwort AUTO_INCREMENT hinzufügen. Als Datenbankentwickler freut man sich sicher, das man so schnell fertig ist.  Aber man stößt sehr schnell an eine Grenze, wenn man komplexere Sachen umsetzen möchte. Zum Beispiel ist es nicht ohne weiteres möglich, eine eindeutige ID über mehrere Tabellen zu definieren.

Auto-ID Feld unter Firebird

Unter Firebird sind mehrere Einzelschritte notwendig, um ein Auto-ID Feld zu definieren. Als erstes wird logischerweise wie in Teil 1 bereits beschrieben die Tabelle angelegt. Als zweiten Schritt erzeugt man sich einen sogenannten Generator, der die jeweils zuletzt genutzte ID speichert. Die Erzeugung eines Generators erfolgt mit folgendem SQL-Befehl:

CREATE GENERATOR GEN_BVA_CREATIONTREE

Als nächstes muss der Generator mit einem Wert initialisiert werden. Im Beispiel wird der Generator mit dem Wert 0 initialisiert.

SET GENERATOR GEN_BVA_CREATIONTREE TO 0

Als letztes und wichtigstes Element wird ein Trigger benötigt, der vor dem Einfügen eines Datensatzes ausgeführt wird. Der Trigger erhöht den Generatorwert um 1 und trägt den Wert in das gewünsche Auto-ID-Feld der Tabelle ein.

CREATE TRIGGER ID_TRIGGER_BVA_CREATIONTREE FOR BVA_CREATIONTREE
 BEFORE INSERT
 AS
 BEGIN
  NEW.ID = GEN_ID(GEN_BVA_CREATIONTREE,1);
 END

Hier ist es möglich über mehrere Tabellen einen eindeutigen Index zu erzeugen. Dafür muss man in den jeweiligen Triggern den gleichen Generator nutzen.

Auto-ID Feld unter Oracle

Oracle arbeitet prinzipiell nach dem gleichen Konzept wie Firebird. Allerdings heißt der Generator bei Oracle Sequenz. Außerdem entfällt der Initialisierungsschritt, da die Initialisierung bereits bei der Erstellung der Sequenz erfolgt. Die Befehlsfolge für Oracle sieht wie folgt aus:

CREATE SEQUENCE GEN_BVA_CREATIONTREE
 START WITH 1
 INCREMENT BY 1
 NOMAXVALUE
 NOCACHE
 ORDER;

CREATE OR REPLACE TRIGGER ID_TRIGGER_BVA_CREATIONTREE
 BEFORE INSERT ON BVA_CREATIONTREE
 FOR EACH ROW
 BEGIN
  SELECT GEN_BVA_CREATIONTREE.nextval INTO :new.id FROM DUAL;
 END;
/

Da ich gerade beim Schreiben der Scripte zum Erstellen der BVASystem-Datenbankstruktur für MySQL, Firebird und Oracle bin, möchte ich heute eine kleine Serie starten, welche die Unterschiede zwischen diesen 3 Datenbanksystemen zusammenfasst. Dabei werde ich allerdings nur auf die Unterschiede eingehen, die mir im Zusammenhang mit dem BVASystem aufgefallen sind.

Starten möchte ich heute mit den unterschiedlichen Syntax des SQL-Befehls “CREATE TABLE”. Im folgendem werde ich an der Tabelle “bva_creationtree” zeigen, wo die  Unterschiede zwischen den Datenbanksystemen liegen.

CREATE TABLE unter MySQL

Richtig bequem finde ich bei MySQL die Möglichkeit ein Auto-ID Feld zu generieren. Hierfür muss einfach neben das gewünschte Feld das Schlüsselwort “AUTO_INCREMENT” geschrieben werden. Bei Firebird und Oracle werden die Auto-ID Felder über eine Kombination aus Generator/Sequenz und Trigger gelöst. Damit dieser Blog nicht zu unübersichtlich wird, werde ich im nächsten Teil noch einmal ausführlich auf das Thema eingehen.

Als zweite Besonderheit bei MySQL fällt auf, das am Ende des Befehles eine “Engine” ausgewählt werden kann. MySQL unterstützt unterschiedliche Speicherengines. Je nach Einsatzzweck unterscheiden sich die Speicherengines in ihrer Performance. Da mir die Transaktionssicherheit recht wichtig ist, nutze ich die langsamere InnoDB-Engine.

Der komplette SQL-Befehl für die bva_creationtree Tabelle sieht wie folgt aus:

CREATE TABLE bva_creationtree (
 id INT NOT NULL AUTO_INCREMENT,
 parent_id INT ,
 caption VARCHAR(10)  NOT NULL,
 PRIMARY KEY (id),
 INDEX fk_bva_creationtree (parent_id ASC),
 CONSTRAINT fk_bva_creationtree
   FOREIGN KEY (parent_id)
   REFERENCES bva_creationtree (id)
) ENGINE = InnoDB

CREATE TABLE unter Firebird

Schaut man sich den gleichen SQL-Befehl für Firebird an, so sieht er auf dem ersten Blick relativ ähnlich aus.

CREATE TABLE bva_creationtree (
 id INT NOT NULL,
 parent_id INT,
 caption VARCHAR(10) NOT NULL,
 PRIMARY KEY (id),
 CONSTRAINT fk_creationtree
   FOREIGN KEY (parent_id)
   REFERENCES bva_creationtree (id)
 )

Auf dem zweiten Blick fällt dann auf, das für den Fremdschlüssel “fk_creationtree” kein zusätzlicher Index definiert wurde. Der zusätzliche Index ist bei Firebird nicht notwendig, da er mit dem Constraint zusammen anglegt wird. Das Auto-ID Feld “id” muss wie bereits beschrieben manuell angelegt werden. Ansonsten gibt es keine weiteren Unterschiede.

CREATE TABLE unter Oracle

Größere syntaktische Unterschiede gibt es bei Oracle. Als erstes fällt auf, das sich die Datentypbezeichnungen unterscheiden: NUMBER(38) anstelle von INT, VARCHAR2() anstelle von VARCHAR() und INT anstelle von FLOAT. Bequem ist, das einfache Primärschlüssel oder auch Constraints direkt hinter der Felddefinition angegeben werden können. Alternativ können sie aber  beispielsweise auch per “CONSTRAINT pk_creationtree PRIMARY KEY (id)” angelegt werden.

Nach dem Ende des eigentlichen Create Table SQL-Befehlt gibt man bei Oracle an, in welchem Tablespace die Daten der Tabelle gespeichert werden sollen und wie die Tabelle sich verhalten soll, wenn sie zusätzlichen Speicher benötigt. Die dort getätigten Einstellungen haben Auswirkungen auf die Performance. Speichert man große Datenmengen in einer Tabelle, ist es sinnvoll sie in größeren Schritten zu vergrößern, da die Vergrößerung dann nicht mit jedem neuen Datensatz durchgeführt werden muss.

Der vollständige SQL Befehl für die Beispieltabelle sieht wie folgt aus:

CREATE TABLE bva_creationtree (
 id NUMBER(38) NOT NULL PRIMARY KEY,
 parent_id NUMBER(38),    
 caption VARCHAR2(10) NOT NULL,
 CONSTRAINT fk_creationtree
   FOREIGN KEY (parent_id)
   REFERENCES bva_creationtree (id)  
 )
 TABLESPACE bva
 STORAGE
  ( INITIAL     1M
    NEXT         1M
    PCTINCREASE 0
    MINEXTENTS     1
    MAXEXTENTS     UNLIMITED
  )

Ausblick

Mein aktueller Zeitplan sieht so aus, das es noch eine weitere Zwischenversion vor der Veröffentlichung der nächsten stabilen Softwareversion geben wird. In dieser Zwischenversion werde ich die Datenbankscripte, die dem Administrationstool hinterlegt sind so erweitern, das 2 weitere Datenbankmanagementsysteme vom BVASystem verwendet werden können. Wahrscheinlich werden es Oracle und Firebird werden. Aber ganz sicher bin ich mir bei der Auswahl noch nicht. Nach der Zwischenversion heißt es dann noch einmal intensives Testen und wahrscheinlich auch intensives Fehlerbeseitigen.

Wie funktioniert das Anlegen der Datenbankstruktur mit dem Administrationstool?

Das Anlegen der Datenbankstruktur ist recht einfach. Im Administrationstool wählt man dafür im Hauptmenü den Eintrag “Datenbankstruktur erstellen” aus. Es öffnet sich dann folgender Dialog:

Administrationstool: Datenbankstruktur erzeugen

In diesem Dialog muss man als erstes die Verbindungsdaten zum Datenbankserver eintragen und anschließend auf “Verbinden” klicken. Wenn die Verbidnung hergestellt wurde, aktiviert sich die untere Hälfte des Dialoges. Hier wählt man nun aus, ob das BVASystem in ein bestehendes Datenbankschema integriert oder ob ein neues Datenbankschema angelegt werden soll. In beiden Fällen muss der Name für das Datenbankschema festgelegt werden. Als letztes hat man noch die Wahl, wer der Besitzer der Datenbanktabellen sein soll und ob ein Standardbenutzer angelegt werden soll. Wenn alle Einstellungen ausgewählt wurden, schließt man die Auswahl mit Druck auf den Knopf “Struktur erstellen” ab. Anschließend wird die Datenbankstruktur automatisch erstellt. In der Log-Ansicht wird der Anwender über Erfolg bzw. Misserfolg der einzelnen Arbeitsschritte informiert.