Datenbanken - Praxis

F√ľr den praktischen Umgang mit Datenbanken werden Hinweise gegeben, die einerseits Aspekte, die schon bei dem Entwurf der Datenbank ber√ľcksichtigt werden sollten, andererseits aber auch Empfehlungen f√ľr die t√§gliche Arbeit mit einer Datenbank thematisieren, wie etwa Dateneingabe, Exportm√∂glichkeiten, Speicherung und Sicherung sowie mehrsprachige Dateneingabe.

Es werden verschiedene DBMS und Administratorentools vorgestellt, mit denen sowohl Desktop- als auch serverbasierte Datenbanken erstellt und betrieben werden k√∂nnen. F√ľr die Archivierung von Datenbanken werden Programme zur automatischen Analyse und Dokumentation der Datenbankstruktur vorgestellt. Auch f√ľr die Speicherung in SIARD und den Umgang mit diesem Format gibt es ein eigenes Toolkit. F√ľr FileMaker- und MSAccess-Datenbanken gibt es gesonderte Hinweise.

Datenbankentwurf

Der Datenbankentwurf bzw. das Datenbankschema hat einen gro√üen Einfluss auf die Qualit√§t einer Datenbank. Die richtige Strukturierung von Informationen vor der eigentlichen Eingabe von Daten stellt die Voraussetzung f√ľr eine langfristige, flexible und sinnvolle Verwendung einer Datenbank dar - vor allem dann, wenn sich im Laufe der Zeit die Anforderungen und W√ľnsche √§ndern

Der Entwurf von Datenbanken erfolgt idealerweise in folgenden Schritten:

  • Anforderungsanalyse: Allgemeine Beschreibung des zuk√ľnftigen Systems in R√ľcksprache mit den Endanwendern, Sammlung der wissenschaftlichen und technischen Anforderungen, Definition der Eigenschaften der zu verarbeitenden Informationen, Festlegung der Arbeitsweise und Rechte der Benutzer, Einbindung von "Altbest√§nden" (alte Dokumentation, etc.) und Analyse der H√§ufigkeit verschiedener Abfragen und Eingaben.
  • Konzeptueller Entwurf: Erstellung eines softwareunabh√§ngigen Datenbankschemas, welches sich als globale Sicht auf die Daten aus den Einzelsichten der jeweiligen Nutzergruppen zusammensetzt. Hierf√ľr empfiehlt sich eine grafische Darstellung, z. B. als Entity-Relationship-Diagramm (ERD).
  • Logischer Entwurf: Umsetzung des konzeptuellen Entwurfs auf ein gew√§hltes DBMS, z. B. durch √úbertragung des ERD in einen Datenkatalog.
  • Datendefinition: Konkrete Realisierung des logischen Entwurfs in einem DBMS, z.B. indem die im Datenkatalog festgelegten Spezifikationen in einer Datenbank-Software angelegt und gespeichert werden.
  • Benutzerrechte: Festlegung, welcher Benutzer welche Daten in welcher Form sehen, bearbeiten, l√∂schen, exportieren, drucken etc. darf.
  • Dokumentation: Strukturiertes Festhalten des Datenbankentwurfes, der Attributdefinitionen, zul√§ssiger Werte, Indizes, Layouts etc. und der dahinter stehenden √úberlegungen.

Bei der Entscheidung, welche Eigenschaften eines realen Objektes durch welche Attribute einer Entit√§t beschrieben werden, sollten folgende Punkte beachtet werden: Grunds√§tzlich sind die Eigenschaften (Attribute) eines Entit√§tstypes m√∂glichst klein bzw. atomar zu halten (z. B. statt einem Attribut "Ma√üangaben" sind verschiedene Attribute wie "H√∂he", "Breite", "Tiefe" etc. sinnvoller). Dies erleichtert pr√§zise Abfragen und Berechnungen sowie den sp√§teren Austausch der Daten mit anderen Systemen. Eine automatische Zusammenf√ľhrung von Daten aus mehreren atomaren Attributen in ein einziges, umfangreicheres Attribut ist immer m√∂glich -- der umgekehrte Weg, also eine automatische Aufteilung eines gr√∂√üeren Attributes auf viele kleinere, dagegen meist nicht. Dabei sollte bedacht werden, dass die Bearbeitungszeit eines Datensatzes mit der Anzahl der auszuf√ľllenden Attribute w√§chst. Je nach Fragestellung und Anforderung muss ein ausgewogenes Verh√§ltnis von Datenvielfalt (Vollst√§ndigkeit) und Effizienz gefunden werden.

