Konzeption und Realisierung eines - RWTH

Konzeption und Realisierung eines
Dokumentenablage- und
–recherchesystems auf Grundlage von
neuen Datenbanktechnologien
– Seminararbeit –
eingereicht von
Felix Remmel
[email protected]
Betreuer
Prof. Dr. Volker Sander
Dr. Winfried Melder-Wolff
12. Dezember 2011
Kurzfassung
Diese Seminararbeit soll die Konzeptionierung und Realisierung eines Dokumentenablageund -recherchesystems vorstellen. Das Konzept stellt die dafür genutzten Technologien vor
und erläutert warum diese genutzt werden. Zusätzlich wird im Konzept beschrieben, wie
die Technologien benutzt werden sollen und in Abhängigkeit voneinander stehen.
Die Umsetzung des Konzepts wird ebenfalls beschrieben. Die relevanten Konfigurationen
werden gezeigt und erklärt, Installationen beschrieben und Probleme die bei der Realisierung aufgefallen sind werden erläutert.
Das Dokumentenablage- und -recherchesystem wird die Möglichkeit bieten, Dokumente
im System benutzer- und rollenbezogen abzuspeichern. Rollen sind die Angestellten, Vorgesetzten und ausgewählte Mitarbeiter des Controllings. Je nach Rolle hat der Benutzer
mehr oder weniger Rechte auf Dokumente zuzugreifen und unterschiedliche Funktionen
um mit ihnen zu arbeiten.
i
ii
Inhaltsverzeichnis
1 Einleitung
1
1.1
Motivation und Ziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Vorstudienergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2 Ausgangslage
3
3 Konzept
5
3.1
3.2
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.1.1
Funktionale Anforderungen an das System . . . . . . . . . . . . . . .
5
3.1.2
Nicht funktionale Anforderungen an das System . . . . . . . . . . .
6
3.1.3
Resümee und benötigte Technologien . . . . . . . . . . . . . . . . . .
6
Auswahl der Technologien . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2.1
Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2.1.1
Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . .
7
3.2.1.2
Überblick über NoSQL Datenbanken
8
3.2.1.3
Gegenüberstellung verschiedener dokumentenorientierter NoSQL Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1.4
Solr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2
3.2.3
. . . . . . . . . . . .
Art der Anwendung . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.2.2.1
Funktionale Anforderungen . . . . . . . . . . . . . . . . . . 13
3.2.2.2
Nicht funktionale Anforderungen . . . . . . . . . . . . . . . 13
3.2.2.3
Gegenüberstellung Website - Desktopanwendung . . . . . . 13
3.2.2.4
Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.2.3.1
Jetty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3
Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4
Prozessabläufe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.4.1
Ermittlung von Login Daten der Benutzer . . . . . . . . . . . . . . . 16
iii
3.5
3.4.2
Ermittlung von Angestellten eines Vorgesetzten . . . . . . . . . . . . 16
3.4.3
Ermittlung von Dokumenten eines Angestellten . . . . . . . . . . . . 16
3.4.4
Ermittlung von unbestätigten Dokumenten der Vorgesetzten . . . . 16
3.4.5
Ermittlung der Email-Adresse eines Benutzers . . . . . . . . . . . . 16
3.4.6
Vorgesetzter weist das Dokument eines Angestellten zurück . . . . . 16
3.4.7
Suche nach Text in den Dokumenten . . . . . . . . . . . . . . . . . . 17
Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.1
Gesamtarchitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.2
Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.6
Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.7
Projektplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4 Realisierung
4.1
4.2
21
Solr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2
Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.3
Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1
Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2
Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3
Probleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.3
Jetty . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.4
Programmierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.5
Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5 Fazit und Ausblick
33
Anhang
35
Literatur
41
Abbildungsverzeichnis
43
Tabellenverzeichnis
45
iv
Kapitel 1
Einleitung
1.1
Motivation und Ziel
Atos Worldline benötigt viel Papier und Mannzeit für die Erstellung von internen Berichten. Jeder Mitarbeiter muss z. B. Monatsberichte erfassen, in denen steht, wie viel Stunden
er welcher Tätigkeit nachgegangen ist. Diese Monatsberichte werden jeden Monat von 230
Mitarbeitern angefertigt. Projektmanager müssen zusätzlich Projektmanagementreports
(PMRs) schreiben. All diese Dokumente werden ausgedruckt. Es wird also viel Papier,
das für zehn Jahre archiviert werden muss, verbraucht bei Atos Worldline. Durch hohen Papierverbrauch entstehen Kosten und die Umwelt wird belastet. Der Traum vom
papier- und medienbruchfreien Büro ist Motivation dieser Arbeit. Die Dokumente sollen
nicht mehr ausgedruckt werden, sondern digital signiert und danach gespeichert werden
können.
Das Software-System, das die Speicherung und Recherche in dem Dokumentenarchiv
ermöglicht, soll im Rahmen dieser Seminararbeit entwickelt werden. Diese Seminararbeit
stellt sowohl das Konzept als auch die Realisierung vor.
1.2
Vorstudienergebnisse
In vorlaufenden Analysen wurden die Machbarkeit eines solchen Softwaresystems untersucht.
Die Dokumente müssen eine vom Wirtschaftsprüfer zugelassene digitale Signatur enthalten. Für diesen Zweck wurden Sign Pads angeschafft. Damit ist es möglich, am Computer
Dokumente digital zu unterschreiben. Der Wirtschaftsprüfer akzeptiert diese Unterschrift.
Da im Software-System sehr viele Dokumente gespeichert werden, ist es wichtig, dass das
einzusetzende System auch bei großen Datenmengen den Inhalt der Dokumente schnell
durchsuchen kann. Zusätzlich wurde festgestellt, dass zum Abspeichern von Dokumenten in dem Dokumentenarchivierungs- und -recherchesystem keine komplexen Relationen
benötigt werden. Somit wäre ein herkömmliches relationales Datenbanksystem zu überladen. Dazu kommt, dass relationale Datenbanksystem nicht auf Textsuche in Dokumenten
optimiert sind. Vielmehr bieten sich speziell auf Volltextsuche ausgerichtete NoSQL Datenbanken an, deren hervorragende Eigenschaft es ist, schnell in großen Datenbeständen
Ergebnisse zu finden.
1
2
Kapitel 2
Ausgangslage
Bei Atos Worldline gibt es viele Dokumente, die ohne Unterschrift keine Gültigkeit besitzen. Die meisten dieser Dokumente werden an Computern erstellt und zum Unterschreiben
ausgedruckt. Es gibt interne Dokumente, wie etwa Monatsberichte oder Projektmangamentreports (PMRs), die lange aufbewahrt werden müssen, aber nur in speziellen Situationen gebraucht werden. z. B. muss jeder Mitarbeiter einmal im Monat einen Monatsbericht anfertigen, in dem steht wie viele Stunden er pro Tag an einem bestimmten Projekt
gearbeitet hat (siehe Abbildung 1 Seite 35 für ein Beispiel eines Monatsberichts). Der
Monatsbericht wird am Computer ausgefüllt, ausgedruckt und unterschrieben. Dieser unterschrieben Monatsbericht wird dann dem Vorgesetzten in das Postfach gelegt. Dort wird
er mehrmals unterschrieben und wandert in einen Ordner im Archiv. Darauf zugegriffen wird dann nur noch in Ausnahmesituationen. Dies kann z. B. passieren, wenn bei der
jährlichen Wirtschaftsprüfung Einsicht in einen bestimmten oder ein Bündel Monatsberichte verlangt wird. Diese Auswahl muss dann händisch im Archiv gesucht werden. Es ist
nicht schwer vorstellbar, dass dies eine langweilige und in Zeiten der modernen Technik
eigentlich überflüssige Aufgabe ist. Aber durch die Notwendigkeit einer rechtskonformen
Unterschrift bisher unvermeidbar war.
Ein Mitarbeiter, der auch mein Betreuer – Dr. Winfried Melder-Wolff – dieser Seminararbeit ist, ist bei Atos Worldline im Rahmen eines internen Innovations-Projektes auf
Sign Pads aufmerksam geworden. Sign Pads sind Geräte, mit denen es möglich ist Do-
Abbildung 2.1: Ein Sign Pad
kumente rechtsgültig zu unterschreiben. Das ist möglich, weil das Sign Pad nicht nur ein
Bild der Unterschrift abspeichert, sondern die gesamte Schreibcharakteristik der Unterschrift analysiert und das Ergebnis abspeichert. Durch diese Geräte ist es jetzt möglich
signierte Dokumente auf dem Computer abzuspeichern anstatt diese auszudrucken und zu
unterschreiben. Es würden sich einige Vorteile für die Firma und die Mitarbeiter ergeben:
3
• Ein Schritt Richtung Hin zum papierlosen Büros - Kosteneinsparung, Green-IT,
Innovation
• Durch das papierlose Büro wird auch der Archivraum überflüssig - mehr Platz
• Durch Datenbanktechniken lassen sich die Dokumente leichter finden - Weniger Arbeit
4
Kapitel 3
Konzept
3.1
Anforderungen
Um ein passendes Konzept zu einem IT-System zu erstellen, müssen die Anforderungen
an das System bekannt sein. Auf Grundlage der Anforderungen werde ich die Auswahl von
geeigneten Tools und Frameworks treffen können. Es gibt zwei Arten von Anforderungen,
welche die Auswahl beeinflussen.
• Funktionale Anforderungen – Sie legen fest, was das Produkt tun soll. z. B. ,,Das
Produkt soll alle Dokumente anhand von Stichworten finden können.”
• Nicht funktionale Anforderungen – Darüber werden die Eigenschaften des Produkts
definiert. z. B. ,,Das Produkt soll gesuchte Dokumente innerhalb zwei Sekunden finden können.”
3.1.1
Funktionale Anforderungen an das System
• Das System ist nicht für die Signierung der Dokumente zuständig. Die Dokumente
sind bereits signiert, wenn sie an das System übergeben werden.
• Zugangskontrolle über ein Atos Worldline internes System namens DAS muss eingebunden werden können
• verschiedene Rollen
– User (normaler Angestellter)
∗ Darf Dokumente hochladen
∗ Darf nur seine eigenen Dokumente ansehen und wenn sie vom Vorgesetzten
noch nicht bestätigt wurden bearbeiten und löschen
– supervisor (Vorgesetzter des Angestellten)
∗ Beinhaltet die Rolle des Angestellten
∗ Hat eine Gruppe von Angestellten
∗ Darf die Dokumente seiner Angestellten ansehen und mit einer aktualisierten Version (in der nur die eigene Signatur hinzugefügt wurde) ersetzen
5
∗ Muss von Angestellten hochgeladene Dokumente bestätigen oder zurückweisen. Bei Zurückweisung muss der Angestellte informiert werden.
– admin (z. B. für ausgewählte Mitarbeiter des Controllings)
∗ Beinhaltet die Rolle des Angestellten
∗ Darf alle Dokumente sehen und löschen, aber nicht bearbeiten.
• Es muss eine Rubrik für PMRs und eine für Monatsberichte geben
• Von Angestellten (user) hochgeladene und signierte Monatsberichte müssen auch
vom Vorgesetzten (supervisor) signiert werden bevor sie gültig sind.
• Von Angestellten signierte und hochgeladene PMRs sind sofort gültig
• Volltextsuche in Dokumenten muss möglich sein
• Jedes Dokumente muss dem Angestellten, der es hochgeladen hat, zugeordnet sein
3.1.2
Nicht funktionale Anforderungen an das System
• Suchergebnisse sollen bei 10 GB Daten innerhalb von einer Sekunde verfügbar sein.
• leichte Installation und Nutzbarkeit für den Anwender
• Softwareupdates sollen einfach eingespielt werden können
• neue Dokumententypen sollen einfach in das System integriert werden können
• leichte Bedienbarkeit des Programms für den Anwender
3.1.3
Resümee und benötigte Technologien
Das Dokumentenablage und -recherchesystem muss bei der Ablage und Änderung von
Dokumenten Rechte prüfen, Dokumente in Rubriken unterteilen(PMR und Monatsbericht)
und zudem so programmiert werden, dass es leicht erweiterbar ist, damit in Zukunft neue
Dokumententypen in das System aufgenommen werden können.
Für die Recherche gilt das Selbe wie für die Dokumentenablage, mit dem Unterschied, dass
die Rechte bei der Suche nach Dokumenten beachtet werden müssen. Zusätzlich muss die
Suche performant sein.
Das gesamte System soll für den Anwender leicht zu installieren sein und Änderungen am
System sollen beim Anwender leicht eingespielt werden können.
Das System soll zu Beginn mit zwei verschiedenen Dokumententypen arbeiten können.
• Projektmanagementreports (PMRs)
• Monatsberichten
Ein PMR wird hochgeladen und in der Datenbank gespeichert. Bei einem Monatsbericht
ist ein mehrschrittiger Prozess abzubilden. Bevor ein Dokument vom System als gültiger
Monatsbericht angesehen wird, muss der vom Angestellten hochgeladene Monatsbericht
von dem zugehörigen Vorgesetzten unterschrieben werden und als gültig markiert werden.
6
Der Vorgesetzte hat auch die Möglichkeit, den Monatsbericht als ungültig zu erklären,
womit das Dokument aus dem System gelöscht wird und der Angestellte automatisch per
E-Mail benachrichtigt wird.
In Zukunft sollen noch mehr Dokumententypen vom System unterstützt werden. Daher
muss das System schon jetzt so entwickelt werden, dass es sehr einfach ist, neue Dokumententypen in das System einzugliedern.
Aus diesem Resümee lässt sich schließen, dass es eine Datenbank geben muss, in welcher die Monatsberichte und PMRs mit zusätzlichen Informationen abgespeichert werden
können. Die auszuwählende Datenbank muss auf eine hohe Zugriffsperformance ausgelegt
sein. Konsistenz ist unwichtig, da extrem selten auf Dokumente zugegriffen wird und Inhalte von Dokumenten nicht geändert werden. Der Zugriff auf Dokumente geschieht z. B.
nur bei einer jährlichen Wirtschaftsprüfung. Ein gleichzeitiges Ändern von Dokumenten
passiert nur, wenn ein Vorgesetzter ein Dokument seines Angestellten als ungültig erklärt
und der Angestellte gleichzeitig sein Dokument zurückruft. In diesem Fall würde das Dokument eine Mail vom Software-System bekommen, dass der Vorgesetzte sein Dokument
als ungültig erklärt hat. Dateninkonsistenzen im System entstehen dadurch nicht.
Die Dokumente müssen über mehrere Jahre archiviert werden und vor unerlaubtem Zugriff
geschützt werden. Deshalb ist eine hohe Datensicherheit auch von Bedeutung.
Um dem Anwender des IT-Systems eine Oberfläche anzubieten, sollte eine passende Lösung,
ob Website oder Desktopanwendung, ausgewählt werden. Welche Komponenten mit welcher Begründung ausgewählt werden, soll im folgenden Kapitel erläutert werden.
3.2
Auswahl der Technologien
Nachfolgend werde ich zeigen, welche Technologien für die Realisierung des Systems verwendet werden sollen und warum. Dabei beeinflussen funktionale und nicht funktionale
Anforderungen das Ergebnis der Auswahl. Das soll dazu beitragen, dass die Auswahl objektiv und begründet ist.
3.2.1
Datenbank
Um die Dokumente abzuspeichern ist eine Datenbank sinnvoll. Aus den in Kapitel 3.1
genannten Anforderungen, lassen sich, speziell für die Datenbank geltende, neue Anforderungen ableiten.
3.2.1.1
Anforderungen
Funktionale Anforderungen
• Dokumente müssen abgespeichert werden können
• Einfache Metainformationen zu einem Dokument müssen abgespeichert werden können
– z. B. wem gehört welches Dokument, Art des Dokuments
• Volltextsuche in den Dokumenten muss möglich sein
• Backups müssen möglich sein
7
• Daten müssen aktualisierbar sein
Nicht funktionale Anforderungen
• schnelle Suche garantieren – Suchergebnisse sollen bei 10 GB Daten innerhalb von
einer Sekunde verfügbar sein
• Datenkonsistenz ist zweitrangig, da die Unternehmensinternen Prozesse eine gleichzeitige Bearbeitung von mehreren Dokumenten unwahrscheinlich machen.
• API und/oder Schnittstelle soll vorhanden sein
• neue Dokumententypen sollen einfach in das System integriert werden können
• geringe Kosten des Systems
• Support sollte vorhanden sein. Bei einem Open Source Projekt z. B. eine aktive
Community.
• gute Dokumentation
Resümee Die nicht funktionale Anforderung ,,Suchergebnisse sollen bei 10 GB Daten
innerhalb von einer Sekunde verfügbar sein” und die funktionale Anforderung ,,Volltextsuche in den Dokumenten muss möglich sein” sind zwei sehr wichtige Anforderungen, für
welche die verbreiteten RDBMs (Relational Database Management Systems) nicht optimiert sind. RDBMs sind darauf ausgelegt komplizierte Relationen abbilden zu können.
Sie wurden nicht dafür gemacht in Dokumenten, welche meist als z. B. blob abgelegt sind,
eine Volltextsuche durchzuführen. Diese Funktionen wurden zwar bei den meisten dieser
System nachgerüstet, allerdings meist nur in rudimentärer Weise. Für solche Zwecke gibt
es Datenbanken, die speziell auf Volltextsuche ausgerichtet sind. Wenn nur die Monatsberichte betrachtet werden, die in einem Jahr hochgeladen werden, sind dies bei ˜ 230
Mitarbeitern 12 ∗ 230 = 2760 Monatsberichte. Wenn ein Monatsbericht eine durchschnittliche Textlänge von 2000 Zeichen hat und davon ausgegangen wird, dass ein Zeichen ein
Byte groß ist, werden pro Jahr 2760 ∗ 2000Byte = 5520000 Byte≈ 5, 26 MB Textdaten
erzeugt, welche durchsucht werden sollen. Diese Menge ist noch sehr überschaubar, doch
steigt diese Menge jedes Jahr weiter an. Des weiteren sollen in Zukunft noch mehr Dokumente und Benutzer von dem System verwaltet werden können, was die Datenmenge
weiter ansteigen lässt. Daher muss das System auf eine performante Volltextsuche ausgerichtet sein. Die Relationen, die in der Datenbank dargestellt werden müssen, sind nicht
sehr komplex. Aus den genannten Gründen bietet sich eine NoSQL Datenbank an.
3.2.1.2
Überblick über NoSQL Datenbanken
NoSQL (not only SQL) Datenbanken verfolgen einen nicht relationalen Ansatz und konzentrieren sich auf einige spezielle Gebiete, in denen sie besonders gut sein müssen. Eines
davon ist eine gute Such-Performance bei großen Datenmengen. Dafür ist die Möglichkeit
Relationen zu definieren kaum oder gar nicht möglich. Datenkonsistenz tritt bei vielen
NoSQL Datenbanken in den Hintergrund, um eine bessere Schreibperformance zu erzielen.
Auch Datentypen sind oft nicht vorzufinden. All dies, vor allem die fehlenden Relationen,
8
erfordert ein vollkommen anderes Konzept bei der Datenbank-Modellierung als man es bei
den RDBMS gewohnt ist. Allerdings lohnt es sich bei Systemen, die große Datenmengen
verwalten, diesen Schritt zu wagen. Twitter, Facebook und Google setzen unter anderem
auf NoSQL Datenbanken, damit Terrabyte an Daten in Millisekunden durchsucht werden
können.
Merkmal
Dokumentenorientierte Datenbanken
Beispiel
Lucene, Solr, CouchDB, MongoDB, Amazon
Simple DB, elasticsearch
AllegroGraph, Core Data, DEX, Neo4j, sones
GraphDB
Google BigTable, SimpleDB
memcached
Amazon Dynamo, Apache Cassandra, Project
Voldemort
Berkeley DB, Memcachedb
Google BigTable, Hbase
Graphendatenbanken
Key-Value-Festplattenspeicher
Key-Value-Caches im RAM
Eventually-consistent-Key-Value-Speicher
Sortierte Key-Value-Speicher
Tabellenorientiert
Tabelle 3.1: Auszug von Datenbanktypen [nos]
Relevant sind für das Projekt nur dokumentenorientierte Datenbanksysteme, da nur sie
die Möglichkeit bieten den Inhalt von Dokumenten abzuspeichern, welcher anschließend
noch durchsuchbar ist.
Dokumentenorientierte Datenbanksysteme sind auf die Speicherung und das spätere Suchen von Text in den Dokumenten spezialisiert. Um die Suche so schnell wie möglich zu
machen, werden raffinierte Methoden benutzt. Eine simple und vor allem auch einfach
zu implementierende Methode wäre, alle Dokumente in die Datenbank zu speichern und
wenn ein Benutzer später einen Text sucht alle Dokumente durchzugehen und den Text
zu suchen. In der Datenbank würde das in etwa wie in Tabelle 3.2 aussehen. Die Tex1
2
3
4
Was ist das
Warum ist das so
Das ist ein Apfel.
Äpfel wachsen an Bäumen
Tabelle 3.2: Die gespeicherten Texte
te werden also ohne System abgespeichert. Wenn ein Text gesucht werden soll, werden
alle Einträge in der Tabelle durchgegangen und Treffer zurückgegeben. Die Suche nach
,,ist” und ,,das” wird die Einträge 1, 2 und 3 ausgeben. Um dieses Ergebnis zu erhalten,
müssen alle Einträge komplett durchsucht werden. Die Komplexität dieser Suche beträgt
also immer O(n2 ), auch wenn das Wort nur im ersten Text vorkommt. Die Datenbank
weiß ja nicht, ob es im letzten Eintrag der Tabelle noch ein zweites mal vorkommt. Dies
ist bei einer großen gespeicherten Menge an Text sehr langsam und daher benutzen auf
Volltextsuche ausgerichtete NoSQL Datenbanken ein besseres System.
Dieses System basiert auf dem aus Büchern bekannten Index. Sätze werden nicht einfach
1:1 übernommen, sondern sie werden analysiert und in einen Index aufgenommen. Ein aus
9
der Tabelle 3.2 erstellter Index kann wie in Tabelle 3.3 aussehen. Aus den Texten in der
Tabelle 3.2 wird dann ein Index erstellt. Wird ein Text in dem Index gesucht, muss nach
den einzelnen Wörtern gesucht werden, die bereits im Index bekannt sind. Es müssen nicht
die indizierten Texte durchsucht werden, sondern nur die indizierten Wörter. Wenn ein
Wort gefunden wird, kann anhand des Eintrags im Index festgestellt werden, in welchem
Text das Wort vorkommt. Die Suche nach ,,Was” liefert das Ergebnis (1, 1). Damit ist
die Position des Satzes und Wortes in den abgespeicherten Texten gemeint, also das Wort
eins in Satz eins der Tabelle 3.2. Dieser Index ist immer noch sehr primitiv gehalten. Die
Was
ist
das
Das
Warum
so
ein
Äpfel
Apfel
wachsen
an
Bäumen
(1,
(1, 2), (2,
(1, 3),
(3,
(2,
(2,
(3,
(3,
(4,
(4,
(4,
(4,
1)
2), (3, 2)
(2, 3)
1)
1)
4)
3)
4)
1)
2)
3)
4)
Tabelle 3.3: Der Index
Suche nach ,,Baum” würde kein Ergebnis liefern, obwohl das verwandte Wort ,,Bäume”
im Index steht. Daher werden die Texte von der Datenbank nicht nur aufgespalten und
in den Index geschoben, sondern die einzelnen Wörter werden analysiert und verwandte
Wörter mit in den Index aufgenommen. So würde nicht nur ,,Bäumen” im Index stehen
sondern auch ,,Baum” oder ,,Bäume” usw. . Außerdem wird oft komplett auf Sonderzeichen und Großschreibung verzichtet. Auch zusammenhängende Wörter können erkannt
werden. z. B. werden aus dem Text ,,wi fi” zusätzlich die Wörter ,,wi-fi” und ,,WiFi” gebildet. Diese Technik wird auch bei der Suche angewandt. Eine Suche nach ,,wi fi” würde
also auch nach ,,wi-fi” und ,,WiFi” suchen.
Durch das Indexing ergibt sich eine sehr performante Suche. Die Komplexität beträgt im
durchschnittlichen Fall nur noch O(1), wenn der Index in einer Hashtabelle steht. Dabei
kommt es auf die Art der Hashtabelle an, wie langsam das Verfahren im ungünstigsten
Fall ist. Allerdings ist der ungünstigste Fall in jedem Fall schneller als der Normalfall beim
primitiven Verfahren. z. B. beträgt die Komplexität bei einer verketteten Hashtabelle im
schlechtesten Fall O(n).
Jetzt stellt sich die Frage, welche dokumentenorientierte NoSQL Datenbank am besten zu
den aufgestellten Anforderungen passt.
3.2.1.3
Gegenüberstellung verschiedener dokumentenorientierter NoSQL Datenbanken
In der Tabelle 3.4 werden verschiedene NoSQL Datenbanken miteinander verglichen. Dabei
werden folgender Kriterien beachtet:
10
• Dokumente indizieren Kann das Datenbanksystem verschiedene Dokumententypen indizieren (PDF, Word, ...)?
• Spaltenupdate Es muss möglich sein, einzelne Spalten in der Tabelle zu aktualisieren, damit bereits im System gespeicherte Monatsberichte als bestätigt markiert
werden können.
• Volltextsuche Volltextsuche in den Dokumenten.
• Backup Gibt es eine Backupmöglichkeit, die durch das Datenbanksystem bereitgestellt wird?
• Dokumentation Die Funktionen des Datenbanksystems müssen gut dokumentiert
sein.
• Open Source Ist das Projekt ein Open Source Projekt. Wenn das nicht der Fall
ist, ist das ein Ausschlusskriterium.
Amazon
Simple DB
[ama]
CouchDB
[cou]
MognoDB
[mon]
Lucene
[luca]
elasticsearch
[ela]
Solr [sola]
Dokumente
indizieren
Spaltenupdate
Volltextsuche
Backup Dokumentation Open Source
nein
ja
ja
ja
sehr gut
nein
nein
ja
ja
ja
sehr gut
ja
nein
ja
ja
ja
sehr gut
ja
nein
ja
ja
ja
sehr gut
ja
ja
ja
ja
ja
spartanisch, da
sehr neues Projekt
ja
ja
ja
ja
ja
sehr gut
ja
Tabelle 3.4: Gegenüberstellung verschiedener dokumentenorientierter NoSQL Datenbanken
Wie in der Tabelle 3.4 zu erkennen ist, ist die NoSQL Datenbank ,,Solr” diejenige, die am
besten an die gegebenen Anforderungen passt. Auch noch interessant ist die Datenbank
,,elasticsearch”. Diese ist allerdings noch relativ jung und hat keine sehr gute Dokumentation.
Die Performance von Solr ist den Anforderungen entsprechend (siehe [lucb]). Somit fällt
die Wahl auf Solr.
3.2.1.4
Solr
Solr ist ein Suchserver, der Dokumente indiziert und dadurch performantes Suchen ermöglicht.
Die Kommunikation mit Solr erfolgt über HTTP Requests und Responses. Ein Request
11
erfolgt über den Aufruf der URL zu dem Solr Server mit Übergabe der Parameter als
HTTP GET-Request. Die Antwort ist in XML kodiert.
Solr bietet durch die vielfältigen Datentypen, die an Solr übergeben werden können, eine
sehr hohe Flexibilität in der Nutzung. Dies wird durch die von Solr genutzt Bibliothek
,,Apache Tika” realisiert [Ext]. Diese Bibliothek kann aus verschiedenen Dateitypen den
darin enthaltenen Text extrahieren. Es werden z. B. HTML-, XML-, Word-, JSON-, JARund PDF-Dateien von Tika unterstützt [tik].
Der aus den übergeben Dateien extrahierte Text wird indiziert. Diese Funktion wird nicht
von Solr zur Verfügung gestellt. Solr nutzt dafür die NoSQL Datenbank ,,Lucene” [Solb],
welche das Herz von Solr bildet. Solr bietet viele Optionen bei der Nutzung von Lucene an,
um die Nutzung so bequem und mit so wenig Programmieraufwand wie möglich zu gestalten. Die Möglichkeit, dass verschiedenste Dokumententypen indiziert werden können, wird
nicht von Lucene zur Verfügung gestellt, sondern von Solr. Wenn Lucene angesprochen
werden soll, ist dies nur mit der Nutzung der API in der Programmiersprache möglich.
Eine Nutzung ohne überhaupt ein Programm zu schreiben, wie es bei Solr möglich ist, ist
bei Lucene nicht vorgesehen.
Der an Lucene übergeben Text wird vor dem indizieren zunächst analysiert. Dafür sind
die ,,Analyzer” zuständig. Diese Analyse ist dafür zuständig mehr Suchergebnisse zu generieren. So wird die Suche nach Baum in Tabelle 3.3 kein Ergebnis bringen. Ein gut
konfigurierte Analyzer hätte aber noch die Einträge Bäume, Baums und weitere verwandte Wörter in den Index hinzugefügt.
Ein Analyzer besteht aus einem Tokenizer und keinem oder beliebig vielen Filtern. Der
Tokenizer erstellt aus einem Wort neue, von diesem Wort abhängige, Wörter. Zu diesem
Zweck gibt es verschiedenste Tokenizer. So erstellt der WhitespaceTokenizerFactory mit
entsprechenden Filtern aus dem Wort wi fi die Wörter WiFi und wi-fi. Die Filter sollen
überflüssige Wörter entfernen. Der StopFilter entfernt z. B. das Wort und aus dem Text,
damit es nicht indiziert wird.
Für ein Feld, das indiziert werden soll, ist es möglich mehrere Analyzer zu konfigurieren.
Jeder Analyzer ist somit direkt von der verwendeten Sprache abhängig. Deshalb ist bei der
WhitespaceTokenizerFactory
KeywordTokenizer
LowerCaseTokenizerFactory
Trennt zwischen den
Leerzeichen
Behandelt das komplette Feld als einzelnen Token
Löscht alle Sonderzeichen und macht alles zu
Kleinbuchstaben
Hallo, wie geht es? ⇒ ,,hallo,”, ,,wie”, ,,geht”’ und ,,es”
http://test.de?Text=+Hallo
wird nicht geändert
Andrea’s Friseursaloon ist zu
⇒ andrea s friseursaloon ist
zu
Tabelle 3.5: Ein paar in Lucene implementierte Tokenizer [tok]
Konfiguration darauf zu achten, dass die konfigurierten Analyzer für die deutsche Sprache
optimiert sind.
3.2.2
Art der Anwendung
Im folgenden Kapitel soll geklärt werden, um welche Art von Anwendung das Dokumentenarchivierungsund -recherchesystem es sich handelt. Es gibt Webanwendungen und Desktopanwendun12
gen. Beide bieten Vor- und Nachteile. Die Anforderungen an die Bedienbarkeit und Darstellung des Programms werden helfen, die Entscheidung zu treffen, welcher Anwendungstyp
am besten geeignet ist..
3.2.2.1
Funktionale Anforderungen
• Aufteilung in verschiedene Bereiche muss möglich sein
3.2.2.2
Nicht funktionale Anforderungen
• leichte Installation und Updates beim Endanwender
• übersichtliche Oberfläche
3.2.2.3
Gegenüberstellung Website - Desktopanwendung
Die Website und die Desktopanwendung bietet für alle Anforderungen eine Lösung. Die
Website hat allerdings den Vorteil, dass beim Endanwender gar keine Installation und
keine Updates nötig sind. Daher fällt die Wahl auf eine Website, da hier die Problematik
der Softwareverteilung entfällt.
3.2.2.4
Website
Die Website wird den zentralen Punkt der kompletten Anwendung bilden, von der aus die
gesamte Funktionalität koordiniert wird. Auf der Website hat der Anwender die Möglichkeit Dokumente hochzuladen und nach ihnen zu suchen, sie zu editieren und sie herunterzuladen. Diese Funktionen stehen für PMRs und Monatsberichte zur Verfügung. Um
die Website übersichtlich zu halten, wird es für jede Dokumentenart eine eigene Rubrik
geben.
Aufbau Der Aufbau der Seiten für PMRs, Monatsberichte und auch zukünftiger Dokumentenarten ist gleich. Eine Seite ist in zwei Hauptteile gegliedert, welche unterschiedliche
Funktionen bieten sollen. Der eine Teil ist für das Hinzufügen neuer Dokumente in das
System zuständig, der andere für das Suchen nach diesen Dokumenten.
Die Benutzer in der Rolle supervisor müssen bei Monatsberichten zusätzlich die Möglichkeit haben, Monatsberichte zu sehen, die bisher nur von den Angestellten unterschrieben
wurden und noch nicht von ihm bestätigt wurden. Admins müssen nach Dokumenten aller
Benutzer zu suchen und diese g. g. f. löschen können.
Hinzufügen von Dokumenten Um neue Monatsberichte oder PMRs hinzuzufügen
muss es auf der Website eine Möglichkeit geben diese hochzuladen und gleichzeitig abzuspeichern wem das Dokument gehört. Eigentümer ist derjenige, der das Dokument hochgeladen hat. Zusätzlich muss beim Hochladen des Dokumentes ein Datum angegeben werden,
welches beschreibt, für welchen Monat und welches Jahr der Monatsbericht bzw. PMR gilt.
Das ist notwendig, da in den Dokumenten nicht nur ein Datum steht und daher von Solr
13
nicht eindeutig erkannt werden kann, welches das zu nutzende Datum ist. Das hochgeladene Dokumente muss dann mit den Information über den Besitzer, die Art des Dokuments
und das Datum an Solr übergeben werden.
Anzeige unsignierter/unbestätigter Monatsberichte (nur für Benutzer in der
Rolle supervisor) In dieser Anzeige werden alle Monatsberichte der Mitarbeiter gelistet, die bisher noch nicht vom Vorgesetzten bestätigt wurden. Bei Monatsberichten ist
zusätzlich zu der Bestätigung die Unterschrift des Vorgesetzten nötig. Dies muss durch
den Vorgesetzten sichergestellt werden.
Suche nach Dokumenten Die Darstellung und Funktion der Suche nach Dokumenten
hat rollenspezifische Unterschiede. Für jede Rolle soll es eine Suchmaske geben, welche
von gewöhnlichen Suchmaschinen wie Google oder Yahoo bekannt sind. In dieser Suchmaske kann der zu suchende Text eingegeben werden. Es muss auch möglich sein, nach
einem Zeitraum zu suchen, für den der Monatsbericht oder PMR erstellt wurde. Bei Monatsberichten kann in der Suchmaske angegeben werden, ob das Dokument bereits vom
Vorgesetzten bestätigt wurde.
Die Rollen supervisor und admin haben zusätzlich die Möglichkeit Dokumente mit Angabe des Besitzers zu suchen. Benutzer in der Rolle supervisor haben nur die Möglichkeit
Benutzer anzugeben, die ihnen zugeordnet sind. Benutzer in der Rolle admin hingegeben
dürfen alle Benutzer angeben.
Login Der Login soll mit dem Atos Worldline internen Benutzermangamentsystem ,,DAS”
ermöglicht werden. Das ist ein System, in dem bereits alle Angestellten von Atos Worldline
mit Login Daten sowie personenbezogenen Daten eingepflegt sind. Darauf kann über eine
API zugegriffen werden. Durch die Nutzung von ,,DAS” müssen keine Benutzer angelegt
werden. Die Benutzerrollen über DAS abgebildet werden, da sie darin bereits vorhanden
sind.
Web-Framework Für die Website soll Tapestry als Framework benutzt werden. Tapestry ist bei Atos Worldline Standard zur Erstellung von Websites. Um Tapestry zu
nutzen wird Java und ein Application Server benötigt. Für weitere Informationen siehe
http://tapestry.apache.org/.
3.2.3
Application Server
Um Solr benutzen zu können muss ein Application Server vorhanden sein, da Solr aus einer
WAR (Web Application Archive) Datei besteht. Diese muss in einem Application Server
geladen werden. Es gibt auch die Möglichkeit, Solr direkt aus der Anwendung zu starten,
statt es im Application Server zu laden. Das möchte ich allerdings vermeiden, da Website
und Solr dann auf dem gleichen Application Server laufen müssen. Aus Gründen der
Systemperformance kann es Sinn machen, beide auf unterschiedliche Application Server
mit unterschiedlicher Hardware laufen zu lassen. Im Moment steht dieses Vorgehen noch
nicht im Fokus, kann aber in Zukunft durchaus relevant werden.
14
3.2.3.1
Jetty
Ich werde zum Testen des Projektes Jetty als Application Server benutzen. Es gibt noch
andere Application Server wie z. B. Glassfish, JBoss oder Tomcat, allerdings ist ein Tapestry Projekt besonders einfach zu nutzen, wenn Jetty als Application Server genutzt
wird. Wenn das Projekt lauffähig ist, kommt es auf einen Application Server der von
Atos Worldline zur Verfügung gestellt wird. Jetty wird also nur zum Testen des Projektes
benötigt.
3.3
Datenbankschema
Name
id
document
text
Datentyp
uuid
blob
string
document name
content type
string
string
owner
valid
string
boolean
date
date
type
string
Beschreibung
Eindeutige ID
Das Dokument als BLOB
Der indizierte Dokumenteninhalt
Der Name des Dokumentes
Die Art des Dokumentes (z. B.
PDF, ZIP, Word Dokument,
...)
DAS ID
Gibt an, ob das Dokument
gültig ist
Für welches Datum das Dokument erstellt wurde
Dokumententyp (PMR, Monatsbericht)
Tabelle 3.6: Datenbankschema
Das Datenbankschema ist kein typisches Schema, wie man es von RDBMS gewohnt ist.
Jeder Eintrag in Solr ist dokumentenorientiert, also an ein Dokument gebunden. Das Schema wird in einer schema.xml in Solr konfiguriert. Eine Dokumentation für diese Datei ist
unter http://wiki.apache.org/solr/SchemaXml zu finden. Für die Erstellung des Schemas
muss Folgendes bekannt sein:
• Solr erstellt automatisch eine id, wenn diese vom Typ uuid ist und keine an Solr
übergeben wurde. Für eine Spezifikation von uuid siehe http://de.wikipedia.org/
wiki/Universally_Unique_Identifier.
• Aus dem an Solr übergeben Dokument wird der enthaltende Text extrahiert und
standardmäßig in das Feld ,,text” gespeichert. Das übergebene Dokument wird nicht
gespeichert! Es muss vom Programm separat übergeben werden.
• Metainformationen, z. B. der Content-Type (die Art des Dateityps), können von Solr
automatisch gesetzt werden.
• Bei Monatsberichten ist ein Dokument erst gültig, wenn der Vorgesetzte das Dokument unterschrieben und bestätigt hat. PMRs sind sofort gültig.
15
• Vom Benutzer muss beim Hochladen eines Dokumentes ein Datum angegeben werden, welches beschreibt für welches Datum sein Monatsbericht oder PMR gültig ist.
Dieses Datum wird auch in der Datenbank gespeichert.
• Der Besitzer eines Dokuments wird anhand seiner ID erkannt, die im DAS hinterlegt
ist.
3.4
Prozessabläufe
Im folgenden werden Prozessabläufe dargestellt, die mit bestimmten Aktionen zusammenhängen.
3.4.1
Ermittlung von Login Daten der Benutzer
Für den Login wird eine bestehende Lösung von Atos Worldline genutzt, in der bereits
alle Angestellten von Atos eingepflegt sind. Dieses System trägt den Namen DAS.
3.4.2
Ermittlung von Angestellten eines Vorgesetzten
Inhalte des Organigramms von Atos Worldline sind im DAS System abgebildet.
3.4.3
Ermittlung von Dokumenten eines Angestellten
Aus der Datenbank werden alle Einträge geladen, dessen Felder folgende Werte haben.
owner=ID des Angestellten
3.4.4
Ermittlung von unbestätigten Dokumenten der Vorgesetzten
Für diese Aktion ist der Vorgesetzte bekannt. Es müssen die Angestellten des Vorgesetzten
(siehe Kapitel 3.4.2) ermittelt werden. Für jeden Angestellten werden alle Einträge aus
der Datenbank geladen, dessen Felder folgende Werte haben.
valid=false
owner=ID des Angestellten
3.4.5
Ermittlung der Email-Adresse eines Benutzers
Die E-Mail Adresse ist im DAS System hinterlegt.
3.4.6
Vorgesetzter weist das Dokument eines Angestellten zurück
Für diese Aktion ist der Vorgesetzte, das Dokument und der Angestellte bekannt. Dem
Angestellten wird in dem Fall eine Email geschickt (Ermittlung der Email siehe Kapitel
3.4.5). Außerdem wird das Dokument aus der Datenbank gelöscht.
16
3.4.7
Suche nach Text in den Dokumenten
Für diese Aktion ist der zu suchende Text gegeben, optional ein Zeitraum ,,von/bis”
und der Besitzer der zu suchenden Dokumenten. Bei Monatsberichten gibt es zusätzlich
eine Suchoption, die prüft, ob das Dokument vom Vorgesetzten bestätigt wurde. Aus der
Datenbank sollen alle Dokumente geladen werden, welche mit dem Text oder Ähnlichkeiten
des Textes und den restlichen Parametern übereinstimmen.
• Der gesuchte Text
• owner=ID des Angestellten (optional)
• from=Startdatum des Zeitraums
• to=Enddatum des Zeitraums
• valid=Ob das Dokument vom Vorgesetzten bestätigt wurde (Nur für Monatsberichte)
3.5
3.5.1
Architektur
Gesamtarchitektur
Das Diagramm soll einen Überblick über das gesamte System geben und somit das Verständnis für das Zusammenspiel der verschiedenen Komponenten erleichtern.
17
3.5.2
Website
Die in Abbildung ?? beschriebene Architektur der Website zeigt die verschiedenen Bestandteile der Website und wie diese gegliedert sind. Wenn man die Website aufruft und
eingeloggt ist, wird eine Auswahl von Dokumententypen angezeigt. Ist ein Dokumententyp
ausgewählt, kann von dort zu den jeweiligen Aktionen, die für den jeweiligen Dokumententyp zur Verfügung stehen, navigiert werden.
Abbildung 3.1: Architektur der Website
3.6
Use Cases
Die Use Cases beschreiben mögliche Anwendungsszenarien.
18
Abbildung 3.3: Use Case für
die Suche nach einem PMR
bzw. Monatsbericht.
Abbildung 3.2: neuer PMR
Abbildung 3.4: Neuer Monatsbe- Abbildung 3.5: Löschen eines
richt
Monatsberichts bzw. PMRs
19
3.7
Projektplan
Den in Tabelle 3.7 dargestellten Projektplan werde ich versuchen einzuhalten. Das Startdatum ist der 31.10.2011. Mit Berücksichtigung der Wochenenden wird das geplante Projektende am 5.12.2011 sein. o
Paket Paketname
ID
1
JBoss installieren
Dauer
(Tage)
1
Vorgänger
Beschreibung
-
2
3
4
Solr installieren
Solr konfigurieren
Layout der Website erstellen
Funktionierenden
Entwurf der einzelnen Teile der
Website erstellen
1
1
2
1, 2
-
7
3, 7
6
Website testen
1
5
7
Gefundene Fehler
verbessern
Entwürfe an das
Layout anpassen
3
6
2
7
Erneutes Testen
der Website
Massendatentest
2
8
1
9
Finale Änderungen
5
10
Installieren und konfigurieren vom
JBoss
Installieren von Solr im JBoss
Konfigurieren von Solr
Layout erstellen, dass für die Website genutzt wird
Hier wird die komplette Website
programmiert. Allerdings nur ein
Entwurf, bei dem es das Aussehen
und die Bedienbarkeit noch nicht so
wichtig sind
Alle Funktionen der Website sollen
getestet werden
Beim Test gefundene Fehler werden
verbessert
Entwürfe werden an das erstellte
Layout angepasst und die Website
wird benutzerfreundlich gestaltet
Test der Funktionen und Benutzerfreundlichkeit
Test, wie sich das System bei großen
Datenmengen verhält
Beim Testen aufgefallene Änderungen werden verbessert
5
8
9
10
11
Tabelle 3.7: Arbeitspakete
20
Kapitel 4
Realisierung
In diesem Kapitel wird beschrieben, wie die einzelnen Technologien installiert und konfiguriert wurden und in welcher Form die Website programmiert wurde. Es werden auch
entstandene Probleme besprochen und die Lösungen dafür vorgestellt. Ebenso ist die Beschreibung des Ergebnisses Teil dieses Kapitels.
4.1
Solr
Solr habe ich in der aktuellen Version 3.4.0 installiert.
4.1.1
Installation
Um Solr zu installieren, muss das von http://www.apache.org/dyn/closer.cgi/lucene/
solr/ heruntergeladene Archiv entpackt werden. Darin enthalten ist bereits ein Jetty Application Server mit einem konfigurierten Solr Server, welcher über eine Jar Datei gestartet
werden kann. Allerdings ist diese Konfiguration lediglich eine Beispielkonfiguration und
muss im Regelfall angepasst werden. Es soll bei einem einfachen und schnellen Einstieg
in Solr helfen. Die Jar Datei ,,start.jar” liegt im Archiv unter dem Verzeichnis example
und wird mit dem Befehl ,,java -jar start.jar” gestartet. Diesen habe ich in der Anfangsphase der Entwicklung auch genutzt. Eine weitere Installation war nicht mehr nötig, da
während der Entwicklung Probleme mit dem Solr Server entstanden sind, wodurch Solr
nicht mehr im Zusammenhang mit einem Application Server genutzt werden konnte. Die
Gründe dieser Probleme sind unter Kapitel 4.1.3 beschrieben.
4.1.2
Konfiguration
Es gibt für Solr mehrere Konfigurationsdateien. Sie liegen wie folgt in den Verzeichnissen.
21
solr/
solr.xml
bin/
...
conf/
schema.xml
solrconfig.xml
...
data/
...
In der Datei solr/solr.xml werden Cores (verschiedene Instanzen) von Solr spezifiziert.
An dieser Datei musste allerdings nichts geändert werden, da dieses Feature nicht genutzt
wird. Sie sieht wie folgt aus.
solr.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!-Licensed to the Apache Software Foundation (ASF) under ...
-->
<!-All (relative) paths are relative to the installation path
persistent: Save changes made via the API to this file
sharedLib: path to a lib directory that will be shared across
all cores
-->
<solr persistent="false">
<!-adminPath: RequestHandler path to manage cores.
If ’null’ (or absent), cores will not be manageable via
request handler
-->
<cores adminPath="/admin/cores" defaultCoreName="collection1">
<core name="collection1" instanceDir="." />
</cores>
</solr>
Die Datei schema.xml enthält, wie der Name bereits andeutet, das Datenbankschema.
Darin werden Datentypen beschrieben, welche Analyzer für welche Datentypen genutzt
werden und welche Felder für die abzuspeichernden Daten vorhanden sind. Die Konfiguration ergibt sich aus dem in Tabelle 3.6 definierten Schema. Zusätzlich dazu muss ein
sinnvoller Analyzer für das Feld text gewählt werden. Die restlichen Felder werden so in
den Index aufgenommen, wie sie abgespeichert werden, da sie nur aus einzelnen Wörtern
bestehen und keinen Text enthalten. Der Analyzer für das Feld text soll alle Wörter einzeln
indizieren, außer Wörter wie ,,und”, ,,oder” usw. , es soll nicht auf Groß- und Kleinschreibung geachtet werden und Umlaute sollen auch ignoriert werden. Ein ü wird also zu einem
22
u, ein ä zum a usw. . Der Analyzer für die Indizierung und die Suche besteht also aus
folgenden Teilen:
• Tokenizer
– solr.WhitespaceTokenizer
• Filter
– solr.LowerCaseFilterFactory
– solr.StopFilterFactory
Es gibt die Möglichkeit je einen Analyzer für die Suche und einen für die Indizierung
zu konfigurieren. Das bedeutet, dass der Text beim indizieren anders analysiert wird,
als bei der Suche. Diese Funktion wird nicht genutzt. Sie wird meistens dann genutzt,
wenn nach Synonymen von Wörtern gesucht werden soll. Synonyme sollen im Regelfall
nicht indiziert werden, aber bei der Suche soll eine Suche nach einem Synonym auch ein
Ergebnis liefern. Da in den Dokumenten nach Namen und Zahlen gesucht wird ist die Suche
nach Synonymen nicht sinnvoll. Zu dem Schema ist noch ein weiteres dynamisches Feld mit
dem Namen ,,ignored *” hinzugekommen. Die Daten die an dieses Feld übergeben werden,
speichert Solr nicht ab, sondern verwirft diese. Der Hintergrund ist, dass beim Extrahieren
von Text aus einem Dokument auch Metadaten des Dokumentes zurückgegeben werden.
Diese können entweder gespeichert werden (wie es bei dem Feld ,,content type” getan
wird) oder verworfen werden. Existiert das Feld ,,ignored *” nicht, schlägt die Indizierung
eines Dokumentes mit der Meldung fehl, dass Solr nicht weiß, wo es die Metainformation
abspeichern soll.
Die Konfigurationsdatei sieht wie folgt aus:
solr.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!-Licensed to the Apache Software Foundation (ASF) under ...
-->
<!-This is the Solr schema file. This file should be named
"schema.xml" ...
-->
<schema name="example" version="1.4">

