DBMS ganz verschwinden lassen, d.h. für den Programmierer "unsichtbar" machen; Objektorientierte Programmierer wollen mit Objekten arbeiten ohne überlegen zu müssen, ob sich diese nun auf der Disk (als persistente Objekte) oder im Speicher (als transistente Objekte) befinden; Programmierer wollen, dass das System unterhalb weiß, wenn ein Objekt nicht mehr im Cache ist & von der Platte geholt werden muß (um sich nicht weiter um diese Hierarchie kümmern zu müssen)
DMBS soll unabhängig von jeglichen Programmiersprachen oder Hilfsfunktionen sein; dieser Ansatz bewegt sich mehr in Richtung traditioneller DBMS - Konzepte und wird vor allem dann verwendet, wenn Objekte von mehreren Applikationen genutzt werden sollen (dieser Ansatz fand vor allem in ersten ODBMS Produkten wie ObjectStore Anwendung, wo es hauptsächlich darum ging, einen persistenten Speicher für Objekte aus objektorientierten Programmiersprachen zu schaffen)
Grund für diese unterschiedlichen Konzepte ist in erster Linie der unterschiedliche Background der Leute (Programmierer vs. Datenbankdesignern). Eine Annäherung der beiden Ansätze war allerdings unvermeidbar, zumal die Programmierer herausfanden, dass sie Objekte "sharen" mussten und die Datenbankdesigner ihrererseits widerum erkannten, dass sie ihre Produkte an C++ und Smalltalk Programmierer verkaufen mussten, die weder mit SQL - Interfaces arbeiten wollten noch wussten was queries waren und die Performance ihrer Programmiersprachen ausnutzen wollten.
Zu Beginn wurden ODBMSs primär für die persistente Speicherung von single-user applications verwendet, die auf client-workstations ausgeführt wurden und performance das Hauptkriterium war.
Mit der Zeit bauten die Hersteller Möglichkeiten zur Durchführung von Transaktionen, Locking-Mechanismen und "shareability" ein, für die Verwendung in multi-user Systemen.
ODBMSs unterstützen außerdem query - Verarbeitung und auch Tools sind mittlerweile für das Design verwendbar. Die Flexibilität geht also nicht verloren. Es wird also ausschließlich Semantik in die Objekte hinzugefügt.
Man ignoriert die Unterschiedlichkeit der Systeme (OO-Programmiersprachen zu RDBMS); So gibt es beispielsweise Tools, die aus einem ER - Modell automatisch tables kreieren, die dem Modell entsprechen. Dieser Ansatz ist allerdings nicht empfehlenswert, zumal der Aufwand - die unterschiedlichen Systeme zu verwalten - schnell zu groß wird und leicht zu einem Verlust von Daten bzw. von semantischen Informationen führen kann.
In vielen Fällen lässt sich dies jedoch nicht vermeiden (z.B. bei einer bereits bestehenden Datenbank). Für solche Fälle gibt es Gateway Produkte - wie beispielsweise Odapter von Hewlett Packard - , die einem den Zugriff auf eine relationale Datenbank mittels einer objektorientierten Programmiersprache erleichtern. Bei solchen Produkten wird die (relationale) Datenbank gescannt und versucht, daraus - im Falle von Odapter - C++ Objektdefinitionen zu erstellen. (Anm.: Odapter setzt auf Oracle auf und ist für mehrere Programmiersprachen wie beispielsweise C++, Smalltalk, C, Pascal und Ada einsetzbar)
SQL ähnliche Queries; Basiert auf einem Produkt von O2 Technologies und ist in ODMG-93 inkludiert; es handelt sich dabei um ein Superset von SQL und die Bemühungen sind dahingehend es mit SQL3 zusammenzuführen;
Query über die objektorientierte Programmiersprache selbst; hierbei wird ein parameter auf eine bestimmte Auswahl (Collection) angewannt, um spezielle Kriterien innerhalb dieser Collection zu erfüllen; die Syntax bei dieser Methode ist zwar komplett unterschiedlich zu der in SQL, es können aber damit prinzipiell die selben Arten von Queries abgesetzt werden
Erweiterung von C++ gekoppelt mit der Verwendung eines Preprozessors (Indizierung bzw. "WHERE"-clauses werden hierbei über Klammerungen vorgenommen)
ODBMS kümmert sich nur um die Struktur der Daten; bei diesem Ansatz kümmert sich das System nicht um die Durchführung spezieller Methoden, sondern überlässt dies komplett dem Applikationsprogrammierer; der Trend geht allerdings zu
Speicherung und Ausführung von Methoden innerhalb des DBMS
Die Wahl der Methode richtet sich im allgemeinen aber nach folgendem:
Objekte sollten also immer dort (innerhalb des Netzwerkes) gespeichert werden, wo sie am ehesten hinpassen und untereinander kommunizieren. Sie sollten also untereinander Daten in der Form austauschen, sodass diese Aktivität vollkommen transparent erscheint.