Kapitel 7 Datenbanken

Beim Anlegen einer Datenbank fallen nur wenige einfache Schritte an.
– Microsoft, Einführung in Windows XP

Eine der wichtigsten Rechneranwendungen ist die Speicherung, Verwaltung und Manipulation beliebiger Informationen. Diesen Verwendungszweck erfüllen Datenbanken. In diesem Kapitel werden zunächst die verschiedenen Arten von Datenbanken vorgestellt. Anschließend wird die Installation und die Anwendung der beliebten Open-Source-Datenbank MySQL behandelt. Danach erhalten Sie einen Überblick über die bedeutendsten Optionen und Funktionen der in den meisten Datenbanksystemen verwendeten Abfragesprache SQL. Als Beispiel für die Datenbankprogrammierung wird schließlich JDBC vorgestellt, eine allgemeine Schnittstelle für den Zugriff auf Datenbanken aus Java-Programmen.

Definition Datenbank

Zunächst ist es wichtig, genau zu definieren, was eine Datenbank eigentlich ist. Der Begriff bezeichnet nämlich zwei verschiedene Dinge: zum einen die Datensammlung selbst, zum anderen das Programm, das diese Daten verwaltet. Bei den Daten handelt es sich um eine nach bestimmten Regeln strukturierte Ansammlung von Informationen zu verschiedenen Themengruppen, beispielsweise Kundendaten von Unternehmen, Diagnose- und Behandlungsinformationen von Ärzten oder die CD-Sammlung eines privaten Musikfans.

Das Anwendungsprogramm, mit dem diese Daten verwaltet werden können, enthält mehr oder weniger mächtige Funktionen zum Suchen, Sortieren, Filtern und formatierten Ausgeben dieser Daten. Ein solches Programm wird als Database Management System (DBMS), also als Datenbankverwaltungssystem, bezeichnet.

Die Daten, die von einem DBMS verwaltet werden, lassen sich nach verschiedenen Kriterien unterscheiden – übrigens ein beliebtes Thema für IHK-Fragen, insbesondere im EDV-Bereich kaufmännischer Berufe.

Arten von Daten

Jedes Datum¹  , das in einer Datenbank gespeichert wird, ist Stammdatum oder Bewegungsdatum und gleichzeitig Rechendatum oder Ordnungsdatum. Die folgenden Definitionen können Ihnen helfen, diese Begriffe zu unterscheiden:

Stammdaten sind unveränderliche (oder zumindest selten veränderte) Informationen, die dauerhafte Auskunft über die Objekte oder Sachverhalte geben, die in der Datenbank gespeichert sind. Beispiele wären der Name einer Person oder die Bestellnummer eines Artikels.

Bewegungsdaten sind dagegen Informationen, die sich ständig im Fluss befinden und die Dynamik von Geschäftsabläufen und anderen Prozessen abbilden. Der Saldo auf einem Konto oder die Körpertemperatur eines Patienten sind gute Beispiele dafür.

Rechendaten sind Daten, die entweder selbst als Glied in einer Berechnung stehen oder aber als Berechnungsgrundlage dienen. Dazu gehören etwa Preise, Zinssätze oder gefahrene Kilometer.

Ordnungsdaten dienen dagegen der Einteilung, Klassifizierung und Filterung von Informationen. Zu den Ordnungsdaten zählen etwa Namen, Postleitzahlen oder KfZ-Kennzeichen.

Wichtig ist, wie bereits erwähnt, dass jedes Datum stets zwei der oben genannten Eigenschaften aufweist. Die folgende Liste zeigt Beispiele für jede der vier möglichen Kombinationen:

Stammdatum und Rechendatum sind beispielsweise der Preis einer Ware, das Grundgehalt eines Mitarbeiters oder der effektive Jahreszins eines Kredits.

Stammdatum und Ordnungsdatum sind etwa der Name eines Kunden, die Bestellnummer eines Artikels oder der Titel eines Buches.

