The schema is inconsistent
There is a discrepancy between the designed diagram and the foreign keys:
- you designed in your diagram a one-to-many relationship for
CryptoCurrency (i.e. one wallet could have several platforms, storage or currencies), but
- the foreign keys added in the schema to the
Wallet implement a many-to-one in the opposite direction (i.e. a wallet can have only one platform, storage or currency, but those could be associated with several wallets).
Is it possible that you have a mismatch in the Hibernate definition of the associations/relations? In case of doubt, don't hesitate to update your question with the annotations you've used.
And a missing many-to-many relationship?
I’m not very knowledgeable of the wallet world, but I am very familiar with currencies. In this respect, I wonder if the relationship between
CryptoCurrency, in both the designed diagram and the foreign keys is correct:
- according to your diagram, a
Wallet can be associated with several
CryptoCurrency rows, but each crypto-currency can only be associated to a single wallet. For example, only one wallet could use bitcoins and all the other wallets have to use something else??
- according to the generated FK, a wallet could be associated to a single currency, but a currency could be used by several wallets.
I understand that a wallet should be able to hold several crypto-currencies, and a crypto-currency can be held by several wallets. That's many-to-many. There is absolutely no valid reason to avoid many-to-many if this is the reality of the domain.
Many-to-many implies the use of an association table (also called junction table, intersect table or bridge table):
- hibernate is perfectly able to generate it (see for example this SO answer).
- if you prefer, you can manually break down the many-to-many in your diagram with two one-to-many relations with an intermediate entity (
Hint: The breakdown with an additional entity makes sense if it reveals a well identified domain entity (e.g an “assignment”), and even more if it could have own attributes. But often, this is not the case and the additional entity would seems somewhat artificial; it usually start with the difficulty to find an entity name. In this case, prefer to keep your diagram simple and just use a junction table without promoting it to a full-blown entity