Oracle APEX 18.2 Tutorial Teil 1 – SQL Workshop

Deutschsprachiges Einsteiger Tutorial für Oracle APEX 18.2. Tabellen mit dem SQL Workshop erstellen.

In dieser Beitragsreihe möchte ich Ihnen anhand einer einfachen Anwendung zur Verwaltung von Kochrezepten eine Einführung in die Anwendungsentwicklung mit der Low-Code Entwicklungsumgebung Oracle Application Express bieten. Um dieses Tutorial nachstellen zu können, benötigen Sie eine lauffähige Apex Installation. Wie Sie APEX einrichten habe ich in dem Beitrag Installation Oracle Apex dieses Blogs beschrieben. Alternativ können Sie sich unter https://apex.orale.com einen Testzugang anlegen und die von Oracle in der Cloud betriebenen APEX-Plattform zu Bildungszwecken nutzen.

Aufgabenstellung

Als Beispiel soll eine einfache Anwendung erstellt werden, mit der Kochrezepte verwaltet werden können. Ein Rezept kann dabei mehrere Zutaten besitzen. Die Verarbeitung der Zutaten soll in einfachen Arbeitsschritten dargestellt werden.

Datenmodell

  • Kochrezepte (cooking_recipe)
    • name
    • description
    • number_of_persons
  • Zutaten (ingredients)
    • name
    • quantity
    • unit
    • product_classification ( bio, vegetarian, vegan, …)
    • calories
  • processing_step
    • name
    • description
    • Pictures/Videos
    • product_id
    • order_number

APEX-Anwendung

Haben Sie sich für eine eigene APEX Installation entschieden, müssen Sie als Erstes als Instanzadministrator einen sogenannten WORKSPACE und eine  Workspace-Developer anlegen. (siehe dazu auch Installation Oracle Apex )

Bei der Nutzung des Server von Oracle apex.oracle.com erfolgt dieser Schritt im Rahmen der Erstanmeldung.

Je nach Variante gibt es verschiedene URLs über die Sie die APEX-Entwicklungsumgebung starten. Sie sollten bei allen Varianten zu der in Abbildung 1 dargestellten Login-Seite gelangen.

Abbildung 1: Anmeldung als APEX-Developer
Abbildung 1: Anmeldung als APEX-Developer

Hier melden Sie sich an Ihrem WORKSPACE an.

Anschließend gelangen Sie zur Startseite der APEX-Entwicklungsumgebung.

Abbildung 2: APEX-Entwicklungsumgebung
Abbildung 2: APEX-Entwicklungsumgebung

Dort können Sie die einzelnen Module von APEX starten. Für den Anfang sind für Sie der APPLICATION BUILDER und der SQL-WORKSHOP von Bedeutung.

Über den SQL-WORKSHOP können Sie mit Hilfe verschiedener Werkzeuge in Ihrem Datenbankschema Objekte wie z.B. Tabellen, Views,… und Daten bearbeiten.

Mit dem APPLICATION BUILDER erstellen Sie die APEX-Anwendungen.

Bei der Entwicklung einer APEX Anwendung werden Sie durch unterschiedliche Wizzards unterstützt. Alle diese Assistenten nutzen massiv die Metadaten Ihrer Oracle Datenbank. Die Metadaten der Datenbankobjekte fungieren quasi als Modell ( im Sinne eines MDA-Ansatzes ) für die Erstellung der Anwendung. Aus diesem Grund, ist es ratsam immer zuerst die zugrunde liegenden Datenbankobjekte anzulegen.

SQL-Workshop

Der SQL-Worshop bietet diverse Werkzeuge zum Bearbeiten von Datenbankobjekten.

Abbildung 3: SQL-WORSHOP
Abbildung 3: SQL-WORKSHOP

Der OBJECT BROWSER zeigt Ihnen alle Datenbankobjekte der Schematas, die dem Apex Workspace zugeordnet sind. Diese können mit diesem Tool bearbeitet werden.

Mit dem Werkzeug SQL COMMANDS können Sie direkt SQL-Befehle ausführen.

Hinter dem Bereich SQL SCRIPTS verbirgt sich ein Verwaltungswerkzeug zum Speichern und Ausführen ganzer SQL Skripte.