Bewegungsdaten und Rechendaten sind zum Beispiel die Anzahl der abgeleisteten Überstunden eines Mitarbeiters, die Anzahl der gefahrenen Kilometer oder der aktuelle Wechselkurs für eine Fremdwährung.

Bewegungsdaten und Ordnungsdaten sind unter anderem das aktuelle Kalenderdatum, die Anzahl der Resturlaubstage eines Mitarbeiters oder die auf Lager befindliche Stückzahl eines Artikels.

7.1 Übersicht über Datenbanktypen 

Da Daten zu vielen verschiedenen Zwecken gespeichert werden müssen, existieren unterschiedliche Arten von Datenbanken. Das wichtigste Modell ist die relationale Datenbank, zu der auch das in diesem Kapitel ausführlich vorgestellte MySQL gehört. In diesem Abschnitt werden die verschiedenen Datenbanktypen vorgestellt. Dies sind im Wesentlichen folgende:

Einzeltabellendatenbanken dienen der einfachen Verwaltung von Daten eines bestimmten Typs, beispielsweise Anschriften oder Briefmarkensammlungen.

Relationale Datenbanken bieten die Möglichkeit, mehrere Einzeltabellen miteinander zu verknüpfen, um die Daten konsistent zu halten: Informationen, die an verschiedenen Stellen vorkommen, müssen nur einmal aufgeführt werden.

Objektorientierte Datenbanken arbeiten auf der Grundlage von Klassen und Objekten wie die objektorientierten Programmiersprachen C++ oder Java. Im Gegensatz zu relationalen Datenbanken sind sie in der Lage, sehr komplexe, nichtlineare Beziehungen zwischen den gespeicherten Informationen abzubilden.

Volltextdatenbanken sind nicht unbedingt ein eigener Datenbanktyp. Speziell geht es um die Implementierung einer effektiven Volltextsuche in vorhandenen Textarchiven. Inzwischen sind auch relationale und objektorientierte Datenbanken mit Volltext-Suchfunktionen ausgestattet.

XML-Datenbanken speichern die Informationen in Form von XML-Dokumenten ab. XML ist eine Metasprache für die Definition von Dokumentstrukturen und wird in Kapitel 15, XML, ausführlich behandelt.

Bild- und Multimedia-Datenbanken sind meist erweiterte relationale Datenbanken, die die Verwaltung von Mediadaten wie Bildern, Sounddateien oder Digitalvideos realisieren. In der Regel ermöglichen sie die Suche nach Media-Dateien auf den diversen Datenträgern sowie deren Katalogisierung nach verschiedenen Kriterien. Bekannte Beispiele sind Cumulus, das häufig von DTP- oder Presse-Profis eingesetzt wird, oder das kostengünstige Programm ThumbsPlus, das eher für kleine Büros oder Privatleute geeignet ist, die Ordnung in ihr Mediadaten-Chaos bringen möchten.

Neben diesen Grundtypen gibt es auch konkrete Datenbanksoftware, die verschiedene Misch- oder Übergangsformen bildet. Beispielsweise verwenden XML-Datenbanken oft keine reinen XML-Dokumente, sondern legen diese in einer relationalen Grundstruktur ab.

In den folgenden Unterabschnitten werden nur die Einzeltabelle, die relationale Datenbank und die objektorientierte Datenbank näher vorgestellt. Volltext- und Media-Datenbanken sind zu speziell und zu unterschiedlich, um sie allgemein zu beschreiben; die Behandlung von XML-Datenbanken ohne XML-Kenntnisse macht keinen Sinn. Wenn Sie XML dagegen im gleichnamigen Kapitel 15 erst einmal kennen gelernt haben, werden Sie XML-Datenbanken ganz von selbst verstehen.

7.1.1 Einzeltabellendatenbanken 

