A Evolução do Modelo Relacional para Objeto-Relacional

Diego Ferreira — Sun, 01 Mar 2026 13:10:59 +0000

Diego Ferreira Camargo

1. Introdução

O modelo relacional, proposto por Edgar Frank Codd em 1970, revolucionou a forma como os dados eram armazenados e manipulados. Antes dele, os sistemas utilizavam modelos hierárquicos e em rede, que eram rígidos e difíceis de manter. O modelo relacional trouxe simplicidade, independência de dados e uma linguagem padronizada, o SQL, que permitiu manipulação eficiente e consistente das informações.
Durante os anos 1980 e 1990, os RDBMS tornaram-se o padrão dominante em sistemas corporativos. No entanto, paralelamente, surgiu um novo paradigma de desenvolvimento de software: a programação orientada a objetos. Linguagens como C++, Java e posteriormente C# passaram a dominar o desenvolvimento de aplicações complexas, introduzindo conceitos como encapsulamento, herança, polimorfismo e identidade de objetos.
Essa mudança criou um problema fundamental: o modelo relacional não foi projetado para representar diretamente objetos complexos. Isso levou a dificuldades na integração entre aplicações orientadas a objetos e bancos de dados relacionais, motivando o surgimento de novos modelos de banco de dados, como os OODBMS e os ORDBMS.

**2. O Problema da Impedância (Impedance Mismatch)

2.1 Conceito de incompatibilidade de impedância**

O termo Impedance Mismatch refere-se à incompatibilidade conceitual e estrutural entre dois modelos distintos de representação de dados: o modelo orientado a objetos e o modelo relacional. Essa incompatibilidade surge porque cada paradigma possui formas diferentes de representar, organizar e manipular dados.
No paradigma orientado a objetos, os dados são encapsulados em objetos que contêm tanto atributos quanto comportamento (métodos). Esses objetos podem herdar características de outros objetos e podem conter estruturas complexas, como listas e outros objetos aninhados.
Por outro lado, o modelo relacional organiza os dados em tabelas compostas por linhas e colunas. Cada linha representa uma entidade, e cada coluna representa um atributo. Os relacionamentos entre entidades são representados por meio de chaves primárias e estrangeiras, essa diferença estrutural significa que objetos complexos não podem ser armazenados diretamente em tabelas relacionais sem conversão.

2.2 Diferenças estruturais entre objetos e tabelas

Um objeto possui características fundamentais que não existem naturalmente no modelo relacional tradicional:

• Identidade independente dos valores dos atributos
• Encapsulamento de dados e comportamento
• Herança entre classes
• Polimorfismo
• Estruturas compostas e aninhadas

Já o modelo relacional possui características distintas:

• Estrutura baseada em tabelas
• Dados organizados em linhas e colunas
• Relacionamentos definidos por chaves
• Ausência de comportamento associado aos dados
• Ausência de suporte nativo à herança (no modelo relacional puro)

Para armazenar objetos em um banco relacional, é necessário converter objetos em registros tabulares e reconstruí-los posteriormente na aplicação. Esse processo cria complexidade adicional.

2.3 Impactos práticos da incompatibilidade

A incompatibilidade de impedância gera diversas consequências práticas:
Complexidade de desenvolvimento:
Os desenvolvedores precisam criar mecanismos de conversão entre objetos e tabelas. Esse processo é conhecido como Object-Relational Mapping (ORM).
Sobrecarga de processamento:
Cada operação exige conversão entre representações diferentes, aumentando o custo computacional.
Dificuldade na representação de estruturas complexas:
Estruturas como listas, árvores e grafos não são facilmente representadas em tabelas relacionais.
Aumento da complexidade do código:
Grande parte do código de aplicação passa a lidar com conversões em vez da lógica de negócio.

2.4 Surgimento dos OODBMS

Para resolver esse problema, surgiram os sistemas gerenciadores de banco de dados orientados a objetos (OODBMS). O objetivo desses sistemas era armazenar objetos diretamente, sem necessidade de conversão para tabelas.
Os OODBMS oferecem:

• Persistência direta de objetos
• Suporte à herança
• Suporte ao polimorfismo
• Representação natural de estruturas complexas
• Eliminação da necessidade de mapeamento objeto-relacional

Isso permite que aplicações orientadas a objetos interajam diretamente com o banco de dados de forma natural.
No entanto, os OODBMS enfrentaram desafios significativos, como a falta de padronização, baixa adoção no mercado e incompatibilidade com sistemas existentes baseados em SQL. Como resultado, surgiu uma nova abordagem híbrida: o modelo objeto-relacional.