Der UTILITIES-Bereich fasst nützliche Datenbankwerkzeuge zusammen.

Das sehr mächtige Modul RESTFUL SERVICES ermöglicht es Ihnen Restfull Web Services auf Basis von SQL und Pl/SQL Anweisungen zu definieren.

Tabelle mit dem OBJECT BROWSER erstellen

Wie bereits erwähnt, sollten Sie mit dem Datenmodell beginnen. Anhand der Tabelle cooking_recipe möchte ich Ihnen das Erstellen einer Tabelle mit dem OBJECT BROWSER zeigen.

Starten Sie als erstes den OBJECT BROWSER.

Abbildung 4: Object Browser
Abbildung 4: Object Browser

Auf der linken Seite können Sie mittels verschiedener Filter unterschiedliche Datenbankobjekte anzeigen lassen. Diese lassen sich selektieren und dann über entsprechende Eingabemöglichkeiten bearbeiten.

Um eine neue Tabelle anzulegen, klicken Sie im rechten Bereich auf + und dann auf Tabelle.

Abbildung 5: Tabelle definieren
Abbildung 5: Tabelle definieren

Legen Sie hier die Spalten der Tabelle fest.

Mit Next > geht es weiter.

Abbildung 6: Sequence und Trigger erzeugen
Abbildung 6: Sequence und Trigger erzeugen

Im nächsten Schritt des Wizzards können Sie definieren, wie der Primärschlüssel der Tabelle erzeugt werden soll. Wie Abbildung 6 zeigt, können Sie durch APEX eine Sequence anlegen lassen.

Klicken Sie auf Next > .

Im nächsten Schritt können Sie Foreign Key Constraints anlegen. In diesem Beispiel überspringen Sie den Punkt mit Next > .

Jetzt folgt eine Seite, über die Sie weitere Constraints für Ihre Tabelle ergänzen können. Auch darauf können Sie hier verzichten. Weiter mit Next > .

Abbildung 7: Create Table
Abbildung 7: Create Table

Abschließend bietet der Assistent Ihnen die Funktion sich das SQL Skript anzusehen.


CREATE table "CO_COOKING_RECIPE" (
   "ID" NUMBER,
   "NAME" VARCHAR2(50),
   "DESCRIPTION" VARCHAR2(2000),
   "NUMBER_OF_PERSONS" NUMBER,
   "CREATED_BY" VARCHAR2(50),
   "CREATED" DATE,
   "CHANGED_BY" VARCHAR2(50),
   "CHANGED" DATE,
  constraint "CO_COOKING_RECIPE_PK" primary key ("ID")
)
/

CREATE sequence "CO_COOKING_RECIPE_SEQ"
/

CREATE trigger "BI_CO_COOKING_RECIPE"
  before insert on "CO_COOKING_RECIPE"
  for each row
 begin
   if :NEW."ID" is null then
     select "CO_COOKING_RECIPE_SEQ".nextval into :NEW."ID" from sys.dual;
   end if;
end;
/

Lassen Sie die Tabelle über Create Table anlegen.

Abbildung 8: Tabelle im Objekt Browser
Abbildung 8: Tabelle im Object Browser

Sie landen nun wieder im Object Browser. Dort können Sie weitere Strukturanpassungen an der Tabelle vornehmen. Für dieses Beispiel ist das aber nicht notwendig.

Die anderen Tabellen werden in den folgenden Beiträgen angelegt, um andere Werkzeuge und Aspekte der Anwendungsentwicklung mit APEX zu verdeutlichen.

Beitragsreihe

[catlist name=”Apex 18.2 Tutorial”]

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Oracle-Datenbank: Teamwork mit Bordmitteln

Synchronisieren Sie mit DDL-Triggern gemeinsames Arbeiten durch Ein -und Ausschenken von Objekten. Und das sogar für beliebige Datenbanktools.