Die einfachste Datenbankart verwendet nur eine einzige Tabelle zur Abspeicherung aller Informationen. Die Einzeltabelle ist das Grundprinzip aller einfachen Adressverwaltungs- oder CD-Sammlungsprogramme. Die meisten Eigenschaften von Einzeltabellendatenbanken gelten auch für die professionelleren und erheblich vielseitigeren relationalen Datenbanken, schließlich handelt es sich bei Letzteren um eine Sammlung miteinander verknüpfter Einzeltabellen.

Datenfeld und Datensatz

In den Spalten einer Datenbanktabelle stehen die verschiedenen Informationskategorien. Die einzelnen Zellen werden Datenfelder genannt und sind die kleinste Informationseinheit der Datenbank: Sie enthalten je eine Einzelinformation über ein Element der Datenbank. Eine ganze Zeile ist die Kombination aller Informationen über ein Element und wird Datensatz (record) genannt. Übrigens wird das jeweilige Element, über das ein Datensatz Informationen enthält, als Entity (manchmal auch Entität) bezeichnet.

Hier sehen Sie ein Beispiel für eine Datenbanktabelle, die verschiedene Informationen über die Mitarbeiter eines Unternehmens enthält:

Von einer Einzeltabellendatenbank dürfen Sie nicht die komplexe Funktionalität eines relationalen DBMS erwarten, aber von den folgenden Grundfunktionen sollten Sie dennoch ausgehen können:

Sortieren der Tabelle auf- und absteigend nach einer beliebigen Kategorie (im Beispiel sind die Datensätze aufsteigend nach Namen sortiert). Eine absteigende Sortierung nach Gehältern würde beispielsweise die folgende Reihenfolge erzeugen: Huber, Juarez, Becker, Klein.

Suchen nach einem beliebigen Feldinhalt und Ausgabe der relevanten Datensätze. Beispielsweise würde die Suche nach dem Eintrittsjahr 1996 Frau Huber zurückgeben.

Einen Schritt weiter als die einfache Suche geht die Filterung der Tabelle. Dies bedeutet, dass nur noch diejenigen Zeilen angezeigt werden, die bestimmten Kriterien entsprechen. Beispielsweise enthielte eine Liste aller Mitarbeiter, die mehr als 4.000 EUR verdienen, nur noch Frau Huber und Herrn Juarez.

Darüber hinaus enthalten die meisten Einzeltabellendatenbanken je nach Verwendungszweck zahlreiche Formatierungsoptionen, um Eingabemasken oder ausdruckbare Berichte und Ähnliches zu erzeugen. Schließlich gibt es nicht allzu viele universelle Einzeltabellen-DBMS, sondern viel häufiger Programme, die für die Verwaltung einer bestimmten Datenart wie Adressen oder Musik-CD-Informationen geeignet sind.

Die Grenzen der Einzeltabelle

Wenn Sie eine Weile mit einer Einzeltabellendatenbank arbeiten, werden Sie feststellen, dass vor allem eine Einschränkung besonders nervt: Es gibt keine Möglichkeit, Inkonsistenzen auszugleichen. Wird beispielsweise die oben gezeigte Mitarbeitertabelle um fünf Kollegen erweitert, die alle in der Abteilung Verkauf arbeiten, dann gibt es keine Möglichkeit des Schutzes davor, dass der Name »Verkauf« in einem dieser fünf Datensätze falsch geschrieben wird. Daraus ergäbe sich natürlich eine vollkommen falsche Tabellenlogik mit Auswirkungen auf Such- und Filterfunktionen.

Noch schwieriger wird es, wenn Daten benötigt werden, die im Grunde gar nicht das Entity betreffen, das im Datensatz beschrieben wird, sondern zusätzliche Informationen über eines der anderen Felder enthalten. Beispielsweise könnten Sie es nützlich finden, neben der Abteilung auch deren Leiter zu erwähnen. Stellen Sie sich den Aufwand vor, wenn dieser Leiter wechselt oder die Probleme, wenn Sie den Namen irgendwo falsch schreiben.

