你的問題有點混亂，所以我對它的解釋可能不正確。
但是，我懷疑你可以通過將選項分成兩個類來解決你的問題。使選項成爲具有兩個具體子類的抽象類，即ListOption和OTCOption，每個子類都有其自己的鑑別值（3或5）。在兩個子類中可能沒有任何不同的字段，但是這會讓您使用兩個InstrumentTypeID來表示Option。
問題是，這意味着重複您的代碼結構中的InstrumentType表中的知識，這顯然不是一件好事。
如果您想完全使用數據驅動，我認爲您必須更改Option和Stock，以使它們不是Instrument的子類。他們可能可能是InstrumentDetails接口的實現，每個類本身都是一個實體。 InstrumentType也是一個實體。然後，您可以給InstrumentType像一些代碼：
@Entity
public class InstrumentType {
private static final Map<String, Class<? extends InstrumentDetails>> STORAGE_CLASSES = new HashMap<String, Class<? extends InstrumentDetails>>();
static {
STORAGE_CLASSES.put("Option", Option.class);
STORAGE_CLASSES.put("Stock", Stock.class);
}
public InstrumentDetails getDetails(Instrument inst) {
return getEntityManager().find(STORAGE_CLASSES.get(getStorageClass()), inst.getID());
}
// NB implementation of getEntityManager() is left as an exercise to the reader
}
而且，爲了方便，對儀器本身的方法：
@Entity
public class Instrument {
public InstrumentDetails getDetails() {
return getInstrumentType().getDetails(this);
}
}
這裏，我從硬存儲類的字符串細節映射類，但是你可以從配置文件或注入動態獲取它，或許可以更容易地添加新的存儲類。