Viele namhafte Tools zur Datenbankentwicklung bieten Funktionen zur Unterstützung von Entwicklerteams. So können Sie Datenbankobjekte zur Bearbeitung ausschenken. Andere Entwickler, können solange keine Änderungen an diesem Objekt mehr vornehmen, bis dieses wieder eingecheckt wurde. Leider funktioniert das meist nicht werkzeugübergreifend, da diese Tools oft eigene Tabellen für die Verwaltung der Bearbeitungszustände der Datenbankobjekte nutzen.

In diesen Beitrag möchte ich Ihnen eine einfache, aber effektive Möglichkeit zeigen, wie Sie so eine Funktion mit Bordmitteln der Oracle Datenbank selber entwickeln können. Vor allem ist bei der vorgestellten Lösung beachtenswert, dass Sie werkzeugübergreifend funktioniert.

Datenmodell

Benötigt werden zwei Tabellen. Über die Tabelle ddl_object_state wird der Bearbeitungsstand der Datenbankobjekte verwaltet. Sobald ein Entwickler ein Objekt bearbeiten möchten, blockt er dieses. Dabei wird ein Datensatz in dieser Tabelle eingefügt. Ist die Bearbeitung abgeschlossen, so wird das Objekt wieder freigegeben und der zugehörige Einträge entfernt.


CREATE TABLE ddl_object_state (
          object_type VARCHAR2(50 BYTE),
          object_owner VARCHAR2(32 BYTE),
          object_name VARCHAR2(32 BYTE), 
          changed_on DATE,
          changed_by VARCHAR2(32 BYTE)
)
/

Listing 1: Tabelle ddl_object_state

In der zweiten Tabelle ddl_object_state_hist wird beim Ein- und Auschecken neben den Statusinformationen auch ein DDL-Extrakt des bearbeiteten Objektes eingetragen. So dass Sie auf einen Stand zu Beginn und zum Ende der Bearbeitung zurückgreifen können.


CREATE TABLE ddl_object_state_hist
(
   object_type VARCHAR2 (50 BYTE),
   object_owner VARCHAR2 (32 BYTE),
   object_name VARCHAR2 (32 BYTE),
   status_code VARCHAR2 (20 BYTE),
   changed_on DATE,
   changed_by VARCHAR2 (32 BYTE),
   ddl_sql CLOB
)
/

Listing 2: Tabelle ddl_object_state_hist

PL/SQL Package ddl_util

Das PL/SQL Package fasst die benötigten Prozeduren zusammen.

PROCEDURE lock_object (
     p_object_type VARCHAR2,
     p_owner VARCHAR2,
     p_name VARCHAR2,
     p_trace_hist BOOLEAN DEFAULT true
  ) IS
    l_c NUMBER;
    l_locked_by VARCHAR2(32);
    l_changed_on DATE;
    l_ddl_extract CLOB;
BEGIN
    SELECT
      COUNT(*)
     INTO l_c
    FROM ddl_object_state
    WHERE object_owner = p_owner
       AND object_name = p_name;

  IF l_c = 0 THEN
       INSERT INTO ddl_object_state (
          object_type,
          object_owner,
          object_name,
          changed_on,
          changed_by )
       SELECT
          p_object_type,
          p_owner object_owner,
          p_name object_name,
          SYSDATE changed_on,
          ora_login_user changed_by
       FROM dual;

    IF p_trace_hist THEN
       l_ddl_extract := dbms_metadata.get_ddl(p_object_type,p_name);

       INSERT INTO ddl_object_state_hist (
          object_type,
          object_owner,
          object_name,
          ddl_sql,
          status_code,
          changed_on,
          changed_by )
       SELECT
          p_object_type,
          p_owner object_owner,
          p_name object_name,
          l_ddl_extract,
          'LOCK',
          SYSDATE changed_on,
          ora_login_user changed_by
       FROM dual;
    END IF;
 ELSE
      SELECT
          changed_by,
          changed_on
      INTO
        l_locked_by,
        l_changed_on
      FROM ddl_object_state
      WHERE object_owner = p_owner
        AND object_name = p_name;

     IF l_locked_by <> ora_login_user THEN
        raise_application_error(-20001,'Object was already locked by '
             || l_locked_by
             || ' at '
             || TO_CHAR(l_changed_on,'dd.mm.yyyy HH24:Mi:ss') );
     END IF;
 END IF;