Einzeltabellen sind also nur für ganz einfache Anwendungszwecke geeignet: Eine kleine Adress- oder Briefmarkensammlungsverwaltung geht gerade noch, während sämtliche Unternehmensanwendungen nur mit relationalen Datenbanken vernünftig funktionieren. Diese ermöglichen es nämlich, dass Sie verschiedene Arten von Daten jeweils in eigenständigen Tabellen ablegen und diese anschließend über Schlüssel miteinander verknüpfen.

7.1.2 Relationale Datenbanken 

Genau wie Einzeltabellen verwenden auch relationale Datenbanken ein Tabellenmodell zum Ablegen von Daten. Eine relationale Datenbank besteht allerdings aus beliebig vielen Einzeltabellen, die auf vielfältige Weise miteinander verknüpft werden können. Dieser Aufbau sorgt dafür, dass die Daten in der Datenbank konsistent sind: Jede Information muss nur ein einziges Mal gespeichert werden, sodass es nicht zu Mehrdeutigkeiten kommen kann.

Relationen

Die Verknüpfungen zwischen den Spalten einer Tabelle und zwischen den einzelnen Tabellen werden als Beziehungen oder Relationen bezeichnet und begründen die Bezeichnung »relationale Datenbank«. Eine Relation entsteht durch die Verwendung von Schlüsseln: Der Primärschlüssel des Datensatzes einer Tabelle wird als Wert in ein Feld einer anderen Tabelle eingetragen. Der Primärschlüssel ist ein spezielles Datenfeld oder eine Kombination der Werte mehrerer Felder, die innerhalb der Tabelle einen einmaligen Wert besitzen und den Datensatz somit eindeutig kennzeichnen. Der Primärschlüssel einer Tabelle, auf den in einer anderen Tabelle verwiesen wird, heißt dort Fremdschlüssel.

Der Primärschlüssel ist übrigens ein Sonderfall eines so genannten Indexes. Indizes ermöglichen den schnellen Zugriff auf bestimmte Tabelleninhalte, indem sie die Informationen einer Datenbankspalte separat in geordneter Form abspeichern. Um einen Datensatz anhand eines indizierten Felds zu finden, muss nicht die gesamte Datenbanktabelle sequenziell durchsucht werden.

Relationsarten

Es gibt drei verschiedene Arten von Relationen, die je nach Art der gespeicherten Information nützlich sind:

Eine 1:1-Relation verknüpft einen Datensatz einer Tabelle mit genau einem Datensatz einer anderen Tabelle. Dies ist immer dann nützlich, wenn bestimmte Informationsaspekte über ein Entity nicht so oft benötigt werden wie andere Aspekte. Die seltener oder in einem anderen Zusammenhang verwendeten Informationen lassen sich auf diese Weise einfach ausblenden. Beispielsweise könnte eine Tabelle Informationen über angebotene Artikel wie Bezeichnung, Preis und Mehrwertsteuersatz enthalten, eine andere dagegen den Lagerbestand.

Eine 1:n-Relation oder Eins-zu-vielen-Relation verbindet einen Datensatz einer Tabelle mit beliebig vielen Datensätzen einer anderen Tabelle. Dies ist der häufigste und nützlichste Verknüpfungstyp, weil er den größten Beitrag zur Vermeidung von Inkonsistenzen leistet: Detailinformationen über Werte, die in einer Spalte einer Tabelle beliebig oft vorkommen können, werden in einer separaten Tabelle erfasst. Die erste Tabelle enthält in dem entsprechenden Feld nur noch einen Verweis auf einen bestimmten Datensatz der zweiten Tabelle.

