Folge 12: „Objektorientierte Datenbanksysteme„ 1. Stärken

IT-Kompaktkurs Datenbanken
Folge 12:
„Objektorientierte Datenbanksysteme„
Prof. Bernd Breutmann
Fachhochschule Würzburg-Schweinfurt
Studiengang Informatik
Münzstrasse 12
97070 Würzburg
email: [email protected]
„Objektorientierte Datenbanksysteme“- das ist zunächst ein Sammelbegriff für neue
Konzepte für Datenbanksysteme, die die bisherige relationale Datenbanktechnik zum
Teil evolutionär weiterentwickeln, zum Teil aber auch revolutionieren.
Wofür brauchen wir neue Datenbankkonzepte? Wie sehen die neuen Konzepte aus?
Wie entscheide ich, ob ich für meine Anwendung oder mein Unternehmen das alte
erfolgreiche relationale Modell oder ein anderes einsetzen soll? Auf diese Fragen sollen
Antworten gegeben werden. Aber sehen wir uns doch zunächst einmal an, welche
besonderen Qualitäten wir denn mit den relationalen Datenbanken bisher kennengelernt
haben.
1.
Stärken und Grenzen relationaler Systeme
Die relationalen Datenbanksysteme haben innerhalb der letzten 30 Jahren einen
beachtlicher Stand erreicht. Sie sind die zur Zeit am weitesten verbreiteten
Datenbanksysteme, die mit einem Marktvolumen von ca. 8 Mrd. USD Umsatz pro Jahr
den Markt beherrschen. Das relationale Datenmodell, 1970 von Codd eingeführt, hat
sich in der Praxis etabliert und zugleich der Datenbankforschung entscheidende Impulse
gegeben.
Warum soll sich an diesem erfolgreichen Konzept etwas ändern ?
Eine Evolution findet immer dann statt, wenn ein System entweder grundsätzlich
Schwächen aufweist, oder wenn sich die Umweltbedingungen grundlegend verändern.
Für die relationalen Systeme trifft beides zu. Zunächst einmal war es erfolgreich, weil
es einfach war: Flache Strukturen, Tabellen mit einfachen Attributen, kann jeder
verstehen und lesen. Außerdem ist das relationale Datenmodell in der Mengentheorie
der Mathematik begründet. Daraus folgt, daß auf den relationalen Strukturen eine
mengenorientierte, mächtige Zugriffssprache SQL definiert werden konnte. Damit kann
1
jedermann Datenbankzugriffe einfach hinschreiben. Eine weitere Konsequenz ist, daß
der Datenbankentwurf theoretisch fundiert werden konnte. Die Normalformen liefern
eine verläßliche Aussage darüber, von welcher Qualität ein Datenbankentwurf ist.
Einfache Strukturen
ANGESTELLTE
NameGehaltAbteilung...
ABTEILUNG
Abt_NameBudget...
Deskriptive Zugriffsprache
SELECT Name, Gehalt
FROM ANGESTELLTE
WHERE Abteilung = “EDV“;
Systematischer Datenbankentwurf
Der Erfolg des relationalen Datenmodells und liegt in seiner mathematischen
Fundierung und in seiner Einfachheit. Die relationalen Datenbanksysteme zeigen ihre
Stärke,
• wenn es um die Verwaltung einfacher numerischer oder zeichenbasierter Daten geht
(zum Beispiel Adressdaten oder Personendaten)
• bei sogenannten Ad-hoc-Anfragen, d.h. wenn ich den Datenbestand mal mit
einfachen Anfragen bearbeiten will
• im Mehr-Benutzer-Betrieb, wenn die Datenbankbenutzer die Tabellen mit kurzen
Transaktionen verändern wollen.
In der Einfachheit liegen aber auch die Grenzen relationaler Systeme. Datenbanken
bilden den Informationshaushalt eines Unternehmens oder einer Anwendung ab.
Personaldatenbanken zum Beispiel bilden das Personalwesen eines Unternehmens ab
mit all seinen Strukturen und Regeln. Die Datenbank ist somit das virtuelle Abbild des
Unternehmens oder eines Teils des Unternehmens. Die Strukturen und Regeln eines
solchen Informationshaushalts sind aber nicht immer einfach.
Betrachten wir als Beispiel das Thema Personaldatenbank unter einem ganz anderen
Gesichtspunkt: Ein Unternehmen organisiert die Arbeitsplätze seiner Angestellten nicht
nach festen Büros, sondern offen: Die Angestellten sind in einer Art Kabinen
untergebracht, Trennwände markieren ihre Arbeitsgrenze. Es gibt bedeutende
Unternehmen, die sich so organisieren, weil dann die Abteilungen sehr flexibel wachsen
oder schrumpfen können.
Die relationale Datenbank für einen Raumplaner würde dann zum Beispiel eine
Relation enthalten, in der die Angestellten mit ihrem Namen abgelegt sind. Dazu kommt
2
ihre Arbeitsfläche, die als ein Vieleck, ein Polygon, dargestellt werden kann und
schließlich die Information, welche Nachbarn unmittelbar an die eigene Arbeitsfläche
angrenzen.
RAUMPLAN
Angestellte ArbeitsPlatz Nachbarn
Platz: polygon
Nachbarn: Menge
von Angestellten
In dieser Anwendung sind die Daten hier komplexer sind, als wir das von den üblichen
Beispielen für das relationale Datenmodell gewohnt sind. Die Polygone können nach
dem Begrenzungsflächenmodell, modelliert werden, d. h. ein Polygon wird beschrieben
durch seine begrenzenden Kanten und diese wiederum durch ihre beiden Eckpunkte.
POLY_Rel
PolyID
p27
p68
...
Ausstattung
Rechner
keine
...
...
...
...
...
KANTEN_Rel
Kant_ID Poly1 Poly2
Pun1 Pun2
k12
k03
...
pu18 pu78
pu18 pu75
...
...
p27
p27
...
p33
p81
...
PUNKT_Rel
Punkt_ID X Y Z
pu00
0.0 0.0 0.0
pu03
...
0.1 0.2 1.0
... ... ...
3
Wenn komplexe Objekte, wie zum Beispiel die Polygone, in einer relationalen
Datenbank abgelegt und verwaltet werden, werden die Grenzen des relationalen
Datenmodells deutlich:
1. Ein Schwachpunkt ist, daß das Anwendungsobjekt, ein Polygon, über mehrere
Relationen verteilt ist. Immer, wenn das Anwendungsobjekt als Ganzes verarbeiten
werden soll, müssen die einzelnen Relationen immer wieder durch einen Verbund
zusammengefügt werden Diese Verbundoperationen sind sehr aufwendig. Als
Konsequenz wird die Leistung des Systems schwach und und das relationale System
wird damit für diese Anwendung unbrauchbar. Der Effekt, ein komplexes Objekt
auf mehrere Relationen aufteilen zu müssen, wird als Segmentierung bezeichnet.
2. Um ein komplexes Objekt wie das Polygon wieder zusammenbauen zu können, muß
ein umfangreiches System von Künstlichen Schlüsselattributen eingeführt und
verwaltet werden. Diese Schlüsselattribute identifizieren die einzelnen Tupel in
einer Relation und müssen vom Benutzer verwaltet werden.
3. Das anwendungsspezifische Verhalten von Objekten, z.B. die Verschiebung oder
die Rotation eines Polygons, kann im relationalen Schema nicht dargestellt werden.
4. SQL ist als eine mengenorientierte Zugriffsprache nicht geeignet, komplexe
Operationen wie, z.B. die Verschiebung oder die Rotation eines Polygons, zu
formulieren. Dazu muß eine „normale“ Programmiersprache eingesetzt werden.
Einige der Probleme bei der Darstellung und Verwaltung komplexer Objekte mit
relationalen Systemen sind auf Geburtsfehler zurück zu führen.
• Die erste Normalform schreibt einfache, d.h. unstrukturierte Attribute vor. Deshalb
ist die Schachtelung komplexer Objekte (Objekt ist Teil von Objekt ist Teil von
Objekt und so weiter) ist nicht direkt modellierbar. Diese Möglichkeit gibt es aber in
Programmiersprachen: Dort kann die Komponente jedes zusammengesetzten
Objekts auch wieder aus einem zusammengesetzten Objekt bestehen.
Programmiersprachen, die so flexibel arbeiten, heißen „orthogonal“. Das relationale
Datenmodell ist nicht orthogonal, weil eine Tabelle aus Attributwerten besteht, aber
ein Attributwert wiederum keine Tabelle sein kann.
• Die Identifikation von Objekten, im relationalen Sprachgebrauch sind das die Zeilen
oder Tupel, beruht auf Eigenschaften des Objekts. Im Beispiel werden Angestellte
über ihre Namen identifiziert. Was passiert aber, wenn der oder die Angestellte
heiratet und den Namen wechselt? Ist die Person dann eine andere? In der
Anwendung nicht, in der Datenbank schon. Hier gibt es Brüche, oder wie wir sagen:
Dateninkonsistenzen, die zu Problemen führen. Wenn man die Probleme beseitigen
will, muß man künstliche Schlüssel einführen und mit großem Aufwand verwalten.
In der Praxis gibt es viele Anwendungen, die ein ähnliches Profil aufweisen, wie das
bisher diskutierte Beispiel (Maschinenbau (CAD), Softwareentwurf, etc), und für die
deshalb ein relationales Datenbanksystem nicht so gut geeignet ist.
4
2.
Objektorientierte Datenbanksysteme: Einführung
Die Anforderungen, die der Entwurf und die Verwaltung komplexer Objekte mit sich
bringen, führten zu einem Evolutionsschritt in der Datenbanktechnologie, den
„objektorientierten Datenbanksystemen“.
Ein objektorientiertes Datenbanksystem ist zunächst einmal ein Datenbanksystem, d.h.
es besitzt die Datenbankeigenschaften, die die Anwender kennen- und schätzen gelernt
haben. Dazu gehört die Persistenz: die Datenobjekte sollen dauerhaft gespeichert
werden. Dazu gehört auch die Unterstützung des effizienten Zugriffs auf die Daten
durch Zugriffspfade wie Indizes oder Speicherungsstrukturen, wie z.B. Cluster. Dazu
gehört ein gutes Transaktionskonzept mit all den Komponenten, die den MehrbenutzerBetrieb steuern. Und schließlich gehören dazu Recovery-Mechanismen für den Fall, daß
eine Fehlersituation aufgetreten ist.
Was ist neu an objektorientierten Datenbanken?
Objektorientierte Datenbanken basieren auf einem objektorientierten Datenmodell.
Das objektorientierte Datenmodell kann erweitert werden um anwendungsspezifische
Datentypen und Funktionen. Und schließlich haben wir Datendefinitions- und
Datenmanipulationssprachen, die für das objektorientierte Modell zugeschnitten sind.
Dazu gehören oft auch die enge Anpassung an objektorientierte Programmiersprachen.
Das objektorientierte Datenmodell bietet
• die üblichen Standarddatentypen, die vom System vordefiniert sind. Das sind zum
Beispiel die wohlbekannten integer-, string-, oder character-Datentypen.
• die typischen Konzepte der Objektorientierung: Klassen und Methoden, d.h.
Operationen auf den Objekten der Klasse. Die Zuschauer, die aufmerksam den Java
Kurs verfolgt haben, werden sich an diese Konzepte erinnern.
• Konzepte zur Beschreibung komplexer Objekte beschreiben. Dazu werden
Typkonstruktoren in die Welt der Datenbanken eingeführt. Es handelt sich dabei um
Sprachelemente, mit denen komplexe Datentypen aufgebaut werden können. Der
Typkonstruktor „set“ wird benutzt, um mehrere Objekte eines Datentyps zu einer
Menge von Objekten zusammenzufassen. Der Typkonstruktor „list“ wird benutzt,
um Objekte eines Datentyps zu einer geordneten Liste zusammenzufassen. Der
Typkonstruktor „tuple“ wird schließlich benutzt, um Objekte verschiedener
Datentypen zu Tupeln wie in Relationen zusammenzufassen.
Die Typkonstruktoren können eingesetzt werden, um komplexe Objekte zu definieren,
wie im folgenden Beispiel dargestellt:
Class Raumplanung
type tuple ( Mitarbeiter: Angestellte,
ArbeitsPlatz: Polygon,
Nachbarn:
set (Angestellte))
method verfuegbarer_platz: integer
Das Beispiel bezieht sich auf ein konkretes objektorientiertes Datenbanksystem mit
Namen O2 von der Firma Ardent Software. Mit der Datendefinitionssprache von O2
wird eine Klasse Raumplanung definiert, die aus Tupeln mit drei Attributen besteht. Das
erste Attribut heißt Mitarbeiter. Es wird durch eine weitere Klasse Angestellter
5
beschrieben. Das zweite Attribut ist der Arbeitsplatz, der über eine Klasse Polygon
beschrieben wird. Das dritte Attribut ist eine Menge von Objekten der Klasse
Angestellte. Und schließlich gibt es eine Methode, die für Objekte der Klasse den
aktuellen verfügbaren Platz berechnet.
Die Klassen Angestellte und Polygon haben selbst wieder eine innere Struktur.
Angestellte haben zum Beispiel Namen, Gehälter und gehören einer Abteilung an.
Polygone werden über die Linien beschrieben, die sie begrenzen und die Linien
wiederum werden durch je zwei Endpunkte beschrieben. So werden Objekte mit
beliebiger Schachtelungstiefe definiert.
Ein wichtiges Merkmal objektorientierter Modelle gegenüber dem klassischen
relationalen Datenmodell ist die Objekt-Identität. Jedes Objekt in der Datenbank erhält
bei seiner Erstellung vom Datenbanksystem einen Identifikator, so etwas wie einen
Eindeutigkeitsstempel. Der Objektidentifikator ist systemweit eindeutig und ändert sich
während der Lebenszeit des Objekts nicht.
OID: 538801
Angestellte:
[]
ArbeitsPlatz:
[ ]
Nachbarn: {[ ], [ ], [ ], ..}
OID: 332753
Name:Müller
Gehalt:8.700,gehört_zu:
...
[]
OID: 002781
PolyNr: p27
kanten:
<k12,
{((0.0),(0.1),(1.7)),((2.8),(3.5),(1.7))},
k37,
{((0.0),(0.1),(1.7)),
((8.0),(9.1),(10.3))},
.... >
Die Nachteile der Identifikation durch Attributwerte in relationalen Systemen sind
bekannt: Objekte (Tupel) verbinden ihre Existenz mit ihrem Zustand, mit der
Ausprägung ihrer Schlüsselattribute. Wenn der Angestellte zum Beispiel seinen Namen
ändert, ändert er in einem relationalen Datenbanksystem seinen Zustand und ist damit
im Datenbanksystem ein ganz anderer. Solche Situationen lassen sich in relationalen
Systemen vermeiden, in dem man künstliche Schlüssel einführt und verwaltet
In einer Objektorientierten Datenbank vergibt das System intern einen neuen
Identifikator, wenn ein Objekt instanziiert wird. Der Identifikator bleibt, solange das
Objet existiert und unabhängig von seiner aktuellen Attributbelegung. Diese
Objektidentifikatoren sind also zustandsunabhängig, sie sind systemweit eindeutig und
sie bleiben dem Anwender verborgen. Und noch wichtig für die Datenbankanwendung:
Die Objektidentifikatoren sind unabhängig vom Speicherungsort des Objekts. Das
6
Anwendungsprogramm muß nicht ich denn wissen, ob sich ein Objekt beim Zugriff auf
der Magnetplatte des Datenbanksystems befindet oder ob es schon im Hauptspeicher
liegt. Das System verwaltet die Objektidentifier und weiß , wo sich das Objekt aktuell
befindet. Ist es beim Zugriff noch in der Datenbank, werden Zugriffsroutinen aktiviert,
die das Objekt finden, in den Hauptspeicher holen, und mit einer Speicheradresse
versehen, so das die objektorientierte Programmiersprache darauf zugreifen kann.
3.
Entwicklungslinien objektorientierter Datenbanken
Ein objektorientiertes Typsystem für Programmiersprachen besteht aus Klassen,
Objekte, Methoden, Spezialisierungsbeziehungen. Das wird über objektorientierte
Datenbanken in die Datenbankwelt übertragen Allerdings sind die Wege dahin
unterschiedlich. Es gibt noch keine einheitlichen Standards, wie zum Beispiel SQL in
relationalen Systemen.
Seit etwa 1987 sind Objektorientierte Datenbanksysteme kommerziell verfügbar.
Dabei sind bisher drei verschiedene Entwicklungsrichtungen erkennbar
4.
1
Erweiterungen objektorientierter Programmiersprachen. Dabei handelt es sich
um Datenbanksysteme, die eine sehr enge Integration mit einer
objektorientierten Programmiersprache eingehen. Die heutigen Produkte sind
zum Beispiel für C++ und SmallTalk konzipiert, einige auch schon für Java.
Das Ziel dabei ist, Objekte persistent auf dem Hintergrundspeicher zu
verwalten und bei der Aktualisierung der Objekte möglichst effizient zu sein.
Es handelt sich also um Verwaltungssysteme für Objekte, die von einer
objektorientierten Programmiersprache erzeugt wurden. ObjectStore (Firma:
Object Design) und POET (Firma: POET) sind Produkte dieser Art.
2
Die zweite Entwicklungslinie ist evolutionär. Herkömmliche relationale
Datenbanksysteme werden erweitert um Konzepte der Objektorientierung. Die
Spitze dieser Entwicklungsrichtung sind die sogenannten objektrelationalen
Datenbanken (s. nächsten Folge).
3
Neuentwicklungen sind Datenbanksysteme, die ein objektorientiertes
Datenmodell benutzen., das von Grund auf neu entwickelt wurde. Das
Datenbanksystem O2 (Ardent Software) ist der klassische Vertreter dieser
Richtung. Jasmine ist ein System von Computer Associates.
Der ODMG-Standard
Die Welt der Datenbanken wird mit den objektorientierten Systemen kompliziert.
Andererseits sind Datenbanken sehr stark auf Standards angewiesen sind, um
Information zwischen verschiedenen Systemen austauschen zu können.
Im Bereich objektorientierter Datenbanken sind zwei Standardisierungsrichtungen
maßgebend:
• Für objektrelationale Systeme gibt es den neuen Standard SQL 99 (nächsten Folge)
• Die kommerziellen Datenbankanbieter versuchen seit Anfang der 90er Jahre, die
unterschiedlichen objektorientierten Datenmodelle und Sprachen ihrer Systeme zu
7
vereinheitlichen. Dazu haben sie sich zu einer Standardisierungskommission
zusammengeschlossen, der ODMG .
ODMG steht für Object Data Management Group. Inzwischen liegen zwei
Standardisierungsvorschläge auf dem Tisch: ODMG 2 aus dem Jahr 97 und der letzte
Stand: ODGM 3.
Ziele dieses Standards:
• Das Objektmodell legt die Grundbegriffe und die Semantik des Datenmodells fest.
• Die Datenbanksprache ODL beschreibt Sprachkonstrukte der Datendefinition. OQL
ist eine deklarative Abfragesprache.
• Die Sprachanbindungen sind der Kern dieser Art von Standard für Objektorientierte
Datenbanken. Hier geht es darum, eine möglichst enge Verbindung zwischen der
Programmiersprache und der Datenbank herzustellen, zum Beispiel durch ein
einheitliches Typsystem. Bisher sind Schnittstellen für C++ , Smalltalk und seit
neuestem auch Java vorgesehen.
Der ODMG Standard spricht demnach vor allem die Produkte der ersten
Entwicklungslinie objektorientierter Datenbanken an. Dabei ging es vor allem darum,
Objekte der Programmiersprache persistent zu verwalten.
Das ODMG Objektmodell ist ein Kompromiß aus den Datenmodellen von C++,
SmallTalk und Java und den Datenmodellen der bereits existierenden objektorientierten
Datenbanksysteme. Es verwendet den Begriff Objekttyp anstelle des Begriffs Klasse.
Ein Objekttyp kann Objekte und Werte beinhalten. Zwei Arten von Objekten werden
unterschieden:
• Mutable (auf deutsch: veränderbare) Objekte haben eine Objektidentität und einen
Zustand. Der Objektidentifikator ist systemweit eindeutig und ändert sich während
der Lebenszeit des Objekts nicht. Zusätzlich hat ein Objekt zu jedem Zeitpunkt
seiner Lebenszeit einen bestimmten Zustand, der sich aus der momentanen
Wertebelegung seiner Attribute ergibt. Der Objekttyp legt die Struktur und das
Verhalten des Objekts fest.
• Die immutable objects (deutsch „unveränderbaren Objekte“) kann man mit den
klassischen Datentypen unserer Programmiersprachen vergleichen. Sie sind
entweder einfache Datentypen, wie integers oder strings, oder sie sind strukturiert.
Wenn sie strukturiert sind, dann heißt das: mit Hilfe der Typkonstruktoren aufgebaut.
Selbstverständlich sieht der ODMG-Standard eine Typhierarchie vor. Das ist ja eines
der Kernkonzepte der Objektorientierung. Darüberhinaus werden aber auch
Beziehungen besonders unterstützt.
In Datenbankanwendungen sind Beziehungen zwischen Objekten besonders wichtig,
wie bereits auf Grund der Probleme der Fremdschlüsselbeziehungen in relationalen
Systeme bekannt ist.
Die folgende Beispiel zeigt Beziehungen zwischen Angestellten und Abteilungen. Das
ODMG Objektmodell ermöglicht es, die Beziehungen zwischen den Klassen explizit als
Relationship zu definieren. (Den Begriff Relationship ist vom Entity-RelationshipModell her bekannt. Dort gibt es 1:1, 1:n und m:n Beziehungen.)
Diese Beziehungen können auch im ODMG-.Modell definiert werden
8
class Angestellte
attribute
attribute
relationship
...
{
string AngName;
integer (4) Gehalt;
Abteilung gehoert_zu inverse Abteilung::set{beschaeftigt};
};
class Abteilung ...
{
attribute
string
AbtName;
attribute
integer (7)
Budget;
relationship set{Angestellte} beschaeftigt inverse Angestellte::gehoert_zu
};
Die 1:N – Beziehung zwischen Angestellten und Abteilungen wird auf der Seite des
Angestelltenobjekts als Relationship, auf der Seite der Abteilung mit Hilfe eines
Mengenkonstruktors set modelliert, der einer Abteilung eine Menge von Referenzen auf
Mitarbeiter-Objekte zuordnet.
Wichtig ist, das man die Beziehungen als „Invers“ definieren kann. Damit kann das
Datenbanksystem dafür sorgen, das die Beziehung konsistent verwaltet wird: Wenn ein
Angestellten-Objekt gelöscht wird, wird die Referenz auf den Angestellten in der
Referenzmenge der Abteilung gelöscht. Umgekehrt erzwingt das System bei der
Instanziierung eines neuen Angestellten-Objekts, daß eine Referenz auf ein Abteilung
eingerichtet wird und ergänzt automatisch in dem Abteilungsobjekt die Referenzmenge.
Weitere Informationen zum ODMG-Standard, insbesondere auch Literaturhinweise und
besondere Artikel zu speziellen Aspekten findet man unter http://www.odmg.org/
9