Es wird dringend empfohlen, dass ein Datenbankentwurf vor dessen praktischer Umsetzung von einem Fachmann zur Informationsmodellierung nach inhaltlichen und formalen Kriterien (z. B. hinsichtlich Inkonsistenzen, Integrit√§tsbedingungen, Redundanzen, M√∂glichkeiten der Verbesserung etc.) √ľberpr√ľft wird. In diesem Austausch sollte dann auch diskutiert werden, inwieweit ein vorhandenes Schema in die sog. erste bis f√ľnfte Normalformen √ľberf√ľhrt werden kann oder nicht. Bei diesem Prozess der Normalisierung handelt es sich um ein in der Informatik entwickeltes Konzept zur Vermeidung von Anomalien der Datenbankinhalte und zur Beurteilung der Qualit√§t eines relationalen Datenbankschemas, das allerdings ein vertieftes Verst√§ndnis zur Funktionsweise von DBMS voraussetzt.

DBMS f√ľr Desktop-Datenbanken

Allen Desktop-Datenbankmanagementsystemen ist gemeinsam, dass eine gleichzeitige Nutzung durch mehrere Benutzer nur unzureichend m√∂glich ist, weswegen diese nur f√ľr kleinere bis mittlere Datenbanken im lokalen Betrieb empfohlen werden k√∂nnen. In der Regel besteht auch die M√∂glichkeit ein Desktop-DBMS in einer Hybridl√∂sung als Frontend zur Dateneingabe zu verwenden, w√§hrend die Datenhaltung in einem serverbasierten DBMS erfolgt.

Sofern die Anforderung besteht, eine Datenbank f√ľr mehrere Benutzer betreiben zu wollen, sollte auf jeden Fall die Verwendung eines DBMS f√ľr eine Server-Datenbank in Betracht gezogen werden. Kann eine Server-Client-Architektur f√ľr mehrere Benutzer nicht realisiert werden und wird stattdessen parallel mit mehreren Desktop-Datenbanken gearbeitet, m√ľssen gesonderte Vorkehrungen bei der Entwicklung der Datenbank getroffen werden und deren strikte Einhaltung gew√§hrleistet werden, damit die Datenbankinhalte trotzdem konsistent bleiben (z. B. Vergabe individueller Nummernbl√∂cke f√ľr einzelne Bearbeiter; Einschr√§nkungen durch ein detailliertes Rechte-Management; regelm√§√üige Datenzusammenf√ľhrungen, um fr√ľhzeitig Inkonsistenzen und Widerspr√ľche im Datenbestand festzustellen).

FileMaker Pro ist ein kommerzielles DBMS f√ľr die Betriebssysteme Mac OS und Windows, das sich neben Microsoft Access zum Standardprogramm f√ľr Datenbanken auf Einzelplatzrechnern entwickelt hat. Charakteristisch ist seine einfache Benutzbarkeit, die es erm√∂glicht schnell L√∂sungen zu realisieren. Der Export der Datens√§tze in Standardformate (z. B. CSV, XML, XLS) ist gew√§hrleistet, der Export der Datenbankstruktur ist mit FileMaker Advanced in den Formaten HTML oder XML m√∂glich. Es gibt jedoch auch einige Schw√§chen wie die mangelnde Unterst√ľtzung von SQL und von Geodaten, erh√∂hte Anschaffungskosten und das Fehlen einer echten Programmiersprache.

Microsoft Access ist Bestandteil des Office-Professional-Pakets von Microsoft, das nur f√ľr das Windows-Betriebssystem angeboten wird. Alle Datenbankelemente, inkl. aller Elemente der Oberfl√§chen als auch die Datenbanktabellen selbst, werden in einer einzigen Datei des propriet√§ren MDB- bzw. ACCDB-Dateiformates abgespeichert. MS Access bietet im Vergleich zu FileMaker Pro weniger unterst√ľtzte Macros an, so dass umfangreiche Funktionen mit der Programmiersprache Visual Basic selbst entwickelt werden m√ľssen. Dadurch k√∂nnen auch komplexe Aufgaben erstellt und individuelle Anpassungen vorgenommen werden, was bei FileMaker Pro mit den internen Script-M√∂glichkeiten nur eingeschr√§nkt m√∂glich ist. Nachteilig sind u.a. die Gr√∂√üenbegrenzung auf 2 GB und eine Instabilit√§t bei gr√∂√üeren Anwendungen.

