Adela,
I would have to see what you have in place for both the Data and the DataHistory descriptors in entirety to understand further. Instead, allow me to offer the following suggestions.
It seems clear that you have a need for both DataHistory and Data classes in your domain model. Seems also that your DataHistory class has two relationships of interest. One is a collection type to all of the Data instances that comprise the history in entirety. The other is the one to one relationship that represents the "current" Data instance for that DataHistory instance.
I would recommend a separation of concerns here and use two tables. If you had a DATA_HISTORY table, I can see the need for two columns, ID and VERSION, where the ID column is the lone primary key. The VERSION column can then be used for optimistic lock checking, but otherwise doesn't house any other business information.
If you then also had a DATA table, I can see the need for at least four columns there ID (primary key, orthogonal to DATA_HISTORY.ID), DATA_HISTORY_FK (points to DATA_HISTORY.ID), VALID_FROM (date not null), and VALID_TO (date). Probably no need for a VERSION column on this table since Data instances are immutable and a change to one really means adding a new instance to its history. That is if I understand your intent correctly.
In the descriptor for the DataHistory class, the one to many relationship that represents all of the Data instances can be set up to do some type of ordering and such. The "current" data instance, a one to one mapping, can be set up so that that mapping's selection criteria specifies where VALID_TO is null. You will of course have to keep that relationship up to date when a new Data instance is added to a DataHistory instance.
The descriptor for the Data class simply has the back pointing one to one relationship from the Data instance back to its owning DataHistory instance.
I think if you break those out that way, some of the complexity you described can be more easily managed.
-- Doug