MER x ORM

Correto. O MER - Modelo Entidade x Relacionamento - eh apenas uma visualizacao grafica que nos ajuda a enxergar o modelo de dados como um todo, inclusive com os relacionamentos. Essa visao ampla facilita a localizacao de redundancias e a otimizacao da base (o que corresponde mais ou menos a normalizacao). As formas normais do BD devem ser respeitadas ate o limite do bom senso - ha muitos casos em que normalizar demais torna o banco simplesmente uma lesma de tao lento ou tao abstrato que fica dificil ate de ser enxergado por alguem que nao participou da modelagem.

O Hibernate simplesmente 'e uma camada de ORM no sentido de mapear sua aplicacao Java (com seus DAO’s, DTOs ou seja la o padrao que voce usar) e o banco de dados - o conflito tao discutido entre mundo orientado a Objetos e o mundo Relacional, que consiste nada mais que texto plano muito bem manuseado pelo SGBD.

ORM 'e isso - conectar suas classes de dominio as respectivas tabelas no banco de dados. O Hibernate encapsula/abstrai toda a parte de queries montadas no braco (imagine uma classe DAO para cada entidade de seu dominio, com as 4 operacoes basicas CRUD e mais um pouco). Haja braco pra escrever codigo !!! Alem do mais, suas classes ficam com alto acoplamento – uma alteracao nas regras de negocio ou no banco de dados e voce tera muito trabalho por aqui.

Alteracoes estruturais devem ser evitadas sempre que possivel, mas quando nao ha jeito, temos de encarar. FAzer o que ? Por isso eh importante ter baixo acoplamento. Utilizando o hibernate (ou um JPA provider qualquer) voce tera de alterar as anotacoes de suas classes de dominio, os getters e setters e os trechos de codigo em que seu DAO instancia seu objeto de entidade e o manipula. Na pratica isso eh MUITO menos doloroso do que alterar SQL’s, chamadas de preparedstatement alem de tudo o que eu ja disse acima. Eh menos doloroso. Mas o importante aqui 'e dizer que MER e ORM sao coisas distintas, que se complementam. O MER produz uma base de dados " enxuta", enquanto que o ORM " interfaceia" entre sua aplicacao e essa base.

Voce pode sim criar sua base a partir de seu modelo de classes, utilizando os recursos do hibernate ('e o que muitos recomendam, e teoricamente seria o correto em um mundo lindo orientado a objetos). Para definir seu modelo de classes, muitas vezes voce utiliza ideias da modelagem de dados como os relacionamentos entre as entidades (por exemplo, tabelas de relacionamento no seu banco nao possuem classes que a referenciam e sim apenas um mapeamento de relacionamento no modelo de classes).

Desculpe se ficou um pouco confuso, acabei escrevendo demais. Mas acho que deu pra pegar a ideia, na hora de modelar o dominio acho que MER e ORM se complementam.

Abraco!

Obrigado TiD!

Então se MER e ORM (Hibernate, neste caso) se complementam, preciso esta “afiado” em ambos, não?

Notou minhas preocupações? i) modelar da melhor maneira possível, para evitar ter de “remodelar” e ii) se tiver mesmo de remodelar, fazer de maneira menos “dolorida”?

Enquanto estou desenvolvendo pet projects nem deveria estar “tão preocupado” com isso, mas como eu disse, tremo só de pensar neste tipo de “alteração” em um BD em Produção… alguma outra dica, neste sentido? :roll:

Nao que voce tenha que estar afiado em ORM… o papel do hibernate 'e estar afiado nisso pra voce pra que voce foque seus esforcos nas regras de negocio do projeto. Alias… todas essas abstracoes e camadas tem como um dos principais objetivos isso… que voce esqueca um pouco a parte repetitiva e de infra pra se concentrar nas regras de negocio. Mas eh bom saber o que esta acontecendo, 'e legal conhecer o hibernate (ou o provider) um pouco a fundo para ter nocao do que acontece na aplicacao.

MER eh uma tecnica de modelagem… eh interessante saber sim. Ajuda muito na hora de modelar o dominio.

Essa dúvida pcassiano é fantástica!

Trabalho com OO (Object Oriented) desde da década de 90, uma tecnologia que surgiu na década de 60. No entanto na hora de modelar uma aplicação em OO com baixo uso de banco de dados, como um SO (Sistema Operacional), um CAD (Computer Aided Design), um CAE (Computer Aided Engineering), processadores de textos, planilhas e vários outras aplicações de uso acadêmicos e científicos, a Orientação a Objetos com todas as suas propriedades servem ao seu propósito para a qual foram criadas. No entanto quando a aplicação possui uma alta utilização de um banco de dados a história é outra totalmente diferente.

Como as linguagens e programadores já foram treinados em OO, somos tendenciosos em utilizar este recurso da linguagem para modelarmos o negócio e consequentemente ocorre uma alinhamento do Banco de dados feito utilizando MER com todas as regras formais conhecidas e a utilização de uma modelagem dos objetos da aplicação. Ou seja, dupla modelagem! Essa dupla modelagem, a princípio se justificaria para escrevermos menos na utilização com OO na linguagem. Já que os bancos de dados em sua maioria ainda não são orientado a objetos (Se o BD fosse orientado a Objetos ORM não se justifica). Além disso duplicar informações da tabela para o objeto é algo redundante.

No entanto, metalinguagens criadas a partir de 2000, muda essa história! Principalmente metalinguagens que são framework de linguagens que utilizam O.O. em sua estrutura funcional e não na estrutura do modelo negócio (Não vou citar essas linguagens, pois não estou defendendo nenhum tipo de linguagem). Com um framework inteligente é possível escrever muito pouco durante a programação, seja num simples CRUD ou numa funcionalidade mais complexa da aplicação.

Somando a isso ao fato de que os negócios de uma empresa evoluem e mudam 10% a cada 3 meses e 30% a cada ano. A aplicação precisa ser de rápida resposta e de fácil modificação (A lei do menor esforço é a lei da natureza e dos negócios). Estou falando apenas do ERP da empresa que tem que funcionar junto com BI, BPM e outras inúmeras siglas, que hoje obviamente ter que ser tudo via navegador (esquece aplicação desktop para estes casos empresariais).

Se for uma aplicação de negócio, um ERP por exemplo, aconselho uma metalinguagem com um bom framework e esquece ORM, porque é perca de tempo. Por fim estamos num fórum de Java, portanto se sua aplicação é em Java a boa prática da programação vai te pedir para usa ORM. Mas é fato, este é um encargo das linguagens OO que migraram do desktop para o navegador e não foram remodeladas ou concebidas para este fim.

Espero ter ajudado!

Interessante essa visão.