Adequar o banco às entidades ou o contrário?

 @Entity public class Produto { @Id @GeneratedValue private Long id; private String nome; private BigDecimal preco; private Calendar inicioPeriodoPromocional; private Calendar fimPeriodoPromocional; // outros atributos e metodos }
@Entity public class Promocao { private Calendar inicio; private Calendar fim; //outros atributos e metodos } 

Suponha que gostaríamos de saber se uma promoção é aplicável a um produto e por quantos dias podemos aproveitar uma promoção. Colocar esse código dentro de um controller ou managed bean não parece uma boa idéia. Esse trecho rapidamente reaparecerá em outro lugar. Onde então podemos criar métodos para essa análise? Poderíamos começar criando a classe Intervalo:

E em vez de Produto e Promocao guardarem referências para duas datas, guardariam para um Intervalo, removendo os respectivos Calendars:

A criação da classe Intervalo pode trazer benefícios muito maiores do que a eliminação da repetição de atributos. Adotando a boa prática de unir dados a comportamentos, podemos isolar todo comportamento relacionado a um intervalo de datas nessa nova classe:

Para saber quantos dias temos para aproveitar a promoção faríamos:

Mas como mapeamos a classe Intervalo? Criar uma tabela e referenciar seus registros através de chaves estrangeiras nas tabelas Produto e Promocao só trará a necessidade de joins. A JPA nos oferece uma alternativa: criar uma classe Embeddable, um dos assuntos básicos abordados no FJ-25. Quando anotamos uma classe com @Embeddable, seus atributos serão colunas na tabela da entidade que tem o atributo anotado com @Embedded.

A classe Intervalo não precisa de um identificador único: ela é definida pelo seu valor e pode ser encarada como um Value Object. É importante conhecer os diversos recursos do Hibernate que nos dão a possibilidade de não precisar adequar nossas entidades às nossas tabelas, nem de adequar nossas tabelas às nossas entidades. Por exemplo, tabelas secundárias oferecem o serviço inverso: uma entidade mapeada em duas tabelas. O próprio @ManyToMany evita a criação de uma classe a mais apenas para manter referências para as duas classes relacionadas. Há ainda o suporte a chaves compostas, herança, nomenclatura das tabelas, namespaces e colunas, e até mesmo tipos definidos pelo próprio usuário para cada banco de dados diferente.