END;

Listing 3: Procedure lock_object

Die Prozedur lock_object erhält als Parameter beim Aufruf den Objekttyp, den Besitzer des Objektes und den Namen des Objektes.

Als erstes prüft die Prozedur, ob das Objekt bereits von einem anderen User ausgescheckt wurde. Ist das der Fall wird ein application_error -20001 ausgelöst. Wenn das Objekt nicht in Bearbeitung ist, trägt die Prozedur diese in der Tabelle ddl_object_state ein und extrahiert eine DDL-Anweisung des Objektes. Diese wird dann in der Tabelle ddl_object_state archiviert.

PROCEDURE unlock_object (
     p_object_type VARCHAR2,
     p_owner VARCHAR2,
     p_name VARCHAR2,
     p_trace_hist BOOLEAN DEFAULT true,
     p_secure_mode BOOLEAN DEFAULT true) 
IS
     l_c NUMBER;
     l_locked_by VARCHAR2(32);
     l_changed_on DATE;
     l_ddl_extract CLOB;
BEGIN
     SELECT COUNT(*)
       INTO l_c
     FROM ddl_object_state
     WHERE object_owner = p_owner
       AND object_name = p_name;

 IF l_c = 1 THEN
     SELECT
       changed_by,
       changed_on
     INTO
       l_locked_by,
       l_changed_on
     FROM ddl_object_state
     WHERE object_owner = p_owner
       AND object_name = p_name;

    IF p_secure_mode AND l_locked_by <> ora_login_user  THEN
        raise_application_error(-20002,'You have no permissions in secure mode to unlock the object. The Object was locked by '
              || l_locked_by
              || ' at '
              || TO_CHAR(l_changed_on,'dd.mm.yyyy HH24:Mi:ss') );
    END IF;

    DELETE ddl_object_state
      WHERE object_owner = p_owner
        AND object_name = p_name;

    IF p_trace_hist THEN
      l_ddl_extract := dbms_metadata.get_ddl(p_object_type,p_name);

      INSERT INTO ddl_object_state_hist (
            object_type,
            object_owner,
            object_name,
            ddl_sql,
            status_code,
            changed_on,
            changed_by )
      SELECT
            p_object_type,
            p_owner object_owner,
            p_name object_name,
            l_ddl_extract,
            'UNLOCK',
            SYSDATE changed_on,
            ora_login_user changed_by
      FROM dual;
   END IF;
 
 END IF;

END;

Listing 4: Procedure unlock_object

Um ein Datenbankobjekt nach der Bearbeitung wieder frei zu geben, nutzen Sie die Prozedur unlock_object. Diese prüft im Secure Mode, ob Sie im Vorfeld das entsprechende Objekt auch selber ausgelockt haben. Ist das nicht der Fall, wird der Applikationsfehler -20002 ausgelöst. Ein von Ihnen ausgelocktes Objekt wird durch das Löschen des zugehörigen Eintrags in der Tabelle ddl_object_state wieder zur Bearbeitung frei gegeben. In der Tabelle ddl_object_state_hist wird wieder ein DDL-Extrakt gespeichert.

Objekte, die von einem anderen Entwickler als Sie selbst geblockt wurden, können Sie durch das Setzen des Parameters p_secure_mode = false wieder freigegeben. Auch dabei wird ein Historiendatensatz erzeugt. Anschließend können Sie so den Besitz durch Aufrufen von lock_object übernehmen.

PROCEDURE check_object_state (
             p_object_type VARCHAR2,
             p_owner VARCHAR2,
             p_name VARCHAR2
           );

Listing 5: Procedure check_object_state

Mit der dritten Procedur check_object_state können Sie einfach den Bearbeitungsstand eine Datenbankobjektes überprüfen.

Wie bereits erwähnt, speichern die Prozeduren beim Ein- und Auschecken jeweils ein DDL-Statements in der Historientabelle. Wenn Sie eine genaue Protokollierung aller Anpassungen benötigen, möchte ich Sie auf den Artikel Oracle Datenbankentwicklung: DDL-Trigger zur Auditierung von Strukturänderungen hinweisen.

DDL-Trigger