3. Comparativo entre RDBMS, OODBMS e ORDBMS

Os ORDBMS foram projetados para combinar a robustez e padronização do modelo relacional com a flexibilidade do modelo orientado a objetos. A tabela abaixo apresenta uma comparação entre os três modelos:

3.1 Como cada modelo lida com relacionamentos complexos

Nos RDBMS, os relacionamentos são representados por chaves estrangeiras e reconstruídos usando operações JOIN. Isso exige processamento adicional e pode aumentar a complexidade das consultas.
Nos OODBMS, os relacionamentos são representados diretamente por referências entre objetos, permitindo navegação direta sem necessidade de JOIN.
Nos ORDBMS, ambos os métodos são suportados. Além disso, é possível criar tipos compostos que permitem armazenar estruturas complexas diretamente no banco de dados.

3.2 O ORDBMS como síntese evolutiva

Os ORDBMS representam uma síntese entre os modelos relacional e orientado a objetos. Eles mantêm o SQL como linguagem padrão, preservando a compatibilidade com sistemas existentes, mas adicionam recursos como:

• Tipos de dados personalizados
• Herança entre tabelas
• Funções definidas pelo usuário
• Operadores personalizados
• Estruturas complexas

Essa combinação permite maior flexibilidade sem sacrificar a estabilidade e padronização do modelo relacional.

*4. Arquitetura do PostgreSQL *

O PostgreSQL é um exemplo de ORDBMS moderno que implementa extensibilidade avançada. Uma de suas principais características é ser um sistema catalogue-driven, ou seja, guiado por catálogo.
Isso significa que toda a estrutura do banco de dados é armazenada em tabelas internas chamadas catálogos do sistema. Esses catálogos armazenam metadados sobre:

• tabelas
• colunas
• tipos de dados
• funções
• operadores
• índices

Em vez de essas estruturas serem definidas diretamente no código do sistema, elas são armazenadas como dados.

4.1 Consequências da arquitetura baseada em catálogo

Essa abordagem permite que novos tipos, funções e operadores sejam criados dinamicamente, sem necessidade de recompilar o banco de dados, isso oferece uma capacidade de extensibilidade extremamente poderosa.
Por exemplo, é possível criar novos tipos de dados personalizados e utilizá-los como se fossem tipos nativos do sistema. Também é possível criar novas funções e operadores que se integram completamente ao mecanismo do banco de dados.

4.2 Extensibilidade sem recompilação

Como o PostgreSQL armazena metadados nos catálogos, a adição de novos elementos é realizada por meio de comandos SQL. Isso significa que o sistema pode ser estendido em tempo de execução, sem interromper sua operação, essa arquitetura permite que o PostgreSQL seja adaptado a diferentes domínios, como:

• Sistemas financeiros
• Sistemas geográficos
• Sistemas científicos
• Aplicações de inteligência artificial

Extensões como PostGIS adicionam suporte completo a dados geoespaciais, demonstrando o poder dessa arquitetura extensível.

5. Conclusão

A evolução dos sistemas gerenciadores de banco de dados reflete a necessidade de adaptação às mudanças nos paradigmas de desenvolvimento de software. O modelo relacional, embora extremamente eficaz, não foi projetado para lidar com a complexidade dos objetos utilizados em aplicações modernas.
O surgimento dos OODBMS foi uma tentativa de resolver a incompatibilidade de impedância, permitindo persistência direta de objetos. No entanto, sua falta de padronização e adoção limitada impediram sua ampla utilização.
Os ORDBMS surgiram como uma solução equilibrada, combinando a robustez do modelo relacional com a flexibilidade do modelo orientado a objetos. Eles mantêm o SQL como linguagem padrão, garantindo compatibilidade com sistemas existentes, enquanto adicionam recursos avançados como tipos personalizados, funções e extensibilidade.
O PostgreSQL exemplifica essa evolução com sua arquitetura baseada em catálogo, que permite extensibilidade dinâmica e adaptação a diferentes necessidades. Essa abordagem representa o estágio atual da evolução dos bancos de dados, oferecendo um equilíbrio ideal entre desempenho, flexibilidade e padronização.
Assim, o modelo objeto-relacional não substitui o modelo relacional, mas o expande, permitindo que os bancos de dados atendam às demandas cada vez mais complexas das aplicações modernas.

DEV Community: Diego Ferreira

A Evolução do Modelo Relacional para Objeto-Relacional