Besonderheiten beim Einsatz mobiler Datenbanken

Datamobil

Rudolf Jansen

Datenbanken gehören als zentraler Bestandteil zu beinahe jeder größeren Applikation. Insbesondere im Bereich von Enterprise-Anwendungen handelt es sich dabei in der Regel auch um Enterprise-Datenbanken, die auf Serverrechnern laufen, deren Hardware-Ausstattung auf die zentrale Bedeutung der Datenbank ausgerichtet ist. Anders sieht die Situation bei der Erstellung mobiler Anwendungen aus, bei der im Hinblick auf Ressourcenausstattung andere Voraussetzungen vorliegen. Dieser Artikel stellt die Anforderungen und Besonderheiten beim Einsatz von Datenbanken in mobilen Anwendungen vor.

Entwickler von Java-Anwendungen, die Applikationen mit allen Java-Editionen (J2SE, J2EE und J2ME) erstellen, kennen die Besonderheiten, die bei der Erstellung von mobilen Java-Anwendungen mit J2ME zu beachten sind. Grundsätzlich gelten die aus der Enterprise-Welt bekannten Java-Regeln zwar auch im Micro-Umfeld. Insbesondere mit Hinblick auf die nur begrenzt zur Verfügung stehenden Hardware-Ressourcen sind aber eine Vielzahl von Einschränkungen zu beachten. Neben diesen zur Entwicklungszeit relevanten Beschränkungen sind die Enterprise-Java-Gegebenheiten aber auch bezüglichDeployment und Runtime-Environment nicht ohne weiteres auf den mobilen Bereich übertragbar.

Im Java-Umfeld wird den mobilen Anwendungen ein großes Zukunftspotential vorhergesagt. Dementsprechend finden sich J2ME-Vorträge auf beinahe jeder bekannten Java-Konferenz. Auch die Anbieter von Entwickler-Tools integrieren J2ME-Komponenten in ihre Produkte oder veröffentlichen eigene Mobile Editions ihrer Tools. In der Praxis ist aber die Zahl der verfügbaren mobilen Anwendungen sowie das Know-how über mobile Techniken im Vergleich zu den entsprechenden Enterprise-Anwendungen bzw. Kenntnissen noch sehr gering.

Ähnlich sieht es im Datenbanksektor aus. Die Anbieter der großen kommerziellen Datenbanken bieten ihr Produkt auch jeweils als Spezialedition für den mobilen Bereich an, z.B.:

  • IBM DB2 Everyplace [1]
  • Microsoft SQL Server CE Edition [2]
  • Oracle 9i Lite [3]

Da die Marketingaufwendungen für diese Produkte und damit auch die Zahl der bekannten Anwendungen geringer sind als die für ihre großen Brüder aus dem Enterprise-Bereich, sind die Produktnamen sowie die Besonderheiten, die bei ihrem Einsatz zu beachten sind, weniger bekannt.

Anforderungen an mobile Datenhaltung

Welche technischen und organisatorischen Besonderheiten sind bei der mobilen Datenhaltung zu beachten? Die größte Beachtung verdienen hierbei sicher die nur begrenzt zur Verfügung stehenden Hardware-Ressourcen. Insbesondere für den Datenbankbereich kann dies zu im Enterprise-Bereich nahezu unbekannten Fragestellungen führen. Auch in der zurzeit schwierigen wirtschaftlichen Situation vieler Unternehmen ist eine ausreichende Hardware-Ausstattung der Datenbankserver in der Regel vorhanden. Die Datenhaltung als zentrale Komponente für eine Vielzahl von unternehmenskritischen Anwendungen gerät nicht so schnell in das Visier von einsparwilligen Finanzverantwortlichen. Im mobilen Bereich sind Hardware-Erweiterungen dagegen Grenzen gesetzt. Dabei handelt es sich in der Regel nicht um finanzielle Grenzen, sondern um technische: Mobile Geräte sind gekennzeichnet durch eingeschränkte Speichermöglichkeiten sowohl bei der Memory-Ausstattung als auch bezüglich. Plattenkapazität. Auch die Leistung mobiler Prozessoren ist nicht mit der Leistung von Enterprise-Servern mit mehreren Prozessoren vergleichbar.

