Oracle Hibernate M:N-Beziehung mit nur einer vorhandenen Tabelle

[Guuustav]

Hallo,
ich habe folgendes Datenbankschema (Tabellen Inhalte sind fiktiv für das Beispiel):

Nutzer
- Nutzer-ID
- Name
- ...

Nutzer-Daten
- Nutzer-ID
- Daten-ID


Jeder Nutzer kann verschiedene Daten-IDs haben, jede Daten-ID kann aber auch von mehreren Nutzern genutzt werden, also eine M:N-Beziehung.

Ok, im allgemeinen kein Problem dies zu modellieren, wenn es noch eine Daten-Tabelle gibt.
Die Daten-IDs sind aber in keiner extra Tabelle gehalten, da in der Datenbank keine weiteren Informationen vorliegen und sie von einem Programm generiert und später auch wieder weiter verarbeitet werden.

Wie kann ich dies modellieren?

In der Art würde ich es mir vorstellen:

@ManyToMany(cascade = CascadeType.ALL)
@JoinTable(name="Nutzer-Daten",
		   joinColumns = {@JoinColumn(name = "Nutzer-ID")},
		   inverseJoinColumns = {@JoinColumn(name = "Daten-ID")})
public List<Integer> getDaten()
{
	return daten;
}

So dass er dann einfach die Integer die er in daten gespeichert hat als Inhalt für Daten-ID nimmt.

Wie zu erwarten kommt:
Use of @ManyToMany targeting an unmapped class: ....daten[java.lang.Integer]

Wie kann ich dies so modellieren, dass es geht?

Danke für die Hilfe

 

[bERt0r]

Wenn die DatenIds nicht näher beschrieben sind in der Datenbank - also in einer eigenen Tabelle DatenIds - macht es auch keinen Sinn eine Relation darauf einzurichten. Wenn sie nur in der einen Tabelle neben den NutzerIds gespeichert werden, sind sie einfach ein Attribut.

 

[nillehammer]

Das, was bERt0r geschrieben hat, stimmt. Wenn es keine extra Tabelle gibt, ist es keine Relation sondern ein Attribut. Um dieses in eine Spalte der Tabelle zu mappen sehe ich zwei Möglichkeiten:
- Nutze eine ArrayList von Integers. In dem Fall auch wirklich den Typ so definieren und nicht List. Die JPA-Implementierung erkennt ArrayList als Serializable und mappt das in eine BLOB-Spalte der Tabelle. Ist nur doof, weil erstens nur JAVA-Clients was mit diesen Binärdaten anfangen können und zweitens man in der Spalte nur binären Kauderwelsch sieht.
- Nutze eine Spalte vom Typ Array(int). Dafür brauchst Du dann aber einen Custom Usertype. Ist also etwas mehr Aufwand aber wenigstens sieht man die Daten in der Tabelle und auch non-Java Clients haben wenigstens die Chance, die Daten zu verarbeiten.

 

[nillehammer]

Warte mal. Ich hab mir den Code nochmal näher angeschaut. Ich glaube, was Du suchst ist einfach @ElementCollection.

 

[Guuustav]

Hallo,
Danke für die Antworten.

Dass hier m:n-Beziehung nicht das richtige Werkzeug ist, habe ich mittlerweile auch bemerkt. War zu sehr in der Denkweise dieses Schemas (da es irgend wo schon noch eine andere Seite gibt und zu dir ist es eine m:n Beziehung. Aber nicht in dem was ich abbilden will).

Über Elementcollection habe ich gelesen:

The JPA 2.0 specification does not provide a way to define the Id in the Embeddable. However, to delete or update a element of the ElementCollection mapping, some unique key is normally required. Otherwise, on every update the JPA provider would need to delete everything from the CollectionTable for the Entity, and then insert the values back. So, the JPA provider will most likely assume that the combination of all of the fields in the Embeddable are unique, in combination with the foreign key (JoinColunm(s)). This however could be inefficient, or just not feasible if the Embeddable is big, or complex.

Deshalb habe ich mich nun für eine bidirektionale 1:n-Beziehung entschieden.

Das einzige was ich an der Lösung nun doof finde ist, dass die Nutzer-Tabelle eine zusätzliche Spalte bekommen hat, die ich mit @Id in der Java-Klasse für die Entity betiteln konnte.

d.h.:
Nutzer-Daten
- ID
- Nutzer-ID
- Daten-ID

Im Prinzip würde Nutzer-ID und Daten-ID zusammen auch einen Primärschlüssel geben aber ich habe nicht gefunden, wie ich das mit Hibernate modelieren kann. Ohne eine @Id Spalte wurden immer Exceptions geworfen.

 

[nillehammer]

Ich denke nach wie vor doch, dass @ElementCollection die richtige Wahl ist. Die NutzerId, DatenId ist für mich keine eigene Entität und sollte auch nicht so modelliert werden. Vielmehr ist es einfach (wie auch Dein Java-Code ganz deutlich macht) eine Liste(die Collection) von Integers (die Elemente) an der Nutzer-Entity. Um den Listen-Index mit zu speichern, ergibt das eine Tabelle mit drei Spalten: NutzerId (der Fremdschlüssel), DatenId (der Element-Wert) und Index (der List-Index). Falls Du darauf verzichten kannst, modelliere es als Set<Integer> oder sogar als SortedSet<Integer>. Dann sparst Du Dir die extra Index-Spalte. Das passt auch besser, da die DatenIds ja nicht mehrfach zugewiesen werden sollen. Damit bist Du auf Java-Seite sauber. Ich meine sogar, dass dann der Unique-Constraint richtig generiert wird.

Aber des Menschen Wille ist sein Himmelreich. Falls Du es also doch anders machen willst. Hier noch der Hinweis, dass man bei Hibernate durchaus die @Id auch über mehrere Felder setzen kann. Die Tatsache, dass Du das musst, und dass es keine weiteren Felder gibt, sollte Dir aber schon zeigen, dass es keine richtige Entität ist.