OpenOffice Base ist ein DBMS, welches im Office Paket von OpenOffice bzw. LibreOffice enthalten ist. Das in der Programmiersprache Java entwickelt Programm steht als Open Source zur Verf√ľgung und kann daher ohne zus√§tzliche Kosten auf vielen unterschiedlichen Betriebssysteme installiert werden. Das Backend von Base wird mit Hilfe der sehr stabilen und robusten Datenbank HSQLDB betrieben, wobei das DBMS jedoch auch viele verschiedene Datenbanktreiber und Schnittstellen unterst√ľtzt. Gegen√ľber den kommerziellen L√∂sungen ist die Gestaltung der Oberfl√§chen umst√§ndlicher und weniger umfangreich.

SQLite ist das weltweit am häufigsten verwendete DBMS, da es im Bereich von Android Smartphones und Browsern zum Speichern von Daten verwendet wird. Die Daten werden in einer einzigen SQLite Datenbank gespeichert. Mit Hilfe der GIS Erweiterung SpatiaLite lassen sich auch Geodaten verarbeiten. Es existiert keine Client-Server Architektur, weswegen das DBMS nur von einem Einzelbenutzer betrieben werden sollte.

DBMS f√ľr Server-Datenbanken

Serverbasierte Datenbankmanagementsysteme bilden die Grundlage f√ľr Datenbanken, die kollaborativ und webbasiert, z.B. √ľber einen Internet-Browser, genutzt werden sollen. Anders als DBMS f√ľr Desktop-Datenbanken werden keine weiteren M√∂glichkeiten zur Gestaltung von grafischen Oberfl√§chen (z.B. Eingabeformulare oder Listendarstellungen) bereitgestellt. Diese m√ľssen mit Hilfe von Programmiersprachen (z.B. JavaScript, PHP oder Java) erstellt werden, was fundierte Software- und Informatikkenntnisse zur Entwicklung von Datenbankanwendungen voraussetzt. Insofern sind sie als Systeme f√ľr "schnelle L√∂sungen" ungeeignet, da in der Regel ein l√§ngerer Planungs- und Entwicklungszeitraum ben√∂tigt wird.

Gegen√ľber Desktop-Datenbanken, die u.U. parallel und technisch unabh√§ngig voneinander betrieben werden, besitzen sie jedoch erhebliche Vorteile hinsichtlich einer konsistenten Datenhaltung. Der Betrieb eines Server DBMS in einer sogenannten Server-Client-Architektur erm√∂glicht es mehreren Benutzern, gleichzeitig auf den jeweils aktuellsten Datenbestand zuzugreifen. Bei einer parallelen Eingabe von Daten verschiedener Nutzer im selben Datensatz verhindert das DBMS, dass es zu Versionierungskonflikten oder Verletzungen von Integrit√§tsbedingungen kommt und der Datenbestand inkonsistent wird.

MySQL und PostgreSQL sind weit verbreitete kostenlose Open-Source-DBMS, die sich in ihrem Funktionsumfang stark √§hneln. Der wesentliche Unterschied ist, dass PostgreSQL mit der Erweiterung PostGIS in der Lage ist, geografische Daten ad√§quat zu speichern und zu verarbeiten, was f√ľr die Auswertung der Datenbankinhalte in einem Geografischen Informationssystem (GIS) entscheidend ist. Daneben besitzt PostgreSQL gegen√ľber MySQL eine h√∂here Konformit√§t zum SQL-Standard, unterst√ľtzt JSON-Objekte, hat bessere Methoden zur Wahrung der Datenintegrit√§t und umfangreichere M√∂glichkeiten zur Erstellung von internen Funktionen (sog. Stored Prozedures). Jedoch weist MySQL durch seine weitere Verbreitung eine h√∂here Unterst√ľtzung von Web Frameworks auf. F√ľr Datenbankanwendungen in der Arch√§ologie kann insbesondere PostgreSQL empfohlen werden. Ein umfangreicher Vergleich beider Systeme kann als Auswahlhilfe dienen. F√ľr den Entwurf eines DMBS in MYSQL kann das frei verf√ľgbare Tool DBDesigner 4 verwendet werden.