Ein weiterer Aspekt, der im Enterprise-Bereich eigentlich als selbstverständlich angesehen wird, ist die Energieversorgung. Diese steht im mobilen Bereich nicht unbegrenzt zur Verfügung. Rechenleistung kann hier also nicht als unlimitiert und umsonst zur Verfügung stehend angesehen werden. Ausfallsicherheit bezüglich Strom- bzw. Netzanbindung zur Außenwelt ist ebenfalls nicht mit den Gegebenheiten im Enterprise-Bereich vergleichbar. Entwickler von Enterprise-Java-Anwendungen müssen sich über diese Datenbank-Administrations-Aspekte in der Regel keine Gedanken machen. Sie gehen davon aus, dass die Datenbank inklusive Netzwerkanbindung stets in vollem Leistungsumfang zur Verfügung steht. Das ist schließlich die Aufgabe derjenigen, die für den Betrieb der Server verantwortlich sind. Ein administrativer Eingriff auf das mobile Gerät ist zur Laufzeit aber in der Regel nicht oder nur eingeschränkt möglich, so dass eine Datenbankanwendung in dieser Beziehung keine hohen Ansprüche stellen darf.

Auch der Punkt Sicherheit, also die Verschlüsselung der Daten sowohl bei der Speicherung als auch beim Transport zum oder vom Server, spielt im mobilen Umfeld eine wichtige Rolle. Die Mobilität des Gerätes bietet zwar viele Vorteile für den Nutzer, sie vereinfacht aber leider auch den unbefugten Zugriff auf die auf dem Gerät gespeicherten Daten: Der Diebstahl eines mobilen Gerätes (Handy, PDA, …) ist wesentlich einfacher und damit wahrscheinlicher als das Entwenden eines Enterprise-Datenbankservers.

Anwendungen

Eine weitere Anforderung an mobile Datenhaltung ist die Replikation mit Serverdaten. Häufiges Einsatzgebiet von mobilen Anwendungen ist die Bereitstellung von Software für Außendienstmitarbeiter von Unternehmen. Diese sollen bei ihrer Arbeit beim Kunden vor Ort sowohl Zugriff auf die relevanten Daten haben, die sie für die Kundenberatung benötigen als auch neue Kundendaten direkt auf ihren mobilen Geräten eingeben können. Das mobile Gerät ist aber nicht der endgültige Speicherort für diese Daten. Die Daten vom mobilen Gerät müssen noch auf die unternehmensinterne Enterprise-Datenbank übertragen wurden. Gemäß dieser Standardanforderung sind auch die speziellen Produkte der Datenbankhersteller für den mobilen Bereich ausgelegt. Sie bestehen in der Regel aus einer abgespeckten Version der Enterprise-Datenbank sowie einem Replikationsmechanismus, mit dem der Abgleich der mobil erfassten Daten mit den Serverdaten durchgeführt werden kann (Abb. 1). Am Beispiel der beiden führenden Anbieter IBM und Oracle wird dies noch näher beschrieben.

Abb. 1: Datenabgleich von mobilen Geräten mit dem Server

Neben solchen mobilen Anwendungen für mobile Mitarbeiter ist aber auch der gesamte Bereich Embedded Systeme ein mögliches Einsatzgebiet für mobile Datenbanken. Beispielhaft sei hier nur der Bereich automobile Informationssysteme genannt. Eine Speicherung von Daten aus den folgenden Bereichen erfordert meist den Einsatz von Datenbanktechnologie:

  • Systemüberwachung aller Fahrzeugkomponenten.
  • Aufzeichnung von Fahrwegen und Bereitstellung von Straßenkarten zwecks Navigation und Verkehrsdatenerfassung.
  • Bereitstellung von Internet-Technologie, Unterhaltungselektronik und anderen Mehrwertdiensten in höherwertigen Fahrzeug-Informationssystemen.

Ähnlich wie in J2SE-Standardanwendungen stellt sich bei kleineren Applikationen im mobilen Bereich zunächst die Frage, ob für die Datenhaltung überhaupt eine Datenbank eingesetzt werden muss. Wird nur eine einfache Datenablage in geringem Umfang benötigt und sind die Daten wirklich nur für die betreffende Anwendung relevant, so bietet sich eine Flatfile-Speicherung als Alternative zu komplexeren Datenbanken an. Diese Art der Datenhaltung ist auch im Bereich J2ME möglich. Konfigurationsdaten für Handyspiele wären ein Beispiel für eine solche Datenhaltung, bei der kein Abgleich der Daten mit serverseitig gespeicherten Daten erforderlich ist. Für J2ME existiert innerhalb des Mobile Information Device Profile (MIDP) das Record Management System (RMS), das eine solche dateibasierte Datenhaltung mit Hilfe so genannter Record Stores vornimmt. Zur Verfügung gestellt werden API-Funktionen zur Anlage von Record Stores (vergleichbar mit Tabellen in relationalen Datenbanken):

