Skript Datenbanken I - Praktische Informatik Universität Kassel

Kapitel 8 – Netzwerk-, hierarchisches und objekt-orientiertes Modell 185
vom Anwender eingebracht werden können und zwar ununterscheidbar
von vordefinierten Typen. Die anderen Forderungen nach Persistenz,
Externspeichermanagement, Mehrprogrammbetrieb (Nebenläufigkeit),
Sicherung und Wiederaufsetzen im Fehlerfall, sowie Spontanabfragen
sind selbstverständlich aus Sicht der klassischen, kommerziellen Datenbanksysteme.
Optionale Eigenschaften
Zu den wünschenswerten bzw. unklaren Eigenschaften zählen
• Mehrfachvererbung, engl. multiple inheritance, z. B. ein Lehrer,
der an einer Weiterbildungsmaßnahme teilnimmt erbt Attribute
und Operationen von Lehrer und Schüler;
• Typprüfung: möglichst vollständig zur Übersetzungszeit;
• Verteilung: Daten und Transaktionen verteilt auf mehrere Systeme;
• lange und geschachtelte Transaktionen, z. B. im Ingenieurbereich
bei CAD-Entwürfen;
• Versionsverwaltung: wie lautete der Auftragsbestand des Kunden x
per (engl. as of) 1.1.1993.
Kritiker dieser Manifests werfen den „OODBS-Heilsbringern“ im
wesentlichen vor, daß sie mit ihren Verknüpfungen via OIDs eine navigierende
DML im Stile der Netzwerke fördern. Sie argumentieren ferner
[Comm90], daß viele der genannten Eigenschaften wie Typsystem, Vererbung,
komplexe Objekte, usw. Eingang in Erweiterungen relationaler
Systeme finden werden, ohne die Vorteile dieses Modells aufzugeben.
Gegenwärtig existieren bereits eine ganze Reihe experimenteller und
auch bereits kommerzieller Vertreter der OODBS-Richtung:
• Altair O 2 , Ontologic Ontos, HP Iris, IBM Starburst, Exodus, Cactis,
Berkeley POSTGRES, Object Design ObjectStore, Versant
OBJECT-Base, Itaska (ex MCC ORION), Servio Corporation
GemStone, DEC Trellis/OWL, Symbolics Statice, Objectivity
Objectivity/DB, TI Zeitgeist, POET.