Microsoft SQL Server und Oracle sind kommerzielle, serverbasierte DBMS mit einem vergleichbaren Funktionsumfang. Im direkten Vergleich ist Microsoft SQL Server einfacher zu administrieren und billiger in den Anschaffungskosten, w√§hrend Oracle die umfangreichsten Erweiterungs- und Anpassungsm√∂glichkeiten bietet, welche jedoch kaum einen praktischen Mehrwert f√ľr Datenbanken in den digitalen Geisteswissenschaften besitzen.

Administration von Server-Datenbanken

F√ľr alle genannten DBMS f√ľr Server-Datenbanken existieren grafische Administrationstools, mit deren Hilfe Anfragen an die Datenbank generiert werden k√∂nnen. Sie lassen sich nach Desktop- und webbasierten Anwendungen unterschieden sowie nach der Anzahl der unterst√ľtzten DBMS, da einige Tools entweder nur f√ľr ein spezifisches oder aber generisch f√ľr verschiedene DBMS geeignet sind.

Zu den empfehlenswerten Desktopanwendungen geh√∂ren die Tools pgAdmin3 (f√ľr PostgreSQL), MySQL Workbench (f√ľr MySQL), SQLite Database Browser (f√ľr SQLite), Oracle SQL Developer (f√ľr Oracle), SQL Server Management Studio (f√ľr Microsoft SQL Server) und SQuirrel SQL (u.a. f√ľr PostgreSQL, MySQL, Oracle, MicrosoftSQL, Microsoft Access). Webbasierte Administrationstools sind beispielsweise phpmyadmin (f√ľr MySQL), phppgadmin (f√ľr PostgreSQL) oder Adminer (f√ľr MySQL, PostgreSQL, SQLite, MS SQL und Oracle).

Dateneingabe und Datenqualität

Zentral f√ľr den Nutzen einer Datenbank ist, dass die semantische Definitionen jeder Entit√§t, und jedes Attributes bekannt sind, d.h. den einzelnen Bearbeitern muss bewusst sein, welche Eigenschaften eines Objektes der realen Welt in welchem Eingabefeld gespeichert werden. Dies kann entweder durch eine externe Dokumentation, deskriptive Eingabeformulare (z.B. mittels Hilfefunktionen), Beispieldatens√§tze, vorgegebene Termini (z.B. Werte-/Codelisten, Thesauri, Vokabulare) oder technische Funktionen (z.B. Indizes, Autovervollst√§ndigungen) unterst√ľtzt werden. Innerhalb eines Projektes individuell definierte oder extern importierte W√∂rter und Begriffe sollten bereits im Verlauf des Datenbankentwurfs festgelegt werden, um eine semantisch saubere Trennung verschiedener Attribute zu gew√§hrleisten.

Von Anfang an und insbesondere bei Mehrbenutzersystemen muss auf eine einheitliche Verwendung von Begriffen und eine möglichst vereinheitlichte Eingabe der einzelnen Werte geachtet werden. So sollte z. B. die gleiche Ansprache von Ortsnamen entweder abgesprochen und dokumentiert werden, durch einen entsprechenden Datenbankentwurf kontrolliert werden oder - im besten Falle - durch referenzierte Vokabular und Normdaten gewährleistet werden. Andernfalls kann es durch unterschiedliche Schreibweisen und Rechtschreibfehler beim Wiederauffinden von an sich gleichen Inhalten zu Problemen kommen. Hilfreich zur Verbesserung der Datenqualität sind Index-Funktionen, die viele DBMS anbieten, da mit ihnen in der Regel schnell erfasst werden kann, welche Werte bereits in ein Attribut eingetragen wurden, und dadurch fehlerhafte Einträge leicht identifiziert werden können.

Bei metrischen Eingaben muss fr√ľhzeitig die sp√§tere Auswertung (z.B. statistische oder r√§umliche Analysen) im Auge behalten werden, da diese die Speicherung als numerische Datentypen, die einheitliche Verwendung einer Ma√üeinheit, die als Metadatum in der Attributbeschreibung hinterlegt werden sollte, oder den Umgang mit unscharfen bzw. unvollst√§ndigen Werten beeinflusst.

