Most database players don't support it, or don't support it exclusively. It is complex, and not used broadly. Even if "data" is OO in nature, the databases existed decades ago, and they cannot take ORDBMS (or OODBMS). Learning curve also imposes problems.
ORDBMS/OODBMS are like virtual registry view you see in Registry Editor. Contents are tree-styled objects. But internally they might be stored as flat/hierarchical or in relational manner. You really don't care - the APIs provide you the view of registry information.
Similarly, even if major players don't support (and won't support) OO nature of database, they may provide some extensions. Or, you may have to craft your own framework for OO data. A movie database, having actors and directors can be represented using relations (tables). Actors, directors, shooting-locations would also be classes/objects, and can easily be represented using tables, and referential integrity imposed by database/DB designer.
You, as a developer would make this relational nature of data to an object-oriented form having Movie
as a class, referencing actors/directors (1:1 or 1:N). I am not aware how/what EE
facilitates this, but it would be doing mapping this way only.
Object-Relational Databases
- Object oriented technology on top of relational technology and in the relational context.
- Objects are stored in tables of objects rather than in tables of rows.
- Support of major object oriented features: complex types, inheritance, aggregation, methods
- Advantage: Extension of a well-known technology
- Disadvantages: Mixture of both technologies may result in difficult to understand schemas
- Has Performance problems
- Object-relational systems include features such as complex object extensibility, encapsulation, inheritance, and better interfaces to OO languages.
- ORDBMSs allow developers to embed new classes of data objects into the relational data model abstraction (and on top of SQL).
Following diagram shows how data can be accessed.