public static RecordStore openRecordStore (String recordStoreName, boolean createIfNecessary)
public void closeRecordStore()
public static void deleteRecordStore (String recordStoreName )

sowie zur Pflege von Records innerhalb dieser Record-Store-Dateien:

public int addRecord( byte[] data, int offset, int numBytes)
public void deleteRecord(int recordId)
public int getRecord(int recordId, byte[] buffer, int offset)
public byte[] getRecord(int recordId)
public void setRecord( int recordId, byte[] newData, int offset, int numBytes)

Ein Record besteht aus den eigentlichen Daten in Form eines Byte-Arrays sowie einer eindeutigen ID in Integer-Format. Offensichtlich hat eine solche dateibasierte Speicherung analog zur Flatfile-Speicherung in J2SE-Applikationen ihre Grenzen: Sobald grundlegende Datenbankeigenschaften wie z.B. Transaktionsverarbeitung und Integritätsregeln gefragt sind, sind diese über Record Stores entweder gar nicht oder nur mit hohem manuellen Aufwand realisierbar. Spätestens hier wird sich der Entwickler solcher Anwendungen also nach Möglichkeiten zum Einsatz richtiger Datenbanken umsehen.

Eine Alternative sind dabei Java-Embedded-Datenbanken, die als JAR-Datei in die Anwendung eingebunden werden und in derselben JVM ablaufen wie der Rest der Anwendung. Eine ausführliche Vorstellung von Java-Embedded-Datenbanken enthält die vorige Ausgabe des Java Magazins [4].
Spätestens wenn der Abgleich der mobilen Daten mit Enterprise-Datenbanken ins Spiel kommt, werden automatisch die bereits erwähnten mobilen Spezialanfertigungen der großen Datenbankhersteller in Betracht gezogen. Eine echte Auswahl aus den am Markt erhältlichen Produkte hat der Entwickler von mobilen Anwendungen aber meist nicht: Maßgeblich ist nämlich in der Regel die bereits vorhandene Datenbanksoftware auf dem Enterprise-Server, deren kleiner Bruder vom gleichen Anbieter dann auf dem mobilen Gerät zum Einsatz kommen wird. Im folgenden Kapitel werden diese speziell für den Einsatz im mobilen Bereich angebotenen Produkte der beiden Marktführer im Enterprise-Datenbanksektor (IBM und Oracle) näher beschrieben.

Hingewiesen sei an dieser Stelle auch auf eine speziell an die Gegebenheiten im mobilen Bereich abgestimmte JDBC-Spezifikation [5]. Über den JSR 169 wird in diesem JDBC Optional Package for CDC/Foundation Profile eine Untermenge der JDBC 3.0-Spezifikation definiert, die den Zugriff auf JDBC-Datenbanken aus Connected Device Configuration (CDC)-Applikationen im J2ME-Umfeld standardisiert. Eine detaillierte Vorstellung dieses JDBC-Subsets ist für eine der folgenden Ausgaben dieser Datenbank-Rubrik des Java Magazins vorgesehen.

Verfügbare Datenbankprodukte

Das Produkt IBM DB2 Everyplace liegt derzeit in Version 8.1. vor [2] und kann als mobiles Gegenstück zur DB2-Datenbank angesehen werden. Das Produkt wird in zwei verschiedenen Varianten angeboten: Die DB2 Everyplace Database Edition beinhaltet die Datenbank für den Einsatz auf dem mobilen Gerät. Unterstützt werden u.a. folgende Betriebssysteme:

  • Embedded Linux,
  • Palm OS,
  • QNX Neutrino,
  • Windows CE sowie
  • Symbian EPOC.

