MER x ORM

[pcassiano 0]

Aprendi que devemos Modelar corretamente nosso BD (usando o MER) e devemos também Normalizar nosso BD, e ambos os procedimentos servem para melhor armazenar e recuperar dados; e pelo pouco que sei, o Hibernate faz o mapeamento ORM - exatamente de objetos para tabelas - o que em si é algo muito bom.

 

Minhas dúvidas começam justamente aí... se devemos Modelar/Normalizar o BD corretamente, a primeira pergunta seria: "então, pra quê usar o Hibernate"? Não seria melhor escrever um bom código Java para acessar um bom BD, bem Modelado/Normilizado, "diretamente"?

 

No caso do MER, o certo seria Modelar e Normalizar corretamente antes de criar o BD em si, mas a gente sabe que isso nem sempre é possível e que, diante de possíveis "alterações" na estrutura dos dados, sei lá, devido a mudanças nas "regras de negócio", teríamos de remodelar tudo de novo... Num caso como este, como proceder: se já existe um BD "em produção", Modelado e Normalizado "corretamente", com "dados reais", mas existem "alterações estruturais" a serem feitas? O que fazer para "garantir as alterações estruturais sem perder os dados já 'imputados'"?

 

No caso do Hibernate, a impressão que tenho é que o mapeamento ORM "livra" o programador de ter de Modelar e Normalizar, é isso mesmo? Ou é preciso conhecer modelagem ER e Normalização de BD para "criticar" (e/ou "editar") o mapeamento gerado pelo Hibernate? Usando o Hibernate, possíveis alterações na estrutura dos dados são mais "fáceis" de serem implementadas? E como ficam os dados "já imputados"?

[Vergil 15]

Acho que você está fazendo uma pequena confusão quanto aos conceitos. A principal função do Hibernate é tratar as tabelas do seu banco de dados como classes de entidade. Com o Hibernate você não teria um diagrama de entidades e relacionamentos, e sim um diagrama de classes.

 

Java é uma linguagem orientada a objetos. Sendo assim, manipular dados de um banco como objetos torna seu código muito mais simples, legível, escalável e fácil de manter.

 

O Hibernate livra o desenvolvedor de diversas preocupações. Entre elas está o gerenciamento do pool de conexões, concorrência de acesso a dados, etc.

 

O Hibernate permite que o desenvolvedor faça insert, update, delete e select sem que seja necessário incluir comandos SQL no seu código fonte Java.

 

O Hibernate disponibiliza uma linguagem própria: HQL. Que permite ao desenvolvedor fazer consultas ao banco com uma linguagem orientada a objetos.

 

E não menos importante, o Hibernate torna sua aplicação independente de banco de dados.

[Giovanni Ritchie 0]

Acho que você está fazendo uma pequena confusão quanto aos conceitos. A principal função do Hibernate é tratar as tabelas do seu banco de dados como classes de entidade. Com o Hibernate você não teria um diagrama de entidades e relacionamentos, e sim um diagrama de classes.

 

Java é uma linguagem orientada a objetos. Sendo assim, manipular dados de um banco como objetos torna seu código muito mais simples, legível, escalável e fácil de manter.

 

O Hibernate livra o desenvolvedor de diversas preocupações. Entre elas está o gerenciamento do pool de conexões, concorrência de acesso a dados, etc.

 

O Hibernate permite que o desenvolvedor faça insert, update, delete e select sem que seja necessário incluir comandos SQL no seu código fonte Java.

 

O Hibernate disponibiliza uma linguagem própria: HQL. Que permite ao desenvolvedor fazer consultas ao banco com uma linguagem orientada a objetos.

 

E não menos importante, o Hibernate torna sua aplicação independente de banco de dados.

 

 

Só pra complementar, usando JDBC e alguns design paterns você tbm pode conseguir a tal "independencia de bancos", até pork o proprio hibernate usa JDBC... mas concerteza o HIbernate facilidade demais o nosso trabalho, tanto que foi se basenado nele que se criou a especificão JPA.. então vale a pena usar e confiar...