Object-oriented programs are designed with methods that result in encapsulated objects whose representation is hidden. Mapping such private object representation to database tables makes such databases fragile according to OOP (object-oriented programming) philosophy, since there are much fewer constraints for design of encapsulated private representation of objects compared to a database’s use of public data, which must be amenable to upgrade, inspection and queries.
RDBMS tend to use rule-based and role-based protection and security mechanisms instead of direct interface restrictions. It could be said that OOP encapsulation uses “additive” security and protection control mechanisms; while RDBMS tend to use “subtractive” mechanisms. Being part of the RDBMS automatically assigns a given data item a default set of relational and database operations. Any restrictions needed on these are often done by removing them incrementally as needed. For example, non-managers may be denied the ability to delete a record in the managers’ tables. On the other hand, encapsulation assumes that a given object offers no access to the outside world until an interface is explicitly built that provides it. (However, most RDBMS offer “stored procedures”, which share some characteristics with OOP-style encapsulation.)
In particular, encapsulation incorporates the more general concept of an invariant, a concept which is used in OO (object oriented) modeling. Invariants allegedly cannot be represented in relational databases (although this may depend on how the term “invariant” is interpreted to a process being modeled or implemented).
In relational thinking, “private” versus “public” access is relative to need rather than being an absolute characteristic of the data’s state, as in the OO model. The relational and OO models often have conflicts over relativity versus absolutism of classifications and characteristics.
Interface, class, inheritance and polymorphism
Access to objects in object-oriented programs is allegedly best performed via interfaces that together provide the only access to the internals of an object. The relational model, on the other hand, utilizes derived relation variables (views) to provide varying perspectives and constraints to ensure integrity. Similarly, essential OOP concepts for classes of objects, inheritance and polymorphism are not supported by relational database systems.
Mapping to RDBMS
A proper mapping between relational database concepts and object-oriented concepts can be made, if relational database tables are linked to associations found in object-oriented analysis.
Data type differences
A major mismatch between existing relational and OO languages is the type system differences. The relational model strictly prohibits by-reference attributes (or pointers), whereas OO languages embrace and expect by-reference behavior. Scalar types and their operator semantics are also very often subtly to vastly different between the models, causing problems in mapping.
For example, most SQL systems support string types with varying collation and constrained maximum lengths (open-ended text types tend to hinder performance), while most OO languages consider collation only as an argument to sort routines and strings are intrinsically sized to available memory. A more subtle, but related example is that SQL systems often ignore trailing white space in a string for the purposes of comparison, whereas OO string libraries do not. It is typically not possible to construct new data types as a matter of constraining the possible values of other primitive types in an OO language.
Structural and integrity differences
Another mismatch has to do with the differences in the structural and integrity aspects of the contrasted models. In OO languages, data structures are heavily nested thus making for difficult mapping to relational schemas, where all data is represented in a named set of global, non nested relation variables. Relations themselves, being sets of tuples all conforming to the same header, also do not have an ideal counterpart in OO languages. Constraints in OO languages are generally not declared as such, but are manifested as exception raising protection logic surrounding encapsulated internal data. The relational model, on the other hand, calls for declarative constraints on scalar types, attributes, relation variables, and the database as a whole.
The semantic differences are especially apparent in the manipulative aspects of the contrasted models, however. The relational model has an intrinsic, relatively small and well defined set of primitive operators for usage in the query and manipulation of data, whereas OO languages generally handle query and manipulation through custom-built or lower-level, case and physical access path specific imperative operations. Some OO languages do have support for declarative query sub-languages, but because OO languages typically deal with lists and perhaps hash-tables, the manipulative primitives are necessarily distinct from the set-based operations of the relational model.
The concurrency and transaction aspects are significantly different also. In particular, relational database transactions, as the smallest unit of work performed by databases, are much larger than any operations performed by classes in OO languages. Transactions in relational databases are dynamically bounded sets of arbitrary data manipulations, whereas the granularity of transactions in OO languages is typically individual assignments of primitive typed fields. OO languages typically have no analogue of isolation or durability as well and atomicity and consistency are only ensured for said writes of primitive typed fields.