Olá amigos, este é meu primeiro post e estou começando a navegar neste “novo” mundo O.O.
Este post-dúvida é sobre análise e projeto OO:
Estou mudando de paradigma (de Estruturado para OO) no desenvolvimento de sw, mas a forma de armazenar minha base de dados continua sendo o bom e velho modelo relacional.
Num projeto estruturado e relacional era elaborado um DER (diagrama de entidade relacionamento) em seguida normalizava os dados (seguindo as formas normais) e construía o DTR (diagrama de tabela relacionamento) depois gerava o banco a partir do mesmo.
[B]Num projeto OO (com DB relacional) como proceder no projeto do DB?[/B]
Não estou falando de implementação (hibernate, etc.), estou me referindo ao projeto do banco… onde vou buscar as informações necessárias para construir o DB?
No momento tenho 2 suposições:
1 - depois de construir o diagrama de classes relativo ao modelo (classes que devem ser persistidas) criaria o banco tendo como base tais classes.
[B]ou[/B]
2 - o projeto da base de dados relacional é “independente” do modelo OO e deve-se continuar com o velho esquema DER->Normalização->DTR->DB.
Qualquer sugestão, indicação de artigo ou livro é bem-vinda.
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.
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!
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.
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?
[quote=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.[/quote]
É 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…)
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.
‘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!!!
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.