Um m√∂glichst vollst√§ndige Suchergebnisse zu erhalten und eine h√∂here Vergleichbarkeit der eingegebenen Daten zu gew√§hrleisten, kann es sinnvoll sein, bei Eigenschaften von Entit√§ten, die als Freitext-Attribute modelliert werden (z.B. ausf√ľhrliche Beschreibungen), zus√§tzlich ein inhaltlich √§quivalentes Attribut mit kontrolliertem Vokabular vorzusehen (z.B. Schlagworte, die zu der freien Beschreibung passen). Bei l√§ngeren Freitext-Attributen ist es zudem ratsam, eine inhaltliche Strukturierung vorzugeben, oder es sollte √ľberlegt werden, diese Informationen auf mehrere separate Attribute aufzuteilen.

Wenn ein Attribut nicht ausgef√ľllt ist, kann es in manchen DBMS einen sog. NULL-Wert annehmen. Dieser entspricht keinem Datentyp und ist nicht mit der numerischen Ziffer 0 gleichzusetzen. Es ist ein symbolischer Wert, der aussagt, dass kein Wert vorhanden ist. Da in solchen F√§llen jedoch √ľblicherweise unklar ist, ob das Feld vergessen, √ľbersehen, nicht verstanden wurde, keine Angabe vorliegt oder erst sp√§ter bearbeitet werden soll (sog. Nullwert-Problematik), kann eine Eingabe erfolgen, die diese Unklarheit beseitigt. Daf√ľr k√∂nnen etwa bestimmte Zeichen reserviert werden, die sich von jedem anderen Wert in einer Datenbank unterscheiden, z.B.:

  • Information zur Zeit unbekannt bzw. nicht relevant: NULL
  • Information wird sp√§ter nachgetragen: #
  • Aussage derzeit nicht eindeutig m√∂glich oder zu beantworten: ?

Schnittstellen und Exportmöglichkeiten

Dient eine Datenbank u. a. als Arbeitsmittel zur strukturierten Erfassung von Daten, die in anderen Programmen weiterverarbeitet werden sollen, ist auf geeignete Exportformate zu achten. Oftmals kann die Entscheidung f√ľr oder gegen ein DBMS davon abh√§ngen, wie gut oder schlecht die Datenbankinhalte aus dem urspr√ľnglichen System wieder herausgeholt und nachgenutzt werden k√∂nnen; ein Aspekt der insbesondere f√ľr die Langzeitarchivierung von besonders hoher Relevanz ist. Prinzipiell lassen sich drei Arten von Exportm√∂glichkeiten unterscheiden, die von den allermeisten DBMS unterst√ľtzt werden:

  • Export einfacher textbasierter Dateiformate wie CSV oder TSV
  • Export komplexer strukturierter Dateiformate wie XML und JSON
  • ODBC (Open Database Connectivity) und JDBC (Java Database Connectivity) sind universelle Schnittstellen, welche den Zugriff auf und den Datenaustausch mit einer Datenbank erm√∂glichen.

Speicherung und Sicherung

Da Datenbanken in den Altertumswissenschaften in der Regel statische Daten enthalten, die nach der initialen Eingabe und ggf. einer ersten √Ąnderung kaum weiter modifiziert werden, sollte das L√∂schen von Datens√§tzen durch Sicherheitsabfragen und restriktive Zugriffsrechte abgesichert werden. Alle Ver√§nderungen an dem Datenbankinhalt werden in der Regel immer sofort und ohne Interaktion mit dem Benutzer durch ein DBMS gespeichert. Dies hat den Vorteile, dass ein ‚Äômanuelles‚Äô Speichern entf√§llt, aber auch den Nachteile, dass alle Dateneingaben - also auch versehentlich falsche- sofort g√ľltig und ohne eine Sicherung vorheriger Zust√§nde nicht revidierbar sind. Daher ist das Anlegen von Sicherungskopien oder Datenexporten, insbesondere vor gr√∂√üeren Ver√§nderungen des Datenbestandes, sehr zu empfehlen. Alternativ kann mit Hilfe einer Versionierung, die jegliche Zust√§nde der Datenbankinhalte abspeichert und vor allem bei Server-DBMS gut konfiguriert werden kann, auch auf √§ltere St√§nde zur√ľckgegriffen werden.

Mehrsprachigkeit