<types>

<fieldType name="uuid" class="solr.UUIDField"
indexed="true" />

23

<fieldType name="string" class="solr.StrField"
sortMissingLast="true" omitNorms="true"/>

<fieldType name="boolean" class="solr.BoolField"
sortMissingLast="true" omitNorms="true"/>

<fieldtype name="binary" class="solr.BinaryField"/>

<fieldtype name="ignored" stored="false" indexed="false"
multiValued="true" class="solr.StrField" />

<!-Default numeric field types. For faster range queries,
consider the tint/tfloat/tlong/tdouble types.
-->
...

<fieldType name="date" class="solr.TrieDateField"
omitNorms="true" precisionStep="0"
positionIncrementGap="0"/>

<fieldType name="tdate" class="solr.TrieDateField"
omitNorms="true" precisionStep="6"
positionIncrementGap="0"/>


<fieldType name="text_ws" class="solr.TextField"
positionIncrementGap="100">
24
<analyzer>
<tokenizer class="solr.WhitespaceTokenizerFactory"/>
<filter class="solr.LowerCaseFilterFactory"/>
<filter class="solr.StopFilterFactory" ignoreCase="true"
words="stopwords_de.txt"
enablePositionIncrements="true" />
</analyzer>
</fieldType>
</types>
<fields>