Eine m:n-Relation, auch Viele-zu-vielen-Relation genannt, kombiniert beliebig viele Vorkommen eines bestimmten Wertes mit beliebig vielen Vorkommen eines anderen. Stellen Sie sich beispielsweise eine Tabelle vor, die eine Liste lieferbarer Waren enthält, und eine weitere Tabelle, in der die Adressen von Kunden erfasst werden. Jeder Artikel kann von beliebig vielen Kunden gekauft werden, und jeder Kunde kann beliebig viele unterschiedliche Artikel kaufen. Das relationale Datenbankmodell verlangt allerdings, dass diese Art von Relation indirekt dargestellt wird: Eine dritte Tabelle listet die einzelnen Kaufaktionen auf; jeder Datensatz enthält dabei eine Verknüpfung zu einem bestimmten Kunden und eine weitere zu einem einzelnen Artikel. Jede dieser Relationen für sich ist eine 1:n-Beziehung; die m:n-Beziehung zwischen Kunden und Artikeln besteht nicht direkt.

Ein einfaches Beispiel

Das unter den m:n-Beziehungen angedeutete Beispiel soll im Folgenden konkret ausgeführt werden: Eine Tabelle enthält Daten über Käufer, die zweite Informationen über die Artikel und die dritte listet jeden einzelnen Kauf auf. Die Beziehung zwischen den drei Tabellen ADRESSEN, ARTIKEL und KAEUFE wird in Abbildung 7.1 dargestellt.

Das oberste, fett gesetzte Feld jeder Tabelle ist der Primärschlüssel. Die Tabelle ADRESSEN enthält die Kundendaten mit dem Primärschlüssel NR. ARTIKEL hat den Primärschlüssel ARTNR (Artikelnummer). KAEUFE schließlich verwendet einen Primärschlüssel namens KAUFNR. Da keine andere Tabelle auf einzelne Käufe zugreift, benötigt die Tabelle momentan eigentlich keinen Primärschlüssel.

Die Beschriftung an den kleinen Rauten, von denen die Relationen ausgehen, zeigen den Relationstyp an. Beide Relationen in der Datenbank sind 1:n-Relationen. Die m:n-Relation zwischen den Tabellen ADRESSEN und ARTIKEL kann natürlich nicht eingezeichnet werden, weil sie nur indirekt besteht.

Konkret kann die Tabelle ADRESSEN zum Beispiel mit folgenden Werten gefüllt werden:

Natürlich müssen Sie die Kunden nicht durchnummerieren, sondern können sich Ihr eigenes individuelles Schema für Kundennummern ausdenken. Wichtig ist lediglich, dass jede dieser Nummern nur ein einziges Mal in der Tabelle vorkommt und dass jeder Kunde eine Nummer bekommt.

Die Tabelle ARTIKEL enthält Informationen über die angebotenen Artikel. Beachten Sie, dass das Feld MWST nicht etwa einen konkreten Wert enthält, sondern den Mehrwertsteuersatz, also den Wert 7 oder den Wert 16. Noch praktischer wären allerdings 1:1-Relationen zu einer weiteren Tabelle, die die konkreten Mehrwertsteuersätze enthält. Schließlich können sich diese ändern. Die Tabelle könnte die folgenden Datensätze enthalten (die Preise werden aus weiter unten erläuterten Gründen in Cent angegeben):

Nachdem diese beiden Tabellen eingerichtet sind, können nun Käufe getätigt werden. In der Tabelle KAEUFE könnten etwa die folgenden Geschäftsvorfälle erfasst werden:

Auswahlabfragen

Die Einträge in der Tabelle KAEUFE sind in dieser Form für Menschen so gut wie unlesbar. Es geht auch gar nicht darum, sie in einer Form zu verwahren, in der sie sofort lesbar sind, sondern darum, die Daten redundanzfrei und kompakt zu speichern. Für die lesbare Ausgabe beherrscht jedes relationale Datenbankverwaltungssystem (RDBMS) so genannte Auswahlabfragen, mit deren Hilfe Sie aufgrund der Relationen Daten aus verschiedenen Tabellen zusammenstellen können.

