as a PDF

Transcription

as a PDF

Evaluierung des Leistungsvermögens von
Datenbanken im Umfeld mobiler Anwendungen
Studienarbeit
Universität Rostock
Institut für Informatik
vorgelegt von:
Andreas Franz
geboren am 14.03.1980 in Kyritz
andreas.franz@stud.uni-rostock.de
Betreuer:
Prof. Dr. rer. nat. habil. Andreas Heuer, Universität Rostock
Dipl.-Inf. Sven Gabrecht, Fraunhofer IGD Rostock
Dipl.-Inf. Andre Zeitz, Universität Rostock
Datum:
30. August 2004
1
Zusammenfassung
Der wachsende mobile Datenzugriff und die Entwicklung immer leistungsfähiger mobiler Hardware erlauben die Nutzung von mobilen Datenbanksystemen auf Mobiltelefonen und Handhelds. Diese Arbeit untersucht die Anforderungen an mobile Datenbanken. Die aktuell verfügbare Hardware, die Einsatzbereiche und die Architekturkomponenten werden auch kurz betrachtet. Im Hauptteil dieses Textes werden die Fähigkeiten
existierender mobiler Datenbanksysteme wie z.B. die smartDB analysiert. Außerdem
soll die mobile Datenbank smartDB im Rahmen dieser Arbeit auf die Handyplattform
portiert werden.
Abstract
The increasing mobile data access and the development of more powerful mobile hardware allow the utilisation of mobile database systems on mobile phones and handhelds.
This work examines the requirements of mobile databases. The current available hardware, the field of application and the components of the architecture are also considered
shortly. In the main part of this text the capabilities of existing mobile database systems
like the smartDB are analysed. Furthermore the mobile database smartDB should be
ported to the cellular phone platform within this work.
ACM CR-Klassifikation:
• C.5.3 [Computer System Implementation]: Microcomputers – Portable Devices
(e.g., laptops, personal digital assistants)
• H.2.4 [Database Management]: Systems
Key Words:
• Mobile Databases, smartDB, Handy, Java 2 Micro Edition
Inhaltsverzeichnis
1 Einleitung
4
2 Mobile Datenbanken
2.1 Charakteristika von Datenbanken . . . . . . . .
2.2 Eigenschaften verteilter Datenbanken . . . . . .
2.3 Kriterien für mobile Datenbanken . . . . . . . .
2.4 Diskussion der Datenbankmerkmale . . . . . . .
2.5 Hardware für mobile Anwendungen . . . . . . .
2.6 Einsatzbereiche für mobile Datenbanken . . . .
2.7 Architektur mobiler Datenbanksysteme . . . . .
2.7.1 Replikation und Synchronisation . . . . .
2.7.2 Speichertechniken und Zugriffsstrukturen
2.7.3 Anfrageverarbeitung . . . . . . . . . . .
2.7.4 Transaktionsverarbeitung . . . . . . . .
2.7.5 Sicherheit . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
5
5
7
8
9
10
13
14
14
15
16
16
17
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
21
23
24
25
26
26
27
29
30
32
33
34
34
35
4 Implementierungsarbeiten
4.1 Java 2 Micro Edition . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Konfigurationen und Profile . . . . . . . . . . . . . . . . . . . .
4.1.2 Details zu CLDC und MIDP . . . . . . . . . . . . . . . . . . . .
38
39
40
40
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3 Existierende Datenbanksysteme
3.1 IBM DB2 Everyplace 8.1 . . . . . . . . . . . . . . . . . . . .
3.2 Oracle Database Lite 10g . . . . . . . . . . . . . . . . . . . .
3.3 Microsoft SQL Server 2000 Windows CE 2.0 . . . . . . . . .
3.4 Sybase SQL Anywhere Studio 9 . . . . . . . . . . . . . . . .
3.5 Tamino Mobile 4.0 . . . . . . . . . . . . . . . . . . . . . . .
3.6 Borland JDataStore 7 . . . . . . . . . . . . . . . . . . . . . .
3.7 Versant/Poet FastObjects j2 und e7 . . . . . . . . . . . . . .
3.8 DataMirror PointBase Micro und Embedded 5.0 . . . . . . .
3.9 Mimer SQL Engine, Mobile und Embedded 9.2 . . . . . . .
3.10 Birdstep RDM Embedded 7.1 und Mobile 3.0 . . . . . . . .
3.11 McObject eXtremeDB 2.3 . . . . . . . . . . . . . . . . . . .
3.12 smartDB – eine mobile Datenbank . . . . . . . . . . . . . .
3.12.1 Analyse der vorhandenen Fähigkeiten . . . . . . . . .
3.12.2 Verbesserungsmöglichkeiten für zukünftige Versionen
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
3
4.1.3 Record Management System – eine einfache Datenbank . . . . .
4.1.4 MIDlets – die MIDP-Anwendungen . . . . . . . . . . . . . . . .
Anforderungen und Restriktionen bei der Programmierung der smartDB
mit J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2.1 JOIN-Implementierung – ja oder nein? . . . . . . . . . . . . . .
4.2.2 Varianten von Sortierverfahren . . . . . . . . . . . . . . . . . . .
4.2.3 Probleme und Lösungen bei großen Datenmengen . . . . . . . .
Datentypen und Struktur des Dateiformats . . . . . . . . . . . . . . . .
Definition und Ausführung von Anfragen . . . . . . . . . . . . . . . . .
Tabellendaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Anfrageergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Entwicklungsumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . .
42
43
5 Performance und Kompatibilität
5.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Tests auf Anfragezeiten und Speicherverbrauch . . . . . . . . . . . . . .
5.3 Getestete mobile Geräte . . . . . . . . . . . . . . . . . . . . . . . . . .
53
53
54
57
6 Zusammenfassung und Ausblick
62
4.2
4.3
4.4
4.5
4.6
4.7
43
44
45
46
47
48
50
51
51
Kapitel 1
Einleitung
Viele Informationen sind weltweit für den elektronischen Zugriff verfügbar. Die Nutzer greifen auf diese Daten jedoch nicht nur über stationäre Computer zu, sondern
zunehmend über mobile Geräte wie z.B. Notebooks, intelligente Mobiltelefone (Smartphones) und Personal Digital Assistants (PDAs). Durch das Mobile Computing steigen
die Anforderungen an die lokale Datenhaltung und führen zur Entwicklung immer leistungsfähiger mobiler Endgeräte, die eine akzeptable Performance bei der Verwendung
von Datenbanksystemen bieten.
Diese Studienarbeit konzentriert sich auf die Evaluierung des Leistungsvermögens existierender Datenbanksysteme für Smartphones und PDAs, da diese mobilen Geräte noch
stark limitierte Ressourcen (z.B. Bildschirm-, Speichergröße und Akkukapazität) haben und somit besondere Anforderungen an die Software stellen. Im Gegensatz dazu
sind Notebooks teilweise fast genauso leistungsfähig wie Workstations, jedoch ist ihre
Betriebsdauer stets von der Batterielaufzeit abhängig. Viele der in den nachfolgenden
Abschnitten vorgestellten Anforderungen und Konzepte für mobile Datenbanken gelten
aber genauso für Notebooks, da in beiden Fällen ein verteiltes Datenbanksystem mit
mobilen Clients zu entwickeln ist.
Des Weiteren werden verschiedene mobile Datenbanken und ihre Funktionalitäten vorgestellt. Eines dieser Systeme ist die smartDB, die vom Fraunhofer Institut für Graphische Datenverarbeitung in Rostock entwickelt wurde. Die smartDB ist ein rudimentäres, relationales Datenbanksystem für PDAs und Smartphones. Es wird z.B. für mobile Messeinformationssysteme eingesetzt und wird im Rahmen dieser Studienarbeit
genauer betrachtet. Außerdem soll die smartDB auf die Handyplattform übertragen
werden und um weitere Funktionen ergänzt werden.
4
Kapitel 2
Mobile Datenbanken
Vor der Betrachtung der Anforderungen an mobile Datenbanksysteme sollen noch einmal kurz die Charakteristika für relationale Datenbanken und die Eigenschaften verteilter Datenbanken wiederholt werden. Darauf aufbauend erfolgt die Definition von
Kriterien für mobile Datenbanksysteme und die Diskussion von Gemeinsamkeiten und
Unterschieden mit relationalen und verteilten Datenbanken. Danach werden die Einsatzbereiche, die aktuell verfügbare Hardware und die Architekturkomponenten einer
mobilen Datenbank detaillierter dargestellt.
2.1
Charakteristika von Datenbanken
Das Ziel der Entwicklung von Datenbanksystemen (DBS) ist die Beseitigung der Datenredundanz, die durch die mehrfache Speicherung von Daten in verschiedenen Anwendungsprogrammen auftritt, und die effiziente Verwaltung großer Datenmengen. Die
Aufgaben von Datenbank-Managementsystemen (DBMS) werden durch die neun Kriterien von Codd beschrieben:
• Integration – einheitliche Verwaltung aller von Anwendungen benötigten Daten.
• Operationen – zum Speichern, Suchen und Ändern des Datenbestands.
• Katalog – zum Zugriff auf die Datenbeschreibungen.
• Benutzersichten – zur Auswahl relevanter Daten und Strukturierung des Datenbestands.
• Konsistenzüberwachung – zur Gewährleistung korrekter Datenbankinhalte
und korrekter Änderungsoperationen.
• Zugriffskontrolle – um unautorisierte Datenzugriffe auszuschließen.
• Transaktionen – zur Zusammenfassung von Datenbankänderungen zu unteilbaren Funktionseinheiten.
• Synchronisation – von konkurrierenden Transaktionen zur Vermeidung von
Konflikten.
5
KAPITEL 2. MOBILE DATENBANKEN
6
• Datensicherung – um Datenwiederherstellung bei Systemfehlern zu ermöglichen.
Bei der Architektur von Datenbanksystemen unterscheidet man drei Ebenen. Die externe Ebene beschreibt die Sicht einer konkreten Anwendung auf die gespeicherten Daten,
die konzeptuelle Ebene gibt eine logische und einheitliche Gesamtsicht auf den Datenbestand und die interne Ebene veranschaulicht die tatsächliche, interne Realisierung
der Datenspeicherung. Die Abbildung 2.1 aus [HS00] zeigt die einzelnen Komponenten
eines Datenbank-Managementsystems. Weitere Details dazu und zum Relationenmodell sowie der Datenbanksprache SQL kann man z.B. [HS00, HS99] entnehmen.
Abbildung 2.1: Architektur eines Datenbanksystems
Klassischerweise werden Datenbanken im kommerziellen Bereich bei Buchhaltungssystemen, Auftragserfassungssystemen, Bibliothekskatalogen und Personendatenbanken eingesetzt. Man erkennt an diesen Beispielen, dass es sich dabei um stationäre
Datenbanken handelt, die durch folgende Eigenschaften gekennzeichnet sind:
• zentrale Verwaltung aller Daten in einem Datenbankserver auf den viele Nutzer
zugreifen können und somit viele I/O-Operationen verursachen.
• auf Grund der vorhergehenden Aussage ist eine ständige Netzwerkverbindung
unerlässlich.
• die Hardware stationärer Datenbanken stellt große Speichermengen und leistungsstarke Prozessoren zur Verfügung, um eine akzeptable Performance zu bieten.
• es gibt keine Mobilität von Nutzern, Computern und Informationen, da sich der
Nutzer stets an einen Rechner setzen muss, um eine Verbindung zur Datenbank
herzustellen und seine Anfragen zu formulieren.
2.2
7
Eigenschaften verteilter Datenbanken
Bei einem verteilten Datenbanksystem (VDBS) werden die Datenbankdaten auf verschiedene Rechner verteilt. Man unterscheidet dabei die Replikation der selben Daten auf mehreren Servern aus Gründen der Effizienz oder der Ausfallsicherheit und
die Partitionierung bestimmter Teildaten auf verschiedenen Rechnern. Analog zu den
neun Kriterien von Codd kann man als Anforderungen für ein verteiltes DatenbankManagementsystem (VDBMS) die 12 Regeln von Date formulieren. Genau genommen
sind es 13 Regeln, da die Verteilungstransparenz implizit vorausgesetzt wird.
• Verteilungstransparenz – die Verteilung vor dem Benutzer geheim halten.
• Lokale Autonomie – Zugriff auf die bei einem Knotenrechner gespeicherten
Daten unabhängig von anderen Rechnern.
• Unabhängigkeit von zentralen Systemfunktionen – da sie der Flaschenhals
verteilter Systeme sind (Leistungsengpass).
• Hohe Verfügbarkeit – ununterbrochenen Datenbankbetrieb auch bei Rechnerausfällen und Netzrekonfigurationen gewährleisten.
• Ortstransparenz – Speicherort bestimmter Daten vor dem Nutzer verbergen.
• Fragmentierungstransparenz – interne Aufteilung von Datenbankobjekten
(Partitionierung) vor dem Benutzer verstecken.
• Replikationstransparenz – Datenreplikation zur Leistungssteigerung und Erhöhung der Ausfallsicherheit sollte auch unsichtbar bleiben.
• Verteilte Anfragebearbeitung – durch den Optimierer und nicht dem Benutzer realisieren.
• Verteilte Transaktionsverwaltung – korrekte Transaktionen garantieren.
• Hardware-Unabhängigkeit – Datenbankverarbeitung auf unterschiedlicher
Hardware ermöglichen.
• Betriebssystem-Unabhängigkeit – Datenbankverarbeitung auf verschiedenen
Betriebssystemen unterstützen.
• Netzwerk-Unabhängigkeit – Datenbankverarbeitung bei heterogenen Netztechnologien erlauben.
• Datenbanksystem-Unabhängigkeit – Datenbankverarbeitung unter Nutzung
verschiedener Knoten-DBMS gestatten.
Diese Regeln sind nur in gewissen Sinne erreichbar bzw. die Unabhängigkeit vom Datenbanksystem in vielen Fällen gar nicht. Bei der Architektur von verteilten Datenbanken wird die klassische Drei-Ebenen-Architektur erweitert. Die globalen externen
Schemata beschreiben die anwendungsspezifische Darstellung auf der externen Ebene.
8
Sie werden ausschließlich auf dem globalen konzeptuellen Schema definiert, das den integrierten, globalen Datenbestand ohne Hinweise auf die Verteilung der Daten abbildet.
Das Fragmentierungsschema definiert die Aufteilung der Datenbankobjekte auf Teilobjekte. Das Allokationsschema stellt die Zuordnung von Fragmenten zu Knoten dar. Eine
mehrfache Zuteilung realisiert eine Replikation von Daten auf mehreren Rechnern. Die
letzten drei Schemaebenen werden zum globalen Schema zusammengefasst, das auf die
Komponenten-DBMS der Knoten zugreift. Auf den Knoten-DBMS übernehmen die lokalen Transformationsschemata die Vereinheitlichung heterogener Datendarstellungen
und es existieren lokale konzeptuelle sowie interne Schemata. Daran erkennt man, dass
die Autonomie der Teilsysteme stark eingeschränkt ist. Demzufolge ist ein Zugriff über
lokale externe Schemata nicht möglich. Das geht jedoch mit föderierten Datenbanken.
Detaillierte Informationen zu verteilten Datenbanken findet man z.B. in [HS99].
2.3
Kriterien für mobile Datenbanken
Im Gegensatz zu den in den vorhergehenden Abschnitten beschriebenen Merkmalen
von Datenbanken hat man im Umfeld mobiler Anwendungen andere bzw. zusätzliche
Anforderungen an ein Datenbanksystem. Das sind folgende Anforderungen:
• Location Based Services (LBS) – die zentrale Aufgabe mobiler Datenbanken
besteht darin, dem Nutzer Zugang zu den von ihm gewünschten Informationen
an jedem Ort weltweit und zu jeder Zeit zu ermöglichen. Die Sicherheit sensitiver
Nutzerdaten ist dabei zu gewährleisten.
• Mobilität und Situation Awareness – es gibt eine ausgeprägte Mobilität der
Nutzer, Computer und Informationen. Daher müssen die Daten dynamisch in
Abhängigkeit vom aktuellen Kontext geliefert werden.
• Synchronisation und Replikation – die Daten werden auf mehrere Server und
mobile Clients verteilt. Folglich sind intelligente Synchronisations- und Replikationsmechanismen inklusive Datenkompression zwischen den beteiligten Computern notwendig, um einen konsistenten Datenbankzustand zu erhalten.
• Begrenzte Hardwareressourcen – die Hardware mobiler Geräte ist in ihrer
Leistungsfähigkeit noch sehr limitiert. Deshalb sind ressourcenschonende, mobile
Datenbanksysteme für eine akzeptable Performance notwendig.
• Unterbrochene Kommunikationsverbindungen und Caching – auf Grund
limitierter Ressourcen besteht keine ständige Verbindung zwischen dem Datenbankserver und dem mobilen Client. Deshalb greifen gegenüber klassischen Datenbanken weniger Nutzer gleichzeitig auf die Daten zu. Sie verursachen weniger
I/O-Operationen, jedoch führt das zu höheren Kosten beim Verbindungsaufbau
und -abbau. Das Datenbanksystem sollte häufige Datenzugriffe mit intelligenten
Caching-Strategien verhindern, um die Verbindungskosten zu minimieren. Beispielsweise kann man bei ähnlichen oder genauer spezifizierten Anfragen schon
vorhandene Anfrageergebnisse wieder verwenden.
2.4
9
Diskussion der Datenbankmerkmale
Die aufgezählten Aspekte im Abschnitt Charakteristika von Datenbanken zeigen, dass
viele dieser Anforderungen auch im mobilen Bereich zutreffen, wenn auch in modifizierter Form. Die Hauptziele bei der Entwicklung eines Datenbanksystems – Redundanzbeseitigung und effiziente Datenverwaltung – gelten nach wie vor. Demgegenüber ist
bei der Replikation aber Redundanz in gewissem Maße erwünscht. Die Integration der
Daten, die Operationen auf den Daten, die Integritätssicherung und die Datensicherheit sind ebenfalls wichtig. Man muss bei den Datenbankoperationen beachten, dass
unter Umständen nur lesende Methoden auf dem mobilen Gerät wegen beschränkter
Hardwarefähigkeiten zugelassen sind.
In Fragen der Datensicherheit sind bei mobilen Endgeräten nur wenige Möglichkeiten,
wie z.B. die Sicherung einer Kopie auf dem PC, vorhanden. In bestimmten Anwendungsfällen ist das aber nicht weiter relevant, falls man immer ganz aktuelle Daten
(z.B. Wetter- und Verkehrsinformationen) benötigt. In Anbetracht des geringen Speicherplatzes werden Sichten in der Regel gar nicht oder nur selten gebraucht. Eine
Nutzerautorisierung ist beim Datenzugriff gelegentlich notwendig oder wird bei der
Registrierung des Geräts an der Basisstation automatisch vorgenommen (z.B. über die
SIM-Card im Handy), da in der Regel nur ein Anwender das mobile Gerät verwendet.
Ein wichtiger Gesichtspunkt bei mobilen Geräten ist die Synchronisation, insbesondere
der Daten und weniger der Transaktionen, weil eine komplexe Transaktionsverarbeitung auf der mobilen Einheit aufwändig ist und eine Realisierung von der bereitgestellten Hardware abhängt. Dagegen sollte natürlich bei der Datenaktualisierung vom
mobilen Client zum Server mit Transaktionsverfahren gearbeitet werden. Die Datensynchronisation führt zugleich zur Datenreplikation, die von verteilten Datenbanksystemen
bekannt ist.
Im Bereich mobiler Systeme sind einige der Eigenschaften verteilter Datenbanken problematisch, vornehmlich wegen limitierter Hardwareressourcen und der Heterogenität
der verfügbaren Geräte. Oft sind Zugriffe auf die Basisstation oder Lokalisierungsmechanismen erforderlich, um situationsabhängige Daten zu erhalten, da die Speicherkapazitäten mobiler Geräte begrenzt sind. Deswegen kann die lokale Autonomie nicht
vollständig gewährleistet werden. Die Unabhängigkeit von zentralen Systemfunktionen
kann nicht sichergestellt werden, weil sich der Nutzer mit seinem Handy an einer zentralen Basisstation anmeldet, die dann seine Anrufe weitervermittelt. Falls sich der
Anwender aus ihrem Empfangs- bzw. Sendebereich entfernt, muss er sich wieder bei
einer anderen Basisstation registrieren. Nachdem eine Verbindung hergestellt wurde,
können die Daten heruntergeladen und lokal gespeichert werden. Die lokale Informationsspeicherung widerspricht der Ortstransparenz. Eine hohe Verfügbarkeit kann nicht
immer garantiert werden, wenn die mobile Einheit beispielsweise in bergigen Regionen
keine Verbindung zur Basisstation errichten kann.
Die verteilte Anfrage- und Transaktionsverarbeitung muss die noch vorhandene Akkulaufzeit berücksichtigen. Die optimale Anfrage bringt dem Benutzer nichts ein, wenn
dafür die letzten Ressourcen der Batterie verbraucht werden und die Ergebnisse nicht
mehr angezeigt werden können. Ebenso sind die Unabhängigkeitsforderungen von Hardware, Betriebssystem, Netzwerk und Datenbanksystem nicht immer erfüllbar, weil das
10
von den Geräten abhängig ist. Es besteht die Möglichkeit mit Java plattformunabhängige Programme zu schreiben, dennoch gibt es nicht für alle Betriebssysteme lizenzfreie
Java Virtual Machines (JVM) zur Ausführung der Programme. Außerdem ist es manchmal aus Performancegründen sinnvoller eine systemnahe Implementierung mit C/C++
vorzunehmen.
Bei den mobilen Datenbanksystemen existieren unterschiedliche Ansätze zur Datenspeicherung von der Erweiterung und Persistentmachung des Programmcodes bis hin
zur Verwendung von DBMS. Diese Diskussion macht deutlich, dass selbst ein verteiltes
Datenbanksystem die Anforderungen im mobilen Bereich nicht erfüllt und entsprechende Modifikationen verlangt. In den nachfolgenden Abschnitten werden wichtige
Aspekte mobiler Datenbanken detaillierter beschrieben.
2.5
Hardware für mobile Anwendungen
Bei der Betrachtung mobiler Hardware kann man die Geräte in drei Klassen einteilen:
• Personal Digital Assistants (PDAs) – sind mobile Kleincomputer im Notizbuchformat für das Personal Information Management (PIM). Sie werden als
elektronischer Terminkalender, Adressbuch, Notizblock, Aufgabenplaner sowie
für E-Mail, Projektmanagement und die Erfassung kleiner Datenmengen verwendet. Fast immer sind noch weitere Anwendungen wie z.B. Textverarbeitung,
Tabellenkalkulation, Taschenrechner und Spiele integriert. PDAs besitzen für die
Eingabe meistens einen Touchscreen anstatt einer Tastatur.
• Smartphones – sind mobile Geräte, die den Leistungsumfang von Mobiltelefonen und PDAs miteinander verbinden (je nach Hersteller mehr PDA oder mehr
Handy). Sie unterstützen Telefon-, SMS-, PIM- sowie Internet-Funktionen (Webbrowser, E-Mail) und können mit Zusatzsoftware versehen werden. Smartphones
erfordern ein großes Display zur Darstellung der Informationen.
• Handys – sind kleine, tragbare Funktelefone, mit denen man schnurlos und ortsungebunden telefonieren kann. Sie können gleichzeitig Nachrichten bzw. Sprache
senden und empfangen. Ferner unterstützen moderne Handys Multimediafunktionen und einfache Anwendungen beispielsweise Spiele.
Darüber hinaus können die mobilen Einheiten noch mit integrierten Digitalkameras
oder MP3-Playern ausgestattet sein. Gemäß der Klassifizierung gibt die Tabelle 2.1
einen Überblick über die technischen Daten der drei Geräteklassen. Es handelt sich
dabei um Durchschnittswerte, die von Gerät zu Gerät noch stark differieren können. In
dieser Tabelle sind die drei wichtigsten Betriebssysteme für mobile Geräte aufgeführt.
• Das Betriebssystem Palm OS wurde speziell für PDAs, mit dem Ziel einer einfachen und intuitiven Bedienung, entwickelt. Palm OS Cobalt (Palm OS 6) ist
eine Neuprogrammierung des bisherigen Palm OS Betriebssystems, um den Anforderungen an zukünftige mobile Endgeräte gerecht zu werden. Außerdem wurde
ein erweitertes API für neue Features und eine bessere Anwendungsperformance eingeführt (z.B. Multitasking, native Unterstützung für ARM-Prozessoren,
11
Speicher-/Prozessschutz sowie verbesserte Multimedia-/Sicherheitsfunktionen).
Des Weiteren existiert noch Palm OS Garnet, das eine optimierte Version der
vorhergehenden Palm OS 5.x Versionen ist und einen geringeren Ressourcenbedarf hat. Für Details sei auf die Datenblätter [Pala, Palb] sowie die Beschreibung
zu den Palm OS Releases [Palc] verwiesen.
• Das Betriebssystem Symbian OS wurde basierend auf der 32-Bit-EPOC-Plattform
von Psion speziell für die Anforderungen von Smartphones entwickelt. Weitere
Informationen sind in der Dokumentation zu Symbian OS 7 (z.B. die Funktionsbeschreibung [Dix03]) nachzulesen, da an dieser Stelle nicht die verschiedenen
Betriebssysteme ausführlich diskutiert werden sollen.
• Ein anderes wichtiges Betriebssystem für mobile Geräte ist Microsoft Windows
Mobile 2003 (auch als Pocket PC 2003 oder Windows CE .NET 4.2 bekannt), das eine Windows-typische Oberfläche und Bedienung hat. Infolgedessen
ist eine gute Kompatibilität zu anderen Microsoft-Anwendungen gegeben.
• In den meisten einfachen Handys werden als Betriebssysteme aber noch Eigenentwicklungen der Hersteller eingesetzt. Daneben sind noch einige andere Betriebssysteme (z.B. Linux) für mobile Anwendungen erhältlich. In Embedded Systems
werden auch Echtzeitbetriebssysteme wie das UNIX-ähnliche QNX Neutrino oder
Wind River VxWorks implementiert.
Basierend auf den drei Geräteklassen und den heterogenen Betriebssystemen wurde
von den Herstellern eine Vielzahl verschiedener mobiler Geräte entwickelt. Die Tabelle
2.2 stellt die technischen Daten einer kleinen Auswahl aktueller PDAs, Smartphones
und Handys bereit. Auf weitere Ausstattungsmerkmale wie Multimedia- und Kommunikationsfähigkeiten wurde der Übersichtlichkeit halber verzichtet. Diese Parameter
sind in der Dokumentation der Hersteller nachzulesen.
Diese kleine Übersicht veranschaulicht die eingeschränkten Hardwaremöglichkeiten. Bei
älteren Geräten stehen noch weniger Ressourcen zur Verfügung. Beim RAM bilden die
128 MB noch eine Ausnahme und man muss von der vorhandenen Speicherkapazität
noch den Bedarf des Betriebssystems, der Ausstattungskomponenten (z.B. Bluetooth,
Wireless LAN, integrierte Digitalkamera, MP3-Player) und der installierten Software
abrechnen. Zudem kann man nicht bei allen Geräten Erweiterungskarten (z.B. SecureDigital Card, MultiMedia Card, CompactFlash Card, Memory Stick und Micro Drive)
nutzen. Logischerweise ist ein geringer Speicherplatzbedarf von 256 kB oder weniger
für ein mobiles Datenbanksystem entscheidend. Für die Ausführung von Programmen
auf den mobilen Endgeräten ist besonders der Heapspeicher wichtig, dessen Größe zwischen 128 kB und 2 MB variiert.
Ebenso ist die Leistungsfähigkeit der Prozessoren beschränkt, da sie mit einem niedrigem Stromverbrauch zu einer langen Batterielaufzeit beitragen sollen und die ganzen
Multimedia- und Kommunikationstechnologien steuern sollen. Bei PDAs und Smartphones werden heutzutage 32-Bit-RISC-Prozessoren mit ARM-Befehlssatz eingebaut,
so dass durch Pipelining die Performance gesteigert werden kann. Die durchschnittliche Stand-by-Zeit der mobilen Geräte ist von der Nutzungsintensität sowie der Kapazität der Batterie abhängig und liegt zwischen wenigen Tagen und zwei Wochen. Die
Parameter
RAM
Heapgröße
Prozessor
Display
PDA
8 - 128 MB
keine Angabe
200 - 400 MHz
300x300 Pixel TFT
mit 64k Farben
Touchscreen/Stift
Smartphone
4 - 16 MB
bis zu 2 MB
100 - 150 MHz
200x200 Pixel TFT mit
64k Farben
EingabemögTouchscreen/Stift,
lichkeiten
Nummerntasten
Kommunika- USB, seriell, GPS, USB, GPS, GSM, GPRS,
tionsschnittWLAN, Bluetooth, HSCSD, EDGE, UMTS,
stellen
Infrarot
Bluetooth, Infrarot
BetriebsPalm OS, Linux, Palm OS, Symbian OS
system
MS Pocket PC
Programmier- C/C++, J2ME,
C/C++, J2ME, .NET,
sprachen
.NET
Personal Java
12
Handy
0,5 - 2 MB
weniger als 0,5 MB
weniger als 75 MHz
100x100 Pixel LCD
mit 4096 Farben
Nummerntasten
USB, GSM, GPRS,
EDGE, Bluetooth,
HSCSD, Infrarot
Herstellerspezifisch
J2ME
Tabelle 2.1: Technische Daten der drei Hardwareklassen
Gerät
Palm Zire
RAM
2 MB
Palm Tungsten
T3
Sony
Clié
PEG-TJ37
HP
iPAQ
H1940
HP
iPAQ
H5550
Sony Ericsson
P900
Siemens SX1
64 MB
Nokia 6600
6 MB
32 MB
64 MB
128 MB
16 MB
8 MB
Sony Ericsson 2 MB
T630
Siemens MC60 2 MB
Nokia 3200
1 MB
Motorola V180
1,8 MB
Prozessor
Motorola Dragonball 16 MHz
Intel XScale 400
MHz
Motorola
i.MXL
200 MHz
Samsung 266 MHz
Display
160x160 LCD,
16 Graustufen
320x480 TFT,
64k Farben
320x320 TFT,
64k Farben
240x320 TFT,
64k Farben
Intel XScale 400 240x320 TFT,
MHz
64k Farben
ARM9 156 MHz
208x320 TFT,
64k Farben
Texas Instruments 176x220 TFT,
OMAP 133 MHz
64k Farben
ARM9 104 MHz
176x208 TFT,
64k Farben
keine Angabe
128x160 TFT,
64k Farben
keine Angabe
101x80 LCD,
4096 Farben
keine Angabe
128x128 LCD,
4096 Farben
keine Angabe
128x128 LCD,
4096 Farben
Betriebssystem
Palm OS 4.1
Palm OS 5.2
Palm OS 5.2
MS Pocket PC
2003
MS Pocket PC
2003
Symbian OS 7.0
Symbian OS 6.1
Symbian OS 7.0
Symbian OS –
Series 40
Tabelle 2.2: Technische Daten einiger aktueller PDAs, Smartphones und Handys
13
größten Energieverbraucher sind der Prozessor, das Display und die Kommunikationsverbindungen. Daher sind bei mobilen Datenbanken effiziente Anfrage- und Transaktionstechniken anzuwenden, um die Verbindungskosten zu reduzieren. Die Eingaben auf
dem Display erfolgen mittels Touchscreen und Stift oder über eine Nummerntastatur.
2.6
Einsatzbereiche für mobile Datenbanken
Nachdem in den vorhergehenden Abschnitten die Anforderungen und die Hardware
mobiler Datenbanken detailliert diskutiert wurden, betrachtet dieser Abschnitt die
Einsatzbereiche mobiler Systeme. Die mobilen Datenbanken sollen den Nutzer im alltäglichen Leben an jedem Ort weltweit und zu jeder Zeit bei der Informationsrecherche
unterstützen. Dadurch ergeben sich vielfältige Einsatzmöglichkeiten:
• Eine klassische Anwendung mobiler Datenbanken ist die Verwendung in Informationssystemen. Dadurch kann der Nutzer z.B. auf Messen, Ausstellungen, Reisen
oder in Museen interaktiv Informationen über seinen aktuellen Standort, Veranstaltungen oder die Exponate abrufen.
• Der zuvor genannte Aspekt führt zugleich zum Anwendungsszenario der Navigation. Die Navigation mit Hilfe des mobilen Gerätes könnte man beispielsweise
mit der Routenplanung im Auto koppeln und so durch aktuelle Informationen
den Verkehrsfluss steuern, um Staus zu vermeiden.
• Weitere Einsatzgebiete sind das persönliche Aufgabenmanagement oder die Verwendung mobiler Geräte als Terminkalender und Adressbuch.
• Außerdem ist eine elektronische Unterstützung bei der Informationssuche in Bibliotheken und Archiven möglich.
• Ein weiterer interessanter Einsatzbereich ist die Verwendung von Handhelds in
der Medizin. Der Arzt könnte sich bei Notfällen auf dem Weg zur Unfallstelle
schnell über die Patientendaten informieren und mögliche Probleme schon frühzeitig erkennen.
• Neben den Consumer-Anwendungen kann man mobile Datenbanken auch in der
Industrie einsetzen, wie z.B. bei der Inventarisierung oder Lagerverwaltung. Durch
die elektronische Datenerfassung wird die manuelle Eintragung der Informationen überflüssig und man spart Kosten durch die Datenübermittlung vom mobilen
Client zum Server.
• Genauso können Außendienstmitarbeiter von Unternehmen über Smartphones
auf aktuelle Daten zugreifen oder fehlende Daten erfassen, so dass ein besserer
Kundenservice möglich ist.
• Ein anderer Anwendungsbereich mobiler Systeme ist die militärische Nutzung
zur Erfassung und Übermittlung von Aufklärungsinformationen.
Ferner hätte jeder Nutzer seinen persönlichen, drahtlosen Internetzugang bei sich und
wäre von herkömmlichen Netzwerkanschlüssen unabhängig.
2.7
14
Architektur mobiler Datenbanksysteme
Bei der Entwicklung von mobilen Datenbanksystemen werden zwei grundlegende Ansätze für die Anwendungsarchitektur unterschieden:
• Erweiterung eines Client-/Serversystems um eine Middleware – Diese Drei-TierArchitektur besteht aus den mobilen Datenbanken als Clients, einem Replikations/Synchronisationsserver als Middleware und dem Datenbankserver als Backend.
Das Datenbank-Managementsystem der mobilen Datenbank ist von der Anwendung getrennt und greift über Schnittstellen auf die Daten zu.
• Integration der Datenbankfunktionalität in die Anwendung – Es wird eine in ihrer
Funktionalität applikationsoptimierte Datenbank erzeugt. Dazu werden nur die
benötigten Komponenten (z.B. Tabellen und Indizes) der Datenbank und die
Datenbankzugriffslogik direkt in die Anwendung kompiliert. Folglich wird die
Unabhängigkeit von Datenbanksystem und Anwendung aufgegeben.
2.7.1
Replikation und Synchronisation
Bei einem mobilen Gerät unterscheidet man zwei verschiedene Zustände:
• Connected Mode – In diesem Zustand befindet sich die mobile Einheit nur
zeitweise. Es existiert eine Netzwerkverbindung zum Middleware-Server, um nach
längeren Offline-Phasen die aktuellen Daten zu replizieren/synchronisieren.
• Disconnected Mode – Das ist der normale Betriebszustand, bei dem keine
Verbindung zum Replikations-/Synchronisationsserver besteht. Demzufolge ist
nur ein Zugriff auf die lokalen und gegebenenfalls schon veralteten Daten möglich.
Die Replikation bezeichnet die redundante Datenspeicherung an mehreren Orten. Bei
mobilen Einheiten werden Kopien von Datenelementen (sogenannte Replikate) des Servers auf die mobilen Clients übertragen, um Anfragen im Disconnected Mode zu erlauben. Dadurch können gegenüber einer permanenten Verbindung die Kommunikationskosten reduziert, hohe Serverlasten vermieden und die Verfügbarkeit der Daten
erhöht werden. Die Synchronisation hat die Aufgabe einen konsistenten Zustand aller
Replikate und der Serverdaten sicherzustellen. Der Synchronisationsprozess setzt sich
aus zwei Phasen zusammen: der Reintegration zur Übertragung der auf dem mobilen
Gerät geänderten Daten auf den Server und der Rückübertragung zur Übermittlung der
Änderungen an den Serverdaten auf den mobilen Client. Die Verteilung der Daten kann
über ein Publish & Subscribe Modell erfolgen. Man definiert dazu auf dem Server abonnierbare Ausschnitte aus dem Datenbestand (sogenannte Publikationen, z.B.
mehrere Tabellen). Die mobilen Clients abonnieren dann die Publikationen für die sie
sich interessieren (sogenannte Subskriptionen) und erhalten immer die aktualisierten
Daten. Daneben gibt es noch die klassischen Client-/Serveranfragen und den unaufgeforderten Informationsversand vom Server an die Clients mittels Broadcast. Gemäß
[Kön03] existieren verschiedene Replikationsverfahren:
15
• Snapshot-Replication – Es wird eine Kopie der gesamten Publikation zu einem bestimmten Zeitpunkt gemacht und komplett übermittelt. Es sind keine
inkrementellen Änderungen möglich.
• Transaction-Replication - Am Anfang wird ein Schnappschuss der gesamten
Publikation erstellt. Danach werden die Transaktionen aufgezeichnet und auf dem
Client bzw. Server nachvollzogen.
• Merge-Replication – Sie ermöglicht ein eigenständiges Arbeiten mit der Teilreplikation in Offline-Phasen, da die Änderungen an den Daten auf dem Client
mitprotokolliert werden. Beim Synchronisieren mit dem Server werden die Änderungen übernommen. Die dabei auftretenden Konflikte sind zu beheben.
Weitere Replikationsverfahren für mobile Datenbanken wie Data Patches, Two-TierReplication und Multiversion Reconciliation werden in [Höp01] ausführlich vorgestellt.
2.7.2
Speichertechniken und Zugriffsstrukturen
Die Daten und Indizes müssen die vorhandenen Speicherkapazitäten optimal nutzen
und einen effizienten Zugriff erlauben, da auf mobilen Geräten der verfügbare Speicherplatz limitiert ist. Dafür können Kompressionsverfahren auf Grund der eingeschränkten
Prozessorleistung nur begrenzt genutzt werden. Deshalb sind leistungsfähige Speichermodelle zu verwenden, wie sie z.B. in [BBPV01] beschrieben werden:
• Flat Storage – Die sequenzielle Speicherung der Tupel hat den Vorteil der Lokalität des Zugriffs. Jedoch ist der Platzbedarf wegen Duplikaten bei den Attributwerten hoch. Außerdem ist das sequenzielle Durchsuchen ineffizient und nur
durch zusätzliche Indexstrukturen verbesserbar.
• Domain Storage – Bei diesem Modell enthalten die Tupel anstatt Attributwerten Zeiger auf die jeweiligen Werte. Demzufolge wird jeder Attributwert nur
einmal gespeichert. Diese Vorgehensweise hat Vorteile, wenn die Werte mehr Speicher als die Zeiger benötigen oder viele Duplikate aufweisen.
• Ring Storage – Das Verfahren arbeitet mit einem Zeiger von den Attributwerten auf das erste Tupel, das diesen Wert enthält, welches dann auf das nächste
Tupel mit diesem Wert verweist, usw. Das letzte Tupel zeigt wieder auf den Attributwert. Dadurch ist kein zusätzlicher Index erforderlich. Allerdings ist die
Bestimmung eines Attributwertes aufwändiger. Im Schnitt ist ein halber Ringdurchlauf notwendig.
Falls leistungsstarke mobile Geräte mit ausreichendem Speicher zur Verfügung stehen,
kann man eventuell für kleine Datenmengen auch klassische Zugriffsstrukturen wie
die B-Bäume nutzen. Im Gebiet mobiler Anwendungen gibt es aber auch bewegliche
Objekte mit dynamischen Attributen wie Zeit. Dafür definiert man räumliche Indexstrukturen (z.B. R-Bäume), bei denen die Zeit als zusätzliche Dimension im Raum
hinzugefügt wurde.
2.7.3
16
Anfrageverarbeitung
Bei der herkömmlichen Anfrageverarbeitung müssen oft Zwischenergebnisse gespeichert werden. Das ist bei mobilen Geräten problematisch, da nur wenig Speicherplatz
verfügbar ist, Schreiboperationen oft sehr lange dauern und die Implementierung komplexer Algorithmen die Größe des Datenbanksystems erhöht, so dass z.B. auf Handys
schnell die Speicherkapazität überschritten wird. In [BBPV01] wird eine Möglichkeit
dargestellt, die auf die Materialisierung von Zwischenergebnissen verzichtet. Zu diesem
Zweck muss der Anfrageoptimierer einen Zugriffsplan auswählen, der einen Operatorbaum in Form eines Extreme-Right-Deep-Trees darstellt. Alle Operatoren werden
dabei in einer Pipeline abgearbeitet und die Zwischenspeicherung vermieden. Es müssen nur die Basisrelationen im Speicher liegen. Eine Adaptation für Mobiltelefone oder
PDAs sollte möglich sein, da das beschriebene Verfahren für Smartcards implementiert
wurde, die noch strengere Ressourcenanforderungen als Handys haben. Eine weiteres Mittel zum Sparen von Speicherplatz ist die Speicherung nur absolut notwendiger
Anfrageergebnisse und die Durchführung einer Reduktion auf wirklich relevante Daten. Dazu kann man Metainformationen aus dem mobilen Kontext miteinbeziehen. In
[Lub00] werden verschiedene Ideen präsentiert:
• Anfragetransformation durch zusätzliche Selektion nach Location oder Projektion
auf wichtigste Attribute
• Reduktion der Datenbasis mit Sichtendefinition oder Statistikverwendung (z.B.
Histogramme) zum Löschen nicht mehr benötigter Daten
• Ergebnistransformation mit Durchschnittswerten anstatt einzelner Attributwerte
• graduelle Datenreduktion, die für den Nutzer uninteressante Daten reduziert
Für den Anwendungsentwickler ist die Unterstützung einer standardisierten Anfragesprache wie SQL wichtig, weil sich die Einarbeitung in eine neue Sprache erübrigt und
meist schon Tools für den Datenzugriff existieren. Andererseits ist eine vollständige Implementierung eines SQL-Standards auf Grund der beschränkten Ressourcen mobiler
Systeme kaum durchführbar. Folglich ist für bestimmte Szenarien die Implementierung
einer eigenen Anfragesprache sinnvoll, die z.B. auch zeitliche und räumliche Aspekte
miteinbezieht (siehe [Kön03]).
2.7.4
Transaktionsverarbeitung
Im mobilen Umgebungen müssen Transaktionen einen nahtlosen Übergang von einer
Zelle zu einer anderen, die Wiederaufnahme nach einem Verbindungsabbruch und lange
Laufzeiten unterstützen. Die ACID-Eigenschaften für mobile Transaktionen werden in
[Kön03, BBPV01] diskutiert:
• Atomicity – Lokal muss eine Transaktion entweder ganz oder gar nicht ausgeführt werden. Die Einhaltung globaler Atomarität ist bei langlaufenden Transaktionen schwierig und ein Abbruch kann teuer werden. Deshalb sind geschachtelte
Transaktionen und ein partielles Zurücksetzen sinnvoll.
17
• Consistency – Bei lokalen Änderungen muss sich die Datenbank vor und nach
einer Transaktion in einem konsistenten Zustand befinden. Problematisch sind
dabei temporale Konsistenzbedingungen (z.B. abgeschlossen bis 12.00 Uhr). Für
höhere Erfolgschancen sollte man in solchen Fällen vielleicht nur bestimmte Teile
einer Transaktion ausführen und unwichtige Teile weglassen.
• Isolation – Die lokale Isolationsbedingung ist erfüllt, da auf mobilen Geräten
nur ein Benutzer alleine mit der Datenbank arbeitet und in der Regel kein Multithreading unterstützt wird. Die globale Isolation muss die spätere Synchronisation garantieren. Bei langlaufenden Transaktionen verringern lange Sperren die
Performance, so dass man diese Anforderung eventuell aufweichen muss.
• Durability – Das Ergebnis einer erfolgreich abgeschlossenen Transaktion muss
dauerhaft gespeichert werden. Dennoch können lokale Datenänderungen verloren
gehen, wenn noch keine Synchronisation mit dem Server vorgenommen wurde
oder die Änderungen bei der Konfliktbehebung verworfen wurden.
Man kann laut [BBPV01] lokale Atomarität durch Shadow-Update, Update-in-Place
mit Write-Ahead-Logging, Pointer-based-Logging oder Garbage-collecting-Values erreichen und globale Atomarität durch das One-Phase-Commit-Protokoll (1PC) gewährleisten. In [Kön03] werden unterschiedliche mobile Transaktionsmodelle erläutert wie
z.B. Reporting-/Co-Transaction, Kangaroo-Transaction, Pre-Serialisation-Transaction
und Relative-Consistent-Transaction.
2.7.5
Sicherheit
Ein wichtiger Aspekt bei mobilen Datenbanken sind Sicherheitsrisiken wie die drahtlose
Datenübertragung, unsichere Kommunikationsprotokolle oder der Verlust der mobilen
Geräte. Deshalb ist eine verschlüsselte Speicherung und Übertragung der Daten notwendig sowie eine Authentifizierung beim Zugriff auf sensitive Daten. Genauso muss bei
Anfragen an den Server kontrolliert werden, ob der Nutzer für den Datenzugriff berechtigt ist. Ebenfalls sollte man die Metainformation im mobilen Kontext (z.B. Position
und Status des Benutzers) vor Missbrauch durch Verschlüsselung und anonymisierter
Übertragung schützen, so dass man die Aktionen des Anwenders nicht zurückverfolgen kann. Für mobile Einheiten gibt es dieselben Gefahren (z.B. Viren/Würmer oder
Hackerangriffe über unsichere Verbindungen) wie für Desktop-Rechner, wenn auch in
sehr geringerem Ausmaß als wie beim klassischen PC. Bei allen Sicherheitsmechanismen ist wiederum zu beachten, dass die Ressourcen der mobilen Endgeräte nicht durch
aufwändige Verfahren (z.B. sehr rechenintensive Verschlüsselungen) zu stark belastet
werden.
Kapitel 3
Existierende Datenbanksysteme für
mobile Endgeräte
In diesem Kapitel werden verschiedene mobile Datenbanksysteme (Stand: Juli 2004)
vorgestellt. Die einzelnen Systeme kann man basierend auf den unterstützten Plattformen entsprechend der drei Geräteklassen klassifizieren. Die Klassifikation wurde in
Tabelle 3.1 vorgenommen. Darüber hinaus gibt es noch weitere Klassifizierungsmöglichkeiten für die Datenbanksysteme z.B. nach der Anwendungsarchitektur (Drei-TierArchitektur oder Integration von Datenbank und Anwendung) bzw. dem unterstützten
Datenmodell (relational, objektorientiert, Netzwerk, XML- oder Java-basiert).
Datenbanksystem
IBM DB2 Everyplace 8.1
Oracle Database Lite 10g
SQL Server Windows CE 2.0
Adaptive Server Anywhere 9
Ultralite 9
Tamino Mobile 4.0
Borland JDataStore 7
FastObjects j2
FastObjects e7
PointBase Micro 5.0
PointBase Embedded 5.0
Mimer SQL Mobile 9.2
Mimer SQL Embedded 9.2
Birdstep RDM Embedded 7.1
Birdstep RDM Mobile 3.0
McObject eXtremeDB 2.3
Footprint
200 kB
150 kB - 1 MB
1 - 3 MB
8 MB
150 kB
430 - 990 kB
1 - 1.2 MB
450 kB
4 MB
45 - 90 kB
1 MB
4 MB
400 kB - 2 MB
270 kB
225 kB
60 - 100 kB
PDA
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
ja
Smartphone
ja
nein
teilweise
nein
teilweise
nein
ja
ja
nein
ja
nein
ja
Handy
teilweise
nein
nein
nein
nein
nein
nein
nein
nein
ja
nein
teilweise
ja
ja
ja
nein
ja
nein
nein
nein
nein
Tabelle 3.1: Klassifikation der Datenbanksysteme in die drei Hardwareklassen
Besonders interessant sind Datenbanksysteme mit denen der Nutzer auf vielen verschiedenen mobilen Geräten arbeiten kann. Einen detaillierten Überblick zu den unterschiedlichen Plattformen gibt die Tabelle 3.2. Der Übersichtlichkeit halber wurden die
18
KAPITEL 3. EXISTIERENDE DATENBANKSYSTEME
19
zahlreichen Betriebssystemversionen der Server, die Pocket PC-Smartphoneversionen
sowie die Hardwareanforderungen der einzelnen Systeme weggelassen. Weitere Informationen kann man der Dokumentation der Datenbankhersteller entnehmen.
Beim Vergleich der verschiedenen Datenbanksysteme und ihrer Synchronisationskomponenten gibt es bis auf Detailunterschiede einige Gemeinsamkeiten. Diese gemeinsamen Funktionalitäten sind nachfolgend aufgeführt. Die smartDB unterstützt diese Funktionen noch nicht vollständig. Die Unterschiede und Details der vorgestellten
Systeme findet man in den einzelnen Datenbankabschnitten. Die Datenbanken haben
folgende gemeinsame Eigenschaften:
• kleiner Footprint
• nahezu kein Administrationsaufwand und selbstoptimierend
• verschlüsselte Speicherung der Daten (Ausnahmen: FastObjects j2, Birdstep RDM
Embedded/Mobile, McObject eXtremeDB)
• SQL-Unterstützung (Ausnahmen: Tamino Mobile, FastObjects j2/e7, Birdstep
RDM Mobile, McObject eXtremeDB)
• Indizierung für schnellere Anfragen
• Transaktionsverarbeitung
Die Synchronisationssysteme (falls vorhanden) haben diese Gemeinsamkeiten:
• Authentifizierung/Autorisierung der Benutzer
• Datenreplikation zwischen dem Synchronisationsserver und dem mobilen Client
• 128-Bit Verschlüsselung und Datenkompression bei der Datenübertragung sowie
Recovery bei Netzwerkfehlern
• automatische Konflikterkennung und -lösung bei Mehrbenutzerzugriffen
Ein weiterer interessanter Gesichtspunkt beim Vergleich von Datenbanksystemen sind
statistische Datenbankinformationen. Eine Übersicht über die Maximalwerte wichtiger
Datenbankparameter gibt die Tabelle 3.3. Es wurden insbesondere relationale Datenbankgrößen berücksichtigt, weil die Mehrheit der Datenbanksysteme das relationale
Modell unterstützen. Mobile Datenbanken mit anderen Datenmodellen kann man beim
Vergleich nur schlecht oder gar nicht miteinbeziehen. Zu einigen Systemen waren keine
oder nur unvollständige Informationen aufzufinden. Des Weiteren ist es schwierig für
jedes Datenbanksystem den RAM-Bedarf anzugeben, da das sehr vom Betriebssystem
und der Funktionalität der Datenbank abhängig ist. Der benötigte RAM liegt zwischen
16 kB und 16 MB.
1
basiert auf Windows CE 2.11
basiert auf Windows CE 3.0, Pocket PC 2002 enthält noch teilweise spezielle Software
3
umfasst Windows CE .NET 4.0/4.1/4.2
4
basiert auf Windows CE .NET 4.2, auch bekannt als Windows Mobile 2003
5
umfasst verschiedene Hersteller von Betriebssystemen für Embedded bzw. Real-Time Systems
6
umfasst als Clients auch alle unterstützten Serverplattformen
7
durch die Mimer SQL Engine unterstützte Client-/Serverplattformen
2
eXtremeDB 2.3
Birdstep Mobile 3.0
Birdstep Embedded
Mimer Embedded 9.2
Mimer SQL Mobile
PointBase Embedded
PointBase Micro 5.0
20
FastObjects e7
FastObjects j2
JDataStore 7
Tamino Mobile 4.0
Ultralite 9
ASA 9
SQL Server CE 2.0
Oracle Lite 10g
Plattform
DB2 Everyplace 8.1
Mobile and Embedded Clients
Palm 0S 3.x/4.x/5.x
X X
X
X
Palmsize PC 2.01
X
Handheld PC Pro1
X
2
Handheld PC 2000
X
X X X
Pocket PC 20002
X
X X X X X
X X
X
X
2
Pocket PC 2002
X X X X X X X
X X
X
X
4
Pocket PC 2003
X X X X X
X X
Windows CE 3.0
X
X X X X X
X X
X
X
3
Windows CE .NET
X
X X X
X X
Windows XP Embedded
X
X X
X X X
Symbian OS V6/V7
X
X
X
X
Embedded Linux5
X
X
X
X X X
Embedded Java
X
Personal Java/JDK 1.1.8
X
X X
X
X
J2ME/CDC + Profiles
X
X X X
J2ME/CLDC + MIDP
X
X
X
QNX Neutrino 6.x
X
X X X
WindRiver VxWorks 5.x
X X
X X X
GreenHills Integrity 4.x
X X X
5
andere Real-Time OS
X
X
Desktop and Laptop Clients
Windows NT/2000/XP
X X
X
X
X X6
X X X
6
6
6
Linux
X X
X
X
X X
X6 X6 X6
Synchronization Servers or Development Platforms
Windows NT/2000/XP/ X X X X X X X X X X X X7 X X X X
Server 2003
Linux x86
X X
X X
X X X X X X7
X X X
7
SUN Solaris SPARC
X X
X X
X X X X X X
X X X
IBM AIX
X X
X X
X7
HP-UX
X
X
X7
X X X
7
HP/Compaq Tru64
X
X
X
MAC OS X
X X
X
Novell Netware
X
OpenVMS
X7
Tabelle 3.2: Unterstützte Plattformen der mobilen Datenbanksysteme
Datenbanksystem
DB2 Everyplace 8.1
Oracle Lite 10g
SQL Server CE 2.0
ASA 9
Ultralite 9
Tamino Mobile 4.0
JDataStore 7
FastObjects j2
FastObjects e7
PointBase Micro 5.0
PointBase Embedded
Mimer SQL Mobile
Mimer Embedded 9.2
Birdstep Embedded
Birdstep Mobile 3.0
eXtremeDB 2.3
Größe
der Datenbank
beliebig8
4 GB
2 GB
beliebig
2 GB
Tabellen
pro Datenbank
beliebig
4 Mrd.
1000
keine
8 TB
keine
keine
keine
8 TB
8 TB
8 TB
beliebig8
beliebig8
4 Mrd.10
4 Mrd.10
2 Mrd.10
Größe
der
Tabelle
beliebig8
21
Zeilen
pro
Tabelle
beliebig9
beliebig
Spalten
pro
Tabelle
beliebig9
1000
255
beliebig8 beliebig8 999
2 GB
65534
65535
Informationen verfügbar
8 TB
2 Mrd.
8 TB
8 TB
252
8 TB
252
beliebig8
beliebig8
Indizes
pro
Tabelle
15
beliebig
249
2048
1000
3276711
Tabelle 3.3: Maximalwerte wichtiger Datenbankparameter mobiler Datenbanken
3.1
IBM DB2 Everyplace 8.1
IBM DB2 Everyplace 8.1 ist ein relationales Datenbanksystem für den Einsatz auf
PDAs und Smartphones. Sie wird in drei Versionen angeboten:
• DB2 Everyplace Database Edition – umfasst die DB2 Everyplace Datenbank für
den Einsatz auf einem mobilen Endgerät. Sie wird von Geräteherstellern in ihre
mobilen Systeme eingebettet.
• DB2 Everyplace Enterprise Edition – enthält die DB2 Everyplace Datenbank für
eine unlimitierte Anzahl mobiler Endgeräte und den DB2 Everyplace Synchonization Server für die Datenreplikation. Sie ist für Großunternehmen gedacht. Die
Lizenzierung erfolgt pro Prozessor des Synchronization Servers.
• DB2 Everyplace Express Edition – basiert auf der gleichen Codebasis wie DB2
Everyplace Enterprise Edition. Sie eignet sich für kleine und mittelständische Unternehmen. Die Lizenzierung erfolgt auf Client-/Server-Basis, wobei die Benutzer
als Named User zählen und beliebig viele mobile Geräte betreiben können. Der
Synchronization Server ist auf maximal zwei Prozessoren begrenzt.
Die Datenbank bietet folgende Features:
8
die Größe wird nur vom verfügbaren Speicherplatz bzw. der Dateigröße begrenzt
die Anzahl wird nur durch die Tabellengröße beschränkt
10
hier sind es Objekte pro Datenbank und keine Tabellen pro Datenbank
11
hier sind es Indizes pro Datenbank und keine Indizes pro Tabelle
9
22
• Schnittstellen für Datenzugriff: JDBC/ODBC, DB2 CLI12 /C/C++, ADO.NET13 ,
.NET APIs, Remote Query und Stored Procedure Adapter für Echtzeitzugriff
• unterstützte Standards: SQL-Kernfunktionen
• DDL14 : CREATE/DROP TABLE, CREATE/DROP INDEX, GRANT
• DML15 : INSERT, DELETE, UPDATE, SELECT, scrollable cursor, JOIN, GROUP
BY, ORDER BY
• Ausdrucks- und Aggregatfunktionen, case-insensitive search, DEFAULT-Werte,
CHECK constraints und IDENTITY columns
• bidirektionale Mehrattributindizes
• Datentypen: small integer, integer, decimal, char, varchar, BLOB16 , date, time,
timestamp
Der Synchronisationsserver unterstützt nachfolgende Funktionen:
• bidirektionale Synchronisation mit IBM DB2 UDB, IBM Lotus Domino, Oracle,
Microsoft, IBM Informix, Sybase und anderen JDBC-kompatiblen Datenquellen
• J2ME Synchronization Client für mobile Geräte mit sehr beschränkten Ressourcen (z.B. Mobiltelefone und Pager)
• Unterstützung von WebSphere Application Server Groups für Load Balancing
• Logging mit programmierbaren Antworten bei Konflikten
• Mobile Devices Administration Center zur zentralen Administration vieler Nutzer
und XML-Skriptschnittstelle
• autonome Indexerzeugung, Check-Constraint-Management für Clientdatenbanken
• vertikale/horizontale Datenpartitionierung
• Dateiunterstützung für Verteilung und Wartung mobiler Applikationen mit OnDemand-Download
• API mit Synchronisationsfunktionen für Java, C/C++ und .NET
Für die Entwicklung mobiler Datenbanken bietet IBM den DB2 Everyplace Mobile Application Builder an. Die oben genannten Informationen wurden [IBM03] entnommen.
Weitere Details findet man auf der Webseite http://www-306.ibm.com/software/
data/db2/everyplace/index.html.
12
Call Level Interface
ActiveX Data Objects for .NET – objektorientierte Schnittstelle für Datenbankzugriff
14
Data Definition Language
15
Data Manipulation Language
16
Binary Large Object – lange Folge von Binärwerten
13
3.2
23
Oracle Database Lite 10g
Oracle Database Lite 10g ist ein relationales Datenbanksystem für Handhelds und
Laptops. Für die Datenbank existiert auch eine Mehrbenutzerversion mit bis zu 32
simultanen Verbindungen. Die mobile Datenbank hat diese Eigenschaften:
• Schnittstellen für Datenzugriff: JDBC/ODBC, ADOCE17 , ADO.NET, C++,
mobiles SQL-Utility, SODA18
• unterstützte Standards: SQL92
• referenzielle Integrität und Data-Integrity-Constraints
• B-Baum-Indizes mit maximal 32 Spalten pro Index
• Java Stored Procedures und Triggers
• Anfrageoptimierung unter Verwendung von Datenbankstatistiken
• Transaktionen mit Row-Level-Locking und automatischem Recovery
• Datentypen: BFILE als LOB, BLOB, CLOB19 und Long jeweils maximal zwei
GB, Number ist abhängig vom Betriebssystem
Das Synchronisationssystem Mobile Server besitzt folgende Funktionalitäten:
• bidirektionalen Synchronisation über ein Publication & Subscription Modell,
Multi-Thread-Architektur mit individuellen Synchronisationsaufrufen, Synchronisationsmonitor
• unterstützte Synchronisations-/Netzwerkprotokolle: TCP/IP, HTTP, 802.11b,
PPP12, GPRS, HotSync, ActiveSync, offene Transport APIs für beliebige kabellose Netzwerke
• datei- und warteschlangenbasierte Replikation mit Snapshots, Replikation von
Java-Prozeduren und SQL-Skripten
• Schemaevolution, Tabellenpartitionierung
• Schnittstellen zu C, Java und COM20
Das Managementsystem der Oracle Database Lite stellt eine webbasierte, serverseitige
Administrationsschnittstelle zur Verfügung, die eine Anwendungsentwicklung und ein
Management der Datenreplikation und der Nutzer ermöglicht. Eine Remote-Gerätediagnose und eine Skriptsprache für die Batchadministration werden auch unterstützt.
Die zuvor erwähnten Aspekte findet man in [Rad04b, Rad04a]. Zusätzliche Informationen bietet die Webseite http://www.oracle.com/technology/products/lite/
index.html.
17
ActiveX Data Objects for Windows CE – objektorientierte Schnittstelle für Datenbankzugriff
Stateless Object Database Access – C++-Bibliothek für Datenbankzugriff über andere Programmiersprachen
19
Character Large Object – lange Folge von Zeichen
20
Component Object Model – Technologie zur Anwendungserstellung aus binären Softwarekomponenten
18
3.3
24
Microsoft SQL Server 2000 Windows CE 2.0
Microsoft SQL Server 2000 Windows CE 2.0 Edition ist ein relationales Datenbanksystem für Pocket PC basierte PDAs und Embedded Systems, das als Teil von SQL
Server 2000 Developer Edition lizenziert wird. Es werden zwei Szenarien unterschieden:
• Stand-Alone-Modus auf dem Windows CE Gerät – die Lizenz der Developer Edition erlaubt eine unbeschränkte Verteilung der mobilen Datenbank auf mehreren
Geräten. Die Geräte dürfen sich nicht zum SQL Server verbinden oder ihn nutzen.
• Austausch von Daten mit dem SQL Server – falls sich das Windows CE Gerät mit
einem SQL Server verbindet oder ihn nutzt, muss dieser im Pro-Prozessor-Modus
lizenziert sein oder das Gerät eine SQL Server Client Access License haben.
Das Datenbanksystem verfügt über nachfolgende Merkmale:
• Schnittstellen für Datenzugriff: ADOCE, ADO.NET, OLE21 DB für Windows
CE, Visual Basic/C++, Visual Studio .NET
• unterstützte Standards: SQL, Unicode
• DDL: CREATE/DROP/ALTER für Datenbanken, Tabellen und Indizes
• DML: INSERT, DELETE, UPDATE, SELECT, INNER/OUTER JOIN, GROUP
BY/HAVING, ORDER BY, UNION, scrollable cursor
• Aggregatfunktionen und Operatoren, DEFAULT-Werte, NULL-Werte, referenzielle Integrität mit kaskadierenden DELETE-/UPDATE-Klauseln
• mehrspaltige Indizes
• parametrisierte/geschachtelte Anfragen und Anfrageoptimierung
• geschachtelte Transaktionen bis maximal fünf Ebenen mit Table-Level-Locking
• Datentypen: tinyint, smallint, int, bigint, real, numeric, float, double, bit, binary, varbinary, Unicode-Zeichendatentypen, image, money, datetime, BLOB bis
maximal ein GB, UNIQUEIDENTIFIER, IDENTITY columns
Die Synchronisationskomponente unterstützt folgende Features:
• Mergereplikation und horizontale/vertikale Filter zum Definieren/Verwalten eindeutiger Datenteilmengen für verschiedene Clients
• nachrichtenbasierte Internetreplikation mit bidirektionaler Synchronisierung durch
eine HTTP-Verbindung mit dem SQL Server über den Internet Information Server (IIS) unter Verwendung von drahtlosen/verdrahteten LANs und WANs
• Remotedatenzugriff auf SQL Server 6.5/7.0/2000 möglich unter Nutzung von IIS
Die oben angeführten Informationen kann man in [Mic00, Mic02, FB03] nachlesen.
Weitere Einzelheiten stehen auf der Webseite http://www.microsoft.com/germany/
ms/sql/2000/wince/index.htm.
21
Object Linking and Embedding – Schnittstelle für Datenaustausch zwischen Anwendungen
3.4
25
Sybase SQL Anywhere Studio 9
Das SQL Anywhere Studio 9 der Sybase-Tochterfirma iAnywhere umfasst die Datenbanksysteme Adaptive Server Anywhere und UltraLite. Adaptive Server Anywhere 9
(ASA 9) ist ein relationales Datenbanksystem für Notebooks und sehr leistungsstarke
PDAs. Es kann auch auf stationären Computern als klassische Datenbank eingesetzt
werden. Für leistungsschwächere mobile Geräte existiert die Datenbank UltraLite 9,
die jedoch kein eigenständiges Datenbanksystem mehr ist, sondern eine anwendungsoptimierte Datenbank. Die UltraLite-Datenbank ist für die Geräteklassen PDA, Smartphone und Handy wesentlich interessanter als der Adaptive Server Anywhere und wird
daher genauer betrachtet. Sie bietet folgende Funktionalitäten:
• Schnittstellen für Datenzugriff: Static C/C++ API mit Embedded SQL, Static
Java API mit JDBC, Dynamic SQL
• unterstützte Standards: SQL, Unicode
• DDL: CREATE/DROP TABLE, CREATE/DROP INDEX
• DML: INSERT, DELETE, UPDATE, SELECT, GROUP BY/HAVING, ORDER
BY, JOIN
• Aggregatfunktionen und Operatoren, DEFAULT-Werte, NULL-Werte, referenzielle Integrität
• B+-Baum-Indizes und mehrspaltige Indizes
• Transaktionen mit Row-Level-Locking und automatischem Recovery mit Zustandsbyte für die Tabellenzeile
• Datentypen: tinyint, smallint, int, bigint, decimal, real, float, double, char, varchar, long varchar, binary, varbinary, long binary, BLOB, date, time, timestamp
Die Synchronisation erfolgt für beide Datenbanksysteme über den MobiLink-Synchronisationsserver, der nachfolgende Eigenschaften umfasst:
• bidirektionale Synchronisation mit Datenbanken von Sybase, IBM, Oracle und
Microsoft, serverinitiierte Synchronisation sowie automatische Erstellung von Synchronisationsskripten
• unterstützte Synchronisations-/Netzwerkprotokolle: TCP/IP, HTTP, HTTPS,
HotSync, ActiveSync
• programmierbare Konfliktbehebung
• vertikale/horizontale Datenpartitionierung und prioritätsbasierte Synchronisation von mehreren Daten-Subsets
• Downloadänderungen als Broadcast-Datei
• Entwicklung der Synchronisationslogik mit SQL, Java oder .NET
26
• bidirektionale, nachrichtenbasierte Synchronisation mit SQL Remote zwischen
Datenbankservern und Clients von Sybase über FTP, e-Mail oder dateibasiert,
minimale Kommunikationskosten da nur aktualisierte Daten gesendet werden
Darüber hinaus bietet QAnywhere ein umfangreiches Messaging API zur Entwicklung
mobiler Datenübertragungsanwendungen. Es nutzt erweiterte MobiLink-Funktionen
und arbeitet wie ein Messaging-Server. Die zuvor aufgezählten Gesichtspunkte wurden [iAn04a, iAn04b] entnommen. Detaillierte Informationen stehen auf der Webseite
http://www.ianywhere.com/deutschland/products/sql_anywhere.html.
3.5
Tamino Mobile 4.0
Die XML-Datenbank Tamino Mobile 4.0 der Software AG ist eine mobile Datenbank für
Handhelds und Embedded Systems. Sie kann speziell für einen kleinen Footprint oder
eine hohe Performance optimiert werden. Die XML-Datenbank besitzt diese Merkmale:
• unterstützte Schnittstellen: DOM22 Level 2 und DOM Level 3 XPath Integration
• Verwendung von XPath 1.0 bei Anfragen und zur Navigation
• strukturierte XML-Dokumente durch Nutzung von DTD23 -Skripten
• Transformation eines beliebigen Datenbankteils in einen ByteStream (z.B. eine
XML-Datei) basierend auf SAX24 Version 2
• Unterstützung der Codierungen UTF-8, UTF-16, US ASCII und Latin-1 Unicode
• Schnittstellen zur XML API für C++ und Java
Die Synchronisation der Daten kann über LAN, Wireless LAN, GPRS oder UMTS
erfolgen. Mit Hilfe des Datenlademoduls von MobileLogic – einem Business Services
Framework mit fertig entwickelten Komponenten für die schnelle Erstellung von Portallösungen – kann man die Daten vom Tamino XML Server in die Tamino Mobile
Datenbank herunterladen. Durch die Arbeit mit einem vorkonfigurierten Portal kann
die zu übertragende Datenmenge bei der Synchronisation reduziert werden. Die oben
genannten Informationen sind in [Sof03] enthalten. Ergänzende Fakten findet man auf
der Webseite http://www2.softwareag.com/de/products/tamino/default.asp.
3.6
Borland JDataStore 7
Borland JDataStore 7 ist ein plattformunabhängiges, komplett in Java geschriebenes,
relationales Datenbanksystem für mobile, eingebettete und kleine bis mittlere Serveranwendungen. Es verfügt über folgende Eigenschaften:
22
Document Object Model – baummanipulierende XML-Prozessoren
Document Type Definition – zur Modellierung von XML-Dokumenten
24
Simple API for XML – ereignisorientierte XML-Prozessoren
23
27
• Schnittstellen für Datenzugriff: JDBC/ODBC, interaktives SQL-Utility
• unterstützte Standards: Untermenge von SQL92 Entry Level, Unicode
• DDL: CREATE/DROP SCHEMA, CREATE/DROP/ALTER TABLE, CREATE/DROP/ALTER VIEW, CREATE/DROP INDEX, GRANT/REVOKE
BY, INNER/OUTER JOIN, UNION, EXCEPT, INTERSECT
• Aggregatfunktionen, Operatoren und Prädikate, DEFAULT-Werte, NULL-Werte,
referenzielle Integrität
• Trigger, Java Stored Procedures, user-defined Functions (UDFs)
• Transaktionen mit Row-/Table-Level-Locking, read-only Transaktionen ohne
Locking, automatisches Crash-Recovery und inkrementelles Datenbankbackup
• verteilte Transaktionen mit JTA25 , X/Open XA26 Standard, Connection Pooling
• hohe Betriebssicherheit durch automatische Ausfallsicherung auf Spiegelservern,
read-only Cluster für Load Balancing
• Datentypen: Java-Typen, Objekte, SQL-Typen (tinyint, smallint, int, bigint, decimal, real, float, double, boolean, bit, varchar, binary, varbinary, date, time,
timestamp), BLOB bis maximal zwei GB
Die Datenbank unterstützt eine unidirektionale Datenreplikation. Außerdem existiert
eine grafische Server Management Konsole für die Verwaltung der Datenbank sowie
visuelle Tools zur Bearbeitung der Datenbankkomponenten und zum Monitoring bzw.
Logging der Datenbankaktivitäten. Die zuvor erwähnten Aspekte kann man in [Bor03b,
Bor03a] nachlesen. Für weitere Details sei auf die Webseite http://www.borland.de/
jdatastore/index.html verwiesen.
3.7
Versant/Poet FastObjects j2 und e7
Nach der Fusion von Versant und Poet werden die FastObjects-Datenbanken von Versant vertrieben. FastObjects j2 und FastObjects e7 sind objektorientierte, echtzeitfähige Einbenutzer-Datenbanken für die lokale Datenspeicherung. Sie werden in Handhelds und Embedded Systems verwendet. Die beiden Datenbanken haben nachstehende
gemeinsame Eigenschaften:
• Schnittstellen für Datenzugriff: JDO27 1.0.1, ODMG 3.0 Java-Binding, Database
Administration API
25
Java Transaction API
eXtended Architecture – Schnittstelle für verteilte Transaktionen
27
Java Data Objects – Schnittstelle zur dauerhaften, transparenten Speicherung von Objekten in
Java-Anwendungen
26
28
• Anfragen/Datenzugriff über JDOQL, Retrieval/Navigation durch Referenz
• Import/Export mit XML und Online-Backup
• geschachtelte/parallele Transaktionen mit Object-Level-Locking, automatische
Integritätskontrolle und Reparatur der Dateien
• Schemaevolution, Schemaversionierung und „On the Fly“-Objektversionierung
• direkte Abbildung der Objektrepräsentation vom Speicher auf die Platte, wobei
Memory Pointer in interne Objektidentifier konvertiert werden
Die beiden Datenbanksysteme haben trotzdem einige Unterschiede. FastObjects j2 ist
komplett in Java geschrieben und wird in Java-Anwendungen genutzt. Es besteht aus
einem Kernsystem sowie mehreren optionalen Modulen und hat folgende zusätzliche
Funktionen:
• j2-Bytecode-Enhancer extrahiert automatisch die Schemainformationen, speichert
die persistenzfähigen Klassen in einem Persistence Descriptor File und modifiziert
den Bytecode für eine persistente Speicherung (Persistenz durch Erreichbarkeit)
• Undo-Log-Recovery
• Replikation mit einer Shadow-Datenbank
FastObjects e7 ist in C++ geschrieben und wird in C++-Anwendungen verwendet. Es
verfügt über nachfolgende zusätzliche Funktionalitäten:
• e7-Präprozessor verwendet die Headerdateien der Anwendung zur Definition der
Datenbankschemata und zur Erzeugung der Datenzugriffslogik direkt aus dem
Objektmodell
• Forward-Log-Recovery
• Schnittstellen: C++-Binding, ODBC für Windows
• Anfragen/Datenzugriff über OQL oder PtQL28 und eine Anfrageoptimierung
• Caching von Objekten zwischen Transaktionen und optimistisches Locking
• Nutzerauthentifizierung/-autorisierung
• Migration von lokaler Datenbank zu Mehrbenutzer-Datenbankserver möglich
Die oben angeführten Informationen sind in [Fas04b, Fas04a, Poe01] enthalten. Weitere
Einzelheiten bietet die Webseite http://www.fastobjects.com/us.
28
Program Trace Query Language
3.8
29
DataMirror PointBase Micro und Embedded 5.0
PointBase Micro 5.0 und PointBase Embedded 5.0 von DataMirror sind plattformunabhängige, komplett in Java geschriebene, relationale Datenbanksysteme für mobile
Umgebungen (z.B. Laptops, PDAs, Smartphones). PointBase Micro ist speziell für
J2SE sowie J2ME CDC + CLDC optimiert und verfügt über folgende Features:
• Schnittstellen für Datenzugriff: JDBC
• unterstützte Standards: Untermenge von SQL92, Unicode
• unterstützte Sicherheitsstandards: XTEA
• DDL: CREATE/DROP/ALTER TABLE, CREATE/DROP INDEX, CREATE
FUNCTION, CREATE USER
• DML: INSERT, DELETE, UPDATE, SELECT, JOIN über mehrere Tabellen
• Aggregatfunktionen und Prädikate für Vergleich/LIKE, NULL-Werte, Primärschlüssel, Java-Funktionen in DDL-/DML-Statements
• regelbasierter Anfrageoptimierer
• automatisches Recovery
• Datentypen: integer, decimal, char, varchar, BLOB, date, time, timestamp
PointBase Embedded wird mit J2EE, J2SE sowie J2ME CDC verwendet. Es umfasst
alle Bestandteile von PointBase Micro und bietet folgende ergänzende Funktionen:
• unterstützte Standards: SQL92 Entry & Transition Level, SQL99-Kernfunktionen
• unterstützte Sicherheitsstandards: Blowfish, Twofish, DES, DES3, TEA, IDEA
• DDL: CREATE/DROP SCHEMA, CREATE/DROP PROCEDURE, CREATE/
DROP read-only VIEW, CREATE/DROP TRIGGER, GRANT/REVOKE
• Prädikate IN/BETWEEN, DEFAULT-Werte, CHECK constraints, IDENTITY
columns, Fremdschlüssel, referenzielle Integrität, SQL-Funktionen in DDL-/DMLStatements, skalare Funktionen
• Unteranfragen, temporäre Tabellen, scrollable/updateable Cursors, updateable
Resultsets, Batchupdates, Java Stored Procedures
• kostenbasierter Anfrageoptimierer, Online-Anfragestatistiken
• Online-Backups
• Datenbank kann als Ressource Manager dienen, um die Transaktionsverwaltung
des Application Servers zu unterstützen
30
• verteilte Transaktionen mit JTA, X/Open XA Standard, Connection Pooling,
Two-Phase-Commit
• Datentypen: smallint, bigint, numeric, bigdecimal, float, double, real, boolean,
CLOB
• einstellbare Datenbankeigenschaften: Cache Size, Database Page Size, Sort Buffer
Size, SQL Caching
Für die Datenbankentwicklung stehen die grafische Oberfläche PointBase Console und
PointBase Commander, ein kommandozeilenorientiertes Tool für den Datenzugriff und
das Skripting, zur Verfügung. PointBase Embedded kann auch auf stationären Computern als klassisches Datenbanksystem benutzt werden und es gibt eine Serveroption
für eine Client-/Server-Umgebung. Das Synchronisationssystem für beide Datenbanken
PointBase UniSync ist vollkommen in Java implementiert und unterstützt nachfolgende
Eigenschaften:
• bidirektionale Synchronisation (PointUpdate = delta changes, Snapshot = full
changes) mit Oracle, Microsoft und anderen JDBC-kompatiblen Datenbanken,
Publish & Subscribe Modell inklusive Filtermöglichkeiten mit JOINs
• automatische Datentypabbildung zwischen Oracle, Microsoft und PointBase
• unterstützte Synchronisations-/Netzwerkprotokolle: TCP/IP, HTTP, HTTPS
• Hub & Spoke Network Modell für mehrere, simultane Verbindungen zwischen
UniSync-Engine und Datenbank, Nutzeranzahl von Hardwaregrenzen abhängig
• Logging bei Konflikten, Standardlösungen: „spoke win“oder „hub win“, Alternativen: regelbasierte Algorithmen oder anwendungsspezifische Lösung
• Businesslogik durch Entwickler in PointBase UniSync vor/nach der Synchronisationsoperation implementierbar (z.B. über EJB29 , Servlets, Java-Klassen)
Darüber hinaus existiert noch die UniSync Console, die ein grafisches Entwicklertool zur
Konfiguration der Synchronisation ist. Die oben aufgezählten Fakten wurden [Dat04b,
Dat04a, Dat04c] entnommen. Ergänzende Informationen findet man auf der Webseite
http://www.pointbase.com/products.
3.9
Mimer SQL Engine, Mobile und Embedded 9.2
Die Mimer SQL Engine 9.2 stellt die Funktionalitäten bereit, um ein DatenbankManagementsystem in eine Nutzeranwendung einzubauen. Die relationale DatenbankEngine kann auf einer Vielzahl von Plattformen (z.B. PDA, Laptop, Desktop PC,
Enterprise-Server) übertragen werden und hat nachfolgende Merkmale:
29
Enterprise Java Beans – serverseitige Komponentenarchitektur für J2EE zur einfachen Entwicklung von komplexen, verteilten Anwendungen
31
• Schnittstellen für Datenzugriff: JDBC/ODBC, ADO, ADO.NET, Embedded SQL
in C/C++/COBOL/FORTRAN, Mimer BSQL (interaktives SQL-Utility)
• unterstützte Standards: SQL92 Entry, Intermediate & Transition Level, SQL99Kernfunktionen, Unicode
• DDL: CREATE/ALTER/DROP TABLE, CREATE/DROP INDEX, CREATE/
DROP VIEW, CREATE/DROP PROCEDURE, CREATE/DROP TRIGGER,
CREATE/DROP FUNCTION, CREATE/DROP SCHEMA, GRANT/REVOKE
BY, INNER/OUTER JOIN, UNION
• Aggregatfunktionen, Operatoren und Prädikate, DEFAULT-Werte, NULL-Werte,
CHECK constraints, skalare Funktionen, referenzielle Integrität
• scrollable/updateable Cursors, updateable Resultsets, Batchverarbeitung
• Indizes mit maximal 32 Spalten
• automatische Online-Datenbankreorganisation und Online-Backup
• Transaktionskontrolle mit optimistischen Verfahren und ohne Locking
• verteilte Transaktionen mit JTA, X/Open XA Standard, Connection Pooling,
2-Phase-Commit sowie COM+ und DTC30
• Datentypen: smallint, int, bigint, decimal, real, float, double, char, varchar, CLOB,
binary, varbinary, BLOB, date, time, timestamp
Mimer SQL Mobile 9.2 ist eine relationale Datenbank für Handhelds, Mobiltelefone
und andere kleine Geräte. Die Datenbank kann in die Anwendungen integriert werden.
Mimer SQL Embedded 9.2 ist eine relationale Datenbank für Embedded Systems. Sie
ist für verschiedene Plattformen verfügbar oder kann auf die gewünschte Plattform in
30 bis 90 Tagen portiert und validiert werden. Die beiden Datenbanken besitzen die
Funktionen der Mimer SQL Engine und nachfolgende zusätzliche Features:
• automatische „On the Fly“-Datenkompression
• automatische Sammlung von statistischen Informationen
• Mehrbenutzerbetrieb und automatisches Recovery
• unterstützte Synchronisations-/Netzwerkprotokolle: serielle Schnittstelle, LAN,
IR, Wireless LAN, Bluetooth
• Unterstützung von Client-/Server-Verbindungen zwischen mehreren Mimer SQL
Datenbanken
30
Distributed Transaction Coordinator – Transaction Manager for Windows Environments
32
Darüber hinaus kann Mimer SQL Mobile auch selbst als Handheld-Datenbankserver arbeiten, auf den man mit beliebigen Clients über JDBC/ODBC zugreifen kann. Folglich
werden mehrere, parallele Datenbankverbindungen mit JDBC/ODBC und Embedded
SQL unterstützt. Des Weiteren ermöglicht Mimer SQL Embedded auch Netzwerkverbindungen über TCP/IP. Für die Erstellung einer Datenbankapplikation unter Mimer
SQL Mobile bzw. Mimer SQL Embedded steht jeweils eine Entwicklungsumgebung
bereit. Für die verschiedenen Mimer SQL Produkte gibt es mehrere Lizenzmodelle
z.B. basierend auf der Plattform, einem Mengenrabatt entsprechend der Lizenzanzahl oder dem Endbenutzerpreis. Die zuvor genannten Informationen kann man in
[Upr04b, Upr04c, Upr04a, Mim04] nachlesen. Für weitere Einzelheiten sei auf die Webseite http://developer.mimer.com verwiesen.
3.10
Birdstep RDM Embedded 7.1 und Mobile 3.0
Birdstep RDM Embedded 7.1 ist ein Datenbanksystem für Embedded Systems und
Echtzeitanwendungen, dass das Netzwerk- sowie das Relationenmodell unterstützt.
Birdstep RDM Mobile 3.0 ist ein Datenbanksystem für Mobile Computing Systems,
das mit dem Netzwerkmodell arbeitet. Es wird z.B. in Notebooks, PDAs und Smartphones verwendet. Beide Datenbanken nutzen zum Teil dieselbe Datenbank-Engine.
Dadurch ist eine Migration von RDM Embedded zu RDM Mobile möglich. Die Datenbanksysteme verfügen über nachstehende gemeinsame Funktionalitäten:
• unterstützte Schnittstellen: Native C/C++ API mit Datenbankfunktionen, Java
API basierend auf JNI31 , XML API für Import/Export
• C/C++-basierte DDL und Unterstützung von Unicode
• Cachingschemata für minimale Laufwerkszugriffe
• Zugriff auf mehrere Datenbankdateien und Netzwerkzugriff über LANs
• Mehrbenutzerbetrieb und automatisches Datenbank-Recovery
• Transaktionen mit File-Locking bzw. Table-Level-Locking
• Datentypen: C-Datentypen, Arrays, Structs
• einstellbare Datenbankparameter: Page Size, Cache Size
Für die Datenbankentwicklung stehen beiden Datenbanken einige Utilities zur Verfügung z.B. für Interactive Database Access, Database Consistency und Import/Export.
Zusätzlich hat Birdstep RDM Embedded noch eine SQL92-Schnittstelle für Anfragen
und ermöglicht ein Datenbank-Mirroring für eine höhere Performance. Die oben erwähnten Aspekte sind in [Bir04b, Bir04c, Bir04a] enthalten. Weitere Details stehen auf
der Webseite http://www.birdstep.com/database_technology/index.php3.
31
Java Native Interface
3.11
33
McObject eXtremeDB 2.3
McObject eXtremeDB 2.3 ist ein anwendungsoptimiertes, objektorientiertes Hauptspeicher-Datenbanksystem für Embedded Systems und Echtzeitanwendungen, das nicht
unbedingt ein Betriebssystem erfordert. Es wird z.B. in Consumer Electronics, Prozesskontrollsystemen, Routern und Handhelds eingebaut. Die Datenbank wird in vier
Versionen angeboten:
• eXtremeDB Standard Edition – ist eine eingebettete Datenbank, die eine strikte
speicherbasierte Architektur hat. Sie unterstützt mehrere Threads sowie hohe
Transaktionsraten. Die Daten werden in der Form, wie sie in der Anwendung
benötigt werden, gespeichert und direkt im Speicher manipuliert. Typische Leseund Schreibzugriffe liegen im Bereich weniger Mikrosekunden.
• eXtremeDB Shared Memory Edition – diese Version der eXtremeDB Standard
Edition ist für Mehrprozessorumgebungen (z.B. Linux, SUN Solaris, QNX Neutrino) geeignet. Die Datenbank wird im Shared Memory erzeugt und auf den
lokalen Adressraum jedes Prozesses abgebildet. In Abhängigkeit von der Zielplattform unterstützt die eXtremeDB eine der folgenden Synchronisationsmethoden
für Shared Memory Datenbanken: UNIX System V IPC32 -Mechanismus, POSIX
Shared Memory und Win32 Shared Memory.
• eXtremeDB Single Threaded Edition – ist eine lizenzfreie Version der eXtremeDB.
Sie ist identisch mit der Standard Edition, jedoch darf sich nur ein Thread mit
der Datenbank verbinden.
• eXtremeDB High Availability Edition – ermöglicht mehrere identische Datenbanken in getrennten Hardwareinstanzen, die durch nutzerdefinierte Kommunikationskanäle über TCP/IP, UDP/IP, Named Pipes, Qnet33 , CAN34 oder USB
miteinander verbunden sind. Die Kanäle werden für den Datenaustausch und
Kommunikationsnachrichten bei der Transaktionsverarbeitung verwendet. Die
Datenbank wird bei Applikationen mit hoher Verfügbarkeit eingesetzt. Sie unterstützt Load Balancing, ein zeitbewusstes Two-Phase-Commit-Protokoll und
eine Kontrollschnittstelle zur Verwaltung der Datenbankverbindungen.
Die eXtremeDB Standard Edition bietet folgende Features:
• beschleunigte Datenverwaltung durch vollständige Speicherung im Hauptspeicher
und kein Overhead durch Laufwerkszugriffe, Caching und andere Prozesse
• direkter, schneller Datenzugriff im Speicher ohne Kopieren der Daten zwischen
Datenbankspeicher, Cache und Anwendungsspeicher
• eigener Memory Manager und synchrone/asynchrone Ereignisverarbeitung
32
Interprocess Communication
QNX Networking – ermöglicht transparenten Zugriff auf Dateisysteme, Server, Hardwareressourcen im Netzwerk und das Internet über TCP/IP
34
Controller Area Network – asynchrones, serielles Bussystem von Bosch für die Autoindustrie
33
34
• zwei C/C++-Datenbank APIs: für Basisoperationen (Cursor-Bewegungen, Datenbank öffnen/schließen) und für Datenmanipulationen (abgeleitet vom anwendungsspezifischen Datenmodell und mit Schemacompiler erzeugt)
• Hashindizes für Exact-Match-Suche, Baumindizes für Pattern-Match-Suche, Bereichsanfragen und Sortierung sowie OIDs für direkten Zugriff
• eigener Transaction Manager mit warteschlangen- und prioritätsbasierten Scheduling, eigenes Spin Locking zur Kontrolle des wechselseitigen Ausschlusses, Transaction Logging für Recovery
• Datentypen: 1/2/4/8-byte signed/unsigned integer, float, double, date, time, char,
string, enum, array, vector, struct, BLOB
Des Weiteren gibt es noch die eXtremeDB XML Extensions zur Schemaevolution und
zum Datenaustausch mit externen Systemen. Die XML-Erweiterungen sind konform
zum SOAP35 -Standard des W3C. Der Schemacompiler erzeugt Schnittstellenfunktionen
zum Auffinden, Erzeugen sowie Ersetzen von XML-Objekten in der Datenbank und
zur Generierung von XML-Schemata. Die oben angeführten Informationen wurden
[McO04c, McO04b, McO04a] entnommen. Ergänzende Fakten stehen auf der Webseite
http://www.mcobject.com/extremedbfamily.shtml.
3.12
smartDB – eine mobile Datenbank
In diesem Abschnitt wird die mobile Datenbank smartDB vorgestellt. Sie wurde vom
Fraunhofer Institut für Graphische Datenverarbeitung, Abteilung Mobile MultimediaTechnologien, in Rostock entwickelt. Die smartDB in der Version 2.0 wurde mit Personal Java 3.1 programmiert. Daher wird sie vorwiegend auf Smartphones und Pocket
PCs genutzt. Diese relationale Datenbank wurde bereits als mobiles Messeinformationssystem im Rahmen des xGuide-Projektes (siehe [fGDR]) eingesetzt. Vor der Portierung der smartDB auf die Handyplattform besteht eine Aufgabe darin, die vorhandenen Fähigkeiten zu analysieren und Verbesserungsmöglichkeiten für zukünftige
Datenbankversionen zu finden, da die smartDB nur grundlegende Datenbankfunktionalitäten aufweist.
3.12.1
Analyse der vorhandenen Fähigkeiten
Die vorliegende smartDB unterstützt einige grundlegende Funktionen relationaler Datenbanken, die durch Java-Methodenaufrufe realisiert werden.
• Man kann eine neue Datenbank erzeugen oder eine existierende Datenbank verwenden. In einer vorhandenen Datenbank ist es dann möglich neue Tabellen zu
erzeugen oder bestehende Tabellen zu nutzen.
35
Simple Object Access Protocol – leichtgewichtiges, XML-basiertes Protokoll für den Nachrichtenaustausch in verteilten Umgebungen
35
• Die Informationen zu einer Tabelle werden auf zwei Dateien – eine für die Tabellendaten und eine für die zugehörigen Tabellenindizes – abgebildet. Für den
Zugriff auf die Tabellen werden zwei verschiedene Strategien gestattet:
– direkter Zugriff auf die Tabellendatei im Java-Archiv
– Caching der Tabellendatei im Arbeitsspeicher für einen schnelleren Zugriff
• Ferner existieren Methoden, um Tupel zu einer Tabelle hinzuzufügen bzw. zu
löschen oder Tabelleninformationen abzufragen.
• Als Datentypen werden die primitiven Datentypen (Byte, Short, Integer, Long,
Float, Double, Boolean) sowie die Typen String und ByteArray für nichttypisierte
Daten unterstützt.
• Indizes können über eine oder mehrere Tabellenspalten definiert werden. Außerdem stehen Methoden zum Lesen, Schreiben, Einfügen und Löschen der einzelnen
Indexeinträge sowie des ganzen Indexes zur Verfügung.
Neben den oben genannten Operationen zur Datendefinition und für Datenänderungen
sind auch Anfragemethoden verfügbar. Bei der Ausführung von Anfragen wird eine
Selektion der relevanten Datensätze vorgenommen. Für die Selektion können entsprechend dem Datentyp verschiedene Selektoren genutzt werden. Es werden Selektoren für
Integer- und Realzahlen, für Strings (case-sensitive und case-insensitive) sowie Selektoren auf ByteArray-Ebene bereitgestellt. Die Selektoren auf ByteArray-Ebene können
auf Enthaltensein, Gleichheit oder Übereinstimmung mit einem Präfix testen. Darüber
hinaus gibt es die Möglichkeit neben einer Selektion auf den Werten einer Spalte auch
eine Selektion auf den Werten mehrerer Spalten durchzuführen. Bei der Anfrage von
Informationen werden, wenn möglich, die Indizes und binäre Suche verwendet. Unter
Nutzung der Selektoren und der Tabellen sind auch Sichten definierbar.
3.12.2
Verbesserungsmöglichkeiten für zukünftige Versionen
Nachdem im vorhergehenden Abschnitt die existierenden Funktionen der smartDB
beschrieben wurden, sollen in diesem Abschnitt mögliche neue Features präsentiert
werden. Dazu werden die im vorangehenden Kapitel diskutierten Datenbankkriterien
herangezogen. Für die Relevanz der neuen Funktionen sind insbesondere die Anforderungen der mobilen Nutzung zu beachten.
• Zwecks Integritätssicherung gibt es nur einen Versionsvergleich zwischen den
Daten- und Indexdateien. Falls unterschiedliche Dateiversionen existieren, werden die Indizes neu erstellt, damit ein Zugriff auf die korrekten Datenbankinhalte möglich ist. Darüber hinaus könnte man noch zusätzliche Mechanismen zur
Sicherung korrekter Datenbankinhalte hinzufügen. Beispielsweise fehlt eine Prüfung auf Schlüsseleigenschaft und die Verwendung von Fremdschlüsselbedingungen. Weitere Maßnahmen zur Konsistenzüberwachung wie z.B. Check-Klauseln
oder Trigger sind in Abhängigkeit von der Leistungsfähigkeit der mobilen Geräte
einzusetzen.
36
• In den Tabellen existiert noch keine Unterstützung für Null-Werte. Falls ein Wert
undefiniert ist, wird er durch leere Bytes gekennzeichnet. Eventuell wäre die explizite Festlegung eines Null-Symbols für die Kennzeichnung von undefinierten
Werten sinnvoll. Gegebenenfalls könnte man noch andere Datentypen (z.B. Char,
Date, Time, usw.) ergänzen.
• Eine Zugriffskontrolle und Rechtevergabe ist nicht weiter relevant, weil in der
Regel nur ein Nutzer das mobile Gerät bedient. Bei der Verbindung zwischen
dem mobilen Client und dem Datenbankserver sollte eine verschlüsselte Datenübertragung sowie eine Authentifizierung ermöglicht werden. In den bisherigen
Anwendungsszenarien spielte es noch keine Rolle, da nur eine Datenverwaltung
auf dem mobilen System verlangt wurde. Zwecks Datenschutz ist auch eine verschlüsselte Datenspeicherung auf dem mobilen Client erforderlich.
• Für eine einfache Datenverwaltung auf dem mobilen Gerät werden normalerweise
keine Transaktionskonzepte und Synchronisationsverfahren benötigt. Interessant
werden Synchronisationsmethoden erst, wenn der Nutzer über das Mobilfunknetz
aktuelle Daten vom Datenbankserver abruft. Ein Transaktionskonzept ist nur
dann notwendig, wenn der Nutzer die Änderungen an seinen lokalen Daten auf
dem mobilen Client auf den Server überspielen möchte.
• Mechanismen zur Datensicherung und Datenwiederherstellung bei Systemfehlern
bestehen noch nicht. Im Hinblick auf die beschränkten Speicherkapazitäten mobiler Einheiten ist das auch schwierig. Eine erdenkliche Lösung ist ein Datenbankbackup auf dem eigenen Rechner.
• Als Schnittstelle für die Datenbankoperationen wird nur der Aufruf von JavaMethoden angeboten. Deswegen ist die Definition einer SQL-Schnittstelle für
Anfragen sowie für den Import und Export der Daten eine weitere sinnvolle
Ergänzung. In Anbetracht des limitierten Speicherplatzes kann nur eine kleine
Untermenge des gesamten SQL-Sprachumfangs auf dem mobilen Gerät realisiert
werden. Besonders wichtig sind dabei Tabellen, Indizes, Sichten und Änderungsoperationen auf den Daten. Die Projektion, der Verbund, die Vereinigung, die
Differenz und die Umbenennung fehlen noch, da in der vorliegenden Datenbank
nur die Selektion vorhanden ist. Ergänzen könnte man die Anfragesprache noch
um Gruppierung, Aggregatfunktionen und Quantoren.
• Zur Anfrageoptimierung trägt nur die konsequente Nutzung der Indexstrukturen
bei. Eine weitere Optimierungsmöglichkeit ist die Verwendung von vorsortierten
Daten, wenn auf eine Tabellenspalte sehr häufig zugegriffen wird. Dieser Vorgehensweise spart Speicherplatz für zusätzliche Indizes ein. Außerdem könnte
man noch die vorhandenen Caching-Strategien weiter optimieren. Diese Verbesserung wäre für die Performance des Systems sicherlich gut, ist aber nur bei
genügend Speicher realisierbar. Zudem müssen bei der Anfrageoptimierung die
Kosten (Optimierungszeit, CPU-Auslastung, Speicherbedarf, Batterieverbrauch)
und der Nutzen ins Verhältnis gesetzt werden.
37
• Bei der Speicherverwaltung ist man sehr stark an die zu Grunde liegende Hardware gebunden. Die Tupel werden in der Regel sequenziell gespeichert. Eine Optimierung könnte man durch einen zusätzlichen Index über dem Sortierattribut
der sequenziellen Daten erhalten (indexsequenzielle Organisation). Durch bessere
mehrstufige Zugriffsstrukturen (z.B. ein dünnbesetzter Index oder ein geclusterter Index) könnte man die Performance bei der Suche verbessern. Eine weitere
Möglichkeit ist die Verwendung einer B-Baum-Struktur, die einen dynamischen,
balancierten Indexbaum darstellt. Bei allen Zugriffsstrukturen muss jedoch der
verfügbare Arbeitsspeicher auf dem mobilen Gerät berücksichtigt werden.
Natürlich ist bei einer Implementierung wieder die Leistungsfähigkeit der Hardware
und das Einsatzszenario zu beachten, so dass gegebenenfalls der Funktionsumfang des
Datenbanksystems eingeschränkt werden muss, um eine akzeptable Performance zu erreichen. Neben den bereits aufgezählten Erweiterungsmöglichkeiten für die smartDB
ist die Portierung auf eine andere Plattform zu überlegen, weil Personal Java und
Embedded Java durch die Java 2 Micro Edition (Java 2 ME) ergänzt werden. Java 2
ME ist die Plattform der Zukunft, da sie von zahlreichen Herstellern mobiler Geräte
schon unterstützt wird oder die Entwicklung von Anwendungen mit Java 2 ME forciert
wird. Auch wäre eine Portierung auf C/C++ zu überlegen, weil eine Implementierung
des Datenbanksystems in einer systemnahen Programmiersprache eine bessere Performance bieten könnte. Die Entscheidung für C/C++ hat jedoch den Nachteil, dass die
Plattformunabhängigkeit von Java verloren geht. Eine Implementierung der smartDB
in C/C++ existiert zur Zeit nur in Ansätzen für den Pocket PC.
Kapitel 4
Implementierungsarbeiten
Anschließend an die vorangegangene Diskussion der Funktionalitäten der smartDB
wurden einige Aspekte ausgewählt und implementiert. Aus folgenden Gründen wurde
eine Portierung der smartDB auf die Java 2 Micro Edition (Java 2 ME) vorgenommen:
• Die Java 2 ME wird von vielen aktuellen und fast allen neuentwickelten mobilen
Geräten, unabhängig vom Betriebssystem, unterstützt.
• Die Mehrheit der mobilen Datenbanksysteme ist vorwiegend für den Einsatz auf
PDAs und Smartphones gedacht. Durch die steigende Leistungsfähigkeit der mobilen Endgeräte, insbesondere der Handys, eröffnet sich ein neuer Markt auf dem
bislang nur wenige Datenbanksysteme existieren.
• Gegenüber den teureren Handhelds und Smartphones sind Mobiltelefone heutzutage in der Bevölkerung wesentlich stärker verbreitet. Infolgedessen kann jeder
Nutzer sein Handy z.B. auf Messen, Ausstellungen oder in Museen als mobiles
Informationssystem nutzen.
• Dieser Bedarf für eine mobile Handydatenbank geht einher mit dem xGuideProjekt (siehe [fGDR]), das ein mobiles Messeinformationssystem auf allen mobilen Plattformen (PDA, Smartphone und Handy) bereitstellen will.
Für eine größtmögliche Kompatibilität mit den mobilen Geräten wurde die Java 2
ME (CLDC 1.0/MIDP 1.0) für die Portierung der smartDB ausgewählt. Dazu erfolgte einer Neuimplementierung der benötigten Funktionen mittels der Java 2 ME, bei
der man sich an den vorhandenen Funktionalitäten und den Einschränkungen der gewählten Plattform orientieren muss. Zusätzlich wurden einige neue Features bei der
Implementierung hinzugefügt. Die Details zur Java 2 Micro Edition kann man dem
nachfolgenden Abschnitt entnehmen. Folglich können alle Mobiltelefone, Smartphones
und Handhelds, die die entsprechenden Java ME Profile unterstützten, die smartDB
verwenden. Dazu zählen z.B. alle Smartphones mit Symbian OS 6.0 oder höher, Palm
PDAs ab Palm OS 5.2 unter Verwendung des IBM WebSphere Micro Environments
(WME) sowie die meisten neueren Handys.
38
KAPITEL 4. IMPLEMENTIERUNGSARBEITEN
4.1
39
Java 2 Micro Edition
Auf Grundlage der Java 2 Plattform wurden von Sun Microsystems verschiedene JavaEditionen entsprechend dem Einsatzgebiet entwickelt:
• die Java 2 Enterprise Edition (J2EE) für Server-Anwendungen
• die Java 2 Standard Edition (J2SE) für Desktop-Rechner
• die Java 2 Micro Edition (J2ME) für kleine, mobile Geräte und eingebettete
Systeme (z.B. Mobiltelefone)
• die Java Card Spezifikation für Smart Cards und andere Mini-Geräte
Die J2ME Technologie unterscheidet zwei Hauptkomponenten: Konfigurationen und
Profile. Eine Konfiguration ist eine Spezifikation, die eine Java Virtual Machine (JVM)
und eine grundlegende Menge von APIs für eine bestimmte Geräteklasse beschreibt.
Ein Profil ist eine Spezifikation, die die darunter liegende Konfiguration nutzt und die
vorhandenen APIs erweitert, um eine komplette Laufzeitumgebung für ein spezielles
Gerät bereitzustellen. Beispielsweise ist das UserInterface für ein Gerät profilspezifisch.
Darüber hinaus können die Profile in Abhängigkeit von der Konfiguration durch weitere optionale Pakete ergänzt werden. Die Abbildung 4.1 zeigt die Architektur der
Java 2 Micro Edition, wobei zwischen zwei Klassen unterschieden wird. Im Rahmen
dieser Studienarbeit ist insbesondere die Klasse mit den in Abbildung 4.1 eingerahmten Komponenten für die Portierung der smartDB auf ein Handy interessant. Weitere
Details zur Java 2 Micro Edition kann man [Suna] entnehmen.
Abbildung 4.1: Architektur der Java 2 Micro Edition
4.1.1
40
Konfigurationen und Profile
• Die Connected Device Configuration (CDC) ist eine Spezifikation für mobile Geräte mit viel Speicher und großer Rechenleistung (z.B. High-End-PDAs, Telematik, Set-Top-Boxen, Netzwerkdrucker und Router). Diese Geräte haben eine
ständige Netzwerkverbindung, 32-Bit-Prozessoren und minimal 2 MB verfügbaren Speicher für Java. Die Compact Virtual Machine (CVM) ist eine optimierte
JVM, die von CDC genutzt wird.
• Das Foundation Profile ist eine auf CDC aufbauende Spezifikation, die zusätzliche Klassen und Schnittstellen hinzufügt, aber keine APIs für die Benutzeroberfläche, eine dauerhafte Speicherung und die Anwendungslebensdauer. Die
fehlenden APIs werden durch weitere Profile wie das Personal Basis Profile
mit einem leichtgewichtigen GUI und das Personal Profile mit vollem AWTSupport ergänzt. Ferner kann man die Funktionalität noch mit optionalen Paketen für RMI und JDBC erweitern. Für weitere Informationen zu CDC sei auf
[Sun03b] verwiesen.
• Die Connected Limited Device Configuration (CLDC) ist eine Spezifikation für Geräte mit 160 kB bis 512 kB Speicher für Java und begrenzten,
zeitweilig unterbrochenen Netzwerkverbindungen. Diese Geräte haben eine eingeschränkte Rechenleistung (16-Bit- oder 32-Bit-Prozessor), wenig Speicher, limitierte graphische Funktionen und sind oft batteriebetrieben (z.B. Mobiltelefone, Pager und Low-End-Organizer). Die Kilobyte Virtual Machine (KVM) ist
eine in ihrer Leistungsfähigkeit reduzierte, speziell für kleine Geräte konzipierte JVM. Sie unterstützt einige APIs für grundlegende Anwendungsdienste. Die
APIs sind Minimalversionen der J2SE-Pakete java.io, java.lang und java.util sowie javax.microedition.io für Netzwerkverbindungen.
• Das Mobile Information Device Profile (MIDP) ist die Spezifikation einer
Schicht über CLDC, die APIs für die Anwendungslebensdauer, die Benutzeroberfläche, den Netzwerkbetrieb und eine dauerhafte Speicherung hinzufügt. Als
optionale Pakete können z.B. das Wireless Messaging API, das Mobile Media
API, das Location API und das Bluetooth API eingebunden werden. Eine Liste
aller optionalen Pakete findet man bei den Java Specification Requests (JSR) for
J2ME unter [Sunb].
4.1.2
Details zu CLDC und MIDP
Die J2ME hat einige Einschränkungen im Vergleich zur J2SE. Es gibt verschiedene
Versionen von CLDC und MIDP. Die Versionen sind aber abwärtskompatibel. In CLDC
1.0 gibt es folgende Restriktionen im Vergleich zur J2SE:
• keine Unterstützung von Gleitkommazahlen (Float, Double) auf Grund fehlender
Hardwareunterstützung
• eingeschränkte Fehlerbehandlung auf Grund sehr gerätespezifischer Fehlerbedingungen und Speichermangel
41
• kein Java Native Interface (JNI) wegen Sicherheits- und Speicherproblemen
• keine Methode Object.finalize() und Weak References für eine Vereinfachung
der Garbage Collection
• keine Reflection und Serialisierung von Objekten
• keine nutzerdefinierten Class Loader da stark geräteabhängig
• keine Thread Groups und Daemon Threads
• keine Klassenverifizierung im J2ME-Programm, sondern eine Zweiteilung in den
Preverifier nach dem Kompilieren und eine leichtere Runtime-Verifikation
Beim Kompilieren muss Bytecode für die Java-Version 1.1 erzeugt und die richtigen
Bootklassen eingebunden werden. Bei der Programmausführung werden gewöhnliche
Java-Programme von der JVM auf konsistenten Bytecode geprüft. Dieser Prozess erfolgt in zwei Phasen, da die Geräte mit der KVM nur geringe Ressourcen haben. Es
wird eine erste Pre-Verifizierung (Bytecode-Erweiterung um StackMap-Attribute) auf
dem Entwicklungsrechner durchgeführt und eine zweite Runtime-Verifizierung (schnell
und speichersparend) auf dem mobilen Gerät vorgenommen.
Außerdem sind in CLDC 1.0 als Speicheranforderungen 128 kB nichtflüchtiger Speicher für die JVM und die CLDC-Bibliotheken sowie 32 kB flüchtiger Speicher für die
Java-Runtime und die Objekte festgelegt. In CLDC 1.1 wurden einige Überarbeitungen
vorgenommen und die Unterstützung von Gleitkommazahlen sowie Weak References
hinzugefügt. Deswegen wurde der minimale nichtflüchtige Speicher auf 160 kB erhöht.
Weitere Fakten dazu kann man in den CLDC-Spezifikationen [Sun00a, Sun03a] finden.
In MIDP 1.0 sind folgende Minimalanforderungen an die Hardware definiert:
• Displaygröße mit 96 x 54 Pixeln, 1 Bit Farbtiefe und Pixelshape 1:1
• Telefontastatur, Computertastatur oder Touchscreen als Eingabemöglichkeit
• drahtlose, bidirektionale und gegebenenfalls unterbrochene Netzwerkverbindung
mit limitierter Bandbreite
• 128 kB nichtflüchtiger Speicher (ROM/Flash) für die MIDP-Komponenten
• 8 kB nichtflüchtiger Speicher für die dauerhafte Datenspeicherung
• 32 kB flüchtiger Speicher (RAM) für die Java-Runtime
Auf MIDP basierende Anwendungen unterstützen folgende Features:
• minimaler Kernel zum Hardwaremanagement (z.B. Handling von Interrupts, Exceptions, Scheduling)
• Systemfunktionen (z.B. Abfragen von Systemeigenschaften, Auslesen von Ressourcendateien)
• Timer für die Verzögerung und Planung von Aktivitäten
42
• Netzwerkverbindungen durch Verwendung einer Untermenge des HTTP-Protokolls 1.1 und Implementierung mit TCP/IP, WAP oder iMode
• High-Level-APIs (GUI-Portierung auf verschiedene Geräte möglich) und LowLevel-APIs (direkte Displayänderungen möglich) für die Entwicklung von Benutzeroberflächen
• dauerhafte Datenspeicherung (siehe Abschnitt Record Management System)
• Anwendungsmanagement (siehe Abschnitt MIDlets)
In MIDP 2.0 wurden für Formulare und Spiele einige Erweiterungen beim User Interface vorgenommen (z.B. neues Formularlayout, neue Formularelemente und OffscreenRendering möglich). Zudem wurde eine einfache Soundunterstützung als Untermenge
des Mobile Media APIs ergänzt. Die Netzwerkfähigkeiten wurden durch verschlüsselte
Verbindungen mit HTTPS verbessert. Die Geräte müssen einen „Over the Air“-Zugriff
(OTA) und eine Rechtevergabe für MIDlet-Suites ermöglichen. MIDlet-Suites können
mit Hilfe des MIDP X.509 Zertifikats signiert und authentifiziert werden. Daneben
wurde der minimale nichtflüchtige Speicher auf 256 kB erhöht. Zusätzliche Einzelheiten stehen in den MIDP-Spezifikationen [Sun00b, Sun02].
4.1.3
Record Management System – eine einfache Datenbank
Das Record Management System (RMS) ist eine einfache record-orientierte Datenbank,
um die Anwendungsdaten dauerhaft zu speichern. Es kann von einem mobilen Datenbanksystem oder von einem Anwendungsprogramm zur Datenspeicherung verwendet
werden. Das RMS wird häufig für die Speicherung von kleinen Datenmengen (z.B.
Spielständen) eingesetzt.
Ein RecordStore besteht aus einer Sammlung von Records, die bei mehrfachen MIDletAufrufen persistent bleiben. Die RecordStores werden plattformabhängig irgendwo im
Speicher abgelegt. MIDlets können mehrere RecordStores mit eindeutig identifizierenden Namen innerhalb einer MIDlet-Suite erzeugen und nur auf diese zugreifen. Erst
ab MIDP 2.0 kann ein MIDlet einem MIDlet aus einer anderen MIDlet-Suite Daten
freigeben. Beim Entfernen einer MIDlet-Suite werden alle zugehörigen RecordStores
gelöscht. Es gibt keine Locking-Operationen für parallele Zugriffe, da alle einzelnen
Operationen atomar, synchron und serialisiert sind. Ein RecordStore hat einen Zeitstempel und eine Versionsnummer. Das Lesen und Schreiben in einen RecordStore ist
sehr langsam, da die Zugriffszeiten in Abhängigkeit von den Geräten zwischen 50 ms
und 1000 ms liegen. Eine Übersicht dazu findet man unter [dUD]. Ein weiteres Problem
ist die maximale Größe eines RecordStores. Sie ist geräteabhängig und liegt meist bei
64 kB oder weniger. Darum sollte man möglichst kleine Datenblöcke verwenden oder
ganz darauf verzichten.
Die einzelnen Records sind ByteArrays, auf die mit InputStreams und OutputStreams zugegriffen wird. Sie werden über eine RecordID als Primärschlüssel eindeutig
identifiziert. Die Records können mit einem RecordFilter gefiltert und mit einem RecordComparator sortiert werden. Indizes werden mit Hilfe einer RecordEnumeration
definiert.
4.1.4
43
MIDlets – die MIDP-Anwendungen
Ein MIDlet ist eine MIDP-Anwendung, die in einer SandBox-Umgebung ausgeführt
wird. Es besitzt keine main()-Methode und ist einem Applet ähnlich. Das MIDlet kann
auf keine Dateien außerhalb des eigenen Java-Archivs (JAR) zugreifen. Die JAR-Datei
enthält eine MIDlet-Suite mit einem oder mehreren MIDlets, die untereinander interagieren können. Außerdem sind in der JAR-Datei ein Manifest zur Beschreibung des
Archivinhaltes, die von den MIDlets exklusiv bzw. gemeinsam genutzten Klassen sowie
die Ressourcendateien enthalten. Das Manifest ordnet jedem MIDlet, einen Namen,
ein Icon und die zugehörigen Klassen zu. Es muss Informationen über den JAR-Inhalt
wie die Namen, die Versionen, die Lieferanten und die Nummern der MIDlets mit entsprechender Startklasse sowie die CLDC- und MIDP-Versionen enthalten. Ein MIDlet
kann sich während seines Lebenszyklusses in folgenden Zuständen befinden:
• active – interagiert gerade mit dem Benutzer
• paused – wird gerade nicht genutzt bzw. wurde gerade erzeugt
• destroyed – hat alle Ressourcen freigegeben bzw. eine Exception ist aufgetreten
Jedes Gerät hat eine Application Management Software (AMS), die sich um die Installation, die Ausführung, die Deinstallation und die Nutzerinteraktion mit der MIDletSuite kümmert. Die AMS liest die benötigten Attribute aus dem Manifest und dem
Application Descriptor aus. Der Java Application Descriptor (*.jad-Datei) wird von
der AMS zur MIDlet-Verwaltung genutzt und kann konfigurations- und anwendungsspezifische Parameter enthalten. Er muss als Informationen die Namen, die Versionen,
die Lieferanten und die Nummern der MIDlets sowie die URL und die Größe des JavaArchivs in Bytes enthalten.
4.2
Anforderungen und Restriktionen bei der Programmierung der smartDB mit J2ME
Die Entwicklung der smartDB für J2ME verlangt vor allem eine effiziente und speicherschonende Implementierung, da die mobile Handydatenbank möglichst die gesamte
Bandbreite an Geräten von der Einstiegsklasse bis hin zur Profiklasse abdecken soll.
Geräte der Einstiegsklasse sind in der Regel dadurch gekennzeichnet, dass die maximale Heapgröße auf 150 kB und die maximale Größe der JAR-Datei auf 64 kB begrenzt
sind. Diese Werte sind jedoch von der entsprechenden Gerätespezifikationen abhängig und werden sich mit zukünftigen Gerätegenerationen sicherlich weiter erhöhen.
Deshalb sind für eine mobile Datenbank schon enge Grenzen für die Größe des Datenbanksystems und den Umfang der Daten gesetzt worden. Des Weiteren kann man
einen Großteil des verfügbaren Speichers auf dem mobilen Gerät wegen der schlechten RMS-Zugriffszeiten und der begrenzten RecordStore-Größe so gut wie gar nicht
verwenden. Als Ergebnis dieser Voraussetzungen bleibt nur die Implementierung eines elementaren Datenbanksystems, das mit fortschreitender Hardwareentwicklung in
seiner Leistungsfähigkeit erweitert wird.
44
• Daher sollte ein möglichst geringer Speicherverbrauch bei der Implementierung
durch wenige Klassen, einfache Variablentypen anstatt Objekten, keine Schnittstellen, nur absolut notwendigen Methoden und effizienten Datenstrukturen Rechnung getragen werden.
• Die Verwendung eines File Shrinkers & Code Obfuscators ist fast unabdingbar.
Dadurch wird die Dateigröße der Java-Klassen verringert. Kommentare, unbenutzte Klassen, Felder, Methoden und Attribute werden erkannt und entfernt.
Ferner erfolgt eine Umbenennung der übrig gebliebenen Klassen, Felder und Methoden mit kurzen Namen (z.B. a.class anstatt Database.class).
• Im Hinblick auf die langsamen Prozessoren in mobilen Geräten sollte man alle rechenintensiven Operationen möglichst gering halten, indem man Objekte
wiederverwendet, lokale Variablen anstatt Klassen-/Objektvariablen gebraucht
sowie bitweise Shiftoperationen anstatt Multiplikationen und Divisionen nutzt.
Auf Verkettungen von String-Objekten und Exceptions sollte man verzichten und
durch eine elegante Programmierung umgehen. Den Garbage Collector sollte man
dadurch unterstützen, dass man die Referenzen von nicht mehr benötigten Objekten auf Null setzt (für eine schnellere Speicherfreigabe) oder den Garbage
Collector an passenden Stellen manuell aufruft.
• Der Datenverkehr zwischen dem mobilen Gerät und der Basisstation sollte auf
Grund der limitierten Bandbreite klein gehalten werden. Dieser Aspekt ist vorläufig nicht weiter relevant, da bei der smartDB mit J2ME nur die Datenverwaltung
und effiziente Anfragen im Vordergrund stehen.
4.2.1
JOIN-Implementierung – ja oder nein?
Bevor man einen Verbund für die Handydatenbank implementiert, ist eine KostenNutzen-Betrachtung sinnvoll. Zu diesem Zweck muss man sich folgende Fragen stellen:
• Welchen Aufwand hat die Implementierung eines JOINs?
Der Verbund ist eine teure Operation und für die effiziente Ausführung einer Anfrage müsste man eine Anfrageoptimierung programmieren. Ein Beispiel für die
Kosten bei optimierter und nicht optimierter Anfrageauswertung kann man in
[HS99] im „Kapitel 7.2 Motivierende Beispiele“nachlesen. Diese Beispiele zeigen,
dass die Implementierung eines Verbundes in der Regel nur in Verbindung mit
einer Anfrageoptimierung sinnvoll ist. Ohne eine Optimierung wäre der Verbund
auf Grund der eingeschränkten Ressourcen eines Handys (schwacher Prozessor
und wenig Speicher) problematisch. Folglich ist die Implementierung eines Verbundes und der zugehörigen Anfrageoptimierung aufwändig.
• Welche Vorteile bringt ein JOIN für die Handydatenbank?
Ein Verbund hat nur einen Vorteil, wenn man dadurch Datenredundanz vermeiden kann. Bei den geringen Datenmengen auf einem mobilen Gerät ist das weniger
wichtig. Deshalb ist zu überlegen, ob ein zusätzlicher Overhead beim DBMS, für
einen nicht oft gebrauchten Verbund, gerechtfertigt ist.
45
• Wie viele Tabellen soll man beim JOIN miteinander verknüpfen können?
Beliebig viele Tabellen können wegen Speicherknappheit nicht miteinander verknüpft werden. Des Weiteren wird bei vielen auszuführenden Verbundoperationen
der schwache Prozessor stark belastet. Darum muss man in Abhängigkeit vom
Gerät die Verbundanzahl begrenzen oder bei ganz schwachen Geräten ganz auf
Verbunde verzichten.
• Welche Verbundalgorithmen kann man verwenden?
Für die Berechnung eines JOINs zweier Relationen gibt es mehrere Techniken:
– Beim Hash-Join wird die kleinere Relation in einer Hashtabelle gespeichert
und die Tupel der anderen Relation finden ihre Vergleichspartner für die Verknüpfung über eine Hashfunktion. Der Hash-Join ist bei geeigneter Wahl der
Hashfunktion und einem hinreichendem Arbeitsspeicher am effizientesten.
Dieses Verfahren ist allerdings nur bei kleinen Datenmengen auf dem Handy
möglich, da die Speicherkapazitäten gering sind.
– Für den Merge-Join werden die beiden Relationen in der vorgegebenen
Tupelreihenfolge durchlaufen und miteinander verknüpft. Als Vorbereitung
müssen beide Relationen nach dem gleichen Sortierkriterium geordnet sein.
Die Details zu den verschiedenen Sortierverfahren kann man dem nächsten
Abschnitt entnehmen. Die Sortierung der Relationen hat den größten Aufwand und ist bei großen Datenmengen auf dem Handy wegen schwacher
Prozessoren sehr langwierig. Der Merge-Join ist am günstigsten, wenn eine
oder beide Relationen bereits sortiert vorliegen.
– Beim Nested-Loop-Join werden die beiden Relationen durch die Abarbeitung
zweier ineinander geschachtelter Schleifen verknüpft. Der Nested-Loop-Join
benötigt die meisten Vergleiche, ist aber für alle Verbundarten geeignet.
• Benötigt man einen Verbund und wenn ja welchen JOIN-Typ verwendet man für
die smartDB mit J2ME?
Auf den JOIN wurde erst einmal verzichtet, weil der Aufwand für die Implementierung eines Verbundes groß ist und die Ressourcen für die mobile Handydatenbank begrenzt sind. Außerdem war ein Ziel bei der Programmierung der
smartDB mit J2ME ein sehr kleines Datenbanksystem zu programmieren, damit
das Java-Archiv möglichst viele Nutzdaten aufnehmen kann. Ferner erfordern die
bisherigen Anwendungsszenarien nur eine einfache Datenverwaltung, so dass ein
Verbund nur unbenötigte Ressourcen belegen würde. Falls der Verbund trotzdem
notwendig ist, kann das auch leicht der Anwendungsprogrammierer realisieren,
indem er einzelne Anfragen an verschiedene Tabellen stellt und die Ergebnismengen mittels Nested-Loop-Join verknüpft.
4.2.2
Varianten von Sortierverfahren
In diesem Abschnitt sollen verschiedene Sortierverfahren betrachtet werden, die man
eventuell für die Sortierung der Daten verwenden kann.
46
• Externe Sortierverfahren wie z.B. das Sort-Merge-Verfahren aus der klassischen
Datenbanktechnik sind für die smartDB mit J2ME nicht verwendbar, weil man
nur lesend auf die Tabellendaten zugreifen kann. Darüber hinaus steht kein Dateisystem zur Zwischenspeicherung zur Verfügung bzw. das RMS ist nur beschränkt
und für kleine Datenmengen nutzbar. Folglich bleiben nur Hauptspeicheralgorithmen.
• Ein schnelles Sortierverfahren das im Hauptspeicher arbeitet ist QuickSort. Dieser Sortieralgorithmus ist sehr gut für kleine Datenmengen auf dem mobilen Gerät einsetzbar. Im Gegensatz dazu ist bei großen Datenmengen der zusätzliche
Aufwand an Speicherplatz für die Rekursionsaufrufe zu groß, so dass man dieses Verfahren und andere rekursive Verfahren wie MergeSort nur in bestimmen
Einsatzszenarien benutzen kann.
• Eine andere Algorithmenklasse sind die elementaren Sortierverfahren wie z.B.
InsertSort. Dieses Verfahren setzt man am besten auf mobilen Geräten mit viel
Speicher ein, da es neben dem Speicherplatz für die Originaldaten noch einmal
den selben Speicherplatz für die Ergebnisdaten zum Einsortieren benötigt. Bei
Handys mit geringen Speicherkapazitäten ist doppelter Speicherplatzbedarf ein
Problem.
• Folglich sind für bestimmte Geräteklassen Sortieralgorithmen notwendig, die keinen oder nur sehr wenig zusätzlichen Speicherplatz für die Sortierung verlangen
und ohne Rekursionen arbeiten. Ein Beispiel dafür ist SelectSort, da nur für die
Suche des minimalen Elementes zusätzlicher Speicherplatz gebraucht wird. Dieser
Aspekt ist hinsichtlich der knappen Ressourcen der Handys wichtig.
• Ein weiterer Algorithmus, der kaum zusätzlichen Speicherplatz beansprucht, ist
HeapSort. Außerdem hat HeapSort eine logarithmische Zeitkomplexität für die
Sortierung gegenüber einer quadratischen Zeitkomplexität bei SelectSort und ermöglicht deshalb eine schnellere Sortierung. Dieser Gesichtspunkt ist bei den
Handys mit langsamen Prozessoren zu beachten.
Für die smartDB mit Java 2 ME wurden der SelectSort- und der HeapSort-Algorithmus
implementiert.
4.2.3
Probleme und Lösungen bei großen Datenmengen
Bei großen Datenmengen können Schwierigkeiten auftreten, da die Speicherkapazitäten
von mobilen Geräten und insbesondere des Heapspeichers begrenzt sind. Eine einfache
Lösung dafür ist die Daten der Tabelle nur teilweise einzulesen. Diese Maßnahme hat
den Vorteil, dass man Speicherplatz einspart. Der Nachteil ist die vergrößerte Anfragezeit. Man muss mehrfach auf die Ressourcendateien im Java-Archiv Zugriff nehmen,
weil die Daten nicht im Hauptspeicher liegen. Das fällt bei Handys mit ihren schwachen Prozessoren besonders auf. Es kann ebenfalls Probleme geben, wenn alle Tupel
der Tabelle sortiert oder Duplikate eliminiert werden sollen. Das Datenvolumen ist begrenzt, da die Größe der JAR-Datei meist auf 64 kB limitiert ist. Demzufolge kann
47
man die Daten meistens komplett in den Heapspeicher von in der Regel 150 kB einlesen. Außerdem muss man noch den Speicherbedarf des Datenbanksystems und des
Anwendungsprogramms im JAR abziehen. Das Ziel bei der Entwicklung der smartDB
mit Java 2 ME war ein möglichst kleines DBMS mit den notwendigsten Funktionalitäten für die begrenzten Handyressourcen zu entwickeln. Das programmierte DBMS hat
eine Größe von circa 12 kB im JAR. Folglich hat man noch rund 50 kB für Daten und
Anwendungsprogramme im JAR zur Verfügung. Die Daten im Java-Archiv werden auf
circa ein Drittel der Originalgröße komprimiert, so dass man ungefähr 135 kB Daten
unterbringen könnte.
Eine andere Alternative bei zu kleinem Speicher wäre die Daten situationsabhängig zu
laden. Dazu müsste man sich stets über Wireless LAN, Bluetooth, UMTS, GPRS, usw.
die aktuellen Daten herunterladen. Diese Vorgehensweise verursacht wiederum Kommunikationskosten. Bei schlechten Empfangsbedingungen sind Online-Zugriffe schwierig.
Bei der J2ME werden HTTP-Zugriffe auf einen Webserver ermöglicht, so dass man sich
die entsprechenden JAR-Dateien herunterladen und installieren kann.
Eine weitere Möglichkeit zum Sparen von Speicherplatz ist die Datenreduktion, indem
man versucht den Wertebereich der Datentypen besser auszunutzen. Beispielsweise liegen Integerwerte zwischen -2147483648 und 2147483647. Falls man nur positive Werte
benötigt, könnte man die vorzeichenbehafteten Zahlen auf den vorzeichenlosen Wertebereich zwischen 0 und 4294967295 abbilden. Dadurch könnte man in bestimmten
Anwendungsszenarien auf 8 Byte Longzahlen verzichten und mit 4 Byte Integerzahlen
arbeiten.
Mit der zukünftigen Entwicklung immer leistungsfähiger, mobiler Hardware, die schon
teilweise in Smartphones und High-End-PDAs eingebaut wird, sollten sich die Restriktionen für die mobilen Anwendungen verringern.
4.3
Datentypen und Struktur des Dateiformats
Die ursprüngliche smartDB und das Dateiformat unterstützen als Datentypen Byte,
Short, Integer, Long, Float, Double, Boolean, String und ByteArray. Die smartDB mit
J2ME basiert auf der Konfiguration CLDC 1.0 und dem Profil MIDP 1.0. Deshalb
wurden die gemäß der Spezifikation unterstützten Datentypen mit den entsprechenden
Vergleichsfunktionen (siehe Klasse Type.java) implementiert. In Abhängigkeit vom
Datentyp stehen folgende Vergleichsoperationen zur Verfügung:
• Byte, Short, Integer und Long – Equal, NotEqual, LessThan, LessThanEqual,
GreaterThan und GreaterThanEqual
• Boolean – Equal und NotEqual
• String – Equal, NotEqual, LessThan, LessThanEqual, GreaterThan, GreaterThanEqual, StartsWith und Contains
Falls man Gleitkommazahlen nicht umgehen kann, muss man sie mittels Festkommazahlen simulieren oder eine weitere Datenbankversion für CLDC 1.1 und MIDP 2.0
programmieren.
48
Die einzelnen Tabellen der Datenbank sind als Ressourcendateien im Java-Archiv enthalten. Die Ressourcendateien haben die Bezeichnung Tabellenname.Erweiterung (z.B.
TABLE.STD), wobei Datendateien die Erweiterung STD und Indexdateien die Erweiterung STI haben. Die Tabellendaten sind im Binärformat in den Dateien abgespeichert
und kompatibel mit dem Dateiformat der smartDB mit Personal Java. Die Kompatibilität des Dateiformates ist wichtig, damit man auf allen mobilen Geräten und Plattformen ein einheitliches Binärformat verwenden kann. Dieser Ansatz vereinfacht auch
die Anwendungsentwicklung. Die Tabelle 4.1 gibt einen Überblick über das Dateiformat der Datendateien mit 64 Byte Tabellenheader, Tabellenschema und Tabellendaten.
Das Dateiformat der Indexdateien ist ähnlich aufgebaut. Es enthält einen Adressindex
und kann mehrere Spaltenindizes enthalten. Der Adressindex ist unsortiert und enthält alle Recordpositionen in der Datei. Die Spaltenindizes sind in der entsprechenden
logischen Reihenfolge der Records sortiert. Die Indexdateien werden von der smartDB
mit J2ME wegen Speichermangel auf den Handys zunächst nicht verwendet. Jedoch
wird der benötigte Adressindex mit den Bytepositionen der Tupel beim Auslesen der
Datendateien erzeugt. Indexstrukturen über andere Tabellenspalten werden zur Zeit
noch nicht erzeugt, um Speicherplatz zu sparen.
4.4
Definition und Ausführung von Anfragen
Die Anfragen an die Datenbank sind SQL-ähnlich gehalten. Sie werden nicht als String
übergeben und anschließend geparst, sondern mittels Methodenaufrufen für die einzelnen Anfragekomponenten konstruiert (siehe Klasse Query.java), da die mobilen Geräte in ihrer Leistungsfähigkeit eingeschränkt sind. Dadurch wird eine schnellere Anfrageverarbeitung ermöglicht. Die Methode setSelect (boolean distinct, String[]
resultcolumns) setzt die zu projizierenden Spalten für das Anfrageergebnis und legt
fest, ob Duplikateliminierung genutzt wird oder nicht. Mit Hilfe der Methode setFrom
(String querytable) wird die Tabelle für die Anfrage bestimmt. Für die Definition
der Selektionsbedingungen existieren die Methoden setWhereLogicOperation (int
logicoperation) und setWhereIgnoreCaseStringCompare (boolean ignorecase).
Die erste Methode setzt entweder die logische Operation AND = 1 oder OR = 2 (als Integerwert codiert) mit der alle Selektionsbedingungen verknüpft werden. Die zweite
Methode definiert, ob bei Stringvergleichen die Groß- und Kleinschreibung ignoriert
werden soll. Die Selektionsbedingungen der Anfrage werden über Methoden für jeden
einzelnen Datentyp (Byte, Short, Integer, Long, Boolean und String) festgelegt. Dazu kann man in jeder Methode mehrere Vergleichsspalten, Vergleichsoperationen und
Vergleichswerte für den selben Datentyp angeben. Für Integerwerte lautet die Methode z.B. setWhereInt (String[] comparecolumns, int[] compareoperations,
int[] comparevalues). Man muss dabei beachten, dass die Dimension aller übergebenen Felder gleich ist. Die Anzahl der Selektionsbedingungen ist beliebig groß und wird
nur vom Wertebereich des Datentyps Integer begrenzt. Ferner sind nur Konstantenselektionen definierbar. Durch Kombination zweier Selektionsbedingungen erhält man eine Bereichselektion. Es gibt keine Verbundbedingungen, weil kein Verbund unterstützt
wird. Die Methode setOrderBy (boolean ascending, String[] sortcolumns) bestimmt die Tabellenspalten für die Sortierung und die Sortierreihenfolge.
Byteposition
00
20
24
40
44
48
52
-
19
23
39
43
47
51
63
64 - 67
68 - 71
72 - x0
x1 - x2
x3 - x4
x5 - x6
x7 - x8
x9 - xa
xb - xx
y0
y1 - y2
y3 - y4
y5 - y6
y7 - y8
y9 - ya
yb - yc
yd
ye - yy
Feldname
Tabellenheader
Signatur der Datenbank
Länge des Tabellennamens
Tabellenname
Tabellenversion
Recordanzahl in Datei
Dateigröße
frei
Tabellenschema
Länge des Tabellenschemas
Spaltenanzahl der Tabelle
1. Spalte - Name
1. Spalte - Datentyp
1. Spalte - Datentypgröße
2. Spalte - Name
2. Spalte - Datentyp
2. Spalte - Datentypgröße
...
Tabellendaten
1. Tupel Recordtyp
1. Tupel - Datenlänge =
feste Länge + variable Länge
1. Tupel - Wert der 1. Spalte mit
fester Länge
...
1. Tupel - Länge der 1. Spalte mit
variabler Länge
1. Tupel - Wert der 1. Spalte mit
variabler Länge
...
2. Tupel Recordtyp
...
49
Beispiel
SDB3.0JAVA2ME
8
TestData
1
500
25190
62
4
Name
1 = String
-1 = variabel
Groesse
2 = Int
4 Byte = fest
...
1 = Daten
47
50000
...
13
Heinz-Dieter0
...
1 = Daten
...
Tabelle 4.1: Dateiformat der Datendateien
50
Nachdem man eine Datenbank erzeugt hat, kann man zur Auswertung einer Anfrage
die Methode executeQuery (Query query) der Datenbank aufrufen. Diese Funktion
berechnet das Anfrageergebnis und liefert das entsprechende ResultSet zurück (siehe
Klasse Database.java). Dazu wird auf die für die Anfrage benötigte Tabelle zugegriffen. Danach werden die in der Anfrage für die Projektion und Sortierung angegebenen Spaltennamen auf Gültigkeit geprüft. Bei den Projektionsspalten wird getestet,
ob sie in der Tabelle vorhanden sind. Wenn Sortierattribute existieren, erfolgt eine
Kontrolle, ob sie auch in den Ergebnisspalten auftreten. Bei einem Fehler wird eine
Exception ausgelöst. Nach erfolgreicher Überprüfung wird ein ResultSet generiert und
werden die Selektionsbedingungen darauf angewendet. Zu diesem Zweck werden die
Bytepositionen der einzelnen Tupel zum ResultSet hinzugefügt und für jedes Tupel
die Selektionsbedingungen ausgewertet. Die Vergleichsergebnisse der einzelnen Selektionsbedingungen werden entsprechend der festgelegten logischen Operation (AND oder
OR) miteinander verknüpft. Falls das Ergebnis negativ ausfällt, wird die entsprechende
Byteposition des Tupels wieder aus dem ResultSet entfernt. Nachdem die relevanten
Tupel selektiert wurden, wird gegebenenfalls eine in der Anfrage definierte Sortierung
vorgenommen. Standardmäßig wird HeapSort1 als Sortieralgorithmus verwendet. Im
nächsten Schritt findet eine Eliminierung der Duplikate statt, falls das in der Anfrage
spezifiziert wurde. Wenn in der Ergebnismenge das Flag für alle Tupel gesetzt wurde,
werden vor der Sortierung bzw. der Duplikateliminierung noch die Bytepositionen aller
Tupel in das ResultSet kopiert.
4.5
Tabellendaten
Beim Benutzen einer Tabelle werden nacheinander der Tabellenheader, das Tabellenschema und die Tabellendaten aus der JAR-Datei ausgelesen. Die Metainformationen
werden in Variablen und die Tabellendaten in einem Datenpuffer gespeichert (siehe
Table.java). Die Details zu den einzelnen Tabellenfeldern sind dem Abschnitt zum
Dateiformat zu entnehmen. Beim Auslesen der Tabellendaten wird ein Adressindex
mit den Bytepositionen der einzelnen Tupel in der Tabellendatei erzeugt. Über einen
Parameter im Konstruktor der Tabelle steuert man, ob dieser Index dicht- oder dünnbesetzt sein soll. Wird als Indexparameter 1 übergeben, so wird jedes Tupel in den
Index aufgenommen. Beim Indexparameter 2 wird jedes 2. Tupel hinzugefügt, beim
Indexparameter 3 jedes 3. Tupel, usw. Durch einen dünnbesetzten Adressindex reduziert sich der Speicherverbrauch, aber man erhöht damit die Anfragezeit auf Grund
einer aufwändigeren Tupelsuche.
Des Weiteren existieren noch verschiedene Methoden für die Arbeit mit der Tabelle.
Es ist möglich die aktuelle Datenlänge und die Kapazität des Datenpuffers abzufragen, Daten zum Puffer hinzuzufügen sowie die Anzahl der Tabellenzeilen und -spalten
zu bestimmen. Der Datenpuffer ist ein ByteArray (byte[] databuffer). Den Namen, den Datentyp und die Datentypgröße zu einem Spaltenindex kann man ebenso
ermitteln wie zu einem Spaltennamen den Spaltenindex. Zum Öffnen und Einlesen
einer Ressourcendatei aus dem JAR wird die Methode InputStream filestream =
1
Alternativ kann man auch SelectSort nutzen, indem man eine kleine Änderung am Quellcode
vornimmt und das J2ME-Projekt neu compiliert.
51
this.getClass().getResourceAsStream("/" + filename) mit String filename
eingesetzt, da es kein Dateisystem mit entsprechenden Zugriffsmethoden gibt. Zum
Datenlesen wurden verschiedene Read-Prozeduren programmiert, die die Daten komplett, ab einer bestimmten Byteposition oder zwischen zwei Bytepositionen einlesen.
Eine Besonderheit auf einigen mobilen Geräten ist, dass der Reset des InputStreams
nicht funktioniert. Man muss zum Datenlesen von einer anderen Byteposition den InputStream schließen und wieder neu öffnen. Darüber hinaus gibt es noch einige andere
Methoden, die nicht auf allen Geräten korrekt implementiert sind.
Zur internen Verwendung beim Auslesen der zwischengepufferten Tabellendaten existieren für alle Datentypen (Byte, Short, Integer, Long, Boolean und String) Funktionen, mit denen man den Datenwert für den jeweiligen Datentyp an einer bestimmten
Position bekommen kann. Für das Auslesen von Strings gibt es die zwei Funktionen
getStringValueAsString (int position) und getStringValueAsByteArray (int
position), da bei Vergleichsoperationen der Vergleich auf einem ByteArray schneller
als auf einem String-Objekt ist.
4.6
Anfrageergebnis
Als Ergebnis einer Anfrage an eine Tabelle erhält man ein JDBC-ähnliches ResultSet,
da ein komplexes Tabellenobjekt zuviel Speicherplatz benötigt (siehe ResultSet.java).
Dadurch kann man das Anfrageergebnis nicht in einer anderen Anfrage einsetzen. Im
Konstruktor der Ergebnismenge wird geprüft, ob alle Tupel der Tabelle selektiert wurden. Wenn das der Fall ist, wird nur ein Flag gesetzt und werden nicht noch einmal alle Bytepositionen der einzelnen Tupel in das ResultSet kopiert, um Speicherplatz zu sparen. Andernfalls wird die Ergebnismenge initialisiert. Danach können die
Bytepositionen von Tupeln zum ResultSet hinzugefügt oder wieder entfernt werden.
Bei diesem Prozess wird die Ergebnismenge wenn erforderlich dynamisch vergrößert.
Die Implementierung des ResultSets orientiert sich an JDBC. Infolgedessen existieren
die Methoden beforeFirst(), afterLast(), next(), previous(), absolute (int
row) und relative (int row) zur Navigation durch das ResultSet. Um die Daten
einer Ergebnisspalte an der aktuellen Position im ResultSet zu erhalten, existieren
für alle Datentypen (Byte, Short, Integer, Long, Boolean und String) entsprechende
Funktionen, die intern die im vorhergehenden Abschnitt beschriebenen Tabellenfunktionen zum Datenlesen benutzen. Analog zur Tabelle gibt es für das Auslesen von
Strings wieder zwei Funktionen getStringColumnValueAsString (int column) und
getStringColumnValueAsByteArray (int column). Daneben sind Funktionen verfügbar, mit denen man die aktuelle Größe und die Kapazität der Ergebnismenge sowie
die Ergebnisspalten ermitteln kann.
4.7
Entwicklungsumgebung
Für die Programmierung der smartDB mit J2ME wurde folgende Software verwendet:
• Java 2 Standard Edition 1.4.2_04 SDK,
siehe http://java.sun.com/j2se/index.jsp
52
• Java 2 Micro Edition Wireless Toolkits 2.1 und 1.0.4_01,
siehe http://java.sun.com/j2me/index.jsp
• Eclipse 3.0 RC3, siehe http://www.eclipse.org
• EclipseME-Plugin 0.4.5 für Eclipse 3.0,
siehe http://eclipseme.sourceforge.net
• ProGuard 2.1 File Shrinker & Code Obfuscator,
siehe http://proguard.sourceforge.net
Für Kompatibilitätstests mit anderen mobilen Geräten wurden folgende Tools genutzt:
• Nokia Developers Suite 2.1 für J2ME und verschiedene Nokia SDKs für Handys,
siehe http://www.forum.nokia.com/main.html
• Siemens Mobility Toolkit 2.00.3b und verschiedene SMTK Emulator Packs,
siehe http://www.siemens-mobile.com/developer
• Sony Ericsson J2ME SDK 2.1.1 Beta,
siehe http://www.sonyericsson.com/developer
• Motorola SDK 4.1 für J2ME,
siehe http://www.motocoders.com/motorola/pcsHome.jsp
• IBM WebSphere Micro Environment für Palm OS und verschiedene Palm OS
Simulatoren, siehe http://www.palmone.com/us/developers
Kapitel 5
Performancebetrachtung und
Kompatibilitätstests
Die ursprüngliche smartDB mit Personal Java wurde schon für die Verwaltung von
mehr als 5000 Datensätzen auf einem Smartphone eingesetzt. Diese Verwendung war
möglich, da die mobilen Geräte mit Personal Java wesentlich mehr Speicher als Geräte
mit J2ME zur Verfügung haben. Um die Leistungsfähigkeit der Handydatenbank einzuschätzen, sind Testversuche auf der J2ME-Plattform notwendig. Insbesondere sind
Tests auf Anfragezeiten und Speicherverbrauch interessant, um gegebenenfalls weitere
Tuningmöglichkeiten zu finden. Dieser Test wird durch den verfügbaren Speicherplatz
auf dem mobilen Gerät, vornehmlich dem Heapspeicher, und der Datensatzgröße limitiert. Folglich muss man Testdaten erzeugen, die die vorhandenen Speicherkapazitäten
in der JAR-Datei bei der Java 2 Micro Edition berücksichtigen. Im Abschnitt Probleme und Lösungen bei großen Datenmengen wurden bereits die Heapspeichergröße
von in der Regel 150 kB und die maximale Speichergrenze von circa 135 kB unkomprimierte Nutzdaten beschrieben. Das bedeutet, dass man bei einer durchschnittlichen
Datensatzgröße von 55 Byte ungefähr 2500 Datensätze verwalten kann.
5.1
Testumgebung
Zum Testen der Funktionalitäten der smartDB mit Java 2 ME wurde eine Nutzeroberfläche programmiert (siehe Klasse SDBTestMidlet.java). Gegenüber der Entwicklung
eines User Interfaces mit der Java 2 SE gibt es einige Unterschiede. Zum einen sind
die Gestaltungsmöglichkeiten wesentlich eingeschränkter als wie beim AWT oder mit
SWING und zum anderen ist die Strategie beim Formulardesign anders. Man kann beispielsweise nur ein Befehlsfeld zum Bildschirm hinzufügen, aber keine Positionsangaben
definieren. Diese Beschränkung ist bedingt durch den Layout-Manager, auf den man
nur einen minimalen Einfluss hat. Der Layout-Manager entscheidet in Abhängigkeit
von den Visualisierungsmöglichkeiten des konkreten Gerätes, wie z.B. das Befehlsfeld
am besten positioniert wird. Deswegen vereinfacht sich die Entwicklung einer grafischen Nutzeroberfläche, da man sich nicht mehr um die konkrete Visualisierung bei
einer unüberschaubaren Vielzahl von mobilen Geräten kümmern muss. Außerdem sollte die Gestaltung der Oberfläche nutzerfreundlich sein und die Programmfunktionen
mit wenig Interaktionen realisieren.
53
KAPITEL 5. PERFORMANCE UND KOMPATIBILITÄT
54
Nach dem Start der Anwendung sieht der Nutzer ein Menü, in dem er die einzelnen
Teile einer vereinfachten SQL-Anfrage (Select, From, Where, Order By) zum Definieren auswählen kann bzw. sich über den Menüpunkt Show Query die komplette Anfrage
anzeigen lassen kann. Die Standardanfrage ist immer SELECT * FROM TABLE. Über den
Button New Query kann die Anfrage wieder neu initialisiert werden bzw. mittels der
Schaltfläche Exit das Testprogramm verlassen werden.
Im Formular SELECT kann der Anwender die zu projizierenden Spalten für das Anfrageergebnis selektieren und festlegen, ob Duplikateliminierung vorgenommen werden
soll oder nicht. Dann bestimmt er im Formular FROM die Tabelle für die Anfrage. Es
ist nur eine Tabelle verfügbar, da kein JOIN implementiert ist. Die Selektionsbedingungen werden im Dialog WHERE definiert. In diesem Fenster besteht die Möglichkeit
die einzelnen Where-Klauseln entweder alle mit AND oder alle mit OR zu verknüpfen. Zusätzlich kann man einstellen, ob bei Stringvergleichen die Groß- und Kleinschreibung
beachtet werden soll. Anschließend können die Vergleichsspalten, die Vergleichsoperationen und die Vergleichswerte getrennt nach den Datentypen Integer und String
gesetzt werden. Zu Testzwecken wurden nur diese beiden Datentypen ausgewählt. In
anderen Einsatzszenarien sind natürlich auch die anderen Typen in einer angepassten
Nutzeroberfläche verwendbar. Eine auf- bzw. absteigende Sortierreihenfolge und die
Attributliste für die Sortierung sind im Formular ORDER BY definierbar.
Im Dialog Complete Query wird die komplette Anfrage angezeigt. Falls sie korrekt ist,
kann man sie durch den Button Execute ausführen lassen bzw. wenn nicht mittels der
Schaltfläche Back zurückgehen und die Anfrage ändern. Nach der Ausführung der Anfrage sieht man im Fenster Query Result das Anfrageergebnis. Mit den Befehlsfeldern
Scroll Down und Scroll Up wird seitenweise durch die Ergebnismenge gescrollt, falls sie
mehr als 5 Einträge enthält. Diese Navigation durch das ResultSet ist notwendig, weil
die TextBox für die Ergebnisanzeige eine maximale Größe für die Anzahl der Zeichen
hat. Die Größe ist abhängig von den Geräten und liegt bei 512 Zeichen oder mehr.
Über die Buttons Exit und New Query kann der Benutzer dann das Testprogramm
verlassen bzw. eine neue Anfrage initialisieren.
Die Testumgebung demonstriert die Funktionen des DBMS und wird nur zu Testzwecken eingesetzt. Das implementierte Test User Interface verbraucht circa 5 kB im
JAR. Bei einer späteren Verwendung der smartDB mit J2ME muss das Datenbanksystem in die Anwendung integriert werden, so dass die Datenbankanfragen im Programm vor dem Nutzer verborgen bleiben. Dieser erwartet z.B. ein Suchfeld in dem
er den Suchbegriff komplett oder teilweise eingibt und nach Auswahl eines Befehlsfeldes wird ihm eine Liste mit den Ergebnissen angezeigt. In Anbetracht der vielfältigen
Geräte sind eventuell die Restriktionen der speziellen Geräte zu berücksichtigen.
5.2
Tests auf Anfragezeiten und Speicherverbrauch
Zur Beurteilung der Leistungsfähigkeit der smartDB mit J2ME wurden unterschiedlich
große Datenmengen generiert und einige Anfragen zum Testen definiert. Die Testdaten
wurden aus den Ausstellerinformationen der Computermesse Systems 2003 erzeugt,
da die existierende smartDB vorwiegend als Messeinformationssystem eingesetzt wird.
Demzufolge kann man die Leistungsfähigkeit der Handydatenbank in einem realen
55
Einsatzszenario betrachten. Entsprechend dem Dateiformat der smartDB wurde unter
Verwendung von Klassen der ursprünglichen smartDB mit Personal Java eine Tabelle
mit folgenden vier Spalten erzeugt (siehe SDBConverterJ2ME.java):
• CompanyID1 – Integerzahl zur Identifizierung der Ausstellereinträge (z.B. 1816240)
• CompanyName – String mit dem Ausstellernamen (z.B. IBM Deutschland GmbH)
• LocationPath – String mit dem Ausstellerstandort auf dem Messegelände in Kurzform (z.B. /Messe/A1/516)
• RowNumber1 – Integerzahl nur für Testzwecke (z.B. 238)
Die erzeugten Tabellen mit den Testdaten haben 500 - 3000 Datensätze, die 30 - 175 kB
Speicherplatz für die Daten benötigen. Die daraus resultierenden JAR-Dateien haben
eine Größe von 28 - 83 kB. Ein Datentupel hat eine durchschnittliche Größe von 60
Byte. Für größere Datenmengen wurden einige Datensätze dupliziert, weil die verfügbaren Messedaten zur Systems 2003 nur 1400 Tupel umfassen. Der Speicherplatzbedarf
des Datenbanksystems wird im Diagramm 5.1 dargestellt.
Abbildung 5.1: Speicherplatzverbrauch der Daten und der Java-Archive
1
Die Schlüsseleigenschaft der CompanyID ging verloren, weil für die Tests einige Datensätze dupliziert wurden. Dieser Verlust wurde durch die zusätzliche Spalte RowNumber kompensiert. Dadurch
sind auch Testversuche mit Duplikateliminierung möglich und es gibt durch jeweils zwei Integer- und
Stringspalten mehr Kombinationsmöglichkeiten für Testanfragen.
56
Zur Bestimmung der Anfragezeiten wurden in mehreren Anfragen die Datenbankoperationen für unterschiedlich große Datenmengen getestet. Die Testversuche wurden auf
einem AMD Duron 1200 MHz mit 320 MB RAM durchgeführt. Dafür wurden fünf Handyemulatoren genutzt: Sun Wireless Toolkit 2.1, Sony Ericsson T616, Siemens CX65,
Nokia 7210 und Motorola E380. Folgende sechs Anfragen wurden definiert:
1. SELECT * FROM Table – Standardanfrage zur Auswahl der kompletten Tabelle
2. SELECT CompanyID FROM Table ORDER BY CompanyID ASC –
Projektion auf eine Integerspalte und Sortierung der Integerwerte
3. SELECT CompanyName FROM Table ORDER BY CompanyName DESC –
Projektion auf eine Stringspalte und Sortierung der Stringwerte
4. SELECT CompanyID, RowNumber FROM Table WHERE RowNumber < ’1000’ –
Projektion auf zwei Integerspalten und Selektion auf einer Integerspalte
5. SELECT CompanyName, LocationPath FROM Table
WHERE LocationPath STARTSWITH ’/Messe/A’ –
Projektion auf zwei Stringspalten und Selektion auf einer Stringspalte
6. SELECT DISTINCT CompanyID FROM Table
WHERE CompanyID > ’1000000’ AND CompanyName CONTAINS ’GmbH’ –
Projektion auf eine Integerspalte mit Duplikateliminierung und Verknüpfung
zweier Selektionen auf einer Integer- sowie einer Stringspalte mit UND
Die Testergebnisse kann man den Diagrammen 5.2, 5.3, 5.4, 5.5, 5.6 und 5.7 entnehmen. Man erkennt, dass alle Anfragen auf dem Standardemulator von Sun und dem
darauf basierenden Emulator von Sony Ericsson wesentlich länger dauern als auf den
anderen Emulatoren von Siemens, Nokia und Motorola. Eine mögliche Ursache dafür
ist, dass der Sun-Emulator universell für alle J2ME-Anwendungen einsetzbar ist und
somit auch ältere, langsamere Geräte emulieren soll.
Die Anfrage 1 wird auf allen Emulatoren innerhalb weniger Sekunden ausgeführt und
bietet für alle Datengrößen eine akzeptable Performance. Die Projektionsoperation erfordert nur einen unwesentlichen Anteil an der Anfragezeit. Die Sortierung der gesamten
Tabelle in den Anfragen 2 und 3 dauert bei Sun und Sony Ericsson einige Sekunden
länger als bei Siemens, Nokia und Motorola, aber hält sich noch in Grenzen. Es ist
zu beobachten, dass die Sortierung von Integerzahlen wesentlich schneller ist als die
Sortierung von Stringobjekten. Derselbe Effekt tritt auch bei der Selektionsoperation
in den Anfragen 4 und 5 auf. Allerdings ist die Selektion der relevanten Tupel nur
minimal langsamer als die Selektion der gesamten Tabelle.
Die aufwändigste Operation bei allen Emulatoren ist die Duplikateliminierung in Anfrage 6, da nur ein simpler Algorithmus mit zahlreichen Vergleichsoperationen verwendet
wird. Ebenso kostet die Reorganisation des ResultSets einige Zeit. Folglich sollte man
die Beseitigung von Duplikaten nur auf kleinen Datenmengen durchführen, um nicht
die Performance des mobilen Datenbanksystems zu reduzieren. Nur beim SiemensEmulator ist das unerheblich. Bei den Emulatoren von Nokia und Motorola dauert die
57
Duplikatentfernung nur wenige Sekunden. Diese Ergebnisse zeigen, dass die Handydatenbank eine gute Performance bietet, vorausgesetzt dass die Testergebnisse auf dem
Emulator mit denen auf einem realen Gerät übereinstimmen.
Bei den Diagrammen bemerkt man, dass einige Messwerte bei Nokia und Motorola
fehlen. Die Ursache dafür ist, dass die Emulatoren bis an ihre Leistungsgrenze getestet wurden. Bei einigen Emulatoren überschritten die Daten und das Programm die
J2ME-Spezifikationen, so dass der Speicher zur Ausführung der Anfrage nicht ausreichte. Außerdem konnte auf dem Motorola-Emulator nach dem Start der Anwendung nur
eine Anfrage bei 1500 oder mehr Datensätzen ausgeführt werden. Falls man danach
eine weitere Anfrage stellen wollte, trat dasselbe Speicherproblem auf. Offensichtlich
wird der Speicher nicht korrekt bereinigt. Des Weiteren war beim Nokia-Emulator die
erzeugte JAR-Datei bei 2500 oder mehr Datensätzen zu groß, so dass man das Programm nicht starten konnte. Dagegen verfügen die anderen Emulatoren über größere
Ressourcen. Die Kapazitäten und Fähigkeiten der Emulatoren sind von Hersteller zu
Hersteller verschieden.
5.3
Getestete mobile Geräte
Die Mehrzahl der Kompatibilitätstests wurde auf verschiedenen Emulatoren und Simulatoren von Nokia, Siemens, Sony Ericsson, Motorola und palmOne durchgeführt, weil
nicht alle mobilen Geräte zur Verfügung standen. Dadurch konnte ein großer Teil der
auf dem Markt existierenden Geräte auf Kompatibilität mit der smartDB mit J2ME
überprüft werden. Laut der Nokia-Webseite [Nok04] ist die Simulationsumgebung so
nah wie möglich an der Firmware der realen Geräte. Dennoch existieren kleine Unterschiede. Beispielsweise ist es nicht möglich die reale Prozessorgeschwindigkeit und die
mobile Netzwerkumgebung zu simulieren. Man kann aber gut den Speicherverbrauch
und die Nutzerinteraktionen überprüfen. Folglich ist das Testergebnis auf dem Emulator oder Simulator, bis auf Unterschiede bei den Programmlaufzeiten, ähnlich mit
dem Testergebnis auf einem realen Gerät. Für 100% sichere Kompatibilitätsaussagen
muss man das mobile Datenbanksystem aber immer auf realen Geräten testen. Bei der
Vielzahl mobiler Geräte können die Kompatibilitätstests umfangreich und schwierig
sein. Die Tabelle 5.1 gibt einen Überblick über erfolgreich getestete mobile Geräte.
Bei den Tests mit der Handydatenbank auf den verschiedenen Emulatoren und Simulatoren sind einige Besonderheiten aufgetreten.
• Beispielsweise haben einige Nokia-Handys und viele Siemens-Handys sehr wenig
Heapspeicher und können nur kleine Datenmengen verarbeiten.
• Bei den Motorola-Handys kann die eine Hälfte der Geräte nur MIDP 1.0 konforme
Anwendungen ausführen und die andere Hälfte nur MIDP 2.0 konforme Anwendungen. In Bezug auf den J2ME-Standard sind die MIDP-Versionen abwärtskompatibel, jedoch wurde das nicht von allen Herstellern korrekt implementiert.
Ferner haben die Hersteller die Spezifikationen um eigene Bibliotheken ergänzt.
1
Der Tungsten T wird offiziell nicht vom WME wegen kleinem Heapspeicher und Palm OS 5.0
unterstützt, aber er kann für die Anwendungsentwicklung verwendet werden. Tests auf einem realen
Gerät ergaben, dass die smartDB mit J2ME auf einem Tungsten T problemlos funktioniert.
Abbildung 5.2: Standardanfrage
Abbildung 5.3: Projektion und Sortierung für Integer
58
Abbildung 5.4: Projektion und Sortierung für String
Abbildung 5.5: Projektion und Selektion für Integer
59
60
Abbildung 5.6: Projektion und Selektion für String
Abbildung 5.7: Projektion mit Duplikateliminierung und Verknüpfung von Selektionen
Nokia
Nokia
Nokia
Nokia
Nokia
Nokia
Nokia
Nokia
Nokia
Nokia
Nokia
Sony
Sony
Sony
Sony
Sony
Sony
Sony
Sony
3300
3410
3510i
5100
6230
6310i
7210
7600
Series 40 SDK
Series 60 SDK
Series 90 SDK
Ericsson
Ericsson
Ericsson
Ericsson
Ericsson
Ericsson
Ericsson
Ericsson
K700
P800
P900
T610
T616
T630
Z500
Z1010
Siemens
Siemens
Siemens
Siemens
Siemens
Siemens
Palm
Palm
Palm
Palm
Palm
CX65
M50
M55
MC60
S57
SL45i
Treo 600
Tungsten T1
Tungsten T3
Zire 31
Zire 72
Sun WTK 2.1
Sun WTK 1.0.4_01
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
Motorola
61
A630
A760
A830
A835
C353t
C370/C450/C550
C650
E380
E398
T280i
T720
T720i
T725
v60i
v60t
v66i
V80
V180
V220
V300/V400/V500
V600
Tabelle 5.1: Liste erfolgreich getesteter mobiler Geräte
Das Problem der Inkompatibilität bei Motorola kann man dadurch umgehen,
dass man die smartDB mit J2ME jeweils für die entsprechende MIDP-Version
kompiliert und dann die zum vorhandenen Gerät passende Variante nutzt.
• Gemäß der Dokumentation zum IBM WebSphere Micro Environment für Palm
OS (siehe [pal04]) sollen die erzeugten Palm-Anwendungen auf allen Palm PDAs
ab Palm OS 5.2 lauffähig sein. Trotzdem gab es bei Tests mit einigen Simulatoren Probleme bei der Ausführung der JVM. Neben den erfolgreich getesteten
Palm PDAs aus Tabelle 5.1 werden auch folgende Handhelds genannt: Tungsten
T2, Tungsten E, Tungsten C, Zire 71 und Tungsten W mit der vorhergehenden
Version des WME.
Kapitel 6
Zusammenfassung und Ausblick
In dieser Studienarbeit wurden die Anforderungen an mobile Datenbanken im Vergleich
zu klassischen, stationären Datenbanken und verteilten Datenbanken diskutiert. Des
Weiteren wurden die aktuell verfügbare Hardware für mobile Geräte und die Einsatzbereiche mobiler Anwendungen betrachtet. Zu diesem Zweck kann man die Hardware
in die drei Geräteklassen PDA, Smartphone und Handy unterteilen. Ebenso wurden
Architekturfragen mobiler Datenbanken beschrieben. Noch nicht ergründet wurden die
technischen Grundlagen wie die Zellfunknetzwerke (z.B. GSM-Technik, Lokalisierung
der mobilen Nutzer über GPS) oder Ad-hoc-Netzwerke (spontane Vernetzung mobiler
Einheiten). In diesem Zusammenhang ist eine detaillierte Analyse der verschiedenen
Kommunikationstechnologien aus Tabelle 2.1 zu erwägen.
Zur Evaluierung des Leistungsvermögen mobiler Datenbanken wurde die Funktionalität einer Vielzahl auf dem Markt befindlicher Datenbanken für mobile und eingebettete
Systeme vorgestellt. Neben den Datenbankfunktionen sind insbesondere der Footprint
und die unterstützten Plattformen des Datenbanksystems wichtig. Die Vorstellung der
Systeme zeigte, dass es im mobilen Umfeld auf Grund der Heterogenität der existierenden Geräte keine universell einsetzbare Datenbank gibt, die für alle Anwendungsszenarien optimal geeignet ist. Dabei wurde vorzugsweise die mobile Datenbank smartDB,
vom Fraunhofer Institut für Graphische Datenverarbeitung in Rostock, detailliert hinsichtlich vorhandener Fähigkeiten und Verbesserungsmöglichkeiten analysiert.
Zur Erweiterung der bestehenden Plattformen der smartDB wurde die mobile Datenbank mit der Java 2 Micro Edition für Handys implementiert. Zu diesem Zweck wurden
die Funktionen der J2ME und die Restriktionen für die Programmierung untersucht.
Außerdem wurden ausführlich die implementierten Datenbankkomponenten wie z.B.
Anfragen, Tabellen und ResultSets beschrieben. Danach wurde die Leistungsfähigkeit
der smartDB mit J2ME bezüglich Performance und Kompatibilität mit vorhandenen
Mobiltelefonen getestet.
Nach der Implementierung und den Tests zeigte sich, dass die Funktionalität der Datenbank für Handys teilweise noch eingeschränkt ist oder für das entsprechende Anwendungsszenario angepasst werden muss. Nichtsdestotrotz liefert die Datenbank schon
eine akzeptable Performance auf der Handyplattform und kann in mobile Anwendungen
integriert werden. Da zukünftig die Leistungsfähigkeit der Handys in Zusammenhang
mit einer Weiterentwicklung der Hardware steigen wird, kann man später noch zusätzliche Funktionen, die in den aktuellen Anwendungen noch keine große Rolle spielten,
62
KAPITEL 6. ZUSAMMENFASSUNG UND AUSBLICK
63
zum Datenbanksystem hinzufügen. Dazu zählt beispielsweise eine SQL-Import- und
Exportschnittstelle. Ebenfalls ist die Implementierung eines Verbundes noch nicht geschehen. In diesem Zusammenhang muss man gegebenenfalls eine Erweiterung des Dateiformates der smartDB in Betracht ziehen, bei dem die Schlüssel- und Fremdschlüsselbeziehungen für den JOIN ergänzt werden. Eine andere Erweiterungsmöglichkeit ist
eine Schnittstelle für das Herunterladen von aktuellen Daten aus dem Internet z.B.
über eine HTTP-Verbindung.
Darüber hinaus ist das Anwendungsgebiet mobile Endgeräte ein Zukunftsmarkt, da
schon heute viele Leute über ein Handy verfügen und der Markt weiterhin wächst.
Diese Entwicklung wird sich vermutlich mit der allgemeinen Verbreitung von Smartphones und UMTS verstärken. Damit könnten in Zukunft mobile Geräte den Nutzer
bei seinen alltäglichen Aktivitäten im Arbeitsleben und in der Freizeit unterstützen.
Daher ist die Untersuchung der Interaktionsmöglichkeiten für den Nutzer und eine optimale Visualisierung der Informationen in mobilen Anwendungen wichtig. Ein Problem
bei der Nutzung mobiler Datenbanksysteme ist die Vielfalt an mobilen Plattformen,
die die Entwicklung einer universell einsetzbaren Anwendung erschweren. Die Java 2
Micro Edition versucht das durch ein plattformunabhängiges Framework für die Anwendungsprogrammierung zu lösen. Mit der smartDB unter J2ME existiert bereits jetzt ein
leistungsfähiges, relationales und mobiles Datenbanksystem für die Handyplattform.
Abbildungsverzeichnis
2.1
Architektur eines Datenbanksystems . . . . . . . . . . . . . . . . . . .
6
4.1
Architektur der Java 2 Micro Edition . . . . . . . . . . . . . . . . . . .
39
5.1
5.2
5.3
5.4
5.5
5.6
5.7
Speicherplatzverbrauch der Daten und der Java-Archive . . . . . . . . .
Standardanfrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Projektion und Sortierung für Integer . . . . . . . . . . . . . . . . . . .
Projektion und Sortierung für String . . . . . . . . . . . . . . . . . . .
Projektion und Selektion für Integer . . . . . . . . . . . . . . . . . . . .
Projektion und Selektion für String . . . . . . . . . . . . . . . . . . . .
Projektion mit Duplikateliminierung und Verknüpfung von Selektionen
55
58
58
59
59
60
60
64
Tabellenverzeichnis
2.1
2.2
Technische Daten der drei Hardwareklassen . . . . . . . . . . . . . . . .
Technische Daten einiger aktueller PDAs, Smartphones und Handys . .
12
12
3.1
3.2
3.3
Klassifikation der Datenbanksysteme in die drei Hardwareklassen . . .
Unterstützte Plattformen der mobilen Datenbanksysteme . . . . . . . .
Maximalwerte wichtiger Datenbankparameter mobiler Datenbanken . .
18
20
21
4.1
Dateiformat der Datendateien . . . . . . . . . . . . . . . . . . . . . . .
49
5.1
Liste erfolgreich getesteter mobiler Geräte . . . . . . . . . . . . . . . .
61
65
Literaturverzeichnis
[BBPV01] Bobineau, Christophe, Bouganim, Luc, Pucheral, Philippe, and Valduriez,
Patrick. PicoDBMS: Scaling down Database Techniques for the Smartcard.
The VLDB Journal, 10(2-3):120–132, September 2001.
[Bir04a] Birdstep Technology ASA. Birdstep Database Product Matrix, May 2004.
[Bir04b] Birdstep Technology, Inc. Birdstep RDM Embedded 7.1 Datasheet, June 2004.
[Bir04c]
Birdstep Technology, Inc. Birdstep RDM Mobile 3.0 Datasheet, June 2004.
[Bor03a] Borland Software Corporation. Borland JDataStore 7 Developer’s Guide,
2003.
[Bor03b] Borland Software Corporation. Borland JDataStore 7 Feature Matrix, 2003.
[Dat04a] DataMirror Mobile Solutions, Inc. PointBase Embedded Datasheet, 2004.
[Dat04b] DataMirror Mobile Solutions, Inc. PointBase Micro Datasheet, 2004.
[Dat04c] DataMirror Mobile Solutions, Inc. PointBase UniSync Datasheet, 2004.
[Dix03]
Dixon, Kevin. Symbian OS Version 7.0s Functional Description, Revision
2.1. Symbian Ltd, June 2003.
[dUD]
Fachbereich Informatik der Universität Dortmund. J2ME Device Database,
siehe http://kissen.cs.uni-dortmund.de:8080/devicedb/index.html.
[Fas04a] FastObjects, Inc. FastObjects – Overview FastObjects e7,
siehe http://www.fastobjects.com/us/FastObjects_PandS_e7.asp, 2004.
[Fas04b] FastObjects, Inc. FastObjects – Overview FastObjects j2,
siehe http://www.fastobjects.com/us/FastObjects_PandS_j2.asp, 2004.
[FB03]
Fox, Dan and Box, John. Building Solutions with the Microsoft .NET Compact Framework: Architecture and Best Practices for Mobile Development,
siehe http://www.windowsitlibrary.com/Content/1016/05/toc.html, chapter
Caching Data with SQL Server CE. Addison Wesley, October 2003.
[fGDR]
Fraunhofer Institut für Graphische Datenverarbeitung Rostock. Mobiles
Informationssystem xGuide, siehe http://www.igd-r.fraunhofer.de/IGD/
Abteilungen/AR3/Produkte_AR3/xGuide.
66
LITERATURVERZEICHNIS
67
[Höp01]
Höpfner, Hagen. Replikationstechniken für mobile Datenbanken. Diplomarbeit, Otto-von-Guericke Universität Magdeburg, Fakultät für Informatik,
März 2001.
[HS99]
Heuer, Andreas and Saake, Gunter. Datenbanken: Implementierungstechniken. MITP-Verlag, 1999.
[HS00]
Heuer, Andreas and Saake, Gunter. Datenbanken: Konzepte und Sprachen.
MITP-Verlag, 2000.
[iAn04a] iAnywhere Solutions, Inc. SQL Anywhere Studio Datenblatt, 2004.
[iAn04b] iAnywhere Solutions, Inc. UltraLite Datenbankhandbuch, Januar 2004.
[IBM03] IBM Corporation. IBM DB2 Everyplace 8.1 Datasheet, October 2003.
[Kön03]
König-Ries, Birgitta. Vorlesung Informationssysteme in mobilen und drahtlosen Umgebungen, siehe http://www.ipd.uka.de/∼koenig/ISMOD/. Universität Karlsruhe (TH) und TU München, 2003.
[Lub00]
Lubinski, Astrid. Small Database Answers for Small Mobile Resources, November 2000.
[McO04a] McObject LLC. eXtremeDB High Availability Edition,
siehe http://www.mcobject.com/highavailability.shtml, 2004.
[McO04b] McObject LLC. eXtremeDB Single Threaded Edition,
siehe http://www.mcobject.com/singlethreaded.shtml, 2004.
[McO04c] McObject LLC. eXtremeDB Standard Edition,
siehe http://www.mcobject.com/standardedition.shtml, 2004.
[Mic00]
Microsoft Corporation. Microsoft SQL Server 2000 Windows CE Edition,
Whitepaper, 2000.
[Mic02]
Microsoft Corporation. Microsoft SQL Server 2000 Windows CE Edition,
Datasheet, 2002.
[Mim04] Mimer Information Technology AB. Mimer SQL Engine Documentation Set,
Version 9.2, März 2004.
[Nok04]
Nokia. Nokia Documentation – Introduction to Java Tools,
siehe http://www.forum.nokia.com/main/0,6566,st_p_61,00.html, 2004.
[Pala]
PalmSource, Inc. Palm OS Cobalt Datasheet.
[Palb]
PalmSource, Inc. Palm OS Garnet Datasheet.
[Palc]
PalmSource, Inc. Palm OS Releases – Palm OS Cobalt,
siehe http://www.palmos.com/dev/tech/oses/cobalt60.html.
LITERATURVERZEICHNIS
68
[pal04]
palmOne, Inc. WebSphere Micro Environment for palmOne Devices – MIDP
2.0 Porting Guide (GM Final), March 2004.
[Poe01]
Poet Software GmbH. FastObjects Products – Features & Architecture, 2001.
[Rad04a] Radage, Kalle. Oracle Database Lite 10g – What’s the Difference with other
Oracle Database Editions? Oracle Corporation, April 2004.
[Rad04b] Radage, Kalle. Oracle Database Lite 10g Overview, Version 1.2. Oracle
Corporation, January 2004.
[Sof03]
Software AG. News – Tamino Mobile 4.0 Released, siehe
http://www.xmlstarterkit.com/corporat/news/jan2003/tamino_mobile4.htm,
January 2003.
[Suna]
Sun Microsystems, Inc. J2ME Documentation,
siehe http://java.sun.com/j2me/docs/index.html.
[Sunb]
Sun Microsystems, Inc. JSR for J2ME,
siehe http://www.jcp.org/en/jsr/tech?listByType=platform.
[Sun00a] Sun Microsystems, Inc. Connected Limited Device Configuration,
Specification Version 1.0a J2ME, May 2000.
[Sun00b] Sun Microsystems, Inc. Mobile Information Device Profile (JSR-37),
Specification Version 1.0a J2ME, December 2000.
[Sun02]
Sun Microsystems, Inc. Mobile Information Device Profile (JSR-118),
Specification Version 2.0 J2ME, November 2002.
[Sun03a] Sun Microsystems, Inc. Connected Limited Device Configuration,
Specification Version 1.1 J2ME, March 2003.
[Sun03b] Sun Microsystems, Inc. Whitepaper CDC: An Application Framework for
Personal Mobile Devices, June 2003.
[Upr04a] Upright Database Technology AB. Mimer SQL Embedded – The Tailor-made
Database, siehe http://www.mimer.com/ImageBottom.asp?secId=197, 2004.
[Upr04b] Upright Database Technology AB. Mimer SQL Engine – The Zero Maintenance Database, siehe http://www.mimer.com/imageBottom.asp?secId=200,
2004.
[Upr04c] Upright Database Technology AB. Mimer SQL Mobile – The Phone is the
Server, siehe http://www.mimer.com/ImageBottom.asp?secId=201, 2004.

as a PDF

Transcription

Similar documents

IP Office - Lipinski Telekom

1 Einführung

Server Hardware monitoring done right - Thomas

teltarif.de Onlineverlag GmbH