Vor allem in internationalen Projekten besteht h√§ufig die Anforderung, die Inhalte einer Datenbank mehrsprachig zu erfassen und auszuwerten. Eine technisch saubere L√∂sung, die die Inhalte in den verschiedenen Sprachen konsistent h√§lt, ist nur mit relativ hohem Aufwand zu realisieren und muss sorgf√§ltig geplant werden. Der Grad der Komplexit√§t der Umsetzung h√§ngt dabei auch davon ab, ob die Datenbank nur eine geringe und feste Anzahl von Sprachen (etwa nur zwei oder drei) oder prinzipiell beliebig viele unterst√ľtzen muss. Auf jeden Fall wirkt sich diese Anforderung auf den konzeptuellen und logischen Entwurf des Datenbankschemas aus.

Am einfachsten und unproblematischsten ist die Beschriftung der Benutzeroberflächen und Formulare (z. B. Überschriften, Bezeichnungen neben den Eingabefeldern, Hilfetexte) in verschiedenen Sprachen, da diese Elemente sich nicht auf die Datenbankinhalte selbst auswirken. Bei Attributen mit kontrolliertem Vokabular ist eine weitgehend automatische Übertragung in eine andere Sprache prinzipiell möglich, sofern Konkordanzlisten vorliegen. In diesen Fällen bietet sich die Benutzung internationaler Referenzsysteme an, bei denen Begriffe und Fachtermini bereits in verschiedenen Sprachen verwaltet werden, sowie im Wesentlichen auf abstrakte Konzepte - unabhängig von ihren sprachlich unterschiedlichen Bezeichnungen - verwiesen wird und die konkreten Wörter erst nach Auswahl einer Sprache durch den Datenbanknutzer nachgeladen werden.

Am schwierigsten und zeitaufwendigsten ist die Behandlung von mehrsprachigen Freitextfeldern. Entweder muss in diesem Fall f√ľr eine Eigenschaft eines Objektes mehrere sprachspezifische Attribute definiert werden (beispielsweise Beschreibung-deu, Beschreibung-eng) oder aber die Eingabe muss mit Hilfe von Hinweistexten, sogenannten Tags, annotiert werde (z.B. <de>Der Avers zeigt den bekr√§nzten Kopf von Nero nach rechts.</de> <en>The Avers shows the wreath head of Nero facing to the right.</en>) In beiden Varianten kann allerdings nicht gew√§hrleistet werden, dass die Eingabe in der einen Sprache inhaltlich mit der Eingabe in der anderen Sprache tats√§chlich √ľbereinstimmt, was nur durch zus√§tzliche manuelle Kontrollen √ľberpr√ľft werden kann.

Automatische Dokumentation der Datenbankstruktur

datenbanken_SchemaSpy_GUI.png

SchemaSpyGUI Benutzeroberfläche zur automatischen Dokumentation der Datenbankstruktur
SchemaSpyGUI Benutzeroberfläche zur automatischen Dokumentation der Datenbankstruktur
Die Erfassung von Metadaten zu einer Datenbank kann je ihrer Komplexit√§t sehr aufwendig sein, wobei sich verschiedene Tools zur automatischen Dokumentation der Datenbankstruktur anbieten, von denen besonders das Tool SchemaSpy zu empfehlen ist. Neben der M√∂glichkeit, Befehle direkt √ľber eine Kommandozeile einzugeben, existiert mit SchemaSpyGUI auch eine grafische Benutzeroberfl√§che (siehe Abbildungen).

Das Tool analysiert die Datenbank-Metadaten verschiedener DBMS, wie OracleDB, MySQL, PostgreSQL und MySQL, und erstellt unter anderem ein ERD aus der vorhandenen Datenstruktur, listet die Eigenschaften der Tabellen auf und visualisiert die Beziehungen zwischen ihnen. Es bietet damit eine wertvolle Unterst√ľtzung bei der Dokumentation der Datenstruktur, ersetzt jedoch nicht die inhaltliche und semantische Beschreibung von Tabellen, Attributen, Wertelisten und Sichten.

datenbanken_SchemaSpy_Documentation.png

Beispiel einer Dokumentation der Tabelle library.book mit Hilfe von SchemaSpy
Beispiel einer Dokumentation der Tabelle library.book mit Hilfe von SchemaSpy

Ein weiteres Tool speziell f√ľr SQL-Datenbanken ist der kostenlose ExPEditor, das eine Beschreibung der Datenbank im docx-Format generiert.

Access-Datenbanken dokumentieren

