Immermannstraße 28 - Magdeburg +49 391 50 55 83 53 info@katla-gmbh.de

Inside JACAMAR

JACAMAR Details

Generelle Einordnung der JACAMAR Datenbank

Mit JACAMAR werden keine Londoner Börse oder der Flughafen Frankfurt/ Main datentechnisch abbildbar sein. Höchstgeschwindigkeit, Ausfallsicherheit und Redundanz sind nicht der eigentliche Einsatzzweck von JACAMAR.

Unsere Anwender kommen aus der Office Welt und sind Wissensarbeiter, Projektsteuerer und Planer. Sie nutzen JACAMAR um einen Datenbestand auf einfache Weise weltweit mit Partnern, Kollegen, Kunden zu teilen. Dabei bleibt der Management-Overhead erfreulich gering. Die administrativen Aufgaben (Stichwort: DevOps)  werden  zu 98%  eliminiert: einfache Backups sind zu spiegeln, für den Fall der Fälle – That’s it.

Queries –  Abfragen

In Abfragesprachen wie SQL haben die Elemente textuelle Verweise auf andere Elemente, die sogenannten Foreign Keys. Wenn man solche Beziehungen abfragen will, testet das System bei jeder Abfrage neu, ob es andere Elemente gibt, deren Primary Key mit dem zu betrachtenden  Foreign-Key übereinstimmt. Man kann sich vorstellen, dass dies bei größeren Datenmengen ganz schön Zeit in Anspruch nehmen wird, wenn jedesmal durch den kompletten Datenbestand iteriert werden muss. (Bei modernen Systemen werden häufig verwendete Beziehungen durch sogenannte “Indizees” quasi prophylaktisch schon mal vorausberechnet sind. Das beseitigt aber die grundsätzliche Problematik nicht.)

Auch die Syntax wird entsprechend einfacher:

SQL: text = {selektiere VerknüpftesElement.Feld, wobei
 Element.foreignKey1 = VerknüpftesElement.primaryKey sein muss}
JACAMAR: text = Element.verknüpfung.feld

Gemeinsamer Datenpool – das Repository

Die zentrale Repository-Datei liegt entweder in einem LAN-Netzwerk oder auf einem Webserver. Von dort lädt sich jeder Benutzer die kompletten Daten einmalig in den RAM seines/ihres Rechners. Ab diesem Zeitpunkt ergibt sich für die Anwender die bestmögliche Berechnungs- und Anzeige-Geschwindigkeit, weil alles “In Memory” direkt bereitsteht. Theoretisch könnte jetzt auch die Netzwerkverbindung bis zum nächsten Speichern oder Synchronisieren getrennt werden.

Speicherprozess

Das Speichern im Multi-User-Betrieb funktioniert (stark vereinfacht) so, dass nicht direkt in das zentrale Repository zurückgeschrieben wird, sondern es werden statt dessen die Änderungen in “Change-Records” quasi neben das zentrale Repository gelegt. In regelmäßigen Abständen checken die JACAMAR-Instanzen der parallel arbeitenden Anwender, ob es neue Änderungen gibt und integrieren diese in den jeweiligen lokalen Datenbestand. Der letzte Anwender, der seine Anwendung schließt, gleicht die zentrale Repository-Datei dann wieder ab.