Konzeptioneller Entwurf und prototypische Realisierung
Werbung
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
