The way individual complex types are structured in the relational model is very similar to the object oriented model with two the major differences.
Object oriented model allows inheritance of properties and abstraction of types, whereas in the relational model all components of the structure are redefined. As such, the area of a circle as defined in the “Circle” type has nothing to do with the area of a square as defined in the “Square” type. Consequently, there is a lot of redundant terminology that can be confusing to a developer because the human mind, will constantly try to associate the two, as they have common semantics.
The second major difference that the relational model has relative to the OO model, is that it sees the relations between types as a separate concept, unrelated to the types themselves. In fact it doesn’t really take any sides between types and relations as both are considered relations. This characteristics gives greater flexibility to the data model, because the addition of a relation, which can occur later on in the use of the application, does not change the structure of the types. They can be added as needed throughout the lifetime of the application. This flexibility and the simplicity of the model allowed for extremely good standardization, which makes the relational model and the relational databases extremely successful to these days.
With object oriented development becoming more and more prevalent due to its efficiency of code reuse, changing the minds of developers into thinking more are more in terms of objects, there is a rising confusion in the field of data manipulation. Storing data in one model and manipulating it in a different one, especially when the difference between the two are significant, needs a lot of overhead work. A separate layer needs to be created to transform back and forth the data structure as well as the searching criteria, which sometimes can prove very difficult. Additionally, the difference in the way the two models conceptually encode information inevitably gives rise to a lot of conceptual conflict as well, and different developers see the transition between the two in different way.
To simplify this, some advocate the creation of object-oriented databases, which would do away with the overhead of coding and the conflict of ideologies, because in the object model, both, members of complex types (structures) and the relation are reusable via inheritance. By wrapping both members and relations under the same umbrella, the object model, allow easy implementation of programming operations like deep comparison, deep copy or deep deletion, operations that can potentially create a lot of data inconsistency and programming overhead in relational systems which do not necessarily enforce these dependencies.
But the subjectivity of structures associated with the object model and the rigidity created by wrapping relations into the types have taken their toll on the standardization and portability of the model. Object databases are by far less versatile and as such there are many different implementation that found their way only into niche applications.
The legacy of both these major data models is that they originate in an era when applications were not meant to communicate with each other. The vast majority of applications resided at most on a local area network or a virtual private network serving one business or one cohesive group of consumers. This meant that the abstraction of data, the pattern created to capture information into it’s meaning free form did not intersect with the property of subjectivity. It was as if individuals, observed information from their own particular points of view and little did it matter that other individuals observe the same information but from an alternate subjective angle. Information losses associated with the abstraction of information could easily be factored in from the beginning. Because of this, information, had that absolute character data has. The two, information and data, were conceptually almost interchangeable as the abstractor was the same with the consumer. Whatever wasn’t encoded into the data, was in the head of that who encoded it, who in the end was also responsible with decoding it. This simplification however can only exist under the premise of the lack of subjectivity.
But not so long ago came a time when applications started to break the barrier of individualism and transfer of information (not data) started to become more and more important in the information industry. This however proved a very difficult nut to crack because the moment this need arose, the encoded information lost its absolute character and encoded information suddenly became what it really is: data and not information. But the industry continued to treat it as if nothing had happened and attempted to apply to information, everything that learned and developed for data.