1. Introdução
O modelo relacional foi, durante muitos anos, o modelo dominante para bancos de dados. Contudo com o passar dos anos surgiu o modelo OO (Orientado a Objetos), uma nova forma de se programar softwares, baseada em classes e objetos. Essa mudança evidenciou uma incompatibilidade conceitual entre aplicações baseadas em objetos e bancos de dados relacionais tradicionais, revelando limitações na integração entre esses dois modelos.
Diante deste cenário, tornou-se necessário buscar soluções para reduzir essa incompatibilidade, dando origem a novos modelos de bancos de dados. Este artigo tem como objetivo analisar a evolução do modelo relacional tradicional ao modelo objeto-relacional, destacando o “Impedance Mismatch” e as soluções que foram surgindo e se aprimorando ao longo do tempo.
2. O Problema da Impedância (Impedance Mismatch)
Com a chegada do modelo OO e a tentativa de implementação entre os dois modelos, surgiu o “Impedance Mismatch” uma incompatibilidade conceitual e estrutural entre esses dois modelos.
A programação OO ela é baseada em: classes, herança, objetos, métodos dentro dos objetos, atributos, no relacionamento direto entre objetos e etc. Em contraste o modelo relacional é baseado em: tabelas, linhas, colunas, chaves primárias (PK) e chaves estrangeiras (FK) para estabelecer relacionamento.
O problema surge porque banco de dados tem maneiras distintas de representar os dados. Linguagens que são voltadas a Programação Orientada a Objetos, utilizam estruturas complexas de dados, mapear a hierarquia de objetos de modelos orientados para modelos relacionais era um grande desafio, porque o processo de conversão entre objetos e tabelas exige um mapeamento adicional, o que causava um problema em aplicações orientadas a objetos quando precisa armazenar ou recuperar informações de um banco de dados relacional e também aumentando a complexidade do desenvolvimento e podendo impactar significantemente no desenvolvimento do sistema.
Além disso o modelo OO permite usar herança e encapsulamento, conceitos que não existem no modelo relacional. Em sistemas OO a herança é comumente utilizada para classes herdarem atributos e métodos de outras, formando assim uma estrutura hierárquica. Já no modelo relacional essa hierarquia não seria possível, precisando-se assim ser adaptado para tabelas, muitas vezes exigindo mais trabalho e estratégias adicionais, e deixando assim o projeto mais complexo.
Outro tópico a ser ressaltado é que objetos podem conter outros objetos como atributos, formando estruturas compostas. No modelo relacional, essa estrutura precisa ser dividida em tabelas que são ligadas por chaves estrangeiras. Esse processo aumenta a dependência de operações de junções (joins) para reconstruir as informações, o que pode dificultar consultas mais complexas.
Diante dessas dificuldades, surgiram algumas ferramentas para facilitarem o mapeamento conhecidas como mapeadores objeto-relacionais (ORM), responsáveis por realizar a conversão automática entre objeto e estruturas relacionais. Por mais que essas ferramentas tenham reduzido consideravelmente a complexidade para o desenvolvedor, elas não eliminam completamente o problema conceitual entre os dois modelos.
Esse cenário motivou o surgimento de novas abordagens para o gerenciamento desses dados, como os bancos de dados orientados a objetos (OODBMS) e, posteriormente, os bancos objetos-relacionais (ORDBMS), que buscam a robustez do modelo relacional com as características do orientado a objetos.
3. Comparativo de modelos
| Critério | RDBMS | OODBMS | ORDBMS |
|---|---|---|---|
| Principal vantagem | Estrutura sólida, padronização em SQL e forte integridade de dados. | Representação natural de objetos complexos sem necessidade de mapeamento. | Combina a estabilidade do modelo relacional com recursos orientados a objetos. |
| Relacionamentos complexos | Utiliza chaves primárias (PK), chaves estrangeiras (FK) e joins para reconstruir relações. Pode gerar consultas complexas. | Relacionamentos são feitos por referências diretas entre objetos, de forma mais natural e direta. | Mantém PK e FK, mas permite tipos complexos, herança e extensões, reduzindo parte da limitação estrutural. |
| Síntese / Evolução | Modelo tradicional baseado exclusivamente em tabelas e SQL padrão. | Abandona o modelo relacional clássico, focando totalmente em objetos. | Mantém o SQL e a estrutura relacional, mas adiciona extensibilidade, tipos personalizados e suporte a conceitos de OO. |
4. Arquitetura do PostgreSQL
O PostgreSQL tem a arquitetura de cliente-servidor sendo um sistema catalogue-driven, ou seja, guiado por catálogos internos. Isso significa que todas as informações sobre o banco de dados como: tabelas, colunas, índices, funções e permissões, estão armazenadas em tabelas catalogadas pelo sistema. Dessa forma, o banco faz uma “auto consulta” para decidir como que ele vai executar determinadas operações, em vez de depender de código fixo.
Essa arquitetura deixa o PostgreSQL extremamente extensível. Sendo possível criar vários tipos de novos dados personalizados, funções, operadores sendo possível até a utilização de extensões, sem precisar compilar o código novamente, algo impressionante para padrões SQL. Esses elementos funcionam como nativos, permitindo assim, que o banco sustente estruturas complexas, objetos compostos e hierarquias, características de sistemas orientados a objetos.
Essa arquitetura é extremamente funcional para o contexto do ORDBMS, já que ela combina a rigidez do modelo relacional com conceitos de orientação a objetos. O PostgreSQL consegue implementar isso graças a seu sistema catalogue-driven e também, graças a sua extensibilidade.
Em resumo, a arquitetura expansível e catalogue-driven tornam o PostgreSQL um banco evolutivo e adaptativo, adaptando-se a necessidades especificas sem quebrar o sistema principal. Isso reflete na segurança, eficiência e na versatilidade, permitindo que ele atenda as exigências de aplicações cada vez mais complexas e de grande porte, sem abrir mão da confiabilidade que o modelo relacional traz.
5. Conclusão
A evolução do banco de dados do modelo relacional para o objeto-relacional reflete a necessidade de acompanhar as mudanças na programação e nas novas aplicações. O modelo relacional, apesar de já consolidado, mostrou limitações com sistemas orientados a objetos devido ao Impedance Mismatch, que dificulta integrar as tabelas e objetos complexos.
Os OODBMS tentaram aproximar a lógica do OO, mas a falta de uma padronização levou ao surgimento dos ORDBMS, que combinam confiabilidade relacional com a flexibilidade da orientação a objetos.
O PostgreSQL consegue exemplificar bem essa evolução, sendo catalogue-driven e extensível, permitindo criar tipos de dados, funções e extensões sem recompilar, mantendo o tradicional SQL. Assim, os bancos modernos suportam hierarquia, objetos compostos e relacionamentos avançados, sem abrir mão da segurança e eficiência.
Referências
Elmasri, R., & Navathe, S. B. (2016). Fundamentals of Database Systems (7th ed.). Pearson.
Date, C. J. (2012). Database Design and Relational Theory: Normal Forms and All That Jazz. O'Reilly Media.
Silberschatz, A., Korth, H., & Sudarshan, S. (2019). Database System Concepts (7th ed.). McGraw-Hill.
Ambler, S. (2003). The Object-Relational Impedance Mismatch. Agile Data. Disponível em: http://www.agiledata.org/essays/mismatch.html
PostgreSQL Global Development Group. (2023). PostgreSQL Documentation. Disponível em: https://www.postgresql.org/docs/
Batista, R. (2019). Bancos de Dados Objeto-Relacionais: Conceitos e Aplicações. São Paulo: Novatec.
Startup House Glossary. (2021). What is Impedance Mismatch in Databases? Disponível em: https://startup-house.com/glossary/what-is-impedance-mismatch-in-databases
Elmasri, R., & Navathe, S. B. (2015). Sistemas de Banco de Dados (6ª ed.). São Paulo: Pearson.
Top comments (0)