Anschließend benötigen Sie noch zwei DDL-Trigger, die Sie in dem Entwicklungsschema anlegen müssen.


CREATE OR REPLACE TRIGGER trg_ddl_util_before 
     BEFORE ALTER OR DROP 
    ON DATABASE 
DECLARE 
BEGIN
      IF ora_dict_obj_name NOT IN (
               'TRG_DDL_UTIL_BEFORE',
               'TRG_DDL_UTIL_AFTER',
               'DDL_UTIL' ) 
          AND ora_login_user NOT IN (
               'SYS',
               'SYSTEM' ) 
      THEN
         ddl_util.lock_object(ora_dict_obj_type,ora_dict_obj_owner,ora_dict_obj_name);
      END IF;
END;
/

Listing 6: Trigger trg_ddl_util_before

Der Trigger trg_ddl_util_before wird bei ALTER- und DROP-Anweisungen ausgeführt. Für einen Create-Befehl macht dieser Zeitpunkt keinen Sinn, da das Objekt in der Datenbank noch nicht vorliegen kann.

Bei der Verwendung von DDL-Triggern sollten Sie besondere Vorsicht walten lassen. Da diese Trigger auch bei Änderungen an sich selbst gefeuert werden, kann es vorkommen, dass man bei einer fehlerhaften Programmierung evtl. keine Änderungen mehr an den Triggern vornehmen kann. Aus diesem Grund prüft der Trigger zu Beginn, ob Änderungen an ihm selbst bzw. an dem Trigger trg_ddl_util_after ausgeführt werden sollen. Des Weiteren werden die Accounts das und system von der Verarbeitung ausgenommen. Allerdings würde auch ein invaliden Package ddl_util zu Problemen führen können.

Die eigentlich Logik des Triggers besteht dann nur noch im Aufruf der Prozedur ddl_util.lock_object. Diese prüft, ob das Objekt von einem anderen Entwickler zur Bearbeitung ausgescheckt wurde. In diesem Fall wird wie bereits erwähnt eine Exception gefeuert und so die Änderungen an dem Objekt dem aktuellen Nutzer verwährt. Bei Objekten, die noch nicht ausgescheckt sind, wird das über diesen Trigger automatisch erledigt.

Alternativ kann es aber auch durchaus sinnvoll sein, dass Ausschecken eines Objektes vor der Bearbeitung manuell durch das Aufrufen von  ddl_util.lock_object durchzuführen. So erspart man sich, dass Änderungen beim Speichern durch den Trigger erst im Nachhinein verworfen werden.

CREATE OR REPLACE TRIGGER trg_ddl_util_after 
    AFTER CREATE OR DROP 
 ON DATABASE 
DECLARE 
BEGIN
    IF ora_dict_obj_name NOT IN (
              'TRG_DDL_UTIL_BEFORE',
              'TRG_DDL_UTIL_AFTER',
              'DDL_UTIL')
    AND ora_login_user NOT IN (
              'SYS',
              'SYSTEM' )
    THEN
        IF ora_sysevent = 'CREATE' THEN
            ddl_util.lock_object(ora_dict_obj_type,ora_dict_obj_owner,ora_dict_obj_name);
       END IF;

       IF ora_sysevent = 'DROP' THEN
           ddl_util.unlock_object(ora_dict_obj_type,ora_dict_obj_owner,ora_dict_obj_name,false,true);
       END IF;

    END IF;
END;
/

Listing 7: Trigger trg_ddl_util_after

Wird nun ein neues Objekt angelegt, kann dieses nicht im Vorfeld geblockt werden. In so einem Fall kommt nun der zweite Trigger trg_ddl_util_after ins Spiel. Dieser prüft ob ein Create-Statement ausgeführt wurde. Wenn das der Fall war, wird das neu erstellte Datenbankobjekt automatisch ausgecheckt und der DDL-Extrakt archiviert.

Bei einem Drop-Befehl verhält es sich etwas anders. Hier existiert das Objekt zum Ausführungszeitpunkt ( AFTER ) des Triggers nicht mehr. Es muss aber noch aus der Tabelle ddl_objet_state entfernt werden.

Abbildung 1: Übersicht ddl_util

