2. Objektorientierte Datenbanken

RDBMS vs. ODBMS

Eines der wohl zur Zeit nach wie vor populärsten Wörter im Bereich der Datenverarbeitung ist "Objektorientiertheit". Zweifelsohne handelt es sich dabei um einen Begriff, der nun mittlerweile seit über 10 Jahren nichts an Bedeutung verloren hat. Doch nicht alles was als "objektorientiert" bezeichnet wird ist es auch tatsächlich.

Manche Leute sind beispielsweise der Ansicht, dass sich alles was über eine graphische Oberfläche verfügt, einen C++ - Compiler oder - im Bezug auf Datenbanken - BLOBs (Binary Large Objects) verwendet bereits hinreichend als objektorientiertes System qualifiziert.

Die Frage die sich uns nun stellt ist: was macht ein objektorientiertes System aus und, im Bezug auf diese Arbeit selbstverständlich vorrangig, wo liegen die Vorteile eines solchen Systems in Bezug auf Datenbanken.

Wir wollen nun, in Zuge dessen, die Hauptmerkmale von relationalen Datenbanken denen von objektorientierten Datenbanken gegenüberstellen.

Zweifelsohne besteht einer der Hauptvorteile von relationalen Datenbanken darin, dass sie über eine logische Unabhängigkeit der Daten vom eigentlichen Speicherungsverfahren verfügen. Die so gespeicherten Daten können mittels SQL (Structured Query Language) - Statements plattformunabhängig bearbeitet und abgefragt werden. SQL ist mittlerweile auf allen Plattformen verfügbar.

Ein gravierender Nachteil an relationalen Datenbanken ist jedoch, dass sie ausschließlich über flache Tabellen mit atomaren Feldern ohne semantischen Zusammenhang verfügen (was in folgendem Beispiel veranschaulicht werden soll).

Beispiel

Verwaltet werden soll eine Personendatenbank. Jede Person soll über einen Namen, mehrere Vornamen und mehrere Adressen verfügen.

Ein möglicher Ansatz für die Realisierung in einer relationalen Datenbank wäre nun der folgende:

Später soll diese Datenbank um Kunden und Lieferanten erweitert werden, die eine Sonderform von Personen darstellen.

Zunächst aber zu den bereits in dieser schlichten Datenbank vorherrschenden Eigenschaften:

• jeder zusätzliche Eintrag in dieser Struktur bedeutet, dass mindestens 2 neue Datensätze hinzugefügt werden müssen (einer in PERSON und einer in ADRESSE)
• jede Suche nach einer bestimmten Person (und deren Eigenschaften) bedeutet eine Selektion in 2 Tabellen (zunächst in PERSON, dann mit PERSON.ID in ADRESSE)

Um diese Datenbank nun in oben angesprochener Form zu erweitern, hat man 2 Möglichkeiten. Entweder

1. man fügt PERSON ein zusätzliches Feld hinzu (=Flag), dass aussagt, ob es sich bei der gefundenen Person um einen Kunden, einen Lieferanten oder um eine x-beliebige Person handelt oder
2. man fügt der Datenbank zwei zusätzliche Tabellen - KUNDE und LIEFERANT - hinzu, die ihrerseits wieder mittels Fremdschlüssel auf die Tabelle PERSON verweisen

Beide Versionen haben gravierende Schwachstellen.

In Variante a) müssen alle Anwendungsprogramme dahingehend geändert werden, dass von nun an in PERSON auch zusätzliche, "spezielle" Personen - nämlich auch Kunden und Lieferanten - gespeichert werden.

In Variante b) erhöht sich nun der Aufwand um Informationen eines Kunden abfragen zu können von dem ursprünglichen Zugriff bei Person auf 2 Tabellen auf 3 Tabellen. Beim Einfügen eines Kunden müssen mittlerweile ebenfalls 3 Datensätze neu erzeugt werden.

Jede Erweiterung bzw. jedes hinzufügen komplexer Elemente führt zu einer eigenständigen Tabelle, die mit einer Relation verbunden werden muß.

Das gleiche Szenario für objektorientierte Datenbanken sieht nun folgendermaßen aus:

Klasse PERSON (mit beliebiger Menge von Vornamen und Adressen)

Jede Person kann mittels eines einzigen Befehls (inklusive ihrer semantischen Verknüpfungen) geladen, verändert oder neu kreiert werden.

Oben angeführte Erweiterung kann schlicht dadurch erreicht werden, dass zwei neue Klassen - KUNDE und LIEFERANT - erstellt werden, die von PERSON abgeleitet werden.

Diese (abgeleiteten) Klassen sind nun ihrerseits wieder mit einem einzigen Befehl speicher- und ladbar. Die Objekte werden sowohl der Basismenge aller Personen als auch der Menge der abgeleiteten Klassen zugeordnet.

» trotz steigender Komplexität der Datenstruktur erfordert dieser Ansatz keinen Mehraufwand für Design und Implementation.

Gegenüberstellung RDBMS - ODBMS