Nos últimos anos, o paradigma de orientação a objetos vem se desenvolvendo
na área de programação. Várias experiências têm mostrado que esse paradigma
aumenta a produtividade dos programadores a modularidade dos programas. Na
área de bancos de dados, sabe-se que os modelos de dados clássicos, como por
exemplo o modelo relacional, não são apropriados para descrever e manipular
os dados das chamadas "novas aplicações", tais como projeto assistido por
computador (CAD), manufatura de produtos (CAM), produção de software (CASE),
automação de escritórios (OIS), aplicações médicas e científicas,
representação do conhecimento para aplicações de inteligência artificial,
etc [The90]. Os dados dessas aplicações são muito complexos e evolutivos,
sendo necessária a modelagem não somente de sua estrutura, mas também de seu
comportamento.

Para compensar estas deficiências, vários modelos de dados tem sido
propostos. Primeiramente, os estudos na área foram dirigidos para os modelos
semânticos e extensões do modelo relacional. Mais recentemente, surgiram
modelos que procuram enfatizar os aspectos comportamentais dos objetos que
manipulam, sendo baseados principalmente em conceitos oriundos da
programação orientada a objetos. Isso se deve ao fato de que a orientação a
objetos auxilia a lidar com a complexidade nas mais diferentes aplicações.
Esses modelos são denominados modelos de dados orientados a objetos [Nav92].

Os modelos de dados orientados s objetos são mais expressivos e flexíveis
que o modelo relacional. O modelo de dados relacional foi criado para
permitir a representação de uma grande variedade de problemas usando um
pequeno conjunto de conceitos simples. Por outro lado, os modelos orientados
a objetos foram projetados para a criação e representação de estruturas bem
mais complexas de uma maneira coerente e uniforme [SZ87].

Apesar de inúmeras vantagens encontradas ao se utilizar o paradigma de
orientação a objetos, ainda não existem SGBDs OO comercialmente disponíveis
para aplicações de grande porte. Os SGBDs relacionais ainda representam o
estado da arte na tecnologia tradicional de bancos de dados e são os mais
estudados na literatura. Suas maiores vantagens são a simplicidade e a
portabilidade entre implementações. Esses sistemas continuam a dominar o
mercado , sendo utilizados nas mais diversas aplicações [Sac94].

Entretanto, os conceitos de orientação a objetos podem ser utilizados como
mecanismos de abstração para o projeto de bancos de dados relacionais. A
modelagem orientada a objetos, por utilizar conceitos mais claros e
naturais, permite produzir bancos de dados relacionais mais adequados às
aplicações do mundo real, evitando os problemas de normalização
freqüentemente associados ao projeto relacional [PBRV90]. Além disso, a
modelagem orientada a objetos aumenta a integração entre os dados e as
aplicações [BPR88]. Dessa forma, uma abordagem orientada a objetos para o
projeto de lógico de bancos de dados relacionais permite que as aplicações
sejam projetadas de forma integrada, em que dados e operações podem ser
projetados ao mesmo tempo.

Com o crescimento do mercado, as linguagens orientadas a objetos começaram a
dar maior enfoque em um novo paradigma, a análise, projeto e codificação de
sistemas. É claro que os bancos de dados não poderiam ficar imunes à esse
novo modo de encarar o desenvolvimento de sistemas. Houve, entretanto, um
desenvolvimento mais rápido nas linguagens orientadas a objetos (OO) que nos
Sistemas Gerenciadores de Bancos de Dados Orientados a Objetos (SGBD OO), o
que deixou os desenvolvedores e administradores de BD numa situação curiosa:
mesmo querendo adotar a orientação a objetos, eles têm que parar na hora de
manipular seus dados. Linguagens visuais como o JAVA, por exemplo, embora
sejam orientadas o objetos em sua essência, acessam os bancos de dados de
maneira convencional, ou seja, não orientada a objetos e usando SQL. Com
isso, um mesmo programa tem uma parte OO e uma parte estruturada. Alguns
autores dizem que quando linguagens OO utilizam SQL embutido para acesso a
dados remotos em um SGBD, as facilidades e vantagens da orientação a objetos
presentes nessas linguagens não são exploradas totalmente.

Outro ponto importante, é saber se a aplicação da OO no armazenamento
estático de dados será tão mais eficiente para dados convencionais (strings
e números) como parecem ser para dados especiais como som, imagens e textos
desestruturados. Caso ela não represente um grande avanço em relação aos
SGBDs relacionais também nessa área, haverá sempre a possibilidade de termos
um grande uso de SGBDs OO para armazenamento de dados multimídia e os velhos
e bons SGBDs relacionais para dados convencionais, o que não representaria
pouco.

Enquanto o armazenamento de dados OO não se tornar comercialmente disponível
apenas, a opção mais adequada é desenvolver o sistema utilizando OO na
análise e no projeto, e posteriormente armazenar os dados relacionalmente.

(*)  Rafael Zolet Kurike rzkurike@din.uem.br