Gregor Retti
SS 1995
Skriptum zur Lehrveranstaltung
Gregor.Retti@uibk.ac.at
(Zehnder 1989: 17 ff.)
Um Daten und Datensysteme bzw. Datenbanken programmunabhängig
beschreiben
zu können, bedient man sich eines Datenmodells (auch:
Datenbeschreibungssprache). Drei Modelle sind seit längerem
verbreitet:
das hierarchische Modell, das Netzwerkmodell und
das
tabellarische oder relationale Modell. In jedem
Modell
gilt es, die Struktur von den konkreten Datenbeständen, dem
Vorkommen der Daten zu unterscheiden.
Als Beispiel soll eine lexikographische Datensammlung dienen.
Verschiedene
"Denotat(e)" haben in verschiedenen "Regionen" verschiedene
"Bezeichnungen".
Hierarchisches Modell
Die Struktur in einer hierarchischen Gliederung sieht
folgendermaßen
aus:
Zwischen "Denotat" und "Bezeichnung" sind 1-m-Beziehungen ("1 zu m") möglich, d.h. daß zu jedem Denotat (jeder Sache) mehrere (m) Bezeichnungen (auch: Söhne, children) möglich sind, während zu jeder Bezeichnung nur genau 1 Denotat (auch: Vater, parent) möglich ist. Das Datenvorkommen kann so dargestellt werden:
Die Organisation von Daten in einem hierarchischen Modell wird sequentiell genannt, d.h. die Daten werden in einer bestimmten Reihenfolge gespeichert und verarbeitet. Es herrscht ein klare Aufbau im Sinne eines Baumgraphen, in der die Sohnelemente den Vaterelementen nachgeordnet sind. Was allerdings nicht im hierarchischen Modell dargestellt werden kann, sind z.B. m-m-Beziehungen.
Netzwerkmodell
Im Netzwerkmodell ist es möglich m-m-Beziehungen darzustellen.
Netzwerke
können auch als Modelle mit mehreren Hierarchien betrachtet
werden, d.h.
ein Sohnelement kann mehr als ein Vaterelement habe. Die Struktur eines
Netzwerkmodells kann so aussehen:
Das Datenvorkommen kann folgendermaßen dargestellt werden:
Relationales Modell
Dieses Modell geht auf E.F. Codd zurück. Es benützt
die
Tabelle als Datenstruktur. Es werden nur Daten und keine
Beziehungen
zwischen diesen dargestellt. Durch einen Vergleich von verschiedenen
Daten kann
aber ein Beziehung rekonstruiert werden.
Die Datenstruktur: BEZEICHNUNG (Denotat, Lemma, Region)
Das Datenvorkommen:
BEZEICHNUNG: Denotat Lemma Region __________________________________________ [...] Handwerker Metzger westöst. [...] Handwerker Fleischhauer ostöst. eine die putzt Putzerin westöst. eine die putzt Zugeherin westöst. eine die putzt Bedienerin ostöst. eine die putzt Putzfrau binnendt.
Tupel heißt eine Zeile (waagrecht) - auch Datensatz, record, row -, Attribut eine Spalte (senkrecht) - auch Datenfeld, field, column - der Tabelle bzw. Relation.
Objektorientierte Datenbanken
(vgl. Goldberg 1993)
Eine der letzten Entwicklungen auf dem Datenbanksektor sind
Objektorientierte
Datenbanken. Sie werden vor allem dort eingesetzt, wo die zu
speichernden Daten
an sich äußerst komplex sind, wie z.B. in geographischen
Informationssystemen oder CAD/CAM-Anwendungen. Den Objektorientierte
Datenbanken mangelt es allerdings bisher an einer ausgereiften
theoretischen
Basis.
2. Datenbankentwurf am relationalen Modell
(Zehnder 1989: 41 ff.)
Ein Tupel ist eine Gruppe von Einzeldaten (Datensatz), mit dem ein Objekt der realen Welt, eine Entität (entity) beschrieben wird. Mit verschiedenen Schlüsseln (key) werden die Datensätze einer Datenbank organisiert. Ein Identifikationsschlüssel (primary key) dient dazu, einen Datensatz eindeutig zu identifizieren. Hiefür werden gerne Nummern verwendet (vgl. Matrikelnummer, Sozialversicherungsnummer). Suchschlüssel (search key) beziehen sich oft auf mehr als einen Datensatz, bzw. werden mit ihnen mehr als eine Entität angesprochen (z.B.: Suchschlüssel "Region" und Wert "ostöst." ergibt mehrere Datensätze aus obiger Tabelle). Sortierschlüssel (sort key) bestimmen die Reihenfolge der Datensätze (aufsteigend, absteigend; alphabetisch, numerisch, nach Datum).
Der Begriff der Entität dient dazu, die Welt in diskrete Elemente zu zergliedern. Die Beschreibung von Entitäten erfolgt durch Merkmale bzw. Attribute, deren Wert hinsichtlich einer Entität angegeben wird. Bei der Modellbildung einer Datenbank besteht ein wesentlicher Schritt darin, Entitäten mit gleichen oder ähnlichen Merkmalen, aber unterschiedlichen Werten zu Entitätsmengen (entity sets) zusammenzufassen. Man unterscheidet weiter zwischen disjunkten Entitätsmengen und überlappenden Entitätsmengen, im ersten Fall gehört keine Entität zu mehr als einer Entitätsmenge, im zweiten Fall gehören manche Entitäten zu mehreren Entitätsmengen.
Beziehungen zwischen Entitätsmengen umfassen die quantitativen Zusammenhänge zwischen diesen. Zur Beschreibung dieser Beziehungen werden gerichtete Assoziationen herangezogen. Eine Assoziation (EM1, EM2) legt fest, wieviele Entitäten aus EM1 einer Entität aus EM2 zugeordnet sein können. Vier Haupttypen von Assoziationen werden unterschieden:
Assoziationstyp (EM1, EM2) Entitäten aus EM2, die jeder
Enität aus
EM1 zugeordnet sind
1: (einfache Assoziation) genau eine
c: (konditionelle Assoziation) eine oder keine (c = 0 / 1)
m: (multiple Assoziation) mindestens eine (m >= 1)
mc: (multipel-konditionelle A.) eine, keine oder mehrere (mc
>= 0)
Aus der Kombination einer Assoziation (EM1, EM2) mit ihrer Gegen-Assoziation (EM2, EM1) ergibt sich die Beziehung (relationship) zwischen den beiden Entitätsmengen. Zehn verschiedene Beziehungstypen können unterschieden werden:
EM1 EM2 Beziehungstyp Beziehung Silbenzahl Schriftzeichen 1 - 1 Chinesisch Landschaft Sprache c - 1 Verbreitungsgebiet Wörter Sprache m - 1 Wortschatz Bedeutung Lautfolge mc - 1 Wort oder nicht Wörterbuch Wörterbuch c - c gemeinsamer Eintrag Menschen Einzelsprache m - c Sprecher d. Sprache Menschen Sprachen mc - c Muttersprachler Laut Sprachen m - m Lautinventar Schriftzeichen Sprachen mc - m Schrift Menschen Sprachen mc - mc Sprecher v. Sprachen
Attribute oder Merkmale dienen der Beschreibung einer bestimmten Eigenschaft einer Entität. In einem bestimmten Tupel hat ein Attribut einen bestimmten Wert. Ein Wertebereich ist eine Menge verschiedener Werte desselben skalaren Datentyps (z.B. Zahlen von 1 bis 100, Wochentag, Wortklassen etc.). Wenn als Werte für ein Attribut nur solche eines skalaren Datentyps zugelassen sind, spricht man von einer formatierten Darstellung. Ansonsten ist die Darstellung unformatiert - sie wird als Text betrachtet. Die meisten Datenbanksysteme unterstützen die Verwaltung formatierter Werte besser als die unformatierter Werte. Oft dienen formatierte Werte daher dem besseren Zugang, während die tatsächlich relevante Information in unformatierter Form vorliegt.
Innerhalb des relationalen Modells spielt die Abhängigkeit von Attributen bzw. Attributskombinationen eine bedeutende Rolle. Abhängig ist ein Attribut A von einem Attribut B dann, wenn zu einem bestimmten Wert von A höchsten ein Wert von B möglich ist, d.h. in einem Datensatz vorausgesagt werden kann, daß immer dann wenn A den Wert X hat, B den Wert Y haben muß. Diese Abhängigkeit nennt man funktional. Eine besondere Stellung hat der Identifikationsschlüssel: er ist ein Attribut (oder eine Attributskombination) von dem alle anderen Attribut einer Relation funktional abhängig sind. Besteht der Identifikationsschlüssel aus einer Attributkombination, so darf keines dieser Attribute von einem anderen Attribut des Identifikationsschlüssels abhängig sein. Von transitiver Abhängigkeit spricht man dann, wenn ein Attribut C von einem Attribut A derart abhängig ist, daß C funktional von einem Attrbut B abhängt, das seinerseits funktional von A abhängt.
Um in einem Modell eine möglichst geringe Redundanz (Wiederholung von abhängigen Daten) zu sichern, werden die Relationen normalisiert. Ziel der Normalisierung ist, die Attribute so zu Entitätsmengen bzw. Relationen zu ordnen, daß innerhalb einer Relation keine Redundanzen auftreten.
Zum Beispiel:
Eine Relation vor der Normalisierung
BEZEICHNUNG: DK Denotat BK Bereich Lemma Region Verwendung ---------------------------------------------1 [...] Handwerker 1 Berufsbez. Fleischhauer, Fleischhacker, Metzger oö / oö / wö 38,6 / 0 / 55,7
2 eine die putzt 1 Berufsbez. Bedienerin, Putzerin, Zugeherin oö / wö / wö 7,6 / 27,3 / 4,5
3 Tuch zum Putzen 2 Haushalt Fetzen, Putzlumpen oö / wö 14,5 / 34,8
4 eine Rübenart 3 Gemüse Karotte, Möhre, gelbe Rübe oö / oö / wö 79,7 / 1,4 /17,4
Man sieht, daß in manchen Attributen mehrere Werte
aufgeführt
sind.
Dies wird in der 1. Normalform beseitigt.
Erste Normalform
Eine Relation befindet sich in der 1. Normalform, wenn ihre Attribute
nur
einfach Attributwerte aufweisen. Mengen sind damit als Attributwerte
ausgeschlossen. Auch wenn nach dem ersten Normalisierungsschritt als
Werte noch
Wertemengen verwendet werden - ein häufiger Fehler bei der
Datenbankerstellung - können diese prinzipiell von der
Datenverwaltung
nicht mehr befriedigend angesprochen werden.
Obiges Beispiel sieht in der 1. Normalform so aus:
BEZEICHNUNG:Der Identifikationsschlüssel dieser Relation ist "Lemma". Die Relation enthält aber noch Redundanzen (z.B. "DK" und "Denotat", die in mehreren Tupeln gleiche Werte haben).DK Denotat BK Bereich Lemma Reg. Verwendung ------------------------------------------------------------------------
1 [...] Handwerker 1 Berufsbez. Fleischhauer oö 38,6 1 [...] Handwerker 1 Berufsbez. Fleischhacker oö 0 1 [...] Handwerker 1 Berufsbez. Metzger wö 55,7 2 eine die putzt 1 Berufsbez. Bedienerin oö 7,6 2 eine die putzt 1 Berufsbez. Putzerin wö 4,5 2 eine die putzt 1 Berufsbez. Zugeherin wö 27,3 3 Tuch zum Putzen 2 Haushalt Fetzen oö 14,5 3 Tuch zum Putzen 2 Haushalt Putzlumpen wö 34,8 4 eine Rübenart 3 Gemüse Karotte oö 79,7 4 eine Rübenart 3 Gemüse Möhre oö 1,4 4 eine Rübenart 3 Gemüse gelbe Rübe wö 17,4
Zweite Normalform
Eine Relation ist in der 2. Normalform, wenn sie in der 1. Normalform
ist und
jedes nicht zum Identifikationsschlüssel gehörige Attribut
voll von
diesem abhängig ist.
Um die Beispielrelation "BEZEICHNUNG" in die 2. Normalform zu bringen, muß sie in zwei Relationen aufgespalten werden (Identifikationsschlüssel fett).
DENOTAT-BEREICH: DK Denotat BK Bereich ------------------------------------Die Verbindung der Relationen erfolgt über das globale Attribut "DK". Von diesem unterscheiden sich alle anderen Attribute außer "Lemma" (Identifikationsschlüssel sind auch global), welche nur lokal sind, d.h. daß sie in nur einer Relation vorkommen und nicht zum Identifikationsschlüssel gehören. Zwar enthälten jetzt die Relation "LEMMA-VERWENDUNG" keine Redundanzen mehr, aber in der Relation "DENOTAT-BEREICH" ist "Bereich" von "BK" abhängig und "BK" vom Identifikationsschlüssel "DK" abhängig. Damit ist "Bereich" von "DK" transitiv abhängig. Dies bedeutet eine Redundanz, deren Eliminierung in die 3. Normalform führt.1 [...] Handwerker 1 Berufsbez. 2 eine die putzt 1 Berufsbez. 3 Tuch zum Putzen 2 Haushalt 4 eine Rübenart 3 Gemüse LEMMA-VERWENDUNG: DK Lemma Region Verwendung ------------------------------------
1 Fleischhauer oö 38,6 1 Fleischhacker oö 0 1 Metzger wö 55,7 2 Bedienerin oö 7,6 2 Putzerin wö 4,5 2 Zugeherin wö 27,3 3 Fetzen oö 14,5 3 Putzlumpen wö 34,8 4 Karotte oö 79,7 4 Möhre oö 1,4 4 gelbe Rübe wö 17,4
Dritte Normalform
Eine Relation befindet sich in der 3. Normalform, wenn sie in der 2.
Normalform
ist und kein Attribut, das nicht zum Identitfikationsschlüssel
gehört, transitiv von diesem abhängig ist.
Für die Beispielrelationen bedeutet dies, daß "DENOTAT-BEREICH" in zwei Relationen "DENOTAT" (DK, Denotat, BK) und "BEREICH" (BK, Bereich) aufgespalten werden muß.
DENOTAT: DK Denotat BK ---------------------------------Der Ablauf der Normalisierung kann wie folgt beschrieben werden (Wilke 1991:48):1 [...] Handwerker 1 2 eine die putzt 1 3 Tuch zum Putzen 2 4 eine Rübenart 3 BEREICH: BK Bereich -----------------
1 Berufsbez. 2 Haushalt 3 Gemüse
In obigem Beispiel werden nun in der 3. Normalform alle lokalen Attribute redundanzfrei gespeichert. Dies hat den Vorteil geringeren Platzbedarfs an Speicherkapazität und größerer Integrität der Daten, da die Werte in lokalen Attributen nur einmal eingegeben bzw. fallweise nur einmal verändert werden müssen. Diese Form entspricht dem klassischen Relationenmodell nach Codd. Ein Nachteil dieser Form ist es, daß Beziehungen zwischen Relationen bzw. Entitätsmengen nur implizit über globale Attribute ausgedrückt werden. Damit geht bei einer größeren Menge von Relationen rasch der Überblick verloren. Der Grund für diesen Nachteil liegt darin, daß im klassischen Relationenmodell bzw. im Zuge der Normalisierung jede Relation für sich betrachtet wird und keine Bedingungen für Beziehungen zwischen Relationen festgelegt werden können.
Dieses Problem läßt sich lösen, indem die Assoziationstypen zwischen Entitätsmengen miteinbezogen werden. Um in einer Relation ein Attribut zu bezeichnen, dessen Wert vom aktuellen Inhalt dieses Attributs in einer anderen Relation abhängt, wird der Begriff des Fremdschlüssels (foreign key) verwendet. Ein Fremdschlüssel in einer Relation R2 ist ein Attribut (oder eine Attributskombination), welches dem Identifikationsschlüssel in einer Relation R1 entspricht. Damit läßt sich eine hierarchische Beziehung zwischen Relationen definieren - sie besteht dann, wenn ein Attribut in R2 dort als Fremdschlüssel auf R1 basiert.
Zum Beispiel:
Zwischen den Relationen "BEREICH" und "DENOTAT" besteht eine hierarchische Beziehung, indem der Idendifikationsschlüssel "BK" aus "BEREICH" in "DENOTAT" als Fremdschlüssel verwendet wird. Es handelt sich um eine 1-m-Beziehung.
Aus den verschiedenen Typen von Assoziationen (vgl. oben) ergeben sich für Relationen verschiedene Beziehungstypen:
Hierarchische Beziehungen (1 - 1, 1 - c, 1 - m, 1 - mc, c - 1, m - 1, mc - 1)
Konditionale Beziehungen (c - c, c- m, c - mc, m - c, mc - c)
Netzwerkartige Beziehungen (m - m, m - mc, mc - m, mc - mc)
Nach dem "Entity-Relationsship Model" (Codd 1980) sind nur hierarchische Beziehungen zulässig. Konditionale und netzwerkartige Beziehungen müssen durch die Einführung von Hilfsrelationen in hierarchische Beziehungen trasnformiert werden.
Bei konditionalen Beziehungen muß eine zusätzliche Relation
eingeführt werden, um zu verhindern, daß kein Wert (c = 0)
zugeordnet wird.
Zum Beispiel:
DUDEN - ÖWB (Österreichisches Wörterbuch) (c - c) vor der Transformation:
DUDEN: Lemma gem. Eintrag -------------------------------------------------DUDEN - WORTSCHATZ (c - 1) / ÖWB - WORTSCHATZ (c - 1) nach der Transformation:Aal [a:l], der; -[e]s, -e; [...] Aal aalartig <Adj.; o. Steig.> [...] ? Aalfang, der [...] ? ÖWB: Lemma gem. Eintrag -------------------------------------------------
Aal der, -(e)s / -e [...] Aal aalglatt: sehr gewandt [...] aalglatt a.a.O = [...] ?
DUDEN: Lemma --------------------------------------Auch netzwerkartige Beziehungen bedürfen der Transformation, damit nur hierarchische Beziehungstypen vorkommen.Aal [a:l], der; -[e]s, -e; [...] aalartig <Adj.; o. Steig.> [...] Aalfang, der [...] ÖWB: Lemma --------------------------------------
Aal der, -(e)s / -e [...] aalglatt: sehr gewandt [...] a.a.O = [...] WORTSCHATZ: Wort DUDEN ÖWB -------------------------
Aal ja ja aalartig ja nein Aalfang ja nein Aalfischer ja nein a.a.O. nein ja
LEMMA: LK Lemma DK ----------------LEMMA - BEZEICHNUG (1 - m) / DENOTAT - BEZEICHNUNG (1 - m) nach der Transformation:1 Klinke 1 1 Klinke 2 2 Schnalle 3 2 Schnalle 1 2 Schnalle 4 2 Schnalle 5 DENOTAT: DK Denotat ---------------------------------------
1 hebelartiger Griff an einer Tür 2 Buchse im Fernmeldewesen 3 Verschluß an einem Gürtel 4 Prostituierte 5 weibliche Person, über die man sich ärgert
LEMMA: -----------LK Lemma 1 Klinke 2 Schnalle DENOTAT: DK Denotat ---------------------------------------
1 hebelartiger Griff an einer Tür 2 Buchse im Fernmeldewesen 3 Verschluß an einem Gürtel 4 Prostituierte 5 weibliche Person, über die man sich ärgert BEZEICHNUNG: LK DK ----------
1 1 1 2 2 1 2 3 2 4 2 5
Es läßt sich zwischen zwei Arten von Konsistenzbedingungen unterscheiden. Modellinhärente Konsistenzbedingungen sind solche Vorschriften über die Daten und die Beziehungen zwischen Daten, die durch das Modell - und damit durch die Datenbank selbst - in ihrer Benützung eingehalten werden müssen (z.B. Eindeutigkeit von Identifikationsschlüsseln, einmaliges Vorkommen von Tupeln, benutzerunabhängiges Aktualisieren von Fremdschlüsseln, Eingabebeschränkungen auf Werte innerhalb der Wertebereiche etc.). Modellexterne Konsistenzbedingungen sind solche Vorschriften über die Daten und die Beziehungen zwischen Daten, die über die modellinhärente Konsistenzbedingungen hinausgehen und in einer anderen Form - üblicherweise programmiert - sichergestellt werden müssen. Letztere Bedingungen können oftmals erst aufgestellt werden, nachdem die Datenbank im Rohentwurf formuliert ist - dadurch können neue Entitätsmengen und Relationen entstehen, die erst wieder normalisiert werden müssen usw. (Vgl. Kap. 4)
In einem ersten Schritt wird der Problemrahmen abgesteckt, die Aufgaben und Anforderungen an die Datenbank werden skizziert, die Daten der realen Welt, welche verarbeitet werden sollen, werden einer ersten Analyse unterworfen etc.
Dann werden Entitätsmengen gebildet, Attribute bleiben vorerst unbeachtet. Im Falle überlappender Entitätsmengen werden umfassender Entitätsmengen gebildet.
In einem weiteren Schritt werden die Beziehungen zwischen den Entitätsmengen festgehalten (eine graphische Darstellung kann helfen).
Jede Entitätsmenge erhält nun einen Identifikationsschlüssel. Aus diesen gehen die globalen Attribute hervor. Identifikationsschlüssel können "natürlich" oder "künstlich" sein: als Datum der realen Welt oder willkürlich.
Der nächste Schritt umfaßt die Eliminierung aller nicht-hierarchischen Beziehungen zwischen Entitätsmengen. Hilfsrelationen werden eingeführt, Rekursionen werden beseitigt. Als Ergebnis erhält man die normalisierten Beziehungen zwischen den Entitätsmengen.
Nun werden die lokalen Attribute festgelegt. Pro Entität und Attribut ist genau ein Attributwert zugelassen. Ansonsten müssen zusätzliche Entitätsmengen definiert werden.
Schließlich werden die Konsistenzbedingungen dargestellt.
Im letzten Schritt werden die Transaktionen, d. s. die Manipulationen an der Datenbank (vgl. unten), formuliert.
(Fast) jeder dieser Schritt kann dazu führen, daß das Schema neu durchlaufen werden muß:
3. Datenmanipulation
(Zehnder 1989: 110 ff.)
Unter Datenmanipulationen werden alle Operationen auf einer bestehenden Datenbank verstanden. Abfragen (query) sind Operationen, bei denen ein bestimmter Ausschnitt abgegrenzt und in geeigneter Form dargeboten wird. Mutationen oder Nachführungen (modification, update) sind Operationen, bei denen in einem bestimmten Ausschnitt der Inhalt von Daten verändert wird. Transaktionen sind solche Operationen, die die Konsistenz, die Wiederspruchsfreiheit einer Datenbank nicht beeinträchtigen.
Abfragen sind die häufigste Art der Datenmanipulation. Es sind sehr unterschiedliche Arten von Abfragen möglich (z.B. Adresse des Studenten mit der Matrikelnummer 8618648 in der zentralen Hörerevidenz des BMWF; wieviele stilistisch markierten Wörter sind in der nächsten Auflage des Österreichischen Wörterbuchs zu erwarten in einer Datenbank über das ÖWB).
Innerhalb der Möglichkeiten von Abfragen lassen sich vier Typen unterscheiden:
1) Der absolute Standort ist (über den Identifikationsschlüssel) bekannt. Die gewünschte Antwort läßt sich direkt ablesen (z.B. welches Buch hat die Inventarnummer 12.534).
2) Der relative Standort ist bekannt, etwa in einer geordneten Datei (z.B. Telefonnummer einer bestimmten Person in einem alphabetischen Telefonbuch).
3) Von einer erhaltenen Antwort will der Benutzer zu einer weiteren Antwort gelangen. Diese Art der Abfragen wird auch Navigation genannt (z.B. Anschlußzug nach Steyr in Attnang-Puchheim in einem Informationssystem der Bahn).
4) Die Antwort umfaßt mehrere Daten, d.h. es müssen zuerst Teilmengen abgegrenzt und dann ausgewertet werden (z.B. alle Wörter mit der Markierung "ostöst." im ÖWB).
Während in den Fällen (1) bis (3) jeweils nur ein Datensatz (Tupel) als Antwort benötigt wird, muß im Fall (4) aus der Menge der Daten eine Teilmenge verfügbar gemacht werden. Die Formulierung dieser Abfrage läßt sich in der Sprache der Mengenlehre fassen, d.h. deskriptiv, oder mittels bestimmter Datenbankaufrufe, d.h. prozedural.
Eine weitere Unterscheidung bei der Abfrage ist zwischen Datenauswahl und Datenausgabe zu machen. Unter Datenauswahl versteht man diejenigen Datensätze, die als Antworten einer Abfrage dienen; unter Datenausgabe das, was dem Benutzer tatsächlich präsentiert wird (z.B. Wieviele Bücher von Chomsky sind in der Bibliothek? Datenauswahl: Datensätze mit Autor, Titel, Jahr etc. Datenausgabe: Anzahl).
Bei Datenmanipulationssprachen (DML = Data Manipulation Language) kann zwischen selbständigen und eingebetteten oder zwischen deskriptiven und prozeduralen oder zwischen mengenorientierten und tupelorientierten Datenmanipulationssprachen unterschieden werden. Während selbständige Datenmanipulationssprachen alle für Manipulationen notwendigen Befehle enthalten, benötigen eigebettete Datenmanipulationssprachen den Zusammenhang mit einer höheren Programmiersprache (host language): sie sind Zusätze zum Standard der jeweiligen Programmiersprache. Mengenorientierte (auch: relationenorientiert) Datenmanipulationssprachen erlauben logische Mengenoperationen (Vereinigung, Durchschnitt etc.), tupelorientierte Datenmanipulationssprachen dagegen arbeiten auf einzelnen Tupeln (Datensätzen, records).
Neben Datenmanipulationssprachen gibt es auch Datendefinitionssprachen (DDL = Data Definition Language). Oft werden diese zwei Komponenten in einer Sprache zusammengefaßt.
(vgl Kap. 6.)
Als einziges Beispiel einer Datenmanipulationssprache soll hier auf SQL (Structured Query Language) eingegangen werden. SQL ist ein Entwicklung von IBM, die sich seit Mitte der 80er stark verbreitet hat und heute fast eine Art Standard für relationale Datenmanipulations- und -definitionssprachen darstellt (vgl. ausführlicher Albers 1994). SQL ist selbständig und eingebettet (z.B. in C, PL/I, COBOL, FORTRAN) oder als Schnittstelle in Datenbanksystemen in Verwendung. Die bekanntesten Datenbanksysteme, die SQL verwenden, sind DB/2 von IBM, Oracle, Sybase, Informix u.a.m. SQL ist weiters deskriptiv, mengenorientiert bzw. relational. SQL ist eine abbildungsorientierte Sprache, deren Grundkonzept es ist, daß die Daten von einem Definitionsbereich (Relation) aufgrund eines Auswahlkriteriums (boolescher Ausdruck: wahr / falsch) auf einen Bildbereich (Projektion) abgebildet werden.
Die Grundstruktur einer SQL-Abfrage hat folgende syntaktische Form:
select <Attributliste> Bildbereich, Projektion auf diese
Attribute
from <Relation(en)> Definitionsbereich, Relation(en)
where <Bedingung> Auswahlkriterium (kann auch leer
sein)
Dazu kommen noch logische Operatoren (and or not in),
Vergleichsoperatoren (= < <= > >= between..and..)
und
weitere mathematische Operatoren.
Einige Beispiele zu SQL
Als Beispieldatenbank:
BEREICH (BK, Bereich)
DENOTAT (DK, Denotat, BK)
LEMMA (LK, Lemma, Verwendung, DK, RK)
REGION (RK, Region)
Alle "Denotat" aus dem "Bereich" 1:
select Denotat -- Bildbereich
from DENOTAT -- Definitionsbereich
where BK = 1 -- Auswahlkriterium mit Konstante
Alle "Lemmata" zur "Bereich" 'Berufsbez.':
select Lemma
from LEMMA, DENOTAT, BEREICH
where BEREICH = 'Berufsbez.'
and BEREICH.BK = DENOTAT.BK
and LEMMA.DK = DENOTAT.DK
Eine Abfrage kann derart ziemlich komplex werden (Beispiel aus Retti
1993):
PREPARE :ARTIKELCTX: FROM SELECT DISTINCT
ARTIKEL.ARTNR,ARTIKEL.KRITIKER,ARTIKEL.TITEL,ARTIKEL.UNTERTITEL,
ARTIKEL.PERIODIKM,ARTIKEL.DATUM,ARTIKEL.JAHR,ARTIKEL.AGENTUR,
ARTIKEL.NOTIZ
FROM ARTIKEL
WHERE ARTIKEL.ARTNR IN
(SELECT DISTINCT ARTIKEL.ARTNR FROM ARTIKEL,ARTORD,ORDNUNG
WHERE ORDNUNG.ORDNUNGSWORT LIKE 'P%'
AND ARTORD.ORDNR=ORDNUNG.ORDNR
AND ARTIKEL.ARTNR=ARTORD.ARTNR
UNION
SELECT DISTINCT ARTIKEL.ARTNR FROM ARTIKEL,ARTAUT,AUTOR
WHERE AUTOR.NATION LIKE 'F'
AND ARTAUT.AUTNR=AUTOR.AUTNR
AND ARTIKEL.ARTNR=ARTAUT.ARTNR)
ORDER BY
UPPER(CONVERT(ARTIKEL.TITEL,'WE8ISO8859P1','WE8MACROMAN8'))
Neben der Möglichkeit zu Abfragen, bietet SQL auch einen
Befehlssatz zur
Mutation von Datensätzen (update delete insert).
Zum Beispiel:
Bei "LK" 7 soll "Verwendung" auf 25,4 geändert werden:
update LEMMA -- betroffene Relation
set Verwendung = 25,4 -- der neue Wert und das zu ändernde
Attribut
where LK = 7 -- Schlüsselwert des betroffenen Tupels
Eine neuer "Bereich" soll hinzugefügt werden:
insert
into BEREICH (BK, Bereich) -- Relation und Attribute
values (4, 'Werkzeug') -- einzufügende Werte
(Zehnder 1989: 175 ff.)
Jede Datensammlung und so auch jede Datenbank ist innerhalb kurzer Zeit unbrauchbar, wenn ihre Integrität nicht gewährleistet ist. Es lassen sich drei Bereich der Datenintegrität unterscheiden: Datenkonsistenz, bezogen auf die Eingabe von Daten, auf Manipulationen etc.; Datensicherheit, bezogen auf die physische Existenz der Daten auf Speichermedien, auf Sicherheitsduplikaten etc.; Datenschutz, bezogen auf die Verwendung von Daten, auf die Wirkung für den Betroffenen etc..
Die Anforderungen dieser Bereiche sind zum Teil widersprüchlich (z.B. Sicherheitskopien erhöhen die Datensicherheit und senken den Datenschutz). Auch können Maßnahmen zur Erhöhung der Datenintegrität die Effizienez der Datenbank schmälern.
Unterschieden werden kann zwischen primären Konsistenzbedingungen, insbesondere betreffend die logische Datendarstellung (z.B. Eindeutigkeit für den Identifikationsschlüssel einer Relation), und sekundären Konsistenzbedingungen, d.s. Bedingungen, die über mehrere Datenbankoperationen hinweg die Konsistenz sichern (wobei eine zeitweise Inkonsistenz zugelassen sein darf).
Ein Beispiel für eine sekundäre Konsistenzbedingung:
Die 1-m-Beziehung zwischen den Relationen "DENOTAT" und "BEREICH" (vgl.
oben)
enthält eine sekundäre Konsistenzbedingung, weil in "DENOTAT"
keine
Tupel (DK, Denotat, BK) eingefügt werden kann, bevor der
dazugehörende "Bereich" als Tupel (BK, Bereich) in der Relation
"BEREICH"
existiert. Umgekehrt muß jedem "Bereich" mindestens eine "Sache"
zugeordnet sein, damit die 1-m-Beziehung erfüllt ist, es kann also
kein
neues Tupel in "BEREICH" eingefügt werden, ehe eine
dazugehöriges
"Denotat" in "DENOTAT" vorhanden ist.
Konsistenzbedingungen können von einzelnen Attributen bis zu mehreren Tupeln in mehreren Relationen verschiedene Mengen von Datenobjekten betreffen:
Ein einzelnes Attribut: Prüfung auf den Wertebereich
und
Datentyp.
z.B. "Verwendung" in "LEMMA"; Prozentwerte : 0 bis 100
Ein einzelnes Tupel: Zusammenhänge zwischen
verschiedenen
Attributen des gleichen Tupels.
z.B. "Jahrgang" und "Studienbeginn" in einer Relation STUDENT ( Name,
Jahrgang,
Studienbeginn, ...);
"Jahrgang" < "Studienbeginn"
Ein Tupel als Teil einer Relation: Prüfung, ob ein Tupel mit diesem Identifikationsschlüssel schon existiert.
Ein Tupel als Teil einer
Datenstruktur:
Abhängigkeit bei hierarchischen Beziehungen, Fremdschlüsseln,
"referentielle Integrität"
z.B. bezüglich der Relationen "DENOTAT" und "BEREICH": existiert
ein
Bereich mit der "BK" 25?
Eine Relation (Menge von Tupeln): Bedingungen, z.B. Summen,
über
einen Teil der oder die gesamte Relation.
z.B. ist die Summe von "Verwendung" in "LEMMA" durch 100 ohne Rest
teilbar?
Mehrere Relationen: Allgemeine Verknüpfungen.
z.B. haben die Werte von "Verwendung" aus "LEMMA" zu einer "DK" aus
"DENOTAT"
die Summe 100, d.h. 100%?
Einen wichtigen Punkt zur Aufrechterhaltung der Konsistenz stellen daneben Fehlerreaktionen und Fehlermeldungen dar. Rückfragen beim Benutzer, Markierung inkonsistenter Daten etc. kommen hier zum Tragen.
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.
5. Entwicklung einer Datenbank
(Zehnder 1989: 210 ff.)
Die Entwicklung einer Datenbank und ihr anschließender Betrieb lassen sich unter sechs Punkte fassen:
1) Datenbankentwurf. (Vgl. Kap. 2.7) Eine nicht zu unterschätzende Bedeutung hat die Dokumentation und die Betriebsanleitung für eine Datenbank.
2) Erste Datenbeschaffung. Soll eine Datenbank völlig neu implementiert werden, müssen die Daten, ohne die eine Datenbank bedeutungslos ist, beschafft werden. Ein anderer Fall tritt dann ein, wenn ein älteres System entweder erneuert werden soll oder dessen Daten übernommen werden sollen. Geeignete Schritte zur Übernahme der Daten, Konversion derselben etc. sind zu erarbeiten.
3) Datenabfrage. (Vgl. Kap. 3.1)
4) Datenpflege. Mutationen und Korrekturen von Daten unter Berücksichtigung der Datenintegrität müssen gewährleistet sein.
5) Datenüberwachung. Die Datenintegrität verlangt in Abhängigkeit von der Sensibilität der verarbeiteten Daten die Überwachung des Betriebs, der Benutzer etc.. Weiters ist Fehlersituationen vorzubeugen.
6) Systemanpassung. Sollten sich die Rahmenbedingungen seitens der Benutzer oder der Computerkomponenten (Hard- und Software) ändern, müssen Verbesserungen und Anpassungen vorgenommen werden.
Diese sechs Punkte kommen mit mehr oder weniger ausgeprägtem Aufwand für jede Datenbank in Betracht:
Ausgehend von der Hardware, lassen sich weiter Betriebssystem, Datenbankverwaltungssystem (DBMS), Daten und Anwenderprogramme unterscheiden. Unter Anwenderprogrammen versteht man die in einer DML (= Data Manipulation Language) verfaßten Abfrage- und Manipulationsprogramme, die dem Benutzer zur Verfügung stehen (Benutzerschnittstelle, vgl 5.3).
Obgleich man meinen könnte, unter diesen Komponenten sei die Hardware der kostspieligste Teil, trifft dies - insbesondere für Datenbanken - üblicherweise nicht zu.
Die Kostenstruktur einer Datenbank für eine Großbibliothek könnte in etwa so aussehen:
Dies bedeutet eine Kostenverteilung von 15 : 3 : 1 für Daten : Anwenderprogramme : DBMS / OS / Hardware.
Der ausschlaggebende Faktor ist, daß die Daten einerseits zwar die langlebigste Komponente der Systems sind, andererseits aber normalerweise von bezahltem Personal bereitgestellt werden müssen. Auch hier spielt wieder die Möglichkeit, Daten (durch Konversion u.ä.) zu übernehmen, eine große Rolle. Bezüglich der Anwenderprogramme muß festgehalten werden, daß mit ihrer Spezialisierung auch die Aufwendigkeit der Erstellung zunimmt.
Im Zusammenhang mit der Minimierung der Kosten kann in manchen Fällen auf Standarddatenbanken zurückgegriffen werden, Datenbanken also, die für spezielle Anforderungen entwickelt wurden (z.B. Branchenlösungen wie Finanzbuchhaltung, Lagerverwaltung etc. oder Literaturdatenbanken). Solche Standarddatenbanken mit Anwenderprogrammen kommen besonders häufig im Microcomputerbereich vor:
Bei vielen Standarddatenbanken wird eine spezielle Datenmanipulationssystem, eine Art abgemagerte Datenmanipulationssprache (DML), mitgeliefert. Standarddatenbanken mit Datenmanipulationssystem erlauben die Entwicklung eigener einfacher Abfragen, die den Routinebedürfnissen genügen:
Große Datenbankanwendungen, die auch anspruchsvolle Aufgaben erfüllen sollen, werden bevorzugt in Standarddatenbanken mit eigenen Anwenderprogrammen realisiert. Das Datenmodell ist vorgegeben, die DML meist eingebettet in eine höhere Programmiersprache:
Völlig eigenentwickelte Datenbanken, d.h. DBMS und DML sind selbst programmiert, sind heute ziemlich selten. Ältere Datenbanken entsprechen öfter diesem Typ. Wichtig ist, daß die Schnittstelle zwischen Datenbankteil und Anwenderprogrammen klar gestaltet ist, entsprechend einer logischen Datenstruktur:
Folgende Grafik soll den Einsatzbereich von Datenbanksystemen unter Berücksichtigung der Komplexität der Datenstrukturen und der Menge der Daten veranschaulichen:
Die heute auf Mikrocomputern (PCs) zur Verfügung stehenden DB-Systeme sind für kleinere Datenbanken mit einfacher Struktur meist ausreichend. Typischerweise integrieren diese Systeme DBMS, DDL und DML in einem Programm. Oft existieren graphische Bendienungshilfen; automatisches Generieren von Eingabemasken und Ausgabelisten, Formluaren etc. ist möglich. Größere DB-Systeme sind heute zumeist nach dem Client/Server-Prinzip aufgebaut, d.h. die DBMS läuft auf einer leistungsstarken Maschine als Back-End und die Bedienung der Datenbank (DML, DLL) erfolgt von einem Arbeitsplatzrechner aus über ein Front-End.
Bei der Wahl eines Systems sollten einige Kirterien beachtete werden:
-- Datenmenge
Ist das System in der Lage, die voraussichtliche Datenmenge ausreichend schnell zu verarbeiten? Sehr nützlich ist in einem solchen Fall, wenn bereits Testdaten vorliegen.
-- Datenformat
Ist es ohne übertriebenen Aufwand möglich, die Daten in ein anderes System zu übernehmen? In manchen DB-Systemen ist der Export der Daten in einem Austauschformat nicht möglich.
-- Komplexität der Daten
Ist das System in der Lage, die Daten relational zu verarbeiten? Nicht alle DB-Systeme haben diese Eigenschaft. Wenn die Daten zu komplex sind, ist mit erheblichen Problemen zu rechnen, wenn versucht wird, diese in einer nicht-relationalen Struktur unterzubringen.
-- Anzahl der Benutzer
PC-Systeme sind für einen seriösen Netzwerkbetrieb mit mehreren gleichzeitigen Benutzern nur sehr eingeschränkt geeignet.
-- Entwicklungsaufwand
PC-Systeme erlauben oft ein sehr schnelles Erstellen von Datenbanken. Ihr Nachteil liegt in diversen Einschränkungen bei der Konsistenzprüfung, der Abfrage etc. Professionelle Systeme sind oft mit einem erheblichen Entwicklungsaufwand verbunden. Die Anpassung an geänderte Bedürfnisse kann bei einem einfachen System u.U. vom Benutzer selbst in kurzer Zeit durchgeführt werden, wohingegen bei Client/Server-Datenbanken oft ein Programmierer hinzugezogen werden muß.
6. Die wichtigsten SQL-Befehle
Folgende Aufstellung stellt eine bei weitem unvollständige Übersicht über die wichtigsten SQL-Befehle aus Weir 1992 dar.
Die Beschreibung hat folgende Struktur:
BEFEHL oder Befehlsblock
Syntax (bisweilen vereinfacht)
Beschreibung
Innerhalb der Syntaxbeschreibung bedeuten:
kleinbuchstaben -- Parameter
GROSSBUCHSTABEN -- Elemente der Sprache SQL
Normale Schrift -- Befehlsblock
[ | ] -- optionale Elemente; | dient als Trennzeichen, wenn
mehrere
Möglichkeiten gegeben sind
{ | } -- Auswahl erforderlicher Elemente; | dient als
Trennzeichen
... -- weitere Parameter derselben Art
kursiv Vorgabewert
COMMIT
COMMIT [ WORK ]
Änderungen permanent machen. Bis zur Eingabe von COMMIT
können
Änderungen mit ROLLBACK annuliert werden.
Column Element
column datatype [ Constraint Clause ]
Wird in CREATE TABLE zur Spezifikation der Datenfelder benötigt
Constraint Clause (Table)
[ { UNIQUE | PRIMARY KEY } ( column [ , colume] ... )
[ FOREIGN KEY ( column [ , colume] ... ) REFERENCES table [ ( column [
,
colume] ... ) ]
[ CHECK (condition) ]
Constraint Clause (Column)
column [ NULL ] | [ NOT NULL ]
[ CHECK (condition) ]
Constraint Clauses dienen dazu, bei der Datendefintion Bedinungen
einzuführen, Schlüssel zu definierten, für bestimmte
Datenfelder
bestimmte Einschränkungen vorzunehmen, Relationen zwischen
Tabellen
festzulegen und Überprüfungen zu definieren.
CREATE INDEX
CREATE [ UNIQUE ] INDEX index ON table ( column [ ASC | DESC ] [ ,
column [ ASC
| DESC ] ... ]
[ STORAGE Storageclause ]
Erzeugt eine Index über dem oder den Datenfeldern, wodurch der
Datenzugriff beschleunigt werden kann. Insbesondere wenn Relationen
über
ihr Schlüssel angesprochen werden, kann dies deutliche
Leistunsverbesserungen bringen.
CREATE SYNONYM
CREATE [ PUBLIC ] SYNONYM synonym FOR { table | view }
Erzeugt eine (öffentlich) zugängliches Synonym des
Datenbankobjekts.
Damit können bestimmte Daten anderen Benutzern zugänglich
gemacht
werden, ohne diesen etwa Benutzernamen oder Passwörter mitteilen
zu
müssen.
CREATE TABLE
CREATE TABLE table ( { Column Element | Contraint Clause } [ , { Column
Element
| Contraint Clause } ] ... )
[ STORAGE Storageclause ]
[ AS Query ]
Erzeugt eine Tabelle mit den angegebenen Felder. Mit der Query-Option
kann aus
einer oder mehreren bestehenden Tabellen eine neue erzeugt werden.
CREATE VIEW
CREATE VIEW view AS Query
Änlich wie ein Synonym kann auch eine View einen beliebigen
Datenausschnitt darstellen.
DELETE
DELETE FROM table [ WHERE condition ]
Löscht Datensätze aus einer Tabelle. Ohne WHERE-Zusatz werden
alle
Datensätze einer Tabelle gelöscht.
DROP INDEX
DROP INDEX index
Entfernt einen Index.
DROP SYNONYM
DROP [ PUBLIC ] SYNONYM synonym
Entfernt ein Synonym. PUBLIC muß angegeben werden, wenn es sich
um ein
PUBIC Synonym handelt.
DROP TABLE
DROP TABLE table
Löschte eine Tabelle mit allen Daten.
DROP VIEW
DROP VIEW view
Entfernt eine View.
INSERT
INSERT INTO table [ (column [ , column ] ... ]
{ VALUES ( value [ , value ] ... ) | Query }
Fügt einer Tabelle Datensätze hinzu, entweder als einzelner
Datensatz
(VALUE) oder auch mehrere, die über Query bestimmt werden.
RENAME
RENAME old TO new
Benennt eine Tabelle, eine View oder ein Synonym um.
ROLLBACK
ROLLBACK
Macht Änderungen (INSERT, UPDATE) rückgängig und zwar
bis zu dem
Punkt an dem letzmalig COMMIT eingegeben wurde.
SELECT
SELECT [ ALL | DISTINCT ] { * | table.* | expression } [ , { * |
table.*
| expression } ] ...
FROM table [ , table ] ...
[ WHERE condition ]
[ GROUP BY expression [ HAVING condition ] ]
[ { UNION | INTERSECT | MINUS } SELECT ... ]
[ ORDER BY { expression | position } [ ASC | DESC ]
... ]
Selektiert die spezifizierten Daten nach den spezifizierten
Bedingungen, wobei
* für alle Datenfelder steht. Bei Sortierung von durch
Mengenoperationen
selektierten Daten müssen die Datenfelder mittels Position
festgelegt
werden.
Storage Clause
STORAGE ( [ INTIAL integer ] [ NEXT integer ] [ PCTINCREASE integer ]
)
Mttels des Storage Clause wird festgelegt, wie die Daten gepeichert
werden.
Dies erfolgt in sogenannten Extents. Am günstigsten ist es alle
Daten
einer Tabelle in einem Extent zu haben. Wenn dieser voll ist, wird ein
neuer
mit der in NEXT angegebenen Größe angelegt. PCTINCREASE gibt
den
Prozentwert an, um den der jeweils nächste Extent
größer sein
soll als der vorhergehende. Da die Vorgabewerte bei einer neu
installiertn
Oracle-Datenbank hier sehr ungünstig sind (10 K für INITIAL
und NEXT,
PCTINCREASE 50 %), empfiehlt es sich, beim Anlegen von Tabellen einen
Storage
Clause zu spezifizieren.
UPDATE
UPDATE table SET column = expression [ , column = expression ] ...
[ WHERE condition ]
oder
UPDATE table SET ( column [ , column ] ... ) = ( Query)
[ WHERE condition ]
Ändern von vorhandenen Daten.
Query
D. i. ein SELECT-Ausdruck.
ALBERS, Stefan (1994): Datenlatein. Einführung in die Programmierung mit SQL/92. In: c't. magazin für computertechnik. Oktober 1994. S. 294-302.
ALBERS, Stefan (1994): Grammatikübung. Wichtige SQL/92-Befehle (Auswahl). In: c't. magazin für computertechnik. Oktober 1994. S. 304-306.
BÖRNER, Wolfgang (1990): Beziehungen sind alles. Was Sie schon immer über Datenbanksysteme auf dem Macintosh wissen wollten. In: MACWELT 4/5. S. 118 - 121.
CHEN, P. P. (1976): The Entity-Releationship-Model - Toward a Unified View of Data. ACM TODS, Vol. 1, No. 1. S. 9 - 36.
CHEN, P. P. (1980): Entity-Relationship Approacch to Systems Analysis and Design. Amsterdam.
CODD, E. F. (1970): A Relational Model for Large Shared Data Banks. In: Comm. ACM, Vol. 13, No. 6. S. 377 - 387.
CODD, E. F. (1972a): Further Normalization of the Data Base Relation Model. In: RUSTIN, R. u.a. (Hrsg.): Data Base Systems. Courant Computer Science Sysmposium 6, 1971. Engelwood Cliffs (NJ). S. 33 - 64.
CODD, E. F. (1972b): Relational Completeness of Data Base Sublanguages. In: RUSTIN, R. u.a. (Hrsg.): Data Base Systems. Courant Computer Science Symposium 6, 1971. Englewood Cliffs (NJ). S. 65 - 98.
DATE, C.J. (1981): An Introduction to Database Systems. 3ed Ed. Reading (MA).
DATE, C.J. (1983): An Introduction to Database Systems. Vol. II. Reading (MA).
GOLDBERG, Cheryl J. (1993): Object Oriented Databases. The New Wave in RDBMS Technology. In: Oracle Magazine. Vol VII. No. I. S. 35 - 39.
RETTI, Gregor (1994): Datenbanken I. Skriptum WS 1994/95. Innsbruck.
(http://info.uibk.ac.at/0hdb1.html)
RETTI, Radoslava (1993): Bericht zum Pilotprojekt: Einsatz von ORACLE als verteiltes System am Beispiel "Innsbrucker Zeitungsarchiv" des Instituts für Germanistik. Innsbruck.
SANDER, Holger (1995): Doppelte Sicherheit. Der Oracle Parallel Server in einem Sequent Cluster. In: iX. Multiuser Multitasking Magazin 2. S. 94 - 100.
SEITER, Charles (1990): The Multiuser Database Challenge. In: MACWORLD (May 1990). S. 316 - 322.
WEIR, Daniel (1992): SQL Language Reference. ORACLE for Macintosh Version 2.0. o.O.
WILKE, Hans D. (1991): ORACLE. Datenbankmanagment professionell. Design, Realisierung und Optimierung. 2. überarbeitete Aufl. Bonn München Reading Mass. u.a.
ZEHNDER, Carl August (1989): Informationssysteme und Datenbanken. 5., durchges. Aufl. Stuttgart. (= Leitfäden der angewandten Informatik)
Für weitere Titel siehe die Literaturangaben in Zehnder (1989).
Beispieldaten aus:
FORER, Rosa / MOSER, Hans (1988): Beobachtungen zum westösterreichischen Sonderwortschatz. In: WIESINGER, Peter (Hrsg.): Das österreichische Deutsch. Wien Köln Graz. S. 189 - 209.
RETTI, Gregor (1991): "Das Österreichische Wörterbuch" Entwicklung, Wortbestand, Markierungssysteme. Diplomarbeit. Innsbruck.