Tabelle 7.5 zeigt das Ergebnis einer solchen Auswahlabfrage. Hier werden die Käufe mit den eigentlichen Kunden- und Artikelnamen aufgeführt, alphabetisch nach Kunden und anschließend alphabetisch nach Artikelbezeichnungen sortiert. Damit Sie das Ergebnis nachvollziehen können, wird die Kaufnummer aus der Tabelle KAEUFE übernommen. Die letzte Spalte enthält den errechneten Gesamtpreis für jeden einzelnen Kauf (das Produkt aus Stückzahl und Einzelpreis).

Bitte beachten Sie, dass die Ergebnisse von Auswahlabfragen normalerweise nicht abgespeichert werden. Schließlich basieren sie auf Daten, die sich durch die nachträgliche Änderung oder Ergänzung von Datensätzen in den zugrunde liegenden Tabellen jederzeit ändern können.

Die meisten relationalen Datenbanksysteme verwenden für Abfragen eine standardisierte Sprache namens SQL (Structured Query Language). Diese Abfragesprache wird weiter unten in einem eigenen Abschnitt vorgestellt.

Normalisierung

Das wichtigste Ziel beim Erstellen relationaler Datenbanken ist – wie bereits erwähnt – die Beseitigung von Redundanzen zur Vermeidung von Inkonsistenzen. Dieser Vorgang wird als Normalisierung der Datenbank bezeichnet. Insgesamt sind fünf, eigentlich sogar sechs so genannte Normalformen definiert, die aufeinander aufbauen und schrittweise den Weg zu einem fertigen relationalen Datenbankmodell weisen:

Die erste Normalform (1NF) verlangt, dass die Information in jedem Feld einer Datenbank atomar ist, das heißt eine nicht weiter zerlegbare Einzelinformation. Eine Spalte wie PLZ_ORT oder STRASSE_HAUSNR würde beispielsweise dagegen verstoßen.

Die zweite Normalform (2NF) fordert zusätzlich, dass Datensätze nur direkte Informationen über ein und denselben Sachverhalt enthalten. Formal gesagt dürfen alle Felder in einer Tabelle, die die zweite Normalform erfüllt, nur vom Primärschlüssel dieser Tabelle abhängen. Beispielsweise dürfte dieselbe Person in einer Kundentabelle nicht zweimal aufgenommen werden, weil sie zwei Wohnsitze hat. In diesem Fall müssten die Wohnorte in eine separate Tabelle geschrieben werden; der Bezug auf die Kunden müsste in dieser Tabelle als Fremdschlüssel eingetragen werden.

Die dritte Normalform (3NF) ist erfüllt, wenn alle Felder funktional unabhängig voneinander sind. Der Unterschied zur zweiten Normalform erscheint geringfügig. Eine Tabelle, die zwar die zweite, aber nicht die dritte Normalform erfüllt, belässt eine eindeutig zu einem bestimmten Feld gehörige Zusatzinformation innerhalb einer Tabelle, in der dieses Feld keinen Schlüssel bildet. Beispielsweise hat in der Personaltabelle einer Unternehmesdatenbank, in der in einem Feld die Abteilung eines Mitarbeiters steht, der Name des Abteilungsleiters nichts zu suchen, weil er nur von der Abteilung, aber nicht vom Mitarbeiter abhängt.

Die Boyce-Codd-Normalform (BCNF), benannt nach Pionieren des relationalen Datenbankmodells, ist eine strengere Variante der dritten Normalform. Eine Tabelle, die sich in der dritten Normalform befindet, kann die BCNF nur dann verletzen, wenn der Primärschlüssel aus mehreren Feldern zusammengesetzt ist, und der Wert irgendeines Felds nicht vom gesamten Primärschlüssel, sondern nur von einem seiner Felder abhängt. Um die Boyce-Codd-Normalform zu erreichen, muss eine solche Tabelle in zwei Einzeltabellen aufgeteilt werden, die jeweils eines dieser Felder als Primärschlüssel aufweisen.

