Datenbanken für den Einsatz auf Embedded Linux

Technische Universität Chemnitz
Fakultät für Elektrotechnik und Informationstechnik
Lehrstuhl Schaltkreis- und Systementwurf
Datenbanken für den Einsatz auf
Embedded Linux
Hauptseminar Informations- und
Kommunikationstechnik
Verfasser: Enrico Billich
Studiengang: Informations- und Kommunikationstechnik
Betreuer: DI Daniel Kriesten
Inhaltsverzeichnis
1. EINLEITUNG
4
1.1.
Motivation
4
1.2.
Ziele der Arbeit
4
1.3.
Struktur
4
2. PRÄ-DATENBANK-ÄRA
6
3. MODERNE DATENBANKTHEORIE
7
3.1.
ANSI-SPARC-Architektur
7
3.2.
Komponenten eines Datenbanksystems
7
3.3.
Aufgaben des DBMS
8
4. VERALTETE DATENBANKMODELLE
10
4.1.
Hierarchisches Datenbankmodell
10
4.2.
Netzwerkdatenbankmodell
11
5. RELATIONALES MODELL
12
5.1.
Entity-Relationship-Modell
12
5.2.
Relationales Datenbankmodell
12
5.3.
Beispiele für relationale Datenbanken
14
5.3.1.
5.3.2.
5.3.3.
5.3.4.
Apache Derby
HSQLDB
Firebird
SQLite
6. OBJEKTORIENTIERTES MODELL
14
14
15
15
17
6.1.
Semantische Datenmodellierung
17
6.2.
Objektorientiertes Datenbankmodell
18
6.3.
Beispiele für objektorientierte Datenbanken
20
6.3.1.
6.3.2.
6.3.3.
JDO (Java Data Objects) Datenbanken
EyeDB
db4o
20
21
21
6.4.
Objektrelationales Datenbankmodell
21
6.5.
Beispiele für objektrelationale Datenbanken
22
6.5.1.
6.5.2.
PostgreSQL
OpenLink Virtuoso
7. WEITERE DATENBANKMODELLE
7.1.
Deduktive Datenbanken
22
23
24
24
2
7.2.
Verteilte Datenbanksysteme
24
7.3.
Eingebettete Datenbanken
26
7.4.
Beispiele
26
7.4.1.
7.4.2.
7.4.3.
Objectivity/DB
db.* (db star)
RRDtool
8. ANFORDERUNGEN UND ABSCHLUSSVERGLEICH
26
26
27
28
8.1.
Anforderungen an Datenbank im InnoProfil Projekt
28
8.2.
Vergleichskriterien
29
8.3.
Abschlussvergleich
29
9. GLOSSAR
33
10. LITERATUR UND QUELLEN
35
3
1.
Einleitung
1.1. Motivation
Jeder kennt sie, jeder spricht über sie, doch kaum jemand sieht sie, da sie tief im Verborgenen
ihre Arbeit verrichten. Datenbanken. Ihre Stellung in jedem Unternehmen, vom Großkonzern
bis zum Lagerhaus, ist so herausragend, dass ein Großteil der Arbeitsplätze von ihrem
Funktionieren abhängt. Gehen ihre gespeicherten Daten verloren, bräche die Verwaltung des
Betriebes zusammen und wesentliche Firmeninformationen, die sich über Jahre ansammelten
und ein beachtliches Kapital darstellen, müssten mühsam wieder beschafft werden. Deshalb
ist ein Datenbanksystem auch derartig komplex, um solche Katastrophen zu verhindern und
trotzdem dem Benutzer einen effektiven Zugriff auf den riesigen Datenberg zu ermöglichen.
Dies beweisen sie schon seit den 1960er Jahren und erfreuen sich deshalb überall großer
Beliebtheit. Populäre Beispiele sind dabei heutzutage die bedeutendsten Internetseiten der
Welt wie Google, Ebay und Wikipedia.
Ich wähle dieses Thema, weil Datenbanken mit die wichtigsten Systeme der
Informationstechnik darstellen und Erfahrungen mit Datenbanken vermutlich sehr wertvoll
für zukünftigere Arbeiten sein können. Ebenso der spezielle Einsatzzweck auf Embedded
Systemen repräsentiert einen zusätzlichen Reiz, da Datenbanken für gewöhnlich ihre gesamte
Leistungsfähigkeit erst mit entsprechend großen Hardwareressourcen zeigen können, die in
einem Embedded System nicht vorhanden sind.
1.2. Ziele der Arbeit
Diese Arbeit, die im Rahmen des Hauptseminars Informations- und Kommunikationstechnik
angefertigt wurde, beschäftigt sich mit Datenbanken, die sich zur Speicherung von
Sensordaten auf dem Embedded System des InnoProfile Projektes eignen. Dazu sollen
verschiedene Datenbankmodelle und darauf basierende Datenbanken hinsichtlich ihrer
Möglichkeiten und Eigenschaften verglichen werden. Dabei stehen der Ressourcenbedarf und
die erbrachten Leistungen im Vordergrund.
1.3. Struktur
Das Dokument beginnt mit der Schilderung der Situation bevor es Datenbanken gab. Es
werden kurz die Probleme angesprochen, die sich durch das einfache Dateisystem ergaben
und Datenbanksysteme notwendig machten.
Daran knüpft die moderne Datenbanktheorie an, die in Standardisierungen wie der ANSISPARC-Architektur sinnvolle Grundsätze festlegte, wie eine Datenbank aufgebaut sein muss
und welche Aufgaben die einzelnen Teile zu übernehmen haben. Es werden zudem die
Vorteile von Datenbanken gegenüber Daten in Dateien genannt, die einzelnen Komponenten
eines Datenbanksystems erklärt und welche Anforderungen man heute an solche Datenbanken
stellt.
Bevor es dann zu den modernen Datenbankmodellen kommt, werden aber zunächst noch die
veralteten Datenbankkonzepte der ersten Generation erläutert, auch als satzorientierte
4
bezeichnet, die aber mittlerweile fast überall von den neueren verdrängt wurden und nur noch
ein Nischendasein führen.
Der fünfte Teil erklärt zunächst das Entity-Relationship-Modell, um einen fließenden Einstieg
in die relationalen Datenbanksysteme zu ermöglichen. Dieses Datenbanksystem wird darauf
detailliert erläutert. Es wird gezeigt, wie mit ihm Relationen dargestellt werden und was seine
wichtigsten Eigenschaften sind. Aufbauend auf diesen Erkenntnissen, werden ein paar
Vertreter dieser Datenbankgattung vorgestellt. Zunächst wird aber nur jede Datenbank mit
ihren speziellen Eigenschaften vorgestellt, da erst später zum Ende des Dokuments, ein
abschließender Vergleich inklusive Wertung und Empfehlung erfolgen wird.
Der sechste Teil widmet sich der neuesten Entwicklung der Datenbanksysteme, dem
Objektmodell samt objektorientierten Datenbanken und mit UML auch einer Methode dieses
zu beschreiben. Auch die Kombination aus relationalen und objektorientierten Datenbanken,
die sogenannten objektrelationalen Datenbanken werden kurz erwähnt. Wie schon bei den
relationalen Datenbanken zuvor, werden auch diese erläutert und einige Beispiele genannt.
Als vorletztes werden kurz noch weitere Datenbanksysteme betrachtet, die keinem der
vorgestellten Datenbankmodelle zugeordnet werden können.
Zum Schluss werden die Kriterien erläutert, die für den Einsatz auf dem Embedded System
des InnoProfile Projektes wichtig sind. Vor allem sind dies die Funktionalität und der
Ressourcenbedarf. Zudem erfolgt eine mögliche Modellierung der Daten im ER-Modell. Am
Ende folgen dann die Zusammenfassung und der Vergleich der vorgestellten Datenbanken.
Enrico Billich
Chemnitz, im Mai 2007
5
2.
Prä-Datenbank-Ära
Bevor es Datenbanken gab, wurden sämtliche Daten in Dateien gespeichert. Dabei bestand
ein gewöhnlicher Datensatz aus verschiedenen Feldern, bei Personendaten z.B. aus Name,
Adresse und Telefonnummer. Siehe Abbildung 2-1. Diese Datensätze wurden dann
sequentiell hintereinander in eine Datei geschrieben. So war es relativ kompliziert,
Beziehungen zwischen den Daten herzustellen oder einfache Anfragen zu tätigen, wie z.B. die
Suche nach allen Personen, die in der gleichen Stadt wohnen. Hinzu kam, dass die Art der
Speicherung stets proprietär war und man beim programmieren von Software genau wissen
musste, wie die Trennzeichen zwischen den Feldern und Datensätzen aussahen, bzw. welche
Bedeutung die einzelnen Felder hatten. Wenn man auch nur minimale Änderungen an der
Struktur der Daten vornehmen wollte, musste man sowohl die ganze Datei einlesen und neu
schreiben, als auch sämtliche Software, die darauf zugreift neu programmieren. Solche
Software nannte man dann auch strukturell abhängig von den Dateien. Selbst kleinste
Aufgaben wie das Löschen oder Ändern von einzelnen Datensätzen zogen einen enormen
Bearbeitungsaufwand für den Computer nach sich. Ein weiters Problem war zudem die
Sicherheit, wenn die Daten in einer Textdatei gespeichert wurden. Da reichte mitunter das
einfache Öffnen in einem Editor aus und ein Unbefugter kam an wichtige
Firmeninformationen.
Mustafa Mustermann;
Beispielallee 7;
12345;
Hypohausen;
555-0815;
= Datensatz in Datei
Abbildung 2-1: Datenspeicherung im Dateisystem
All diese Nachteile, vor allem die lange Bearbeitungszeit, führten dazu, dass Daten dann
mehrfach in verschiedenen Dateien gespeichert wurden. Dies konnte zwar
Geschwindigkeitsvorteile bringen und wird auch heute noch bewusst deswegen angewendet,
doch führte dies auch zu unnötigen Redundanzen, welche dann in Inkonsistenzen mündeten,
wenn Änderungen (z.B. Adressänderungen) nur in einer Datei vorgenommen wurden. Diese
Probleme konnten aber auch dann entstehen, wenn mehrere Personen gleichzeitig an
derselben Datei arbeiteten und der eine die Änderungen des anderen überschrieb. Auch fand
das Backup der Daten meist manuell in größeren Perioden statt, was Mehraufwand bedeutete
und nicht stets 100% Datensicherheit brachte.
Mit diesen Problemen konfrontiert, entwickelte man anfangs der 1960er Jahre die ersten
Datenbanksysteme, die als eigenständiges Programm die Datenverwaltung übernahmen und
den Programmen feste Schnittstellen boten. So konnten viele Nachteile der bisherigen
Datenverwaltung beseitigt werden und die zugreifende Software wurde über einen größeren
Zeitraum eingesetzt, bevor Anpassungen nötig wurden.
6
3.
Moderne Datenbanktheorie
3.1. ANSI-SPARC-Architektur
Die ANSI-SPARC-Architektur zerlegt das Datenbanksystem in drei Ebenen (Abbildung 3-1).
Eine interne Ebene, die sich um die Speicherung der Daten auf dem Hardwaremedium
kümmert. Sie bietet der darüber liegenden Schicht Schnittstellen, wodurch sich diese nicht
dafür interessieren muss, wie und auf was genau die Daten gespeichert sind. Damit wird eine
physische Datenunabhängigkeit erreicht. Sollten nun Änderungen an der Speicherstruktur,
z.B. zur Optimierung, vorgenommen werden, muss man die oberen Schichten nicht anpassen.
Die mittlere Ebene ist die konzeptuelle. Diese kümmert sich darum, welche Daten gespeichert
werden und in welcher Beziehung sie zueinander stehen. Der darüber liegenden Schicht wird
dadurch eine logische Datenunabhängigkeit geboten, so dass diese nicht merkt, wenn
Elemente der Datenstruktur umbenannt werden.
Die externe Ebene schließlich bietet verschiedene Sichten für einzelne Benutzergruppen und
Anwendungen auf die gespeicherten Daten, da sich nicht jeder für sämtliche Daten interessiert
oder Zugriffsrechte auf sie hat. Außerdem kann man mit ihnen auch die Daten unterschiedlich
strukturiert präsentieren (virtuelle/berechnete Struktur der Datenbank, nicht tatsächlich
gespeicherte).
Externe
Ebene
Sicht 1
Sicht n
Logische
Datenunabhängigkeit
Konzeptuelle Ebene
Interne
Ebene
Physische
Datenunabhängigkeit
Datenmedium
Abbildung 3-1: ANSI-SPARC-Architektur
Heutige Datenbanksysteme gewährleisten zumeist nur die physische Datenunabhängigkeit, da
die logische schon rein konzeptuell schwierig zu realisieren ist. Auch nutzen Programme, die
auf die Datenbank zugreifen, nur selten die verschiedenen gebotenen Sichten, sondern greifen
direkt auf die Datenstruktur (z.B. Tabellen) zu.
3.2. Komponenten eines Datenbanksystems
Die Datenbanksysteme, die aus diesem Modell hervor gingen (vor allem die relationalen),
gliedern sich in zwei Komponenten (Abbildung 3-2). Die physische Komponente, welche den
gesammelten Datenbestand darstellt, ist die Datenbank. In ihr werden alle Daten in einer
bestimmten Struktur abhängig vom Datenbankmodell abgespeichert. Die Verwaltung dieser
Daten übernimmt das Datenbankmanagementsystem (DBMS). Dieses System ist die
7
eigentliche Komponente, mit welcher der Nutzer kommuniziert. Er stellt Anfragen oder
Befehle, die dann das DBMS in ausführbaren Code umwandelt und auf die Daten zugreift.
Dem gewöhnlichen Nutzer bleibt der direkte Zugang zu den Daten verwehrt, was auch in
seinem Sinne sein sollte, da so die Datensicherheit und Integrität gewahrt wird.
Datenbanksystem
Datenbankmanagementsystem
Datenbank
Abbildung 3-2: Teile eines Datenbanksystems
3.3. Aufgaben des DBMS
In einem Datenbanksystem ist das DBMS die zentrale Verwaltungseinheit. Es übernimmt alle
Aufgaben, die man von so einem System erwartet. Diese Aufgaben sind:
- Benutzerverwaltung, dies beinhaltet die Kontrolle der Zugriffsrechte, die die
berechtigten Benutzer haben, welche Funktionen sie ausführen dürfen und auf welche
Daten sie zugreifen können, dies kann durch verschiedene Sichten auf die Daten
ermöglicht werden
- Mehrbenutzerbetrieb, ermöglicht den Zugriff durch mehrere Benutzer gleichzeitig
und stellt sicher, dass nicht ein Nutzer die gerade gemachten Änderungen eines
anderen unwissentlich überschreibt (Isolationen der Transaktionen voneinander durch
Sperren)
- Datensicherung und Wiederherstellung, kümmert sich um die Sicherung der Daten
(Backup) gegen Verlust und ermöglicht die Wiederherstellung von Daten nach einem
Benutzerfehler (löschen wichtiger Daten), wenn eine Transaktion nicht vollständig
ausgeführt werden konnte (Atomarität, ganz oder gar nicht) oder das System während
einer Transaktion abstürzt (Dauerhaftigkeit, z.B. durch Pufferspeicher)
- Abfragesprache, damit der Nutzer auf die Daten zugreifen kann, z.B. standardisierte
Sprachen wie SQL, die einen Zugriff auf verschiedene Datenbanken unterschiedlicher
Hersteller bietet, die diesen Standard unterstützen
- Schnittstellen für Computerprogramme und Middleware (datenbankspezifische
Treiber), um z.B. über C++ auf Daten zugreifen zu können
- Datenstruktur, Speicherung der Daten je nach Datenbankmodell (Tabelle, Objekt)
und Optimierung der Struktur auf Dateiebene zur schnellen Durchsuchung (B-Baum,
Hashtabellen)
8
-
-
-
Datenintegrität, für die automatische Überprüfung von vorgegebenen Regeln
(Constraints) zur Erhöhung der Konsistenz, z.B. kann eine Matrikelnummer nicht an
mehrere Studenten vergeben werden
Redundanzminderung, indem verhindert wird, dass gleiche Daten mehrfach
gespeichert werden müssen
Physische Datenunabhängigkeit, indem dem Benutzer nur das logische Format der
Daten gezeigt wird und nicht der physische Datentyp, indem der Wert abgespeichert
ist
Datenträgerzugriff und –verwaltung, so muss sich der Nutzer nicht um die Art und
die Optimierung des Zugriffs auf den Datenträger kümmern
Metadatenverwaltung, zusätzliche Informationen über die gespeicherten Daten, z.B.
Tabellennamen
Die vier Eigenschaften Atomarität, Konsistenz (consistency), Isoliertheit und Dauerhaftigkeit
werden in der Informatik auch kurz ACID genannt und beschreiben Mindestanforderungen
für sichere Transaktionen, die von einem Datenbanksystem erwartet werden. Da viele der
oben genannten Aufgaben durch das DBMS übernommen werden, muss sich der Benutzer
nicht drum kümmern und spart so erheblich an Programmieraufwand.
9
4.
Veraltete Datenbankmodelle
4.1. Hierarchisches Datenbankmodell
Die erste Inkarnation eines Datenbankmodells ist das hierarchische. Die Besonderheit dieses
Modells ist, dass es versucht den relevanten Teil der realen Welt durch eine hierarchische
Struktur darzustellen. Deshalb werden die Datensätze (Records) in einer Baumstruktur
angeordnet, bei der ein Knoten genau einen Vorgänger (Eltern/ Parent) und mehrere
Nachfolger (Kind/ Child) besitzt. Der Baum beginnt beim Wurzeldatensatz, der als einziger
keinen Vorgänger hat, und verzweigt sich dann über Kinder und Kindeskinder bis zum
äußersten Datensatz (Blatt), der keine Kinder mehr besitzt. Abbildung 4-1 stellt dies dar.
= Datensatz
Blatt
Blatt
Wurzel
Blatt
= Eltern-Kind-Beziehung
Blatt
Blatt
Abbildung 4-1: Baumstruktur des Hierarchischen Modells
Die Verknüpfungen zwischen den Datensätzen werden Eltern-Kind-Beziehung (Parent-childRelationships) genannt und stellen eine sinnvolle Beziehung zwischen beiden Datensätzen
dar. Mit dieser Struktur sind problemlos 1:1 und 1:N Beziehungen möglich, doch scheitert das
Modell an M:N Beziehungen, also wenn ein Kindknoten mehrere Elternknoten besitzt. Dies
ist dann nur durch redundante Speicherung der Kindknoten oder virtuelle Beziehungen
möglich. Ein ähnliches Problem tut sich auch auf, wenn verschiedene Bäume miteinander
verknüpft werden sollen.
redundante
Datensätze
Professor
hält
Vorlesung 2
Vorlesung 1
Vorlesung 3
hört
Student 1 Student 2 Student 3 Student 1 Student 4 Student 2 Student 3
Abbildung 4-2: Beispiel für Hierarchisches Modell
10
Das System wurde dann schließlich in den 1980er Jahren verdrängt. Gründe dafür waren das
komplizierte Management und die schwierige Implementierung. Auch musste der
Anwendungsprogrammierer die genaue Struktur der Daten kennen und alle Elternknoten
durchlaufen, bevor er die Daten des gewünschten Kindknoten auslesen konnte. Dies bedingte
auch die Umprogrammierung von Software, wenn die Struktur der Datenbank verändert
wurde. Die Datenbank erfüllte also nicht die Bedingung nach struktureller Unabhängigkeit.
Ein weiteres Problem ergab sich außerdem, wenn Elternknoten gelöscht wurden und somit
sämtliche Kinder verloren gingen.
Trotzdem werden solche Datenbanken noch heute angewendet und eignen sich vor allem gut
für hierarchische Daten, wie sie bei XML anfallen (XML-Datenbanken).
4.2. Netzwerkdatenbankmodell
Das Netzwerkdatenbankmodell, das in den 1970er Jahren eingeführt wurde, stellt eine
Erweiterung des hierarchischen Datenbankmodells dar. In diesem sind nun auch M:N
Beziehungen erlaubt, also ein Datensatz kann mehrere Vorgänger besitzen, weshalb das
Eltern-Kind-Bezeichnungsschema aufgegeben wurde.
Professor
hält
Vorlesung 1
Student 1
Vorlesung 2
hört
Student 2
Student 3
Student 4
Vorlesung 3
Abbildung 4-3: Struktur des Netzwerkdatenbankmodells
Die Beziehungen zwischen den Datensätzen (Record) nennt man hier Set-Typen. Sie stellen
1:N Beziehungen zwischen einem Besitzer (Owner) und mehreren Mitgliedern (Members)
her. Für M:N Beziehungen nimmt man als Mittelsmann einen speziellen Record-Typ (KettRecord), der jeweils 1:N Beziehungen zu beiden beteiligten Parteien (Owner der Beziehung)
unterhält.
Trotz dieser Vorteile, behielt dieses Modell wesentliche Nachteile des hierarchischen Modells
bei. So musste man zu mindest einen Teil der Struktur (Substruktur) kennen, um den
gewünschten Datensatz auslesen zu können. Deshalb waren auch die Programme immer noch
strukturabhängig.
11
5.
Relationales Modell
5.1. Entity-Relationship-Modell
Nachdem die bisherigen Datenbankmodelle derartig viele Nachteile bei der Modellierung und
Implementierung zeigten und zudem nicht alle geforderten Eigenschaften erfüllen konnten,
entwickelte man das neue Modell der relationalen Datenbanken. Um diese übersichtlich
modellieren zu können, bedient man sich dem Entity-Relationship-Modell. In diesem werden
die Objekte der realen Welt durch Entities repräsentiert und ihre Eigenschaften durch
Attribute. Entities erkennt man an der rechteckigen Form in der Grafik und Attribute an der
ovalen. Attribute werden mit ungerichteten Kanten mit genau einer Entity verbunden. Die
Beziehungen zwischen Entities erscheinen als Rauten im Schema und werden mit allen
beteiligten Entities verbunden. Auch sie können Attribute besitzen, die man ihnen ebenfalls
mit einer Kante zuordnet. Wegen der Übersicht werden ähnliche Entities zu Entitytypen und
Beziehungen zu Beziehungstypen zusammengefasst. Um zu kennzeichnen, wie viele Entities
eines Typs an einer Beziehung teilnehmen, schreibt man deren Anzahl an die Kante.
Gewöhnlich sind das 1 oder N. Damit sind alle möglichen Beziehungsarten wie 1:1, 1:N, N:1
und M:N beschreibbar.
Name
Studenten N
SWS
Name
Matrikel Nr.
hören
N
M
Vorlesungen
M
N
Note
Vorl. Nr.
halten
prüfen
1
1
Raum
Name
Professoren
Pers. Nr.
Abbildung 5-1: Beispiel für Entity-Relationship-Modell
Um eine Entity aus der Menge aller Entities ihres Types eindeutig zu identifizieren, weist man
einem oder mehreren Attributen eine Schlüsselrolle zu. Sollten keine geeigneten Attribute
vorhanden sein, generiert man ein künstliches, z.B. eine laufende Nummer. Dieses
Schlüsselattribut wird durch Unterstreichen gekennzeichnet. Es gibt noch eine ganze Menge
mehr Verfeinerungen für das Modell, die aber für eine kurze Einführung an dieser Stelle zu
weit gehen würden.
5.2. Relationales Datenbankmodell
Um aus einem Entity-Relationship-Modell ein relationales Datenbankmodell zu machen,
muss man nur die Entities und die Beziehungen samt Attribute in eine Tabellenform bringen.
Die Namen der Entities und der Beziehungen stellen dabei die Tabellennamen dar, die
12
Attribute die Spalten und die einzelnen Datensätze die Zeilen. Um auch die Beziehungen und
die an ihnen beteiligte Entities in der Tabelle eindeutig identifizieren zu können, bedient man
sich bei den Schlüsselattributen dieser Entities. Da jetzt sowohl Entities als auch Beziehungen
in derselben Tabellenform vorliegen, nennt man beides im Datenbankmodell nur noch
Relations.
Studenten
Matrikelnummer
Name
100345
Paul Specht
44783
Robert Pfeiffer
…
…
Vorlesungen
Vorlesungsnummer
Name
SWS
443
Mathematik
8
321
Theoretische Experimentalphysik
2
…
…
…
Hören
Matrikelnummer Vorlesungsnummer
100345
443
100345
321
44783
321
…
…
In dem Beispiel kann man erkennen, dass Paul Specht beide genannten Vorlesungen besucht,
während sich der Robert Pfeiffer nur für Physik interessiert. Durch die Verknüpfung der
Matrikel- und Vorlesungsnummer ist jede Hören-Relation einzigartig. Beides sind deshalb
Schlüssel.
Gerade wegen diesem einfachen Schema, konnte man nun auch komplexe Probleme
modellieren, die vorher mit den alten Datenbankkonzepten nur schwer realisierbar waren.
Erstmals bot das DBMS dem Nutzer eine völlige Trennung von der physischen und
strukturellen Form der gespeicherten Daten, so dass sich dieser nur mit der logischen
Darstellung beschäftigen musste. Nun konnten nicht nur Spezialisten, sondern auch Laien
schnell eine Datenbank aufsetzen und die Vorteile solcher Systeme nutzen. Zudem etablierten
sich standardisierte Zugriffssprachen wie SQL (Structured Query Language), die von
Datenbanken der meisten Hersteller verstanden wurde. Diese Eigenschaften verhalfen den
relationalen Datenbanken schnell zu durchschlagendem Erfolg und sie verdrängten die alten
Datenbankmodelle in den 1980er Jahren fast gänzlich.
Es gibt aber auch einige Nachteile zu nennen. Bevor relationale Datenbanken den großen
Durchbruch erzielten, brauchte man fast 10 Jahren, um von der Theorie zu laufenden
Anwendungen zu kommen. Dies war dem hohen Ressourcenverlangen der neuen
Datenbanken geschuldet, die auf der alten Hardware deutlich langsamer liefen als ihre
hierarchischen Kollegen. Auch täuschte die leichte Handhabung darüber hinweg, dass man
sich vor der Implementierung immer noch genaue Gedanken über die Modellierung der realen
Sachverhalte machen musste. Eine schlechte Modellierung führte zu schlechten Datenbanken,
die dann schließlich die an sie gestellten Aufgaben nicht zur vollsten Zufriedenheit
bewerkstelligen konnten. Zudem werden viele Informationen über ein Objekt verstreut über
13
viele Relationen gespeichert, die dann erst durch ein Programm mit einer Reihe von Anfragen
zusammengesucht werden muss.
5.3. Beispiele für relationale Datenbanken
Da relationale Datenbanken die ältesten der modernen Datenbanksysteme sind, gibt es auch
von ihnen die meisten, am weitesten entwickelten, mit dem größten Umfang und am
häufigsten eingesetzten Vertreter. Die bekanntesten wie Oracle, Microsoft SQL oder MySQL
sind aber nicht primär für die vorgesehene Aufgabe entwickelt worden und deshalb nicht so
geeignet, wie viele andere, die an dieser Stelle kurz vorgestellt werden.
5.3.1. Apache Derby
Apache Derby ist eine Open Source Datenbank der Apache Software Foundation (ASF), die
unter anderem auch mit dem Apache HTTP Server einen der am weitesten verbreiteten
Webserver der Welt entwickelt hat. Die Entwicklung von Apache Derby startete vor über
zehn Jahren bei der kalifornischen Firma Cloudscape Inc. Nach mehreren Übernahmen
landete sie bei IBM, welches die Datenbank als Open Source Software der ASF übereignete.
Vorläufigen Höhepunkt erreichte Apache Derby als es von Sun in Java 6 als Java DB
aufgenommen wurde. So hat sie bis heute eine weite Verbreitung gefunden und wird von
allen drei Unternehmen (Sun, IBM, ASF) unterstützt.
Apache Derby ist in Java entwickelt und somit vor allem für Java Programme gedacht, in die
sie auch eingebettet werden kann. Nichts desto trotz bietet sie auch einen Client-Server Mode,
in dem mehrere Programme sie nutzen können. Es besitzt Schnittstellen für JDBC, ODBC,
Open CLI, Perl und PHP. Der Standard SQL92 wird vollständig, die jüngeren Standards
SQL99 und SQL2003 teilweise unterstützt. Sie kann unter Apache License Version 2.0
genutzt werden (für kommerzielle oder nichtkommerzielle Projekte einsetzbar). Sie bietet
volle ACID Unterstützung. Ihr Footprint beträgt 2MB. Des Weiteren benötigt sie eine Java
Laufzeitumgebung, da sie nur in einer Java Virtual Machine läuft. Ansonsten stellt sie keine
Ansprüche und ist auf jedem System mit diesen minimalen Voraussetzungen lauffähig. Auf
der Homepage findet man eine ausführliche Dokumentation und Anleitung zur Nutzung.
Weiterführende Links:
Apache Derby http://db.apache.org/derby/
Getting Started http://db.apache.org/derby/docs/dev/getstart/
Features http://www.jugs.ch/html/events/slides/051124_Derby.pdf
IBM Cloudscape http://www-304.ibm.com/jct03002c/software/data/cloudscape/
5.3.2. HSQLDB
Ist ebenfalls eine in Java geschriebene Open Source Datenbank. Sie ist weit verbreitet und
kann auch auf eine lange und bewegte Geschichte zurückblicken. Sie wird in vielen Projekten
und Unternehmen eingesetzt. Am bekanntesten ist wohl ihr Einsatz in der
Datenbankanwendung Base in OpenOffice. Man kann sie ebenfalls entweder in eine
Anwendung einbetten oder im Client-Server Mode betreiben. Im zweiten ist ein Zugriff über
den JDBC Treiber möglich. Zudem unterstützt sie große Teile der SQL-Standards (92, 99,
2003). Je nach Version beträgt der Footprint zwischen 100kB und 600kB (je nach Version).
14
Sie bietet viele verschiedene Betriebsmodi an, um z.B. vollständig im Arbeitsspeicher zu
laufen oder nur lesend auf die Daten im Speicher (CD, ROM) zuzugreifen. Es ist aber auch
ein ganz gewöhnlicher Datenbankbetrieb möglich. Größter Nachteil ist wohl die
unvollständige ACID Unterstützung, besonders in Bezug auf die Datenintegrität. Die
Datenbank wird über die BSD License vertrieben. Für den Betrieb benötigt sie als Java
Programm auch eine entsprechende Laufzeitumgebung. Man findet auch viele Quellen, in
denen die Datenbank gut dokumentiert ist.
Die HSQL Datenbank ist einst aus dem Hypersonic SQL Project entstanden. Ein Alternativer
Entwicklungszweig ist die ebenfalls in Java geschriebene Datenbank H2. Es gibt noch
wesentlich mehr relationale Java Datenbanken, von denen aber nur noch McKoi und
JDataStore (Borland) erwähnenswert sind. Weiterführende Links:
Projektseite http://hsqldb.org/
Wikipedia zu HSQLDB http://de.wikipedia.org/wiki/HSQLDB
Wikipedia zu H2 http://en.wikipedia.org/wiki/H2_%28DBMS%29
Wikipedia zu McKoi http://de.wikipedia.org/wiki/McKoi
JDataStore http://www.borland.com/de/products/jdatastore/index.html
Liste mit Java Datenbanken http://java-source.net/open-source/database-engines
5.3.3. Firebird
Die größte Bekanntheit erlangte diese Datenbank wohl, als sie vor Jahren mit Mozillas
Firefox um den Namen stritt, da dieser damals ebenfalls unter dieser Bezeichnung vertrieben
wurde. Es ist heute offensichtlich, wer die Auseinandersetzung gewann. Firebird ist der Open
Source Zweig der Closed Source Datenbank InterBase von Borland. Die Lizenz heißt IDPL,
eine modifizierte Version der Mozilla Public License 1.1. Es gibt sie sowohl in verschiedenen
Server Versionen als auch in einer Embedded Version. An Standards unterstützt sie
vollständig SQL92 und SQL99 bzw. teilweise SQL2003. Sie bietet Zugriffsmöglichkeiten
über JDBC, ODBC, Delphi, Pascal, Perl, Python, .NET, Java, C++ und PHP. Die gebotenen
Funktionen sind enorm vielfältig. Angefangen von klassischen Datenbankaufgaben wie
ACID-Konformität und Backupmanagement bis hin zu integrierten Prozeduren. Da sie in C++
geschrieben ist, braucht sie auch keine zusätzliche Laufzeitumgebung. Dafür kann sie aber
auch nicht so plattformunabhängig sein wie eine Java oder .NET Anwendung. Unter anderem
werden Windows, Linux und diverse UNIX Systeme unterstützt. Der Footprint beträgt 1MB
bis 2,6MB (je nach Quelle), es werden aber 16MB RAM empfohlen. Die Dokumentation ist
selbstverständlich umfangreich und die Entwicklung wird von einer großen Community
vorangetrieben.
Weiterführende Quellen:
Wikipedia über Firebird http://de.wikipedia.org/wiki/Firebird_%28Datenbank%29
Homepage http://www.firebirdsql.org/
5.3.4. SQLite
SQLite ist eine sehr kleine, in C geschriebene Open Source Datenbank, die speziell für den
Embedded Betrieb gedacht ist. Sie untersteht keiner Lizenz, da sie gemeinfrei verfügbar ist.
Zwar bietet sie keinen Client-Server Mode, doch können verschiedene Anwendungen auf die
Datenbasis zugreifen, da sie in einem einzigen File gespeichert wird. Jedoch werden keine
gleichzeitigen Schreibvorgänge unterstützt, da die Datei bei einem Zugriff blockiert wird.
15
Auch der sonstige Funktionsumfang ist eher bescheiden. Dafür ist ihr Footprint einer der
kleinsten aller Datenbanken mit 150kB bis 225kB (je nach verwendeten Features) und die
Geschwindigkeit hoch. Trotz eingeschränkter Funktionalität erfüllt sie die ACID
Anforderungen und unterstützt einen großen Umfang des SQL92 Standards. Sie bietet
Schnittstellen für C/C++, Python, PHP und Tcl. Es werden unter anderem Windows, Linux,
UNIX und OS X unterstützt. Durch die hohe Verbreitung findet man auch viele nützliche
Informationen auf diversen Internetseiten und der Homepage des Projektes.
Weiterführende Links:
Homepage http://www.sqlite.org/index.html
16
6.
Objektorientiertes Modell
6.1. Semantische Datenmodellierung
Seit den 1980er Jahren setzt sich in der Softwareindustrie objektorientiertes Programmieren
durch, bei dem man Klassen von Objekten bildet, denen dann Attribute und Methoden
zugeordnet werden. Diese Klassen können dann wiederum ihre Eigenschaften an neue,
speziellere Klassen weiter vererben. Diese Dinge zu modellieren überstieg die Möglichkeiten
des Entity-Relationship-Modell. Man benötigte nun also ein neues Modellierungswerkzeug,
das nicht nur die Struktur von Objekten und die Beziehungen zwischen ihnen wiedergeben
kann, sondern auch die Semantik (Bedeutung) und das Verhalten (Methoden, die die Daten
manipulieren) darstellt. Schnell entwickelten sich deshalb unterschiedlichste Produkte, von
denen sich aber keines wirklich durchsetzen konnte. Erst als sich ein paar Entwickler auf den
gemeinsamen Standard UML (Unified Modeling Language) einigten, entstand ein weit
verbreitetes und mittlerweile etabliertes Werkzeug.
Student
Vorlesungen
+Hörer
+MatrikelNr : int
+Name : string
hören
1..*
0..*
+NameAendern(NeuName : string) : void
+Notendurchschnitt() : float
1
0..*
Prüfung
+Note : float
1
+VorlesungsNr : int
+Name : string
+SWS : int
+Raum : int
+RaumVerlegen(NeuRaum : int) : void
+Prüfungsstoff
0..*
*
gehaltenVon
1
+Prüfer
geprüftVon
0..*
1
Professor
+Raum : int
+Umziehen(NeuRaum : int) : void
Angestellter
+Name : string
+TelefonNr : int
+Gehalt() : int
Abbildung 6-1: Beispiel für UML
Da UML für viele Anwendungsfälle konzipiert wurde, ist sie in ihrer Gesamtheit ziemlich
gewaltig und komplex geworden. Deshalb wird an dieser Stelle nur an dem einfachen Beispiel
von oben gezeigt, wie man sie einsetzen kann. Zunächst werden aus den Entities Klassen und
aus den Beziehungen Assoziationen. Klassen sind Rechtecke, in denen der Name der Klasse,
deren Attribute und Methoden stehen. Über das + wird die Sichtbarkeit angezeigt und hinter
dem Doppelpunkt steht der Datentyp bzw. Rückgabewert. Die Klasse Student z.B. enthält die
Attribute Name und Matrikelnummer. Zudem auch zwei Methoden, um seinen Namen zu
ändern und seinen Notendurchschnitt zu berechnen.
Eine Assoziation ist eine Linie zwischen 2 Klassen. Je nachdem wie rum man den Pfeil wählt,
hängt es ab, aus welcher Richtung man auf die assoziierten Objekte zugreifen kann (z.B. kann
man anhand der Vorlesung den Professor ermitteln, der sie hält). Den Teilnehmern kann man
zudem auch noch eine Rolle zuweisen. Im Modell ist der Student der Hörer einer Vorlesung.
Außerdem gibt man an, wie viele Instanzen einer Klasse an einer Assoziation teilnehmen. Im
17
Beispiel muss eine Vorlesung von mindestens einem Studenten besucht werden. Ein Student
hingegen kann beliebig viele (auch keine) besuchen.
Die erste größere Neuerung ist die Komposition. Damit modelliert man ein Teil eines
größeren Ganzen. Das bedeutet, dass eine Klasse exklusiv mit einer anderen verbunden ist. In
unserem Fall sind mehrere Prüfungen mit einem Studenten verbunden. Da Prüfungen ohne
Studenten nicht existieren könnten, sind diese vom Studenten existenzabhängig. Dies wird
durch die ausgefüllte Raute angezeigt. Es gibt aber auch nichtexistenzabhängige
Verbindungen, die man Aggregation nennt.
Als letztes sei noch ein Beispiel für die Vererbung erwähnt. Mit einem geschlossenen Pfeil
wird im Bild gezeigt, das Professoren von der Klasse Angestellter abstammen. Diese erben
alle deren Attribute und Methoden und ergänzen diese um eigene.
6.2. Objektorientiertes Datenbankmodell
Da es mit der Zeit immer schwieriger wurde die komplexen Strukturen vor dem Speichern
und nach dem Lesen auf das relationale Modell umzubrechen (objekt-relational-Mapping),
um sie in relationalen Datenbanken speichern zu können, entwarf man das objektorientierte
Datenbankmodell. Dies ermöglichte das direkte Speichern von Objekten inklusive ihrer
Attribute und Methoden. Da jetzt die Daten in einem Datenbankobjekt abgelegt werden, spart
man sich das zusammensuchen der Informationen und entlastet die Anwendung (Vermeidung
von Segmentierung). Trotz dieser Veränderung konnte man weiter die physische
Datenunabhängigkeit und weitere wichtige Datenbankeigenschaften gewährleisten. Ein
großer Vorteil bestand nun auch darin, Funktionen, die mit den Daten in der Datenbank
arbeiten, direkt innerhalb der Datenbank auszuführen. So spart man das Auslesen und
Zurückschreiben der Daten über langsame Kommunikationsverbindungen, da sich die
Datenbank oft auf einem entfernten Server befindet. Der Nutzer musste jetzt auch nur die
Aufrufstruktur der Methode des Objektes kennen, um dessen Attribute zu manipulieren. So
wurde eine Objektkapselung erreicht und der Benutzer sieht nur noch die Operationen.
Um auch bei den objektorientierten Datenbanken eine ähnliche Standardisierung zu erreichen
wie einst bei den relationalen, formierte sich die ODMG (Object Database Management
Group) aus vielen Anbietern von Datenbankprodukten und erstellte ein einheitliches
Objektmodell. Dieses ODMG-Modell bietet Schnittstellen für Programmiersprachen wie C++
zur vereinfachten Datenbankanbindung. Zudem wurde die Anfragesprache OQL (Object
Query Language) entwickelt, die eines Tages für objektorientierte Datenbanken einen
ähnlichen Stellenwert erreichen soll wie SQL bei den relationalen.
Anhand des obigen Beispiels soll das ODMG-Modell näher erklärt werden. Darin stellt jedes
Objekt eine Instanz eines bestimmten Objekttyps (Klasse) dar. Der Objekttyp dient so zu
sagen als Schablone für neue Objekte, die diesem Typ entsprechen. Paul Specht z.B. ist vom
Typ Student. Er besitzt einen Namen, eine Matrikelnummer, kann seinen Namen ändern und
seinen Notendurchschnitt ermitteln. Zudem besucht er noch Vorlesungen und schreibt
Prüfungen. Um ein Objekt eindeutig identifizieren zu können, besitzt jedes einen systemweit
einzigartigen Objektidentifikator. Ähnliches gilt für das Fach Mathematik. Dieses ist vom Typ
Vorlesung, besitzt eine Vorlesungsnummer, einen Namen, eine SWS-Anzahl, einen Raum
und kann verlegt werden. Da nun jedes Objekt so einen Identifikator besitzt, könnte man auf
künstliche Schlüssel verzichten, wenn sie in der realen Welt nicht von Bedeutung wären (z.B.
Matrikelnummer).
18
class Student {
attribute int MatrikelNr;
attribute string Name;
relationship set<Vorlesung> hört
inverse Vorlesung::Hörer;
relationship set<Prüfung>
wurdeGeprüft inverse
Prüfung::Prüfling;
void NameÄndern(string NeuName);
float Notendurchschnitt();
};
ID1
Student
MatrikelNr:
100345
Name:
Paul Specht
hört:
{ID3, ID4}
wurdeGeprüft:
{ID5}
class Vorlesung {
attribute int VorlesungsNr;
attribute string Name;
attribute int SWS;
attribute int Raum;
relationship set<Student> Hörer
inverse Student::hört;
relationship set<Prüfung> warInhalt
inverse Prüfung::Inhalt;
void RaumVerlegen(int NeuRaum);
};
ID3
Vorlesung
VorlesungsNr:
443
Name:
Mathematik
SWS:
8
Raum:
007
Hörer:
{ID1}
warInhalt:
{ID5}
ID2
MatrikelNr:
Name:
Student
44783
Robert Pfeiffer
ID4
VorlesungsNr:
Name:
hört:
wurdeGeprüft:
{ID4}
{}
SWS:
Raum:
Hörer:
warInhalt:
Vorlesung
321
Theoretische
Experimentalphysik
2
854
{ID1, ID2}
{}
Attribute werden in der Klassendefinition mit dem Schlüsselwort attribute und dem Datentyp
deklariert, Beziehungen über realionship. Sollte eine Klasse mehrere Beziehungen eines Typs
besitzen können, wird dies über den Mengenkonstruktor set<…> realisiert. Mit dem
Konstrukt inverse kann man zudem noch die Konsistenz sicherstellen, z.B. damit nicht bei der
Vorlesung Studenten als Hörer eingetragen sind, die gar nicht die Vorlesung besuchen. Bei
den Instanzen werden die ObjektIDs der an der Beziehung teilnehmenden Instanzen vermerkt.
Mengen kann man mit geschweiften Klammern angeben. Wenn an einer Beziehung mehr als
zwei Parteien teil nehmen, muss man dies über einen neuen Objekttyp bewirken.
class Prüfung {
attribute float Note;
relationship Student Prüfling
inverse Student::wurdeGeprüft;
relationship Vorlesung Inhalt
inverse Vorlesung::warInhalt;
relationship Professor Prüfer
inverse Professor::hatGeprüft;
};
ID5
Note:
Prüfling:
Inhalt:
Prüfer:
Prüfung
2,7
ID1
ID3
Prof1
In der Klasse Prüfung gibt es drei Beziehungen. Eine zum geprüften Studenten, eine zum
prüfenden Professor und eine zur Vorlesung, dessen Inhalt Gegenstand der Prüfung war. Die
Klasse Professor mit der Instanz Prof1 wird hier nicht noch einmal explizit dargestellt.
19
Über die Beschreibung von Methoden sei an dieser Stelle nur der Funktionskopf in der Klasse
gezeigt. Er beginnt z.B. bei der Methode NameÄndern mit dem Rückgabedatentyp (void
bedeutet kein Rückgabewert), darauf folgt der Funktionsname und in den Klammern alle
übergebenen Parameter.
Dieses Modell hatte auch einige Nachteile, wobei der erhöhte Ressourcenbedarf für die
Verwaltung der Objekte und die komplexere Implementierung nur von untergeordneter
Bedeutung waren. Vor allem die fehlende Unterstützung der standardisierten Schnittstellen
und Sprachen erforderten oft eine komplette Neuprogrammierung der Programme, wenn man
die Datenbank wechselte. Um trotzdem die Vorteile dieses Datenbankmodells unter
akzeptablen Bedingungen nutzen zu können, entwickelte man objektrelationale Datenbanken,
die Eigenschaften aus beiden Welten vereinten. Heutzutage wurden fast alle bedeutenden
relationalen Datenbanken um objektorientierte Fähigkeiten erweitert, weshalb sie nun zu den
objektrelationalen Datenbanksystemen zählen.
6.3. Beispiele für objektorientierte Datenbanken
6.3.1. JDO (Java Data Objects) Datenbanken
JDO ist eine Spezifikation von Sun, die eine einheitliche Schnittstelle beschreibt, mit dessen
Hilfe die Java Anwendungen ihre Daten in Datenbanken speichern können. Relationale
Datenbanken, die diesen Standard unterstützen, müssen vor der Speicherung und vor der
Übergabe beim Auslesen zunächst ein objektrelationales Mapping vornehmen.
Objektorientierte Datenbanken kommen ohne dieses Mapping aus und können Java Objekte
direkt speichern. Zudem stellen diese Datenbanken auch Schnittstellen nach dem ODMG 3.0
Standard zur Verfügung, damit andere Sprachen wie C++ ebenfalls ähnlich einfach ihre Daten
dort ohne Mapping ablegen können.
Wikipedia http://de.wikipedia.org/wiki/Java_Data_Objects
Eine Umsetzung dieser Spezifikation stellt die Orient ODBMS dar. Sie ist Open Source und
ist sowohl in einer Client-Server als auch einer Embedded Version verfügbar. Sie unterstützt
zusätzlich zu JDO (Java) auch ODMG 3.0 für Zugriffe von C++ Anwendungen und Teile des
SQL92 Standards für Datenmanipulationen an den gespeicherten Objekten. Ihr Footprint
beträgt mindestens 200kB (Embedded Edition) und benötigt eine Java Laufzeitumgebung. Sie
wird unter der Apache Lizenz vertrieben.
Homepage http://lnx.orientechnologies.com/cms/?Solutions:Orient_ODBMS
Eine kommerzielle Alternative ist die ObjectDB. Auch sie bietet eine Embedded (300$) und
eine Client-Server (600$) Version. Die kostenlose Version ist in ihrer Funktionalität
eingeschränkt und darf nur für nichtkommerzielle Anwendungen genutzt werden. ObjectDB
bietet zwar viele Funktionen (Recovery, Garbage Collector, Remote Management), doch kann
man ausschließlich über Java auf sie zugreifen. Ihr Footprint beträgt nur 300kB und sie
benötigt eine Java Laufzeitugebung.
Homepage http://www.objectdb.com/
In Konkurrenz steht der JDO Standard mit der EJB3 (Enterprise Java Beans 3.0)
Spezifikation, da sie ähnliche Funktionalitäten und Performance bietet.
20
6.3.2. EyeDB
EyeDB ist eine junge Open Source Datenbank, die unter der LGPL vertrieben wird. Sie
unterstützt den ODMG 3.0 Standard und die standardisierte Anfragesprache OQL für
objektorientierte Datenbanken. Schnittstellen bringt sie für C++ und Java mit. Sie arbeitet im
Client-Server und bietet darüber hinaus noch eine Menge der üblichen Datenbankfunktionen
(Vererbung, Trigger, ausdrucksstarkes Object Modell, Intgritätsbedingungen, Methoden).
Bisher werden Linux und Solaris sowohl auf 32Bit als auch 64Bit Plattformen unterstützt. Ein
Footprint oder Hardware Anforderungen sind explizit nicht erwähnt, doch kann man bei der
geringen Programmgröße von 500kB bis 2MB ausgehen.
Zwar sind die gegebenen Schnittstellen und Funktionen der Datenbank sehr interessant, doch
sollte man trotzdem nicht ihr junges Alter (Januar 2006) vergessen, aus dem wohl die geringe
Quellenanzahl und die mäßige Dokumentation resultieren. Weiterführende Links:
Homepage http://www.eyedb.org/index.php
6.3.3. db4o
Dies ist eine objektorientierte Datenbank, die sowohl mit Java als auch mit .NET (C#,
VB.NET, Managed C++) zusammenarbeitet. Sie wird unter zwei verschiedenen Lizenzen
vertrieben. Zum einen unter der GPL für nichtkommerzielle Einsatzzwecke und zum anderen
unter einer kostenpflichtigen Lizenz für kommerzielle Produkte. Sie besitzt sowohl einen
embedded als auch einen Client-Server Mode, wobei der erstere der primäre ist und der
zweite vor allem dem Datenaustausch dient. Neben den vielen Funktionen (ACID,
Verschlüsselung, Read Only Modus) ist der größte Vorteil die leichte Benutzbarkeit. Die
Syntax ist sehr einfach und der Entwickler wird durch viele Tutorials unterstützt. Der
Footprint beträgt nur 600kB. Man benötigt zum Betrieb entweder eine Java oder eine .NET
Laufzeitumgebung. Statt eine verbreitete standardisierte Anfragesprache wie SQL oder OQL
zu verwenden, benutzt sie ihre eigene namens Native Queries (NQ). Je nach Version kostet
die kommerzielle Lizenz zwischen 200$ (In-Process) und 1500$ (Client-Server).
Mengenrabatt wird ebenfalls gewährt.
Weiterführende Links:
Produktinformationen
http://www.db4o.com/deutsch/db4o%20Product%20Information%20V6.0(German).pdf
6.4. Objektrelationales Datenbankmodell
Folgende wesentliche Erweiterungen machen objektrelationale Datenbanken aus:
- Große Objekte, Datentypen für große Attributwerte wie Multimediadaten
- Mengenwertige Attribute, wenn eine Entity mehrere Attribute eines Typs besitzt,
z.B. eine Person kann mehrere Adressen oder Telefonnummern besitzen, dann wäre es
sinnvoller statt eine bestimmte Anzahl an Adressfeldern in der Tabelle zu reservieren,
ein Feld vorzusehen, dass eine beliebige Menge dieser Attribute aufnimmt
- Geschachtelte Relationen, sind hilfreich, wenn Attribute wiederum Attribute
besitzen, also ein Attribut eine Entity ist, die einer anderen Entity fest zugeordnet ist,
21
-
-
-
z.B. besteht ein Fahrrad aus 2 Rädern, diese wiederum aus Speichen, Schlauch und
Reifen aufgebaut sind
Typdeklaration, Erweiterung des gegeben Satzes an Typen um eigene, vor allem
genutzt um komplexe Objektstrukturen zu deklarieren und in der Datenbank zu
speichern
Referenzen, durch Referenzen auf Objekte spart man sich die Verwendung von
Fremdschlüsseln zur Herstellung von Beziehungen. Man kann sogar ganz auf manche
Beziehungsrelationen verzichten, wenn man Mengen von Referenzen in bestehende
Entitys als Attribute ablegt, z.B. könnte ein Student Referenzen auf alle Vorlesungen
besitzen, die er besucht.
Objektidentität, werden zum einen für Referenzen benötigt, zum anderen spart man
sich das Anlegen von künstlichen Schlüsseln
Pfadausdrücke, werden notwendig bei der Verwendung von Referenzen
Vererbung, Unterrelationen können von einer übergeordneten Oberrelationen
bestimmte Eigenschaften erben und um spezifische Eigenschaften erweitern
Operationen, man kann nun auch Daten Operationen zuordnen, die direkt in der
Datenbank ausgeführt werden
Eigenschaften der objektrelationalen Datenbanken flossen auch in die Standards SQL99 und
SQL2003 ein.
6.5. Beispiele für objektrelationale Datenbanken
6.5.1. PostgreSQL
Eine der ältesten und fortschrittlichsten objektrelationalen Datenbanken, die es gibt. Sie ist
Open Source und wird unter der BSD Lizenz vertrieben. Sie ist weitgehend konform mit allen
SQL Standards (92 bis 2003) und unterstützt den gesamten Sprachumfang. Auch die ACID
Fähigkeiten sind gegenüber vielen anderen Datenbanken außerordentlich gut umgesetzt.
Zudem werden typische objektrelationale Funktionen wie Prozeduren innerhalb der
Datenbank geboten. Sie bietet Schnittstellen für C/C++, JDBC, ODBC, Java, Tcl, PHP, Perl,
Python, Ruby und .NET. Lauffähig ist sie unter Windows, Linux und UNIX Systemen. Da
PostgreSQL seit über 25 Jahren entwickelt wird, ist der Funktionsumfang gewaltig und
konkurrenzlos zu vielen anderen freien Datenbanken. Deshalb dienen Neuerungen in jüngeren
Versionen vor allem der Benutzerfreundlichkeit und Geschwindigkeit, um gegen populäre
Kontrahenten wie MySQL wieder Boden gut zu machen. Trotz oder gerade wegen dem
großen Umfang ist PostgreSQL eher ungeeignet für den Einsatz in Embedded Systemen, da es
eine Menge Ressourcen verschlingt. Die Dokumentation spricht von mindestens 25MB
Festplattenspeicher und in den Foren ist von 8MB Footprint die Rede, wenn man auf viele
Features verzichtet. Sie wird deshalb in der Abschlussbetrachtung nicht berücksichtigt.
Weiterführende Links:
Wikipedia http://de.wikipedia.org/wiki/PostgreSQL
Homepage http://www.postgresql.org/
22
6.5.2. OpenLink Virtuoso
Ist die Open Source Version (GPL) des Virtuoso Universal Server. Die Datenbank ist wie
PostgreSQL eine objektrelationale und unterstützt weite Teile des SQL Standards (SQL92,
SQL99). Auch ist die Schnittstellenvielfalt mit ODBC, JDBC, .NET und OLE/DB recht groß.
Sie ist für viele Plattformen wie Windows, Linux und Unix verfügbar. Zwar ist der gebotene
Funktionsumfang nicht so umfangreich wie bei PostgreSQL, dafür ist aber auch der
Ressourcenhunger nicht so gewaltig. Mit 10MB Fesplattenspeicher und 2MB Footprint gibt
sie sich schon zu frieden. Allerdings auch erst nachdem man möglichst viele Features vor der
Installation entfernt hat. Dadurch muss man auf nützliche Extras wie eine einfache
Konfigurationsoberfläche verzichten. In den Grundeinstellungen benötigt die Datenbank
500MB bis 800MB. Da diese mühsamen Voreinstellungen sehr lästig sein können und nicht
immer zum gewünschten Ergebnis führen, wird auch an dieser Stelle empfohlen, besser auf
kleinere Datenbanksysteme auszuweichen.
Weiterführende Links:
Wikipedia http://en.wikipedia.org/wiki/Virtuoso_Universal_Server
Homepage http://virtuoso.openlinksw.com/wiki/main/Main/
23
7.
Weitere Datenbankmodelle
7.1. Deduktive Datenbanken
Eine deduktive Datenbank erweitert eine relationale um eine Deduktionskomponente. Das
bedeutet, dass der Datenbank Regeln vorgegeben werden, mit denen sie aus bereits
vorhandenen Daten neue Erkenntnisse gewinnen kann. Z.B. wenn man Geschwindigkeit und
Zeit misst, kann die Datenbank leicht die zurückgelegte Strecke eines Messobjektes
bestimmen. Nachteilig ist jedoch, dass es keine Standards gibt und jede Datenbank ihre eigene
Anfragesprache besitzt, was eine hohe Einarbeitungszeit bedeutet. Ebenfalls sind die
Hardwareanforderungen hoch, damit die deduktiven Datenbanken ihre besonderen Vorteile
ausspielen können.
Besonders Anfang der 1990er machten sich viele Universitäten daran zu beweisen, dass das
Konzept einer deduktiven Datenbank realisierbar ist und ähnlich leistungsfähig wäre, wie
relationale Datenbanken. Da zu der Zeit auch das objektorientierte Modell populär wurde,
stellen viele dieser Systeme eine Mischung von beiden Formen dar. Leider haben alle diese
Entwicklungen das Stadium einer akademischen Anwendung niemals überschritten und nach
wenigen Jahren Arbeit, wurde die Weiterentwicklung eingestellt oder zumindest stark
verzögert. Beispielhafte Vertreter wären ConceptBase der RWTH Aachen, bddbddb (Stanford
Universität) oder Aditi (Universität von Melbourne).
Eine intensive Betrachtung aus dem Jahr 1994 findet man in:
http://delivery.acm.org/10.1145/620000/615193/p107-ramamohanarao.pdf
7.2. Verteilte Datenbanksysteme
Trotz aller Vorteile haben zentrale Datenbanken auch diverse Nachteile. Sie können nur eine
geringe Anzahl von Anfragen gleichzeitig bearbeiten, die Kommunikationswege können
ziemlich lang werden und wenn der Server mit der Datenbank zusammenbricht, ist auch
sämtliche Datenverarbeitung lahm gelegt. Deshalb entwickelte man verteilte
Datenbanksysteme mit folgenden Vorteilen:
- Lastverteilung, wenn die Datenbank auf mehrere Server verteilt ist, können auch die
Anfragen der Benutzer auf diese gleichmäßig verteilt werden
- Standortnähe, die Teilsysteme können näher an den einzelnen Standorten der
Benutzer stehen
- auf den Teilsystemen kann man nur die lokal relevanten Daten speichern und greift
nur dann in Einzelfällen auf die gesamte Datenbank zu (weniger Ressourcen pro
System und Vermeidung der Speicherung von sensiblen Daten auf allen Systemen)
- Ausfallsicherheit, wenn ein Teilsystem ausfällt, können andere dessen Aufgabe
übernehmen oder es ist zumindest nur ein Standort von der Datenverarbeitung
ausgeschlossen und andere können wenigstens noch auf ihre lokalen Daten zugreifen
Es gibt aber auch einige neue Nachteile, die entstehen könnten:
- Inkonsistenz der Daten, wenn sie in mehreren Teilsystemen gespeichert, aber nicht
in allen bei einer Transaktion gleichzeitig verändert werden
- Deadlocks, wenn mehrere Nutzer mehrere Teilsysteme gleichzeitig exklusiv nutzen
wollen (ähnlich den „Speisenden Philosophen“)
- Höherer gesamter Ressourcenbedarf
24
-
-
Sicherheit (Zugriff auf Daten) ist schwieriger zu gewährleisten
Bei Abfragen von Daten, die auf mehrere Systeme verteilt sind, müssen diese
Anfragen auf mehrere Teilanfragen an die Teilsysteme aufgeteilt werden und die
Ergebnisse zusammengefügt
Es existieren keine gemeinsame Standards, um Systeme aus Datenbanken
verschiedener Herstellern aufzubauen (keine heterogenen Systeme, nur homogene)
Chemnitz
New York
DB
Teil 2
DB
Teil 1
Kapstadt
Benutzer
DB
Teil 3
Abbildung 7-1: Beispiel für verteilte Datenbanken
Um ein paar dieser Nachteile zu beheben ist ein erweitertes DBMS nötig. Es löst
Inkonsistenzen auf, indem von ihm Datenveränderungen an allen Teilsystemen vorgenommen
werden. Deadlocks werden aufgelöst. Ein erweitertes Sicherheitssystem wird implementiert.
Doch vor allem realisiert das DBMS eine Transparenz der Datenhaltung und stellt dem
Benutzer die verteilte Datenbank als monolithisches System dar. So kann dieser wie gewohnt
seine Anfragen stellen, ohne sich Gedanken darüber zu machen, wo genau nun die Daten
liegen. Da ein DBMS für verteilte Datenbanken eine Erweiterung für bestehende
Datenbankmodelle darstellt, sind die meisten Umsetzungen bloße Aufsätze auf andere
Datenbanken wie relationale oder objektorientierte. Das DBMS nutzt die Möglichkeiten der
darunterliegenden Datenbank und stellt zusätzlich die Funktionen für verteilte Datenbanken
zur Verfügung. Viele der großen Datenbankhersteller haben deshalb mittlerweile eigene
Realisierungen für ihre Produkte veröffentlicht, es gibt aber auch unabhängige Projekte, die
bekannte freie Datenbanken nutzen.
Bei Verwendung von verteilten Datenbanken ist noch darauf zu achten, welchen Grad an
Verteiltheit man haben möchte. Die niedrigste Form ist die Spiegelung, bei der ein Master auf
viele Slaves vollständig oder teilweise kopiert wird. Änderungen werden nur am Master
vorgenommen und die Slaves übernehmen diese. Solche Systeme sind vor allem bei der
Lastverteilung nützlich. Die nächst höhere Form sind Client-Server Systeme, bei denen an
den Clients zwar Änderungen vorgenommen werden können, diese sich dann aber über den
Server, der alle Daten beherbergt, synchronisieren müssen, damit keine Inkonsistenzen
entstehen. Höchste Verteilung erreichen Systeme, bei denen die Daten vollständig verteilt
sind und kein zentraler Server zur Synchronisation benötigt wird. Bekannteste Umsetzung ist
das Peer-2-Peer-Prinzip, das von diversen File-Sharing-Programmen (Emule, BitTorrent)
genutzt wird.
25
7.3. Eingebettete Datenbanken
Diese Laufen nicht als eigenständiges Programm, sondern können in die Anwendung
vollständig integriert werden, die dann auch exklusiven Zugriff auf sie hat. So spart man sich
die Entwicklung einer komplizierten Datenverwaltung, muss aber auf viele Vorteile einer
richtigen Datenbank (Mehrbenutzerbetrieb) verzichten.
7.4. Beispiele
7.4.1. Objectivity/DB
Objectivity/DB ist vor allem eine objektorientierte Datenbank, mit all ihren Stärken, um
komplexe Objekte einer Anwendung direkt speichern zu können. Doch zudem ist sie auch
eine verteilte Datenbank, die vollständig Client-Zentriert arbeitet und ohne große Server
auskommt, die sich als Flaschenhals im Netzwerk herausstellen könnten. Durch die
Verteilung der Datenbank (vor allem durch replizieren) sind eine hohe Skalierbarkeit und
eventuelle Performancevorteile gegeben. Die Einsatzgebiete sind vielfältig, sowohl
Datenintensive als auch Echtzeit- und Embedded Systeme kommen in Betracht. Sie bringt
Schnittstellen für die bekanntesten objektorientierten Sprachen wie C++, Java, Python,
.NET/C# und Smalltalk mit. Zudem ist auch ein Zugriff über SQL++/ODBC (mit
objektorientierten Erweiterungen) möglich, weshalb sich die Anwendungen keine Gedanken
darüber machen müssen, ob sie nun auf eine relationale oder objektorientierte Datenbank
zugreifen. Auch eine XML Schnittstelle ist vorhanden. Sie ist ACID konform, bietet viele
interessante Funktionen und bietet Support für die Eclipse IDE. Lauffähig ist die Datenbank
auf Windows, Linux und Unix Systemen. Ihr Footprint beträgt 1,5MB. Da Objectivity/DB
eine kommerzielle Datenbank ist, muss man für eine dauerhafte Verwendung eine Lizenz
kaufen. Es steht allerdings zum Testen eine vollfunktionstüchtige 60 Tage Evaluation Version
zu Verfügung. Durch den Kundensupport kann die Evaluierungszeit aber auch auf Nachfrage
verlängert werden. Preise werden nicht genannt, sondern müssen nachgefragt werden
([email protected]). Zusammen aber mit den Supportkosten, können mehrere tausend
Doller pro Jahr zusammenkommen.
Weiterführende Links:
Wikipedia http://en.wikipedia.org/wiki/Objectivity/DB
Homepage http://www.objectivity.com/pages/objectivity/default.asp
7.4.2. db.* (db star)
Die Datenbank db.* kombiniert das relationale Datenbankmodell und das
Netzwerkdatenbankmodell. Damit versucht es die Vorteile beider Modelle zu vereinen und
bietet sowohl schnellen Zugriff als auch einfache Datenmodellierung. Sie bietet verschiedene
Zugriffsmethoden, so dass man die Datenbank gleichzeitig als relationale oder
Netzwerkdatenbank nutzen kann. Zugriffe werden in einer eigenen Sprache vorgenommen,
deren Funktionen in einer Bibliothek zur Verfügung stehen. Daneben kann man aber auch
über einen ODBC Treiber in standardisiertem SQL mit der Datenbank kommunizieren. Sie
bietet volle ACID Konformität. Datensicherheit wird über ein Recovery Mechanismus
gewährleistet.
26
Zwar versteht sich die Datenbank selbst vor allem als embedded Datenbank, doch ermöglicht
sie ähnlich wie SQLite mehreren Benutzern Zugriff auf die Datenbasis, die in einer Datei
gespeichert wird. Vorteilhaft gegenüber SQLite ist allerdings, dass db.* einen sogenannten
„lock manager“ mitbringt, der einen nebenläufigen Zugriff ermöglicht und gleichzeitig die
Datenkonsistenz wahrt. Eine Schnittstelle für Programmiersprachen bringt sie nur für C/C++
mit.
Der Footprint beträgt nur 150kB und die Datenbank ist diversen Betriebsystemen wie
Windows, Linux und Unix lauffähig. Ihr Source Code ist offen gelegt (in C geschrieben). Sie
kann kostenlos in nichtkommerziellen Produkten verwendet werden. Eine kommerzielle
Benutzung ist Mitgliedern des Club ITTIA vorbehalten (Centura Open Source License, Club
ITTIA Terms, ITTIA db.* V2 License). Die Dokumentation ist sehr ausführlich in Anbetracht
des geringen Bekanntheitsgrades dieser Datenbank.
Weiterführende Links:
Homepage http://www.ittia.com/dbstar/dbstar.html
Club ITTIA http://www.ittia.com/community/membership
7.4.3. RRDtool
Die letzte hier vorgestellte Datenbank ist das RRDtool (Round Robin Database). Das
besondere an dieser Datenbank ist, dass man die ihre maximale Größe einstellen kann und bei
Überschreiten die alten Daten durch die neuen überschrieben werden. Einzige Anforderung an
die Daten ist, dass sie Zeitbezogen sind, was auf Messwerte ja zutrifft. Zudem bietet sie viele
zusätzlichen Funktionen, um die Daten visuell aufzubereiten und ansprechend darzustellen.
Vertrieben wird sie über die GPL. Sie bietet Schnittstellen für Perl, Python, Tcl und PHP. Der
Footprint kann nicht genau angegeben werden, da er von der maximalen Größe der Daten
abhängt, die man vorher einstellen muss. RRDtool wird von vielen anderen Programmen
genutzt, die dessen besondere Fähigkeiten zu schätzen wissen und so findet man auch viele
Informationen zur erfolgreichen Nutzung im Internet.
Weiterführende Links:
Homepage http://oss.oetiker.ch/rrdtool/index.en.html
27
8.
Anforderungen und Abschlussvergleich
8.1. Anforderungen an Datenbank im InnoProfil Projekt
Die hauptsächlichste Aufgabe der Datenbank im InnoProfil Projekt ist es, auf dem Embedded
System Messdaten zu sammeln und sie auf Anfrage wieder auszugeben. Deshalb werden von
der Datenbank weniger exotische Zusatzfunktion als vielmehr sichere Datenhaltung und
einfacher Zugriff gefordert. Wesentlich ist zudem auch der Ressourcenhunger der Datenbank.
Dieser Punkt sollte allerdings kein Problem für die hier vorgestellten Datenbanken sein, da
diese unter anderem wegen diesem Kriterium ausgesucht wurden. Außerdem sollte sie Zugriff
mit Hilfe einer standardisierten Anfragesprache bieten und Schnittstellen für die wichtigsten
Programmiersprachen besitzen. Berücksichtigen sollte man auch den Preis, damit das
Endprodukt, dass aus dem InnoProfil Projekt eines Tages hervorgehen könnte, nicht
unerschwinglich ist. Letztes Kriterium wäre noch die Lizenz, die die Form der Verbreitung
des Endprodukts mal mehr oder weniger beschränkt.
Eine Datenmodellierung im Entity-Relationship-Modell zeigt Abbildung 8-1.
Name
Messwert
Messobjekt
O_Nr
1
Messung
Uhrzeit
Typ
N
S_Nr
Name
Sensor
Dimension
Abbildung 8-1: mögliche Modellierung des Systems
Eine Messung wird von einem Sensor an einem Messobjekt vorgenommen. Dabei kann ein
Messobjekt mehrere Sensoren besitzen. Es ist jedoch äußerst selten, dass ein Sensor auch
mehrere Objekte messen kann. Dazu müsste er mobil sein oder die Messungen werden
manuell vorgenommen. Für ein Messobjekt genügt ein Name. Eventuell könnte man ihm auch
noch eine Ortsangabe (GPS-Koordinaten) zuordnen. Der Sensor besitzt ebenfalls einen
Namen. Zusätzlich sind noch der Typ (Temperatur, Druck, Spannung) und die Dimension
(mV, V, kV) der aufgenommenen Daten interessant. Die Messung selbst wird zu einem
bestimmten Zeitpunkt vorgenommen an dem man einen Messwert aufnimmt. Zusätzlich
bekommen Sensor und Messobjekt einen einzigartigen Schlüssel zugewiesen, um Instanzen
mit gleichen Namen auszuschließen. Für die eindeutige Identifizierung einer Messung, müsste
ein Schlüsselpaar aus Messobjekt-Schlüssel, Sensor-Schlüssel und Uhrzeit ausreichen. Die
Uhrzeit müsste aber hinreichend genau festgehalten werden, falls Messungen in kurzen
Abständen erfolgen.
28
8.2. Vergleichskriterien
Die ersten beiden Vergleichskriterien sind der Entwicklungszeitraum und die Version. Zwar
sagen diese beiden Werte nicht wirklich viel über die tatsächliche Einsatzfähigkeit aus, doch
bekommt man zu mindest eine Ahnung, wie lange sich die Entwickler schon Gedanken
deswegen machen. Als nächsten werden die beiden Modi Embedded und Client-Server
betrachtet, um die Einsatzwecke abschätzen zu können.
Der nächst größere Block beinhaltet die wichtigsten Datenbankfunktionen wie ACID
Konformität, Backupmanagement und integrierte Prozeduren. Darauf folgen die
Anforderungen an den Arbeitsspeicher und eventuelle Empfehlungen des Herstellers.
Der dritte Abschnitt zählt die Anfragesprachen und Schnittstellen zu Programmiersprachen
auf. Besonders werden an dieser stelle standardisierte Anfragesprachen und die
Programmiersprache C++ berücksichtigt.
Als letztes folgen Kriterien wie die einsetzbaren Plattformen, nötige Zusatzsoftware, Qualität
der Dokumentation, Lizenz und Preis.
8.3. Abschlussvergleich
In die Endrunde haben es die vier relationalen Datenbanken Apache Derby, HSQLDB,
Firebird und SQLite geschafft. Außerdem die beiden objektorientierten Vertreter EyeDB und
Orient ODBMS. Das RRDtool wird außer Konkurrenz präsentiert, da es zwar keine
Datenbank im eigentlichen Sinn ist, sich aber speziell für das Speichern von Messwerten
eignet. Die anderen wurden entweder wegen zu großem Ressourcenbedarf, zu hohem Preis
und zu kleinen Funktionsumfang disqualifiziert. Nichts desto trotz kann man in den
vorherigen kurzen Präsentationen der anderen Datenbanksysteme viele wichtige
Informationen finden, die an dieser Stelle als Kriterium dienten.
Die folgenden Informationen stammen alle aus den Dokumentationen der
Datenbankherstellern oder Quellen, die sich intensiv mit einer der Datenbanken
auseinandergesetzt haben.
Apache Derby
HSQLDB
Firebird
1997
10.2.2.0
vor 2001
1.8.0.7
1981
2.0.1
Entwicklung seit
Aktuelle Version
Client-Server Mode
Embedded Mode
ACID
Ja
Ja
Ja
Backup Management
Ja
Multiuser fähig
Benutzerverwaltung/
Zugriffsrechte
Integrierbare Prozeduren
und Trigger
Ja
Ja
Objekte speicherbar
(außer BLOB)
Siehe JDO
Ja (Prozeduren,
Funktionen,
Triggers)
Ja
Ja
Nein, nicht
vollständig
Ja, über Redo
Logging File
Ja
Ja
Ja (Java
Prozeduren,
Funktionen,
Triggers)
Siehe JDO
Ja
Ja
Ja
Ja
Ja
Ja
Ja (PSQL
Prozeduren,
Trigger)
Siehe JDO
29
Sonstige Features
Data Caching,
Verschlüsselung
2MB
k.A.
Memory Only
Mode, Read Only
Mode, Disk-based
Mode
600kB
k.A.
Footprint
Empfohlener
Festplattenplatz
Empfohlener RAM
Systembelastung
(Prozessor)
SQL92
SQL99
SQL2003
OQL
ODMG 3.0
JDO
1MB bis 2,6MB
k.A.
k.A.
Gering
k.A.
Gering
16MB
Gering
Ja
Teilweise
Teilweise
Nein
Nein
Mit JPOX
Teilweise
Teilweise
Teilweise
Nein
Nein
Mit JDO Genie
Sonstige Anfragesprachen
C++ Schnittstelle
ODBC Treiber
JDBC Treiber
Sonstige
Programmiersprachen und
Schnittstellen
Nein
Ja (über ODBC)
Ja
Ja
Java, Perl, PHP,
Python, .NET, Open
CLI
Nein
Nein
Nein
Ja
Java
Ja
Ja
Teilweise
Nein
Nein
Mit JDO Genie,
TJDO oder LiDO
Nein
Ja
Ja
Ja
Delphi, Pascal,
Perl, Python,
.NET, Java und
PHP
IDEs
Eclipse, NetBeans,
JBuilder
Unabhängig
Eclipse, JBuilder
unabhängig
befriedigend
JRE oder JDK (ab
1.3)
Unabhängig
gut
JRE oder JDK (ab
1.4)
Betriebssysteme
Architekturen
Dokumentation
Zusätzliche Software
benötigt
Nennenswerte
Erweiterungen
Bekanntheit (Google
Ergebnisse)
Lizenz
Preis
Unabhängig
Windows, Linux,
Unix (Solaris, HPUX), FreeBSD,
OS X
x86, Sparc
gut
keine
JayBird
545000
919000
Über 2 Millionen
Apache 2.0 License
Kostenlos
BSD License
Kostenlos
IDPL
Kostenlos
SQLite
Entwicklung seit
Aktuelle Version
Client-Server Mode
Read Only Mode
möglich (für CDs)
2000
3.3.17
Kein Server, aber mehrere
Programme können auf
Datenbasis zugreifen
Ja
EyeDB
Orient
2006
2.7.10
k.A.
2.3
Ja
30
Embedded Mode
ACID
Backup Management
Ja
Ja
Nein
Multiuser fähig
Kein gleichzeitiger
Schreibzugriff, nur
nacheinander (Datei wird
gelocked)
Nein
Benutzerverwaltung/
Zugriffsrechte
Integrierbare Prozeduren
und Trigger
Objekte speicherbar
(außer BLOB)
Sonstige Features
Footprint
Empfohlener
Festplattenplatz
Empfohlener RAM
Systembelastung
(Prozessor)
SQL92
SQL99
SQL2003
OQL
ODMG 3.0
JDO
Sonstige
Anfragesprachen
C++ Schnittstelle
ODBC Treiber
JDBC Treiber
Sonstige
Programmiersprachen
und Schnittstellen
IDEs
Betriebssysteme
Architekturen
Nein
k.A.
Ja (Recovery
System)
Ja
Ja
k.A.
k.A.
Ja
Ja
Ja (Methoden,
Trigger)
Ja
Ja
Da Daten in einer oder
mehreren Dateien gespeichert
sind, können sie leicht auf
andere Systeme übertragen
und weiterverwendet werden
150kB bis 225kB
Vererbung,
Integritätsbedingungen,
Objektmodel
Intelligent
Cache
Ca. 2MB
k.A.
k.A.
Mindestens
200kB
k.A.
k.A.
Gering
k.A.
Gering
k.A.
Gering
Teilweise
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Nein
Ja
Ja
Nein
Nein
Teilweise
Nein
Nein
k.A.
Ja
Ja
Nein
Ja
Ja
Ja
Java, Basic Dialekte, Delphi,
Python, Perl, PHP, .NET,
Ruby, Smalltalk, Tcl und viele
mehr
Ja
Nein
Nein
Java, CORBA
Ja
Nein
Nein
Java, XML
Windows, Linux, Unix, OS X
k.A.
Linux, Unix
32 und 64Bit
Prozessoren
ausreichend
keine
Unabhängig
Unabhängig
Ja (Funktionen, Trigger)
Nein, nur BLOB
Dokumentation
Zusätzliche Software
benötigt
befriedigend
keine
Nennenswerte
sqlite3 (zum anlegen eines
Ja
Ja
ungenügend
JRE oder
JDK (ab
1.3)
oExplorer
31
Erweiterungen
Bekanntheit (Google
Ergebnisse)
Lizenz
Datenbankfiles)
Über 8 Millionen
11400
742
Public Domain
LGPL
Preis
Kostenlos
Kostenlos
Apache 2.0
License
Kostenlos
In anbetracht der Anforderungen des InnoProfil Projektes erscheint mir persönlich die SQLite
Datenbank für ausreichend. Sie bietet einen einfachen Zugriff für mehrere Programme, hat
etliche Schnittstellen, eine große Gemeinde an Nutzern, geringe Hardwareanforderungen und
ausreichend Funktionen. Zwar bietet sie kein Backup und keinen Server Mode, um eventuell
mit anderen Teilnehmern im Netz Daten auszutauschen oder Daten zu sichern, doch kann
man dies mit eigenen Programmen oder Beispielprogrammen anderer Nutzer nachrüsten. Bei
Nichtgefallen bietet sich alternativ immer noch Firebird oder das RRDtool an. Da besonders
das RRDtool gerade für die gedachte Aufgabe konzipiert wurde, ist es zumindest eine gewisse
Beachtung wert.
Weiterführende Links:
Vergleich relationaler Datenbanken bei Wikipedia
http://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems
32
9.
Glossar
ACID
Synonym für Mindestanforderung, die eine Datenbank erfüllen muss. Steht
für Atomarität, Konsistenz (consistency), Isoliertheit und Dauerhaftigkeit.
ANSI
Amerikanisches Standardisierungsgremium ähnlich der ISO.
Backup
Englisch für Datensicherung. Auf einem anderen Medium wird eine Kopie
von Daten erzeugt, damit diese nach einem Crash des Primärmediums nicht
verloren gehen. Für ein stets aktuelles Backup müssten nach jeder Änderung
der Daten Sicherungen vorgenommen werden. Dies erledigt das DBMS oder
ein Festplatten-Raid System.
ClientServer
Mode
Modus einer Datenbank, in dem mehrere Programme auf die Daten der
Datenbank zugreifen können. Datenbank arbeitet als eigenständiges
Programm. Sie stellt Schnittstellen bereit, damit Programme auf dem
gleichen Rechner oder Programme auf entfernten Rechnern über Netzwerk
auf sie zugreifen können.
DBMS
Datenbankmanagementsystem, siehe 2.3. Je nach Datenbankmodell gibt es
auch andere Abkürzungen. RDBMS (relationale), VDBMS (verteilte
Datenbanken), ODBMS und OODBMS (objektorientierte)
Embedded
Mode
Modus einer Datenbank, indem sie in eine Anwendung integriert wird und
nur diese auf die Daten Zugriff hat.
ER-Modell
Entity-Relationship-Modell. Werkzeug zur Modellierung von Daten für
relationale Datenbanken.
Footprint
Minimum an Speicherbelegung der Datenbank.
JDBC
Standardisierte Treiberschnittstelle, um von Java Programmen auf die
Datenbank zugreifen zu können.
JDO
Java Data Objects. Standard von Sun um Java-Objekte direkt in Datenbanken
speichern zu können.
JRE
Java Runtime Environment. Laufzeitumgebung, die Java Programme
benötigen.
MySQL
Populärste der freien Datenbanken.
ODBC
Standardisierte Treiberschnittstelle, um von Programmen auf die Datenbank
zugreifen zu können, z.B. mit C++.
ODMG
Standardisierungsgremium. Entwarf unter anderem den ODMG Standard und
die Anfragesprache OQL.
OQL
Standardisierte Anfragesprache für objektorientierte Datenbanken. Hat sich
33
im Gegensatz zu SQL bisher kaum durchgesetzt. Liegt eventuell auch an
ihrem jungen Alter von nur wenigen Jahren.
SQL
Anfragesprache für relationale Datenbanken. Heutzutage wird das Kürzel
gewöhnlich als Structured Query Language interpretiert. Hat sich weitgehend
als Standard durchgesetzt. Verschiedene Standardisierungsversion schreiben
unterschiedliche Funktionalitäten vor. Es gibt SQL92, SQL99 und SQL2003.
UML
Werkzeug für semantische Datenmodellierung
XML
Beschreibungssprache für strukturierte Daten.
34
10. Literatur und Quellen
[Gei06]
Geisler, Frank: Datenbanken – Grundlagen und Design. 2. Auflage, mitpVerlag, 2006
[Kem06]
Kemper, Alfons; Eickler, André: Datenbanksysteme – Eine Einführung. 6.
Auflage, Oldenbourg Wissenschaftsverlag GmbH, 2006
[Vos00]
Vossen,
Gottfried:
Datenmodelle,
Datenbanksprachen
und
Datenbankmanagementsysteme. 4. Auflage, Oldenbourg Wissenschaftsverlag
GmbH, 2000
[Heu00]
Heuer, Andreas; Saake, Gunter: Datenbanken: Konzepte und Sprachen, , 2.
Auflage, mitp-Verlag, 2000
[Wik07]
http://www.wikipedia.org/
Diverse Artikel in der englischen und deutschen Version. An den
entsprechenden Stellen in dieser Arbeit als weiterführende Links angegeben.
35