<field name="id" type="uuid" indexed="true" stored="true"
default="NEW"/>
<field name="owner" type="string" indexed="true"
stored="true" required="true"/>
<field name="valid" type="boolean" indexed="true"
stored="true" required="true"/>
<field name="date" type="tdate" indexed="true" stored="true"
required="true"/>
<field name="type" type="string" indexed="true" stored="true"
required="true"/>
<field name="document_name" type="string" indexed="false"
stored="true" required="true"/>
<field name="document" type="string" indexed="false"
stored="true" required="true"/>

<field name="text" type="text_ws" indexed="true"
stored="false" multiValued="true"/>
<field name="content_type" type="string" indexed="true"
stored="true"/>

<dynamicField name="ignored_*" type="ignored"
multiValued="true"/>
</fields>

<uniqueKey>id</uniqueKey>
25

<defaultSearchField>text</defaultSearchField>

<solrQueryParser defaultOperator="OR"/>
</schema>
solrconfig.xml ist die Konfigurationsdatei in der alle systemnahen Einstellungen stehen. So
werden dort die Verzeichnisse angegeben, in denen Java Bibliotheken liegen, welche von
Solr genutzt werden und das Verzeichnis in dem der Index, also der Inhalt der Datenbank,
liegt. Es wird angegeben, wie viele Dokumente in den RAM geladen werden dürfen bis sie
auf der Festplatte abgespeichert werden, wie Dateien gesperrt werden und welche Timeouts
für die Sperrung der Dateien gelten. Diese Konfiguration habe ich größtenteils bei der
Standardkonfiguration belassen. Die Datei ist 1515 Zeilen lang und daher zu lang um sie
hier anzuzeigen. Sie sieht strukturell wie die von Solr mitgelieferte solrconfig.xml aus, mit
dem Unterschied dass andere Verzeichnisse zu den Java Bibliotheken angegeben sind.
4.1.3
Probleme
Bei der Benutzung von Solr traten einige Probleme auf. Für alle Probleme konnte eine
Lösung gefunden werden.
Problem: Das Feld ,,document” konnte nicht an Solr übergeben werden. Der
Base64 kodierte Inhalt des Dokuments konnte nicht an Solr übergeben werden, da im Programm eine Exception mit der Meldung ,,socket write error” geworfen wurde. Die Ursache
für dieses Problem ist, dass Parameter an Solr mittels HTTP GET Request gesendet werden. Da der Base64 kodierte String sehr lang wird, ist es nicht möglich diesen per HTTP
GET Request zu versenden. Das Dokument, aus dem der Text extrahiert wird, wird als
HTTP POST Request verschickt. Dieses Dokument wird von Solr aber nicht abgespeichert
und es gibt auch keine Möglichkeit, dies über eine Konfiguration von Solr zu verlangen.
1. Lösungsansatz: Solr patchen Da Solr Open Source ist könnte der Quelltext von
Solr so geändert werden, dass Solr die Parameter nicht per HTTP GET sondern per HTTP
POST Request verschickt. Dies würde aber Arbeit an der Client und Server Komponente
von Solr erfordern, bei denen es nicht trivial ist abzuschätzen, welche Seiteneffekte dies
hat.
2. Lösungsansatz: Dateien lokal speichern Die Dateien können auf dem Webserver
gespeichert werden und der Pfad zu einer Datei wird an Solr übergeben. Dies erfordert
allerdings auch zusätzlichen Aufwand. Es muss die Logik dafür programmiert werden und
die Dateien müssen zusätzlich zum Index durch regelmäßige Backups gesichert werden.
26
3. Lösungsansatz: Embedded Solr Server Der Solr Server kann auch heraus der
Anwendung aus gestartet werden. Er läuft dann nicht mehr im Application Server und
ist somit nur aus der Anwendung direkt ansprechbar. Damit erfolgt keine Kommunikation
übers Netzwerk, wodurch die Parameter nicht mehr per HTTP GET Request verschickt
werden. Der Nachteil davon ist, dass der Solr Server von der Anwendung abhängig ist und
nicht als eigenständige Instanz laufen kann. Das ist für das gesamte Softwaresystem aber
nicht relevant und daher hier die beste Lösung.
Problem: Text wird aus manchen PDF Dateien nicht korrekt extrahiert Für
die Extrahierung von Text ist die Bibliothek ,,Apache Tika” zuständig. Leider hat diese
Bibliothek Probleme mit der Extrahierung von Text aus manchen PDF Dateien. Der
Text ist zwar vollständig, Leerzeichen werden jedoch teilweise nicht erkannt und auch
Zeilenumbrüche fehlen stellenweise. Das Verhalten tritt nicht bei allen PDF Dateien auf.
Lösung:
emphApache Tika patchen Apache Tika ist ein Open Source Projekt und daher kann
der Quelltext leicht geändert werden. Die Änderung im Quelltext ist nur eine kleine, und
zwar muss ein boolean Wert von ,,true” auf ,,false” geändert werden. ,,Apache Tika”
benutzt ,,Apache PDFBox” um Text aus PDF Dokumenten zu extrahieren. Es gibt bei
PDFBox eine Option, dass beim Extrahieren vom Text auf die Platzierung des Textes
geachtet werden soll. Diese Option ist von Tika aus Performance-Gründen ausgeschaltet.
Über eine Konfiguration ist das auch nicht zu ändern, weshalb der Quelltext geändert
und die Bibliothek neu erstellt werden muss. Konkret geändert werden muss in der Klasse
org.apache.tika.parser.PdfPDF2XHTML der Aufruf der Methode setSortByPosition mit
dem Parameter ,,true” anstatt ,,false”.
Problem: Aus Zip Dateien werden nur die Namen der enthaltenen Dateien
extrahiert Wenn an Solr eine Zip Datei übergeben wird, wird nicht der Inhalt aller darin
enthaltenden Dateien extrahiert, sondern die Dateinamen der im Archiv enthaltenden
Dateien.
Lösung: Solr patchen Glücklicherweise gibt es dafür bereits einen Patch, der unter
https://issues.apache.org/jira/browse/SOLR-2416 zu finden ist.
4.2
Website
Für die Website von Solr wird Tapestry in der aktuellen Version 5.2.6 benutzt.
4.2.1
Installation
Tapestry kann sehr einfach mittels ,,Apache Maven” installiert werden. Maven ist ähnlich
wie das von C/C++ bekannte Tool ,,make”, jedoch wesentlich mächtiger. Ich bin nach
der Anleitung vorgegangen, die unter http://tapestry.apache.org/getting-started.
html beschrieben ist. Mit dieser Installation ist auch direkt ein Jetty Application Server
verfügbar, so dass dessen Installation entfällt.
27
4.2.2
Konfiguration
Dank der Erstellung des Projektes durch Maven musste nichts gesondert konfiguriert werden.
4.2.3
Probleme
Es gab keine wesentlichen Probleme mit Tapestry. Da Tapestry ein für mich neues Framework war, musste ich mich entsprechend einarbeiten. Das Framework an sich stellte alle
benötigten Funktionen zur Verfügung und ist im Allgemeinen leicht zu erlernen.
4.3
Jetty
Die Installation von Jetty entfiel, da Solr aus den in Kapitel 4.1.3 beschriebenen Problemen
keinen Application Server mehr benötigt und Tapestry bereits einen Jetty Application
Server bereitstellte.
4.4
Programmierung
Um Solr zu benutzen musste nicht viel programmiert werden, da es schon alle Funktionen
bereitstellt, um ein Dokument zu indizieren. Es mussten die Parameter und das Dokument
an Solr übergeben werden. Um nach Dokumenten zu Suchen, kann für jedes im Schema
existierende Feld ein Suchstring übergeben werden. Dieser Suchstring kann ein einfacher
Text sein, oder auch ein komplexer regulärer Ausdruck. Für das Feld date ist die Suche
nach einem Zeitraum in dem das Datum liegen soll möglich. Die Syntax für den Suchstring
ist unter http://wiki.apache.org/solr/SolrQuerySyntax beschrieben.
Die Website erforderte mehr Aufwand bei der Programmierung. Tapestry unterstützt die
Erstellung in weiten Teilen, da grundlegende Funktionen bereits implementiert sind. So
müssen z. B. die Parameter eines Requests von einem HTTP-Form Element nicht mehr
in Java Datentypen umgewandelt werden. Durch diese und andere unterstützende Fähigkeiten von Tapestry kann man sich wesentlich auf die Erstellung der Funktionalität der
Website konzentrieren. Durch Tapestry wird der Quelltext strikt in HTML Template Code und Java Code aufgeteilt. Der HTML Template Code wird durch Elemente der Java
Klassen dynamisch gefüllt und enthält nur die darzustellende Seite, also keine Programmlogik. Die Logik ist in den dazugehörigen Java-Klassen. Dort habe ich die Java-Klassen,
welche die Templates befüllen, möglichst frei von Programmlogik gehalten und sie nur
mit den, dem Template zu übergebenen, Daten befüllt. All die Funktionen, wie die Loginfunktionalität, Anbindung an Solr und Rechtemangement, finden also nicht in den zu den
Templates gehörenden Java-Klassen, sondern in eigenen Klassen statt. Das schafft Übersicht und vermeidet doppelten Quelltext, da Funktionen, die für Teile der Website doppelt
benötigt werden, in extra Klassen ausgelagert werden. Insgesamt stellt die Website sieben
unterschiedliche Unterseiten zu Verfügung.
• Login
• Auswahl für welchen Dokumententyp die Unterseiten angezeigt werden sollen (PMR
oder Monatsbericht)
• Suche nach PMRs
28
• Hochladen von einem neuen PMR
• Suche nach Monatsberichten
• Hochladen eines neuen Monatsberichts
• Anzeige für den Vorgesetzten welche Monatsberichte seiner Mitarbeiter noch nicht
bestätigt wurden
Um neue Dokumente dynamisch hinzufügen zu können, habe ich nicht für jeden Dokumententyp eine eigene Such- und Uploadfunktion programmiert, sondern ein Template
und eine Java Klasse für alle Dokumententypen. Die Website weiß, welchen Dokumententyp der Benutzer ausgewählt hat und passt so die Anzeige entsprechend an. Im System
selbst sind alle verfügbaren Dokumententyp über eine Konfigurationsdatei definiert. In
dieser Konfigurationsdatei wird auch definiert, welche Seiten für welchen Dokumententypen verfügbar sind. Für den Vorgesetzten ist für den PMR keine Seite vorhanden, welche
anzeigt, welche PMRs seiner Angestellten noch nicht von ihm signiert wurden, da sie
nicht signiert werden müssen. Dadurch können Dokumententypen sehr einfach ins System
eingebunden werden, da kein Quelltext, sondern einzig die Konfigurationsdatei angepasst
werden muss.
4.5
Ergebnis
Das Ergebnis, was für den Endbenutzer sichtbar ist, ist die Website. Bilder der einzelnen
Teile der Website sind im Anhang ab Seite 36 zu finden.
Das gesamte Software-System ist sehr einfach zu starten. Entweder wird die erzeugte
WAR Datei in einem vorhanden Application Server geladen, oder es wird aus dem Projekverzeichnis der Befehl ,,mvn jetty:run” aufgerufen. Dieser Befehl startet den Webserver,
welcher dann unter http://localhost:8080/documentarchiver/ zu erreichen ist. Dort
muss sich der Anwender entweder anmelden, außer der Webserver hat für diesen Nutzer
noch eine HTTP-Session gespeichert und den Anwender daher erkennt. Ist der Anwender eingeloggt, wird er aufgefordert, einen Dokumententypen, PMR oder Monatsbericht,
auszuwählen, für den er weitere Aktionen durchführen möchte. Bei PMRs besteht für ihn
die Möglichkeit neue PMRs hinzuzufügen oder nach ihnen zu suchen. Wenn der Anwender in der Rolle supervisor oder admin ist (Vorgesetzte sind supervisor und ausgewählte
Mitarbeiter des Controllings sind admins), hat er die Möglichkeit, nach Dokumenten eines bestimmten Angestellten zu suchen. Bei Monatsberichten stehen die selben Optionen
zur Verfügung wie bei PMRs. Es gibt jedoch für Vorgesetzte noch die Möglichkeit, alle
Monatsberichte anzuzeigen, die von seinen Angestellten in das System hinzugefügt wurde,
von ihm noch nicht bestätigt und signiert wurden.
Dokumententypen und deren Funktionen werden über eine Konfigurationsdatei definiert.
Diese Konfigurationsdatei sieht wie folgt aus:
documentarchiver.properties
# In dieser Datei werden Dokumententypen und die Zuordnungen von
# Aktionen zu einem Dokumententyp definiert. Z.B. welche Seite
# für die Uploads von PMRs zuständig ist und welche für Monats# berichte oder für die Suche dieser Dokumente.
# Die Konfiguration hat folgende Syntax
# dokumententyp+Aktion=aktion
29
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
#
also z.B.:
Monatsbericht+Upload=Upload
Gültige Werte für "Aktion" sind:
Upload
- Die Seite auf der die Dokumente hochgeladen werden
sollen
Search
- Die Seite auf der die Dokumente gesucht werden
sollen
Unsigned - Die Seite auf der dem Vorgesetzten unbestätigte
Dokumente der Mitarbeiter angezeigt werden
Der Wert von der Eigenschaft kann jede Seite sein, die im
Tapestry-Projekt existiert. Soll eine Seite nicht genutzt
werden können, wird der Wert NULL genutzt.
NULL
- Wenn die Seite nicht verfügbar ist. Es muss allerdings ein Feld zu einem Dokumententyp vorhanden
sein, das nicht NULL ist.
Der Wert NULL hat Auswirkungen auf den Workflow, wenn dieser
für die Aktion Unsigned gesetzt wird. Ist für diese Aktion
eine Website gesetzt (er ist also nicht NULL), müssen Dokumente
mit der dort angegeben Seite von einer dort bestimmten
(in der derzeit implementierten UnsignedMB ist das der
Vorgesetzte) Person bestätigt werden. Beim hochladen werden die
Dokumente daher mit einem Flag als ungültig markiert. Durch
einen Schritt, der bei der Aktion Unsigned vorgenommen wird,
muss das Dokument als gültig markiert werden können. Ist dieser
Wert NULL entfällt der Workflow und das Dokumente ist mit dem
Upload des Users direkt gültig.
Derzeit implementierte Websiten für Aktionen sind:
Aktion Upload: Die Website "Upload" stellt eine
Upload Funktionalität zur Verfügung. Über die Properties
Datei der Upload Seite (Upload.properties) muss spezifiziert
werden, wie viele Dokumente für den Dokumententyp hochgeladen
werden sollen.
Aktion Search: Die Website "Search" stellt eine Suchfunktion
zur Verfügung.
Aktion UnsignedMB: Diese Funktion zeigt dem Vorgesetzten
alle Dokumente für den konfigurierten Typ an, die noch
von ihm noch nicht bestätigt wurden. Er hat dort auch die
Möglichkeit die Dokumente zu signieren.
# vorhandene Dokumententypen, durch ’;’ getrennt
types=PMR;Monatsbericht
# Konfiguration für Monatsberichte
Monatsbericht+Upload=Upload
30
Monatsbericht+Search=Search
Monatsbericht+Unsigned=UnsignedMB
# Konfiguration für PMRs
PMR+Upload=Upload
PMR+Search=Search
# Müssen nicht bestätigt werden...
PMR+Unsigned=NULL
# Namen die für die Verlinkungen der Seiten angezeigt werden
# sollen
Upload=Hochladen
Search=Suche
UnsignedMB=Unbestätigte Monatsberichte
Wenn ein neuer Dokumententyp vom System verwaltet werden soll, ist dies sehr einfach
und ohne Programmierkentnisse möglich. Sollen z. B. Urlaubsanträge zum System hinzugefügt werden können, muss die Konfigurationsdatei wie folgt angepasst werden.
documentarchiver.properties
# ...
# vorhandene Dokumententypen, durch ’;’ getrennt
types=PMR;Monatsbericht;Urlaubsantrag
# Konfiguration für Monatsberichte
...
# Konfiguration für PMRs
...
# Konfiguration für Urlaubsanträge
Urlaubsantrag+Upload=Upload
Urlaubsantrag+Search=Search
Urlaubsantrag+Unsigned=UnsignedMB
# Namen die für die Verlinkungen der Seiten angezeigt werden
# sollen
...
UnsignedMB=Unbestätigte Dokumente
31
32
Kapitel 5
Fazit und Ausblick
In Solr steckt ein enormes Potential, um eine sehr mächtige und schnelle Volltextsuche auf
sehr einfache Art und Weise zu implementieren. Ich habe nur einen kleinen, aber dennoch
sehr umfangreichen Teil der Möglichkeiten von Solr nutzen dürfen. Solr unterstützt die Extrahierung von Text aus unzähligen Dokumententypen (PDF, Word, Excel, usw. ), womit
sehr viel Arbeit erspart wird. Allerdings ist diese Funktion auch noch nicht voll ausgereift.
Solr hatte Probleme damit den Text aus einigen PDF Dateien zu extrahieren und hatte
auch bei ZIP Dateien kein zufrieden stellendes Ergebnis geliefert. Diese Probleme sind der
Community von Solr bekannt und an der Lösung wird gearbeitet.
Sehr interessant finde ich die Art, wie Solr Texte abspeichert um eine performante Suche zu ermöglichen. Die Indizierung von Texten ist eine simple, aber effiziente Lösung,
die im Detail bei bestimmten Anwendungsfällen (z. B. Erkennen von Synonymen) sehr
komplex werden kann. Diese Herangehensweise an eine NoSQL Datenbank ist komplett
unterschiedlich zur Datenmodellierung bei herkömmlichen, relationalen Datenbanken wie
MySQL oder einer Oracle Datenbank. Viele Möglichkeiten, die relationale Datenbanken
bieten, sind mit Solr allerdings nicht realisierbar. Es ist also immer ein Abwägen, ob es
Sinn macht einen Teil aus einer relationalen Datenbank in die Solr Datenbank auszulagern
oder ob nicht die ausschließliche Nutzung von Solr die Lösung ist.
Es gibt Situationen in denen Solr, wenn man z. B. nur eine Suchfunktion in eine DesktopAnwendung integrieren möchte oder auf Funktionen zugreifen möchte, welche die Benutzung von Lucenes API Klassen erfordert, zu mächtig ist. In solchen Fällen ist Solr eher ein
Ballast statt eine Hilfe. Dann sollte das ,,Herz” von Solr, nämlich Lucene alleine genutzt
werden.
Das entstandene System wird nun in eine erste öffentliche Testphase gehen, in der eine
Abteilung von Atos Worldline die Monatsberichte und PMRs mit dem Sign Pad unterschreiben werden und diese in das System hochladen werden. Dabei wird vor allem darauf
geachtet werden, ob das System für die Mitarbeiter eine Vereinfachung der bestehenden Prozesse ist oder ob dadurch ein erheblicher Mehraufwand durch das Signieren und
Hochladen entsteht. Der Prozess in dem der Vorgesetzte die Monatsberichte seiner Angestellten bestätigt bedarf noch der Optimierung, die sich aus dem täglichen Umgang mit
dem System ergeben wird. Der Vorgesetzte muss beim derzeitigen Stand der Website die
Monatsberichte herunterladen, ein Archiv entpacken, die darin enthaltenden Dokumente
unterschreiben und in ein neues Archiv packen. Dieses Archiv muss dann auf der Website
wieder hochgeladen werden. Dieses Problem soll durch ein Java Applet gelöst werden, dass
in die Seite eingebunden wird. Mit Hilfe diesen Java Applets müssen die Berichte nicht
mehr heruntergeladen werden, sondern können direkt auf der Seite angezeigt und signiert
33
werden.
Ist diese Testphase beendet, werden neue Dokumente zu dem System hinzugefügt. Vorstellbar wären da als erster Schritt Urlaubsanträge.
34
Anhang
Monatsbericht
PersNr.
KSt.
7005452 DE09234010
KUZ
Kapaz. Sollstd.
fre 100,00
160
Monat
Jahr
10 2011
Felix
Remmel (Azubi)
3003000846
8,00
SAP Import 3003000846
Reisezeiten unbezahlt
920
8,00
ADE.AZUSNS SNS: Azubi-MaTA Stunden
23,50
10
Praktischer Teil-ATOS
20
Vorlesungen/Unterricht-RWTH
19,25
4,25
Iststunden
31,50
Sollstunden
160,00
Monatssaldo
-128,50
Übertrag Vormonat:
Saldo aktueller Monat:
Übertrag Folgemonat:
Urlaubskonto
Std.
Genommene
Urlaubstage
Genommene
Gleittage
Arbeitszeitkonto
Std.
52,00
0,00
52,00
30,00
0,00
30,00
2,00
0,00
2,00
-8,50
-128,50
-137,00
Angeordnete Arbeit zu ungünstigen Zeiten:
Datum
Uhrzeit von
Uhrzeit bis
Stunden
Bemerkung
Summe:
Datum:
Datum:
Unterschrift Mitarbeiter:
Unterschrift Vorgesetzter:
06.10.2011 13:15:23
MoBerZRT_AngMAZuZ2.rpt
fre
1,00
0,00
0,00
Page 1 of 1
2,00
Abbildung 1: Beispiel eines Monatsberichts
35
Abbildung 2: Login
Abbildung 3: Auswahl des Dokumententyps
36
Abbildung 4: Monatsbericht hinzufügen
Abbildung 5: Monatsbericht suchen
37
Abbildung 6: Unbestätigte Monatsberichte
Abbildung 7: PMR hinzufügen
38
Abbildung 8: PMR suchen
39
40
Literaturverzeichnis
[ama] Amazon simple db. Online verfügbar auf http://aws.amazon.com/de/simpledb/;
Zugriff 24.10.2011.
[cou] Couchdb. Online verfügbar auf http://couchdb.apache.org; Zugriff 24.10.2011.
[ela]
elasticsearch.
24.10.2011.
Online verfügbar auf http://www.elasticsearch.org/; Zugriff
[Ext] Extractingrequesthandler. Online verfügbar auf http://wiki.apache.org/solr/
ExtractingRequestHandler; Zugriff 17.10.2011.
[luca] Lucene. Online verfügbar auf http://lucene.apache.org; Zugriff 24.10.2011.
[lucb] Lucene benchmark. Online verfügbar auf http://lucene.apache.org/java/2_2_
0/benchmarks.html; Zugriff 24.10.2011.
[mon] Mongodb. Online verfügbar auf http://couchdb.apache.org; Zugriff 24.10.2011.
[nos] Nosql datenbanktypen. Online verfügbar auf http://de.wikipedia.org/wiki/
NoSQL_%28Konzept%29; Zugriff 20.10.2011.
[sola] Solr. Online verfügbar auf http://lucene.apache.org/solr/; Zugriff 24.10.2011.
[Solb] What is solr? Online verfügbar auf http://lucene.apache.org/solr/#intro;
Zugriff 07.10.2011.
[tik]
Supported document formats. Online verfügbar auf http://tika.apache.org/0.
5/formats.html; Zugriff 17.10.2011.
[tok] Analyzers, tokenizers, and token filters. Online verfügbar auf http://wiki.
apache.org/solr/AnalyzersTokenizersTokenFilters#TokenizerFactories;
Zugriff 09.10.2011.
41
42
Abbildungsverzeichnis
2.1
Ein Sign Pad . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1
3.2
3.3
3.4
3.5
Architektur der Website . . . . . . . . . . . . . . . . . . . . .
neuer PMR . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Use Case für die Suche nach einem PMR bzw. Monatsbericht.
Neuer Monatsbericht . . . . . . . . . . . . . . . . . . . . . . .
Löschen eines Monatsberichts bzw. PMRs . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
18
19
19
19
19
1
2
3
4
5
6
7
8
Beispiel eines Monatsberichts
Login . . . . . . . . . . . . .
Auswahl des Dokumententyps
Monatsbericht hinzufügen . .
Monatsbericht suchen . . . .
Unbestätigte Monatsberichte
PMR hinzufügen . . . . . . .
PMR suchen . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
35
36
36
37
37
38
38
39
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
44
Tabellenverzeichnis
3.1
3.2
3.3
3.4
3.5
3.6
3.7
Auszug von Datenbanktypen [nos] . . . . . . . . . . . . . . . . . . . . . . .
Die gespeicherten Texte . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Der Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gegenüberstellung verschiedener dokumentenorientierter NoSQL Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ein paar in Lucene implementierte Tokenizer [tok] . . . . . . . . . . . . . .
Datenbankschema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Arbeitspakete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
45
9
9
10
11
12
15
20
46
Eidesstattliche Erklärung
Hiermit versichere ich, dass ich die Seminararbeit mit dem Thema
Konzeption und Realisierung eines Dokumentenablage- und -–recherchesystems auf Grundlage von neuen Datenbanktechnologien
selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt habe, alle Ausführungen, die anderen Schriften wörtlich oder sinngemäß entnommen
wurden, kenntlich gemacht sind und die Arbeit in gleicher oder ähnlicher Fassung noch
nicht Bestandteil einer Studien- oder Prüfungsleistung war.
Name: Felix Remmel
Aachen, den 12. Dezember 2011

Konzeption und Realisierung eines - RWTH

Zugehörige Unterlagen

Produkte

Unterstützung

Konzeption und Realisierung eines - RWTH

Zugehörige Unterlagen

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können