Evaluierung Und Kon Guration einesDBMS Sowie Die Konzeption Undentwicklung Eines Datenbank-Serviceauf Basis Von RESTful Web Servicesin Scala

Masterarbeit
Evaluierung und Konguration eines DBMS sowie die Konzeption und Entwicklung eines Datenbank-Service auf Basis von RESTful Web Services in Scala
Zur Erlangung des akademischen Grades eines Master of Science - Media Processing and Interactive Services -
Fakultt Informatik Referent: Prof. Dr. Oliver Braun Korreferent: Dipl.-Mathematiker Michael Otto eingereicht von: Benjamin Ldicke Matr.-Nr. 260156 Schwarzhuser Str. 6b 99891 Winterstein Schmalkalden, den 13.09.2011
Zusammenfassung Diese Arbeit ist Teil des Projekts spirit@fhs, welches sich mit der Implementierung eines Informations- und Planungssystems fr die Fakultt Informatik der Fachhochschule Schmalkalden beschftigt. Ziel dieser Arbeit ist es, herauszunden inwiefern sich eine relationale oder NoSQL Datenbank fr die Datenhaltung eignet und wie die gespeicherten Daten ber eine REST-Schnittstelle fr andere Anwendungen zugnglich gemacht werden knnen. Dabei wird die relationale Datenbank PostgreSQL, die Graphen-Datenbank OrientDB und die Key/Value-Datenbank Riak nher untersucht. Ferner wird ein Datenmodell anhand von Anforderungen, welche vom Team sprit@fhs aufgestellt wurden, entwickelt und in den Datenbank-Service eingebettet. Der Datenbank-Service wird so konzipiert, dass Abhngigkeiten zur Datenbank vermieden werden und somit der Wechsel zu einer anderen Datenbank mglich ist.
Danksagung An dieser Stelle mchte ich bei allen bedanken, die mich bei der Erstellung dieser Master-Thesis untersttzt haben. Besonderen Dank gilt dabei Prof. Dr. Oliver Braun, welcher mir die Chance gab innerhalb des Team spirit@fhs diese Arbeit anzufertigen. Einen ganz besonderen Dank gilt ebenso Dipl.-Mathematiker Michael Otto, der mich bei der Einrichtung eines Servers untersttzt hat, damit auch andere Teammitglieder den Datenbank-Service nutzen knnen. Auch mchte ich mich bei meinen Teammitgliedern fr die tolle Zusammenarbeit bedanken. Besonders zu erwhnen sind Sebastian Stallenberger, Ronny Schleicher und Florian Schuhmann, welche die Qualitt des Datenmodell durch Vorschlge und konstruktive Kritik mageblich verbessert haben. Abschlieend mchte ich mich bei meinen Eltern Detlef und Scarlett Ldicke bedanken, die mich whrend meiner Studienzeit stets untersttzt und ermutigt haben.
Inhaltsverzeichnis
1 Einleitung 1.1 Motivation . . . . . . . . . 1.2 Das Projekt Spirit . . . . 1.3 Ziel der Arbeit . . . . . . 1.4 Vorgehensweise der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1 2 4 4 6 6 6 7 7 8 8 9 10 11 15 15 15 16
2 Theoretischer Hintergrund 2.1 Datenformate . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1 Extensible Markup Language . . . . . . . . . . . 2.1.2 JavaScript Object Notation . . . . . . . . . . . . 2.2 Web-Services mit REST . . . . . . . . . . . . . . . . . . 2.3 Lift - Ein Framework fr RESTful Web Services in Scala 2.4 Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . 2.4.1 Relationale Datenbanken . . . . . . . . . . . . . . 2.4.2 Die Standard Query Language . . . . . . . . . . . 2.4.3 Denition und Kategorisierung von NoSQL . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
3 Anforderungsspezikation 3.1 Ausgangssituation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.2 Anforderungen an den Datenbank-Service . . . . . . . . . . . . . . . 3.3 Anforderungen an die Datenbank . . . . . . . . . . . . . . . . . . . .
4 Anforderungsanalyse 17 4.1 Miniwelt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 4.2 Interaktion zwischen Anwender und System . . . . . . . . . . . . . . 17 4.3 Beurteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 5 Evaluierung mglicher Datenbanken 5.1 OrientDB . . . . . . . . . . . . . . 5.1.1 Datenmodell . . . . . . . . . 5.1.2 Beispielanwendung . . . . . 5.1.3 CRUD . . . . . . . . . . . . 5.1.4 Backup . . . . . . . . . . . 5.1.5 Skalierung und Replikation 5.1.6 Bewertung . . . . . . . . . . 5.2 Riak . . . . . . . . . . . . . . . . . 5.2.1 Datenmodell . . . . . . . . . 5.2.2 CRUD . . . . . . . . . . . . 5.2.3 Backup . . . . . . . . . . . 22 22 23 23 25 30 31 31 32 32 33 39
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
. . . . . . . . . . .
Benjamin Ldicke
IV
Inhaltsverzeichnis
Fachhochschule Schmalkalden SS 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 41 42 42 46 47 48 49 50 51 52 52 53 53 54 54 55 56 56 56 56 60 61 63 63 63 65 67 69 70 70 73 74 80 82 83 85 95
5.3
5.4 5.5
5.2.4 Skalierung, Replikation und Konguration 5.2.5 Bewertung . . . . . . . . . . . . . . . . . . PostgreSQL . . . . . . . . . . . . . . . . . . . . . 5.3.1 CRUD . . . . . . . . . . . . . . . . . . . . 5.3.2 Backup . . . . . . . . . . . . . . . . . . . 5.3.3 Replikation . . . . . . . . . . . . . . . . . 5.3.4 Bewertung . . . . . . . . . . . . . . . . . . EclipseLink als Object-Relational Mapper . . . . Auswahl einer Datenbank . . . . . . . . . . . . .
6 Festlegen des Datenmodell 6.1 Event . . . . . . . . . 6.2 Appointment . . . . . 6.3 Location . . . . . . . . 6.4 DegreeClass . . . . . . 6.5 Member . . . . . . . . 6.6 News . . . . . . . . . . 6.7 NewsComment . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
. . . . . . .
7 Realisierung 7.1 Grobentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2 Feinentwurf . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2.1 REST-Schnittstelle des Datenbank-Service . . . . . . . 7.2.2 Einbinden des Datenmodells in den Datenbank-Service 7.2.3 Helfer-Klassen . . . . . . . . . . . . . . . . . . . . . . . 8 Implementierung 8.1 Die REST-Schnittstelle und Http-Basic-Authentication 8.1.1 Die Klasse Boot . . . . . . . . . . . . . . . . . . 8.1.2 Die Klasse ServiceApi . . . . . . . . . . . . . . 8.1.3 Die abstrakte Klasse Invoke . . . . . . . . . . . 8.1.4 Die Klasse WithBody . . . . . . . . . . . . . . . 8.2 EclipseLink und PostgreSQL . . . . . . . . . . . . . . . 8.2.1 Das Datenmodell und EclipseLink . . . . . . . . 8.2.2 Anbinden von PostgreSQL an EclipseLink . . . 8.2.3 Datenbankabfragen mit EclipseLink . . . . . . . 9 Test 10 Zusammenfassung und Ausblick Literaturverzeichnis A Anhang Eidesstattliche Erklrung
. . . . .
. . . . .
. . . . .
. . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
. . . . . . . . .
Benjamin Ldicke
1 Einleitung
Das Internet ist in der Gegenwart eine nicht mehr wegzudenkende Informationsquelle. Mit der stetig wachsenden Menge an Daten werden neue Anforderungen an die Speichertechniken und besonders an die Datenbanken gestellt. Alle Datenbanken mssen in der Lage sein, schnell auf angeforderte Informationen zuzugreifen und diese bereitzustellen. Dabei ist jedoch nicht jede Datenbank fr jedes Anwendungsszenario gleich gut geeignet. Vor allem durch das Aufkommen der sogenannten NoSQL Datenbanken erweckt es den Anschein, als ob die klassischen relationalen Datenbanken nicht in neue Konzepte der Web2.0-Entwicklung passen. Die Auswahl einer geeigneten Datenbank fr ein geplantes Projekt, ist somit keine triviale Angelegenheit. Ferner sind jedoch nicht nur Datenbanken von der wachsenden Anzahl an Diensten im Internet betroen. Soziale Netzwerke, Nachrichten-Portale, Streaming-Portale und Blogs werden immer enger miteinander vernetzt. Somit ergeben sich auch neue Anforderungen an die Schnittstellen zuknftiger Webentwicklungen. Dienste mssen plattformbergreifend bereitgestellt werden, um eine optimale Nutzung zu gewhrleisten. Auch die Fachhochschule Schmalkalden hat diesen Trend erkannt und plant mit dem Projekt spirit@fhs1 eine Neuimplementierung des derzeitigen Informations- und Planungssystems. Als Teilprojekt von spirit@fhs ist diese Master-Thesis fr die Evaluierung einer geeigneten Datenbank verantwortlich. Des Weiteren muss eine Schnittstelle konzipiert werden, welche unabhngig von der gewhlten Datenbank deren Dienste bereitstellt. Im folgenden Abschnitt wird auf die Motivation und das Projekt spirit@fhs eingegangen. Danach wird das Ziel dieser Master-Thesis erlutert und abschlieend die Vorgehensweise der Bearbeitung der Arbeit dargestellt.
1.1 Motivation
Fr die Fakultt Informatik an der Fachhochschule Schmalkalden gibt es derzeit kein einheitliches Informations- und Planungssystem. Um Neuigkeiten und Termine zu verbreiten, werden verschiedene Distributionskanle genutzt. Es gibt die Homepage der Fakultt sowie die einzelnen Homepages der Professoren. Des Weiteren werden E-Mails an die betroenen Studiengnge versendet oder Termine und Neuigkeiten in einem Aushang verentlicht. Der Empfnger muss somit viel Aufwand betreiben, um ber alles informiert zu sein und ist zudem fr die Verwaltung der Termine selber verantwortlich. Studenten und Dozenten nutzen dafr einen Terminkalender in Form eines Buches oder einer Anwendung auf dem PC. Ein Abgleich der Termine ndet meist nicht automatisch statt. Somit werden nderungen und Konikte bei der Terminplanung nicht sofort oder erst viel spter erkannt. Auch die Bereitstellung des
1
http://pads.fh-schmalkalden.de/spirit.html
Benjamin Ldicke
Seite 1 von 95
1. Einleitung
Fachhochschule Schmalkalden SS 2011
Stundenplans fr die einzelnen Studiengnge erfolgt nicht dynamisch, sondern durch eine einmalig generierte HTML-Seite. Der statische Stundenplan im HTML-Format hat mehrere Nachteile. Zum Beispiel kann aus Platzgrnden nur die Abkrzung des Titels einer Vorlesung angezeigt werden. Um den vollstndigen Titel einer Vorlesung zu erfahren, muss in einem Abkrzungsverzeichnis nachgeschlagen werden. Auerdem ist nicht sofort zu erkennen, von wie vielen und welchen Dozenten die Vorlesung gehalten wird, da nur eine Zeile fr den Dozenten-Namen vergeben werden kann. Folglich entstehen zusammengesetzte Namen, wenn die Vorlesung von mehreren Dozenten gehalten wird. Findet beispielsweise eine Vorlesung mit den Dozenten Bse, Chantelau und Hettler statt, steht im Stundenplan der zusammengesetzte Name BoeChaHett (siehe Listing A.1). Weitere Termine wie Gastvortrge von Externen oder Tutorien knnen in diesem Plan nicht angezeigt werden. Das Erstellen eines personalisierten Stundenplans, mit einem automatischen Terminabgleich ist nicht mglich. Ferner knnen die Stundenplne und Nachrichten nur schlecht archiviert und gegebenenfalls wieder abgerufen werden. Auch das Festlegen bestimmter Filterkriterien, um Informationen gezielt anzuzeigen ist derzeit nicht umgesetzt. Aufgrund der dargelegten Missstnde ist es notwendig ein System zu entwickeln, welches die Limitierung der bisherigen statischen Lsung aufhebt. Durch das Speichern des Stundenplans in einer Datenbank, ist es mglich personalisierte Stundenplne zu erstellen sowie nderungen bei der Terminplanung nachzuvollziehen. Auch das Archivieren und Filtern von Nachrichten kann durch eine Datenbank realisiert werden. Damit die Datenbank bei Bedarf ausgetauscht oder erweitert werden kann, ist die Funktionalitt durch eine Service-Schnittstelle zu kapseln. Ferner wird so eine plattformund programmiersprachenunabhngige Nutzung gewhrleistet.
1.2 Das Projekt Spirit

Das Projekt spirit@fhs ist von Prof. Dr. Oliver Braun im Sommersemester 2010 an der Fachhochschule Schmalkalden gestartet worden. Es befasst sich mit der Neuimplementierung des Informations- und Planungssystems fr den Fachbereich Informatik. Dabei soll der Aufwand bei der Planung und Verwaltung von Terminen minimiert werden. Umgesetzt werden dabei mehrere Teilprojekte mit unterschiedlichen Schwerpunkten. Diese Teilprojekte werden im Rahmen von Bachelor- bzw. Masterarbeiten durchgefhrt und bilden unabhngige Module. So knnen einzelne Anwendungen ausgetauscht oder erweitert werden, ohne andere Anwendungen in ihrer Funktionalitt zu beeinussen. Diese einzelnen Teilprojekte werden nun kurz vorgestellt.
Core
Das Teilprojekt Core ist ein prototypischer Generator. Dieser erstellt anhand von vorher denierten Bedingungen gltige Stundenplne. Eine Aussage ber die Gte eines Stundenplans wird jedoch nicht getroen.
Benjamin Ldicke
Seite 2 von 95
1. Einleitung
Studweb
Studweb wird das neue Informationsportal fr Studenten der Fakultt Informatik. Es soll Funktionen wie das Anzeigen von Nachrichten und Kommentaren sowie das Verwalten eines Terminkalenders beinhalten.
EmployeeWeb
Das Teilprojekt EmployeeWeb wird hnliche Funktionen wie Studweb haben. Jedoch soll es auf die Nutzung durch Mitarbeiter der Fachhochschule Schmalkalden optimiert werden.
PlanningWeb
Dieses Teilprojekt bietet Untersttzung bei der Planung von Stundenplnen. Ziel ist es, den Aufwand bei der Planung zu minimieren indem durch eine Web-Anwendung, die fr Core bentigten Daten bereitgestellt werden. Alle erfassten Daten werden fr eine sptere Verwendung in einer separaten Datenbank abgelegt.
Mobile
Das Teilprojekt Mobile umfasst mehrere Anwendungen. Ziel ist es, fr verschiedene mobile Endgerte einen hnlichen Funktionsumfang wie von EmployeeWeb und StudWeb bereitzustellen. Dafr werden Applikationen fr die Betriebssysteme Android, Windows 7 Phone und iOS entwickelt.
DistributedCalc
Nachdem keine Aussage ber die Gte eines erstellten Stundenplans getroen wird, soll durch diese Anwendung anhand einer Metrik, der beste Stundenplan ermittelt werden.
Migrate
Das Teilprojekt Migrate hat als Ziel den bisherigen statischen Stundenplan zu parsen und in eine dynamische Datenstruktur zu berfhren. Dieses Projekt ist eine bergangslsung bis das Projekt DistributedCalc funktionsfhig ist.
News
Das Teilprojekt News ist eine Informationsplattform, mit dem Nachrichten von Dozenten auf der Homepage der Fakultt verentlicht werden. Es bietet zustzliche Funktionen, wie das verentlichen von Nachrichten ber Twitter oder die Mglichkeit einen RSS-Feed zu abonnieren. Dieses Teilprojekt ist schon fertiggestellt
Benjamin Ldicke
Seite 3 von 95
1. Einleitung
und kann als bergangslsung oder Ergnzung fr die neuen Informationsportale Studweb und EmployeeWeb angesehen werden.
Data
Das Teilprojekt Data ist Bestandteil dieser Master-Thesis und wird im Abschnitt 1.3 genauer erlutert.
1.3 Ziel der Arbeit

Um das Ziel dieser Master-Thesis zu erlutern, wird zunchst der Titel der Arbeit betrachtet: Evaluierung und Konguration eines DBMS2 sowie die Konzeption und Entwicklung eines Datenbank-Service auf Basis eines RESTful Web-Service in Scala. Zu erkennen ist, dass in der Master-Thesis zwei Ziele verfolgt werden. Zum einen soll untersucht werden, was fr ein DBMS sich fr das Projekt spirit@fhs eignet und zum anderen soll ein Service konzipiert werden, welcher die Dienste von diesem System abstrahiert, um eine einheitliche Schnittstelle bereitzustellen. Ziel ist, dass die Teilprojekte von spirit@fhs auf den Datenbank-Service zugreifen, um Informationen zu speichern oder abzurufen. Durch das Kapseln der Datenbank hinter den Datenbank-Service ist es mglich die Datenbank auszutauschen, ohne dass die Schnittstellen zu den Teilprojekten angepasst werden mssen.
1.4 Vorgehensweise der Arbeit

Um ein besseres Verstndnis fr die Thematik zu bekommen, wird in dem Kapitel 2 auf Begrie und Technologien eingegangen, welche die Grundlage fr diese Arbeit bilden. Zuerst werden die zwei Datenformate JavaScript Object Notation und Extensible Markup Language erlutert die genutzt werden, um Daten vom Datenbank-Service zu empfangen oder zum Datenbank-Service zu senden. Danach wird die bertragungstechnologie REST vorgestellt. Um einen berblick ber die bestehenden Datenbanktechnologien zu bekommen, wird des Weiteren das Konzept der relationalen Datenbanken und die dazugehrige Abfragesprache SQL erlutert. Ferner wird der Begri NoSQL deniert und eine Kategorisierung von NoSQL Datenbanken vorgenommen. In den darauf folgendem Kapitel 3 werden die Anforderungen an den Datenbank-Service und an die Datenbank deniert. Damit die Auswahl einer geeigneten Datenbank eingeschrnkt werden kann, wird im Abschnitt 4 eine Datenanalyse durchgefhrt, wobei Zusammenhnge zwischen den Daten verdeutlicht werden. Mgliche Datenbanken werden daraufhin an den festgelegten Anforderungen gemessen. Ferner wird untersucht, welche Untersttzung Frameworks fr die ausgewhlten Datenbanken bieten und wie die REST-Schnittstelle vom DatenbankService umgesetzt werden kann. Im Kapitel 7 wird ein Datenmodell entworfen, welches den Anforderungen an den Datenbank-Service gengt. Auf diesem Datenmodell beruht der Entwurf der zu implementierenden REST-Schnittstelle. Im Kapitel 8
2
Datenbankmanagementsystem
Benjamin Ldicke
Seite 4 von 95
1. Einleitung
wird dargestellt, wie die Datenbank an den Datenbank-Service angebunden ist. Ferner wird anhand einer Beispiel-Anfrage gezeigt, wie diese vom Datenbank-Service abgearbeitet wird. Abschlieend erfolgen eine Zusammenfassung ber die erreichten Ziele und ein Ausblick.
Benjamin Ldicke
Seite 5 von 95
2 Theoretischer Hintergrund
Dieses Kapitel befasst sich mit den Grundlagentechnologien und Begrien, welche fr das Verstndnis dieser Master-Thesis notwendig sind. Einleitend werden die Datenformate JavaScript Object Notation und Extensible Markup Language beschrieben. Im Anschluss wird die bertragungstechnologie REST erlutert, die genutzt wird um den Datenbank-Service fr andere Applikationen zugnglich zu machen. Zum Speichern der Daten stehen verschiedene Technologien zur Verfgung. In diesem Kapitel wird auf das relationale Datenmodell und die Abfragesprache SQL eingegangen. Des Weiteren wird der Begri NoSQL deniert und NoSQL Datenbanken kategorisiert.
2.1 Datenformate
Fr den Datenaustausch zwischen Datenbank-Service und anderen Spirit-Applikationen, werden die Extensible Markup Language und die JavaScript Object Notation verwendet. Beide Datenformate sind im Internet weit verbreitet und gewhrleisten ein programmiersprachen- und plattformunabhngiges Austauschen von Informationen.
2.1.1 Extensible Markup Language

Die Extensible Markup Language (XML) ist eine Meta-Auszeichnungssprache die 1998 entstand und vom W3C1 speziziert wurde. Entspricht die Syntax eines XMLDokumentes dieser Spezikation, wird es als wohlgeformt bezeichnet. Der Vorteil eines wohlgeformten XML-Dokumentes ist, dass es von allen Anwendungen interpretiert werden kann, welche die XML-Spezikation kennen. Ein gltiges XMLDokument besteht aus einem oder mehreren XML-Elementen, wobei ein XMLElement durch sogenannte Tags deniert ist. Weil XML eine Meta-Auszeichnungssprache ist, hat es keine fest vergebene Menge an Elementen, wie es bei HTML der Fall ist. Dadurch ermglicht XML, den Autoren eines XML-Dokuments, selber Elemente zu denieren. Dadurch wird das XML-Dokument selbstbeschreibend und fr den Menschen lesbar. Ferner ermglicht XML das Erstellen von Auszeichnungssprachen. Die Struktur einer Auszeichnungssprache wird in einem Schema erfasst. Ein XML-Schema kann zum Beispiel als XML-Schema-Denition (XSD) oder Document-Type-Denition (DTD) erstellt werden. Ein Dokument welches der Struktur des Schemas entspricht, wird als valide bezeichnet [HM04].
World Wide Web Consortium
Benjamin Ldicke
Seite 6 von 95
2. Theoretischer Hintergrund
2.1.2 JavaScript Object Notation

Die JavaScript Object Notation (JSON) ist ein weiteres bertragungsformat, mit dem es mglich ist strukturiert Daten zwischen Anwendungen auszutauschen. Es entstand im Jahr 2005 und wird im RFC 4627 beschrieben. Anders als bei XML werden Strukturen nicht durch lange Tag-Namen, sondern durch eckige und geschweifte Klammern deniert [Rie09]. Die eigentlichen Daten werden durch Schlssel/WertPaare dargestellt und knnen vom Typ String, Number, Array, Object, Boolean oder Null sein. Wie auch bei XML werden Binrdaten nicht untersttzt. Daten innerhalb von geschweiften Klammern reprsentieren ein Objekt. Mehrere Objekte oder Schlssel/Wert-Paare innerhalb eckigen Klammern stellen ein Array dar. Eine genauere Beschreibung der JSON-Struktur ist auf der JSON-Homepage2 zu nden. Der Vorteil dieser knappen Strukturierung ist das Reduzieren des sogenannten Daten-Overheads. Infolgedessen ist JSON geeignet, um Daten mit mobilen oder schwachen Endgerten auszutauschen.
2.2 Web-Services mit REST

Die im vorherigen Abschnitt vorgestellten bertragungsformate werden genutzt, um Informationen zwischen dem Datenbank-Service und dessen Clients auszutauschen. Die dafr verwendete Architektur ist REST. REST bedeutet Representational State Transfer und wurde im Jahr 2000, in der Dissertation [Fie00] von Roy Thomas Fielding, als Verfahren zum Bewerten von Architekturen prsentiert. In dieser Master-Thesis wird REST verwendet, um einen Web-Service bereitzustellen. Im Gegensatz zu dem Web-Service-Stack3 gilt REST als weniger komplex [RR07, S. XV], da es mglich ist Daten ohne eine zustzliche Transportschicht zu versenden. Eine besondere Eigenschaft von REST ist die Adressierbarkeit von Ressourcen4 . Eine Ressource ist genau einem http-URI5 zugeordnet. In der Tabelle 2.1 sind die http-Methoden aufgelistet, welche ein Client fr eine Anfrage verwenden kann. In dieser Master-Thesis werden lediglich die Methoden GET, PUT, POST und DELETE implementiert. Durch den Kontext der Methoden, wird dem Client das Verhalten des jeweiligen URI verdeutlicht. Wie bei GET beschrieben, erhlt der Client eine Reprsentation als Antwort auf eine Anfrage. Dabei kann eine Reprsentation in verschiedenen Formen vorliegen. Die in dieser Arbeit verwendeten Reprsentationsformen sind XML und JSON, welche im Abschnitt 2.1 erlutert wurden. Ferner enthlt die Antwort die blichen http-Statuscodes. Ein weiteres Merkmal von REST ist die Zustandslosigkeit. Laut Richardson und Ruby [RR07, S. 101] existieren zwei Arten von Zustnden - den Anwendungszustand und den Ressourcenzustand. Ersterer wird im Client gespeichert und bei jeder Anfrage an den Server mitgesendet. Ein Beispiel ist die Eingabe eines Begris in eine Suchmaschine. Je nachdem welcher
2 3
Homepage: http://www.json.org/ als Web Service Stack wird die Sammlung an Protokollen und Standards bezeichnet, die notwendig sind um eine service-orientierte Architektur (SOA) aufzubauen 4 eine Ressource reprsentiert eine Information auf dem Server - das knnen eine Methode oder Daten aus einer Datenbank sein 5 RFC 3986: http://tools.ietf.org/html/rfc3986#page-16
Benjamin Ldicke
Seite 7 von 95
2. Theoretischer Hintergrund GET PUT POST DELETE HEAD TRACE OPTION
liefert eine Reprsentation einer Ressource an den Client zurck erzeugt eine Ressource auf dem Server erzeugt oder ndert eine Ressource auf dem Server lscht eine Ressource auf dem Server liefert nur den Header einer Antwort sendet die Anfrage so zurck, wie sie der Server empfangen hat sendet eine Liste mit Features zurck, welche von diesem URI untersttzt werden CONNECT wird verwendet um SSL-Tunnel zu erstellen Tabelle 2.1: http-Methoden Begri eingeben wurde, liefert der Server eine andere Liste an Links. Der Ressourcenzustand wird auf dem Server gehalten und ist fr jeden Client gleich. In den meisten Fllen ist der Ressourcenzustand eine Datenbank. Infolgedessen ist der Server, welcher eine REST-konforme Schnittstelle anbietet, nicht fr die Verwaltung des Anwendungszustandes verantwortlich.
2.3 Lift - Ein Framework fr RESTful Web Services in Scala