In Abbildung 1 sehen Sie alle beschriebenen Objekte.

Drop …

Jetzt habe ich der Einfachheit halber Ihnen noch ein kurzes Skript hier eingefügt, mit dem Sie die Tabellen, Trigger und das Package wieder los werden können.


DROP TRIGGER trg_ddl_util_before;
DROP TRIGGER trg_ddl_util_after;
DROP PACKAGE ddl_util;
DROP TABLE ddl_object_state;
DROP TABLE ddl_object_state_hist;

Beispiel

Im Folgenden möchte ich Ihnen die Nutzung der beschrieben Methode anhand einiger kleiner Beispiele demonstrieren. Dazu wurden in dem Schema MY_PROJECTS die beiden Tabellen, das Package und die beiden Trigger angelegt. diesen Account wurde eine Verbindung im SQL Developer hergestellt.

Dann gibt es einen weiteren Account namens DEVELOPER1, welcher mit DBA-Rechten versehen wurde. Der DEVELOPER1  ist via. sqlplus mit der Datenbank verbunden.

Tabelle T1 anlegen

Zu Beginn soll eine Tabelle erzeugt werden.

Abbildung 2: Tabelle T1 anlegen

Wie Sie der Abbildung 2 entnehmen können, wurde die Tabelle T1 ohne Probleme erzeugt. Dabei wurde der Trigger trg_ddl_util_after ausgeführt und ein Lock-Eintrag in der Tabelle ddl_object_state eingefügt.

Abbildung 3: Datenbanktabelle T1 für ausgecheckt

Tabelle T2 erweitern

Jetzt soll der DEVELOPER1 dieser Tabelle eine neue Spalte hinzufügen.

Abbildung 4 : Spalte in T1 ergänzen

Wie zu erwarten war, wird dieser Vorgang mit der Exception ORA-20001 durch den Trigger trg_ddl_util_before unterbunden. Der Meldung können Sie entnehmen, dass die Tabelle durch den User MY_PROJECTS am 17.06.2018 um 20:59:17 gesperrt wurde.

Abbildung 5: Objekt einchecken

Erst wenn der Benutzer MY_PROJECTS die Tabelle wieder zur Bearbeitung frei gibt, kann der DEVELOPER1 die Spalte ergänzen.

Abbildung 6: Spalte hinzufügen

Dies hat wiederum zu Folge, dass die Tabelle jetzt durch den User DEVELOPER1 ausgecheckt wurde.

Tabelle T1 löschen

Setzt nun der User MY_PROJECTS eine Drop Anweisung für die Tabelle T1 ab, wird auch diese mit einer entsprechenden Fehlermeldung abgebrochen.

Abbildung 7: Drop der Tabelle nicht möglich

Möchten Sie jetzt aber die Tabelle trotzdem löschen und die Sperre durch den DEVELOPER1 übergehen, so können Sie das durch den Aufruf der Prozedur unlock_objects mit folgenden Parametern tun.


BEGIN
  DDL_UTIL.UNLOCK_OBJECT(
         P_OBJECT_TYPE = 'TABLE',
         P_OWNER =       'MY_PROJECTS',
         P_NAME =        'T1',
         P_TRACE_HIST =  true,
         P_SECURE_MODE = false
        );
   commit;
END;

Änderungshistorie

Die Trigger bzw. das PL/SQL Package ddl_util sorgen beim Ein- und Auschecken der Datenbankobjekte auch dafür, dass ein DDL-Extrakt in der Tabelle ddl_object_state_hist archiviert wird. So können Sie auf einfache Weise auf ältere Entwicklungsstände zugreifen.

Abbildung 8: Änderungshistorie

Download

Abschließend habe ich Ihnen ein DDL-Script zum Anlegen der beschriebenen Objekte an diesen Beitrag angefügt. Die Verwendung erfolgt aber auf eigene Gefahr.

Oracle-Datenbank: Teamwork mit Bordmitteln Download ddl_util.sql

Dieses DDL-Sript ist im Rahmen des Beitrags Oracle-Datenbank: Teamwork mit Boardmitteln entstanden.

Oracle Application Express – Quick SQL

