Como projetar/elaborar um DB relacional num projeto de sw OO?

num mundo ideal, acho que seria isso o melhor…

No diagrama de classes, estará a base do modelo do banco, mas ter uma camada de persistencia ajuda a abstrair e isolar estas duas áreas e desta forma otimizar o banco.

Para mim é o número 2.

Após você saber que dados serão persistidos. Você utiliza técnicas para modelar os dados da melhor forma para que ele se enquadre no seu ambiente de persistencia, no caso relacional, para assim utilizar dos beneficios dos seu ambiente de persistencia. Resumindo: Sim na hora de projetar sua persitencia em um ambiente relacional. Voce vai projetar relacionalmente e vai se beneficiar das facilidades que o ambiente relacional ta te oferecendo!

Na hora de você integrar seu ambiente OO com seu ambiente relacional você deve utilizar um mediador. Pois um ambiente fala a lingua OO e o outro ambiente fala a lingua Relacional, eles precisam de um interpreti para que eles possam se enteder no caso um mediador!

Espero que eu tenha ajudado abraços!

Aqui no trabalho criamos um modelo de classes fine-grained e tentamos seguir a idéia de criar o banco independentemente do modelo de classes. Aí é que a porca torce o rabo. Várias “conversões” que tencionávamos fazer não são bem suportadas pelo Hibernate. Algumas nem mesmo possíveis.

o ideal seria utilizar db oo

Certamente, seria o ideal. Confesso que não conheço nenhum a fundo. Há algum que não seja preso a uma linguagem em particular, como GemStone/Smalltalk, Ozone/Java e ZODB/Python?

Rodrigo Manhães:

Aqui no trabalho criamos um modelo de classes fine-grained e tentamos seguir a idéia de criar o banco independentemente do modelo de classes. Aí é que a porca torce o rabo. Várias “conversões” que tencionávamos fazer não são bem suportadas pelo Hibernate. Algumas nem mesmo possíveis.

É realmente muitas coisas não são possiveis no hibernate, quando se diz a respeito de se utilizar ao maximo os recursos do seu banco de dados relacional. Mas a vida é assim agente ganha um coisa e perde outra!

No caso do hibernate voce ganha abstração e perde desempenho, perde facilidade de gerar relatorios.

Ai que esta a escolha vou usar hibernate porque a vou desfrutar muito da abstração que ele prove e eu não me importo com o desempenho que vou perde. Ou não vou usar o hibernate porque eu me importo com o desempenho que eu vou perder entaum vou eu mesmo criar uma camada de abstração não tão boa quanto o hibernate mas que para mim é suficiente. Ou senão eu sou sinistro vou criar uma camada de abstração melhor que o hibernate e que utilize todos os recursos e se beneficie de todo desempenho da minha persistencia. (Acho que essa ultima não vai dar muito certo rs… pelo menos no meu caso não sou tao sinistro assim rs…)

ahhhh… acabei esquecendo a galera diz que esse banco aqui http://www.intersystems.com.br/isc/CacheTecnoGuia.csp OO parece ser bacana…

Galera, vamos sair do mundo ideal e voltar pro mundo real.

Muitas empresas utilizam Oracle, MS SQL Server etc.

O mais adequado seria mesmo criar o modelo de classes e então, baseado no seu modelo OO, criar seu modelo de dados (ER).

Algumas empresas já tem o modelo ER e daí derivam seu modelo OO fielmente, ou com algumas mudanças para não perder as vantagens da OO.

é isso!

Valeu pelo retorno galera!

Realmente esta questão é bem polêmica, e por mais incrível que pareça não encontrei um livro/artigo que arriscasse dar uma solução final para esta situação. A maioria do pessoal sempre agarra nas duas situações, como o danieldestro colocou.

-se vc já tem o DB, faz o diagrama de classes do modelo/negócio espelhando as tabelas;

-se vc não tem o DB, faz o diagrama de classes e baseado nele cai no esquema DER->Normalização->DTR, em seguida vê se o os atributos e relações do DTR conferem com o diagrama de classes para só depois gerar o banco.

putz… que rolo :shock: eu devia ter estudado direito ou medicina

PS: pra complicar ainda mais: um colega disse que existem ferramentas Case que geram banco a partir de classes e classes a partir de banco :roll:

Mas aí a porca torna a torcer o rabo. Se você criar um modelo de BD fiel ao modelo de classes (e seu modelo de classes for um modelo rico) você irá se atolar em zilhões de produtos cartesianos a cada consulta simples. Se, ao contrário, você derivar seu modelo de classes do banco, você não terá um modelo de classes orientado a objetos, mas um modelo de dados implementado com classes.

Há que escolher, caso a caso, entre várias estratégias de mapeamento O/R (tabela por classe concreta, tabela por hierarquia, tabela por classe, etc) e isso não há ferramenta ORM que faça automaticamente a contento.

Mas eu não falei de fazer fielmente.
Mas uma estrutura ER que suporte um modelo OO.

danieldestro:

Galera, vamos sair do mundo ideal e voltar pro mundo real.

Me assustei agora !!! :shock:

Em alguns dois meus posts eu sai da realidade? Pensei que minhas possibilidades de escolha estavam na realidade ou pelo menos proximas dela!!!

O mundo real nem sempre é o melhor.

‘Vamos ficar no mundo real’ me faz sentir acomodado, e por isso devemos ir atrás de melhores soluções, assim como a comunidade hype do Ruby está tentando convencer de que existem ganhos em produtividade no desenvolvimento, o outro lado tenta também mostrar que essas ‘gambiarras’ de transformar objetos em dados relacionais pode ser melhorada.

Aí é que entra o modelo de dados orientado a objetos, hoje em dia existem frameworks como hibernate, que todo mundo já conhece, que faz esse trabalho árduo, mas ainda sim devemos utilizar ‘mais um’ framework, que se formos catalogar, a lista parece não ter fim.

Infelizmente ainda é pouco utilizado, mas creio que os nossos jovens e fortalecidos desenvolvedores, programadores e arquitetos podem transformar esse cenário.

Pense no dia que você estiver desenvolvendo e ficar transparente as consultas em objetos sendo refletidas em banco.
O prevayler foi um ponto marcante pra o início dessa evolução, mostrando a rapidez em consultas pesadas. Isso pode ser uma realidade na indústria de software daqui um tempo… Rapidez, Transparência, Eficiência …

Pense também em ter menos trabalho, pq alguns bancos O.O. vc não precisa criar tabelas , seus objetos persistidos são suas tabelas, nossa … meu diagrama de classes agora está mais rico!!!

Pois é, vale a pena dar uma olhada em alguns bancos O.O
http://www.db4o.com/
http://www.intersystems.com.br/isc/indexcache.csp
,entre outros …

Me mostre algum sistema decente de empresas sérias que usem banco de dados OO.

O sistema de análise de risco da maior empresa de energia elétrica do mundo usa. Mas vão migrar pra SGBDR. O banco é muito ruim.

Se SGBOs são “mundo real” ou não é outra conversa. Mas que SGBDs relacionais são um sério empecilho a um modelo realmente orientado a objetos, isso são. Apesar de ainda bastante imaturos, torço pelos bancos de objetos e vejo neles (ou em algo similar, mas no paradigma OO) o futuro do armazenamento de dados. Como disse o companheiro há 3 posts, ver SGBOs simplesmente como fantasia e colocar uma pedra sobre o assunto é imobilismo. Feramentas ORM, por mais eficientes, bem construídas e high-quality que sejam, não passam de gambiarras.