Wie im Abschnitt 2.2 erwhnt, wird der Datenbank-Service ber eine REST-Schnittstelle erreichbar sein. Um diese in Scala umzusetzen, gibt es verschiedene Frameworks wie zum Beispiel Scalatra6 , BlueEyes7 oder Lift8 . In dieser MasterThesis wird Lift, aufgrund einer besseren Dokumentation gegenber den anderen Frameworks, verwendet. Das Lift-Projekt startete im Jahr 2007 und die erste stabile Version 1.0 wurde im Jahr 2009 verentlicht. Derzeitig liegt Lift in der stabilen Version 2.3 vor. Lift ist jedoch nicht nur ein Framework mit dem ein RESTful Web Service implementiert werden kann. Ferner ist es ein Web-Framework, mit dem komplette Webseiten und Webapplikationen entwickelt werden knnen. Zustzlich kann Lift fr ORM9 verwendet werden. Dafr hat Lift das Mapper- und Record Framework integriert, wobei Mapper als primrer ORM von Record abgelst werden soll. Weil sich Record noch in der Entwicklungsphase bendet, ist die Verwendung im Produktiveinsatz nicht zu empfehlen [CBDW].
2.4 Datenbanken
Es gibt heutzutage in den meisten Unternehmen und Organisationen keine Alternative mehr zum Einsatz eines DBMS fr die Informationsverarbeitung [KE01, S. 17]. Der Verzicht eines Datenbankmanagementsystems hat weitreichende Konsequenzen
6 7
https://github.com/scalatra/scalatra https://github.com/jdegoes/blueeyes 8 http://liftweb.net/ 9 Object-Relational Mapping
Benjamin Ldicke
Seite 8 von 95
auf die Informationsverarbeitung. Durch die Speicherung der Daten in isolierten Dateien auf einem Server, kann es zu Inkonsistenzen10 kommen, da Daten redundant in weiteren Dateien gespeichert sein knnten. Ferner ist es schwer eine Beziehung zwischen diesen Dateien aufzubauen und somit zusammenhngende Abfragen zu formulieren. Auerdem wird auch kein Mehrbenutzerbetrieb untersttzt, was Inkonsistenzen oder Leistungseinbuen zur Folge haben kann. Aus diesem Grund wird fr das Projekt spirit@fhs das Speichern der Daten in einem DBMS bevorzugt. In diesem Abschnitt wird das Konzept der relationalen Datenbanken sowie die Abfragesprache SQL erlutert. Zustzlich wird der Begri NoSQL deniert und einen Kategorisierung von NoSQL Datenbanken vorgenommen.
2.4.1 Relationale Datenbanken

Relationale Datenbanken beruhen auf dem relationalen Modell, welches am Anfang der siebziger Jahre von E. F. Codd konzipiert wurde. Die grundlegende Datenstruktur des relationalen Datenmodells ist dabei die Relation. Die Deklaration einer Relation erfolgt ber das sogenannte Relationenschema, wobei ein relationales Datenbankschema aus mehreren dieser Schemen besteht [Kud07, S. 73]. Ein Relationenschema beschreibt dabei die zugrundeliegende Datenstruktur, wobei das relationale Datenbankschema die Beziehungen zwischen den Relationen abbildet. Der Aufbau einer Relation wird in Abbildung 2.1 dargestellt. Die Spalten einer Relation werden als Attribute oder Felder bezeichnet und reprsentieren die Eigenschaften eines Objekttyps. Die Zeilen heien Tupel und stellen mehrere Objekte dar. Die Anzahl der Tupel einer Relation nennt man Grad. Die Mengeneigenschaft einer Relation
Abbildung 2.1: Eigene Darstellung einer Relation in Anlehnung an [Kud07, S. 74]
10
als Konsistenz bezeichnet man die logische Widerspruchsfreiheit von Daten, wobei eine Inkonsistenz das Gegenteil bedeutet
Benjamin Ldicke
Seite 9 von 95
fordert die Einzigkeit der Tupel. Damit diese und eine logische Konsistenz umgesetzt werden kann, nutzt man Integrittsbedingungen. Unterschieden werden dabei die Entittsintegritt und die referentielle Integritt. Entittsintegritt bedeutet, dass jedes Tupel in einer Relation nur einmal vorkommen darf. Sichergestellt wird das durch sogenannte Primrschlssel. Ein Schlssel ist dabei eine Attributmenge, welche ein Tupel eindeutig identiziert. Die kleinste Menge dieser Attributmenge, nennt man Primrschlssel [Kud07, S. 76]. Zum Beispiel ist ein Student eindeutig an seiner Matrikelnummer zu identizieren. Als referenzielle Integritt bezeichnet man die Konsistenzsicherung ber sogenannte Fremdschlssel. Ein Fremdschlssel ist eine Attributmenge, die einen Primrschlssel einer (anderen) Relation referenziert [Kud07, S. 77]. Zu beachten ist, dass zu jeden Wert eines Fremdschlssels, ein Primrschlssel mit dem gleichen Wert existiert, wie es in Abbildung 2.2 dargestellt ist. In der Tabelle warenkorb_artikel verweist der Fremdschlssel artikel_id auf den Primrschlssel id der Tabelle artikel. Laut Meinung des Autors sind die bekanntesten Vertreter relationaler Datenbanken: Microsoft mit dem SQL Server, IBM mit DB2, MySQL, PostgreSQL und Oracle.
Abbildung 2.2: Eigene Darstellung einer N:M Beziehung zwischen Relationen
2.4.2 Die Standard Query Language

Die Standard Query Language (SQL) beruht auf der relationalen Algebra und wurde 1970 von E. F. Codd vorgestellt. Derzeit liegt SQL, ISO/ANSI standardisiert, in der Version 200811 vor. SQL heit bersetzt Standard Abfrage-Sprache. Durch SQL ist es mglich relationale Datenbanken zu steuern oder zu manipulieren. SQL lsst sich in vier Teilsprachen aufteilen, welche in Tabelle 2.2 abgebildet sind. Wie ein SQL-Ausdruck aufgebaut ist und wie mit der DML und DQL eine relationale Datenbank manipuliert bzw. abgefragt wird, ist im Kapitel 5.3 erlutert. Neben SQL existieren noch weitere Abfragesprachen wie zum Beispiel QUEL, welche in
11
SQL-Standard: http://www.iso.org/iso/catalogue_detail.htm?csnumber=45498
Benjamin Ldicke
Seite 10 von 95
2. Theoretischer Hintergrund Teilsprache Data Denition Language (DDL) Data Manipulation Language (DML) Data Query Language (DQL) Data Control Language (DCL)
Fachhochschule Schmalkalden SS 2011 Anwendung zum Erzeugen, Lschen und ndern von Schemata zum Erzeugen, Lschen und ndern von Tabelleninhalten zur Abfrage von Tabelleninhalten zur Vergabe von Zugrisrechten
Tabelle 2.2: Teilsprachen von SQL laut [Kud07, S. 108] der open-source Datenbank INGRES12 eingebettet ist.
2.4.3 Denition und Kategorisierung von NoSQL

Der Begri NoSQL erweckt den Anschein, dass es sich hierbei um eine Ablehnung von SQL handelt. Das ist jedoch nicht der Fall. Vielmehr ist der Begri NoSQL eine Provokation um Aufmerksamkeit zu erregen und wird heutzutage als not only SQL bersetzt [EFHB10, S. XI]. In diesem Abschnitt wird der Begri NoSQL deniert und eine mgliche Kategorisierung von NoSQL Datenbanken vorgestellt. Denition von NoSQL Die NoSQL-Community mchte mit dem Begri NoSQL eine Alternative zu den relationalen Datenbanken und dem Transaktionsmanagement herausstellen. Dabei sollen NoSQL-Technologien besonders bei den Betriebskosten, der Skalierbarkeit und der Anwendungsentwicklung einem relationalen Datenbanksystem berlegen sein. Durch die Open-Source-Community wird diesbezglich selten auf Standards zurckgegrien, sondern durch die verbreitete Anwendung von Programmiermodellen De-facto-Standards erschaen, die sich in NoSQL Datenbanksystemen wiedernden. Ein Beispiel dazu ist das Map/Reduce Framework aus dem Projekt Hadoop, mit dem es mglich ist nebenluge Berechnungen ezient durchzufhren. Auf der Webseite http://nosql-databases.org sind viele Vertreter der NoSQL Datenbanken aufgelistet. Jedoch sind nicht nur neue unbekannte Datenbanksysteme verzeichnet, sondern auch schon lnger existierende Objekt- oder XML-Datenbanken. Ferner existieren Hybrid-Lsungen wie GenieDB, welche die Trennung zwischen relationalen Datenbanksystemen und NoSQL Datenbanksystemen erschweren. Anhand von sieben Punkten wird in dem Buch [EFHB10, S. 2] versucht eine Grenze zwischen relationalen und NoSQL Datenbanken herzustellen. 1. das zugrundeliegende Datenmodell ist nicht relational 2. die Systeme sind von Anbeginn an auf eine verteilte und horizontale Skalierbarkeit ausgerichtet 3. das NoSQL-System ist open-source 4. das System ist schemafrei oder hat nur schwchere Schemarestriktionen
12
Homepage INGRES: http://www.ingres.com
Benjamin Ldicke
Seite 11 von 95
5. aufgrund der verteilten Architektur untersttzt das System eine einfache Datenreplikation 6. dem System liegt meist auch ein anderes Konsistenzmodell zugrunde: Eventually Consistent und BASE, aber nicht ACID Die aufgezhlten Punkte sind nicht alle als k.o. Kriterium zu sehen. Zum Beispiel gibt es durchaus NoSQL-Systeme wie SimpleDB von Amazon, welche keine opensource Projekte darstellen. Der Punkt vier, welcher Schemafreiheit fordert, wird jedoch als grundlegende Anforderung an ein NoSQL-System angesehen. Weil sich Webanwendungen oft ndern, muss auch das Datenbankschema oft angepasst werden. In nichtrelationalen Datenbanken geschieht dies durch die DDL. In schemafreien Datenbanken wird die Verantwortung fr das Schema aus der Datenbank in die Anwendung verlagert. Dadurch sollen schnellere Anpassungen des Schemas mglich sein [EFHB10, S. 3]. Im folgenden Abschnitt wird gezeigt, in welche Kategorien sich NoSQL Datenbanken einteilen lassen. Kategorisierung von NoSQL Datenbanken In der Abbildung 2.3 ist zu erkennen welche Datenbanken laut [EFHB10, S. 6] eher als relationale und welche als NoSQL Datenbanken angesehen werden. Unter der Rubrik relational/SQL world sind bekannte relationale Datenbanken aufgelistet, wobei unter Core NoSQL keine Datenbanken stehen, sondern verschiedene Kategorien von NoSQL Datenbanken. Damit wird nochmals deutlich, dass NoSQL kein Datenmodell ist, sondern eine Sammlung von alternativen zu dem relationalen Datenmodell. Die vier gezeigten NoSQL Datenbankkategorien werden jetzt kurz vorgestellt. Key/Value-Systeme Ein Key/Value-System speichert Informationen in Schlssel/Wert Paaren ab. Dabei knnen die Werte nicht nur einzelne Strings, sondern auch Listen oder Mengen darstellen. Key/Value Systeme lassen sich wiederum in die Varianten In-Memory und On-Disk aufteilen. In-Memory Datenbanken halten die Informationen im Speicher und sind deshalb in der Lage schnell Ergebnisse zu liefern, ohne das langsame Festplattenzugrie erfolgen mssen. Der Nachteil ist, dass bei einem Ausfall der Hardware die Daten im Speicher eventuell verloren gehen knnen und nicht wiederherzustellen sind. Bei der zweiten Variante handelt es sich um Datenbanksysteme, welche die Daten auf der Festplatte hinterlegen um Datenverlusten vorzubeugen. Jedoch ist diese Variante technisch bedingt nicht so performant wie bei In-Memory Systemen [WM]. Ein Beispiel fr ein On-Disk System ist die Datenbank Riak, welche im Kapitel 5.2 vorgestellt wird. Wide Column Systeme Die relationalen Datenbanken wie zum Beispiel PostgreSQL werden als zeilenorientiert bezeichnet, da das Speichern von Informationen zeilenweise durchgefhrt wird. Bei einer spaltenorientierten Datenbank ist es jedoch so, dass die Informationen spaltenweise hinterlegt werden. Im folgenden Beispiel sollen drei Datenstze mit den Attributen: id, name und alter gespeichert werden. In einer relationalen Datenbank sind die Daten folgendermaen im Speicher hinterlegt: 1, luedicke, 26, 2, stallenberger, 27, 3, schleicher, 31
Benjamin Ldicke
Seite 12 von 95
Abbildung 2.3: Eigene Darstellung zur Kategorisierung von NoSQL-Systemen in Anlehnung an [EFHB10, S. 6] Bei einer spaltenorientierten Datenbank sieht die Struktur so aus: 1, 2, 3, luedicke, stallenberger, schleicher, 26, 27, 31 Durch die spaltenorientierte Speicherung der Datenstze ist ein ezientes analysieren der Daten mglich, da die Informationen zu einer Spalte im Speicher hintereinander liegen. Werden nun alle Werte eines Attributes bentigt, kann die Hardware so ezienter auf die bentigten Daten zugreifen. Ein Beispiel ist die Berechnung des durchschnittlichen Alters aller eingetragenen Personen. Leistungseinbuen entstehen jedoch beim Einfgen oder Lesen von ganzen Datenstzen [EFHB10, S. 53]. Dokumenten-Datenbanken Dokumenten-Datenbanken sind in der Lage strukturierte Daten in Form von JSON- oder XML-Dokumenten abzuspeichern. Dabei gehren sie grundstzlich zu den schemafreien Datenbanken. Wird ein Dokument gespeichert, muss demnach ein anderes Dokument nicht zwingend die gleiche Struktur aufweisen. Darum sind Dokument-Datenbanken sehr exibel und lassen sich leicht skalieren. Aufgrund der Schemafreiheit kann es jedoch zu Inkonsistenzen und Integrittsproblemen kommen. Die bekanntesten Dokumenten-Datenbanken sind CouchDB und MongoDB [EFHB10, S.12] [WM]. Graphen-Datenbanken Laut [Tit03, S. 12] wird ein Graph folgendermaen deniert. Ein Graph G = (V, E) wird durch eine Knotenmenge V und eine Kantenmenge E dargestellt, wobei jeder Kante aus E zwei Knoten aus K zugeordnet sind.
Benjamin Ldicke
Seite 13 von 95
Ein Vorteil von Graphen-Datenbanken ist das eziente Erstellen und Abfragen von komplexen Beziehungen, die in relationalen Datenbanken nur schwer umzusetzen sind. Vorteile von Graphen-Datenbanken sind laut [EFHB10, S. 169]: einfacher Umgang mit rekursiv vernetzten Informationen gute Untersttzung von semistrukturierten Datenstzen Untersttzung graphenorientierter und semantsicher Operationen einfache Skalierbarkeit Anwendungsgebiete von Graphen-Datenbanken sind Geoinformationssysteme, soziale Netzwerke oder auch Empfehlungssysteme. Im Kapitel 5.1 wird OrientDB als ein Vertreter der Graphen-Datenbanken vorgestellt, sowie das zugrunde liegende Datenmodell erlutert.
Benjamin Ldicke
Seite 14 von 95
3 Anforderungsspezikation
In diesem Kapitel wird die Ausgangssituation dargelegt, wie derzeitig Informationen bezglich des Stundenplans und anderen Veranstaltungen an der Fachhochschule Schmalkalden verbreitet werden. Aufbauend darauf werden Anforderungen an die Datenbank und den Service gestellt, um ein Informations- und Planungssystem umzusetzen. Diese Anforderungen sind durch Absprachen mit den Projektmitgliedern entstanden. Ferner gab es regelmige Veranstaltungen, bei denen Vorschlge zur Umsetzung diskutiert wurden. In dieser Master-Thesis werden die Anforderungen bei der Auswahl einer geeigneten Datenbank bercksichtigt und der Service anhand der festgelegten Anforderungen, sowie die daraus folgenden Anwendungsflle umgesetzt.
3.1 Ausgangssituation
Wie im Kapitel 1 bereits erwhnt, gibt es an der Fachhochschule Schmalkalden kein einheitliches Informations- und Planungssystem. Die Verteilung von Informationen geschieht ber mehrere Plattformen. Ferner ist der Stundenplan nur im statischen HTML verfgbar. nderungen an dem Stundenplan, bedingt durch Verschiebung oder Ausfllen, sind derzeitig nicht mglich und somit nicht nachvollziehbar. Mit dem Projekt spirit@fhs wird versucht ein neues System zu entwickeln, welches die Terminplanung und das Verbreiten von Informationen ber Webportale und Handyapplikationen ermglicht. Damit die Applikationen auf den gleichen Datenbestand zugreifen knnen, ist es notwendig die Daten an einer zentralen Stelle zu halten.
3.2 Anforderungen an den Datenbank-Service

1. die Datenbank ist fr die anderen Teilprojekte nur ber den Datenbank-Service zu erreichen 2. fr die Kommunikation mit den anderen Applikation ist eine einheitliche Schnittstelle bereitzustellen 3. es drfen nur ausgewhlte Applikationen mit dem Service Verbindung aufnehmen 4. der Datenbank-Service stellt Filterfunktionen ber die Schnittstelle bereit 5. der Service ermglicht das Austauschen der Datenbank, ohne das die Schnittstelle zu den Teilprojekten gendert werden muss 6. es wird eine Schnittstelle angeboten, welche die Authentizierung gegen einen LDAP-Server ermglicht
Benjamin Ldicke
Seite 15 von 95
3. Anforderungsspezikation
Damit die Applikationen der Teilprojekte, bei nderung an der Datenbank, nicht angepasst werden mssen, kapselt der Datenbank-Service die Datenbank. Ferner wird somit sichergestellt, dass nur authentizierte Applikationen auf die Datenbank zugreifen knnen. Auerdem ist somit eine Brut-Force-Attacke gegen den LDAP-Server nicht direkt mglich. ber die bereitgestellten Filterfunktionen soll es mglich sein, gezielt nach Daten zu suchen. Die Bereitstellung der Daten erfolgt ber einen RESTful Web Service, welcher die bertragungsformate XML und JSON untersttzt.
3.3 Anforderungen an die Datenbank

1. die Datenbank ermglicht ein einfaches Erstellen von Backups 2. die Datenbank muss sehr gut dokumentiert sein und in einer stabilen Version vorliegen 3. die Datenbank sollte horizontale Skalierung untersttzen1 4. alle von den Teilprojekten gesendeten Daten mssen konsistent gespeichert werden 5. die Datenbank ist kostenlos ohne Einschrnkungen zu nutzen 6. die Datenbank muss unter Linux lauhig sein Damit die Daten bei einem Totalausfall der Hard- oder Software nicht komplett verloren gehen, soll es eine einfache Mglichkeit geben ein Backup zu erstellen. Ferner sollte die Datenbank horizontal skalierbar sein, um die Systemlast auf andere Knoten zu verteilen. Eine ausfhrliche Dokumentation ist notwendig, um neuen Projektmitgliedern einen leichten Einstieg in den Umgang mit der Datenbank zu ermglichen. Auerdem ist dadurch die Wartung und Administration der Datenbank fr neue Projektmitglieder einfacher. Weil zuknftige nderungen im Datenschema nicht ausgeschlossen werden knnen, soll die Datenbank leicht zu erweitern sein. Des Weiteren ist der Einsatz eines Linux-Betriebssystems als Server vorgesehen, weshalb die Datenbank unter Linux lauhig sein muss.
unter horizontalen Skalieren wird das Einbinden eines weiteren Knoten verstanden, welcher einen Teil der Last/Daten bernimmt [EFHB10]
Benjamin Ldicke
Seite 16 von 95
4 Anforderungsanalyse
In diesem Kapitel wird untersucht, welche Art von Daten in der Datenbank gespeichert werden und wie diese in Beziehung zueinander stehen. Aufgrund dessen, dass unterschiedliche Daten ungleiche Anforderungen an die Datenbank stellen, wird dabei die Auswahl mglicher Datenbanken weiter eingegrenzt [EFHB10, S. 277]. Die aus diesem Kapitel resultierenden Ergebnisse sind auerdem Grundlage fr das zu erstellende Datenmodell.
4.1 Miniwelt
Als Miniwelt bezeichnet man den zu modellierenden Teilausschnitt der realen Welt, welcher in der Datenbank abgebildet werden soll [Sau02, S. 19]. Ziel der Miniwelt ist das Identizieren von Objekten sowie das Abbilden deren Beziehung fr das zu erstellende System. Anhand des Diagramms in Abbildung 4.1 wird die Miniwelt (Fakultt Informatik) dargestellt. Das Objekt Veranstaltung kann eine Vorlesung, bung oder ein sonstiges Event sein, welches von Gruppen, Klassen oder einzelnen Studenten besucht werden kann. Ist die Veranstaltung eine Vorlesung oder eine bung, wird diese von einem Dozenten gehalten. Weil es auch mglich ist, dass Tutorien nicht nur von Dozenten gehalten werden, knnen auch Studenten Tutorien als Veranstaltung anlegen. Des Weiteren hat eine Veranstaltung einen Ort an dem diese durchgefhrt wird. Der Ort wird durch einen Raum in einem Gebude beschrieben. Um Informationen innerhalb der Fakultt zu verbreiten, knnen Nachrichten von Dozenten und Studenten verfasst werden, die einzelne Gruppen oder Klassen der Fakultt betreen. Ein Student und Dozent hat die Mglichkeit diese Nachrichten zu lesen und zu kommentieren. Anhand der Miniwelt ergeben sich Anwendungsflle, welche im nchsten Abschnitt in Anwendungsfalldiagrammen abgebildet sind.
4.2 Interaktion zwischen Anwender und System

Die Miniwelt ist eine abstrakte Darstellung des Informations- und Planungssystem der Fakultt Informatik. In den folgenden Abbildungen 4.2 und 4.3 sind die Anwendungsfalldiagramme dargestellt, welche die zuknftig mglichen Interaktionen zwischen den Anwendern und dem Datenbank-Service beschreiben. Zu beachten ist, dass wie in der Miniwelt nicht die Teilprojekte von spirit@fhs, sondern Dozenten und Studenten als Akteure zu verstehen sind. Zustzlich gibt es einen Administrator, welcher keine Einschrnkungen bei der Nutzung des Datenbank-Service hat. Die Datenbank ist in diesen Abbildungen nicht aufgenommen, da diese vom Datenbank-Service gekapselt wird und keine direkte Interaktion zwischen den Ak-
Benjamin Ldicke
Seite 17 von 95
4. Anforderungsanalyse
Abbildung 4.1: Eigene Darstellung Planungssystem
der
Miniwelt
fr
Informations-
und
teuren und der Datenbank stattnden soll. In dem Anwendungsfalldiagramm 4.2 ist zu erkennen, dass die Akteure Student und Dozent, die gleichen Rechte haben um Veranstaltungen, Kommentare und Nachrichten zu verwalten. Diese Rechte beinhalten die Anwendungsflle Erstellen, Lesen, Bearbeiten und Lschen. Damit ein willkrliches Bearbeiten und Lschen von Objekten unterbunden werden kann, sind diese Anwendungsflle auf den Erzeuger des Objekts beschrnkt. Das Anwendungsfalldiagramm 4.3 zeigt den zustzlichen Akteur Admin. Ein Admin hat keine Einschrnkungen und kann den Datenbank-Service somit im vollen Umfang nutzen. ber den Admin ist es mglich neue Mitglieder in der Datenbank aufzunehmen oder diese zu lschen. Ferner kann der Admin Gebude und Rume in der Datenbank verwalten. Dozenten und Studenten haben nur die Mglichkeit ihre eigenen Proldaten zu bearbeiten oder anzeigen zu lassen.
Benjamin Ldicke
Seite 18 von 95
Abbildung 4.2: Eigene Darstellung Einschrnkungen
des
Anwendungsfaldiagramms
ohne
Benjamin Ldicke
Seite 19 von 95
Abbildung 4.3: Eigene Darstellung des Anwendungsfaldiagramms mit Administrator als Akteur
Benjamin Ldicke
Seite 20 von 95
4.3 Beurteilung
In diesem Kapitel wurden die zu speichernden Daten analysiert. Dabei wurde festgestellt, dass viele Beziehungen zwischen den Objekten bestehen. Es handelt sich demnach nicht um eine lose Datenmenge, wie sie zum Beispiel beim Loggen von Ereignissen anfllt. Eine Datenbank, die Beziehungen gut abbilden kann, ist als Speicherlsung zu bevorzugen. Die nach Meinung des Autors geeigneten Datenbanken werden im Kapitel 5 vorgestellt.
Benjamin Ldicke
Seite 21 von 95
5 Evaluierung mglicher Datenbanken

