[RESOLVIDO] Modelagem de BD e Classes Java

thimfont

Essa é uma dúvida que tenho a anos: Banco ou código? Se me permitir gostaria de acompanhar os que os colegas mais experientes Javeiros tem a discorrer sobre.

Claro Rickzale. Pois é, quando o trabalho envolve apenas modelagem de um dos lados (hora só no BD ou hora só no Java), ainda vai, mas quando é preciso “juntar tudo”, as dúvidas aparecem … kkkk

O que devo modelar primeiro, o BD ou as Classes Java?

R - vai depender do sistema e dos requisitos Funcionais, possui duas abordagens:

Buttom - up - começa pelo banco;
top - down - Começa pela aplicação.

Quantas tabelas terei no meu Banco? Serão 2 (Usuario e Conta)?

R - terá 4 tabelas, 1 Usuário, 1 conta, 1 poupanca referenciando a tabela conta, e 1 corrente referenciando a tabela conta.

Olá Sandro,
tudo bem?

Interessante. Quer dizer que o número de tabelas e classes são equivalentes, ou seja, sempre 1 tabela representa 1 classe e vice versa?

Por que você quer construir sua arquitetura em cima da incompatibilidade do modelo relacional com o modelo de objetos?

De modo geral sim, mas a pergunta é: todas as classes serão persistidas no banco?

caso não, então não terá tabelas < classes.

a exemplo temos as classes DAO, que possuem apenas métodos de persistência, mas não possuem tabelas no banco.

então resumindo, terá uma tabela no banco para cada classe que queira persistir.

Legal Sandro. Irei criar um modelo para testar.

Obrigado pela ajuda.

Olá Pfk66. Com certeza você “manja” muito mais que eu…rsrs Não sei responder a sua pergunta e também não saberia fazer de outra forma, então, qual é a incompatibilidade existente? Qual a outra alternativa?

Valeu!

Parece que sim.

Você fala entre um grafo de objetos e uma estrutura relacional tabular?

São estruturas diferentes.

Alternativa a que?

Oi Pfk66,
vamos lá.

Você me perguntou:

Por que construir sua arquitetura em cima da incompatibilidade do modelo relacional com o modelo de objetos?

Eu nem sabia que eram incompatíveis e por isso pedi para me ajudar a entender qual lé esta incompatibilidade que você fala/enxerga.

Uma vez que há uma incompatibilidade entre modelo relacional e modelo de objetos, como deve ser feito para que não haja incompatibilidade?

Valeu!

Se esta com problema pra mapear 2 objetos, imagina uma aplicação real. rsrs

Não da pra simplesmente mapear uma coisa na outra e não querer encontrar essas perguntas difíceis. O nome disso é incompatibilidade.

A questão que eu fiz é qual seu objetivo. Porque se for criar algum framework ORM, então va em frente, vai ser uma experiência util, mas se for criar aplicações com BD… talvez seja melhor aproveitar seu tempo de maneira mais produtiva, pensando na experiência de uso da app ou entendendo o negócio do cliente, por exemplo.

É apenas uma dúvida pfk66. Por hora, o objetivo é puramente acadêmico. Apenas gostaria de entender conceitualmente como fazer, sem utilização de qualquer framework, pensando apenas na modelagem.

Tive um professor que dizia que o principal era ter um banco de dados bem estruturado assim a parte de programação fica mais fácil, neste exemplo que você deu tanto faz, mas em um sistema mais complexo se o seu banco de dados estiver normalizado e com todos os relacionamentos corretos fica mais fácil na hora da programação seja usando hibernate ou JDBC.

Interessante Paulo Maia. Valeu por compartilhar.

Para a galera que acompanhou ou leu o post até aqui … kkk segue uma outra maneira, sugerida por amigo meu.

Ele comentou que talvez não haja uma regra/padrão no que se refere a modelagem do BD ou a Classe primeiro. Mas, ele prefere modelar primeiro as classes.

Sobre a quantidade de tabelas, a ideia é criá-las baseando-se nas entidades, ou seja, as classes que implementam as interfaces (isto referindo-se ao meu exemplo).

Assim, tendo 1 interface Conta e as classes ContaCorrente, ContaPoupanca e Cliente, seria preciso ciar 3 tabelas no BD.

Fiz alguns testes aqui e neste modelo parece funcionar bem.

Abraço.

Funciona bem para exemplos fantasiosos ou triviais.

No mundo real nenhum desenvolvedor quer ficar mapeando objetos para tabelas e vice-versa na mão porque é uma atividade repetitiva e propensa a bugs, sem falar que isso não é OO.