Z kolei sformułowany na podstawie teorii zbiorów model relacyjny nie oddziela obiektów od powiązań między nimi, a "relacje" daje się wygodnie przedstawiać za pomocą dwuwymiarowych tablic. Z założeń tego modelu daje się pośrednio wywnioskować tezę, iż ważkim problemem relacyjnych baz danych jest czas dostępu do informacji, wynikający z braku sztywnych połączeń między nimi.

Spośród rozwiązań postrelacyjnych interesującą alternatywą są rozwiązania typu NF2. Modele te dopuszczają odstępstwa od zalecanych dla relacyjnych baz danych form normalnych (NF1 - NF5). W praktyce oznacza to możliwość stosowania złożonych atrybutów (rys. 7), co pozwala na quasi-spakowaną reprezentację danych i tym samym na osiągnięcie lepszej wydajności (performance) bazy danych.

Niewątpliwie ważnym kierunkiem rozwoju modeli danych jest koncepcja obiektowo-zorientowana (OZ). Aktualnie w praktyce istnieją ograniczone potrzeby stosowania tego typu rozwiązań. Wynika to z doświadczeń projektowych, które zakładają, że korzystniej jest stosować stabilny i sprawdzony system informatyczny niż podobny, nowszy, ale gorzej przetestowany. Owszem, systemy OZ mogą odgrywać istotną rolę jako specjalistyczne moduły przedsiębiorstwa, ale w bliskiej perspektywie nie zanosi się, aby mogły one zastąpić dominujące bazy danych typu relacyjnego. Dotyczy to zwłaszcza centralnych, operacyjnych zasobów danych w dużych firmach.

Źródłem genealogii obiektowo-zorientowanych modeli danych są obiektowo-zorientowane języki programowania, począwszy od rozszerzenia ALGOL-u - SIMULI, aż do współczesnych wersji C++. Języki te pozwalają na wygodne manipulowanie zmiennymi, które znajdują się chwilowo (transient) w pamięci operacyjnej podczas działania programu. Wykazują one jednak wiele słabości, wszędzie tam gdzie niezbędne jest operowanie złożonymi strukturami danych o trwałym charakterze (persistent), co należy do specyfiki baz danych. Wynika stąd konieczność rozwoju modeli danych i skojarzonych z nimi języków, specjalnie dla baz danych OZ (OZBD).

Podstawą koncepcji modelu danych OZ jest połączenie w całość (obiekt) logicznie powiązanych danych oraz operacji na nich zdefiniowanych. W ten sposób operacje stają się częścią schematu danych, gdyż należą do definicji typu obiektu. Wynika z tego, że operacje takie mogą być wykonywane bezpośrednio w języku modelowania danych (obiektów). Koncepcja taka gwarantuje więc redukcję uciążliwych transformacji struktur danych, wynikającą z niedopasowania modelu danych do języka, wykonującego operacje na tych danych. Zjawisko to znane pod hasłem "impedance mismatch" (niedopasowanie klas językowych) doprowadziło m.in. do powstania fenomenu tzw. zagnieżdżonego SQL (embedded).

Obiekt można scharakteryzować jako trójkę:

OBIEKT = (IDO, TYP, STAN), gdzie

IDO - identyfikator obiektu generowany przez bazę danych

TYP - zdefiniowany typ obiektu

STAN - wewnętrzny stan (wartości) elementów należących do obiektu.

Identyfikatory obiektów nie zmieniają się przez cały czas ich funkcjonowania w systemie, a także są niezależne od stanu obiektów i sposobu ich zapamiętania. Cechy te pozwalają na uniknięcie charakterystycznej dla modelu relacyjnego segmentacji obiektów świata rzeczywistego, reprezentowanych w modelu danych, co przejawia się w ich rozbiciu na wiele tabel.

Oczywiście w praktyce każdy model jest warty tyle tylko, ile jego konkretna implementacja w postaci istniejącej bazy danych. Ponad dekadę temu firma Servio Logic wprowadziła na rynek pierwszą komercyjną OZBD - GemStone, wykorzystując język Smalltalk-80. Od tego czasu kolejne pakiety tej klasy można podzielić na dwie duże grupy. W systemach, takich jak np. Ontos firmy Ontologic Inc., architektura bazy danych jest rozszerzeniem obiektowo-zorientowanego języka programowania, przeważnie jest to C++. Z kolei baza danych Starburst (IBM) jest rozszerzeniem koncepcji relacyjnej. Podobnie jest z bazą danych Postgres (Berkeley, Universytet Kalifornijski), która korzysta ze skojarzonego z nią języka Postquel.

Wydaje się, że ta druga grupa ma bardziej obiecujące perspektywy, gdyż pozwala na łagodne łączenie technologii obiektowej z relacyjną. Oczywiście wymaga to nowego standardu SQL i właśnie w tym kierunku idą prace gremiów normatywnych (ANSI, ISO/IEC) i firm software'owych, których celem jest obiektowo-zorientowany język SQL3. Na razie jednak wielcy producenci baz danych koncentrują się na hurtowniach danych czy narzędziach typu OLAP (Online Analytical Processing). Nie bez powodu Oracle kupiła firmę IRI - wytwórcę tzw. wielowymiarowych baz danych Express. Na razie to właśnie ten kierunek rozwoju baz danych zdominował teoretyczne dyskusje nad wyższością poszczególnych modeli danych.