In dem vorherigen Abschnitt wurden die Objekttypen bestimmt und grob speziziert, wie diese miteinander in Beziehung stehen. In diesem Kapitel werden drei Datenbanken untersucht, inwiefern sich diese fr das neue Informations- und Planungssystem eignen. Grundlagen fr die Beurteilung sind die vorher festgelegten Anforderungen an die Datenbank, die Abfragemglichkeiten und wie Beziehungen in der Datenbank abgebildet werden knnen. Zuerst wird die Graphen-Datenbank OrientDB, dann die Key/Value-Datenbank Riak und zum Schluss die relationale Datenbank PostgreSQL untersucht. Zu erwhnen ist, dass Riak und OrientDB keine reinen Key/Value- bzw. Graphen-Datenbanken darstellen. Beide besitzen auch Eigenschaften anderer Datenbankkategorien. PostgreSQL hingegen ist eine reine relationale Datenbank. Dennoch lassen sich durch Plugins neue Funktionen hinzufgen.
5.1 OrientDB
OrientDB ist eine Graphen-Datenbank, welche 1997 in C++ programmiert und spter in Java reimplementiert wurde. Die derzeitig aktuelle Versionsnummer ist die 1.0rc3 (stand 19.07.2011). In dieser Master-Thesis wurde die Evaluierung der Datenbank in der Version 0.9.25 durchgefhrt. Das Ziel von OrientDB ist es die besten Eigenschaften anderer Datenbanken in sich zu vereinen und somit ein breites Anwendungsspektrum abzudecken. Daher ist es mglich OrientDB als Graphen-Datenbank, Objekt-Datenbank oder Dokumenten-Datenbank zu nutzen [Ori]. Laut [Ori] ist OrientDB fhig bis zu 150.000 Eintrge pro Sekunde zu speichern, was auf das zugrunde liegende Datenmodell zurckzufhren ist. Fr die Administration von OrientDB stehen die Werkzeuge OrientDB-Studio1 und OrientDB-Console2 zur Verfgung. In diesem Abschnitt wird das zugrundeliegende Datenmodell von OrientDB erlutert und an Beispielen anschlieend die CRUD-Operationen3 vorgestellt. Abschlieend wird gezeigt, wie die Replikation funktioniert und eine Bewertung von OrientDB vorgenommen.
1 2
http://code.google.com/p/orient/wiki/OrientDB_Studio http://code.google.com/p/orient/wiki/ConsoleCommands 3 (C)reate, (R)ead, (U)pdate, (D)elete
Benjamin Ldicke
Seite 22 von 95
5. Evaluierung mglicher Datenbanken
5.1.1 Datenmodell
Das zugrundeliegende Datenmodell von OrientDB ist das sogenannte PropertyGraph-Modell [EFHB10, S. 237]. Ein Property Graph ist ein gerichteter, multirelationaler Graph. Die Knoten und Kanten dieses Graphen bestehen aus Objekten und darin eingebetteten Eigenschaften (Properties) [EFHB10, S. 173]. Ein Property entspricht dabei einen Schlssel/Wert-Paar. Wie in dem Zitat erwhnt, sind Knoten und Kanten Objekte, was einen leichteren Umgang mit objektorientierten Programmiersprachen ermglicht soll. Zwischen zwei Knoten knnen beliebig viele Kanten existieren, sofern diese unterschiedliche Typen aufweisen. In OrientDB gibt es die Mglichkeit ein Schema fr die Kanten und Knoten zu denieren. Dabei ist es nicht relevant wie viele Schemata existieren. Ferner kann auf ein Schema verzichtet oder ein Mix aus beiden verwendet werden, um die Daten exibel zu speichern.
5.1.2 Beispielanwendung
Damit die CRUD-Operationen vorgestellt werden knnen, wird in diesem Abschnitt dargestellt, wie eine Datenbank mit OrientDB erstellt wird. Dabei wird die zugrundeliegende Struktur beschrieben und ein Schema angefertigt. Die Beispielanwendung lehnt sich dabei an die Demo-Datenbank von OrientDB an. In diesem Szenario sollen zu einer Firma die Adressen und Mitarbeiter gespeichert werden, wobei Mitarbeiter wiederum mehrere Adressen besitzen knnen. Eine Adresse beinhaltet einen Straennamen, eine Stadt und ein Land. Inbetriebnahme Nachdem OrientDB heruntergeladen, entpackt und gestartet wurde, kann ber das Konsolenwerkzeug mit dem folgenden Befehl eine neue Datenbank angelegt werden: create database remote:localhost/beispieldb user password local Das Schlsselwort remote beschreibt das Protokoll welches angibt, dass auf die Datenbank ber eine TCP/IP Verbindung zugrien wird. Der Name der neuen Datenbank lautet beispieldb und steht vor dem Host localhost. Zum Anlegen einer Datenbank bentigt man in OrientDB Administratorrechte, welche in der Datei orientdb-server-config.xml festgelegt sind. Die in dieser Datei hinterlegten Nutzerdaten werden beim Herunterladen von OrientDB automatisch generiert. Somit ist sichergestellt, dass jede Distribution andere Zugangsdaten hat. Das Schlsselwort local legt fest, dass die neue Datenbank auf der Festplatte abgelegt wird. Das hat den Vorteil, dass bei einem Neustart oder Ausfall des Systems keine gespeicherten Daten verloren gehen. Wird statt local das Schlsselwort memory angegeben, werden alle Daten im Hauptspeicher hinterlegt, was einen Performancegewinn zur Folge hat, jedoch keine dauerhafte Persistenz sicherstellt. Nachdem die Datenbank angelegt wurde kann eine Verbindung ber folgenden Befehl hergestellt werden: connect remote:localhost/beispielDB user password
Benjamin Ldicke
Seite 23 von 95
Ist die Verbindung hergestellt, knnen mittels des Schlsselwortes help alle untersttzten Befehle angezeigt werden. Soll ein Schema fr einen Knoten in OrientDB angelegt werden, muss eine sogenannte Class mit folgendem Befehl erstellt werden: create class <classname> Der Platzhalter <classname> muss durch den Namen der anzulegenden Klasse ersetzt werden. Aufgrund dessen, dass das Schema bisher nicht deniert ist, ist eine schemalose Verwendung mglich. Damit jedoch die Typsicherheit gewhrleistet ist, muss die Class durch folgenden Befehl mit Eigenschaften gefllt werden: create property <classname>.<propertyname> <type> Mit diesem Befehl wird der Class <classname> die Eigenschaft <propertyname> mit dem Typ <type> zugewiesen. Die erzeugten Eigenschaften sind keine Pichtfelder und mssen somit beim Einfgen von Daten nicht zwingend angegeben werden. Ist das Schema erstellt, ist es mglich bestimmte Eigenschaften zu indizieren. Durch einen Index knnen Duplikate vermieden und eine performante Suche erreicht werden: create index <classname>.<propertyname> <indextype> Als Indextyp werden in OrientDB folgende Typen unterschieden (siehe Tabelle 5.1). unique not unique full-text erlaubt keine Duplikate erlaubt Duplikate (ist Standard) ermglicht das Suchen nach bestimmten Schlagwrtern in einer Eigenschaft Tabelle 5.1: Indextypen in OrientDB In dem Listing 5.1 sind alle Befehle aufgelistet, um das Schema fr die Beispielanwendung zu erstellen. create create create create create create create create create create create create create create create create c l a s s country p r o p e r t y c o u n t r y . name S t r i n g property country . population I n t e g e r class city p r o p e r t y c i t y . name S t r i n g property c i t y . population Integer property c i t y . country l i n k country c l a s s address property address . s t r e e t String property address . c i t y l i n k c i t y c l a s s employee p r o p e r t y employee . name S t r i n g c l a s s company p r o p e r t y company . name S t r i n g class livesIn c l a s s worksIn Listing 5.1: Erstellen eines Schemas in OrientDB
Benjamin Ldicke
Seite 24 von 95
Der Typ linklist <supportedtyp> erlaubt das Speichern einer Liste von Knoten und entspricht einer 1:N Beziehung, wobei der Typ link <supportedtyp> eine 1:1 Beziehung abbildet. Dabei wird ausschlielich die ID des anderen Knoten gespeichert. Somit ist OrientDB in der Lage Beziehungen zwischen Knoten abzubilden und kann auch bestehende Daten aus relationalen Datenbanken importieren. Ferner erlaubt OrientDB, durch den Typ embeddedlist <supportedtyp>, das Speichern von Mengenattributen. Die gespeicherten Daten sind somit kein Verweis auf andere Tupel, sondern sind ausschlielich in dieser Liste gespeichert. Die beiden Classes livesIn und worksIn sind notwendig, um ein Schema fr die spter zu erstellenden Kanten bereitzustellen. Das erstellte Schema kann mit folgendem Befehl angeschaut werden: info class <classname> Nachdem das Schema in den Classes erzeugt wurde, knnen Daten in OrientDB gespeichert werden. Die Daten werden dabei in sogenannten Clustern hinterlegt, welche beim Anlegen von Classes automatisch erzeugt werden. Durch diese Trennung ist es mglich einem Cluster ein anderes Schema zuzuweisen. Ferner kann die Schemaanpassung auch ber die Java-API vorgenommen werden.
5.1.3 CRUD
Im vorherigen Abschnitt wurde gezeigt, wie ein Schema in OrientDB erstellt werden kann. Im folgenden wird beschrieben, wie die erstellten Cluster mit Daten gefllt, diese wieder gelesen, verndert oder gelscht werden knnen. Fr den Zugri auf das erstellte Modell wird die Java-API von OrientDB verwendet. Ferner besteht die Mglichkeit ber REST oder die DSL (domain specic language) Gremlin4 auf die Daten zuzugreifen. Eine API fr Scala existiert nicht. Lediglich der Hinweis, dass mit Hilfe der Bibliotheken scala.collection.JavaConverters._ und scala.collection.JavaConversions._, Scala-Collections in die von OrientDB erwarteten Java-Collections, konvertiert werden mssen.
Create Im Listing 5.2 ist ein Auszug des Quellcodes abgebildet, welcher Daten erzeugt und in Clustern abspeichert. Der komplette Quellcode ist auf der beiliegenden CD-ROM hinterlegt.
1
2 3 4 5
val db : OGraphDatabase = new OGraphDatabase ( " remote : 192.168.178.42 : 2424/ beispieldb " ) . open ( " admin " , " admin " ) def create () = { val germany : ODocument = db . createVertex ( " country " ) germany . field ( " name " , " Germany " ) germany . field ( " population " , 81000000)
4
http://www.tinkerpop.com
Benjamin Ldicke
Seite 25 von 95
6 7 8
val microsoft : ODocument = db . createVertex ( " company " ) microsoft . field ( " name " , " Microsoft Headquarter Germany " ) val berlin : ODocument = db . createVertex ( " city " ) berlin . field ( " name " , " Berlin " ) berlin . field ( " population " , 3000000) berlin . field ( " country " , germany ) val petrasAddress : ODocument = db . createVertex ( " address ") petrasAddress . field ( " street " , " Kreuzberger Str . " ) petrasAddress . field ( " city " , berlin ) val petra : ODocument = db . createVertex ( " employee " ) petra . field ( " name " , " Petra " ) val petrasAddressEdge = db . createEdge ( petra , petrasAddress , " livesIn " ) [...] db . save ( germany ) db . save ( berlin ) db . save ( petrasAddress ) db . save ( petra ) db . save ( petrasAddressEdge ) db . setRoot ( " graph " , microsoft ) db . close } Listing 5.2: Create-Operation in OrientDB mit Java-API In Zeile 1 ist zu erkennen, wie eine Verbindung mit der Datenbank hergestellt wird. Wichtig dabei ist, dass eine Instanz von OGraphDatabase und nicht von ODatabaseGraphTx erzeugt wird. Letztere wird in den nchsten Versionen von OrientDB nicht mehr untersttzt. Dem Konstruktor von OGraphDatabase wird die Adresse der Datenbank mitgegeben und diese mittels der Methode open()genet. Ferner wird ber die Methode vertex(<classname>) ein neuer Knoten unter Bercksichtigung des angegebenen Schemas erzeugt und eine Instanz von ODocument zurckgegeben. Dieser Instanz knnen Schlssel/Wert-Paare bergeben werden, um den Knoten mit Daten zu fllen. Wie zu erkennen ist, wird dem Attribut country des Knoten berlin das Objekt germany bergeben, um eine 1:1 Beziehung darzustellen. Damit dem Objekt petra eine Adresse zugewiesen werden kann, muss eine
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29 30 31 32 33 34 35
Benjamin Ldicke
Seite 26 von 95
Kante zwischen petra und petrasAddress erstellt werden. Dafr muss die Methode createEdge(<sourcevertex>, <destinationvertex>, <classname>) aufgerufen werden. Fr den Platzhalter <sourcevertex> wird der Startknoten und fr <destinationvertex> der Zielknoten der Kante angegeben. Ferner kann dieser Kante eine Class bergeben werden, welche ebenfalls mit Schlssel/Wert-Paaren gefllt werden kann. Um durch den Graphen von einem bestimmten Knoten aus zu traversieren, gibt es die Mglichkeit einen Startknoten festzulegen. In diesem Beispiel ist das der Knoten microsoft mit der Bezeichnung graph. Das Ergebnis nach dem Erstellen der Knoten und Kanten ist in Abbildung 5.1 dargestellt.
Abbildung 5.1: Eigene Darstellung des PropertyGraph nach dem Aufruf der Methode create()
Read In diesem Abschnitt wird gezeigt, wie mittels der Java-API die gespeicherten Daten aus der Datenbank ausgelesen werden knnen. Die in Listing 5.3 auskommentierten
Benjamin Ldicke
Seite 27 von 95
Codezeilen sollen alle ausgehenden Kanten des Vertex root zurckgeben. Aufgrund eines Fehlers bei der bergabe des Vertex root, ist dieser Code jedoch nicht ausfhrbar. Ferner erzeugt das Java-Beispiel auf der Projekt-Homepage5 ebenfalls eine IllegalArgumentException. Eine andere Mglichkeit die Datenbank abzufragen, ist eine SQL-Abfrage mittels der Klasse OSQLSynchQuery zu erstellen, wie es in Zeile 6 zu erkennen ist. Das Fragezeichen in der SQL-Abfrage dient als Platzhalter, dessen Wert beim Ausfhren in Zeile 8 bergeben wird. In diesem Fall werden alle Mitarbeiterinnen mit dem Namen Petra in einer ArrayList gespeichert und danach auf der Konsole ausgegeben. Zu erwhnen ist, dass die Methode foreach nicht Bestandteil von java.util.ArrayList ist. Aufgrund der importierten Bibliothek scala.collection.JavaConversions._ ndet eine implizite Konvertierung in eine Scala-Collection statt, so das foreach aufgerufen werden kann.
1 2 3 4 5 6
def read () = { // Erzeugt IllegalArgumentException // val root : ODocument = db . getRoot (" graph ") // val outEdges = db . getOutEdges ( root ) val query3 : OSQLSynchQuery [ ODocument ] = new OSQLSynchQuery [ ODocument ]( " select from employee where name = ? " ) query3 . setDatabase ( db ) val res3 : ArrayList [ ODocument ] = query . execute ( " Petra ") res3 . foreach ( document = > println ( document . field [ String ]( " name " ) ) ) val query2 : OSQLSynchQuery [ ODocument ] = new OSQLSynchQuery [ ODocument ]( " select from employee where all () traverse (0 , -1) (@ class = country and name = USA ) " ) query2 . setDatabase ( db ) val res2 : ArrayList [ ODocument ] = query2 . execute () res2 . foreach ( document = > println ( document . field [ String ]( " name " ) ) ) db . close } } Listing 5.3: Read-Operation in OrientDB mit Java-API Ferner kann mittels Graphentraversierung nach Daten im Graphen gesucht werden. In Listing 5.3 Zeile 11, ist eine SQL Abfrage abgebildet, die alle Mitarbeiter zurckgibt, welche mit dem Land USA in Verbindung gebracht werden knnen. Der Operator all() gibt an, dass alle Attribute des Clusters employee fr die Tra5
7 8
10 11
12 13 14
15 16 17 18
http://code.google.com/p/orient/wiki/GraphDatabaseRaw)
Benjamin Ldicke
Seite 28 von 95
versierung einbezogen werden. Dies beinhaltet ebenfalls die Attribute INEDGES und OUTEDGES6 . Der Operator traverse(<min>, <max>) gibt die Mindest- und Maximaltiefe an, auf welche die darauf folgende Bedingung zutreen muss, um ein Ergebnis zurckzugeben. Wird als Maximaltiefe eine -1 angegeben, gilt keine Tiefenbeschrnkung. Durch den and Operator werden die Bedingungen @class=country und name=USA miteinander verbunden. Dadurch wird erreicht, dass nur die Attribute name aus der Class country die Bedingungen erfllen knnen.
Update Um zu demonstrieren wie ein Knoten gendert werden kann, wird in diesem Abschnitt die Einwohnerzahl des Knoten berlin korrigiert. In Listing 5.4 Zeile 2 bis 10, ist abgebildet wie ein Update durch die Java-API vorgenommen werden kann. Beim Versuch eine neue Kante zwischen zwei Knoten zu erstellen, kommt es zu einer ClasscastException, sobald die Methode createEdge() in Zeile 22 aufgerufen wird. Dem Autor ist nicht bekannt, wie dieser Fehler vermieden werden kann. Der Code, welcher zu diesem Fehler fhrt, ist in Listing 5.4 auskommentiert und von Zeile 12 bis 27 abgebildet.
1 2
3 4 5 6 7 8 9 10 11 12 13
def update () = { val query : OSQLSynchQuery [ ODocument ] = new OSQLSynchQuery [ ODocument ]( " select from city where name = Berlin " ) query . setDatabase ( db ) val res : ArrayList [ ODocument ] = query . execute () if (! res . isEmpty ) { val berlin = res . head berlin . field ( " population " , 5000000) db . save ( berlin ) } db . close () // // Erzeugt ClasscastException val query : OSQLSynchQuery [ ODocument ] = new OSQLSynchQuery [ ODocument ](" select from employee where name = Steve ") val query2 : OSQLSynchQuery [ ODocument ] = new OSQLSynchQuery [ ODocument ](" select from company where name = Microsoft Headquarter Germany ") query . setDatabase ( db ) query2 . setDatabase ( db ) val res : ArrayList [ ODocument ] = query . execute () val res2 : ArrayList [ ODocument ] = query2 . execute () if (! res . isEmpty && ! res2 . isEmpty ) {
14
//
15 16 17 18 19
// // // // //
6
diese Attribute verweisen auf die eingehenden und ausgehenden Kanten eines Knoten
Benjamin Ldicke
Seite 29 von 95
5. Evaluierung mglicher Datenbanken // // //
20 21 22
23 24 25 26 27 28
val steve = res . head val microsoft = res2 . head val edge = db . createEdge ( steve , microsoft , " worksIn ") // db . save ( steve ) // db . save ( microsoft ) // db . save ( edge ) // } // db . close () } Listing 5.4: Update-Operation in OrientDB mit Java-API
Delete Damit ein Knoten entfernt werden kann muss sichergestellt werden, dass keine Kanten zu anderen Knoten existieren. OrientDB bietet mit der Methode removeVertex() die Mglichkeit zustzlich alle Kanten zu entfernen, welche auf den zu lschenden Knoten verweisen. Der Code in Listing 5.5 produziert ebenfalls, wie das Hinzufgen einer neuen Kante, eine ClasscastException. Ersetzt man die Methode removeVertex() durch die Methode delete() wird der Knoten entfernt. Jedoch bleiben die Kanten zu dem alten Knoten erhalten, weshalb diese vorher gelscht werden mssen.
1 2
3 4 5 6 7 8 9 10 11 12
def delete () = { val query : OSQLSynchQuery [ ODocument ] = new OSQLSynchQuery [ ODocument ]( " select from employee where name = Steve " ) query . setDatabase ( db ) val res : ArrayList [ ODocument ] = query . execute () if (! res . isEmpty ) { val steve = res . head // Erzeugt Classcastexception // db . removeVertex ( steve ) db . delete ( steve ) } db . close () } Listing 5.5: Delete-Operation in OrientDB mit Java-API
5.1.4 Backup
Bei einem Totalausfall des Systems ist es notwendig die Daten wieder herstellen zu knnen. Dies kann laut Meinung des Autors auf zwei Arten realisiert werden. Zum einen durch das Spiegeln der Festplatte auf den die Datenbank installiert ist und
Benjamin Ldicke
Seite 30 von 95
zum anderen durch das Erstellen eines Backups der Datenbank. Letztere Variante hat den Vorteil, dass nicht nur die Daten gesichert sind, sondern dass auch bei einem Versionswechsel die Daten in die neue OrientDB-Version importiert werden knnen, ohne Daten zu verlieren. Aufgrund dessen erfolgt der Export in eine JSON-Datei. Ist der Benutzer ber OrientDB-Console bei der zu sichernden Datenbank eingeloggt, wird mit folgendem Befehl ein Backup erstellt: export database <dateiname>.export Die dabei erstellte Datei wird im Unterordner /bin von OrientDB abgelegt. Soll ein Backup wiederhergestellt werden, muss dieses in eine genete Datenbank importiert werden. Fr einen erfolgreichen Import muss die Datei einen gltigen JSON-String beinhalten. Folgender Befehl importiert Daten aus einer JSON-Datei: import database <dateiname>.export
5.1.5 Skalierung und Replikation

Fr die Skalierung und Replikation unter OrientDB, muss die Datei orientdb-server-config.xml im Verzeichnis /config angepasst werden. Dabei ist darauf zu achten, dass die Parameter name und security.key fr alle Knoten im Cluster die jeweils gleichen Werte haben. Wurden beide Parameter angepasst, muss man sich ber OrientDB-Console, bei dem Knoten mit der zu replizierenden Datenbank, als root einloggen und folgenden Befehl eingeben: share database <db-name> <db-user> <db-password> <server-name> <mode> Als <db-name> muss der Name der zu replizierenden Datenbank angegeben werden und ber <mode> kann man durch synch oder asynch festlegen, ob der Datenabgleich synchron oder asynchron stattnden soll. Fr den Platzhalter <server-name> ist der Knoten anzugeben, auf dem die Datenbank repliziert werden soll. OrientDB nutzt bei der Replikation das sogenannte Master-Slave Prinzip, wobei es einen Master und mehrere Slave gibt. Die Kommunikation der Clients erfolgt dabei ausschlielich ber den Master, welcher daraufhin die Lastverteilung und Replikation steuert. Um die Datenbank beispieldb synchron zu replizieren, knnte der Befehl folgendermaen aussehen: share database beispieldb admin admin debian1.local:2425 synch
5.1.6 Bewertung
Vorteile: horizontale Skalierung und Replikation ist einfach umzusetzen Backups sind versionsunabhngig es knnen komplexe Beziehungen abgebildet werden untersttzt erweiterte Untermenge von SQL, so dass auch Graphen durchlaufen werden knnen
Benjamin Ldicke
Seite 31 von 95
Nachteile: Java-API ist laut Meinung des Autors nicht fehlerfrei und stimmt nicht mit der Dokumentation berein die Einbindung der Abfragesprache Gremlin in ein Java-Programm ist nicht dokumentiert und wurde deswegen in dieser Master-Thesis nicht behandelt die auf der Homepage verentlichten Java-Beispiele sind nicht fehlerfrei und somit nicht einfach anzuwenden OrientDB-Console untersttzt noch nicht alle grundlegenden Befehle wie zum Beispiel das ndern einer Kante oder eines Knoten Wie an den Vor- und Nachteilen zu erkennen ist, wre OrientDB laut Meinung des Autors eine gute Datenbank fr das neue Informations- und Planungssystem. Jedoch ist die Dokumentation nicht ausreichend und die Java-API fehlerhaft, was ein ezientes programmieren erschwert.
5.2 Riak
Riak gibt es seit dem Jahr 2007 und wurde von Basho Technologies in den Programmiersprachen Erlang, C und JavaScript entwickelt. Derzeitig liegt Riak in der Version 0.14.2 vor (stand 08.08.2011). Fr die Evaluierung in dieser Master-Thesis wurde Riak in der Version 0.14.1 verwendet und unter Debian Squeeze 64 Bit installiert. Riak lsst sich in die Kategorie der Key/Value-Datenbanken einordnen und speichert Daten ausschlielich auf der Festplatte und nicht im Hauptspeicher. Demzufolge ist eine hhere Datensicherheit gewhrleistet, welche jedoch die Performance negativ beeintrchtigt. Laut [Riab] wird deshalb die Verwendung von RAID-Systemen oder SSDs empfohlen, um schnelle Ein-/Ausgabeoperationen durchzufhren. In den folgenden Abschnitten wird zunchst auf das Datenmodell von Riak eingegangen. Ferner werden anhand eines Beispiels die CRUD-Operationen mittels der Java-API vorgestellt. Danach wird gezeigt wie die horizontale Skalierung sowie die Replikation und das Erstellen von Backups durchgefhrt werden knnen. Abschlieend ndet eine Bewertung von Riak statt.
5.2.1 Datenmodell
Riak gehrt zu den Key/Value-Datenbanken, obwohl im eigentlichen Sinn Dokumente, wie bei Dokumenten-Datenbanken, gespeichert werden. Eine Vorgabe in welchem Format die Daten gespeichert werden sollen gibt es nicht, jedoch wird JSON laut [EFHB10, S. 159] derzeitig am besten untersttzt. Um Daten in Riak strukturiert abzulegen gibt es sogenannte Buckets in denen Keys hinterlegt sind, welche wiederum auf Dokumente verweisen. In Abbildung 5.2 ist dieses Prinzip verdeutlicht. Was Riak von anderen Dokumenten- oder Key/Value-Datenbanken unterscheidet ist die Mglichkeit innerhalb der Dokumente Verlinkungen zu anderen Dokumenten abzubilden. Somit ist es mglich Riak einzusetzen, wenn Beziehungen zwischen Daten von Bedeutung sind.
Benjamin Ldicke
Seite 32 von 95
Abbildung 5.2: Eigene Darstellung des Namensraum in Riak in Anlehnung an [EFHB10, S. 157]
5.2.2 CRUD
In diesem Abschnitt wird erlutert wie die Beispielanwendung mittels der Java-API umgesetzt werden kann. Diese API nutzt den Apache http-Client, um Daten zwischen Riak und dem Client auszutauschen. Die zwei lteren Community-Projekte Riakka7 und Ryu8 sind eine Mglichkeit Riak mittels Scala zu nutzen. Aufgrund dessen, dass diese Projekte schon lnger nicht weiterentwickelt wurden, wird in dieser Maste-Thesis auf eine Evaluierung dieser APIs verzichtet. Ferner kann ber eine REST-Schnittstelle mit Riak kommuniziert werden. Zum Vorstellen der CRUD-Operationen wird die gleiche Beispielanwendung umgesetzt, wie in Abschnitt 5.1.2 beschrieben. Create Um eine Verbindung mit Riak herzustellen, muss eine Instanz von RiakClient wie folgt angelegt werden: riakClient = new RiakClient("http://192.168.178.33:8098/riak") Anders als bei OrientDB, wo die Adresse des Master-Knoten bergeben werden muss, kann in Riak ein beliebiger Knoten im Cluster adressiert werden. Das ist mglich, da in Riak jeder Knoten gleichwertig ist [EFHB10, S. 166]. Ein Auszug der Create-Operation mittels der Java-API, ist in Listing 5.6 dargestellt. Dabei ist aullig, dass zuvor kein Schema festgelegt wurde, um Typsicherheit zu gewhrleisten. Dies liegt daran, weil Riak keine Vorgaben ber die zu speichernden Daten macht. Aufgrund dessen, knnen zum Beispiel einfacher Text, XML, JSON oder Binrdaten abgelegt werden. In diesem Beispiel wird JSON-Text abgespeichert.
1 2
3 4
def create () = { val microsoft = new RiakObject ( " company " , " Microsoft " ) microsoft . setContentType ( " application / json " ) microsoft . addLink ( new RiakLink ( " address " , " Microsoft " , " livesIn " ) ) val germany = new RiakObject ( " country " , " Germany " ) germany . setContentType ( " application / json " )
7 8
5 6 7
https://github.com/timperrett/riakka https://github.com/softprops/ryu
Benjamin Ldicke
Seite 33 von 95
8 9 10 11 12
germany . setValue ( " {\" population \" : 81000000} " ) val berlin = new RiakObject ( " city " , " Berlin " ) berlin . setContentType ( " application / json " ) berlin . addLink ( new RiakLink ( " country " , " Germany " , " isIn " ) ) val microsoftsAddress = new RiakObject ( " address " , " Microsoft " ) microsoftsAddress . setContentType ( " application / json " ) microsoftsAddress . setValue ( " {\" street \" : \" Hauptstrasse \"} " ) microsoftsAddress . addLink ( new RiakLink ( " city " , " Berlin " , " isIn " ) ) val petra = new RiakObject ( " employee " , " Petra " ) petra . setContentType ( " application / json " ) petra . addLink ( new RiakLink ( " address " , " Petra " , " livesIn " ) ) petra . addLink ( new RiakLink ( " company " , " Microsoft " , " worksIn " ) ) riakClient . store ( microsoft ) riakClient . store ( petra ) riakClient . store ( microsoftsAddress ) riakClient . store ( berlin ) riakClient . store ( germany ) } Listing 5.6: Create-Operation in Riak mit Java-API In der Zeile 2 wird ein neues Objekt der Klasse RiakObject angelegt. Dabei wird dem Konstruktor der Klasse, der Name des Bucket und des Key bergeben, unter dem die Daten abgelegt werden sollen. Wird zweimal der gleiche Bucket und Key zum Speichern genutzt, werden die vorher angelegten Daten berschrieben sofern keine Siblings9 erlaubt sind. Wie bereits erwhnt macht Riak keine Vorgaben ber die zu speichernden Daten. In Zeile 7 wird der Content-Type des httpHeader gesetzt. Das ist von Vorteil, da beim Abrufen der Daten berprft werden kann, um welche Art von Daten es sich handelt und wie diese zu verarbeiten sind. Die Methode setValue() fllt das RiakObject mit Daten. In Zeile 8 ist dargestellt, wie als JSON-Text die Einwohnerzahl von Deutschland bergeben wird. Um eine Verbindung zwischen zwei Dokumenten aufzubauen, muss die Methode addLink(<bucket>, <key>, <tag>) aufgerufen werden. Als Parameter werden der Bucket und der Key des Ziel-Dokuments angegeben. Der Platzhalter <tag> bestimmt den Namen der Verbindung. In Zeile 22 wird eine Verbindung zwischen der Instanz
9
13 14
15 16
17
18 19 20 21
22
23 24 25 26 27 28 29
Siblings sind in Riak unterschiedliche Versionen von Daten, welche angelegt werden wenn mehrmals unter demselben Bucket und Key gespeichert wird
Benjamin Ldicke
Seite 34 von 95
petra und der Instanz microsoft, mit dem Namen worksIn, erstellt. Dabei soll verdeutlicht werden, dass Petra fr Microsoft arbeitet. In Riak sind solche Verbindungen unidirektional. Semantisch bedeutet dass, das Microsoft keine Kenntnisse ber seine Mitarbeiter hat. Ferner kann ein Verweis auf einen Bucket und Key bestehen, ohne das Daten innerhalb dieser gespeichert wurden oder diese berhaupt existieren, wie in den Zeilen 24 bis 28 zu sehen ist. Read Nachdem die Datenbank mit Daten gefllt wurde, knnen diese wieder mittels der Java-API Abgerufen werden. In diesem Abschnitt wird dabei auf das abrufen eines gewhnlichen JSON-Text sowie dessen Siblings eingegangen. Ferner wird gezeigt, wie mit dem sogenannten Link-Walking die Verbindungen zwischen Dokumenten traversiert werden knnen und komplexe Abfragen mittels Map/Reduce zu formulieren sind. Abfrage und Siblings Das einfache Abfragen von Daten aus Riak ist in Listing 5.7 abgebildet.
1
2 3 4 5 6 7 8 9 10 11 12
val res : FetchResponse = riakClient . fetch ( " country " , " Germany " ) if ( res . hasObject ) { val germany : RiakObject = res . getObject println ( " Value : " + germany . getValue ) } if ( res . hasSiblings ) { val germanySiblings = res . getSiblings for ( sibling <- germanySiblings ) { println ( " Value " + sibling . getValue ) } } Listing 5.7: Read-Operation in Riak mit Java-API Das Abrufen der Daten wird mittels der Methode fetch(<bucket>, <key>) realisiert. In der Zeile 1 bekommt diese Methode den Bucket country und den Key Germany bergeben, woraufhin eine FetchResponse zurckgegeben wird. In der Zeile 2 wird geprft, ob unter diesen Parametern Daten hinterlegt sind. Ist die Bedingung erfllt, wird durch den Aufruf der Methode getObject() das zuvor gespeicherte RiakObject zurckgeben und mittels der Methode getValue() der Inhalt dessen auf der Konsole ausgegeben. Sofern unter dem Bucket country und dem Key Germany mehrmals ein RiakObject abgespeichert wurde, exisitieren Siblings. Um zu Prfen ob Siblings vorhanden sind, wird die Methode hasSiblings() aufgerufen. Gilt die Bedingung in Zeile 7 als erfllt, knnen durch die Methode getSiblings() alle vorhandenen Siblings abgerufen werden. In den Zeilen 9 und 10 wird der Inhalt des jeweiligen Sibling auf der Konsole ausgegeben.
Benjamin Ldicke
Seite 35 von 95
Link-Walking Um die in Listing 5.7 erstellten Verweise zu traversieren, gibt es in Riak die Mglichkeit des sogenannten Link-Walking. In Listing 5.8 ist dargestellt, wie das in Riak umgesetzt ist. Wie bei den einfachen Abfragen wird in Zeile 1 das RiakObject geholt. Mchte man nun ber die Verweise traversieren, muss die Methode walk(<bucket>, <tag>, <keep>) aufgerufen werden, wie es in Zeile 4 zu sehen ist. Der Platzhalter <bucket> gibt an, in welchem Bucket sich die verlinkten Daten benden. Durch den Platzhalter <tag> wird der Name des Verweises angegeben und der Platzhalter <keep> legt fest, ob die ermittelten Daten in das Ergebnis einieen. Dies ist von Vorteil, wenn auf das Ergebnis der Methode walk() wieder Link-Walking angewendet wird und nur das letzte Ergebnis zurckgeliefert werden soll. Ferner knnen die Platzhalter <bucket> und <tag> durch die Wildcard "_" ersetzt werden. Damit ist es mglich nicht nur Verweisen innerhalb eines bestimmten Bucket und Namen zu folgen, sondern alle Verweise zu traversieren.
1
2 3 4
5 6 7 8 9 10 11
val res2 : FetchResponse = riakClient . fetch ( " employee " , " Petra " ) if ( res2 . hasObject ) { val petra = res2 . getObject val response : WalkResponse = petra . walk ( " address " , " livesIn " , true ) . run val steps = response . getSteps for ( step <- steps ) { for ( address <- step ) { println ( " Address : " + address . getValue ) } } } Listing 5.8: Link-Walking in Riak mit Java-API Im Listing 5.8 ist abgebildet, wie der Verweis zum Bucket address mit dem Namen livesIn, der Instanz petra, verfolgt wird. Aufgrund dessen, das es mehrere Verweise mit diesem Namen und Bucket geben kann, welche wiederum auf andere Daten verweisen, ist der Rckgabetyp der Methode getSteps() in Zeile 5 List[_ <: List[RiakObject]]. In den Zeilen 6 bis 10 werden die Listen durchlaufen und alle Adressen von Petra auf der Konsole ausgegeben. Map/Reduce Werden die Daten wie in dem vorherigen Abschnitt beschrieben abgerufen, ist das Anwenden von Filtern nicht mglich. Ferner knnen keine komplexen Berechnungen durchgefhrt werden, ohne die Daten zuvor in dem Client zu sammeln. Somit wrde eine hohe Netzlast entstehen, wenn viele Daten angefordert werden. Besser wre es, wenn die Berechnung auf den jeweiligen Knoten durchgefhrt wird, welcher die fr die Berechnung notwendigen Daten enthlt. Durch Map/Reduce ermglicht Riak den Code fr die Berechnung vom Client zu den jeweiligen Knoten zu transferieren, welcher dann das gewnschte Ergebnis zum Client zurcksendet. Bevor beschrie-
Benjamin Ldicke
Seite 36 von 95
ben wird wie Map/Reduce mittels der Java-API umzusetzen ist, soll anhand der Abbildung 5.3 das Verfahren genauer betrachtet werden.
Abbildung 5.3: Eigene Darstellung des Map/Reduce-Verfahren in Anlehnung an [EFHB10, S. 18] In der Map-Phase wird eine selbst denierte Funktion, fr alle eingehenden Daten ausgefhrt. Dabei [...] werden alle Eingabedaten auf verschiedene Map-Prozesse aufgeteilt [EFHB10, S. 17]. Die einzelnen Zwischenergebnisse werden danach in einer Liste zusammengefasst und in der Reduce-Phase auf verschiedene ReduceProzesse aufgeteilt, in denen eine selbst deniert Funktion auf die einzelnen Zwischenergebnisse angewendet wird. Das Ergebnis aus der Berechnung in der ReducePhase wird an den Aufrufer des Map/Reduce-Algorithmus zurckgegeben.
1
3 4 5 6 7 8
val res3 : MapReduceResponse = riakClient . mapReduceOverBucket ( " country " ) . map ( JavascriptFunction . anon ( """ function ( v ) { return [ JSON . parse ( v . values [0]. data ) . population ]; } """ ) , false ) . reduce ( JavascriptFunction . anon ( """ function ( v ) { var total = 0; for ( var value = 0; value < v . length ; value ++) { total += v [ value ]; }
Benjamin Ldicke
Seite 37 von 95
9 10 11 12 13 14
var average = total / v . length ; return [ average ]; } """ ) , true ) . submit () if ( res3 . isSuccess ) { println ( " Average population : " + res3 . getResults . get (0) ) } Listing 5.9: Map/Reduce in Riak mit Java-API In Listing 5.9 ist ein Beispiel fr die Anwendung des Map/Reduce-Verfahrens abgebildet. Das Ziel ist, die durchschnittliche Einwohnerzahl aller abgespeicherten Lnder im Bucket country zu berechnen. Dafr wird in Zeile 1 die Methode mapReduceOverBucket(<bucket>) aufgerufen, die als Parameter den Bucket country bergeben bekommt. Um fr die Map-Phase eine Funktion bereitzustellen, muss die Methode map(<MapReduceFunction>, <keep>) aufgerufen werden. Die fr den Platzhalter <MapReduceFunction> zu bergebene Funktion kann entweder in den Programmiersprachen Erlang oder JavaScript programmiert sein. In diesem Beispiel wird eine anonyme JavaScript-Funktion bergeben. Diese Funktion wandelt die Eingabedaten in ein JSON-Objekt, liest den Wert des Schlssels population und speichert diesen als Zwischenergebnis ab. Fr den Platzhalter <keep> wird angegeben, ob die Zwischenergebnisse in das Endergebnis einieen. Nachdem alle Zwischenergebnisse berechnet wurden, wird die anonyme JavaScript-Funktion in der Reduce-Phase aufgerufen. Diese Funktion addiert die eingehenden Zwischenergebnisse, in den Zeilen 6 bis 8 und errechnet den Durchschnitt in Zeile 9. Anschlieend wird das Ergebnis zurckgegeben und in Zeile 14 auf der Konsole ausgegeben. Update Die Daten unter einem Bucket und Key knnen entweder aktualisiert oder durch das Speichern eines neuen RiakObject berschrieben werden. Im Listing 5.10 ist abgebildet, wie die Einwohnerzahl von Deutschland um den Wert 1.000 erhht wird. In der Zeile 4 wird das RiakObject mit dem Namen germany, welches unter dem Bucket country mit dem Key Germany hinterlegt ist, aus der Datenbank abgefragt. Um die Daten in dem RiakObject verarbeiten zu knnen, wird aus ihnen in Zeile 5 ein JSONObject erstellt und in Zeile 6 die Einwohnerzahl ausgelesen. In Zeile 7 wird die Einwohnerzahl um den Wert 1.000 erhht und in Zeile 8 wird der neue Wert im RiakObject abgespeichert. Beim Update eines Dokuments wird eine sogenannte Vector Clock verwendet, um Konikte aufzulsen. Standardmig ist Riak so konguriert, dass das letzte Update gewinnt. Dies kann jedoch in der Konguration gendert werden, so dass der Konikt in der Anwendung aufgelst werden kann [Riaa].
15
1 2
def update () = { val res : FetchResponse = riakClient . fetch ( " country " , " Germany " ) if ( res . hasObject ) {
Benjamin Ldicke
Seite 38 von 95
4 5 6
7 8 9 10 11
val germany : RiakObject = res . getObject val jsonObject = new JSONObject ( germany . getValue ) val popoulation : Int = jsonObject . get ( " population " ) . asInstanceOf [ Int ] jsonObject . put ( " population " , ( popoulation + 1000) ) germany . setValue ( jsonObject . toString ) riakClient . store ( germany ) } } Listing 5.10: Update in Riak mit Java-API
Delete Das Lschen von Daten wird im Listing 5.11 beschrieben. Dabei muss lediglich der Bucket und der Key in der Methode delete(<bucket>, <key>) angegeben werden, unter welchen die zu lschenden Daten abgelegt sind.
1 2 3
def delete () = { riakClient . delete ( " country " , " Germany " ) } Listing 5.11: Delete in Riak mit Java-API
5.2.3 Backup
Wie auch bei anderen Datenbanken, ist es in Riak mglich ein Backup zu erstellen. Um dieses anzulegen muss Riak gestartet sein und folgender Befehl in der Kommandozeile ausgefhrt werden, wobei die Parameter in der Tabelle 5.2 erlutert sind: riak-admin backup <node> <cookie> <lename> [node|all] Fr die Wiederherstellung muss folgender Befehl ausgefhrt werden: riak-admin restore <node> <cookie> <lename> Die dabei verwendeten Parameter sind ebenfalls in der Tabelle 5.2 beschrieben. Der Backup-Befehl fr die erstellte Beispieldatenbank sieht wie folgt aus: riak-admin backup riak@192.168.178.33 riak ./backup.dets all
5.2.4 Skalierung, Replikation und Konguration

Um die Skalierung und Replikation in Riak nachvollziehen zu knnen, wird zunchst auf die Struktur und Konguration von Riak eingegangen. Riak verwaltet mittels des Consistent-Hashing-Verfahren10 einen Ring, welcher einen 2160 groen Schlsselraum
10
Ziele des Consistent-Hashing-Verfahren ist es einen festen Speicherort fr ein Objekt, in einer verteilten Umgebung, zu nden [EFHB10, S. 37]
Benjamin Ldicke
Seite 39 von 95
5. Evaluierung mglicher Datenbanken <node> <cookie>
gibt an, auf welchem Knoten das Backup ausgefhrt werden soll Cookie gibt an, ob Zugang gewhrt wird oder nicht - Cookie muss bei allen Knoten im Cluster gleich sein <lename> legt den Namen der Backup-Datei fest - dabei muss der komplette Pfad angegeben werden node/all gibt an, ob nur der einzelne Knoten oder das ganze Cluster gespeichert werden soll Tabelle 5.2: Backup-Optionen in Riak abbildet (somit knnen ca. 1048 Dokumente hinterlegt werden) [EFHB10, S. 164]. Dieser Ring wird in Partitionen aufgeteilt, wobei jeder Knoten im Cluster einen bestimmten Anteil der Partitionen verwaltet. Ein Beispiel fr die Partitionierung des Rings ist in Abbildung 5.4 dargestellt.
Abbildung 5.4: Eigene Darstellung des 160 bit Hash-Ring mit vier Knoten und 32 Partitionen Dabei gilt, jeder Knoten hat 1/(Anzahl von physikalischen Knoten) Partitionen. Ferner hat jeder Knoten virtuelle Knoten (sogenannte vnodes) in denen die Daten gespeichert werden. Die Anzahl der virtuellen Knoten wird durch die Formel (Anzahl der Partitionen)/(Anzahl der physikalischen Knoten) berechnet. Die virtuellen Knoten werden ber den Ring gleichmig verteilt. Wird ein neuer Knoten hinzugefgt, werden unter Verwendung des Consistent-Hashing-Verfahrens die bereits gespeicherten Daten neu verteilt. Im umgekehrten Fall, wenn ein Knoten den Ring verlsst, verteilt dieser zuvor die Daten an seine Nachbarn im Ring. Um einen
Benjamin Ldicke
Seite 40 von 95
Knoten zu einem Cluster hinzuzufgen, muss folgender Befehl ausgefhrt werden: riak-admin join riak@192.168.1.34 Die dabei angegebene IP-Adresse muss mit der des hinzuzufgenden Knoten bereinstimmen. Soll ein Knoten entfernt werden, muss statt dem Schlsselwort join das Schlsselwort remove angegeben werden. Die Replikation von Daten in Riak erfolgt automatisch und ist standardmig auf den Wert drei eingestellt. Diese Replikate werden dann auf unterschiedliche virtuelle Knoten verteilt, wie es in Abbildung 5.4 zu sehen ist. Die Eigenschaft n_val bestimmt die Anzahl der Replikate im Cluster und kann ausschlielich ber die REST-Schnittstelle angepasst werden. Ferner kann n_val fr jeden Bucket einen anderen Wert annehmen. Folgender Aufruf mit Curl11 erhht die Anzahl der Replikate fr den Bucket country von drei auf fnf: curl -X PUT -H "Content-Type: application/json" -d "props":"n_val":5 http://192.168.178.33:8098/riak/country Somit sind Daten in Riak hochverfgbar und single point of failure12 sind nicht mglich. Riak sttzt sich dabei auf die Verfgbarkeit (availability) und Ausfalltoleranz (partition tolerance) des CAP-Theorem13 . Die Konsistenz der Daten ist somit in Riak zweitrangig, wodurch die Daten erst nach einer unbestimmten Zeit konsistent vorliegen. Das von Riak verwendete Konsistenzmodell bezeichnet man als BASE14 .
5.2.5 Bewertung
Vorteile: bei der horizontalen Skalierung ist jeder Knoten gleichberechtigt, was single point of failure ausschliet Replikation und Lastverteilung erfolgt im Cluster automatisch unidirektionale Beziehung knnen abgebildet und traversiert werden Nachteile: die Dokumentation von Riak ist besser als bei OrientDB, jedoch nicht sehr umfangreich eine gute Geschwindigkeit ist nur mit dem Einsatz von SSDs oder RAIDSystemen zu erreichen Java-API fr nchste Version hat sich gendert und erfordert eine neue Evaluierung Abfragen ber Map/Reduce-Verfahren sind laut Meinung des Autors sehr umstndlich und erfordern Kenntnisse in JavaScript oder Erlang Riak ist eine gute Datenbank, wenn Verfgbarkeit wichtiger als Konsistenz ist. Durch das Map/Reduce-Verfahren ist es mglich, komplexe Anfragen zu formulieren und
11 12
http://curl.haxx.se unter single point of failure versteht man, wenn ein Ausfall eines einzelnen Knotens den Ausfall des gesamten Systems verursacht 13 das CAP-Theorem bedeutet, (C)onsisteny (A)vailability (P)artition tolerance und besagt, dass ein verteiltes System lediglich zwei dieser Kompetenzen vollstndig umsetzen kann 14 (B)asically (A)vailable (S)oft State (E)ventually Consistent [EFHB10, S. 33]
Benjamin Ldicke
Seite 41 von 95
innerhalb der Knoten ausfhren zu lassen. Jedoch sind die dafr notwendigen Funktionen umstndlich zu erstellen.
5.3 PostgreSQL
Postgres wurde von 1986 bis 1994 an der UCB15 entwickelt. Danach nahm die Firma Illustra Information Technologies16 den Quellcode und kommerzialisiert diesen. Die Einstellung des Projekt an der UCB erfolgte im gleichen Jahr, weil die Wartung des Quellcodes zunehmend Zeit in Anspruch nahm. Die zwei Doktoranden Andrew Yu und Jolly Chen entwickelten fr Postgres einen SQL Interpreter und verentlichten Postgres95 als Open-Source. 1996 wurde Postrges in PostgeSQL umbenannt, damit die Verwendung von SQL klar zum Ausdruck kommt. PostgreSQL gilt als sehr stabile Datenbank und wird von vielen Instituten eingesetzt [Posb]. Aufgrund dessen ist der Autor der Meinung, dass PostgreSQL als relationale Datenbank, fr die Verwendung innerhalb des neuen Informations- und Planungssystems, zu evaluieren ist. In den folgenden Abschnitten werden auf die CRUD-Operation, das Erstellen von Backups und Replikation eingegangen. Das relationale Datenmodell ist im Abschnitt 2.4.1 beschrieben, weshalb in diesen Kapitel nicht nher drauf eingegangen wird. Abschlieend erfolgt eine Bewertung der getesteten Datenbank, welche in der Version 9.0.4 vorliegt.
5.3.1 CRUD
Anders als bei den bisher vorgestellten Datenbanken hat PostgreSQL keine exklusive API, um auf die Datenbank zuzugreifen, sondern ermglicht das Verwenden eines JDBC-Treiber17 . JDBC ist ein Java-Standard [...] zum datenbankunabhngigen Zugri auf relationale Datenbanken [Kud07, S. 168]. Durch die Verwendung eines standardisierten Treiber ist es mglich, Anwendungen zu entwickeln die exibel zwischen verschiedenen Datenbanken wechseln knnen, ohne das der Quellcode stark angepasst werden muss. In diesem Abschnitt wird vorgestellt, wie ber JDBC eine Verbindung zu PostgreSQL aufgebaut wird und die CRUD-Operationen umzusetzen sind. Inbetriebnahme Die in diesem Abschnitt verwendete Beispielanwendung ist die gleiche wie in Abschnitt 5.1.2 beschrieben. Um in PostgreSQL die CRUD-Operationen vorzustellen, muss ein Datenbankschema vorhanden sein. Bevor dies jedoch angelegt werden kann, is es notwendig zunchst eine Datenbank mit folgendem Befehl zu erstellen: createdb -U postgres beispieldatenbank
15 16
University of California at Berkeley Illustra Information Technologies fusionierte spter mit Informix, welches seit 2001 zu IBM gehrt 17 Java Database Connectivity
Benjamin Ldicke
Seite 42 von 95
Die vom Nutzer postgres erstellte Datenbank hat den Namen beispieldatenbank und in dieser kann im nchsten Schritt das Datenbankschema erstellt werden. Falls das Schema spter nochmal verwendet oder abgendert werden soll, kann dies in einer SQL-Datei abgespeichert werden. In Listing 5.12 sind die, fr das Erstellen des Schemas, notwendigen DDL-Befehle dargestellt.
1 2 3 4 5 6 7 8
CREATE TABLE country ( name VARCHAR (50) PRIMARY KEY , population INTEGER ); CREATE TABLE city ( city _ id SERIAL PRIMARY KEY , country _ fk VARCHAR (50) REFERENCES country ON DELETE CASCADE , name VARCHAR (50) ); CREATE TABLE address ( address _ id SERIAL PRIMARY KEY , city _ fk INTEGER REFERENCES city ON DELETE CASCADE , street VARCHAR (50) ); CREATE TABLE company ( company _ id SERIAL PRIMARY KEY , address _ fk INTEGER REFERENCES address , name VARCHAR (50) ); CREATE TABLE employee ( employee _ id SERIAL PRIMARY KEY , address _ fk INTEGER REFERENCES address , company _ fk INTEGER REFERENCES company , name VARCHAR (50) ); Listing 5.12: Datenbankschema fr die Beispieldatenbank in PostgreSQL Eine Besonderheit beim Anlegen des Schemas, ist die Verwendung des Datentyps SERIAL. Dieser veranlasst PostgreSQL eine Sequenz zu erstellen, welche einen IntegerWert beim hinzufgen eines neuen Tupel mit eins akkumuliert. Ferner sind die generierten Integer-Werte eindeutig, weswegen sie als Primrschlssel deniert sind. Damit eine Beziehung zwischen den Tabellen hergestellt werden kann, verweisen Fremdschlssel auf die Primrschlssel einer anderen Tabelle, wie es in den Zeilen 8, 14, 20, 26 und 27 zu erkennen ist. Sofern einer Referenz der Befehl ON DELETE CASCADE angehngt ist, wird das ndern oder Entfernen von Primrschlsseln an die Tupel, welche auf die betroenen Primrschlssel verweisen, weitergegeben.
9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
Benjamin Ldicke
Seite 43 von 95
5. Evaluierung mglicher Datenbanken Create
Im Listing 5.13 ist auszugsweise dargestellt, wie Daten in PostreSQL hinzugefgt werden knnen.
1 2
3 4 5
val dbDriver = Class . forName ( " org . postgresql . Driver " ) val url = " jdbc : postgresql : //192.168.178.41 : 5432/ beispieldatenbank " val user = " postgres " val password = " password " val connection = DriverManager . getConnection ( url , user , password ) [...] def create () = { // Insert countries val countryStmt : PreparedStatement = connection . prepareStatement ( " INSERT INTO country ( name , population ) VALUES (? , ?) " ) countryStmt . setString (1 , " Germany " ) countryStmt . setInt (2 , 81000000) countryStmt . execute () // Insert cities val cityStmt : PreparedStatement = connection . prepareStatement ( " INSERT INTO city ( country _fk , name ) VALUES (? , ?) " ) cityStmt . setString (1 , " Germany " ) cityStmt . setString (2 , " Berlin " ) cityStmt . execute () Listing 5.13: Create in PostgreSQL mit JDBC-Treiber Fr den Verbindungsaufbau zu dem PostgreSQL-Server ist es notwendig, den Namen des verwendeten JDBC-Treiber und den Pfad zum Server festzulegen. Ferner muss von einem autorisierten Nutzer der Benutzername und das Passwort angegeben werden. Diese Parameter werden in den Zeilen 2 bis 4 festgelegt und in Zeile 5, der Methode getConnection(<url, <username>, <password>), bergeben. Die somit eingerichtete Verbindung wird in den folgenden Codebeispielen fr die Manipulation der erstellten Tabellen verwendet. In Zeile 11 wird ein SQL-String der Methode prepareStatement(<sqlString>) bergeben. Die im String enthaltenen ? mssen im folgenden durch gltige Werte ersetzt werden. Durch die Verwendung von prepareStatement wird serverseitig ein Objekt erzeugt, welches alle bentigten Parameter fr die Ausfhrung des SQL-Strings analysiert. Durch das einmalige Generieren des Objekts und dessen Wiederverwendung, kann die Leistung von PostgreSQL optimiert werden [Posa]. In den Zeilen 12 und 13 werden die Werte fr die Attribute name und population gesetzt. Der Befehl execute() fhrt das State-
6 7 8 9 10 11
12 13 14 15 16 17
18 19 20
Benjamin Ldicke
Seite 44 von 95
ment aus. Die Verbindung zwischen den Tabellen country und city wird durch das angeben des Fremdschlssels in Zeile 18 erreicht. Read In diesem Abschnitt wird gezeigt, wie die zuvor erstellten Daten wieder aus PostgreSQL abgefragt werden knnen (siehe Listing 5.14). Dabei wird wie im Abschnitt 5.3.1 beschrieben, ein PreparedStatement erzeugt. Ziel der Abfrage ist es, alle Lnder auszugeben, welche eine grere Einwohnerzahl als 70 Millionen haben.
1 2
3 4
5 6 7 8
9 10 11 12
def read () = { val readStmt : PreparedStatement = connection . prepareStatement ( " SELECT * FROM country WHERE population > 70000000 " ) val resultSet : ResultSet = readStmt . executeQuery () val resultSetMetaData : ResultSetMetaData = resultSet . getMetaData () val columns = resultSetMetaData . getColumnCount while ( resultSet . next ) { for ( column <- 1 to columns ) { print ( resultSet . getObject ( column ) . toString + " \ t " ) } println () } } Listing 5.14: Read in PostgreSQL mit JDBC-Treiber In der Zeile 3 wird das Statement mit dem Befehl executeQuery() ausgefhrt und ein Objekt vom Typ ResultSet zurckgegeben. Da dem Statement ein String bergeben wurde, ist nicht klar welche Struktur die zurckgegeben Daten haben. Es ist lediglich bekannt, dass im ResultSet eine Menge von Tupeln enthalten sind. Um ein komplettes Tupel auszugeben, muss zuvor die Anzahl der zurckgegebenen Spalten ermittelt werden (siehe Zeile 5). In den beiden Schleifen wird dann jedes Tupel der zurckgelieferten Ergebnismenge, mit allen Attributen, ausgegeben. Ferner knnte jedes Tupel in ein passendes Objekt abgespeichert werden. Die aus Sicht des Autors umstndliche Umwandlung der Ergebnismenge in Java-Objekte wird als impendance mismatch bezeichnet [Kud07, S. 153]. Update Ein Update wird, wie zuvor auch ein Create oder Read, ber das PreparedStatement durchgefhrt. In Listing 5.15 ist dargestellt, wie die Einwohnerzahl von Deutschland auf 82 Millionen gesetzt wird. Eine Besonderheit ist das Ausfhren des Statement durch die Methode executeUpdate(). Diese Methode liefert als Rckgabewert einen Integer, welche aussagt wie viele Tupel von dem Update betroen waren.
Benjamin Ldicke
Seite 45 von 95
1 2
3 4 5
def update () = { val updateStmt : PreparedStatement = connection . prepareStatement ( " UPDATE country SET population = 82000000 WHERE name = Germany " ) val affected : Int = updateStmt . executeUpdate () println ( affected + " row ( s ) affected " ) } Listing 5.15: Update in PostgreSQL mit JDBC-Treiber
Delete Das Lschen von Tupeln erfolgt ebenso wie das Update, welches im Abschnitt 5.3.1 beschrieben wurde. Lediglich der SQL-String unterscheidet sich wie in Listing 5.16 zu erkennen ist.
1 2
3 4 5
def delete () = { val updateStmt : PreparedStatement = connection . prepareStatement ( " DELETE FROM employee WHERE name = Steve " ) val affected : Int = updateStmt . executeUpdate () println ( affected + " row ( s ) affected " ) } Listing 5.16: Delete in PostgreSQL mit JDBC-Treiber
5.3.2 Backup
Ein Backup kann in PostgreSQL auf verschiedene Art und Weise durchgefhrt werden. Die einfachste Mglichkeit ist das Erzeugen einer Textdatei, in der alle Tabellen inklusive deren Inhalte abgelegt sind. Diese Textdatei wird in PostgreSQL als TextDump bezeichnet. Um ein Text-Dump zu erzeugen, muss die Datei pg_dump im /bin Verzeichnis der PostgreSQL-Installation wie folgt aufgerufen werden: pg_dump le=dump.sql beispieldatenbank In diesem Beispiel wird die Datenbank beispieldatenbank gesichert und das TextDump dump.sql im Verzeichnis /bin hinterlegt. Fr das Wiederherstellen der Daten, muss folgender Befehl verwendet werden: psql -f dump.sql beispieldatenbank Bei der Wiederherstellung ist sicherzustellen, dass die Datenbank beispieldatenbank in PostgreSQL existiert [Posa]. Eine andere Mglichkeit ein Backup zu erstellen, ist das Verwenden der sogenannten WAL-Archivierung18 . Bei diesem Verfahren werden alle Schreiboperationen im Datenbanksystem aufgezeichnet und knnen bei Bedarf wiederholt werden. Um die WAL-Archivieung nutzen
18
Write-Ahead-Log
Benjamin Ldicke
Seite 46 von 95
zu knnen, muss in der Datei postgresql.conf die Variable archive_mode auf den Wert on gesetzt und Postgre-SQL neu gestartet werden. Weil bei der WALArchivierung nur die Schreiboperationen und nicht der derzeitige Datenbestand gesichert wird, muss eine Basis-Sicherung durchgefhrt werden. Durch den Befehl: psql -c ";SELECT pg_start_backup(Backup)"; wird in PostgreSQL der Backup-Modus fr Basis-Sicherung gestartet. Dies ist wichtig, um einen doppelten Zugri auf das Datenverzeichnis /data zu unterbinden. Der in Klammern angegebene String, ist lediglich ein Hinweis zu dem Backup und kann beliebigen Text enthalten. Ist der Backup-Modus gestartet, kann eine Sicherung des Datenverzeichnis erfolgen. Nachdem das Kopieren abgeschlossen ist, beendet der Befehl: psql -c ";SELECT pg_stop_backup()"; den Backup-Modus. Anschlieend muss das Verzeichnis pg_xlog, in welchem sich die aufgezeichneten Schreiboperationen benden, gesichert werden. Vorteil gegenber der zuerst vorgestellten Variante ist, dass so auch inkrementelle Sicherungen mglich sind, die bei einer greren Datenbank das Datenvolumen der Sicherungen reduzieren [EH09, S. 85 .].
5.3.3 Replikation
In PostgreSQL ist es seit der Version 9 mglich eine Replikation auf mehrere StandbyServer19 durchzufhren. Um die Replikation auf einen Standby-Server zu ermglichen, mssen folgende Schritte durchgefhrt werden: 1. Anpassen der Datei postgresql.conf a) listen_address = 192.168.178.42 b) wal_level = hot_standby c) max_wal_senders = 1 2. Anpassen der Datei pg_hba.conf a) host replication all 192.168.178.42/32 trust 3. Erstellen einer Basissicherung (siehe Abschnitt 5.3.2) auf Primr-Servers und dieses anschlieend auf den Standby-Server kopieren 4. im Datenverzeichnis des Standby-Server die Datei recovery.conf erstellen und anpassen a) standby_mode = on b) primary_conninfo = host=192.168.178.41 5. Starten des Standby- und Primr-Servers Im Punkt eins wird die Datei postgresql.conf angepasst, wobei die IP-Adressen der jeweiligen Standby-Server anzugeben sind. Der Wert hot_standby erlaubt es dem Nutzer auf den Standby-Server lesend zuzugreifen und mit wal_senders wird die Anzahl dieser festgelegt. Weil der Standby-Server die Erlaubnis haben muss
19
ein Standby-Server bernimmt die Aufgaben des Primr-Servers, wenn dieser ausfllt
Benjamin Ldicke
Seite 47 von 95
auf den Primr-Server zuzugreifen, ist in der Datei pg_hba.conf die Zeile unter Punkt 2. b) anzugeben. Das Schlsselwort replication signalisiert, dass die eingehende Verbindung fr die Replikation der Daten genutzt wird. Ferner braucht der Standby-Server keine Zugangsdaten fr die Verbindung angeben, da das Schlsselwort trust gesetzt ist. Nachdem die Basissicherung auf dem Standby-Server kopiert wurde, muss die Datei recovery.conf angelegt werden. Die darin enthaltenen Angaben veranlassen PostgreSQL als Standby-Server zu starten und eine Verbindung mit dem Primr-Server einzugehen [Posc]. PostgreSQL untersttzt bei der eben vorgestellten Replikation keine horizontale Skalierung. Durch Plugins, wie zum Beispiel Slony-I, kann PostgreSQL jedoch so erweitert werden, dass eine horizontale Skalierung umgesetzt werden kann. Slony-I nutzt dafr, wie auch OrientDB, das Master-Slave Prinzip, wobei alle Schreiboperationen ber den Master-Knoten durchgefhrt werden. Leseoperationen werden an die Slave-Knoten verteilt, wodurch eine gleichmige Auslastung der Server erreicht wird. Aufgrund der hohen Komplexitt bei der Einrichtung von Slony-I, wird dies in dieser Master-Thesis nicht demonstriert und auf die Homepage20 von Slony-I verwiesen.
5.3.4 Bewertung
Vorteile: ausfhrliche Dokumentation benutzt SQL als Abfragesprache und ist somit fr viele Anwender bekannt da ein JDBC-Treiber vorhanden ist, muss beim Wechsel zu einer anderen Datenbank, die einen JDBC-Treiber anbietet, der Quellcode nur minimal angepasst werden liegt in einer stabilen Version vor Beziehungen knnen einfach ber Fremdschlssel abgebildet werden Nachteile: Replikation ist umstndlicher, als bei den vorgestellten NoSQL Datenbanken, einzurichten horizontale Skalierung ist nur durch zustzliche Plugins mglich, welche ebenfalls einen hohen Kongurationsaufwand haben Bei der Evaluierung von PostgreSQL, sind bei den CRUD-Operationen keine Fehler aufgetreten und alle Beispiele funktionierten wie auf der Homepage und im Wiki beschrieben. Ferner konnten alle Beispiele fr die Replikation nachvollzogen und umgesetzt werden. Aufgrund dessen ist der Autor der Meinung, dass PostgreSQL eine sehr gute Dokumentation hat, welche wichtig fr zuknftige Mitglieder des Projekt spirit@fhs ist. Beziehungen zwischen den Daten knnen durch das relationale Paradigma einfach umgesetzt werden. Lediglich die Replikation und horizontale Skalierung ist aufwndig umzusetzen. Haben die Skalierung und Replikation nicht die
20
http://slony.info/
Benjamin Ldicke
Seite 48 von 95
hchste Prioritt bei der Auswahl einer passenden Datenbank, ist PostgreSQL fr das neue Informations- und Planungssystem gut geeignet.
5.4 EclipseLink als Object-Relational Mapper