Low Code Entwicklung von Datenmodellen mit Quick SQL, einer APEX Packaged Application.

Oracle bietet im Rahmen seiner Entwicklungsumgebung APEX sogenannte Packaged Applications. Bei diesen Anwendungen handelt es sich zum Einen um Bespielanwendungen zum Anderen aber auch um produktiv nutzbare Systeme.

Eine dieser Anwendungen ist Quick SQL.

Quick SQL einrichten

Die Installation von Quick SQL geht zügig von der Hand. In APEX angemeldet, klicken Sie auf den Menüpunkt Packed Application.

APEX Packaged Application (Mitgelieferte Anwendungen)

Nun können Sie in der sich öffnenden Übersicht die Packaged Application Quick SQL auswählen.

Quick SQL auswählen

Neben einer Kurzbeschreibung finden Sie auf der sich öffnenden Seite die Schaltfläche Installieren. Folgen Sie dem Installationsassistenten. Fertig.

Starten Sie die Anwendung das erste mal, können Sie sich mit dem bei der Installation gewählten Authentifizierungsverfahren an Quick SQL anmelden. Bei dem ersten Start, müssen Sie noch einige Parameter prüfen und bei Bedarf anpassen. Das stellt sich wie in folgender Abbildung  dar.

QuickSQL einrichten

Datenmodell mit Quick SQL entwerfen

Quick SQL gliedert sich in  zwei Bereiche. Links können Sie sehr kompakt Tabellen und ihre Relationen zueinander definieren.

Rechts wird bei jeder Änderung das zugehörige DDL (Data Definition Language) Skript erzeugt.

Benutzeroberfläche QuickSQL

Als einfaches Beispiel soll ein Datenmodell für ein Projektplanungstool dienen.

Tabellen werden einfach durch die Eingabe des Tabellennamens deklariert. Die zugehörigen Spalten rücken Sie einfach in den folgenden Zeilen ein.

Datenmodell Projektplanung

Quick SQL Eigenschaften

Schauen Sie sich das erzeugte DDL-Script näher an, so sehen Sie, dass eine ID-Spalte als künstlicher Schlüssel erzeugt wurde.  Diese Spalte wird über einen Trigger gefüllt. Auch gibt es mehrere Spalten, in denen Audit-Informationen gespeichert werden. Diese Spalten können beim Einsatz der Tabelle in einer APEX-Anwendung sogar mit den APEX-Account über einen Trigger belegt werden. Dies sind nur zwei Beispiele, die Ihnen Quick SQL bietet. Festlegen können Sie die Generierung dieser Funktionen in den Eigenschaften von Quick SQL.

Quick SQL Eigenschaften

Die Abbildung zeigt nur einen Teil der Möglichkeiten. So können Sie z.B. allen Tabellen einen Präfix voran stellen, Änderungen automatisch über einen Trigger in einer Audit-Tabelle protokollieren und noch vieles mehr erledigen lassen. Nehmen Sie sich Zeit, um diese Möglichkeiten in Gänze kennen zu lernen.

Relationen

Jedem Projekt sollen in dem gezeigten Beispiel n ToDos zugeordnet werden können. Also eine einfache 1:n Beziehung.

Um diese abhängige Tabelle zu erzeugen, geben Sie auf der Ebene der Spalten zunächst ToDos als neuen Tabellennamen ein. In den nächsten Zeilen rücken Sie die Spaltenbezeichner um eine weitere Ebene tiefer ein. Quick SQL erweitert das DDL-Script um die Tabelle ToDos und fügt eine Fremdschlüsselspalte project_id ein.  Neben der Spalte wird auch sofort ein foreign key constraint erzeugt.

Relationen erzeugen

Syntax and Examples

Nähere Informationen über die sehr umfangreichen Möglichkeiten von Quick SQL verbergen sich hinter dem Link Syntax and Examples in der Anwendung.

Fazit

Quick SQL bietet als Low Code Entwicklungstool durch die Nutzung von Konventionen eine enorme Geschwindigkeit bei der Erstellung eines Datenmodells. Auch für nicht APEX-Entwickler verdient diese Anwendung eine genauere Betrachtung.