Microsoft Access bietet einige eingebaute M√∂glichkeiten, die die Erstellung einer Datenbank Dokumentation unterst√ľtzen.¬† Ausf√ľhrlicher werden die M√∂glichkeiten auf AccessDatabaseTutorial.com, bei Microsoft oder bei access-im-unternehmen.de erl√§utert.

  • Im Fenster Beziehungen (Microsoft Access 2010 > Datenbanktools > Beziehungen) sind alle Tabellen der Access Datenbank inklusive ihrer Beziehungen untereinander dargestellt. Es ist auch m√∂glich dieses Beziehungsdiagramm als Beziehungsbericht zu exportieren. (Microsoft Access 2010 > Datenbanktools > Beziehungen > Entwurf > Beziehungsbericht)
  • Der Databanken Dokumentierer (Microsoft Access 2010 > Datenbanktools > Datenbankdokumentierer) erm√∂glicht es automatisiert eine Dokumentation zu ausgew√§hlten Objekten (Tabellen, Abfragen, Formularen, Berichten und Makros) zu erstellen. Das Textdokument kann nach Word exportiert werden.
  • Das Database Preservation Toolkit unterst√ľtzt MS Access. Damit l√§sst sich die Datenbank mit Hilfe von SIARD archivieren. Mit SIARD kann auch die Datenbankstruktur beschrieben werden. Es wird jedoch empfohlen zus√§tzlich das Beziehungsdiagramm zu exportieren.

 

Datenbanken mit SIARD archivieren

Mit dem Format SIARD in der Version 2 lassen sich Datenbanken unabh√§ngig von dem verwendeten DBMS sehr gut f√ľr die Archivierung vorbereiten. Die Erzeugung einer SIARD-Datei erfolgt mit dem Database Preservation Toolkit, das per Kommandozeile bedient wird. Die Software verbindet sich unter Angabe DBMS-spezifischer Parameter mit einer laufenden Datenbank, extrahiert die Struktur inklusive aller Attribute, Metadaten, Skripte sowie der Inhalte und transformiert alle Informationen in das SIARD-Format. Umgekehrt erm√∂glicht das Toolkit auch die Umwandlung einer SIARD-Datei in ein anderes DBMS-Format. Eine Beschreibung der Benutzung des Tools wird ebenfalls bereit gestellt.

FileMaker-Datenbanken archivieren

Das DBMS FileMaker Pro wird von den genannten Tools nicht unterst√ľtzt, da die Software anerkannte Standards, wie die Datenbanksprache SQL, nur eingeschr√§nkt unterst√ľtzt. Daher muss bei der Archivierung und Dokumentation von FileMaker-Datenbanken ein individueller Ansatz gew√§hlt werden, der hier skizziert wird.

Mit FileMaker Pro Advanced, einer erweiterten Version von FileMaker Pro, kann das Datenbankschema mit der Funktion "Datenbank-Design-Report" unter Werkzeuge > Datenbank-Design-Report in HTML oder XML dokumentiert werden. Die Funktion wird in der FileMaker Hilfe beschrieben.

Die Datenbankinhalte selbst lassen sich aus FileMaker Pro mit Hilfe von Datei > Datensätze exportieren... unter Windows, bzw. Ablage > Datensätze exportieren... unter MacOS im Format XML exportieren, wobei als XML-Grammatik FMPDSORESULT verwendet werden sollte, um die Lesbarkeit zu erhalten.

 <?xml version="1.0" encoding="UTF-16"?>
    <FMPReport creationTime="14:38:43" creationDate="08.12.2016"
                         type="Summary" version="11.0v3">
            <File link=".//Bleibarren_Bohrkern.xml"
                        name="Bleibarren_Bohrkern" path="134.95.117.58">
                    <BaseTables count="3"/>
                    <Tables count="37"/>
                    <Relationships count="35"/>
                    <Accounts count="4"/>
                    <Privileges count="4"/>
                    <ExtendedPrivileges count="6"/>
                    <FileAccess count="0"/>
                    <Layouts count="1"/>
                    <Scripts count="10"/>
                    <ValueLists count="87"/>
                    <CustomFunctions count="1"/>
                    <FileReferences count="13"/>
                    <CustomMenuSets count="2"/>
                    <CustomMenus count="30"/>
            </File> 

Ausschnitt des Filemaker-Datenbank-Design-Berichts im XML-Format

 

Letzte Änderung: 7. August 2017