Wie im Abschnitt 2.3 bereits erwhnt, wird Mapper von Lift zuknftig durch Record abgelst. Eine Verwendung als ORM kommt deshalb in dieser Master-Thesis nicht in Frage. Da in Scala auch ORMs genutzt werden knnen, die fr Java-Anwendungen entwickelt wurden, kann sowohl Hibernate21 als auch EclipseLink22 genutzt werden. In dieser Master-Thesis wird EclipseLink in der Version 2.3 verwendet, da es die Referenzimplementierung fr die JPA 2.023 darstellt und somit eine hohe Standardkonformitt aufweist. EclipseLink basiert auf den ORM TopLink der Firma Oracle und wurde 2008 in der Version 1.0 verentlicht. Durch den Einsatz eines ORM gibt es keinen impendance mismatch zwischen der Datenbank und Scala. Ferner ist es mglich Abfragen mittels Expressions zu abstrahieren, so dass keine SQL-Befehle vom Anwendungsprogrammierer erstellt werden mssen. Dies hat laut [Fou] gegenber SQL folgende Vorteile: Expressions sind leichter zu Pegen, da die Datenbank abstrahiert wird nderungen an Tabellen haben keine Einuss auf die Abfragestruktur Expressions machen Abfragen lesbarer besteht zwischen zwei Tabellen eine Beziehung, knnen Attribute beider Tabellen abgefragt werden - EclipseLink generiert dafr automatisch einen Join Expressions verbergen die Komplexitt von SQL-Abfragen Wie im Abschnitt 5.3 zu sehen ist, muss ein Datenbankschema in PostgreSQL erstellt werden, um Daten abspeichern zu knnen. Damit der Programmierer sich nicht zustzlich mit der DDL auseinandersetzen muss, kann er EclipseLink das Schema erstellen lassen. Dafr ist es notwendig EclipseLink das Datenmodell der Anwendung verstndlich zu machen. Dies wird ber Annotationen in den Klassen oder ber eine externe XML-Datei ermglicht. Beide Varianten haben Vor- und Nachteile. Entscheidet sich der Programmierer fr Annotationen, wird der Quellcode weniger lesbar und zustzliche Abhngigkeiten werden geschaen. Der Vorteil jedoch ist, dass Annotationen leichter umzusetzen sind als die Denition des Schemas in einer XMLDatei zu hinterlegen. Ein weiterer Vorteil von EclipseLink ist, das die Mglichkeit besteht ein Datenbankcluster zu erstellen, selbst wenn die verwendete Datenbank dies nicht untersttzt. Die Lastverteilung wird dabei ausschlielich von EclipseLink bernommen.
21 22
http://www.hibernate.org/ http://www.eclipse.org/eclipselink/ 23 die Java-Persistence-API ist eine Schnittstelle zur bertragung von Objekten zu einer realtionalen Datenbank
Benjamin Ldicke
Seite 49 von 95
5.5 Auswahl einer Datenbank