Die vierte Normalform (4NF) betrifft so genannte mehrwertige Abhängigkeiten (multi-valued dependencies). Eine mehrwertige Abhängigkeit liegt vor, wenn eine Beziehung zwischen verschiedenen Informationen nicht so in zwei Tabellen unterteilt werden kann, dass eine 1:n- oder die umgekehrte n:1-Relation entsteht.

Die fünfte Normalform (5NF) erfordert schließlich, dass innerhalb einer Tabelle nur triviale Join-Abhängigkeiten existieren dürfen. Eine Join-Abhängigkeit besteht in jeder Tabelle, die sich in mehrere Einzeltabellen aufteilen ließe, indem derselbe Schlüssel jeweils auf einzelne Spalten der Tabelle angewandt wird. Trivial ist eine Join-Abhängigkeit dann, wenn durch eine Verknüpfung zweier solcher Einzeltabellen keine Redundanz durch einen verdoppelten Datensatz vorkommen würde.

Normalisierung schon beim Datenbankentwurf

Die Bezeichnung Normalisierung könnte als kontinuierlicher Prozess missverstanden werden, der auf eine bereits bestehende Datenbank angewendet wird. In Wirklichkeit müssen Sie sich bereits bei der Datenbankmodellierung Gedanken darüber machen, also bevor Sie eine Datenbank einrichten.

7.1.3 Objektorientierte Datenbanken 

Trotz der soeben besprochenen Normalisierung lassen sich gewisse komplexe Datenstrukturen nur unzureichend mit Hilfe einer relationalen Datenbank modellieren. Aus diesem Grund wurde das objektorientierte Datenbankmodell eingeführt, das eine völlig freie und beliebige Strukturierung der Daten ermöglicht. Eine objektorientierte Datenbank besteht aus Klassen und Objekten und ähnelt damit der objektorientierten Programmierung, die in Kapitel 5, Grundlagen der Programmierung, erläutert wird.

Grenzen der RDBMS

Ein gutes Beispiel für ein Gefüge, das sich durch relationale Modellierung nicht vernünftig darstellen lässt, wären Verbindungen und Entfernungen zwischen verschiedenen Orten, wie sie beispielsweise für ein Speditionsunternehmen benötigt werden. Tabelle 7.7 unternimmt dennoch den Versuch, diese Informationen nach relationalem Muster darzustellen.

Diese Tabelle ist aus verschiedenen Gründen ungeeignet. Erstens enthalten zwei Spalten Informationen der gleichen Art; es gibt kein Kriterium, das bestimmt, welche Stadt unter VON_ORT aufgeführt wird und welche unter NACH_ORT. Die Darstellung der Entfernung in beide Richtungen ist auch keine Alternative, weil es dadurch zu Redundanzen käme. Durch die Normalisierungsregeln für relationale Datenbanken lässt sich dieses Modell nicht weiter verbessern.

Übrigens ist es auch keine Lösung, die durchaus relational darstellbaren Entfernungen von einer bestimmten Stadt zu allen anderen zu verwenden. Dies verhindert nämlich die Aufnahme günstigerer Verbindungen in die Datenbank. Angenommen, eine Tabelle listet die Entfernungen von Köln zu den anderen Städten auf. Sicherlich würde niemand, der von Hamburg nach Berlin muss, den Umweg über Köln wählen.² 

Mit Hilfe der objektorientierten Modellierung ist die Darstellung dieser Entfernungen dagegen ein Leichtes. Hier lässt sich eine Klasse namens Ort einrichten, die einfach ein Array von Zielen enthält, zu denen Verbindungen bestehen.

ODL