Zusätzlich zur Datenbank enthält die DB2 Everyplace Enterprise Edition noch den DB2 Everyplace Sync Server. Über diesen kann ein uni- oder bidirektionaler Abgleich von Datensätzen der mobilen Datenbank sowie der Server-Datenbank vorgenommen werden. Haupteinsatzgebiet ist dabei naturgemäß ein Abgleich mit der hauseigenen IBM DB2 Universal Datenbank, aber auch ein Einsatz in Verbindung mit anderen JDBC-fähigen Datenbanken ist möglich. Die DB2 Everyplace Datenbank benötigt auf dem mobilen Client nur knapp 200 KB Speicher und wird nicht als Standalone-Prozess, sondern als Shared Library zur Verfügung gestellt. Bei der Architektur der Datenbank-Engine wurde auf eine weitgehende Plattformunabhängigkeit geachtet. Erst auf einer sehr tiefen Ebene innerhalb der Schichtenarchitektur erfolgt beim Zugriff auf die Betriebssystem-Dateien eine Abpictureung auf plattformspezifische Methoden. Als Folge können Datenbanken ohne Dateikonvertierung von einem unterstützten Betriebssystem auf ein mobiles Gerät mit einem anderen Betriebssystem übertragen werden. Den auf dem mobilen Gerät nur begrenzt zur Verfügung stehenden Ressourcen trägt IBM DB2 Everyplace auch bei der Verarbeitung von Datenbankabfragen Rechnung. Eine Optimierung von Abfragen erfolgt nicht – wie bei großen Enterprise-System üblich – auf den Ergebnissen eines Cost-Based-Optimizers, sondern nach heuristischen Regeln, bei denen die typische Anforderung von mobilen Applikationen nach einer möglichst schnellen Verfügbarkeit stellen der ersten Ergebniszeilen im Vordergrund steht. Über den bereits erwähnten DB2 Everyplace Sync Server sowie sein Gegenstück auf dem mobilen Gerät, den DB2 Everyplace Sync Client, werden zusätzlich so genannte Remote Stored Procedures (RSP) angeboten. Gedacht sind diese für Datenmengen, die aufgrund ihres Speicherbedarfs nicht oder nur mit Einschränkungen für die übrigen Applikationen auf dem mobilen Gerät gespeichert werden und darüber hinaus auch nur selten benötigt werden. Diese können weiterhin auf dem Enterprise-Server gespeichert und über RSPs, die auf dem mobilen Gerät laufen, abgefragt werden.

IBM-Konkurrent Oracle bietet mit der Oracle 9i Lite Datenbank eine ähnliche mobile Variante seiner Enterprise-Datenbank Oracle 9i an. Der Datenabgleich zwischen mobiler Datenbank und dem Server wird bei Oracle über den Consolidator durchgeführt. Wie auch die IBM DB2 Everyplace-Datenbank bietet Oracle 9i Lite nur eine Teilmenge der aus dem Enterprise-Bereich bekannten SQL- und Datenbankfunktionen an.

Einschränkungen bei mobilen Datenbanken

Am Beispiel von Oracle 9i Lite soll der folgende Auszug zeigen, welche Einschränkungen ein Entwickler von mobilen Anwendungen auf der Basis von Oracle 9i Lite beachten muss. Dabei handelt es sich meist um ressourcenaufwendigere Funktionen, deren Fehlen zwar zu weniger Flexibilität gegenüber Enterprise-Anwendungen führt, durch deren Verzicht aber den speziellen Gegebenheiten auf dem mobilen Gerät Rechnung getragen wird.
Folgende Funktionen stehen bei Einsatz von Oracle 9i Lite nicht zur Verfügung:

  • Klauseln zur physikalischen Speicherung innerhalb von CREATE TABLE-Anweisungen (z.B. PCTFREE).
  • INSTEAD-OF-Trigger, Trigger auf Views.
  • Set-Klauseln mit mehrelementigen Subqueries innerhalb von UPDATE-Befehlen.
  • Datenbank-Links.
  • PL/SQL-Stored Procedures und Stored Functions mit Ausnahme von Java Stored Procedures.
  • Rollback-Segmente.
  • Tablespaces.

Bei der Portierung von Datenbank-Anwendungen aus dem Enterprise-Bereich in den mobilen Bereich ist außerdem zu beachten, dass sich die von der Oracle 9i Lite Datenbank erzeugten Fehlermeldungen und Fehlercodes von den aus dem Enterprise-Bereich bekannten Meldungen und Codes unterscheiden können. Auch die Tatsache, dass Oracle 9i Lite eine Transaktion bereits beim ersten SELECT-Statement beginnt und – abhängig vom gesetzten Isolation Level – somit auch ein SELECT in einer Verbindung einen späteren UPDATE-Befehl aus einer anderen Verbindung heraus sperren kann, ist zu beachten. In diesem Fall müsste dann der SELECT-Befehl in der ersten Verbindung über ein COMMIT freigegeben werden, um den UPDATE-Befehl über die zweite Verbindung ausführen zu können.

Geschrieben von
Rudolf Jansen
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.