In den vorherigen Kapiteln wurden drei mgliche Datenbanken darauf hin untersucht, inwiefern diese sich fr das neue Informations- und Planungssystem eignen. In allen drei Datenbanken ist die Darstellung von Beziehungen zwischen Objektentypen einfach umzusetzen. Wobei OrientDB als Graphen-Datenbank besonders gut bidirektionale Beziehungen abbilden kann, mssen in den beiden anderen Datenbanken dafr zustzliche Beziehungen angelegt werden. Fr die Manipulation und das Erstellen von Daten haben OrientDB und Riak jeweils eine eigene API bereitgestellt, welche laut Meinung des Autors nicht ausgereift sind. Insbesondere bei der API von OrientDB sind dem Autor Fehler aufgefallen und das Map/Reduce-Verfahren von Riak ist zu aufwndig bei der Programmierung. Der JDBC-Treiber von PostgreSQL dagegen ist ausgereift und alle Beispiele in der Dokumentation, sowie im Wiki, konnten umgesetzt werden. Zustzlich ermglicht der JDBC-Treiber die Verwendung von EclipseLink als ORM. Die Dokumentation von PostgreSQL ist sehr ausfhrlich, was bei der Einarbeitung neuer Mitglieder im Team spirit@fhs von Vorteil ist. Ein Nachteil von PostgreSQL gegenber den anderen evaluierten Datenbanken ist, die komplizierte Konguration der Replikation und horizontalen Skalierung. Aufgrund dessen, dass keine hohe Systemlast in dem neuen Informations- und Planungssystem zu erwarten ist, entscheidet sich der Autor fr PostgreSQL, in Verbindung mit EclipseLink, als Datenbankmanagementsystem.
Benjamin Ldicke
Seite 50 von 95
6 Festlegen des Datenmodell

