The Evolution from Relational to Object-Relational Database Models
#Infrastructure

The Evolution from Relational to Object-Relational Database Models

Backend Reporter
4 min read

The evolution of database systems from pure relational models to object-relational hybrids reflects the changing needs of software development, addressing the impedance mismatch between object-oriented programming and traditional relational storage.

The evolution of database management systems over recent decades has been driven by the need to adapt to changing software development requirements. During the 1970s and 1980s, relational databases dominated the computing landscape, offering a structured and reliable way to store and manipulate information. This model, proposed by Edgar F. Codd, revolutionized how data was organized in computer systems. Relational Database Management Systems (RDBMS) use tables composed of rows and columns to organize information. Each row represents a record, and each column represents an attribute of the stored data. To manipulate this data, SQL became the standard language for querying and managing relational databases.

However, with the growth of object-oriented programming in the 1990s, new challenges emerged for integrating modern applications with traditional relational databases. Languages like Java, C++, and Python use object-based structures with attributes, methods, and complex relationships. This structural difference between programming objects and relational tables created what became known as the "Impedance Mismatch" problem.

Impedance Mismatch refers to the structural incompatibility between two systems that need to interact. In the database context, it describes the difference between how data is represented in object-oriented programming languages and how it's stored in relational databases. In object-oriented languages, data is organized into objects with attributes and methods. These objects can inherit properties from other classes, have complex relationships, and naturally represent hierarchical structures within applications.

In contrast, relational databases organize data into two-dimensional tables. Relationships between entities are represented through primary keys and foreign keys. To reconstruct relationships between different entities, JOIN operations are required. This structural difference creates numerous difficulties in system development. Complex objects need to be converted into tables, hierarchical structures must be broken into multiple tables, and developers must perform the mapping between objects and database records. This process is known as Object Relational Mapping (ORM).

While tools exist to assist with this process, it still represents an additional layer of complexity between the application and the database. In an attempt to solve this problem, object-oriented databases (OODBMS) emerged. These systems allow storing objects directly in the database, preserving fundamental object-oriented concepts like encapsulation, inheritance, and object identity. Despite these conceptual advantages, OODBMS didn't achieve significant commercial adoption due to lack of standardization and the strong presence of relational databases in the market.

This led to a new hybrid model: object-relational databases (ORDBMS). The relational model remains widely used due to its reliability and standardization. Systems like MySQL, Oracle, and SQL Server are examples of databases based on this model. Object-oriented databases, on the other hand, were designed to handle complex data structures directly. However, their adoption was limited by the lack of widely accepted standards.

Object-relational databases emerged as an intermediate solution. They maintain the traditional relational structure while adding support for more complex data types and extensions that allow greater flexibility. PostgreSQL is an important example of an object-relational database. It's often described as a "catalogue-driven" system, meaning it's guided by a catalog. This means that much of the database's internal information is stored in special tables called system catalogs.

These catalogs store information about tables, columns, indexes, data types, functions, and permissions. In practice, these catalogs function as an internal database that describes the structure of the system itself. This approach allows PostgreSQL to be highly extensible. Developers can create custom data types, define specific functions, implement custom operators, and install extensions that add functionality to the system. All of this can be done without needing to recompile the database.

Additionally, PostgreSQL allows creating functions in various programming languages, including SQL, PL/pgSQL, Python, and C. This feature significantly expands the possibilities for customizing the database. Another important feature is the extension system, which allows adding complete modules to the database. A well-known example is PostGIS, which adds support for geospatial data and transforms PostgreSQL into a powerful platform for geolocation applications.

The evolution of databases reflects changes in software development needs. The relational model established a solid foundation for data storage and manipulation, becoming the industry standard for several decades. With the advancement of object-oriented programming, challenges related to integrating applications and relational databases emerged. The impedance mismatch problem highlighted the need for new approaches to handle complex data structures.

Object-oriented databases attempted to solve this problem by storing objects directly, but faced market adoption difficulties. As a result, object-relational databases emerged as a hybrid solution that combines the advantages of both models. PostgreSQL represents a successful example of this evolution, offering an extensible, catalog-based architecture that provides great flexibility in data storage and manipulation. Thus, ORDBMS represent an efficient synthesis between relational and object-oriented paradigms, offering a powerful platform for developing modern applications.

Featured image

Comments

Loading comments...