Gregor Retti
WS 1994 / 95
Skriptum zur Lehrveranstaltung
Gregor.Retti@uibk.ac.at
Unter einer Datenbank versteht man üblicherweise einerseits eine Menge organisierter Daten und andererseits eine dazugehörige Datenverwaltung (d.i. ein Programm zur Organisation der Daten). Die Organisiertheit von Daten findet sich auch in Datensammlungen, die nicht mittels eines Computers verwaltet werden (Zettelkasten, Telefonbuch, Wörterbuch etc.). Ein Datenbankprogramm muß gewisse Basisfunktionalitäten aufweisen: z.B. die Strukturiertheit der Daten erhalten (zum Unterschied einer Textverarbeitung), Funktionen wie Suche und Sortierung unterstützen etc.
Es gibt derzeit auf den unterschiedlichen Hardwareplattformen eine erkleckliche Anzahl unterschiedlich leistungsstarker und unterschiedlich kostspieliger und unterschiedlich benutzerfreundlicher Datenbankprogramme. Allen ist aber grundsätzlich gemeinsam, daß sie eine Adapation an die speziellen Bedürfnisse des Benutzers erfordern, bevor mit ihnen überhaupt Daten verarbeitet werden können. Für die Praxis bedeutet dies, daß vor dem Arbeiten mit einer Datenbank eingehende Überlegungen über die Natur und Struktur der zu verarbeitenden Daten angestellt werden müssen. Schwerwiegende Fehler beim Entwurf einer Datenbank können sich durch beträchtliche Mehrarbeit rächen. Grundsätzlich sollte man beachten, daß die Daten in jedem Fall transportabel bleiben, um jederzeit das Programm wechseln zu können.
Datenbanken sind Abbildungen (der realen Welt). Dies impliziert, daß mit der Exaktheit der Abbildung die Wahrscheinlichkeit zunimmt, daß die aus einer Datenbank gewonnen Erkenntnisse in der Welt des Abgebildeten zutreffen. Da aber eine vollständige Abbildung nicht möglich (und auch zumeist nicht erwünscht) ist, müssen die Ergebnisse, die aus einer Datenbank gewonnen werden, in einem Spektrum von ziemlich wahr(scheinlich) bis eigentlich (ver)fa(e)lsch(t) liegen.
Der Begriff der Daten wird nicht immer gleich verwendet. Geht man von
der realen Welt aus, so ergeben sich als nächste Ebene (zumeist
sprachliche) Informationen über diese. Eine weitere Abstraktion
führt zur logischen Datenbeschreibung. Hinsichtlich des
Computers gelangt man schließlich zu physischen Daten, d.i.
die Form der gespeicherten Daten.
z.B.:
ein bestimmtes Buch Objekt der realen Welt
Titel des Buchs Information über das Buch
Klasse "Buch" logische Datenbeschreibung
Bytes auf einer Diskette physische Daten
Für die Verarbeitung von Daten lassen sich sinnvoll einige verschiedene Typen unterscheiden. Die meisten Datenbankprogramme treffen ähnliche Unterscheidungen:
Unter einem anderen Gesichtspunkt lassen sich skalare und nicht-skalare Datentypen unterscheiden. Unter skalaren Daten versteht man solche, die in einer bestimmten Datenbank nur einen Wert aus einer endlichen Menge von Werten haben können (z.B. von 1 bis 100 bei Prozentwerten). Bei nicht-skalaren Daten gilt diese Einschränkung nicht.
Um die Begriffe Datensatz (record, row, Tupel) und Datenfeld (field, column, Attribut) besser zu verstehen, stellt man sich die Datenbank am besten als Tabelle vor, in der die Daten einer Zeile zusammengehören, indem sie ein Objekt beschreiben, und die einer Spalte zusammengehören, indem sie dasselbe Merkmal der erfaßten Objekte beschreiben und demselben Datentyp angehören. Üblicherweise werden für Datenfelder Namen vergeben, die (vgl. oben) der logischen Datenbeschreibung entsprechen.
Verschiedene Datenbankenprogramme und die mit ihnen verwaltbaren Datenbanken lassen sich unter einer Reihe verschiedener Gesichtspunkte klassifizieren. Jeder dieser Punkte kann für die Auswahl bei der Erstellung einer Datenbank von Bedeutung sein.
Unterscheidung nach der Organisationsstruktur:
Unterscheidung nach der Softwarearchitektur:
Unterscheidung nach der Vernetzbarkeit:
Unterscheidung nach der Plattformabhängigkeit:
Unterscheidung nach der Programmierung:
Unterscheidung nach der Arbeitsaufwand:
Unterscheidung nach der Einbindung in die Arbeitsumgebung:
Manche der Unterscheidungskriterien können für ein konkretes Projekt selbstverständlich irrelevant sein. Es gilt auch zu beachten, daß z.B. die Qualitäten eines Programms, hinsichtlich der Benutzerschnittstelle und der Gestaltbarkeit, dieses zur Dateneingabe prädestinieren, während die Auswertung der Daten in einem anderen System erfolgt, auf das z.B. von mehreren Benutzern gleichzeitig zugegriffen werden kann oder das eine bessere Verarbeitungsgeschwindigkeit aufweist.
Bei der Erstellung einer Datenbank geht der Auswahl der geeigneten Soft- und Hardware immer erst eine eingehende Analyse der zu verarbeitenden Daten voraus. Selbstverständlich ist auch der Zweck der Datenbank möglichst exakt zu bestimmen. Insbesondere bei Benutzern ohne einschlägige Erfahrungen sind die Vorstellung oft recht nebelhaft, was nicht selten unnötige Mehrarbeit bedeutet, da Bedürfnisse erst zu einem späteren Zeitpunkt artikuliert werden und dann -- abhängig vom verwendeten System -- mehr oder weniger viel Aufwand zur Umgestaltung der Datenbank nötig wird.
Einige Punkte, die beim Entwurf einer Datenbank beachtet werden sollten:
-- Sind bereits Daten vorhanden oder nicht?
Falls Daten vorhanden sind, stellt sich die Frage in welchem Format diese vorliegen. Ein Vorteil bei vorhandenem Datenmaterial liegt darin, daß die Fragestellung, welche Daten verarbeitet werden sollen und welche nicht, wegfällt, daß Daten zum Testen der Datenbank vorliegen und daß an die Stelle der (meist mühsamen) Dateneingabe das Importieren von Daten tritt. Nachteile sind etwa, daß bei einer verfehlten bestehenden Struktur diese oft übernommen werden muß, daß eine gewisse Ähnlichkeit bei der Bedienung der Datenbank oft gewünscht wird u.a.m.
Sollten noch keine Daten vorliegen, kann mehr Gewicht auf die Sturkur und Datenanalyse gelegt werden. Die Gefahr aber, daß sich nach der Fertigstellung der Datenbank die Notwendigkeit zu Änderungen einstellt ist größer. Außerdem kann die Gewinnung von Testdaten ein Problem darstellen.
-- Wie groß ist die voraussichtliche Datenmenge?
Manche Datenbanksysteme zeigen einen deutlichen Leistungsabfall bei größeren Datenmengen. Dies ist den Handbüchern oftmals nicht zu entnehmen. Wenn die Menge der Daten in etwa bekannt ist und relativ groß erscheint, sollten erst Tests gemacht oder Erfahrungswerte gesammelt werden. Auch die Datentypen können hier eine Rolle spielen: Sollen Bilddaten oder längere Texte verarbeitet werden?
-- Wie komplex sind die Daten?
Ist das Datenbanksystem in der Lage, die Komplexität der Daten darzustellen?
-- Wieviele Benutzer wird die Datenbank haben?
Hier fällt die Entscheidung für ein Ein- oder Mehr-Platz-System.
-- Entwicklungsaufwand vs. Änderbarkeit
Je kleiner der Entwicklungsaufwand ist, desto eher ist man bereit, nachträglich anfallende Änderungen durchzuführen. Wenn also nicht ganz klar ist, ob sich bei der Arbeit mit der Datenbank nicht völlig neue Bedürfnisse einstellen, sollte ein System gewählt werden, in dem solche Änderungen schnell und unproblematisch durchgeführt werden können.
-- Portablität und Skalierbarkeit
Es ist ein verbreiteter Fehler, eine eventuell vorhandene Hardware als maßgeblichen Faktor beim Entwurf einer Datenbank zu berücksichtigen (auf vorhandene Kenntnisse der Benutzer Rücksicht zu nehmen, ist dagegen u.U. recht sinnvoll). Die Hardware ist üblicherweise die kurzlebigste Komponente eines Datenbanksystems -- die Daten sind dagegen von dauerhafter Natur. Da meist damit zu rechnen ist, daß im Laufe der Zeit die verwendete Hardware zu leistungsschwach wird, also auf eine leistungsstärkere Hardware umgestellt werden muß (Skalierbarkeit), sollte auf Portablität (Übertragbarkeit auf andere Hardware) besonderer Wert gelegt werden. Hierbei läßt sich unterscheiden, ob die Datenbank vollständig, d.h. inklusive Daten, Strukturen, Benutzerschnittstelle etc. oder nur teilweise übertragen werden kann. Die geringste Portablität erlaubt nur die Übertragung der Daten (in einem Austauschformat). Client/Server-Systeme bieten hier den Vorteil, daß u.U. nur ein Teil der Datenbank übertragen werden muß (z.B. Auf- oder Umrüstung des Servers; keine Änderung in der Clientsoftware). Die Umstellung eines funktionierenden Systems birgt meist unerfreuliche Überraschungen (dies betrifft bekanntlich nicht nur Datenbanksysteme). Sie sollte daher mit der nötigen Vorsicht vorgenommen werden.
Auch eine Datenbank, die nur dem eigenen Zweck dient, sollte getestet werden, bevor mit ihr Daten verarbeitet werden. Wichtiger sind Tests aber, wenn die Datenbank für jemand anderen erstellt wird.
Manche Test lassen sich selbst auführen, andere sollten besser von jemandem ausgeführt werden, der nicht am Entwicklungsprozeß beteiligt ist. Der Grund hierfür ist, daß genaue Kenntnisse des Innenlebens der Datenbank (insbesondere, wenn diese programmierte Komponenten enthält) dazu führen, daß der Tester sich an diesen Kenntnissen orientiert und damit nur Handlungen ausführt, die bei der Programmierung berücksichtigt wurden.
Selbstverständlich ist es unmöglich, alle nur erdenklichen Konfigurationen und Situationen auszutesten. Um unerfreuliche Überraschungen auszuschließen, sollte die Hard- und Softwareumgebung möglichst exakt der vorausichtlichen Einsatzumgebung entsprechen.
Einige Anhaltspunkte für Tests:
-- Funktionalität der Datenbank
Werden die Daten wie geplant verarbeitet? Werden die event. zu importierenden Daten korrekt eingelesen? Bewähren sich die definierten Restriktionen (z.B. ein bestimmtes Datenfeld muß einen Wert enthalten, einen eindeutigen Wert enthalten etc.). Entspricht die Datenausgabe den Erwartungen? Ist die Benutzerschnittstelle stabil? usw.
Manche dieser Test sollten mit kleinen, bekannten Datenmengen durchgeführt werden, das Ergebnis ist dann überprüfbar.
-- Fehlerverhalten
Beim Test von Fehlerreaktionen des Systems sind zwei Komponenten
hervorzuheben:
1) Bleiben die Daten bei einem Fehler unbeschädigt?
2) Wie sieht das Feedback an den Benutzer aus?
Wie reagiert das Datenbanksystem auf Fehler, z.B. zu wenig Hauptspeicher, zu
wenig Plattenplatz, Konfigurationsfehler, Systemabstürze, Bedienungsfehler
etc.
-- Datenmenge
Da die Performance bei Datenbank überlicherweise ein kritischer Punkt ist, sollte die Datenbank u.U. auch mit mehr Daten, als zu erwarten sind, getestet werden. Hierzu können Methoden der automatischen Vervielfachung hilfreich sein. Wenn Originaldaten zum Test vorliegen, ist dies vorzuziehen.
Einfache zeitkritische Operationen sind Suche und Sortierung. Wenn sich herausstellt, daß das Datenbanksystem zu langsam ist und keine Möglichkeit besteht, Beschleunigung durch Wechsel der Hard- oder Software zu erreichen, sollte bei landdauernden Prozessen entsprechendes Feedback an den Benutzer ausgegeben werden (das die Datenbank laut scharrend auf der Festplatte wütet, ist nicht unbedingt ausreichend).
-- Testphase
Es empfiehlt sich, eine Testphase im sogenannten Echtbetrieb durchzuführen, d.h. der oder die Benutzer arbeiten mit Datenbank. Benutzer sind die besten Tester. Die Ergebnisse der Testphase können dann zur Verbesserung und Konsolidierung der Datenbank verwendet werden, bevor sie definitiv zum Einsatz kommt.
Viele Datenbanksysteme erlauben die Entwicklung von Datenbank mit Unterstützung grafischer Schnittstellen. Besonders im Umgang mit diesen Systemen ist darauf zu achten, daß alle Komponenten (Defintionen, Masken, Ausgabe etc.) dokumentiert sind. Wenn erst im Nachhinein die Datenbank analysiert werden muß, um evnt. Änderungen vorzunehmen, ist dies ein sinnloser Mehraufwand. Auch wenn die Datenbank von unerfahrenen Benutzern bedient wird, sollte es das Ziel einer Dokumentation sein, eine erschöpfende Beschreibung der Datenbank zu geben. Technische Hinweise sollten von Benutzerhinweisen getrennt werden. Bisweilen kann eine Dokumentation auch kürzer sein, wenn für die verwendete Datenbanksoftware ausreichend Material zur Verfügung steht, auf das verwiesen werden kann. Dokumentationen werden zwar wie Computerhandbücher normalerweise nicht gelesen, aber für den Entwickler der Datenbank sind sie allemal praktisch.
Eine Dokumentation sollte folgende Punkte enthalten:
Alle Datenbanksysteme unterstützten gewisse Standardfunktionen. Hiezu gehören Datenmanipulationen (Eingabe, Änderung, Löschen), Datenselektion (Suche) und Datenausgabe.
Bei der Dateneingabe (über Tastatur) oder -erfassung (über Meßgeräte etc.) ist besonders darauf zu achten, daß keine falschen oder unvollständigen Daten in die Datenbank gelangen. Ab einer gewissen Größe sind die Daten nicht mehr wirklich korrigierbar (abgesehen von Zufallsfunden). Entsprechende Maßnahmen (Konsistenzprüfungen) werden von den meisten Datenbanksystemen unterstützt. Nur in einer Datenbank, die man selbst erstellt hat und mit der man selbst arbeitet und die nicht so wichtig ist, kann man es sich leisten, auf entsprechende Maßnahmen zu verzichten.
Die Dateneingabe durch Menschen stellt insofern einen besonderen Problembereich dar, als Menschen üblicherweise "Fehler" machen, die für die verarbeiteten Informationen hinsichtlich deren Verständlichkeit und Korrektheit im Bezug auf andere Menschen keine oder nur eine untergeordnete Rolle spielen, während solche "Fehler" für ein Datenverarbeitungssystem bisweilen katastrophale Folgen haben können. Menschen sind es gewöhnt, mit unvollständigen oder deformierten Informationen umzugehen, Computer können diese Fähigkeit bestenfalls unter Einsatz von Methoden der Künstlichen Intelligenz in mehr oder minder stark eingeschränkten Kontexten ansatzweise simulieren. Je stärker der formale Charakter von Daten ist, desto eher ist der Computer in der Lage, ihre Richtigkeit zu prüfen (z.B. Prüfziffer am Ende einer mehrstelligen Zahl, "dumme" Tippfehler durch Rechtschreibkorrektur, Vollständigkeit eines Datums etc.).
Nach Daten in einer Datenbank zu suchen bedeutet, eine Auswahl (Selektion) zu treffen: eine Teilmenge von Datensätzen aus der Gesamtmenge wird festgelegt.
Datenbankintern spielt für die Geschwindigkeit der Suche die Indizierung von Datenfeldern meist eine große Rolle. Ein Index stellt dem Datenbanksystem die Daten in einer für den jeweiligen Suchalgorithmus (und auch Sortieralgorithmus) optimierten Art dar. Der Zeitgewinn ist damit ein Vorteil von Indizes, ein Nachteil ist der erhöhte Speicherbedarf und der vermehrte Rechenaufwand bei der Datenmanipulation: nicht nur die Daten müssen akutualisiert werden, sondern auch der dazugehörige Index. Besonders Datenbanken auf CDROM haben gerne große Indizes. Dies liegt einerseits an der verfügbaren Speicherkapazität, der Unveränderbarkeit der Daten und soll nicht zuletzt die langsame Zugriffszeit auf CDROM-Laufwerke kompensieren.
Für den Benutzer präsentiert sich die Suche oft in einer Maske (die bisweilen der Eingabemaske gleicht) mit den suchbaren Datenfeldern. Üblicherweise werden boolsche Operationen unterstützt (logisches UND, logisches ODER, logisches NICHT). Weiters sollte die Suche die Verwendung von Platzhaltern ("wildcards", Trunkierung) erlauben (solche Platzhalter sollten dann für die Dateneingabe ausgeschlossen werden, außer sie lassen sich in der Suche anders darstellen). Schließlich ist wünschenswert, wenn die Suche nach Bereichen (von ... bis ...), fehlenden Werten, größeren bzw. kleineren Werten u.a.m. unterstützt wird. Ein Datenbanksystem sollte darauf geprüft werden, was es in dieser Hinsicht kann und vor allem nicht kann.
Die Sortierung von Daten ist eigentlich eher der Datenausgabe zuzurechnen. Sortierungen erfolgen absteigend oder aufsteigend, numerisch, alphabetisch oder alphanumerisch, mehrere Sortierebenen sind möglich (die letzte Ebene ist damit immer die wichtigste). Da der Umgang mit "Sonderzeichen" bei der Sortierung Porbleme aufwerfen kann, ist zu untersuchen, wie solche Zeichen sortiert werden. Auch die Sortierung von fehlenden Werten sollte bekannt sein. Sortierung kann ebenfalls zeitaufwendig sein.
Für die Datenausgabe ("Reports") gibt es eine Vielzahl verschiedener Modelle und Möglichkeiten. Die Daten können sich in der Ausgabe auch völlig anders präsentieren als in der Eingabe. Dies ist in erster Linie vom Zweck der Datenbank abhängig. Teildaten können präsentiert werden, Listen, summierende Berichte oder nur die Anzahl der gefundenen Datensätze. Zu beachten ist auch, wohin die Ausgabe erfolgt bzw. erfolgen kann: Bildschirm, Drucker, Datei, andere Schnittstellen. Es gibt spezielle Ausgabeformate (z.B. Serienbriefdateien zur Weiterverarbeitung mit einer Textverarbeitung, Austauschformate vgl. unten). Systeme, die keine Möglichkeit bieten, die Ausgabe in Dateien umzuleiten, sind mit Mißtrauen zu betrachten.
Operationen, die in vielen Datenbanksystemen unterstützt werden, lassen sich danach unterscheiden, ob sie auf einzelne Datensätze oder Mengen von Datensätzen angewandte werden, und auf welche Datentypen sie angewandt werden können. Diese Operationen, gerne Funktionen oder Formeln oder so genannt, lassen sich zumeist auch kombinieren. Sie können in der Dateneingabe und / oder in der Datenausgabe eingesetzt werden.
Einige Funktionen:
Die oben schon mehrfach erwähnte Benutzerschnittstelle ("User interface") spielt bei der Bedienbarkeit einer Datenbank eine ausschlaggebende Rolle. Heute werden graphische Benutzerschnittstellen ("GUI", d.h. "Graphical User Interface") zunehmend zum Standard. GUIs bringen für den Entwickler den Vorteil mit sich, daß er nicht für jede Funktionalität ein bestimmtes Verhalten seines Programms erfinden muß, sondern auf die Standards des jeweiligen GUIs rekrutieren kann, und den Nachteil, daß diese Standards ziemlich verbindlich sind, d.h. vom Benutzer Abweichungen übel genommen werden. Da man bei der Entwicklung von Datenbank meist mit Entwicklungswerkzeugen arbeitet, die die Elemente eines GUIs zur Verfügung stellen, hängt es mehr vom Datenbanksystem als von einem selbst ab, wie hoch die Konsistenz der Benutzerschnittstelle mit dem jeweiligen GUI ist. Je weiter die Programmierbarkeit der Benutzerschnittstelle geht, desto mehr Verantwortung hat man selbst. Graphische Benutzerschnittstellen müssen allein schon deshalb intensiver getestet werden, weil dem Benutzer mit Tastatur und Maus zwei Eingabemedien zur Verfügung stehen, um das Interface ins Wanken zu bringen.
Das Feedback an den Benutzer sollte möglichst einfach und verständlich sein. Meldungen von der Art "Error at line 354: DEFPROC -4656 / Aborted" sind nur mit Hilfe der technischen Dokumentation verständlich. Die Erfahrung zeigt auch, daß Warnhinweise nicht beachtet werden, wenn sie zu häufig auftreten ("Alle Dateien löschen (J/N)?").
Wenn gewisse Funktionen in bestimmten Situationen nicht verfügbar sind, sollte dies optisch signalisiert werden. Die Durchführung der Funktion mit der Rückmeldung "Dies ist im Augenblick nicht möglich?" abzuwehren, führt auf Seiten des Benutzers zu Frustrationen, da er solche Meldungen (wie auch Warntöne) anders interpretiert, nämlich als Nachweis seiner Unkenntnis.
6. Übetragung von Daten / Austauschformate
Die Übertragung bzw. Übertragbarkeit von Daten zwischen verschiedenen Datenbanksystemen (auf verschiedenen Hardwareplattformen) spielt bei der Übernahme von bestehenden Datenbeständen, bei der Weitergabe von Daten, beim Wechsel des Datenbanksystems usw. eine Rolle. Es gibt einige gängige Übertragungsformate und das Datenbanksystem sollte in der Lage sein, eines oder mehrere dieser Formate zu unterstützen. Daneben gibt es auch Konvertiertungsprogramme, die von einem ins andere Format konvertieren können. Bei der Übertragung von Daten zwischen verschiedenen Betriebssystemen muß auch die korrekte Konvertierung von Zeichen der zweiten Hälfte des ASCII-Codes berücksichtigt werden (z.B Umlaute, ß etc.).
Einige Formate:
7. Datensicherheit und Datenschutz
Ohne daß hier im einzelnen auf den Bereich der Datensicherheit eingegangen werden soll, seien die Hauptbereich aufgeführt: Schutz vor Verlust und Verfälschung von Daten; Schutz vor unberechtigtem Zugriff auf Daten. Diese Bereiche sind vor allem dann von Bedeutung, wenn mehrere Benutzer (gleichzeitig) an einer Datenbank arbeiten.
Datenschutz erhält naturgemäß vor allem dort größere Brisanz, wo personenbezogene Daten verarbeitet werden. Im Rahmen der Erstellung von Datenbanken scheint derzeit der Datenföderalismus einen höheren Schutz der Interessen des Betroffenen zu bieten, als dies in zentralen Datenorganisationsformen gewährleistet ist. Datenföderalismus bedeutet, daß Daten in Teilbereichen autonom organisiert sind und nur unter bestimmten, genau definierten Bedingungen zusammenarbeiten können. Dies zieht zwar vielfach einen größeren Arbeits- und Kostenaufwand nach sich, welcher jedoch gerade im öffentlichen Bereich als gerechtfertigt betrachtet werden muß - zumal eine Datenschutzkultur bestenfalls im Entstehen begriffen zu sein scheint.