In diesem Abschnitt wird das Datenmodell fr das neue Informations- und Planungssystem vorgestellt. Als Grundlage dienen die im Abschnitt 3 erstellte Miniwelt, sowie die Anwendungsfalldiagramme. In der Miniwelt und den Anwendungsfalldiagrammen ist jedoch nicht ersichtlich, welche Eigenschaften die einzelnen Objekte reprsentieren. In der Abbildung 6.1 sind die Objekttypen1 mit ihren Beziehung abgebildet und werden im folgenden erlutert. Zu erwhnen ist, dass das in diesem Kapitel vorgestellte Datenmodell in Zusammenarbeit mit den Teammitgliedern des Projekts spirit@fhs entstand, um mglichst allen Forderungen der Teilprojekte gerecht zu werden.
Abbildung 6.1: Eigene Darstellung des Datenmodell Informations- und Planungssystems
des zu
entwickelnden
Ein Objekttyp ist eine durch einen Objekttyp-Namen eindeutige benannte Klasse von Objekten, ber die dieselben Informationen gespeichert werden und die in prinzipiell gleicher Weise verarbeitet werden [Jar10, S. 31].
Benjamin Ldicke
Seite 51 von 95
6. Festlegen des Datenmodell
6.1 Event
In der Tabelle 6.1 sind die Eigenschaften des Objekttyp Event aufgelistet. Das Attribut titleShort reprsentiert die Abkrzung der Titelbeschreibung. Somit ist es mglich bei der Darstellung im Browser oder auf dem Handy Platz zu sparen und somit Komponenten besser anzuordnen. Sollte die Abkrzung nicht aussagekrftig genug sein, kann auch die komplette Bezeichnung ausgegeben werden. Wie in der Miniwelt (siehe Abbildung 4.1) dargestellt, existieren verschiedene Events. Aufgrund dessen, dass alle Events eine hnliche Struktur aufweisen, wurden diese in einem Objekttyp zusammengefasst und anhand des Attributs event_type unterschieden. Durch das neue Informations- und Planungssystem soll es mglich sein, auch auf den Stundenplan und einzelne Events vergangener Semester zuzugreifen. Damit alte und aktuelle Events unterschieden werden knnen, deniert die Eigenschaft expireDate ein Datum an dem die Vorlesung verfllt und diese nicht mehr unter aktuellen Events aufgelistet wird. Ferner knnen Events aufgelistet werden die keine Termine haben, aber dennoch bis zu einem bestimmten Datum gltig sind. Event event_id event_type
titleShort titleLong expireDate
jedes Event ist eindeutig durch eine ID zu identizieren legt fest, um welchen Typ es sich handelt - folgende mgliche Werte sind festgelegt: Lecture, Tutorial, Lesson, Other kurz ist die Abkrzung eines Events - diese wurde im alten Stundenplan angezeigt ist die ausgeschriebene Bezeichnung eines Events gibt an, wann ein Event verfallen ist Tabelle 6.1: Objekttyp Event
6.2 Appointment
Die Eigenschaften des Objekttyp Appointment sind in der Tabelle 6.2 dargestellt. Ein Appointment ist ein Termin fr ein bestimmtes Event. Dabei kann ein Event keinen oder mehrere Appointments haben. Durch die Attribute startAppointment und endAppointment wird bestimmt, wie lange ein Appointment dauert. Der Vorteil dabei ist, dass es keine festen Raster gibt, in die ein Appointment passen muss. Ferner knnen einzelne Termine verschoben und nderungen durch das Attribut status nachvollzogen werden. Somit ist es mglich jedes einzelne Event im Stundenplan zu planen und anzupassen. Ein statischer Stundenplan, wie er im Moment existiert, wre laut Meinung des Autors berssig. Auch die Verentlichung von Terminnderungen ber News knnen damit entfallen.
Benjamin Ldicke
Seite 52 von 95
6. Festlegen des Datenmodell Appointment appointment_id startAppointment endAppointment status
jedes Appointment ist eindeutig durch eine ID zu identizieren bestimmt wann ein Appointment beginnt (yyyyMMddHHmmss) kurz bestimmt wann ein Appointment beendet ist (yyyyMMddHHmmss) reprsentiert den derzeitigen Status - dieser kann sein ok, cancelled oder moved Tabelle 6.2: Objekttyp Appointment
6.3 Location
In der Tabelle 6.3 ist der Objekttyp Location dargestellt. Eine Location ist anhand der Attribute building und room eindeutig zu identizieren. Die Location dient als Trepunkt fr die Events und kann von Appointment zu Appointment variieren. Location building room
ist die Bezeichnung eines Gebudes ist die Bezeichnung eines Raumes Tabelle 6.3: Objekttyp Location
6.4 DegreeClass
Der Objekttyp DegreeClass (siehe Tabelle 6.4) ermglicht das Erstellen einer Baumstruktur, um die Kurse der Fakultt Informatik abzubilden. Dies ermglicht einer Klasse mehrere Untergruppen hinzuzufgen, wobei jede Untergruppe wieder Untergruppen haben kann. Da an der Fakultt derzeitig nur Kurse Untergruppen haben knnen, kann das Attribut classType folgende Werte annehmen: Class oder Group. Durch dieses Attribut ist eine schnelle Filterung nach Gruppen oder Kursen mglich. Ferner hat ein DegreeClass-Objekt beliebig viele Mitglieder (Objekttyp Member) und nimmt an beliebig vielen Veranstaltungen (Objekttyp Event) teil. DegreeClass class_id mail title classType
jedes DegreeClass Objekt ist durch diese ID eindeutig zu identizieren ist die E-Mail der jeweiligen Gruppe oder Klasse ist die Bezeichnung der Gruppe oder Klasse bestimmt ob es sich um eine Gruppe oder Klasse handelt - mgliche Werte sind Class oder Group Tabelle 6.4: Objekttyp DegreeClass
Benjamin Ldicke
Seite 53 von 95
6. Festlegen des Datenmodell
6.5 Member
In der Tabelle 6.5 ist der Objekttyp Member abgebildet. Ein Member ist ein Mitglied der Fachhochschule Schmalkalden. Aufgrund der sehr hnlichen Struktur von Dozenten, Studenten und anderen Mitgliedern sind diese in einem Objekttyp zusammengefasst. Die Unterscheidung der einzelnen Mitglieder wird durch das Attribut memberType vorgenommen. Ein Member hat die Mglichkeit an beliebig vielen Events teilzunehmen und kann mehreren Klassen oder Gruppen (Objekttyp DegreeClass) angehren. Eine Besonderheit bei dem Objekttyp Member ist die Verbindung zum Objekttyp Event, welche ber den Objekttyp MemberEvent erfolgt. MemberEvent ist eine Kreuztabelle mit dem zustzlichen Attribut qualifier, welches eine Unterscheidung zwischen den Vorlesenden und den Zuhrern ermglicht. Ferner wird in dieser Tabelle der persnliche Stundenplan der Member hinterlegt. Member fhs_id displayedName memberType
jeder Member ist durch seine fhs_id eindeutig zu identizieren ist der Name, welche beim Erstellen einer News oder eines Kommentars angezeigt wird legt den Typ fest - folgende Werte sind mglich: Lecturer oder Student Tabelle 6.5: Objekttyp Member
6.6 News
ber News knnen Nachrichten auf der Homepage der Fachhochschule Schmalkalden verentlicht werden. In der Tabelle 6.6 sind die Attribute einer Nachricht aufgelistet. Beim Erstellen einer Nachricht wird das Erstellungsdatum in den Attributen creationDate und lastModified gespeichert. Unterscheiden sich die Werte der beiden Attribute, ist im Attribut lastModiefied zu erkennen, wann News das letzte mal bearbeitet wurden. Ferner kann eine News nur von einem Mitglied der Fachhochschule Schmalkalden erstellt werden und kann beliebig viele Kurse betreen.
Benjamin Ldicke
Seite 54 von 95
6. Festlegen des Datenmodell News news_id creationDate expireDate title lastModied content
jede News ist durch eine ID eindeutig zu identizieren gibt an wann die News erstellt wurde legt fest wann eine News verfallen und somit nicht mehr gltig ist ist der Betre einer News gibt an wann eine News das letzte mal bearbeitet wurde ist der Inhalt der News Tabelle 6.6: Objekttyp News
6.7 NewsComment
Der Objekttyp NewsComment ermglicht das Speichern von Kommentaren zu einer bestimmten Nachricht (Objekttyp NewsComment), dabei wird beim Anlegen eines Kommentars das Erstellungsdatum im Attribut creationDate abgespeichert. Ferner kann ein Kommentar nur von einem Mitglied der Fachhochschule Schmalkalden erstellt werden. NewsComment newsComment_id creationDate content
jeder Kommentar ist durch eine ID eindeutig zu identizieren gibt an wann der Kommentar erstellt wurde ist der Inhalt des Kommentars Tabelle 6.7: Objekttyp NewsComment
Benjamin Ldicke
Seite 55 von 95
7 Realisierung
In diesem Kapitel wird die Funktionsweise des Datenbank-Service erlutert. Ferner wird dargestellt, wie die REST-Schnittstelle aufgebaut ist und das Datenmodell in den Datenbank-Service integriert wird.
7.1 Grobentwurf
In diesem Abschnitt soll die Funktionsweise des Datenbank-Service verdeutlicht werden. Ziel des Datenbank-Service ist es, die dahinter liegende Datenbank zu kapseln und somit austauschbar zu machen. Durch die Verwendung von EclipseLink, kann PostgreSQL durch eine andere relationale Datenbank, die einen JDBC-Treiber anbietet, ausgetauscht werden. Die Verwendung einer beliebigen Datenbank, ist jedoch nicht ohne Weiteres mglich. Damit auch andere Datenbanken verwendet werden knnen, muss die REST-Schnittstelle und das Datenmodell von der Datenbank unabhngig sein. Dies wird durch das Fabrik-Entwurfsmuster und Komposition erreicht. Ferner werden XML und JSON als Datenbertragungsformate untersttzt, wobei der Datenbank-Service intern ausschlielich mit JSON-Dokumenten arbeitet. Somit muss bei eingehenden Verbindungen eine Konvertierung von XML zu JSON und umgekehrt bei ausgehenden Verbindungen durchgefhrt werden, sofern XML als Datenbertragungsformat gefordert ist. Aufgrund dessen, dass unterschiedliche Datenbanksysteme auch unterschiedliche Fehlermeldungen ausgeben knnen, mssen diese abgefangen und gekapselt werden. Dabei wird sichergestellt, dass der Client unabhngig vom verwendeten Datenbanksystem stets die gleichen Fehlermeldungen empfngt. Der Ablauf einer eingehenden Anfrage an den Datenbank-Service ist im Aktivittsdiagramm 7.1 dargestellt.
7.2 Feinentwurf
Beim Feinentwurf wird festgelegt welche Klassen fr den Datenbank-Service deklariert werden mssen. Anhand von Klassendiagrammen wird erlutert wie der Datenbank-Service umgesetzt werden kann, wobei die Kapselung des Datenmodells und der REST-Schnittstelle im Fokus des Entwurfs liegen. Die Beschreibung der Klassen und ihre Aufgaben wird ebenfalls vorgenommen.
7.2.1 REST-Schnittstelle des Datenbank-Service

In diesem Abschnitt wird die Struktur der Rest-Schnittstelle erlutert. Die bentigten Klassen, um die Schnittstelle vom Datenmodell zu kapseln, sind in Abbildung 7.2
Benjamin Ldicke
Seite 56 von 95
7. Realisierung
Abbildung 7.1: Verarbeiten einer eingehenden Anfrage beim Datenbank-Service dargestellt. Im folgenden werden die einzelnen Klassen vorgestellt und deren Beziehungen miteinander beschrieben. Die Klasse ServiceApi Die Klasse ServiceApi legt die URLs fr die jeweiligen Ressourcen fest. Um verschiedene Operationen auf einer Ressource ausfhren zu knnen, werden die httpMethoden PUT, GET, POST und DELETE (siehe Tabelle 2.1) angeboten. Ferner wird in dieser Klasse die Uhrzeit und das Datum gespeichert, wenn neue Nachrichten hinzugefgt oder gendert werden. Somit knnen Clients den Zeitpunkt der letzten nderung abfragen und sich die neue Nachricht schicken lassen. Die abstrakte Klasse Invoke Die abstrakte Klasse Invoke beinhaltet die Methode invoke(), welche die Methode start() kapselt und somit doppelten Code vermeidet, in dem die Fehlerberprfung nur einmal implementiert werden muss (Strategie-Entwurfsmuster). Die Methode start() hat als bergabeparameter eine Funktion, welche den eigentlich Aufruf der gewnschten Ressource enthlt und wird in den Basisklassen berschrieben.
Benjamin Ldicke
Seite 57 von 95
7. Realisierung
Abbildung 7.2: Klassendiagramm der REST-Schnittstelle des Datenbank-Service Die Klassen WithBody und WithoutBody WithBody und WithoutBody sind Subklassen von Invoke. Der Unterschied beider Klassen besteht lediglich darin, dass bei WithBody eine berprfung des http-Header auf den Content-Type stattndet und anschlieend eine Konvertierung des httpBody in das JSON-Format durchgefhrt wird. In der Klasse WithoutBody ist das nicht notwendig, da diese nur bei lesenden Aufrufen verwendet wird und somit Daten aus dem http-Body nicht relevant sind. Die Funktion, welche als bergabeparameter bei der Methode start() angegeben werden muss, entspricht der Signatur von den Methoden in der Klasse DBConnector. Die Klasse DBConnector Die Klasse DBConnector liegt zwischen dem Datenmodell und der REST-Schnittstelle. Als Parameter bekommt der Konstruktor ein Objekt der Klasse DAOFactory. Die Methoden von DBConnector werden in der Klasse ServiceApi an die Subklassen WithBody und WithoutBody bergeben. In den Methoden wird von der bergebe-
Benjamin Ldicke
Seite 58 von 95
7. Realisierung
nen Fabrik ein DAO-Objekt angefordert und somit auf die Daten der Datenbank zugegrien. Die abstrakte Klasse DAOFactory Diese Klasse dient als Fabrik und gibt ber die Methode getDAOFactory() eine Subklasse zurck. Diese Subklasse berschreibt alle Methoden, welche eine Schnittstelle aus dem Paket DAOInterfaces als Rckgabeparameter haben. Durch diese Schnittstellen werden die CRUD-Operationen abstrahiert und knnen fr jede Klasse des Datenmodells angepasst werden.
Abbildung 7.3: Klassendiagramm des Datenbank-Service
eingebundenen
Datenmodells
in
den
Benjamin Ldicke
Seite 59 von 95
7. Realisierung
7.2.2 Einbinden des Datenmodells in den Datenbank-Service

In diesem Abschnitt wird erlutert wie das ausgearbeitete Datenmodell in den Datenbank-Service integriert wird. In der Abbildung 7.3 ist das Klassendiagramm abgebildet, wobei zugunsten der bersicht die Beziehungen zwischen den Klassen des Datenmodells nicht dargestellt wurden. Jedoch sind diese implementiert und entsprechen denen aus der Abbildung 6.1. Ferner ist die Klasse EclipseLinkDAOFactory dieselbe wie in Abbildung 7.2. Das Paket DAOInterfaces Das Paket DAOInterfaces beinhaltet alle Schnittstellen, welche die CRUD-Operationen abbilden. Die Struktur der Schnittstelle NewsDAO ist in der Abbildung 7.3 als Hinweis dargestellt. Dabei ist zu erkennen, dass die CRUDOperationen ein oder mehrere Objekte der Klasse News zurckliefern. Der Rckgabetyp variiert zwischen den Schnittstellen, was an den Abhngigkeiten zu erkennen ist. Obwohl alle Schnittstellen die CRUD-Operationen beinhalten, wurde fr jede Klasse des Datenmodells eine Schnittstelle bereitgestellt, um diese individuell anpassen zu knnen. Dabei ist zu erwhnen, das lediglich die Schnittstelle DegreeClassDAO eine zustzlich Methode hat, um alle Unterklassen (Kurse und Gruppen) einer bestimmten Klasse zu ermitteln. Die abstrakte Klasse AbstractPersistence Von der Klasse AbstractPersistence werden alle Klassen abgeleitet, welche eine Schnittstelle aus dem Paket DAOInterface implementieren. Diese Klasse ist fr die Ausfhrung von erstellten Expression verantwortlich und bekommt diese innerhalb einer Funktion an die Methode invoke(f() => AnyRef) bergeben. Innerhalb der Methode invoke() wird die bergebene Funktion ausgefhrt und mgliche Fehlermeldungen, durch EclipseLink oder PostgreSQL, werden abgefangen und in allgemeinere Fehlermeldungen umgewandelt. Die EclipseLink DAO-Klassen Alle Klassen, welche die Schnittstellen des Pakets DAOInterfaces implementieren, sind fr das Erstellen von Expressions verantwortlich. Dabei werden Parameter, die der URL mitgegeben wurden als Filter verwendet, um die zurckzusendende Datenmenge einzugrenzen. Ferner wird berprft, ob semantische Vorbedingungen erfllt werden. Zum Beispiel darf eine Nachricht nur von demjenigen bearbeitet werden, der diese erstellt hat. Eine Zusammenfassung ber alle URLs und deren Filter sind im Wiki1 aufgelistet und als Screenshot A.2, A.3 und A.4 im Anhang zu nden.
https://pads.fh-schmalkalden.de/wiki/spirit/database/specification
Benjamin Ldicke
Seite 60 von 95
7. Realisierung
7.2.3 Helfer-Klassen
In diesem Abschnitt werden Klassen vorgestellt, welche nicht direkt im Zusammenhang mit dem Datenmodell oder der REST-Schnittstelle stehen. Diese Klassen sind in Abbildung 7.4 zusammengefasst. Die Schnittstelle FormatedException stellt eine allgemeine Struktur fr Fehlermeldungen bereit. Die Methode getErrorAsJson() liefert ein JSON-String zurck, welcher bei einem Fehler an den aufrufenden Client gesendet wird. Ferner kann die Fehlermeldung ber den Konstruktor gendert werden. Damit zustzlich zu der Fehlermeldung auch der http-Header angepasst wird, muss die Methode getHttpStatusCode() aufgerufen werden. Diese Statuscodes sind im RFC 2616 speziziert und somit fr alle Clients verstndlich. In der folgenden Tabelle 7.1 sind die im Datenbank-Service denierten Fehlermeldungen zusammengefasst. Klasssenname FindByCriteriaException MappingException Beschreibung wenn die Ergebnismenge eines lesenden Datenbankzugris leer ist wenn die gesendete Datenstruktur an den REST-Schnittstelle nicht auf das Datenmodell projiziert werden kann wenn versucht wird ein Datensatz zu ndern ohne dessen Eigentmer/Ersteller zu sein wenn unbekannte Fehler auftreten die nicht behandelt werden, da noch keine eigene Klasse fr diese Fehlermeldung implementiert ist wenn eine CRUD-Operation aufgerufen wird die noch nicht implementiert ist
PermissionException UnknownErrorException
UnsupportedOperationException
Tabelle 7.1: Fehlerklassen im Datenbank-Service Die Klasse Helper passt das Datum an das ISO 8601 speziziert Format an. Weil bei den Abfrage-Parametern Leerzeichen als Wert nur umstndlich zu erzeugen sind, ist das Datumsformat als yyyyMMddHHmmss festgelegt wurden. Beim senden als JSONString jedoch, wird das ISO 8601 spezizierte Format yyyy-MM-dd HH:mm:ss bertragen, um das Datum besser lesbar zu machen. Ferner wird es in diesem Format in der Datenbank abgespeichert. In der Klasse MyDB wird eine Instanz der Klasse DAOFactory gehalten. Erzeugt wird die Instanz in der Klasse Boot, welche ein Anpassen des Lift-Frameworks ermglicht. Ferner wird in dieser Klasse die HttpBasic-Authentication umgesetzt.
Benjamin Ldicke
Seite 61 von 95
7. Realisierung
Abbildung 7.4: Helfer-Klassen des Datenbank-Service
Benjamin Ldicke
Seite 62 von 95
8 Implementierung
Dieses Kapitel verdeutlicht, wie die REST-Schnittstelle im Datenbank-Service umgesetzt ist und wie Ressourcen durch die Http-Basic-Authentication geschtzt werden knnen. Ferner wird erlutert wie PostgreSQL mittels EclipseLink an den DatenbankService gekoppelt sowie das Datenmodell zu PostgreSQL bertragen wird. Abschlieend wird auf das Erstellen und Ausfhren von Expressions anhand der Klassen ELNewsDAO und AbstractPersistence eingegangen.
8.1 Die REST-Schnittstelle und Http-Basic-Authentication