Es gibt verschiedene Sprachen, in denen sich objektorientierte Datenbanken formulieren lassen. Einige Lösungen verwenden die Syntax objektorientierter Programmiersprachen wie C++, während andere Systeme ihre eigenen Sprachen benutzen. Einen allgemeinen Standard für objektorientierte Datenbankverwaltungssysteme (OODBMS), wie ihn SQL für relationale Datenbanken bildet, gibt es noch nicht. Dennoch arbeitet ein Gremium namens Object Database Management Group (ODMG) an einer solchen Standardisierung; eine einigermaßen verbreitete Objektmodellierungssprache ist die von dieser Gruppe definierte Object Definition Language (ODL).

Eine übergeordnete Datenstruktur, am ehesten vergleichbar mit einer Tabelle in einer relationalen Datenbank, wird durch eine Klasse gebildet, deren Definition das Schlüsselwort class einleitet. Eine Informationskategorie, die in etwa einer Spalte in einer relationalen Datenbanktabelle entspricht, wird durch das Schlüsselwort attribute, die Angabe eines Datentyps und eine Bezeichnung eingerichtet. Das folgende Beispiel entspricht der weiter oben dargestellten relationalen Tabelle ADRESSEN:

class Adressen {
   attribute long Nr;
   attribute string Name;
   attribute string Strasse;
   attribute short Hausnr;
   attribute short Plz;
   attribute string Ort;
}

Die atomaren Datentypen string, long und short sollten sich von selbst erklären. Es existieren keine separaten Typen für ganzzahlige und für Fließkommazahlen. Eine objektorientierte Umsetzung der Tabelle ARTIKEL sieht folgendermaßen aus:

class Artikel {
   attribute long ArtNr;
   attribute string ArtName;
   attribute long Preis;
   attribute short MWSt;
}

Eine Beziehung wird in der ODL durch das Schlüsselwort relationship dargestellt. Da jeder Datensatz ein Objekt einer Klasse ist, müssen Sie nicht mit Schlüsseln arbeiten, sondern können ein Objekt dieser Klasse direkt referenzieren. Die Darstellung der Tabelle in einer OO-Datenbank lautet demnach:

class Kaeufe {
   attribute long KaufNr;
   relationship Adressen Kunde;
   relationship Artikel Ware;
   attribute short Stueck;
   attribute struct Datum {
      short Tag;
      short Monat;
      short Jahr;
   } KaufDatum;
}

Der Datentyp struct bietet die Möglichkeit, eine nichtatomare Information als verschachtelte Gruppe einzufügen. Dies garantiert im vorliegenden Fall die leicht handhabbare Darstellung eines Datums. Die Syntax für struct entspricht dabei dem in der Programmiersprache C üblichen Standard: Vor der öffnenden geschweiften Klammer steht der Datentypname der Struktur, hinter der schließenden wird ein konkretes Element dieses Typs deklariert.

Die ursprüngliche Aufgabe, die Entfernungstabelle darzustellen, lässt sich mit Hilfe der ODL-Syntax recht einfach lösen:

class Ort {
   attribute string Name;
   struct Entfernung {
      relationship Ort Zielort;
      attribute short Kilometer;
   };
   array (struct Entfernung) Entfernungen;
}

Ein array ist – wie in Programmiersprachen – eine Liste beliebig vieler Elemente eines bestimmten Datentyps. In diesem Fall wird eine Entfernung als Struktur aus einer Verknüpfung mit einem Ort und der Kilometeranzahl gebildet. Die entsprechenden Entfernungen werden in einem Array dargestellt.

Um objektorientierte Datenstrukturen mit Werten zu füllen und um diese Werte später nach verschiedenen Kriterien zu lesen und auszuwerten, wird eine zweite Sprache benötigt. Die von der ODMG vorgeschlagene Version einer solchen objektorientierten Abfragesprache heißt OQL (Object Query Language). Sie verwendet weitgehend dieselben Befehle und die gleiche Syntax wie die weiter unten vorgestellte relationale Abfragesprache SQL.