Technische Universität Chemnitz

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. Apache Derby 14 5.3.2. HSQLDB 14 5.3.3. Firebird 15 5.3.4. SQLite 15 6. OBJEKTORIENTIERTES MODELL 17 6.1. Semantische Datenmodellierung 17 6.2. Objektorientiertes Datenbankmodell 18 6.3. Beispiele für objektorientierte Datenbanken 20 6.3.1. JDO (Java Data Objects) Datenbanken 20 6.3.2. EyeDB 21 6.3.3. db4o 21 6.4. Objektrelationales Datenbankmodell 21 6.5. Beispiele für objektrelationale Datenbanken 22 6.5.1. PostgreSQL 22 6.5.2. OpenLink Virtuoso 23 7. WEITERE DATENBANKMODELLE 24 7.1. Deduktive Datenbanken 24 2

7.2. Verteilte Datenbanksysteme 24 7.3. Eingebettete Datenbanken 26 7.4. Beispiele 26 7.4.1. Objectivity/DB 26 7.4.2. db.* (db star) 26 7.4.3. RRDtool 27 8. ANFORDERUNGEN UND ABSCHLUSSVERGLEICH 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 ANSI- SPARC-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 Konzeptuelle Ebene Interne Ebene Datenmedium Logische Datenunabhängigkeit Physische Datenunabhängigkeit 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 Wurzel = Eltern-Kind-Beziehung Blatt Blatt Blatt Blatt Blatt Abbildung 4-1: Baumstruktur des Hierarchischen Modells Die Verknüpfungen zwischen den Datensätzen werden Eltern-Kind-Beziehung (Parent-child- Relationships) 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 1 Vorlesung 2 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 hört Student 2 Student 3 Student 1 Vorlesung 2 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 (Kett- Record), 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 Matrikel Nr. Name SWS Studenten N hören M Vorlesungen N M N Vorl. Nr. Note prüfen 1 1 halten Name Professoren Raum 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 +MatrikelNr : int +Name : string +NameAendern(NeuName : string) : void +Notendurchschnitt() : float 1 0..* Prüfung +Note : float 0..* +Prüfer geprüftvon 0..* 1 +Hörer +Raum : int hören 1..* 0..* +Prüfungsstoff Professor +Umziehen(NeuRaum : int) : void 1 Vorlesungen +VorlesungsNr : int +Name : string +SWS : int +Raum : int +RaumVerlegen(NeuRaum : int) : void * gehaltenvon 1 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(); }; 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); } ; ID1 Student ID3 Vorlesung MatrikelNr: 100345 VorlesungsNr: 443 Name: Paul Specht Name: Mathematik hört: {ID3, ID4} SWS: 8 wurdegeprüft: {ID5} Raum: 007 Hörer: {ID1} warinhalt: {ID5} ID2 Student ID4 Vorlesung MatrikelNr: 44783 VorlesungsNr: 321 Name: Robert Pfeiffer Name: Theoretische Experimentalphysik hört: {ID4} SWS: 2 wurdegeprüft: {} Raum: 854 Hörer: {ID1, ID2} warinhalt: {} 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 Prüfung Note: 2,7 Prüfling: ID1 Inhalt: ID3 Prüfer: 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