In diesem Abschnitt wird erlutert wie die REST-Schnittstelle mittels des LiftFramework umgesetzt wird. Dabei werden die Klassen Boot, ServiceApi, Invoke und WithBody nher beschrieben. Das in Abbildung 7.2 dargestellte Klassendiagramm, zeigt die Beziehung zwischen diesen Klassen.
8.1.1 Die Klasse Boot
Abbildung 8.1: Abbildung der Klasse Boot Die Klasse Boot ist in Abbildung 8.1 dargestellt. Sie hat lediglich eine Methode, welche beim Starten des Datenbank-Service ausgefhrt wird. Die Aufgabe dieser Methode besteht darin, die Umgebungsvariablen von Lift zu manipulieren und Nutzerrollen fr den Zugri auf Ressourcen zu erstellen. Im Listing 8.1 ist die Methode boot abgebildet.
1 2 3 4 5 6
def boot { val roles = AuthRole ( " Admin " , AuthRole ( " Standard " ) )
Benjamin Ldicke
Seite 63 von 95
8. Implementierung
7 8
10
11
12 13 14
LiftRules . httpAuthProtectedResource . append { // case Req (_ :: _ , _ , PutRequest ) = > roles . getRoleByName (" Standard ") // case Req (_ :: _ , _ , PostRequest ) = > roles . getRoleByName (" Standard ") // case Req (_ :: _ , _ , DeleteRequest ) = > roles . getRoleByName (" Standard ") case Req ( " protected " :: Nil , _ , _) = > roles . getRoleByName ( " Standard " ) } LiftRules . authentication = HttpBasicAuthentication ( " code " ) { case ( " Standard " , " Standard2011 " , req ) = > userRoles ( AuthRole ( " Standard " ) ) true case ( " Admin " , " Admin2011 " , req ) = > userRoles ( AuthRole ( " Admin " ) ) true } MyDB . factory = DAOFactory . getDAOFactory ( DAOFactory . ECLIPSELINK ) LiftRules . unloadHooks . append ( MyDB . factory . closeConnection ) LiftRules . statelessDispatchTable . append ( ServiceApi ) } Listing 8.1: Quellcode der Klasse Boot In den Zeilen 2 bis 5 werden die Nutzerrollen fr die Http-Basic-Authentication festgelegt. Dabei ist der Rolle Admin die Rolle Standard untergeordnet. Aufgrund dessen hat ein Nutzer mit der Rolle Admin mehr Rechte, als ein Nutzer mit der Rolle Standard. In den Zeilen 7 bis 12 werden URLs an die Nutzerrollen gebunden, wobei in diesem Beispiel ausschlielich die Rolle Standard verwendet wird. Durch die Angaben PutRequest, PostRequest, DeleteRequest werden alle Schreibzugrie auf allen Ressourcen gesperrt und sind nur fr Nutzer mit der Rolle Standard oder hher nutzbar. Weil nicht alle Clients derzeitig eine solche Authentizierung untersttzen, ist zu Testzwecken nur eine bestimmte URL geschtzt, wie in Zeile 11 zu erkennen ist. Abhngig davon auf welchen Host der Datenbank-Service luft, knnte die geschtzte URL zum Beispiel https://212.201.64.226:8443/fhs-spirit/protected lauten. Damit eine Ressource wirklich geschtzt ist, mssen fr die vorher denierten Nutzerrollen Zugangsdaten festgelegt werden. In den Zeilen 14 bis 20 ist zu erkennen, dass die Nutzerrolle Standard das Passwort Standard2011 und die Nutzerrolle Admin das Passwort Admin2011 haben, wobei die Benutzernamen der jeweiligen Bezeichnung der Nutzerrolle entsprechen. In der Zeile 23 wird ber die Fabrik
15 16 17 18 19 20 21 22 23
24
25 26 27
Benjamin Ldicke
Seite 64 von 95
8. Implementierung
DAOFactory EclipseLink fr die Persistenz ausgewhlt. Ferner wird Lift eine Methode bergeben, welche beim herunterfahren des Datenbank-Service aufgerufen wird. Somit wird erreicht, dass die Verbindung zur Datenbank und EclipseLink ordnungsgem beendet wird. Abschlieend wird Lift so konguriert, dass keine Sessions verwaltet werden und der Datenbank-Service somit als zustandslos gilt.
8.1.2 Die Klasse ServiceApi
Abbildung 8.2: Abbildung der Klasse ServiceApi Das Objekt ServiceApi ist in Abbildung 8.2 abgebildet. Seine Aufgabe ist es, die URLs fr die Ressourcen zu denieren. Dabei wird nach den http-Methoden PUT, POST, GET und DELETE unterschieden. Im Listing 8.2 ist ein Auszug des Quellcodes vom Objekt ServiceApi dargestellt.
1 2 3 4
object ServiceApi extends RestHelper { println ( " Konstruktor der Service API " ) val connector : DBConnector = new DBConnector ( MyDB . factory ) val withoutBody : Invoke = new WithoutBody val withBody : Invoke = new WithBody var lastModifiedNews : java . util . Date = new java . util . Date serve { case " news " :: " comment " :: Nil Put req = > { lastModifiedNews = new java . util . Date withBody . invoke ( req , req . params , 201 , connector . putNewsComment ) } case " news " :: AsLong ( news _ id ) :: " comment " :: Nil Get req = > { var params = req . params params += ( " news _ id " -> List ( news _ id . toString ) ) withoutBody . invoke ( req , params , 200 , connector . getNewsComment ) } case " news " :: " comment " :: Nil Get req = > {
5 6 7
8 9 10 11 12
13 14
15 16 17
18 19
Benjamin Ldicke
Seite 65 von 95
8. Implementierung
20
withoutBody . invoke ( req , req . params , 200 , connector . getNewsComment ) } case " news " :: " comment " :: AsLong ( comment _ id ) :: Nil Get req = > { var params = req . params params += " comment _ id " -> List ( comment _ id . toString ) withoutBody . invoke ( req , params , 200 , connector . getNewsComment ) } } // Delete serve { case " news " :: " comment " :: AsLong ( comment _ id ) :: Nil Delete req = > { var params = req . params params += " comment _ id " -> List ( comment _ id . toString ) withoutBody . invoke ( req , params , 200 , connector . deleteNewsComment ) } } // Post serve { case " news " :: " comment " :: AsLong ( comment _ id ) :: Nil Post req = > { var params = req . params params += " comment _ id " -> List ( comment _ id . toString ) withBody . invoke ( req , params , 201 , connector . postNewsComment ) } case _ = > NotFoundResponse ( " Bad URI " ) } } Listing 8.2: Auszug des Quellcodes vom Objekt ServiceApi In der Zeile 1 ist zu erkennen, dass das Objekt ServiceApi von der Klasse RestHelper aus dem Paket net.liftweb.http.rest erbt. Somit wird ermglicht, dass die URLs in dem serve-Block erstellt werden knnen. Um den Aufbau der REST-Schnittstelle zu verdeutlichen, wird als Beispiel die API fr das Erstellen, Lesen, ndern und Lschen von Kommentaren verwendet. In der Zeile 10 bis 13 ist dargestellt, wie die URL fr das Erstellen eines Kommentars im neuen Informationsund Planungssystem implementiert ist. Durch :: wird die URL konstruiert und mit Nil abgeschlossen. Put gibt an, dass nur Anfragen mit der http-Methode PUT fr diese URL zugelassen sind und in req ist die komplette http-Anfrage hinterlegt. Fr die Unterscheidung der einzelnen URLs verwendet Scala pattern matching, was durch das Schlsselwort case eingeleitet wird. In der Zeile 11 wird das Datum der
21 22
23 24 25
26 27 28 29 30
31 32 33
34 35 36 37 38
39 40 41
42 43 44 45
Benjamin Ldicke
Seite 66 von 95
8. Implementierung
Variable lastModiefiedNews gesetzt, um eine Vernderung bei den Nachrichten zu verdeutlichen. Diese Variable ist nur zu Testzwecken implementiert, wobei jeweils eine Variable fr Nachrichten und Kommentare zu deklarieren ist, um zwischen nderungen dierenzieren zu knnen. Da ein neuer Kommentar angelegt werden soll, sind im http-Body Daten vorhanden die ausgewertet werden mssen. Aus diesem Grund wird withBody.invoke() aufgerufen. Als Parameter bekommt die Methode invoke() die komplette http-Anfrage, die Anfrage-Parameter und den Statuscode der bei erfolgreichen Anlegen des Kommentars zurckgesendet wird und eine Methode bergeben. Die bergebene Methode wird in der Klasse Invoke() ausgefhrt, wo auch die Konvertierung in das angeforderte Datenbertragungsformat stattndet. In den Zeilen 14 bis 18 ist zu sehen, wie die Kommentare einer bestimmten Nachricht abgefragt werden knnen. Dafr ist es notwendig die ID der Nachricht in der URL anzugeben. Durch AsLong() wird berprft, ob sich die ID in einen Wert des Datentyp Long konvertieren lsst. Ist dies der Fall, wird die ID in der Variable news_id gespeichert und im folgenden den Anfrage-Parametern hinzugefgt. Aufgrund dessen, dass es sich um die http-Methode GET handelt, wird without.invoke() aufgerufen und der http-Body nicht ausgewertet. Die folgenden Codezeilen sind hnlich und unterscheiden sich nur anhand der URL oder der verwendeten http-Methode.
8.1.3 Die abstrakte Klasse Invoke
Abbildung 8.3: Abbildung der abstrakten Klasse Invoke In der Abbildung 8.3 ist die abstrakte Klasse Invoke dargestellt. Sie ist fr die Konvertierung der zurckzusendenden Daten in das vorgegebene Datenbertragungsformat verantwortlich. Ferner werden unbehandelte Fehler abgefangen, um eine geeignete Fehlermeldung zurckzugeben. Im Listing 8.3 ist der komplette Quellcode der abstrakten Klasse Invoke abgebildet.
1 2 3
abstract class Invoke { protected implicit def toXml ( json : JValue ): Node = < root > { Xml . toXml ( json ) } </ root > protected implicit def toJson ( xml : Node ): JValue = Xml . toJson ( xml )
4 5 6 7
Benjamin Ldicke
Seite 67 von 95
8. Implementierung
10 11
12
13 14 15 16 17
protected def responseBuilder ( req : Req , code : Int , msg : JValue ): LiftResponse = { req . accepts match { case Full ( " application / json " ) = > JsonResponse ( msg , Nil , Nil , code ) case Full ( " application / xml " ) = > XmlResponse ( msg , code , " " , Nil ) case _ = > new UnsupportedMediaTypeResponse } } def invoke ( req : Req , params : Map [ String , List [ String ]] , successCode : Int , f: ( JValue , Map [ String , List [ String ]]) = > JValue ): LiftResponse = { try { start ( req , params , successCode , f ) } catch { case ex : code . exceptions . FormatedException = > responseBuilder ( req , ex . getHttpStatusCode , ex . getErrorAsJson ) case err = > { println ( err . printStackTrace ) val ex = new code . exceptions . UnknownErrorException responseBuilder ( req , ex . getHttpStatusCode , ex . getErrorAsJson ) } } } protected def start ( req : Req , params : Map [ String , List [ String ]] , successCode : Int , f: ( JValue , Map [ String , List [ String ]]) = > JValue ): LiftResponse } Listing 8.3: Quellcodes der abstrakten Klasse Invoke Die Methode responseBuilder() in den Zeilen 9 bis 15 berprft den Header der http-Anfrage, ob JSON oder XML als Datenbertragungsformat untersttzt werden. Ist dies nicht der Fall, wird eine UnsupportedMediaTypeResponse an den Client zurckgesendet. Untersttzt der Client XML als Datenbertragungsformat wird eine XmlResponse erzeugt, die als Parameter den Inhalt fr den http-Body und den http-Statuscode bergeben bekommt. Aufgrund dessen, dass die Variable msg vom Datentyp JValue und nicht vom erwarteten Datentyp Node ist, muss eine
18
19 20 21 22
23 24 25
26
27 28 29 30 31
32
33 34
Benjamin Ldicke
Seite 68 von 95
8. Implementierung
Konvertierung durchgefhrt werden. Dafr ist die Methode toXml() verantwortlich. Das Schlsselwort implicite gibt an, dass diese Methode automatisch aufgerufen wird, sobald eine Konvertierung bentigt wird. Weil der Rckgabetyp beim Aufruf Xml.toXml(json) eine NodeSequence und kein Node ist, wird das Ergebnis noch in das XML-Element root verpackt. In der Methode invoke() ist die zu berschreibende Methode start() eingebettet. Dadurch ist es mglich, den Quellcode fr die Fehlerberprfung nur einmal zu implementieren, wobei die Funktionalitt in der Methode start() austauschbar ist. Diese Umsetzung wird als StrategieEntwurfsmuster bezeichnet. Tritt innerhalb der Methode start() ein unbekannter Fehler auf, wird eine UnknownErrorException erzeugt und dem Client zurckgesendet. In den Zeilen 25 und 26 ist zu erkennen wie diese Fehlermeldung an die Methode responseBuilder() bergeben wird.
8.1.4 Die Klasse WithBody
Abbildung 8.4: Abbildung der Klasse WithBody Die Klasse WithBody ist in Abbildung 8.4 dargestellt. Sie ist fr das Konvertieren des http-Body in den Datentyp JValue verantwortlich und besteht aus zwei Methoden. Im Listing 8.4 ist der Quellcode der Klasse abgebildet.
1 2 3 4 5 6 7 8 9 10 11 12 13
class WithBody extends Invoke { private def bodyToJson ( req : Req ): Box [ JValue ] = { req . contentType match { case Full ( " application / json " ) = > { req . json } case Full ( " application / xml " ) = > req . xml case _ = > Failure ( " unsupported media type " ) } } override def start ( req : Req , params : Map [ String , List [ String ]] , successCode : Int , f: ( JValue , Map [ String , List [ String ]]) = > JValue ): LiftResponse = { bodyToJson ( req ) match { case Full ( json : JValue ) = > { responseBuilder ( req , successCode , f ( json , params ) )
14
15 16 17 18
Benjamin Ldicke
Seite 69 von 95
8. Implementierung
19 20 21 22 23
} case _ = > new UnsupportedMediaTypeResponse } } } Listing 8.4: Quellcode der Klasse WithBody Die Methode start(), aus der abstrakten Klasse Invoke, wird in Zeile 13 berschrieben. Dabei wird die Methode bodyToJson() aufgerufen und geprft was im Header fr ein Content-Type angegeben ist. Falls der http-Body XML enthlt, ndet eine implizite Konvertierung in den Datentyp JValue statt. Sollte der Content-Type jedoch leer oder kein untersttztes Datenbertragungsformat angegeben sein, wird ein Fehler zurckgegeben.
8.2 EclipseLink und PostgreSQL

In diesem Abschnitt wird beschrieben wie EclipseLink eine Verbindung mit PostgreSQL aufbaut und das Datenmodell mit EclispeLink verbunden werden kann.
8.2.1 Das Datenmodell und EclipseLink
Abbildung 8.5: Abbildung der Klassen News und NewsComment Das in Kapitel 6 vorgestellte Datenmodell soll mittels EclipseLink in PostgreSQL abbgebildet werden. Um das zu ermglichen, muss EclipseLink das Datenmodell kennen und die Beziehungen zwischen den Klassen verstehen. Dafr kann entweder die Datei orm.xml im Verzeichnis \resources\META-INF hinterlegt und konguriert werden oder es wird in den jeweiligen Klassen ber Annotationen die Konguration vorgenommen. Zugunsten einer loseren Kopplung zwischen Konguration und Abbildung des Datenmodells im Quellcode, hat sich der Autor fr das Kongurieren der
Benjamin Ldicke
Seite 70 von 95
8. Implementierung
Datei orm.xml entschieden. Weil der komplette Inhalt der Datei sehr umfangreich ist, wird beispielhaft an den Klassen News und NewsComment verdeutlicht, wie ber XML das Datenmodell abgebildet wird (siehe Abbildung 8.5). Im Listing 8.5 wird dargestellt, wie die Konguration der Klassen News und NewsComment vorgenommen wird. Das Mapping einer Klasse beginnt mit den Tag <entity>, in dem der voll qualizierte Name der jeweiligen Klasse anzugeben ist. Die Methoden prePersist und preUpdate setzen das Datum von creationDate und lastModified automatisch, damit der Client dieses im http-Body nicht mitsenden muss und immer das Datum des gleichen Systems verwendet wird. Um EclipseLink diese Methoden automatisch ausfhren zu lassen, mssen die Befehle in Zeile 3 und 4 verwendeten angegeben werden. In dem folgenden Tag <attributes> werden die Attribute der Klasse beschreiben. Aufgrund dessen, dass es sich bei den IDs der Klassen um automatisch generierte Werte handeln soll, muss eine Sequenz in PostgreSQL erstellt werden. Auch hierfr ist es nicht notwendig extra PostgreSQL anzupassen. EclipseLink bietet einen Sequenzgenerator, welcher konguriert werden kann und spter in PostgreSQL bernommen wird. In den Zeilen 7 bis 10 ist zu erkennen, wie fr das Attribut news_id ein Sequenzgenerator mit dem Namen und der Sequenzbezeichnung seq_news erstellt wird. Ferner beginnt die Sequenz mit dem Wert 1, welcher beim Einfgen eines neuen Tupel um den Wert 1 inkrementiert wird. In den Zeilen 11 bis 13 wird beschrieben wie das Attribut content abgebildet wird. Da der Inhalt einer Nachricht sehr gro sein kann, entschied sich der Autor die Anzahl der Zeichen auf den Wert 5.000 festzulegen, wobei content in PostgreSQL auf den Datentyp Varchar abgebildet wird. Die folgenden Attribute creationDate, expireDate und lastModified haben den Datentyp TimeStamp. hnlich wie die Klasse News wird auch die Klasse NewsComment abgebildet. Der einzige Unterschied ist das Kongurieren der Beziehung zwischen den beiden Klassen. Wie in Abbildung 8.5 zu erkennen ist, besteht zwischen den Klassen eine 1:N Beziehung. Das bedeutet, eine Nachricht kann keine oder mehrere Kommentare haben und ein Kommentar gehrt immer zu genau einer Nachricht. Ferner sollen alle Kommentare gelscht werden, wenn die Nachricht gelscht wird zu der sie gehren. Dies wird als kaskadierendes Lschen bezeichnet. In den Zeilen 26 bis 31 wird gezeigt, wie die Beziehung seitens News konguriert werden muss. Der Tag <one-to-many> gibt an, dass es sich um eine 1:N Beziehung handelt. Ferner wird innerhalb des Tags, die Variable der Gegenseite benannt, mit der die Beziehung umgesetzt wird. In diesem Fall heit diese news. Durch den Tag <cascade-on-delete> wird das kaskadierende Lschen aktiviert und <cascade-all> veranlasst das weiterreichen aller Operationen. Somit wird zum Beispiel das Update eines Tupel in der anderen Klasse sichtbar. Um die Beziehung auf der Gegenseite, also fr die Klasse NewsComment, zu kongurieren muss der Tag many-to-one verwendet werden. Ferner muss das Attribut news_id der Klasse News angegeben werden, da dieses als Primrschlssel verwendet wird.
1 2 3 4 5 6
< entity class =" code . model . News " > < table name =" News " / > <pre - persist method - name =" prePersist " / > <pre - update method - name =" preUpdate " / > < attributes > < id name =" news _ id " >
Benjamin Ldicke
Seite 71 von 95
8. Implementierung
8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
< sequence - generator name =" seq _ news " sequence - name =" seq _ news " initial - value =" 1 " allocation - size =" 1 " / > < generated - value generator =" seq _ news " / > < column name =" news _ id " / > </ id > < basic name =" content " > < column length =" 5000 " / > </ basic > < basic name =" creationDate " > < temporal > TIMESTAMP </ temporal > </ basic > < basic name =" expireDate " > < temporal > TIMESTAMP </ temporal > </ basic > < basic name =" lastModified " > < temporal > TIMESTAMP </ temporal > </ basic > [...] <one - to - many name =" comment " mapped - by =" news " > < cascade - on - delete > true </ cascade - on delete > < cascade > < cascade - all / > </ cascade > </ one - to - many > </ attributes > </ entity > < entity class =" code . model . NewsComment " > < table name =" NewsComment " / > <pre - persist method - name =" prePersist " / > < attributes > < id name =" comment _ id " > < sequence - generator name =" seq _ newscomment " sequence - name =" seq _ newscomment " initial - value =" 1 " allocation - size =" 1 " / > < generated - value generator =" seq _ newscomment " / > < column name =" comment _ id " / > </ id > < basic name =" content " > < column length =" 5000 " / >
28 29 30 31 32 33 34 35 36 37 38 39 40
41 42
43 44 45 46
Benjamin Ldicke
Seite 72 von 95
8. Implementierung
47 48 49 50 51 52 53 54 55 56 57 58
</ basic > < basic name =" creationDate " > < temporal > TIMESTAMP </ temporal > </ basic > [...] < many - to - one name =" news " > < join - column name =" news _ id " / > </ many - to - one > </ attributes > </ entity > Listing 8.5: Auszug des ORM-Mapping der Klassen News und NewsComment in EclipseLink
8.2.2 Anbinden von PostgreSQL an EclipseLink

Nachdem beschrieben wurde wie das Datenmodell mit EclipseLink verbunden ist, mssen die Zugangsdaten fr die verwendete Datenbank an EclipseLink bergeben werden. Diese Konguration wird in der Datei persistence.xml vorgenommen. Im Listing 8.6 ist ein Auszug aus dieser Datei abgebildet.
1
< persistence - unit name =" TestUnit " transaction - type =" RESOURCE _ LOCAL " > < provider > org . eclipse . persistence . jpa . PersistenceProvider </ provider > < class > code . model . Member </ class > < class > code . model . MemberEvent </ class > < class > code . model . Lecturer </ class > < class > code . model . News </ class > < class > code . model . NewsComment </ class > < class > code . model . DegreeClass </ class > < class > code . model . Event </ class > < class > code . model . Appointment </ class > < class > code . model . Location </ class > < properties > < property name =" javax . persistence . jdbc . driver " value =" org . postgresql . Driver " / > < property name =" javax . persistence . jdbc . url " value =" jdbc : postgresql : //127.0.0.1 : 5432/ Spirit " / > < property name =" javax . persistence . jdbc . user " value = " admin " / > < property name =" javax . persistence . jdbc . password " value =" 123456 " / >
3 4 5 6 7 8 9 10 11 12 13 14 15
16
17
18
Benjamin Ldicke
Seite 73 von 95
8. Implementierung
19
20
21
22
23 24 25
<! - - < property name =" eclipselink . ddl - generation " value =" drop - and - create - tables " / > --> <! - - < property name =" eclipselink . ddl - generation " value =" create - tables " / > --> <! - - < property name =" eclipselink . logging . level " value =" FINEST " / > --> <! - - < property name =" eclipselink . logging . file " value =" output . log " / > --> </ properties > </ persistence - unit > Listing 8.6: persistence.xml Dabei ist zu erkennen, wie eine persistence-unit1 mit dem Namen TestUnit deniert wird (auf diesen Namen wird spter im Quellcode verwiesen, um eine Verbindung zu PostgreSQL aufzubauen). Der Transaktionstyp RESOURCE_LOCAL gibt an, dass die Anwendung fr Transaktionen verantwortlich ist. Wird als Transaktionstyp JTA2 angegeben, wird die Verantwortung an den Anwendungs-Server abgegeben3 und es knnen somit verteilte Transaktionen durchgefhrt werden. In der Zeile 2 wird festgelegt, dass EclipseLink als JPA-Provider verwendet wird. Wrde Hibernate als ORM-Mapper genutzt werden, muss stattdessen org.hibernate.ejb. HibernatePersistence dangegeben werden. Ferner muss der passende JDBC-Treiber im Ordner lib_managed hinterlegt sein. Anschlieend werden alle Klassen aufgelistet, welche durch diese persistence-unit verwaltet werden sollen. Die eigentliche Konguration der Datenbank erfolgt innerhalb des Tags <properties>. Dabei muss der Treiber fr die verwendete Datenbank, die HostAdresse, der Nutzername und ein Passwort angegeben werden, um den Zugri auf die Datenbank zu ermglichen. Ferner kann durch die auskommentierten Tags veranlasst werden, dass bei jedem Neustart des Datenbank-Service das Datenmodell in PostgreSQL erstellt wird, sofern dies noch nicht in der Datenbank existiert. Zustzlich kann zu Testzwecken der Datenbankzugri aufgezeichnet und in der Datei outlog.log analysiert werden.
8.2.3 Datenbankabfragen mit EclipseLink

Durch die Verwendung von EclipseLink ist es mglich, Expressions anstelle von SQL-Abfragen zu nutzen. Dies hat, wie in Kapitel 5.4 aufgelistet, einige Vorteile. Anhand der Klassen ELNewsDAO und AbstractPersistence (siehe Abbildung 8.6) wird beschrieben, wie Expressions im Datenbank-Service genutzt werden, um Zugri auf die Datenbank zu erhalten.
1 2
in der persistence-unit werden bestimmte Kongurationen gruppiert (J)ava (T)ransaction (A)PI 3 in dieser Master-Thesis wurde Tomcat 6 verwendet, welcher kein JTA beinhaltet - soll Tomcat dennoch mit JTA verwendet werden, muss ein JTA-Manager, wie zum Beispiel Atomikos, nachinstalliert werden
Benjamin Ldicke
Seite 74 von 95
8. Implementierung
Abbildung 8.6: Abbildung der Klassen ELNewsDAO und AbstractPersistence Die Klasse ELNewsDAO implementiert die Schnittstelle NewsDAO und wird von der Klasse AbstarctPersistence abgeleitet. Aufgrund dessen hat sie vier Methoden zum Erzeugen, Lesen, ndern und Lschen von Daten. Bevor jedoch an einem Beispiel der Quellcode beider Klassen erlutert wird muss geklrt werden, wie Transaktionen in EclipseLink umzusetzen sind. Dabei ist es wichtig zu wissen, dass EclipseLink keine verschachtelten Transaktionen erlaubt. Wird also eine Transaktion gestartet, darf keine weitere Transaktion gestartet werden, ohne die vorherige Transaktion zu beenden. Die Verwaltung von Transaktionen wird von der Klasse EntityManager bernommen. Angelegt wird eine Instanz dieser Klasse immer, wenn eine Instanz von den EclipseLink DAO-Klassen erzeugt wird. Wird eine solche Klasse innerhalb einer anderen EclipseLink DAO-Klasse gestartet, wird eine Exception mit der Meldung Transaction already active geworfen. Um dieses Problem zu umgehen, mssen allen weiteren EclipseLink DAO-Klassen den bereits erstellten Entitymanger bergeben bekommen und das Starten weiter Transaktion unterbunden werden. Im Beispiel sollen alle Nachrichten zurckgegeben werden, welche zu den Kursen mit den IDs 2 und 3 gehren. Die URL dafr knnte folgendermaen aufgebaut sein: https://212.201.64.226:8443/fhs-spirit/news?class_id=2&class_id=3 Das Sequenzdiagram in Abbildung 8.7 zeigt den korrekten Ablauf dieser Abfrage4 .
Abbildung 8.7: Sequenzdiagramm - Abfrage nach alle Nachrichten zu den Kursen mit den IDs 2 und 3
4
wie das Sequenzdiagramm aussieht wenn der Entitymanger nicht weitergegeben wird, ist im Anhang in Abbildung A dargestellt
Benjamin Ldicke
Seite 75 von 95
8. Implementierung
Im Listing 8.7 ist die Methode read() dargestellt, welche in der Klasse DBConnector aufgerufen wird.
1
2 3 4 5 6 7 8
10 11 12
13
14
15 16 17
18 19 20 21 22 23
24 25 26 27 28
def read ( params : Map [ String , List [ String ]]) : List [ News ] = { def function () : AnyRef = { val eb = new ExpressionBuilder var expressions : List [ Expression ] = Nil params . keySet foreach { key = > { key match { case " news _ id " = > return params . get ( key ) . get map ( news _ id = > getResourceById ( classOf [ News ] , news _ id . toLong ) ) case " owner " = > expressions ::= eb . get ( key ) . get ( " fhs _ id " ) . equal (( params . get ( key ) ) . get . head ) case " class _ id " = > { val degreeClassDAO = ELDegreeClassDAO ( em ) val clazzes = degreeClassDAO . read ( params ) flatMap ( degreeClassDAO . readWithSubClasses (_) ) expressions ::= concatQuerysWithOr ( clazzes map ( clazz = > eb . anyOf ( " degreeClass " ) . get ( key ) . equal ( clazz . class _ id ) ) ) } case " creationDate " = > expressions ::= { eb . get ( key ) . greaterThanEqual ( Helper . pathParamToDate ( params . get ( key ) . get . head )) } } } } if (! params . contains ( " creationDate " ) ) expressions ::= eb . get ( " expireDate " ) . greaterThan ( eb . currentDate () ) addOrderBy ( eb . get ( " lastModified " ) . descending () ) getResourceByExpression ( expressions ) } invoke ( function ) . asInstanceOf [ List [ News ]] } Listing 8.7: Quellcode der Methode read() aus der Klasse ELNewsDAO Die Methode read() gibt eine Liste von Nachrichten zurck, wenn bestimmte Filterkriterien zutreen. Diese Filterkriterien werden ber die Variable params be-
Benjamin Ldicke
Seite 76 von 95
8. Implementierung
reitgestellt. In der Zeile 2 ist zu erkennen, dass innerhalb der Methode read() eine zweite Funktionen deniert wird, welche als Rckgabetyp AnyRef hat. Diese Funktion beinhaltet die eigentliche Funktionalitt und wird in Zeile 27 der Methode invoke(), welche von AbstractPersistence geerbt wurde, bergeben. Dabei kommt das Strategie-Entwurfsmuster zum Einsatz, um den Code fr die Transaktionsverwaltung nur einmal implementieren zu mssen. In der Funktion function() wird eine Instanz der Klasse ExpressionBuilder erzeugt, damit Expressions verwendet werden knnen. Ferner gilt, dass fr jeden Filter eine eigene Expression erzeugt und in der Liste expressions abgelegt wird. In der Zeile 5 wird die Liste der keys durchlaufen und mittels pattern matching geprft, ob ein Filterkriterium angegeben wurde. In der Zeile 10 wird der Filter class_id behandelt. Weil die zu lternden Kurse nicht Bestandteil einer Nachricht sind, mssen diese ber ELDegreeClass gesucht werden. Wie im Sequenzdiagramm (siehe Abbildung 8.7) abgebildet ist, wird dem Konstruktor5 der bereits erstellte Entitymanger bergeben. In der Zeile 12 wird die Methode read der Klasse ELDegreeClassDAO aufgerufen und die gesuchten Kurse zurckgegeben. Weil jedoch die zurckgegebenen Kurse Untergruppen haben knnen und Nachrichten zu diesen ebenso fr den Client interessant sein knnten, werden alle Untergruppen mit der Methode readWithSubClasses() ausgelesen. Ferner werden die Ergebnisse durch den Aufruf von flatMap in einer Liste gespeichert. Nachdem alle relevanten Kurse bekannt sind, kann die Expression erstellt werden. Zu diesem Zweck wird fr jeden Kurs eine Expression erstellt, welche anschlieend mit dem logischen Operator OR6 verknpft werden. In der Zeile 14 ist zu erkennen wie eine Expression konstruiert ist. Dabei muss der ExpressionBuilder aufgerufen werden, welcher ausgehend vom Objekt News, in der Liste degreeClass, von allen Objekten das Attribut class_id, mit den IDs der ermittelten Kurse vergleicht. Anschlieend wird das Ergebnis an die Liste expressions angehngt. In der Zeile 22 ndet eine berprfung auf den Filter creationDate statt. Ist bei diesem Filter ein Datum angegeben, werden alle Nachrichten ab diesem Datum ausgegeben und das Verfallsdatum expireDate ignoriert. Sollte der Filter creationDate nicht angegeben sein, werden nur Nachrichten zurckgegeben dessen Verfallsdatum noch nicht berschritten ist. In der Zeile 25 wird die Methode getResourceByExpression() mit der Liste expressions aufgerufen. Diese sowie die Methode concatsQueryWithOr wurden von der Klasse AbstractPersistence geerbt. Ein Auszug des Quellcodes der Klasse AbstractPersistence ist im Listing 8.8 dargestellt.
1
abstract class AbstractPersistence [ T <: AnyRef : ClassManifest ]( em : EntityManager ) { private [ this ] val readAll = new ReadAllQuery ( classManifest [ T ]. erasure ) def concatQuerysWithOr ( exp : List [ Expression ]) : Expression = { val complex : Expression = null exp . foldLeft ( complex ) {
genau genommen ist das der Aufruf des companion Objekt, welches die Methoden apply() und apply(em: EntityManager) anbietet, in denen eine Instanz erzeugt und zurckgegeben wird 6 Oder-Verknpfung
5
3 4
5 6
Benjamin Ldicke
Seite 77 von 95
8. Implementierung
7 8 9 10 11 12 13
case (r , c ) if ( r == null && c != null ) = > c case (r , c ) if ( r != null && c != null ) = > r . or ( c ) case (r , c ) if ( r == null || c == null ) = > r } } def addOrderBy ( orderExpression : Expression ): Unit = readAll . addOrdering ( orderExpression ) def getResourceByExpression ( expressions : List [ Expression ]) : List [ T ] = { val jpaEm = JpaHelper . getEntityManager ( em ) val exp : Expression = concatQuerysWithAnd ( expressions ) readAll . setSelectionCriteria ( exp ) val query : Query = jpaEm . createQuery ( readAll ) val result : List [ T ] = query . getResultList . toList . asInstanceOf [ List [ T ]] if ( result . isEmpty ) throw new FindByCriteriaException result } def invoke ( f: () = > AnyRef ): AnyRef = { var tx : EntityTransaction = em . getTransaction try { if (! tx . isActive ) tx . begin val newObj = f () if (! tx . isActive ) tx . commit newObj } catch { case ex : code . exceptions . FormatedException = > { if (! tx . isActive ) tx . rollback throw ex } case ex = > { if (! tx . isActive ) tx . rollback () throw new code . exceptions . UnknownErrorException } } finally { if (! tx . isActive ) em . close } }} Listing 8.8: Auszug des Quellcodes der Klasse AbstractPersistence In der Zeile 1 ist zu erkennen das die Klasse AbstractPersistence den Entity-
14 15
16 17
18 19 20
21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
Benjamin Ldicke
Seite 78 von 95
8. Implementierung
manger bergeben bekommt. Ferner wird festgelegt welche Typen T reprsentieren darf. Die Angabe des ClassManifest ist notwendig, da Typen in Scala auf type erasure7 basieren. In diesem ClassManifest sind alle Informationen vorhanden, um T den passenden Typen zuzuordnen [Bra11, S. 156]. In der Zeile 3 wird eine Instanz von ReadAllQuery erzeugt. ReadAllQuery ermglicht es Expressions um bestimmte Funktionen zu erweitern, wie es in Zeile 15 dargestellt ist (hinzufgen eines order by). Die in der Methode concatQuerysWithOr wird zum konkatenieren der Expressions verwendet und ist in den Zeilen 5 bis 12 dargestellt. Die Liste expressions wird durch den Aufruf von foldLeft rekursiv durchlaufen, wobei die Variable r der Akkumulator und die Variable c das aktuelle Elemente der Liste darstellt. Ferner wird als Startwert eine Expression mit null initiiert. Die drei folgenden Zeilen Quellcode werden so oft durchlaufen, bis alle Element der Liste expressions abgearbeitet sind. In der Zeile 8 wird geprft, ob der Akkumulator leer ist und ein Element vorhanden ist. Ist diese Bedingung wahr, ist das Ergebnis das aktuelle Element. In der Zeile 9 wird berprft ob der Akkumulator nicht leer ist und ein Element vorhanden ist. Ist diese Bedingung wahr, wird das aktuelle Element an das Element im Akkumulator angehngt. In der Zeile 10 wird geprft, ob weder im Akkumulator oder das aktuelle Element leer ist. Ist dies der Fall, wird der leere Akkumulator zurckgegeben. In der Methode getResourcebyExpression() werden alle Expressions (Filter) mit der Methode concatQuerysWithAnd konkateniert. Diese Methode ist mit concatQuerysWithOr identisch, bis auf dass die Expressions in diesem Fall mit dem logischen Operator AND8 verknpft werden. Anschlieend ndet in den Zeilen 21 und 22 eine Konvertierung der Expressions in ein SQL-Statement statt, welches in Zeile 23 ausgefhrt wird. Abschlieend wird die Methode invoke() vorgestellt, welche die in read() implementierte Funktion ausfhrt. Um alle Datenbankzugrie in einer Transaktion auszufhren, muss eine Instanz vom Typ EntityTransaction erzeugt werden. Das wird durch den Aufruf der Methode getTransaction() vom Entitymanager erreicht. Aufgrund dessen, dass keine verschachtelten Transaktionen in EclipseLink untersttzt werden, muss vor dem Starten einer Transaktion geprft werden, ob schon eine andere Transaktion aktiv ist. Ist keine Transaktion aktiv, kann ber die Methode begin() eine neue Transaktion gestartet und die bergebene Funktion ausgefhrt werden. Sofern keine Fehler bei der Ausfhrung aufgetreten sind, werden die nderungen durch den Aufruf commit() in der Datenbank persistent gemacht. Ist jedoch ein Fehler aufgetreten knnen alle nderungen vom Start der Transaktion bis zum Auftreten des Fehlers, durch die Methode rollback() rckgngig gemacht werden.
[...] die Typ- parameter werden zum bersetzungszeitpunkt berprft und nach erfolgreicher Prfung entfernt [Bra11, S. 156]. 8 Und-Verknpfung
Benjamin Ldicke
Seite 79 von 95
9 Test
Fr den Produktiveinsatz muss das entwickelte System verschiedenen Tests unterzogen werden. Zum einen muss berprft werden, ob die zum Datenbank-Service gesendeten Daten korrekt verarbeitet und gespeichert werden. Und zum anderen mssen Last-Tests durchgefhrt werden, um zu ermitteln wann die Lastgrenze erreicht ist und eine horizontale oder vertikale Skalierung vorgenommen werden muss. In dieser Master-Thesis wurden bei der Entwicklung dieses Prototypen keine derartigen automatisierten Tests erstellt, um den korrekten Ablauf des Systems zu berprfen. Aufgrund dessen, dass es sich um ein berschaubares Projekt handelt, wurden Daten mittels Curl an den Datenbank-Service gesendet, abgefragt und anschlieend verglichen. Ferner wurde eine extra Anwendung1 implementiert, welche den Apache Http-Client verwendet, um grere Datenmengen zu senden oder zu empfangen. Im Listing 9.1 ist ein Auszug des Quellcodes von diesem Programm abgebildet. Zweck von diesem Test ist es, eine neue Nachricht an den Datenbank-Service zu senden und die Antwort mit den gesendeten Informationen abzugleichen.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
def main ( args : Array [ String ]) { val httpclient = new DefaultHttpClient () // News erstellen val send : JValue = " news " -> ( ( " title " -> " Test " ) ~ ( " content " -> " Das ist ein Test " ) ~ ( " expireDate " -> " 2011 -12 -24 12 : 00 : 00 " ) ~ ( " degreeClass " -> ( List (5) map ( class _ id = > ( " class _ id " -> class _ id ) ))) ~ ( " owner " -> ( " fhs _ id " -> " knolle " ) ) )) val httpput : HttpPut = new HttpPut ( " http : // localhost : 8080/ lift - sbt - template _ 2.8.1 -0.1/ news " ) ; httpput . setHeader ( " Content - Type " , " application / json " ) httpput . setHeader ( " Accept " , " application / json " ) println ( " Senden :" + pretty ( render ( send ) ) ) var sendEntity : HttpEntity = new StringEntity ( compact ( render ( send ) ) )
1
18 19 20 21
der komplette Quellcode dieser Anwendung ist auf der beigelegten CD-ROM hinterlegt
Benjamin Ldicke
Seite 80 von 95
9. Test
22 23 24 25 26
27 28 29
httpput . setEntity ( sendEntity ) val response = httpclient . execute ( httpput ) val responseEntity = response . getEntity println ( " Antwort : " + response ) val content = convertStreamToString ( responseEntity . getContent ) println ( content ) httpput . abort () } Listing 9.1: Auszug des Quellcodes zum Testen des Datenbank-Service In der Zeile 2 wird ein Objekt des Typs DefaultHttpClient erstellt und anschlieend eine neue Nachricht im JSON-Format generiert. In der Zeile 17 wird durch HttpPut angegeben, dass die http-Methode PUT verwendet werden soll. Dies ermglicht den Datenbank-Service den Zweck der Verbindung zu bestimmen. Ferner wird die URL des Datenbank-Service als String bergeben. Danach wird der httpHeader so konguriert, dass der Server ein JSON-String als Antwort sendet. Durch die Methode execute() wird die Anfrage an den Datenbank-Service gesendet und anschlieend wird die Antwort des Datenbank-Service auf der Konsole ausgegeben.
Benjamin Ldicke
Seite 81 von 95
10 Zusammenfassung und Ausblick

In dieser Master-Thesis wurde die Entwicklung und Konzeption eines Informationsund Planungssystems beschrieben. Ziel dieses Systems soll es sein, einen persnlichen Terminkalender anstelle des statischen Stundenplans zu verwenden. Somit ist es mglich nderungen am Stundenplan nachzuvollziehen und Tutorien fr bestimmte Kurse zu planen, welche im persnlichen Terminkalender angezeigt werden knnen. Auerdem soll es ermglicht werden Nachrichten, welche auf der Homepage der Fachhochschule Schmalkalden verentlicht werden, zu kommentieren. Ausgehend von Anwendungsfllen und daraus folgenden Anforderungen, sind drei Datenbanken evaluiert wurden, wobei sich PostgreSQL zusammen mit EclipseLink, laut Meinung des Autors, als beste Alternative erwies. Ferner wurde ein prototypischer Datenbank-Service mit dem Framework Lift umgesetzt, welcher die ausgewhlte Datenbank kapselt und austauschbar macht. Zustzlich ist durch Anwendung des Fabrik-Entwurfsmusters die konzipierte REST-Schnittstelle von der verwendeten Datenbank unabhngig. Fr die Verwendung im produktiven Einsatz mssten zuknftig Tests entwickelt werden, um festzustellen ob alle Erwartungen an den Datenbank-Service erfllt werden. Zustzlich knnen diese Tests hilfreich sein, um Fehler nach nderungen am Quellcode aufzudecken. Eine neue Funktionalitt, welche der Autor fr sinnvoll erachtet ist zum Beispiel eine REST-Schnittstelle fr Administratoren, wie sie im Kapitel 4 vorgestellt wurde. Ferner kann diese durch die implementierte Http-Basic-Authentication in Verbindung mit SSL geschtzt werden. Ferner wre es mglich die Authentizierung von Fachhochschulmitgliedern, welche von Clients selbstndig durchgefhrt wird, auf den Datenbank-Service zu verlagern.
Benjamin Ldicke
Seite 82 von 95
Literaturverzeichnis
[Bra11] Braun, Oliver: Scala - Objektfunktionale Programmierung. Carl Hanser Verlag Mnchen, 2011 [CBDW] Chen-Becker, Derek (Hrsg.) ; Danciu, Marius (Hrsg.) ; Weir, Tyler (Hrsg.): Exploring Lift. http://exploring.liftweb.net/master/, Abruf: 20. Jul. 2011 [EFHB10] Edlich, Stefan ; Friedland, Achim ; Hampe, Jens ; Brauer, Benjamin: NoSQL Einstieg in die Welt nichtrelationaler Web 2.0 Datenbanken. Carl Hanser Verlag Mnchen, 2010 [EH09] Eisentraut, Peter ; Helmle, Bernd: OReilly Media, Inc., 2009 PostgreSQL-Administration.
[Fie00] Fielding, Roy T.: Architectural Styles and the Design of Network-based Software Architectures, University of California, Irvine, Diss., 2000 [Fou] Foundation, Eclipse (Hrsg.): EclipseLink Documentation. http://wiki.eclipse.org/EclipseLink/Documentation_Center, Abruf: 20. Jul. 2011 [HM04] Harold, Elliotte R. ; Means, William S.: XML in a Nutshell: A Desktop Quick Reference. OReilly Media, Inc., 2004 [Jar10] Jarosch, Helmut: Grundkurs Datenbankentwurf - Eine beispielorientierte Einfhrung fr Studenten und Praktiker. Vieweg + Teubner, 2010 [KE01] Kemper, Alfons ; Eickler, Andr: Datenbanksysteme eine Einfhrung. Oldenbourg Verlag Mnchen Wien, 2001 [Kud07] Kudra, Thomas: Taschenbuch Datenbanken. Carl Hanser Verlag Mnchen, 2007 [Ori] OrientDB (Hrsg.): What is Orient? http://code.google.com/p/ orient/, Abruf: 31. Jul. 2011 [Posa] PostgreSQL (Hrsg.): Documentation of PostgreSQL. http://www. postgresql.org/docs/9.0/static/, Abruf: 12. Aug. 2011 [Posb] PostgreSQL (Hrsg.): History of PostgreSQL. postgresql.org/about/history, Abruf: 12. Aug. 2011 http://www.
Benjamin Ldicke
83
Literaturverzeichnis
[Posc] PostgreSQL (Hrsg.): Wiki of PostgreSQL. http://wiki. postgresql.org/wiki/Binary_Replication_Tutorial, Abruf: 18. Aug. 2011 [Riaa] Riak (Hrsg.): An Introduction to Riak. http://wiki.basho.com/ An-Introduction-to-Riak.html, Abruf: 10. Aug. 2011 [Riab] Riak (Hrsg.): System Requirements. http://wiki.basho.com/ System-Requirements.html, Abruf: 10. Aug. 2011 [Rie09] Rieber, Philipp: Dynamische Webseiten in der Praxis: PHP, MySQL, CSS, Javascript, XHTML und Ajax. mitp, eine Marke der Verlagsgruppe Hthig Jehle Rehm GmbH, 2009 [RR07] Richardson, Leonard ; Ruby, Sam: Web Services mit REST. OReilly Media, Inc., 2007 [Sau02] Sauer, Hermann: Relationale Datenbanken - Theorie und Praxis. Addison-Wesley, 2002 [Tit03] Tittmann, Peter: Graphentheorie eine anwendungsorientierte Einfhrung. Fachbuchverlag Leipzig, 2003 [WM] Walker-Morgan, Dj (Hrsg.): NoSQL im berblick. http://www. heise.de/open/artikel/NoSQL-im-Ueberblick-1012483.html, Abruf: 05. Jul. 2011
Benjamin Ldicke
84
A Anhang
Benjamin Ldicke
85
A. Anhang
Abbildung A.1: Statischer Stundenplan in HTML
Benjamin Ldicke
86
A. Anhang
Abbildung A.2: Interface-Spezikation Teil eins Benjamin Ldicke
87
A. Anhang
Abbildung A.3: Interface-Spezikation Teil zwei
Benjamin Ldicke
88
A. Anhang
Abbildung A.4: Interface-Spezikation Teil drei
Benjamin Ldicke
89
A. Anhang
Abbildung A.5: Sequenzdiagramm - Abfrage nach alle Nachrichten zu den Kursen mit den IDs 2 und 3 (fehlerhafter Ablauf)
Benjamin Ldicke
90
Abbildungsverzeichnis
2.1 2.2 2.3 4.1 4.2 4.3 5.1 5.2 5.3 5.4 6.1 7.1 7.2 7.3 7.4 8.1 8.2 8.3 8.4 8.5 8.6 8.7 Eigene Darstellung einer Relation in Anlehnung an [Kud07, S. 74] . . 9 Eigene Darstellung einer N:M Beziehung zwischen Relationen . . . . 10 Eigene Darstellung zur Kategorisierung von NoSQL-Systemen in Anlehnung an [EFHB10, S. 6] . . . . . . . . . . . . . . . . . . . . . . . 13 Eigene Darstellung der Miniwelt fr Informations- und Planungssystem 18 Eigene Darstellung des Anwendungsfaldiagramms ohne Einschrnkungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Eigene Darstellung des Anwendungsfaldiagramms mit Administrator als Akteur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Eigene Darstellung des PropertyGraph nach dem Aufruf der Methode create() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Eigene Darstellung des Namensraum in Riak in Anlehnung an [EFHB10, S. 157] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 Eigene Darstellung des Map/Reduce-Verfahren in Anlehnung an [EFHB10, S. 18] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Eigene Darstellung des 160 bit Hash-Ring mit vier Knoten und 32 Partitionen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Eigene Darstellung des Datenmodell des zu entwickelnden Informationsund Planungssystems . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Verarbeiten einer eingehenden Anfrage beim Datenbank-Service . . . Klassendiagramm der REST-Schnittstelle des Datenbank-Service . . . Klassendiagramm des eingebundenen Datenmodells in den DatenbankService . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Helfer-Klassen des Datenbank-Service . . . . . . . . . . . . . . . . . . Abbildung der Klasse Boot . . . . . . . . . . . . . . . . . . . . . . . Abbildung der Klasse ServiceApi . . . . . . . . . . . . . . . . . . . Abbildung der abstrakten Klasse Invoke . . . . . . . . . . . . . . . Abbildung der Klasse WithBody . . . . . . . . . . . . . . . . . . . . Abbildung der Klassen News und NewsComment . . . . . . . . . . Abbildung der Klassen ELNewsDAO und AbstractPersistence . . . Sequenzdiagramm - Abfrage nach alle Nachrichten zu den Kursen mit den IDs 2 und 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 58 59 62 63 65 67 69 70 75
. 75
A.1 Statischer Stundenplan in HTML . . . . . . . . . . . . . . . . . . . . 86 A.2 Interface-Spezikation Teil eins . . . . . . . . . . . . . . . . . . . . . 87
Benjamin Ldicke
91
Abbildungsverzeichnis
A.3 Interface-Spezikation Teil zwei . . . . . . . . . . . . . . . . . . . . . 88 A.4 Interface-Spezikation Teil drei . . . . . . . . . . . . . . . . . . . . . 89 A.5 Sequenzdiagramm - Abfrage nach alle Nachrichten zu den Kursen mit den IDs 2 und 3 (fehlerhafter Ablauf) . . . . . . . . . . . . . . . . . . 90
Benjamin Ldicke
92
Tabellenverzeichnis
2.1 2.2 5.1 5.2 6.1 6.2 6.3 6.4 6.5 6.6 6.7 7.1 http-Methoden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Teilsprachen von SQL laut [Kud07, S. 108] . . . . . . . . . . . . . . . 11 Indextypen in OrientDB . . . . . . . . . . . . . . . . . . . . . . . . . 24 Backup-Optionen in Riak . . . . . . . . . . . . . . . . . . . . . . . . 40 Objekttyp Objekttyp Objekttyp Objekttyp Objekttyp Objekttyp Objekttyp Event . . . . . Appointment . Location . . . . DegreeClass . . Member . . . . News . . . . . . NewsComment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 53 53 53 54 55 55
Fehlerklassen im Datenbank-Service . . . . . . . . . . . . . . . . . . . 61
Benjamin Ldicke
93
Listings
5.1 5.2 5.3 5.4 5.5 5.6 5.7 5.8 5.9 5.10 5.11 5.12 5.13 5.14 5.15 5.16 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 9.1 Erstellen eines Schemas in OrientDB . . . . . Create-Operation in OrientDB mit Java-API . Read-Operation in OrientDB mit Java-API . . Update-Operation in OrientDB mit Java-API Delete-Operation in OrientDB mit Java-API . Create-Operation in Riak mit Java-API . . . . Read-Operation in Riak mit Java-API . . . . Link-Walking in Riak mit Java-API . . . . . . Map/Reduce in Riak mit Java-API . . . . . . Update in Riak mit Java-API . . . . . . . . . Delete in Riak mit Java-API . . . . . . . . . . Datenbankschema fr die Beispieldatenbank in Create in PostgreSQL mit JDBC-Treiber . . . Read in PostgreSQL mit JDBC-Treiber . . . . Update in PostgreSQL mit JDBC-Treiber . . Delete in PostgreSQL mit JDBC-Treiber . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PostgreSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 25 28 29 30 33 35 36 37 38 39 43 44 45 46 46 63 65 67 69 71 73 76 77
Quellcode der Klasse Boot . . . . . . . . . . . . . . . . . . . . . . . Auszug des Quellcodes vom Objekt ServiceApi . . . . . . . . . . . . Quellcodes der abstrakten Klasse Invoke . . . . . . . . . . . . . . . Quellcode der Klasse WithBody . . . . . . . . . . . . . . . . . . . . Auszug des ORM-Mapping der Klassen News und NewsComment in EclipseLink . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . persistence.xml . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Quellcode der Methode read() aus der Klasse ELNewsDAO . . . . . Auszug des Quellcodes der Klasse AbstractPersistence . . . . . . . .
Auszug des Quellcodes zum Testen des Datenbank-Service . . . . . . 80
Benjamin Ldicke
94
Eidesstattliche Erklrung
Ich versichere an Eides Statt durch meine eigenhndige Unterschrift, dass ich die vorliegende Arbeit selbststndig und ohne fremde Hilfe angefertigt habe. Alle Stellen, die wrtlich oder dem Sinn nach auf Publikationen oder Vortrgen anderer Autoren beruhen, sind als solche kenntlich gemacht. Ich versichere auerdem, dass ich keine andere als die angegebene Literatur verwendet habe. Diese Versicherung bezieht sich auch auf alle in der Arbeit enthaltenen Zeichnungen, Skizzen, bildlichen Darstellungen und dergleichen. Die Arbeit wurde bisher keiner anderen Prfungsbehrde vorgelegt und auch noch nicht verentlicht.
Winterstein, den 28. September 2011

Ort, Datum Benjamin Ldicke
Benjamin Ldicke
95

Sprache

Evaluierung Und Kon Guration einesDBMS Sowie Die Konzeption Undentwicklung Eines Datenbank-Serviceauf Basis Von RESTful Web Servicesin Scala

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Evaluierung Und Kon Guration einesDBMS Sowie Die Konzeption Undentwicklung Eines Datenbank-Serviceauf Basis Von RESTful Web Servicesin Scala

Hochgeladen von

Copyright:

Verfügbare Formate

Masterarbeit

Fachhochschule Schmalkalden SS 2011

1.2 Das Projekt Spirit

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

1.3 Ziel der Arbeit

1.4 Vorgehensweise der Arbeit

Fachhochschule Schmalkalden SS 2011

2.1.1 Extensible Markup Language

World Wide Web Consortium

Fachhochschule Schmalkalden SS 2011

2.1.2 JavaScript Object Notation

2.2 Web-Services mit REST

2. Theoretischer Hintergrund GET PUT POST DELETE HEAD TRACE OPTION

Fachhochschule Schmalkalden SS 2011

2.3 Lift - Ein Framework fr RESTful Web Services in Scala

https://github.com/scalatra/scalatra https://github.com/jdegoes/blueeyes 8 http://liftweb.net/ 9 Object-Relational Mapping

Fachhochschule Schmalkalden SS 2011

2.4.1 Relationale Datenbanken

Abbildung 2.1: Eigene Darstellung einer Relation in Anlehnung an [Kud07, S. 74]

Fachhochschule Schmalkalden SS 2011

Abbildung 2.2: Eigene Darstellung einer N:M Beziehung zwischen Relationen

2.4.2 Die Standard Query Language

2.4.3 Denition und Kategorisierung von NoSQL

Homepage INGRES: http://www.ingres.com

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

3.2 Anforderungen an den Datenbank-Service

Fachhochschule Schmalkalden SS 2011

3.3 Anforderungen an die Datenbank

4.2 Interaktion zwischen Anwender und System

Fachhochschule Schmalkalden SS 2011

Abbildung 4.1: Eigene Darstellung Planungssystem

Fachhochschule Schmalkalden SS 2011

Abbildung 4.2: Eigene Darstellung Einschrnkungen

Fachhochschule Schmalkalden SS 2011

Fachhochschule Schmalkalden SS 2011

5 Evaluierung mglicher Datenbanken

http://code.google.com/p/orient/wiki/OrientDB_Studio http://code.google.com/p/orient/wiki/ConsoleCommands 3 (C)reate, (R)ead, (U)pdate, (D)elete

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken // // //

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5.1.5 Skalierung und Replikation

5. Evaluierung mglicher Datenbanken

Fachhochschule Schmalkalden SS 2011

5. Evaluierung mglicher Datenbanken