Konzeptioneller Entwurf und prototypische Realisierung einer

Hochschule für Technik und Wirtschaft Dresden (FH)
Fachbereich Informatik/Mathematik
Diplomarbeit
im Studiengang Wirtschaftsinformatik
Thema:
„Konzeptioneller Entwurf und prototypische Realisierung einer Datenbanklösung
für chemische Risikoanalysen“
eingereicht von:
Marco Münzberg
eingereicht am:
06.08.2007
Betreuer:
Prof. Dr. oec. Gunter Gräfe
HTW Dresden
Dr. Vinzenz Brendler
Forschungszentrum Dresden-Rossendorf e. V.
Inhaltsverzeichnis
Abbildungsverzeichnis
III
Tabellenverzeichnis
IV
Verzeichnis verwendeter Abkürzungen
V
Glossar
VI
1 Einleitung
1
2 Was ist eine chemische Risikoanalyse?
3
3 Analyse der Anforderungen und des Datenbestandes
6
3.1 Analyse der Nutzerzahlen und Datenzugriffe ......................................................... 6
3.2 Funktionale Anforderungen .................................................................................... 7
3.3 Technologische Anforderungen ............................................................................ 11
3.4 Kostenanalyse ....................................................................................................... 16
3.5 Analyse der Datentypen und des Datenbestandes ................................................. 17
4 Konzeption einer Auswahlstrategie
20
4.1 Datenbankmodelle................................................................................................. 20
4.2 Lizenzmodelle ....................................................................................................... 22
4.2.1 Closed Source ................................................................................................ 22
4.2.2 Open Source ................................................................................................... 23
4.2.3 Open Source Initiative (OSI) zertifizierte Lizenzen ...................................... 24
4.3 Definition und Beurteilung von Auswahlkriterien ................................................ 24
5 Grundlagen der Datenbankmangementsysteme
27
5.1 Konzept eines DBMS............................................................................................ 27
5.2 Übersicht relevanter DBMS .................................................................................. 28
I
6 Auswahl des DBMS
34
6.1 Methodik der Auswahl .......................................................................................... 34
6.2 Anwendung des mehrstufigen Auswahlverfahrens ............................................... 34
6.3 DBMS: Auswahlentscheidung .............................................................................. 36
7 Konzeption von Datenmodell und Nutzerinteraktionen
37
7.1 Vorstellung Datenmodell ...................................................................................... 37
7.1.1 Detailliertes Datenmodell für die grundlegenden Daten ................................ 40
7.1.2 Detailliertes Datenmodell für chemische Stoffdaten und zugehörige
Reaktionsgleichungen .................................................................................... 41
7.1.3 Detailliertes Datenmodell der Parameter für die Wechselwirkungen zwischen
Ionen oder Festphasen .................................................................................... 43
7.1.4 Detailliertes Datenmodell für bibliographische Informationen ..................... 44
7.2 PostgreSQL-Client: Einbindung in das WCMS Joomla ....................................... 45
7.2.1 WCMS und seine Vorteile ............................................................................. 45
7.2.2 Kurzbeschreibung Joomla .............................................................................. 47
7.2.3 Client-Konzept (1. Ausbaustufe) ................................................................... 47
8 Prototypische Realisierung der Datenbank
49
8.1 Umsetzung des Datenmodells in PostgreSQL ...................................................... 49
8.2 Exemplarische Abfrage ......................................................................................... 50
9 Zusammenfassung und Ausblick
51
Literaturverzeichnis
53
Anhang A: Anforderungsanalyse erstellt mit MindMapper 5
57
Eidesstattliche Erklärung
60
II
Abbildungsverzeichnis
Abbildung 1: Mehrfachbarrierensystem für nukleare Endlager........................................ 3
Abbildung 2: Zugriffsschema über WWW-Interface ..................................................... 10
Abbildung 3: Relationales Datenmodell ......................................................................... 21
Abbildung 4: Entity-Relationship-Modell ...................................................................... 21
Abbildung 5: Grobarchitektur von Datenbanksystemen nach Stahlknecht .................... 27
Abbildung 6: Datenmodell der Basisdaten ..................................................................... 40
Abbildung 7: Datenmodell der chemischen Stoffdaten .................................................. 41
Abbildung 8: Datenmodell zur Beschreibung chemischer Reaktionsgleichungen ......... 41
Abbildung 9: Datenmodell zur Beschreibung von Wechselwirkungen .......................... 43
Abbildung 10: Datenmodell für bibliographische Informationen ................................... 44
Abbildung 11: Web-Interface Backend .......................................................................... 46
Abbildung 12: Web-Interface Frontend .......................................................................... 46
Abbildung 13: Client-Konzept ........................................................................................ 48
Abbildung 14: Abfrageergebnis auf der THEREDA-Seite............................................. 50
III
Tabellenverzeichnis
Tabelle 1: Hauptfehlerquellen und Recoveryverfahren [I_WLOK02] ........................... 13
Tabelle 2: Vor- und Nachteile von Open Source Software............................................. 23
Tabelle 3: Gruppierung der Auswahlkriterien für ein DBMS nach deren Relevanz
für das Gelingen des THEREDA-Projektes ................................................... 26
Tabelle 4: Detailvergleich der DBMS Firebird, Ingres, MySQL und PostgreSQL ........ 35
Tabelle 5: Feldtypen in THEREDA ................................................................................ 38
IV
Verzeichnis verwendeter Abkürzungen
ACID
Atomic, Consistent, Isolated, Durable
BSD
Berkeley System Distribution
CPU
Central Processing Unit
DBMS
Data Base Management System
DDL
Data Definition Language
DML
Data Manipulation Language
GPL
GNU General Public License
GRS
Gesellschaft für Reaktorsicherheit
IDPL
Initial Developer's Public License
IPsec
Internet Protocol Security
LAMP
Linux, Apache, MySQL, PHP/Perl/Python
ODBC
Open Database Connectivity
OEM
Original Equipment Manufacturer
OLTP
Online-Transaction-Processing
OLAP
Online-Analytical-Processing
OSI
Open Source Initiative
SCP
Secure Copy Protocol
SQL
Structured Query Language
SSL
Secure Sockets Layer
THEREDA
THErmodynamische REferenzDAtenbasis
WCMS
Web Content Management System
V
Glossar
Biosphäre
Der Bereich auf der Erde in dem lebende Materie vorkommt. Die Biosphäre umfasst die
komplette Hydrosphäre, den obersten Teil der Erdkruste (Leben ist bis in Tiefen von
über 2000 m nachgewiesen worden) und den unteren Teil der Atmosphäre.
Gleichgewichtskonstante
Beschreibt die Lage eines chemischen Gleichgewichts und ist der Quotient aus dem
Produkt aller Konzentrationen der Reaktionsprodukte und dem Produkt aller
Konzentrationen der Ausgangsstoffe. Sie ist Maß für die chemische Stabilität einer
Verbindung.
Entity-Relationship-Modell
1976 wurde das Entity-Relationship-Modell von Peter Pin-Shan Chen vorgeschlagen,
um das Datenbank-Design zu erleichtern. Es können mit dem Entity-RelationshipModell grundlegende Tabellen- Beziehungsstruktur einer Datenbank strukturiert
entworfen und visualisiert werden
Hosting
Unter Hosting versteht man die technische Bereitstellung von Inhalten. In der Regel
sollen die Inhalte durch das Internet abgerufen werden. Hosting-Dienstleister (Provider
oder Webhoster) bieten für diesen Einsatz Webspeicher, Datenbanken, E-Mailadressen
und weitere Produkte an.
IPsec
Das Internet Protocol Security ist ein Protokoll zur verschlüsselten Übertragung von
Daten über ein Netzwerk.
LAMP-Stack
Open Source Softwarepaket, um dynamische Webseiten zur Verfügung zu stellen. L
steht dabei für Linux, A für Apache, M für MySQL und P für PHP/Perl/Python.
VI
Logging
Logging ist die Protokollierung von Vorgängen in IT-Systemen. Bei DBMS wird
Logging zur Protokollierung von Transaktionen auf einer Datenbank genutzt.
Radionuklide
Radioaktive Strahlung aussendende Isotope von chemischen Elementen (Isotope eines
Elementes sind chemisch ähnlich, haben im Atomkern gleiche Anzahl an Protonen, aber
unterschiedliche Anzahl an Neutronen)
Recovery
Ist die Funktion eines DBMS die Datenbank nach einem Systemabsturz oder anderen
Fehlern wieder in einen konsistenten Zustand zu überführen. Die geschieht meistens
über ein internes Logbuch (Logging) des DBMS.
Mainframe
Große Server, an denen sehr viele Clients angeschlossen sind. Diese Mainframes haben
sehr viel mehr Rechenleistung als ein Personal Computer oder typischer Server.
Multi-Threading
Ist die gleichzeitige Abarbeitung mehrerer Ausführungsstränge eines einzelnen
Prozesses.
Multi-Processing
Betriebsart eines Rechensystems, beim dem mehrere Prozessoren auf einem
Arbeitsspeicher arbeiten.
OEM-Lizenz
Sind meist günstigere Lizenzen zu Programmen, die bei Produkten anderer Hersteller
beigelegt werden. Diese Programme dürfen meistens nur mit diesem Produkt benutzt
werden.
VII
Online Analytical Processing
Unter Online Analytical Processing werden Technologien, Tools und Methoden
zusammengefasst, die die Analyse sehr großer Datenmengen unterstützen. OLAP stellt
diese Daten zum Zweck der Entscheidungsunterstützung und Erkenntnisförderung
bereit.
Online Transaction Processing
Unter Online Transaction Processing versteht man die Durchführung von Transaktionen
an operativen Datenbeständen durch operative Systeme. Ein OLTP-System kann eine
große Anzahl kleiner vordefinierter Transaktionen verarbeiten.
SCP
Das Secure Copy Protocol ist ein Protokoll zur verschlüsselten Übertragung von Daten
über ein Netzwerk.
SQL:99 / SQL:03
Standards, welche vom American National Standards Institute (ANSI) und der
International Organization for Standardization (ISO) verabschiedet wurden. Sie
beschreiben die Regeln, wie SQL-Befehle (zum Beispiel CREATE) in Datenbanken
auszusehen haben.
SSL
Das Secure Sockets Layer ist ein Protokoll zur verschlüsselten Übertragung von Daten
im Internet.
Stored Procedure
Stored Procedure ist eine Reihe von SQL-Befehlen, die als eigenständiges Programm in
einem DBMS gespeichert werden. Über den EXECUTE PROCEDURE-Befehl können
diese unter Angabe des Prozedurnamens und optional mit Übergabeparametern gestartet
werden.
VIII
Toxisch
Eigenschaft chemischer Verbindungen, Vergiftungen zu bewirken. Die Giftigkeit hängt
dabei stark von der Art eines Organismus ab.
Wirtsgesteine
Gesteinsformationen, in welche ein zukünftiges Endlager für radioaktive Abfälle
eingebaut werden soll, bestimmt maßgeblich die Rückhaltefähigkeit über geologische
Zeiträume.
Wrapper
Ist eine Komponente eines Web Content Management Systems, mit der man externe
Seiten in das CMS einbinden kann.
IX
1 Einleitung
Die Sicherheit eines Endlagers für radioaktive Abfälle sowie von Untertagedeponien für
chemisch-toxische Stoffe, ebenso wie die Sanierung von Altlasten des Uranbergbaus
stehen
im
Fokus
des
öffentlichen
Interesses.
Belastbare
Aussagen
zum
Transportverhalten toxischer Bestandteile und möglichen Strategien zur Verhinderung
des Eintrags in die Biosphäre sind von entscheidender Bedeutung. Neben geeigneten
Modellen sind hierfür qualitativ hochwertige Daten notwendig.
Auf nationaler Ebene unter anderem in den USA und in der Schweiz wurden
Standarddatenbanken für die Anwendung thermodynamischer Daten im Rahmen
spezifischer Endlagerprojekte zusammengestellt, vervollständigt und an die jeweiligen
Bedürfnisse angepasst.
In Deutschland hingegen wurde bisher
noch keine
Standarddatenbank für die Anwendung in Endlager- und Sanierungsprojekten erarbeitet.
Eine einheitlich und verbindlich zu nutzende Standarddatenbank ist die Voraussetzung
für
vergleichbare
und
nachvollziehbare
Ergebnisse
von
geochemischen
Modellrechnungen in allen geologischen Formationen. Der Aufbau einer solchen
Datenbank für die spezifischen Belange Deutschlands wird deshalb seit Mitte 2006 in
einem Verbundprojekt von fünf Institutionen vorangetrieben – dem THEREDA-Projekt
für eine THErmodynamische REferenzDAtenbasis. Die Partner in diesem Projekt sind
das Forschungszentrum Dresden-Rossendorf e.V., Institut für Radiochemie, die
Gesellschaft für Anlagen- und Reaktorsicherheit mbH Braunschweig, die Technische
Universität
Bergakademie
Freiberg,
Institut
für
Anorganische
Chemie,
das
Forschungszentrum Karlsruhe GmbH, Institut für Nukleare Entsorgung sowie Colenco
Power Engineering AG.
1
Um das Ziel einer qualitätsgesicherten Datenbasis für Langzeitsicherheitsanalysen zu
erreichen, muss eine solche Datenbasis eine ganze Reihe von Anforderungen erfüllen.
Diese Anforderungen sind zum Beispiel die langfristig preiswerte Verfügbarkeit, gute
Anbindung an das World Wide Web, Archivierbarkeit von Zwischenständen und eine
hohe Sicherheit gegen Manipulationen. Die Qualitätssicherung erfordert zudem, dass
alle aufgenommenen Daten nach Entstehungsart, Quelle und Qualität beschrieben bzw.
eingeteilt werden. Zusätzliche Anmerkungen sollen spezifische Informationen
(Literaturstelle, Gültigkeitsbereiche und sonstige Hinweise, z.B. über zu Grunde
liegendes
Analogon
Datengruppen
eine
oder
Schätzmethode)
konsistente
Datenbasis
liefern.
vorliegt,
Sobald
erfolgt
für
eine
geschlossene
detaillierte
Dokumentation des Bewertungs- und Auswahlprozesses für alle Daten. Zur
Sicherstellung der Rückverfolgbarkeit wird ein zentrales Literaturarchiv vorgehalten, in
der alle relevanten Quellen archiviert werden.
Die vorliegende Arbeit widmet sich der Teilaufgabe, nach Analyse dieser und weiterer
Nutzeranforderungen und unter Einbeziehung von Auswahlkriterien ein Ranking
potenzieller Datenbanken für den Einsatz bei THEREDA vorzunehmen und eine
Empfehlung für ein mögliches Datenbankbetriebssystem auszusprechen.
Nach Auswahl des
Datenbankbetriebssystems sind die Datenstrukturen und
Beziehungen zu analysieren und ein Entwurf für die Datenbank-Architektur abzuleiten.
Es ist ein Prototyp einer entsprechenden Datenbank zu erstellen, die das NutzerFeedback für eine iterative Konzeptentwicklung und anschließende Umsetzung in eine
konkrete Implementierung absichert.
Dieser Entscheidungs- und Umsetzungsprozess wird mit dieser Diplomarbeit
nachvollziehbar dokumentiert.
2
2 Was ist eine chemische Risikoanalyse?
Durch chemische Risikoanalysen soll geklärt werden, welche Risiken für Mensch und
Umwelt entstehen, wenn toxische Stoffe in die Geo- und Biosphäre gelangen. Ein
Spezialfall hiervon sind radioaktive Substanzen, welche in einem Salz-, Granit- oder
Tonbergwerk endgelagert werden. Andere konkrete Anwendungsfälle sind untertägige
Deponien für Schwermetalle, giftige organische Verbindungen (z.B. Dioxin) oder
Arsen. Ebenso sind Lagerorte für alte Munition und Explosivstoffe potenziell
gefährdend.
Für eine sichere Verwahrung, der oben genannten Schadstoffe, sind verschiedene
Anforderungen zu erfüllen. Dafür wird meist ein Mehrfachbarrierenkonzept (siehe
Abbildung 1 für den Spezialfall eines nuklearen Endlagers) genutzt.
Geologische Barriere:
Geotechnische Barriere:
- Wirtsgestein
- Versatzmaterial
- Untertägige Dammsysteme
- Bohrlochverschlüsse
Technische Barriere:
- Brennstabhülle
- Verglaster Abfall
- Behälter
Mobiler
Schadstoff
Abbildung 1: Mehrfachbarrierensystem für nukleare Endlager
Dabei beruht die Langzeitsicherheit nach Tausenden von Jahren, wenn ein zumindest
teilweises Versagen der technischen Barrieren angenommen werden muss, ganz
entscheidend auf der geologischen Beschaffenheit des Wirtsgesteins. Insbesondere wird
eine hohe Zuverlässigkeit für lange Zeiträume, gute Begründbarkeit der Szenarien zur
3
Schadstofffreisetzung und -ausbreitung und Reduzierung der Unsicherheiten gefordert.
Zwei wichtige Anforderungen an das Wirtsgestein sind zum Beispiel, dass es ein hohes
Rückhaltevermögen gegenüber Gefahrstoffen besitzt sowie die Freisetzung und der
Transport von Gefahrstoffen reduziert werden.
Bei chemischen Risikoanalysen werden Berechnungen zum chemischen Verhalten aller
beteiligten Schadstoffe durchgeführt. Im Fokus stehen die möglichen Reaktionen
untereinander bzw. Wechselwirkungen mit anderen Lösungsbestandteilen, dem
umgebenden Wirtsgestein, ingenieurtechnischen Barrieren, Zusatzstoffen sowie der
Gasphase. Die Ergebnisse wiederum sind eine Grundlage für Ausbreitungsrechnungen,
wofür zusätzliche Angaben zu Transportparametern erforderlich sind. Auf Grund der
hohen
gesellschaftlichen
Relevanz
solcherart
erhaltener
Aussagen
sind
alle
Entscheidungsprozesse durch eine öffentliche Datenbank transparent und für jedermann
nachvollziehbar zu gestalten. Selbstverständlich müssen alle in der Datenbasis
bereitgestellten Daten höchsten Qualitätsansprüchen genügen.
Welche Art von numerischen Daten sind in einer Datenbasis für chemische
Risikoanalysen vorzuhalten? Hier sind zum Einen die Reaktionskonstanten für die
Bildung gelöster Komplexe als auch die Löslichkeiten aller Minerale zu nennen.
Zusätzlich zu Koeffizienten, welche die Wechselwirkung von Ionen in Lösung
beschreiben, werden für sämtliche Parameter die Temperatur- und Druckabhängigkeit
aufgeführt. Chemische Risikoanalysen müssen in der Lage sein, eine Vielzahl variabler
Umweltparameter zu berücksichtigen, hier seien insbesondere die Temperatur, Druck,
pH-Wert, Konzentration der Schadstoffe und weiterer gelöster Komponenten, das
Redoxpotential und die Zusammensetzung der Gasphasen genannt. Zudem ist vielen
chemischen Reaktionen eine zeitliche Entwicklung aufgeprägt, d.h. verschiedene
Reaktionen verlaufen unterschiedlich schnell. Dies muss eine chemische Risikoanalyse
berücksichtigen. Oft sind die entsprechenden Codes für solche Berechnungen auch in
der Lage, Sensitivitäts- und Unsicherheitsanalysen einzubeziehen, d.h. sie können der
Ungenauigkeit der numerischen Daten als auch der zu Grunde liegenden chemischen
Modelle Rechnung tragen.
4
Ein wesentlicher Aspekt chemischer Risikoanalysen ist schließlich die Quantifizierung
des Risikos für Mensch und Umwelt. Diese ist nicht trivial, da eine Mischung von
Gefahrstoffen durchaus unterschiedliche Risiken bewirken kann (Beeinträchtigungen
des Wohlbefindens, Schädigungen und Ausfall von Organen, Schädigungen des
Erbgutes u.a.), welche wiederum akut oder chronisch sein können. Teilweise treten die
negativen Wirkungen nach Latenzzeiten von Jahren oder Jahrzehnten auf. Zudem
reagieren unterschiedliche Bevölkerungsgruppen (Alter, Geschlecht, Lebensweise)
durchaus verschieden auf nominell gleiche Risiken [L_AUSW01].
5
3 Analyse der Anforderungen und des Datenbestandes
3.1 Analyse der Nutzerzahlen und Datenzugriffe
Die Nutzerzahlen der Datenbank setzen sich vorrangig aus institutionellen Nutzern
zusammen, dazu kommen Nutzer aus der Industrie sowie aus der Wissenschaft. Bei den
Angaben handelt es sich um Schätzungen für Maximalwerte, in der Realität können
diese Zahlen durchaus kleiner ausfallen.
-
80 Ministerien (aus Bund und 16 Ländern) mit je 10 involvierten
Mitarbeitern (800 Personen)
-
500 Kommunen, welche durch ein nukleares Endlager, Altlasten des
Uranerzbergbaus oder andere Deponien betroffen sind, mit je fünf
involvierten Mitarbeitern (2500 Personen)
-
200 Wirtschaftsunternehmen (z.B. Kernkraftwerke, die WISMUT, Betreiber
von Deponien) mit je fünf involvierten Mitarbeitern (1000 Personen)
-
1000 Ingenieurbüros, welche den Institutionen und der Industrie zuarbeiten,
mit je drei involvierten Mitarbeitern (3000 Personen)
-
20 Universitäten, Hochschulen, und Forschungseinrichtungen mit je zehn
involvierten Wissenschaftlern (200 Personen)
Daraus ergeben sich rund 7500 Personen, welche prinzipielles Interesse an der
Datenbank aufweisen sollten. Davon wird jedoch nur ein Bruchteil gleichzeitig
(innerhalb einer Stunde) auf die Datenbasis zugreifen wollen (Schätzung ca. 2 %). So
ergeben sich ca. 150 Abfragen pro Stunde an die Datenbank. Die Datenbank soll
öffentlich im Internet verfügbar sein, so dass auch mehr Abfragen pro Stunde zustande
kommen können. Eingaben in und Änderungen an der Datenbank werden durch etwa 10
Wissenschaftler (aus den Partnerinstitutionen des THEREDA-Projektes) vorgenommen.
Im Vergleich zu sehr vielen anderen Datenbanken aus Industrie und Wissenschaft sind
obige Zahlen als unkritisch zu bewerten, die heutige Infrastruktur (sowohl auf Softwareals auch auf Netzebene) sollte den entstehenden Datenverkehr ohne jegliche Probleme
bewältigen können.
6
3.2 Funktionale Anforderungen
Langzeitverfügbarkeit
Eine Besonderheit von THEREDA ist dessen Langzeitverfügbarkeit. Allein die
Zeitspanne bis zur Erteilung der Genehmigung für ein nukleares Endlager in
Deutschland wird auf bis zu 25 Jahre geschätzt. Für weitere Informationen wird auf die
Dokumente des Arbeitskreises „Auswahlverfahren für Endlagerstandorte“ verwiesen
[L_AUSW01]. Daran schließt sich eine Bau- und Erprobungsphase an. Auch nach
Inbetriebnahme des Endlagers sollen die ursprünglichen Berechnungen nachvollziehbar
bleiben. Eine Abschätzung der „Lebensdauer“ von THEREDA mit vierzig Jahren ist
daher eher noch als kurz zu bezeichnen.
Daraus ergibt sich die Notwendigkeit, dass die Datenbank selbst über mindestens diesen
Zeitraum nutzbar bleibt. Bei herstellergebundenen Datenbanken besteht die Gefahr,
dass der Hersteller den Vertrieb/Support einstellt und somit keine Updates mehr
angeboten werden. Eine wesentlich bessere Langzeitnutzung ist möglich, wenn der
Quellcode der Datenbank frei verfügbar ist (Open Source) und nicht durch zu restriktive
Lizenzen Behinderungen entstehen. Eine detaillierte Auseinandersetzung mit Begriff
und Inhalt von Open Source und den daran gebundenen Lizenzmodellen erfolgt im
Kapitel 4.2.
Auf Grund der angestrebten sehr langen Nutzungsdauer der Datenbank sollte diese
entsprechende
internationale
Standards
unterstützen.
Insbesondere
im
nicht
ausgeschlossenen Fall, dass die hier ausgewählte Datenbank bereits innerhalb des
angestrebten Nutzungsbereiches von ca. 40 Jahren nicht mehr einsetzbar ist. Sollte eine
Datenbank-Migration notwendig werden, sorgt die Einhaltung von Standards dafür,
dass die Datenbank relativ schnell wieder einsatzbereit ist. Als Mindestanforderung
wird eine weitestgehende Einhaltung des SQL:92 Standard angesehen. Erstrebenswert
wären der SQL:99 und SQL:03 Standard, aber diese werden zurzeit von kaum einer
Datenbank wirklich vollständig unterstützt [I_WLOK01]. Daher wird in der weiteren
Betrachtung auf den SQL:03 Standard kein Bezug genommen, wohingegen der SQL:99
Standard in wesentlichen Teilen unterstützt werden sollte.
7
Datenbankadministration
Typische Administrationsaufgaben, welche bei der Arbeit mit THEREDA zu erwarten
sind, umfassen Nutzer- und Rechteverwaltung, Konfiguration und Tuning. Diese
Administration muss auch von Nutzern mit geringen Informatikkenntnissen zu
bewältigen sein. Ein leicht bedienbares Administrationstool mit einer grafischen
Benutzeroberfläche für Microsoft Windows und Linux und die Bereitstellung einer
ausführlichen Dokumentation bzw. Hilfe kann die Datenbankadminstration erleichtern.
Um die Administration auch von einem Computer ohne lokal installiertem Tool
durchführen zu können, sollte man den Zugriff auf die Datenbank über den Browser
gewährleisten. Dies kann ein Programm ermöglichen, welches auf dem Server installiert
wird und zum Beispiel auf einer Skriptsprache, wie PHP, basiert. Dieses Programm
sollte ebenfalls eine gute Dokumentation bieten und mit möglichst vielen Browsern
(Internet Explorer 7, Mozilla Firefox, Opera, Konqueror, Epiphany, Safari u.a.)
kompatibel sein. Falls die Tools Open Source sind, dann muss gleichzeitig auf eine
große Community (siehe Kapitel 4.2) geachtet werden.
Datenbestandspflege
Die ersten Daten werden von einer vorhandenen MS Access-Datenbank importiert.
Danach wird die Datenbasis über verschiedene Verfahren mit Daten gefüllt:
-
Übernahme aus bestehenden Datenbeständen über speziell angepasste
Importfilter
-
Übernahme aus ASCII-Dateien mit einer vorgegebenen Datenstruktur über
spezielle Tools
-
Manuelle Eingabe über ein Webinterface
Datenbankzugriffsarten
Die Datenbasis ist in zwei Ausprägungen verfügbar:
1. Anwendungsbezogene
veröffentlichte
TDBs
(Thermodynamische
Daten-
banken), in der keine Manipulation im Datenbestand möglich und nur
verbindliche Daten enthalten sind.
8
2. Die
eigentliche
interne
Datenbasis
mit
allen
Möglichkeiten
für
Testrechnungen/Vergleiche und mit allen Datensätzen, Dokumentationen, die
für Updates notwendig sind.
Die für vordefinierte Anwendungsprofile notwendigen TDBs nach Variante 1 werden in
regelmäßigen Abständen (etwa sechs Monate) automatisch aus Variante 2 erstellt und
zum Download angeboten. Als Anwendungsprofile werden die typischen Umgebungsbedingungen, für die in Deutschland momentan diskutierten drei möglichen Wirtsgesteine (Salz, Ton, Granit), bezeichnet. Weiterhin soll ein einfacher Zugriff direkt auf
die Datenbestände durch zuvor autorisierte Nutzer über konventionelle Web-Browser
(Abbildung 2) möglich sein. Hierbei werden vom Nutzer Abfragekriterien definiert und
die
entsprechenden
Detaildatensätze
aus
der
Datenbasis
ausgegeben.
Nutzungsarten sollen über ein gemeinsames Interface vermittelt werden.
9
Beide
Abbildung 2: Zugriffsschema über WWW-Interface
Für
die
zuvor
genannten
Anforderungen
an
die
Datenbankadministration,
Datenbestandspflege und Datenbankzugriff ergibt sich die Anforderung, ein
komfortables Nutzerinterface programmieren zu können. Da zum jetzigen Zeitpunkt
noch nicht geklärt ist, welche Skriptsprache verwendet werden soll bzw. über welche
Programmiersprachen Zugriffsmodule erstellt werden, muss die Datenbank hier eine
gewisse
Flexibilität
aufweisen.
Insbesondere
sollten
zum
Beispiel
folgende
Skriptsprachen unterstützt werden: PHP, Perl, Python, und Ruby. Während bei höheren
Programmiersprachen Wert auf C, C++, C#, Delphi sowie Java gelegt wird.
10
3.3 Technologische Anforderungen
Integritätssicherung
Um die Sicherung der Richtigkeit, Vollständigkeit und logischen Widerspruchsfreiheit
der Daten auf der Datenbank zu gewährleisten, muss die Datenintegrität durch
verschiedene Technologien gesichert werden. Die Integritätssicherung beinhaltet die
Sicherung der Daten vor Verlust oder Zerstörung bei Programm- oder Gerätefehlern
(physische Integrität), vor Schäden bei parallel oder konkurrierend zugreifenden
Nutzern und Programmen (operationale Integrität) und die inhaltliche Richtigkeit bei
Pflegeoperationen und Dateneingabe (semantische Integrität). In diesem Abschnitt
werden die Formen der Integrität erläutert und die Integritätssicherung anhand von
ausgewählten Datenbankfunktionen dargestellt.
Ein wichtiger Bestandteil bei der Sicherung der Integrität sind die Transaktionen.
Transaktionen sind Datenmanipulationen, die eine logische Einheit bilden und dabei die
Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand
überführen. Diese Transaktionen sollten nach dem ACID-Prinzip erfolgen:
-
Atomicity (Atomarität): Die Transaktion muss vollständig ausgeführt werden
oder gar nicht.
-
Consistency (Konsistenz): Nach Beendigung einer Transaktion muss der
Zustand der Datenbank wieder widerspruchsfrei sein.
-
Isolation: Es wird verhindert, dass sich in Ausführungen befindliche
Transaktionen gegenseitig beeinflussen. Das geschieht zum Beispiel über
Sperrprotokolle oder Zeitstempelverfahren.
-
Durability (Dauerhaftigkeit): Das Ergebnis einer Transaktion bleibt
dauerhaft in einer Datenbank erhalten und kann nicht mehr verloren gehen.
Die physische Integrität kann bei der Arbeit mit der Datenbank durch Fehler in den
Operationen einer Transaktion und durch Software-/Hardwarefehler verletzt werden.
Das Ziel der physischen Integritätssicherung ist die Sicherung der Vollständigkeit des
Datenbestandes und die Vermeidung von Datenverlust.
11
Die operationale Integrität sichert die Konsistenz der Daten beim Mehrbenutzerbetrieb,
d. h. zwei oder mehr Nutzer wollen einen Datensatz gleichzeitig ändern. Dabei kann es
zu Fehlern im Datenbestand kommen, obwohl jeder Nutzer für sich fehlerfrei arbeitet.
Zur Vermeidung dieser Konflikte muss ein fiktiver Einzelnutzerbetrieb und die
Isolation einer jeden Transaktion realisiert werden.
Die semantische Integrität wird durch Fehler (beabsichtigt oder unbeabsichtigt) bei der
Eingabe und Änderung der Daten verletzt. Durch den Vergleich von Daten und
Datenveränderungen mit individuell aufgestellten Integritätsbedingungen kann die
semantische Integrität gesichert werden. Diese Integritätsbedingungen sind beim
Datenbankentwurf sehr schwer abzuleiten, da diese von Fall zu Fall in oft
unterschiedlicher Weise von dem Entwickler aufzustellen sind.
Um die oben genannten Formen der Integritäten zu sichern, stellt das DBMS
verschiedene Funktionen und Möglichkeiten zur Verfügung, die im Folgenden
auszugsweise näher erläutert werden.
Die physische Integrität sichert man am einfachsten durch regelmäßige Backups der
Datenbank und durch Spiegelungen auf anderen Servern. Logging und Recovery sind
bei auftretenden Transaktions- oder Hardwarefehlern geeignete Wiederherstellungsverfahren. Beim Logging muss man zwischen der temporären Protokolldatei und der
Archiv-Protokolldatei
unterscheiden.
Die
temporäre
Protokolldatei
dient
zur
Wiederherstellung nach Transaktionsfehlern und bei einem Systemausfall. Die in der
Protokolldatei gesicherten Daten können nach dem Einbringen des ursprünglichen
Datenbestandes wieder überschrieben werden. Bei einem Festplattenausfall (Headcrash)
sind alle nach dem letzten Backup der Datenbank erfolgten Transaktionen notwendig.
Hierfür wird eine Archiv-Protokolldatei, in der alle Eintragungen der temporären
Protokolldateien archiviert sind, benötigt.
Beim Revocery wird der konsistente Zustand einer Datenbank nach einem Fehler
(Transaktionsfehler, Systemausfall oder Ausfall von Speichermedien) wiederhergestellt.
Es werden dabei verschiedene Recoverymaßnahmen (Tabelle 1) in Abhängigkeit vom
auftretenden Fehler angewandt.
12
Tabelle 1: Hauptfehlerquellen und Recoveryverfahren [I_WLOK02]
Hauptfehlerquellen
Transaktionsfehler
(z.B. Verletzung der
semantischen Integrität)
Systemfehler
(Verlust des
Hauptspeicherinhaltes)
Medienfehler
(Plattenfehler)
Recoveryverfahren
Zurücksetzen gescheiterter
Transaktion UNDO (R1)
Transaktionen beeinflusst andere
partielles Zurücksetzen
Transaktionen nicht
Partial REDO (R2)
partielles Wiederholen
Wiederholung derjenigen
abgeschlossenen Transaktionen,
deren Ergebnisse verloren
gegangen sind
Global UNDO (R3)
vollständiges
Zurücksetzen
Zurücksetzen aller gescheiterten
Transaktionen
Globales REDO (R4)
vollständiges
Wiederholen
Wiederholen aller
abgeschlossenen Transaktionen
Wenn mehrere Nutzer/Programme zur gleichen Zeit auf denselben Daten arbeiten, dann
kann es zur Verletzung der operationalen Integrität kommen. Zur Sicherung der
Ablaufintegrität gibt es verschiedene Gruppen von Verfahren, von denen drei kurz
vorgestellt werden.
Beim pessimistischen oder sperrorientierten Verfahren wird davon ausgegangen, dass
parallele laufende Transaktionen auf gleiche Daten eines Datenbestandes zugreifen. Um
Konflikte zu vermeiden, werden diese Daten für andere Transaktionen gesperrt.
Das optimistische Verfahren geht zunächst davon aus, dass parallel laufende
Transaktionen nicht zur selben Zeit auf die gleichen Daten zugreifen. Die Daten werden
nicht gesperrt, sondern erst im weiteren Verlauf auf Konflikte überprüft. Im Falle einer
Verletzung der operationalen Integrität werden die Transaktionen zurückgesetzt.
Um Konflikte zu erkennen, bekommen die Transaktionen beim Zeitstempelverfahren zu
Beginn eine Zeitmarke. Beim Lesen eines Datenobjektes bekommt diese eine
Lesezeitmarke und beim Schreiben eine Schreibzeitmarke. Durch einen Vergleich der
unterschiedlichen Zeitmarken kann ermittelt werden, ob die Daten von einer parallel
laufenden Transaktion verändert wurden sind. Kommt es zu einem Konflikt, dann
werden die Transaktionen zurückgesetzt und erneut gestartet.
13
Zur Sicherung der semantischen Integrität bieten DBMS einige Möglichkeiten, wie zum
Beispiel:
-
CHECK – Klauseln
-
Trigger
-
Entity-Integrität
-
Referentielle Integrität
CHECK-Klauseln werden zum Beispiel bei der Erstellung von Tabellen verwendet, um
den Wertebereich für Attribute einzuschränken. Die Aufnahme unsinniger Daten wird
somit mit einer Fehlermeldung verweigert.
Trigger werden direkt in der Datenbank hinterlegt und automatisch ausgeführt, wenn
Änderungen (INSERT, UPDATE, DELETE) in der Datenbank vorgenommen werden.
Diese können vor (BEFORE) oder nach (AFTER) einer Änderung eines Datensatzes
aufgerufen werden. Ein DELETE-Trigger reagiert beispielsweise auf einen DELETEBefehl und führt dabei eine vorher festgelegte Befehlsfolge (weitere DELETE-Befehle)
aus.
Die Entity-Integrität stellt sicher, dass jedes Entity einer Relation einen eindeutigen
Schlüssel besitzt, dessen Attribut zu keinem Zeitpunkt einen NULL-Wert enthalten
darf.
Besitzt eine Relation einen Fremdschlüssel, der auf einen Primärschlüssel einer anderen
Relation verweist, dann muss jeder Wert des Fremdschlüssels gleich einem Wert des
Primärschlüssels der anderen Relation sein, um die referentielle Integrität zu
gewährleisten [I_WLOK02].
14
Zugriffsschutz
Der Zugriffsschutz ist eine Anforderung mit sehr hoher Priorität, da es sich um eine
Standarddatenbank für die Anwendung in Endlager – und Sanierungsprojekten handelt,
mithin eine sehr sensible Problematik betrifft. Es muss daher sichergestellt werden, dass
nur berechtigte Personen Änderungen an der Datenbank vornehmen können. Die
öffentliche Verfügbarkeit der Datenbank im Internet macht es notwendig, dass die
übertragenen Anmeldungsdaten mittels SSL (Secure Sockets Layer) verschlüsselt
werden können.
Die Datenbank wird parallel von der GRS (in deren Rechenzentrum in Berlin) und vom
Forschungszentrum Dresden-Rossendorf und nicht von einem externen HostingDienstleister bereitgestellt. Dies garantiert eine Langzeitverfügbarkeit des Hosts an sich.
Eine hohe durchschnittliche Verfügbarkeit und Sicherheit ist durch die entsprechenden
Rechenzentren abzusichern.
Nutzer, mit wohldefinierten Rechten und abgestuftem Zugriff auf den Datenbestand,
müssen verschiedenen Nutzergruppen zugeordnet werden,. Die Datenintegrität wird so
über eine Beschränkung des Nutzerzugriffs auf qualifizierte und autorisierte Personen
unterstützt. Folgende drei Nutzergruppen sollen unterschieden werden:
-
Nutzer, welche die Datenbasis per Abfrage nutzen, um ihren spezifischen
Datenbedarf zu befriedigen. Mitglieder dieser Gruppe (welche die DefaultGruppe ist) besitzen lediglich Leserechte für die Datentabellen (ohne
ausgewählte Tabellen für die Administration). Sie dürfen aus THEREDA
Daten abfragen und entsprechend den Möglichkeiten der Nutzerschnittstelle
weiterverarbeiten.
-
Editoren, welche als qualifiziert genug angesehen werden, die Datenauswahl,
-bewertung und -eingabe bzw. ggf. Datenkorrekturen durchzuführen.
Zusätzlich zu den Nutzern der Default-Gruppe „users“ besitzen die Editoren
die
Schreibberechtigung auf
die
Tabellen
mit
thermodynamischen
Datensätzen.
-
Administratoren, welche die Gesamtverwaltung von THEREDA absichern,
mit Lese- und Schreibrechten für sämtliche Tabellen. Aufgabe der
15
Administratoren ist zudem die Sicherstellung des regelmäßigen Betriebs von
THEREDA sowie die Pflege der Datenbank inklusive der Bereitstellung von
Updates bei Bedarf.
3.4 Kostenanalyse
Bedingt durch die anvisierte Langzeitverfügbarkeit auf Basis öffentlicher Steuergelder
ist die Kostenminimierung ein wichtiger Bestandteil der Planungen. Die Kosten der
Datenbank lassen sich in einmalige, laufende und spekulative Kosten aufteilen.
Einmalige Kosten
Die einmaligen Kosten sind die Kosten, die einmal zum Beginn eines Projektes
anfallen.
Darunter fallen die Kosten für die Datenbank, den verwendeten Server (Hardware und
Software) und gegebenenfalls Installationskosten. Installiert wird die Datenbank auf
Servern beteiligter Projektpartner (siehe Kapitel 1), so dass die Kosten für den Server
und die Installation sehr gering ausfallen werden.
Ein Teil der Daten wird momentan noch in Microsoft Access Tabellen bereitgestellt.
Deswegen sollte eine ODBC-Schnittstelle verfügbar sein, damit diese bereits
strukturiert vorliegenden Daten auf einfache Weise importiert werden können. Eine
erneute Aufbereitung und Eingabe dieser Daten wäre ökonomisch nicht sinnvoll.
Betriebskosten
Die Betriebskosten setzen sich aus Kosten für das Hosting, die Serverwartung und
Abschreibungen zusammen. Diese Kosten fallen sehr gering aus, da kein externer
Dienstleister (Webhoster) in Anspruch genommen werden muss. Da auch keine
Investitionen getätigt werden müssen, fallen auch keine Abschreibungskosten an. Die
meisten laufenden Kosten werden die Personalkosten sein, die durch die Server/Datenbankwartung
und
Datenmanipulationen
entstehen.
Dabei
werden
die
Personalkosten für die Datenmanipulation am größten ausfallen, da die komplette
16
Administration/Wartung
vom
Verbundpartner
Gesellschaft
für
Anlagen-
und
Reaktorsicherheit (GRS) mbH in Berlin übernommen wird.
Spekulative Kosten
Die spekulativen Kosten können nicht vorab quantifiziert werden, weil diese Kosten
nicht notwendigerweise auftreten müssen. Unter diese fallen zum Beispiel die Kosten
für das Update einer kostenpflichtigen Datenbank, für die Umstellung auf eine andere
Datenbank, für kostenpflichtigen Support oder für Weiterbildungen. Zusätzliche Kosten
ergeben sich durch die lange Laufzeit des Projektes und dem ständigen technologischen
Fortschritt von Hard- und Software, z.B. wird der jetzige Server nach einigen Jahren
veraltet sein und ersetzt werden müssen.
3.5 Analyse der Datentypen und des Datenbestandes
Der Datenbestand setzt sich aus verschiedenen Kategorien zusammen. Eine relativ
kleine Anzahl von Datensätzen dient der näheren Beschreibung der verschiedenen
chemischen Elemente und den daraus gebildeten Verbindungen (z.B. Minerale oder in
Wasser gelöste Ionen). Hierunter fallen unter anderem chemische Symbole, Bezeichner,
Atommassen, elektrische Ladungen oder Kristallformen. Der Hauptteil der Datenbank
umfasst die numerischen Werte für chemische Reaktionsparameter wie z.B.
Stabilitätskonstanten, Enthalpien, Entropien oder Wärmekapazitäten. Ein weiterer
numerischer Teil enthält die Parameter, welche die Wechselwirkungen zwischen
elektrisch geladenen Teilchen (Ionen) beschreiben. Alle numerischen Werte stammen
aus wissenschaftlichen Veröffentlichungen. Die zugeordneten bibliographischen
Informationen werden in der Datenbank ebenfalls hinterlegt. Schließlich werden noch
einige
Metadaten
(Namen
und
Institutionen
der
Datenbank-Bearbeiter,
Versionshinweise, etc.) vorgehalten. Weitere Details hierzu sind im Kapitel 7 zu finden.
Hier soll zunächst nur auf den abzuschätzenden Umfang des Gesamtdatenbestandes
eingegangen werden. Für eine solche Betrachtung ist zudem noch wichtig, dass zum
gegenwärtigen Zeitpunkt (nach über 120 Jahren der Gewinnung chemischer Stoffdaten)
der Hauptteil der interessierenden Verbindungen bereits hinlänglich genau untersucht
17
ist. Das bedeutet, dass für die Zukunft (hier: die weiter oben abgeschätzten 40 Jahre
Bestand der THEREDA-Datenbasis) nicht damit zu rechnen ist, das der gegenwärtig
weltweit verfügbare Datenbestand um mehr als einen einstelligen Prozentbetrag
anwachsen wird.
Alle
nachfolgenden
numerischen
Werte
sind
wiederum
Schätzungen
von
Maximalwerten (außer der Liste der Elemente, welche vom Projekt vorgegeben ist). Die
nachfolgenden Elemente sind expliziter Bestandteil der THEREDA-Aktivitäten. Dazu
kommen noch Sauerstoff (O) und Wasserstoff (H) als wesentliche Komponenten fast
aller Spezies (diese sind daher nicht jeweils separat aufgeführt). In der momentanen
ersten Projektphase konzentrieren sich die Arbeiten zur Datensichtung, -bewertung und
-auswahl auf die folgenden Elemente.
1. Actinide, Spalt- und Aktivierungsprodukte:
-
Pa, Th, U, Np, Pu, Cm, Am
-
Sm, I, Se, Cs, Ru, Sr, Ni, Tc, Zr, Sb, Eu, Co, Fe, Ra, Nb, Mo, Pd, Ag
2. Zircalloy (Umkleidung der Brennstäbe) & Containermaterial:
-
Fe, Zr und Legierungselemente (Sn, Ni, Cr, Nb)
3. Toxische Schwermetalle und andere Schadstoffe:
-
Zn, Cr, Co, Ni, Cu, Cd, Hg, Pb, As
4. Lösungsbestandteile im Salz:
-
Na, K, Mg, Ca, Cl, S, C
5. Tongestein (Alumosilikate und Verwitterungsprodukte)
-
Al, Si, K, Fe
6. Zement-Phasen
-
Ca, Al, Si
7. Komponenten der häufigsten Laborsysteme
-
N, Cl
Da einige Elemente in mehreren Kategorien erfasst sind, ergibt sich eine Gesamtzahl
von 45. Bei den aus den Elementen gebildeten Verbindungen (Spezies) wird von 30
Mineralen und 50 gelösten Komplexen (Ionen) ausgegangen. Pro Verbindung wiederum
sind 6 Reaktionsdaten (log k /
0
fG
/
0
fH
/ S0 / Cp0 / V0) mit jeweils 6 Temperatur-
18
koeffizienten vorstellbar. Das entspricht also 72 Zahlenwerten, wenn man
berücksichtigt, dass im Idealfall jeder numerischer Wert noch eine Fehlerangabe besitzt.
Als Reaktionsdaten sind also maximal 44 × (30 + 50) × 72 = 253440 Datensätze zu
erwarten.
Für die Erfassung der Ionen-Wechselwirkungsparameter sind zunächst die möglichen
Ionenkombinationen abzuschätzen. Hier wird von 50 Paaren und 100 Tripeln
ausgegangen. Pro Ionenkombination sind 9 Parameter (8 für das Pitzer-Modell nach
[L_PITZ01] und 1 für das einfachere, alternative SIT-Modell) mit bis zu 4
Temperaturkoeffizienten denkbar, inklusive Fehlerangaben also wiederum 72
Zahlenwerte. Insgesamt ergeben sich so (50 + 100) × 72 = 10800 Datensätze zur
Beschreibung der Ionen-Wechselwirkung.
Also ergibt sich als Maximalschätzung ein Umfang von ca. 254000 Datensätzen mit
zugehörigen Literatur-Referenzen. Die anderen oben genannten Datenkategorien sind
im Vergleich dazu von der Menge her vernachlässigbar.
Ein alternatives (und womöglich realistischeres) Szenario zur Abschätzung der Größe
der Datenbasis bei Ende des Projektes basiert auf dem verfügbaren Personaleinsatz. Es
wird davon ausgegangen, dass 5 Mitarbeiter, jeweils den halben Tag (4 Stunden), 220
Tage im Jahr, 3 Jahre lang Daten einpflegen und im Durchschnitt zwei Datensätze pro
Stunde bewältigen. Dies ergibt als Obergrenze lediglich 5 × 4 × 220 × 3 × 2 = 26400
Datensätze, also deutlich unter der obigen Abschätzung.
Unabhängig von der Vorgehensweise bei der Abschätzung des Gesamtdatenbestandes
kann festgehalten werden, dass die Größe der Datenbank vergleichsweise klein bleiben
wird.
19
4 Konzeption einer Auswahlstrategie
4.1 Datenbankmodelle
Unter dem Datenbankmodell versteht man das Konzept wie Daten in ein
Datenbanksystem gespeichert werden und die Datenmanipulationen erfolgen. In den
meisten Fällen werden fünf Datenbankmodelle unterschieden:
-
Hierarchisches Datenbankmodell
-
Netzwerkdatenbankmodell
-
Objektorientiertes Datenbankmodell
-
Relationales Datenbankmodell
-
Objektrationales Datenbankmodell
Das hierarchische Datenbankmodell und das Netzwerkdatenmodell sind die ältesten
Datenbankmodelle und werden in der Praxis kaum noch eingesetzt. Die Gründe hierfür
sind u.a. die sehr beschränkten Modellierungsmöglichkeiten beim hierarchischen
Datenbankmodell sowie die anspruchsvolle DDL (Data Definition Language) und DML
(Data Manipulation Language) beim Netzwerkdatenmodell. Daher wird auf diese
beiden Datenbankmodelle in dieser Diplomarbeit nicht weiter eingegangen.
Bei objektorientierten Datenbanken werden die Daten als Objekte im Sinn der
Objektorientierung abgelegt. Jedes Objekt besitzt Attribute bzw. Eigenschaften, welche
ein Objekt näher bezeichnen, zum Beispiel gehört die Molare Masse und das Symbol zu
dem Objekt Element. Die Datenbasis besteht aus einer Sammlung von Objekten, wobei
jedes Objekt einen physischen Gegenstand, ein Konzept, eine Idee usw. repräsentiert. In
anderen Datenbanksystemen werden die Daten satzorientiert (Netzwerk- und
Hierarchisches Datenmodell) oder mengenorientiert (relationales
Datenmodell)
abgelegt. Einige Anforderungen an das objektorientierte Datenbankmodell sind:
-
Unterstützung komplexer (zusammengesetzter) Objekte
-
Unterstützung von Objekttypen und Klassenbildung
-
Vererbung von Objekteigenschaften über die Klassenhierarchien
20
-
Identität des Objektes muss unabhängig sein
-
Schutz der Objekte durch Methoden, Zugriff nur über vorher definierte
Schnittstellen
Beim relationalen Datenbankmodell (Abbildung 3) werden die Daten in Relationen
(zweidimensionale Tabellen) gespeichert. Diese Tabellen werden über Schlüssel
definiert (Primärschlüssel) und verknüpft (Fremdschlüssel). Die Beziehungen werden
meistens über ein Entity-Relationship-Modell (Abbildung 4) dargestellt.
Abbildung 3: Relationales Datenmodell
Abbildung 4: Entity-Relationship-Modell
Das relationale Datenbankmodell ist einfach zu verstehen und mit SQL hat sich ein
Sprachstandard für DDL und DML weitgehend durchgesetzt. Der Performancenachteil
gegenüber dem hierarchischen Datenbankmodell hat sich inzwischen durch die
Verbesserung der Leistungsmerkmale moderner Rechnersystem relativiert. Deswegen
ist das relationale Datenbankmodell das heute am häufigsten verwendete Modell.
21
Das objektrationale Datenbankmodell ist ein Bindeglied zwischen dem relationalen und
dem objektorientierten Datenbankmodell. Ziel ist es, das erfolgreiche relationale
Datenbankmodell mit den Vorteilen des objektorientierten zu verbinden und dabei die
Kompatibilität zum relationalen Datenbankmodell zu bewahren. Objektrelationale
DBMS erweitern das relationale Datenbankmodell um die Fähigkeit Daten
objektorientiert zu modellieren. Der SQL:99 Standard wurde um objektorientierte
Funktionalitäten
erweitert,
deswegen
können
die
Anbieter
ihre
DBMS
zu
objektrationalen DBMS ausbauen.
Beim THEREDA-Projekt wurde bereits im Vorfeld festgelegt, dass nur relationale und
objektrelationale Datenbanken zum Einsatz kommen sollen. Deswegen werden in dieser
Diplomarbeit nur diese beiden Typen betrachtet.
4.2 Lizenzmodelle
Das den einzelnen Datenbanken zu Grunde liegende Lizenzmodell ist für die Bewertung
der verschiedenen Analysenergebnisse, insbesondere für die Punkte Langzeitverfügbarkeit, Sicherheit und Kosten von großer Bedeutung. Daher werden im
Folgenden die beiden wichtigsten Klassen der Lizenzmodelle kurz charakterisiert und
repräsentative Beispiele aufgeführt.
4.2.1 Closed Source
Als Closed Source wird Software bezeichnet, bei der der Programmcode nicht
zugänglich ist. Der Hersteller der Software kompiliert seinen Programmcode zu einem
lauffähigen Programm und will somit den Zugang zum Programmcode für Dritte
erschweren. Closed Source wird meistens bei kommerzieller Software (proprietäre
Software) genutzt. Somit kann nur der Hersteller Änderungen am Programmcode
22
vornehmen. Durch Reverse Engineering kann man den Quellcode zurückgewinnen, was
aber die meisten Firmen in ihren Lizenzbedingungen verbieten.
4.2.2 Open Source
Als Open Source wird Software bezeichnet, bei der der Programmcode für jeden
einzusehen ist. Die Veröffentlichung von Open Source Software erfolgt unter einer
Open Source Lizenz, wo der Quellcode verändert und weitergeben werden darf.
Dadurch kann jeder Veränderungen am Programm vornehmen und zum Beispiel
aufgetretene Sicherheitslücken selbst schließen. In Tabelle 2 werden einige Vor- und
Nachteile von Open Source Software aufgeführt.
Tabelle 2: Vor- und Nachteile von Open Source Software
Vorteile
Nachteile
- Niedrigere Kosten
- Fehlende Produktverantwortlichkeit
- Höheres Sicherheits-Niveau
- Oft keine offizielle Supportstelle
- Bewertung durch Nutzer
- Planung neuer Versionen schwer
- Modifizier-/Erweiterbarkeit
möglich
- Community
Damit eine Pflege (und ggf. Weiterentwicklung und Updates) von Open Source
Software aber tatsächlich realistisch ist, sollte auch eine hinreichend große
Entwicklergemeinde (Community) engagiert sein. Je größer diese ist, desto besser ist
erfahrungsgemäß der Support in den Foren und desto schneller werden Updates bei
Programmfehlern verfügbar gemacht. Sicherheitslücken können durch den offenen
Programmcode von jedem Entwickler geschlossen werden. Dies geschieht meist
schneller als bei einer Softwarefirma. Die qualitativen Bewertungen der jeweiligen
Software
erfolgen
von
unabhängigen
Personen,
Glaubwürdigkeit besitzen [I_BUCK01].
23
so
dass
diese
eine
hohe
Engagement und Größe der Community sind naturgemäß nur schwer quantifizierbare
Eigenschaften. In der vorliegenden Arbeit werden daher diese näherungsweise über die
Beitragsanzahl in den relevanten Foren und Newsgroups, Downloadzahlen bei
http://sourceforge.net/ und die Anzahl der Installationen/Referenzen beurteilt.
4.2.3 Open Source Initiative (OSI) zertifizierte Lizenzen
Die Open Source Initiative (OSI) ist eine gemeinnützige Organisation, die 1998 von
Bruce Perens und Eric Raymond gegründet wurde. Die OSI überprüft von Dritten
eingereichte Open Source Lizenzen bezüglich der Einhaltung der Open Source
Definition (OSD), bei positivem Gutachten wird ein entsprechendes Zertifikat
ausgestellt. Unter anderem sind bisher die GNU General Public License (GPL), die
New BSD License und die PHP License von der OSI zertifiziert. Eine vollständige Liste
kann unter [I_LIST01] abgerufen werden.
4.3 Definition und Beurteilung von Auswahlkriterien
In diesem Kapitel werden die Kriterien benannt und in ihrer Bedeutung geordnet,
welche für die Erfüllung der unter Kapitel 3 analysierten Anforderungen notwendig
sind. Diese Kriterien sind die Basis für die Auswahlentscheidungen in Kapitel 6 und
sind in Tabelle 3 zusammengefasst.
Tabelle
3
ordnet
gleichzeitig
die
Auswahlkriterien
nach
den
Kategorien
„Projektkritisch“, „Wichtig“ und „Projektunkritisch“. Die projektkritischen Kriterien
muss die zukünftige Datenbank unbedingt erfüllen. Werden diese nicht erfüllt, dann
kann die Funktionalität des Gesamtprojektes nicht gewährleistet werden. Durch
Nichterfüllung der wichtigen Kriterien ist die Funktionalität des Gesamtprojektes nicht
grundsätzlich gefährdet. Dennoch sollte die Datenbank diese erfüllen, da sie
Voraussetzung für ein effizientes und sicheres Funktionieren der Datenbank sind.
24
Kriterien, die unter projektunkritisch fallen, sind für das Gelingen des Projektes nicht
notwendig, wären aber wünschenswert.
Zum besseren Verständnis von Tabelle 3 sind noch einige Anmerkungen notwendig.
Für die Gewährleistung der Langzeitverfügbarkeit sind sowohl die (weitestgehende)
Einhaltung des SQL:92 Standards als auch die Offenheit des Quellcodes essentiell. Nur
durch die Offenheit des Quellcodes kann gewährleistet werden, dass die Datenbank
ständig weiterentwickelt wird. So ist man von Softwareherstellern unabhängig, denn
diese können die Weiterentwicklung und den Support jederzeit einstellen. Ist der
Quellcode Closed Source, so kann auch eine entstandene Community diese Datenbank
nicht weiterentwickeln. Der SQL:99 Standard wird nur als wichtig angesehen, da dieser
in kaum einer Datenbank im großen Umfang umgesetzt ist. Bei Datenbanken, die mit
der Konformität zum SQL:99 Standard werben, ist nur ein geringer Teil des SQL:99
Standard wirklich umgesetzt [I_WLOK01]. Unter dem Gesichtspunkt der hohen
Sensibilität der erfassten Daten sind sowohl eine sichere Kommunikation mit der
Datenbank als auch die Gewährleistung von logischer und physischer Integrität
unabdingbar. Wichtige Elemente sind hierbei die Verfügbarkeit von ACIDTransaktionen, die Unterstützung von Triggern und die Bereitstellung von CHECKBedingungen. Schließlich nützt der beste Datenbestand wenig, wenn nicht auch
Werkzeuge für den Aufbau einer modernen Nutzerschnittstelle verfügbar sind, also
entsprechende Skript- und Programmier-sprachen (und daraus aufgebaute komplexere
Tools) auf die Datenbank zugreifen können. All diese Auswahlkriterien sind daher als
projektkritisch eingestuft.
Innerhalb der Kategorie „Wichtig“ ist die Absicherung der Kosteneffizienz (unter Open
Source gewährleistet, aber im Prinzip auch auf anderen Wegen möglich) eingeordnet,
hiermit verbunden ist der Bedarf einer ODBC-Schnittstelle für die Übernahme bereits
erfasster Daten. Weiterhin wird die Unterstützung von mindestens zwei Betriebssystemen sowie die Verfügbarkeit von Tools für eine einfache Administration als
wichtig erachtet.
25
Als projektunkritisch sind die Toleranz betreffs hoher absoluter Zugriffszahlen,
Nutzerzahlen und einer hohen Zugriffsfrequenz, sowie die maximal verwaltbare
Datenmenge zu bewerten, da all diese Zahlen relativ gering ausfallen (siehe Kapitel
3.5).
Tabelle 3: Gruppierung der Auswahlkriterien für ein DBMS nach deren Relevanz für das Gelingen des
THEREDA-Projektes
Projektkritisch
Wichtig
Projektunkritisch
-
SQL:92-Standard
-
SQL:99-Standard
-
Open Source
-
Kosteneffizienz
(Lizenz,
-
ODBC-Schnittstelle
-
Datenbankgröße
Community)
-
Unterstützte
-
Nutzerzahlen
-
Sichere
Kommunikation
(SSL)
-
Betriebssysteme
-
Tools zur einfachen
Administration
Logische
Datenintegrität
(ACID, Trigger,
CHECK)
-
Skript- und
Programmiersprache
n
26
-
Zugriffszahlen und
-frequenz
5 Grundlagen der Datenbankmangementsysteme
5.1 Konzept eines DBMS
Datenbankmanagementsysteme stellen Werkzeuge bereit, mit denen eine oder mehrere
Datenbanken (Abbildung 5) erstellt, mit Daten gefüllt und verwaltet werden können.
Abbildung 5: Grobarchitektur von Datenbanksystemen nach Stahlknecht [L_STAH01]
Von einem DMBS wird gefordert, dass:
-
die Daten logisch und physisch unabhängig sind,
-
die Datenintegrität gewährleistet wird,
-
die Daten redundanzfrei sind.
Daraus ergeben sich die folgenden Hauptanforderungen an die Datenbank:
-
die Daten müssen nach beliebigen Merkmalen auswertbar und
verknüpfbar sein,
-
die Daten dürfen festgelegten Benutzern ganz oder teilweise zugänglich
sein,
-
die Daten müssen für bestimmte Benutzer gesperrt werden können,
-
eine Abfrage von Daten muss in kurzer Zeit zum Ergebnis führen.
27
5.2 Übersicht relevanter DBMS
In diesem Kapitel wird jedes betrachtete DBMS kurz vorgestellt. Es wurden insgesamt
elf DBMS geprüft. Da ständig neue Versionen (Updates/Patches) veröffentlicht werden,
wurde der 16.03.2007 als Stichtag festgelegt. Alle neuen Versionen nach diesem
Stichtag konnten in der vorliegenden Arbeit leider nicht mehr betrachtet werden. Bei
der Zusammenstellung der Übersicht wurde zudem bewusst auf Datenbanken verzichtet,
welche dediziert für die Nutzung in Großunternehmen ausgelegt sind, dadurch eine
überdurchschnittliche Komplexität aufweisen, oft nur auf Mainframes laufen und/oder
sehr hohe Kosten verursachen. Als Beispiele hierfür seien Oracle 10g Enterprise Edition
(entweder $800 pro Nutzer bei einer Mindestnutzerzahl von 25 oder $40000 pro CPU
für unbegrenzte Nutzeranzahl) [I_ORAC03] oder SolidDB 6 (Hersteller Solid
Information Technology, Preise nur auf Anfrage) genannt [I_SOLI01].
Die Vorstellung der einzelnen DBMS erfolgt in Kurzform und nach alphabetischer
Reihenfolge.
Firebird
Die Firebird Datenbank gibt es aktuell in der Version 2.0.1 und wird unter der IDPL
(Initial Developer's PUBLIC LICENSE) Lizenz bereitgestellt. Die Open-SourceDatenbank ist aus der von Borland entwickelten InterBase Version 6 entstanden.
Borland hatte im Jahre 2000 den Quellcode freigegeben, da die Datenbank kaum
Marktanteil besaß. Durch die Freigabe wollte man das Produkt wiederbeleben und
durch kommerziellen Support höhere Einnahmen erzielen. Dieses Konzept ging jedoch
nicht auf, so dass Borland den Code wenig später (Version 7.1) wieder schloss. Die bis
dahin entstandene Community entwickelte das Produkt eigenständig unter dem Namen
Firebird weiter. Betrachtet wurde nur die Version 1.5, da die Version 2.0.1 erst Ende
März 2007 veröffentlicht wurde und noch keine zuverlässigen Informationen/Tests zur
Verfügung standen. Die Version 1.5 gibt es für Microsoft Windows und Linux
[I_FIRE01]. Die Datenbank bietet die grundlegenden Funktionen, aber jedoch nur
wenige anspruchsvolle Features [I_HORS01]. Unter anderem fehlen Firebird folgende
Funktionen:
28
-
Schemata
-
Volltext-Suche
-
SSL-Verschlüsselung zwischen Client und Server
-
Indexierungsalgorithmen außer B-Tree
IBM DB 2 Express-C
IBM DB 2 Express-C ist die kostenlose Version der DB2 Datenbank von IBM. Diese
wurde erstmals Anfang 2006 unter einer eigenen Lizenz (nicht Open Source) von IBM
veröffentlicht. Die kostenlose Version enthält folgende Einschränkungen gegenüber der
kommerziellen Version:
-
max. 2 CPUs werden unterstützt, dabei werden nur die Sockel gezählt und
nicht mehrere Kerne bzw. Hyperthreading
-
max. 4 GB Hauptspeicher
Die Größe der Datenbank, Anzahl der Benutzer und die Instanzen oder Datenbanken
pro Server sind nicht beschränkt. Sollte IBM die kostenlose Datenbank nicht mehr
weiterentwickeln bzw. nicht mehr anbieten, dann kann die aktuelle Version nicht von
der Community weiterentwickelt werden, da der Quellcode nicht Open Source ist.
Dadurch ist die Community wesentlich kleiner als von Datenbanken, bei denen
Quellcode Open Source ist. Die Datenbank unterstützt die Programmiersprachen
C/C++, Java, .NET und PHP und unterstützt diverse Betriebssysteme (Microsoft
Windows, Linux, Unix u.a.) [I_IBMD01].
Informix
Informix wurde 2001 von IBM übernommen und wird seitdem von IBM
weiterentwickelt. Aktuell gibt es die Version 10 für alle gängigen Betriebssysteme zum
Download. Seit dem Kauf der Informix-Datenbank von IBM werden die Funktionen
von Informix zu DB2 von IBM hinzugefügt. Somit soll der Umstieg von Informix auf
DBD für die Anwender von Informix erleichtert werden.
Der Quellcode von Informix ist nicht Open Source und die Datenbank muss käuflich
erworben werden. Die Preise variieren je nach Version zwischen 100 und 2000 Euro.
Um die Datenbank hat sich keine große Community entwickelt, da Informix nur als
29
kommerzielle Version zur Verfügung steht. Über den Funktionsumfang der Datenbank
konnten keine nennenswerten Angaben gefunden werden [I_INFO01].
Ingres
Ingres wurde in den 70er Jahren an der University of California, Berkeley, USA unter
Mike Stonebreaker entwickelt. Aktuell gibt es eine Enterprise und eine Community
Edition in der Version 2006 Release 2. Der Unterschied zwischen der kommerziellen
Enterprise Edition und der unter GPL (GNU General Public License Version 2)
veröffentlichten Community Edition ist, dass für die Enterprise Edition Support von
Ingres angeboten wird. Weitere Unterschiede bestehen nicht. Ingres unterstützt
Microsoft Windows, Linux und andere Betriebssysteme. Obwohl die Datenbank schon
seit Version Ingres r3 als Open Source Software freigegeben ist, ist die Community
nicht wesentlich größer geworden. Bei der älteren Version Ingres r3 fehlten wichtige
Features wie Before-Trigger, Check-Bedingungen und SSL-Verschlüsselung, die jetzt
in der Version 2006 Release 2 bis auf die SSL-Verschlüsselung alle enthalten sind
[I_INGR01], [I_HORS01].
MaxDB
MaxDB wurde 1977 unter dem Namen VDN (Verteilte Datenbanksysteme Nixdorf) an
der TU Berlin als Forschungsprojekt mit dem Partner Siemens Nixdorf AG entwickelt.
Bis 1997 wechselten oft die Rechte und Namen an VDN. 1997 übernahm SAP AG die
Datenbank und benannten sie in SAP DB um. Im Jahre 2000 veröffentlichte die SAP
AG die Datenbank unter der GNU Lizenz. 2003 wurde eine Kooperation zwischen der
SAP AG und MYSQL AB gegründet, welche die Datenbank zu MaxDB umbenannte.
MaxDB ist eine SAP-zertifizierte Open Source Datenbank für OLTP- und OLAP
Einsätze. Aktuell gibt es die Version 7.6 für Microsoft Windows 2000/XP, Linux, Sun
Solaris und andere Systeme unter der GPL.
MaxDB hat seine Stärken bei der parallelen Verarbeitung, da es eines der wenigen
Systeme ist, welches Multi-Threading, Multi-Processing und die parallele AbfrageBearbeitung beherrscht. Es fehlen aber auch wichtige Features wie zum Beispiel
30
Before-Trigger, sämtliche Indexierungs-Algorithmen außer B*-Tree und zweiphasiges
Commit [I_MAXD01], [I_HORS01].
Microsoft SQL Server 2005 Express
Microsoft SQL Server 2005 Express ist die kostenlose Version des Microsoft SQL
Server 2005, welchen es in den Versionen Workgroup, Standard und Enterprise gibt.
Die erste Version unter diesem Namen wurde 1992 als Microsoft SQL Server 4.2
veröffentlicht. Die Express Version gibt es nur für Microsoft Windows Betriebssysteme
und wird nicht unter einer Open-Source-Lizenz veröffentlicht. Die Version ist nicht
Open Source, somit hat sich auch keine große Community gebildet. Des Weiteren
unterstützt die Datenbank nur einen Prozessor, mit max. 1 GB RAM und eine maximale
Datenbankgröße von 4 GB. Über vorhandene bzw. nicht vorhandene Funktionen
werden keine nennenswerten Angaben gemacht [I_EDIT01].
MySQL
MySQL wurde 1995 von MySQL AB als Clone von mSQL entwickelt und wird als
Duales Lizenzsystem angeboten. Die Datenbank kann unter der GPL entwickelt und
vertrieben werden. Wenn man seinen Quell-Code nicht unter der GPL lizenzieren und
vertreiben will, dann bietet MySQL eine flexible kommerzielle OEM-Lizenz an.
MySQL 5.0 ist die aktuelle Version, die es unter anderem für Windows, Linux und
Solaris gibt.
Um die Datenbank hat sich schnell eine große Community gebildet, da das
Datenbanksystem eines der vier Säulen das LAMP-Stacks bildet (Linux, Apache,
MySQL, PHP/Python/Perl).
Seit der Version 5.0 ist MySQL auch für komplexe Unternehmens-Anwendungen
einsetzbar. Unter anderem unterstützt die neue Version jetzt Stored Procedures (nach
SQL 2003), Trigger und Updateable Views. Des Weiteren unterstützt MySQL MultiThreading und Mulit-Prozessor-Support. Einschränkungen gibt es bei den Constraints,
da MySQL nur UNIQUE und NOT NULL bietet, sowie bei der Partitionierung. Die
Rollen- und Gruppenkonzepte für das Rechtemanagement fehlen vollständig
[I_HORS01].
31
Oracle Database 10g Express Edition
2005 stellte Oracle die 10g Express Edition als kostenlose Variante seiner Datenbank
Oracle 10g vor. Diese Version ist für Microsoft Windows und Linux erhältlich. Oracle
nutzt eine eigene Lizenz, so dass der Quellcode nicht Open Source ist und somit auch
nicht von der Community weiterentwickelt werden kann. Aus diesem Grund hat sich
auch keine große Community um die Datenbank gebildet. Des Weiteren besitzt diese
Version einige Einschränkungen im Vergleich zu den kostenpflichtigen Versionen
(Standard Edition, Standard Edition One, Enterprise Edition). Zu den Einschränkungen
zählen, dass die maximale Datenbankgröße 4 GB beträgt, nur maximal 1 GB RAM und
ein Prozessor benutzt wird. Über vorhandene bzw. nicht vorhandene Funktionen werden
keine nennenswerten Angaben gemacht [I_ORAC01], [I_ORAC02].
PostgreSQL
POSTGRES wurde ursprünglich als universitäres Projekt an der University of
California (Berkeley Computer Science) entwickelt. Als das Projekt 1994 auslief, wurde
die Datenbank in Postgres95 umbenannt und unter der BSD-Lizenz als Open-SourceSoftware veröffentlichtet. 1996 erhielt die Datenbank ihren jetzigen Namen
PostgreSQL. PostgreSQL ist aktuell in der Version 8.2 für Microsoft Windows, Linux
und andere Systeme erhältlich. Durch die enorme Funktionsvielfalt und der BSD-Lizenz
hat sich eine sehr große Community gebildet. Die BSD-Lizenz erlaubt im Gegensatz zur
GPL, das Schließen von Codes. Somit können Unternehmen selbstentwickelte Features
zum Quellcode hinzufügen und dann selbst verteilen oder verkaufen. Des Weiteren ist
PostgreSQL weitgehend konform mit dem SQL:92 Standard und hat auch schon einige
Teile des SQL:99 und SQL:2003 Standards umgesetzt [I_EISEN01]. Somit stehen, die
in dem Standard geforderten Funktionen zur Verfügung. Einschränkungen müssen bei
der Parallelisierung und auch im Rechtemanagement akzeptiert werden werden. Es
können nur Rechte auf Tabellen, aber nicht auf Spalten vergeben werden. PostgreSQL
unterstützt zwar mehrere Prozessoren, aber kein Multi-Threading [I_HORS01].
32
SQLite
SQLite ist eine C-Programmbibliothek, welche eine relationale Datenbank enthält und
die ACID-Eigenschaften erfüllt. Die Datenbank wurde im Jahr 2000 von D. Richard
Hipp entwickelt und gibt es aktuell als Version 3.4.0 für Microsoft Windows und Linux
unter der Public Domain Lizenz kostenlos zum Runterladen. Public Domain bedeutet,
dass die Software gemeinfrei ist und somit keinem Urheberrecht mehr unterliegt. Der
Vorteil dieser Datenbank gegenüber anderen Datenbanken ist, dass durch das Einbinden
der Bibliothek die Applikation um Datenbankfunktionalitäten erweitert wird, ohne auf
externe Softwarepakete angewiesen zu sein. Nachteile sind unter anderem, dass die
Datenbank nur teilweise mit dem SQL-92 Standard konform ist, dass bei Bearbeitung
von Daten die komplette Datenbank für Schreiboperationen gesperrt wird und es keine
richtige Rechteverwaltung gibt [I_SQLI01].
SYBASE SQL Anywhere Developer Edition
SQL Anywhere Developer Edition wird als kostenlose Entwicklungs- und Testversion
angeboten und ist im Moment in der Version 10.0 erhältlich. Diese Version unterstützt
alle gängigen Betriebssysteme und besitzt keine Einschränkungen zur SQL Anywhere
Version.
Der Quellcode der Datenbank ist nicht Open Source. Die 1 CPU Lizenz der SQL
Anywhere 10.0.1 Datenbank kostet momentan 2363 €. Laut Hersteller ist SQL
Anywhere eine Datenbank der Enterprise-Klasse, die hunderte GB Daten mit mehreren
Millionen Zeilen verwalten kann [I_SYBA01].
33
6 Auswahl des DBMS
6.1 Methodik der Auswahl
Die Auswahl des Datenbankmanagementsystems erfolgt in zwei Stufen. In der ersten
Stufe werden die Datenbankmanagementsysteme ausgefiltert, die die projektkritischen
Kriterien aus Kapitel 4.3 nicht erfüllen. Diese DBMS werden dann nicht mehr weiter
untersucht. Alle übrigen DBMS werden in der zweiten Stufe näher betrachtet. Dabei
werden vor allem die wichtigen Kriterien untersucht. Sollten mehrere Datenbanken alle
wichtigen Kriterien erfüllen, werden schließlich die projektunkritischen Kriterien
verglichen. Die pro DBMS verfügbaren Informationen können in Umfang und
inhaltlicher Abdeckung sehr unterschiedlich ausfallen, daher wird als pragmatischer
Ansatz so vorgegangen, dass fehlende Information als fehlendes Kriterium interpretiert
wird.
6.2 Anwendung des mehrstufigen Auswahlverfahrens
Erste Stufe
Die Datenbanken IBM DB 2 Express-C, Informix, MS SQL Server 2005 Express,
Oracle Database 10g Express Edition und Sybase SQL Anywhere Developer Edition
wurden in der ersten Stufe ausgefiltert, weil der Quellcode dieser Datenbanken nicht
Open Source ist und somit dieses projektkritische Kriterium nicht erfüllt. SQLite und
MaxDB sind nur teilweise mit dem SQL-92 Standard konform (bei SQLite fehlt der
komplette ALTER TABLE und MaxDB der BEFORE TRIGGER Support) und werden
deswegen nicht mehr in der zweiten Stufe betrachtet.
Zweite Stufe
Die
Datenbanken
Firebird,
Ingres,
MySQL
und
PostgreSQL
erfüllen
alle
projektkritischen Kriterien. In dieser 2. Stufe werden daher diese vier verbliebenen
Datenbanken genauer verglichen (Tabelle 4). Eine Reihe von Detailanforderungen sind
34
in dieser Tabelle nicht enthalten, da sie von allen vier DBMS erfüllt werden und somit
nicht als Unterscheidungskriterium dienen können. Dies betrifft die Fähigkeiten für
ACID-Transaktionen, für Stored Procedures, für ODBC und die unterstützten
Betriebssysteme (jeweils Windows und Linux). Downloadzahlen sind für Ingres leider
nicht zugänglich, bei den drei anderen DBMS liegen diese in Bereichen weit oberhalb
von 50.000, sprechen also für eine große und agile Community. Des Weiteren
unterstützen alle DBMS die geforderten Skript- und Programmiersprachen (namentlich
PHP, Python, Perl, Java und C++). Diese Anforderungen werden deshalb in der
folgenden Tabelle nicht extra ausgewiesen.
Tabelle 4: Detailvergleich der DBMS Firebird, Ingres, MySQL und PostgreSQL
Firebird
Ingres 2006
MySQL
PostgreSQL
1.5.4
Release 2
5.0
8.2
Lizenz
IDPL
GPL
GPL
BSD
SQL-Standard
92, 99
92, 99
92, 99
92, 99, 2003
SSL
Ja
Ja (IPsec)
Ja
Ja
CHECKBedingungen
Ja
Ja
Nein
Ja
Trigger
Before/After
Before/After
Before/After
Before/After
Spaltenanzahl
unbegrenzt
1024
3398
1600
Maximale DBGröße
980 GB
Abhängig
vom
Dateisystem
unbegrenzt
unbegrenzt
Tabellengröße
30 GB
unbekannt
Administrationstools
ibWebAdmin,
SQuirreL SQL
unbekannt
Kriterium
35
64 TB
(InnoDB)
phpMyAdmin,
MySQL
Administrator
32 TB
pgAdmin III,
phpPgAdmin
6.3 DBMS: Auswahlentscheidung
Basierend auf den in der Tabelle 4 zusammengestellten Eigenschaften, ergibt sich die
beste Übereinstimmung mit dem Anforderungsprofil, d.h. die beste Abdeckung der
Auswahlkriterien, für das DBMS PostgreSQL. Insbesondere trifft dies auf die gute
Konformität zum SQL-Standard SQL:99, die Unterstützung von CHECK-Bedingungen
und der guten Administrationstools zu. Des Weiteren ist die Community und somit auch
die Verbreitung von PostgreSQL ständig am Wachsen. Zu den Referenzen von
PostgreSQL zählt unter anderem die Carl Zeiss 3D Metrology Services GmbH und
Cisco Systems, Inc. Daher wurde PostgreSQL als Grundlage für die THEREDADatenbank ausgewählt. Diese Entscheidung wurde von den anderen Partnern im
Verbundprojekt unterstützt und daher konnte auf dieser Basis mit der Realisierung eines
entsprechenden Prototypen begonnen werden.
Nachdem die Entscheidung für PostgreSQL gefallen war, wurde zudem durch die
Verbundpartner PHP als Skriptsprache ausgewählt.
36
7 Konzeption von Datenmodell und Nutzerinteraktionen
7.1 Vorstellung Datenmodell
Das Datenmodell wurde in der ersten Projektphase von THEREDA in Zusammenarbeit
des FZ Dresden-Rossendorf und der GRS Braunschweig entwickelt, es ist momentan
als Entity-Relationship-Modell in der Software Toad Data Modeller (TDM - Version 2,
Quest Software, Inc., Aliso Viejo, Cal., USA) implementiert, welche den Export in
derzeit 17 verschiedene DBMS (teilweise mit weiteren Unterversionen) gestattet. Toad
Data Modeller ermöglicht im Fall von PostgreSQL zudem die automatische Erstellung
von Funktionen zur Sicherung, der vom Nutzer zuvor definierten referentiellen
Integrität.
Die Einhaltung des Standard SQL:99 ist auch in der neuesten Version 8.2.3 (Stand vom
16. Mai 2007, dem Datum der Systemimplementierung beim Projektpartner GRS
Braunschweig, Außenstelle Berlin) von PostgreSQL noch nicht 100 % gewährleistet.
Um jedoch zukünftige Konflikte mit Vorgaben der verschiedenen SQL-Standards
möglichst klein zu halten, werden bei der konkreten Umsetzung der THEREDADatenbank in PostgreSQL unbedingt jegliche speziellen, nicht standard-konformen
Erweiterungen vermieden.
Wie im Kapitel 3.5 bereits dargelegt, lassen sich die Inhalte und damit die Gesamtfunktionalität der Datenbank grob in verschiedene Kategorien gliedern, nachfolgend
nach Relevanz und Umfang geordnet:
-
grundlegende physiko-chemische Daten
-
numerische Werte der chemischen Stoffdaten und zugehörigen Reaktionsgleichungen
-
numerische Werte der Parameter für die Wechselwirkungen zwischen Ionen
oder Festphasen
-
bibliographische Informationen
-
„Hilfsdaten“ und Metadaten
37
Die nachfolgende Detailbeschreibung des Datenmodells folgt weitestgehend diesem
Prinzip. Zuvor werden noch die wichtigsten in THEREDA auftretenden Feldtypen
aufgelistet (Tabelle 5) und Konventionen zur Datenmodell-Beschreibung (inklusive
Farbkodierung für die Abbildungen) benannt.
Tabelle 5: Feldtypen in THEREDA. Mit * markierte Felder werden durch das DBMS automatisch
erzeugt.
Feldtyp
Varchar(n)
Timestamp*
Beschreibung
Eine Folge von maximal n Zeichen
(alphanumerisch und Zwischenraum)
Sowohl für Datum und Zeit genutzt,
im Format: yyyy.mm.dd hh:mm:ss, z.B. 1999-01-08 04:05:06.
Numeric
Fließkommazahl
Smallint
Kleine Integerzahl: -32768 bis +32767
Boolean
Logische Variable: “wahr” oder “falsch”
Serial*
Automatischer Integerzähler: 1 bis 2147483647
Text
Zeichenkette mit variabler, unbegrenzter Länge
In vielen Tabellen sind Felder für allgemeine Attribute vorhanden, welche entweder
Beziehungen zu anderen Tabellen knüpfen oder spezifische Meta-Informationen
speichern. Die für die jeweiligen Attribute für Beziehungen zuliefernden Tabellen
(Auswahllisten) sind in den nachfolgenden Datenmodellen nicht noch einmal separat
erklärt.
1. Beziehungen:
-
UncType: Art der Fehlerverteilung bei numerischen Werten
-
Reference: Bibliographische Referenz
-
Editor: Name des letzten Bearbeiters eines Datensatzes
-
DataClass: Klasse des chemischen Experimentes, welches den Datenwert
lieferte
-
DataQuality: Qualitätsstufe eines experimentellen Wertes
-
DataSource: Typ der bibliographischen Referenz für experimentelle Werte
38
-
TPFunc: Term für die Beschreibung von Temperatur- und
Druckabhängigkeit eines Datensatzes
2. Spezifische Attribute:
-
Description, Remark: Allgemeine, zusätzliche Beschreibungen und
Kommentare zu Datensätzen
-
DBDateTime: Datumsstempel der letzten Änderung an einem Datensatz
Die Farbkodierung in den nachfolgenden Abbildungen bedeutet:
-
Grau: optionales Attribut
-
Schwarz: notwendiges Attribut, darf nicht NULL sein
-
Blau: Fremdschlüssel
-
Rot: Primärschlüssel
-
Grün: Gleichzeitig Fremd- und Primärschlüssel
Unterhalb der einzelnen Datenmodell-Grafiken sind alle jeweils relevanten Tabellen
aufgeführt, sofern diese nicht bereits zuvor genannt wurden. Für eine Reihe von
Tabellen ist umfangreiches chemisches Sachwissen notwendig, welches hier leider nicht
explizit dargestellt werden kann. Weitere Grundlagen des dargestellten Datenmodells
beruhen vorrangig auf chemischen Sachverhalten und wurden außerhalb dieser
Diplomarbeit durch Kooperationspartner entwickeltt. Daher erfolgt die Darstellung des
Datenmodells für THEREDA hier in verkürzter Form. Insbesondere werden die
speziellen Datenmodelle für die Bildung von in sich konsistenten Datensets und
jeweilige Gültigkeitsgrenzen hier nicht dargestellt. Bei Interesse können ausgiebige
Erläuterungen
in
THEREDA-Handbuch
nachgeschlagen
Downloadbereich von http://www.thereda.de zu finden ist.
39
werden,
welches
im
7.1.1 Detailliertes Datenmodell für die grundlegenden Daten
Abbildung 6: Datenmodell der Basisdaten
Die folgenden Tabellen sind hierbei relevant:
-
Physical Constants – allgemeine physikalische Naturkonstanten
-
Element – Periodensystem der chemischen Elemente
-
Phase – in sich abgeschlossene chemische Phase
-
AggregationState – Aggregatzustand
-
Modification – Modifikationsform fester Phasen
-
PCon – Komponenten einer Phase
-
PConComposition – Zusammensetzung einer Phase
-
PConType – Art einer Phasenkomponente
-
SITPitzerConsistencyList – Konsistenzkriterium bei hochsalinaren Lösungen
40
7.1.2 Detailliertes Datenmodell für chemische Stoffdaten und zugehörige
Reaktionsgleichungen
Abbildung 7: Datenmodell der chemischen Stoffdaten
Abbildung 8: Datenmodell zur Beschreibung chemischer Reaktionsgleichungen
41
Die folgenden Tabellen sind hierbei relevant:
-
DataStandard – Stoffdaten bei Standardbedingungen (25 °C, 1 bar)
-
DataVariable – Stoffdaten bei Nicht-Standardbedingungen
-
DataType – Art der Stoffdaten
-
CalcMode – Art der Berechnung bei intern abgeleiteten Daten
-
DataType_x_CalcMode – Liste der erlaubten Kombinationen von DataType
und CalcMode
-
State – gibt an, ob Datenwert für Standardbedingungen gültig ist oder nicht
-
Reactions – Liste der Reaktionspartner einer chemischen Reaktion
-
Category – gibt an, ob eine Bildungsreaktion vorliegt oder nicht
42
7.1.3 Detailliertes Datenmodell der Parameter für die Wechselwirkungen
zwischen Ionen oder Festphasen
Abbildung 9: Datenmodell zur Beschreibung von Wechselwirkungen
43
Die folgenden Tabellen sind hierbei relevant:
-
Interactions_Standard – Wechselwirkungsparameter bei
Standardbedingungen (25 °C, 1 bar)
-
Interactions_Variable – Wechselwirkungsparameter bei NichtStandardbedingungen
-
Interactions – definiert Art und Beteiligte einer Wechselwirkung
-
InteractionType – Art des Wechselwirkungsparameters
-
InteractionModel – Liste erlaubter Wechselwirkungsmodelle
-
InteractionModel_x_Phase – Liste erlaubter Kombinationen von
Wechselwirkungsmodellen und Phasen
7.1.4 Detailliertes Datenmodell für bibliographische Informationen
Abbildung 10: Datenmodell für bibliographische Informationen
44
Die folgenden Tabellen sind hierbei relevant:
-
Reference – detaillierte bibliographische Beschreibung einer Referenz
(zitierfähige Publikation)
-
ReferenceAuthors – Liste der Autoren einer Publikation
-
ReferenceKeywordsList – Liste aller erlaubten, vordefinierten Schlagworte
-
ReferenceKeywordsUsed – Liste weiterer Schlagworte, die durch Nutzer
erweitert werden kann
-
ReferenceStatus
–
Form
der
physischen
Speicherung
einer
Literaturstelle/Kopie
-
ReferenceType – Art der Publikation (Buch, Report, Zeitschrift etc.)
-
ReferenceLanguage – Sprache, in der die Publikation vorliegt
7.2 PostgreSQL-Client: Einbindung in das WCMS Joomla
7.2.1 WCMS und seine Vorteile
Ein Web-Content-Management-System ist ein Anwendungsprogramm, welches die
Bearbeitung, Verwaltung und die Publikation von Webinhalten und Informationen
ermöglicht. Die wichtigsten Eigenschaften eines WCMS sind:
-
Inhalt (Content) und Design der Seiten werden getrennt verwaltet.
-
Alle Informationen werden in einer Datenbank gespeichert.
-
Die Verwaltung erfolgt meist über Web-Interfaces, wo kein Client-Software
benötigt wird.
-
Nutzer- und Rechtemanagement
-
Zahlreiche Erweiterungsmöglichkeiten (Foren, Umfragen, Shops)
Aus den Eigenschaften lassen sich die wesentlichen Vorteile eines WCMS ableiten.
Inhalt und Design werden getrennt verwaltet, somit sind die Beiträge aller Autoren in
einem einheitlichen Design. Durch die Speicherung der Inhalte in einer Datenbank
können die Inhalte an verschiedenen Stellen wiederverwendet werden und für
verschiedene Medien (Webbrowser, Mobiltelefon, Druck) adäquat formatiert werden.
45
Die Verwaltung des CMS erfolgt über ein Web-Interface (Abbildung 11), so dass man
überall und zu jeder Zeit daran arbeiten kann. Autoren, die durch das Nutzer- und
Rechtemanagement angelegt werden, benötigen keine HTML-Kenntnisse. Sie können
ihre Beiträge in einen über das Web-Interface bereitgestellten Texteditor eingeben und
auf der Homepage veröffentlichen. Diese Veröffentlichungen können zeitgenau
gesteuert werden. Das heißt, dass der Inhalt schon vorher eingeben werden kann und
dann zum eingestellten Datum/Uhrzeit veröffentlicht wird.
Abbildung 11: Web-Interface Backend
Abbildung 12: Web-Interface Frontend
46
7.2.2 Kurzbeschreibung Joomla
Joomla ist ein Open Source WCMS, welches auf http://www.joomla.org unter der
General Public License zum Download angeboten wird. Joomla zeichnet sich durch
seine große Community und den daraus folgenden meist kostenlosen Erweiterungen
(Komponenten, Templates) aus. Um Joomla installieren zu können, sollte auf dem
Webserver mindestens Apache 1.13.19, PHP 4.2 sowie MySQL 3.23 laufen. Die
Programmdateien werden einfach über ein FTP-Programm auf den Webserver kopiert
und anschließend die mitgelieferte Installationsroutine im Webbrowser aufgerufen. Das
THEREDA Verbundprojekt hat sich auf Grund der Eigenschaften/Vorteile und der
geringen Systemvoraussetzungen entschieden, Joomla für ihren Webauftritt zu
verwenden.
7.2.3 Client-Konzept (1. Ausbaustufe)
Das Einfügen und Abfragen der Daten von der THEREDA Datenbank soll auf
unterschiedliche Art und Weise erfolgen (siehe Abbildung 13). Wie schon in Kapitel
3.2 erwähnt, werden die Daten über ASCII-/Exceldateien von vorhandenen
Datenbanken oder neu über ein Web-Interface eingeben. Die Abfragen werden
hauptsächlich über ein Web-Interface gestaltet. Des Weiteren sollen in regelmäßigen
Abständen ausgewählte Daten in einer neu generierten Datenbank zum Download
angeboten werden. So sollten auch Abfragen auf die Daten möglich sein, wenn keine
Internetverbindung zur Verfügung steht.
47
ASCII-Input
(MS Access,
Delphi)
Excel-Input
Interaktive
Abfrage (WWW)
THEREDA-DB
(PostgreSQL)
NEA
Nagra-PSI
Generische DB
Interaktive
Eingabe (WWW)
LMA-DBs
(EQ3/6;PhreeqC)
GME-DBs
(ChemApp etc.)
Abbildung 13: Client-Konzept
Die Datenabfrage und Dateneingabe, die über das Web-Interface (Skriptsprache PHP)
erfolgt, soll in das WCMS Joomla integriert werden. Joomla speichert jeglichen Content
als HTML ab (der eingegebene Code wird als ganz normaler Text angezeigt), so dass
der eingebene PHP-Code nicht vom Webserver verarbeitet wird. Von daher muss der
PHP-Code in eine extra PHP-Datei auf dem Server abgelegt werden und dann mit der
Komponente Wrapper in Joomla integriert werden. Die PHP-Datei kann allerdings nicht
über das Web-Interface von Joomla bearbeitet werden. Zur Bearbeitung der PHP-Datei
werden ein SCP-Client (WinSCP) und ein Editor (Notepad++) benötigt.
Nicht jeder Nutzer soll Eintragungen in die Datenbank vornehmen können. Um dies zu
gewährleisten, kann die Nutzer- und Rechteverwaltung von Joomla benutzt werden.
Joomla erlaubt es Inhalte (Datenbankeingaben) vor nicht registrierten Nutzern zu
verbergen. Weitere Autorisierungen können über .htaccess-Dateien und manuelle
Anmeldung an die PostgreSQL-Datenbank realisiert werden.
48
8 Prototypische Realisierung der Datenbank
8.1 Umsetzung des Datenmodells in PostgreSQL
Ein erster Schritt für die Umsetzung des Datenmodells für THEREDA in PostgreSQL
war das Aufsetzen einer kompletten DBMS-Umgebung auf dem Host bei der GRS, dies
geschah unter einem Linux Betriebssystem und in enger Kooperation mit den dortigen
Kollegen. Letztlich wurde folgende Konstellation gewählt: Apache Webserver in der
Version 2.0, PHP als Skriptsprache in der Version 4.4.4-8, PostgreSQL in der Version
8.1.3., sowie phpPgAdmin in Version 4.1.1. Der Fernzugriff für Wartung und Datenpflege ist über PuTTY Version 0.60 und WinSCP Version 3.8.2 realisiert. Zukünftig
wird der Zugriff auf die Datenbank THEREDA über ein WWW-Interface erfolgen,
welches PHP-basiert ist und in eine Internetpräsenz unter www.thereda.de eingebettet
werden soll.
Nach Bereitstellung einer arbeitsfähigen Software-Umgebung waren in einem
mehrstufigen Prozess Verfeinerungen des Konzeptes auf abstrakter Ebene (TDM)
notwendig. Parallel dazu mussten eine ganze Reihe von DB-Variablen umbenannt
werden, welche im ersten Entwurf z.B. noch geschützte Begriffe etc. darstellten. Ebenso
musste noch die Vergabe von Defaultwerten und von Datums-/Zeitwerten angepasst
werden. Ein wesentlicher Aspekt war schließlich die Bereitstellung von Funktionen und
Triggern in der PostgreSQL-Programmiersprache PL/pgSQL. PL/pgSQL ist eine
ladbare prozedurale Sprache für das PostgreSQL-Datenbanksystem. Die Entwickler von
PL/pgSQL hatten das Ziel, eine Programmiersprache für PostgreSQL zu erstellen, die:
-
verwendet werden kann, um Funktionen und Triggerprozeduren zu
schreiben,
-
Kontrollstrukturen zur Sprache SQL hinzufügt,
-
komplexe Berechnungen ausführen kann,
-
alle benutzerdefinierten Typen, Funktionen und Operatoren zur Verfügung
hat.
49
Nach der Installation der Datenbank auf dem THEREDA-Server wurden die ersten
Daten eingetragen, wobei bei einigen Spalten vom Datentyp „character varying“ die
maximale Anzahl der vorher eingestellten Zeichen nicht ausreichte, so dass diese
angepasst werden mussten. Das folgende Kapitel zeigt eine ausgewählte Testabfrage auf
die vorher eingegebenen Daten.
8.2 Exemplarische Abfrage
In diesem Kapitel wird eine exemplarische Abfrage auf die Datenbank mit dem
Datenbestand vom 01.08.2007 durchgeführt.
Die Abfrage wird auf die Tabelle Element ausgeführt und soll alle Datensätze mit den
Attributwerten Name, Symbol und MolarMass anzeigen. Die Ausgabe soll alphabetisch
sortiert nach dem Namen erfolgen. Das Abfrageergebnis ist in Abbildung 14 zu sehen.
Der SQL-Befehl dazu lautet:
SELECT "Name", "Symbol", "MolarMass" FROM "Element" ORDER BY "Name";
Abbildung 14: Abfrageergebnis auf der THEREDA-Seite
50
9 Zusammenfassung und Ausblick
Im Rahmen dieser Diplomarbeit sollte ein DBMS für eine qualitätsgesicherte und
verlässliche Langzeitsicherheitsanalyse nuklearer Endlager in Deutschland geschaffen
werden. Zum Aufbau einer solchen Datenbank haben sich Mitte 2006 fünf Institutionen
zum
Verbundprojekt
THEREDA
(THErmodynamische
REferenzDAtenbasis)
zusammengeschlossen.
Durch die große Auswahl an DBMS mussten die Anforderungen klar definiert und in
drei Auswahlkriterien (Projektkritisch, Wichtig und Projektunkritisch) gruppiert
werden. Zu den projektkritischen Kriterien gehören:
-
SQL:92-Standard
-
Open Source (Lizenz, Community)
-
Sichere Kommunikation
-
Logische Datenintegrität (ACID, Trigger, CHECK)
-
Skript- und Programmiersprachen
Aufgrund dieser Kriterien haben nur 4 von 11 untersuchten DBMS die 2. Stufe des
Auswahlverfahrens erreicht. Diese 4 DBMS wurden dann genauer untersucht und in
Tabelle 4 gegenüber gestellt. Demnach wären 4 DBMS (Firebird, Ingres, MySQL und
PostgreSQL) für das Projekt geeignet. Bei der Untersuchung der einzelnen DBMS
wurde deutlich, dass die Open Source DBMS kaum bis gar keine Nachteile gegenüber
kommerziellen Datenbanken aufweisen. Die Anbieter kommerzieller DBMS sollten
daher noch mehr Wert auf Service und Support legen, um sich in Zukunft von den Open
Source DBMS abheben zu können.
Ausgewählt wurde letztendlich PostgreSQL, da diese eine gute Konformität zum SQLStandard
SQL:99,
die
Unterstützung
von
CHECK-Bedingungen
und
gute
Administrationstools mitbringt. Auch die ständig wachsende und gute Community war
ein ausschlaggebender Punkt für die Auswahl von PostgresSQL.
Aus dem im TDM erstellten Entity Relationship Modell hat das Programm automatisch
ein SQL-Skript für PostgreSQL generiert. Dieses wurde auf die zuvor eingerichtete
PostgreSQL-Datenbank auf dem THEREDA-Server importiert. Danach wurde über
Microsoft Office Access und phpPGAdmin mit dem Import der ersten Daten begonnen.
Anfang Juli 2007 wurde das WCMS Joomla erfolgreich eingerichtet und danach die
51
Projekthomepage http://www.thereda.de der Öffentlichkeit vorgestellt. Enthalten sind
Informationen/Downloads über das THEREDA-Projekt und erste Abfragen auf die
PostgreSQL-Datenbank. Leider sind zum jetzigen Zeitpunkt noch sehr wenige Daten in
der Datenbank verfügbar, so dass keine umfangreicheren Abfragen erstellt werden
konnten. Das erste Feedback der Verbundpartner war durchweg positiv. In den nächsten
Monaten wird die Datenbank mit Daten gefüllt und weitere Abfragen erstellt. Später
werden die Berechnungen aus der Datenbank, die Grundlage für die Auswahl des
Wirtsgesteins (Salz, Ton, Granit) für ein nukleares Endlager in Deutschland sein.
52
Literaturverzeichnis
[I_xxxxxx]
Internet
[L_xxxxxx]
Literatur
[S_xxxxxx]
Sonstige Quelle
[I_BUCK01]
BUCKA-KLASSEN, K. & J. SORENSEN: Open Source in einer
Schweizer Großbank
http://www.svifsi.ch/revue/pages/issues/n016/in016Bucka.pdf
[I_BUND01]
Bundesanstalt für Geowissenschaften und Rohstoffe
Geotechnik, Endlagerung
http://www.bgr.bund.de/cln_029/nn_825342/DE/Themen/
Geotechnik/geotechnik__node.html__nnn=true
[I_EDIT01]
Editionenvergleich des DBMS Microsoft SQL Server
http://www.microsoft.com/germany/sql/editionen/default.mspx
[I_EISEN01]
EISENTRAUT, P.: PostgreSQL Das Offizielle Handbuch
http://dokus.dyndns.info/postgres/
[I_FIRE01]
Firebird Dokumentation
http://www.firebirdsql.org/manual/
[I_HORS01]
HORSTMANN, J.: Freie Datenbanken im Unternehmenseinsatz
Analyse
und
Vergleich
der
wichtigsten
Datenbanken
http://www.heise.de/open/artikel/70100/0
53
Open-Source-
[I_IBMD01]
IBM DB2 Express-C Dokumentation
http://publib.boulder.ibm.com/infocenter/db2luw/v9/index.jsp
[I_INFO01]
Informix 10.0 Datenblatt
ftp://ftp.software.ibm.com/software/data/informix/pubs/
datasheets/IDS-V10-0-datasheet.pdf
[I_INGR01]
Ingres 2006 Release 2 Dokumentation
http://downloads.ingres.com/download/ingres2006r2pdfs.tgz
[I_LIST01]
Liste der Open Source Initiative zertifizierte Lizenzen
http://www.opensource.org/licenses/alphabetical
[I_MAXD01]
MaxDB Dokumentation
http://dev.mysql.com/doc/maxdb/
[I_MYSL01]
MySQL 5.0 Dokumentation
http://dev.mysql.com/doc/refman/5.0/en/
[I_ORAC01]
Oracle Database 10g Express Edition Datenblatt
http://www.oracle.com/technology/products/database/xe/
pdf/dbxe_datasheet.pdf
[I_ORAC02]
Oracle Database 10g Express Edition FAQ
http://www.oracle.com/technology/products/database/
xe/pdf/dbxe_faq.pdf
[I_SOLI01]
SolidDB 6 FAQ
http://www.solidtech.com/en/products/
relationaldatabasemanagementsoftware/faq.asp
54
[I_SQLI01]
SQLite 3.4.0 Dokumentation
http://www.sqlite.org/docs.html
[I_SYBA01]
SYBASE SQL Anywhere Datenblatt
http://www.ianywhere.com/deutschland/
datasheets/sql_anywhere_10.pdf
[I_WLOK01]
WLOKA,U.: Entwicklung des SQL-Standard vom
Hoffnungsträger zum Ideengrab
http://www.informatik.htw-dresden.de/
~wloka/vortraegestammtisch/Wloka07.pdf
[I_WLOK02]
WLOKA, U.: Datensicherheit/Datenintegrität in Datenbanken
- in 5 Modulen einer interaktiven, netzgestützten Lernumgebung http://wwwmi.informatik.htw-dresden.de/wbt-ds2/
[L_AUSW01]
Auswahlverfahren für Endlagerstandorte, 1. Auflage, 2002
[L_MATT01]
MATTHEW, C & R. STONES: Beginning Databases with
PostgreSQL, 2. Auflage, Springer-Verlag, New York, 2005
[L_PITZ01]
PITZER, S., K.: Thermodynamics (Mcgraw Hill Series in
Advanced Chemistry), 3. Auflage, McGraw-Hill Education, New
York, 1995
[L_SPON01]
SPONA, H.: Web-Datenbanken, 1. Auflage, verlag moderne
industrie Buch AG & Co. KG, Bonn, 2002
[L_STAH01]
STAHLKNECHT, P. & U. HASENKAMP: Einführung in die
Wirtschaftsinformatik, 11. Auflage, Springer-Verlag, Berlin, 2004
55
[L_WIDG01]
WIGARD, S.: Das Einsteigerseminar PHP 4, 3. Auflage, verlag
moderne industrie Buch AG & Co. KG, Bonn, 2003
[L_WILL01]
WILLIAMS E. H. & D. LANE: Web Datenbank Applikation mit
PHP & MySQL, 1. Auflage, O`Reilly Verlag, Köln, 2003
[S_FLEC01 ]
FLECKNA, J.: Diplomarbeit „Konzeptioneller Entwurf und
prototypische Realisierung einer datenbankbasierten Software zur
Verwaltung von Daten eines Transientenrekorders“, Dresden,
2006
Anmerkung: Die WWW-Links wurden letztmalig am 01.08.2007 vor Drucklegung der
Diplomarbeit auf Gültigkeit überprüft.
Weiteres unterstützendes Material zu dieser Diplomarbeit befindet sich auf der
beiliegenden CD.
56
Anhang A: Anforderungsanalyse erstellt mit MindMapper 5
Dieser Anhang präsentiert, die mit MindMapper 5 erstellte Anforderungsanalyse.
57
58
Danksagung
Ich möchte mich an dieser Stelle bei all denen bedanken, die mich bei der Bearbeitung
meines Diplomthemas unterstützt haben. Für die Betreuung meiner Diplomarbeit danke
ich Herrn Prof. Gunter Gräfe von der Hochschule für Technik und Wirtschaft Dresden
und Herrn Dr. Vinzenz Brendler vom Forschungszentrum Dresden Rossendorf e.V. Des
Weiteren gilt mein Dank den Verbundpartnern von THEREDA, besonders Herrn Dr.
Helge Moog und Dr. Sven Hagemann von der Gesellschaft für Anlagen- und
Reaktorsicherheit (GRS) mbH sowie Frau Dr. Anke Richter vom Forschungszentrum
Dresden Rossendorf e.V.
59
Eidesstattliche Erklärung
Hierdurch erkläre ich, dass ich die von mir am heutigen Tag eingereichte Diplomarbeit
selbstständig verfasst und ausschließlich die angegebenen Hilfsmittel benutzt habe.
Marco Münzberg
Dresden, 06.08.2007
60