n:1 Beziehungen umsetzen

[Elephant]

Hallo,

mir geht es eigentlich im Allgemeinen darum, wie man z.B. n:1 Beziehungen in Java 'modeliert'.

Also ich habe z.B. verschiedene Autos. Jedes Auto hat ein Baujahr, ID und andere mögliche Attribute.
Jedes Auto kann außerdem einem bestimmten Autotyp zugeordnet werden. Der auch Name, ID usw. hat.

Es können mehrerer Autos zu einer Liste zusammengefasst werden, wobei alle Autos den gleichen AutoTyp haben. Nun wüsste ich gerne wie man das am besten in Klassen umsetzt.

Also ich habe zuerst einmal eine Klasse Auto mit den entsprechenden Variablen (id, name etc.).
Außerdem habe ich eine Klasse Autotyp auch mit den entsprechenden Attributen.
Die Frage ist nun, wie ich die Beziehung zwischen den Klassen 'modelieren' sollte.
Bei einer AutoListe haben z.B. alle Autos denselben Autotyp. Sollte jetzt jedes Auto-Objekt auf das gleiche
Autotyp-Objekt zeigen (also als Referenz) oder sollte jedes Auto-Objekt ein eigenes Autotyp-Objekt als Variable speichern?

Der erste Fall ist logischer (finde ich) wenn man modelieren möchte, das alle Autos der Liste vom gleichen
Typ sein müssen und wenn man dann das eine Autotyp-Objekt ändert, sind automatisch alle Autos von diesem geänderten Typ.
Es gibt aber nicht nur diese Autolisten. Wenn man jetzt also ein Auto aus der Liste nimmt und woanders 'benutzt' ist es logischer, wenn jedes Auto-Objekt ein eigenes Autotyp-Objekt besitzt, sonst müsste die Referenz auf das Autotyp-Objekt u.U. auf einen neues 'umgelenkt' werden, was vielleicht nicht so intuitiv ist.

Vielleicht weiß jemand wie man eine solche Beziehung darstellen sollte oder kann man das gar nicht so 'pauschal' sagen.
Mir geht es einfach im Allgemeinen darum, wie man solche z.B. n:1 Beziehungen darstellt.
Vielleicht kennt auch jemand eine Seite, wo gezeigt wird, wie bestimmte Beziehungen umgesetzt werden.

 

[bygones]

hä ? wo ist da die 1:n beziehung

Ein Auto -> Ein Autotyp

die Entität Autotyp wird ja kein konkretes Auto speichern, also ist es eine gerichtete beziehung.

und wieviel autos du hast ist ja dann unwichtig ?!

Bei einer AutoListe haben z.B. alle Autos denselben Autotyp

Autotyp ist ein Attribut von Auto. Somit kann jedes Auto einen anderen Typ haben ....

 

[Elephant]

Also ich meinte das z.B. so

-----------------                            ------------------|
|Auto           |                            |Autotyp          |
|---------------|n                          1|-----------------|
|id             |----------------------------|id               |
|name           |                            |name             |
|---------------|                            |-----------------|

Vielleicht ist das jetzt mit dem Autotyp ein blödes Beispiel (oder eher falsch modeliert). Ein besseres Beispiel ist vielleicht eine Beziehung Buch <-> Bibliothek oder so etwas ähnliches. In dem Buchfall wärs wahrscheinlich logisch, wenn man jeweils ein Objekt der Klasse Bibliothek hat und das eine Liste von Buch-Objekten enthält. Aber wie stelle ich dann dar, dass z.B. jeman ein Buch der einen und ein Buch der anderen Bibliothek z.B. ausleit? Also ich hätte ein Person-Objekt mit einer Liste von Buch-Objekten eigentlich. (Also alle Bücher, die er ausgeliehen hat) Wo bleibt dann die Beziehung zur Bibliothek.

Entschuldigung, wenn das einfach ne blöde Frage ist.

 

[bygones]

keine blöde Frage

meiner Ansicht nach ist das mit dem Autotyp falsch modelliert. . Das Buch Bibliothek ist denk ich besser zum Veranschaulichen.

Das Ausleihen ist das parade beispiel für eine n:n Beziehung. Eine Person kann n Bücher ausleihen aus n Bibliotheken.

N:N Beziehungen löst man über das erschaffen einer neuen Entität auf, so dass 1:n beziehungen entstehen. In diesem Fall z.b. "Ausleihe".

Die neue Entität braucht auf alle Fälle beide Schlüssel der Grundentitäten (also in unserem Fall muss Ausleihe die Person und die Bibliothek die zu ihr passen speichern - plus natürlich zusätzliche Infos).

Klingt wahr. ein bisschn verwirrend

public class Person {
   private String name;
   private String adresse;
  // usw.
}

public class Bibliothek {
   private int anzahlDerBücher;
   private String name;
  // usw;
}

public class Ausleihe {
   private Person ausleihendePerson;
   private Bibliothek bib;
   private Date rueckgabeDatum;
   private Buch dasBuch;
   
   //usw.
}

hoffe dadurch wirds ein bisschen klarer

 

[Elephant]

Ok, danke! Jetzt weiß ich, dass ich praktisch eine n:n Beziehung nehmen muss.

Wenn ich jetzt einfach Datenbanken hätte, wüsste ich auch besser wie ich das formuliere. Also z.B. vier Tabellen:

Person
persid
name

Bibliothek
bibid
name

Buch
bookid
name

Buchzugehörigkeit
bookid (foreign key)
bibid (foreign key)

Ausleihe
bookid (foreign key)
bibid (foreign key)
persid (foreign key)

Naja nicht so ganz richtig, aber nur mal so schnell.

Aber wie macht man das genau in Java, ich hab ja keinen 'Fremdschlüssel'. Wenn ich jetzt also zwei Ausleihe-Objekte anlege, für jeweils eine Person, woher nehme ich dann das Buch-Objekt und Bibliotheks-Objekt? Also ich meine, benutzt man da einen zentralen Speicher? Wäre vielleicht nicht so geschickt, oder? Und wie ist das, wenn ich nicht nur Ausleihen sondern auch einfach nur Buch-Objekte, die einer Bibliothek gehören habe, dann brauch ich eine Referenz von Buch auf Bibliothek? Oder doch nicht? Ich könnte jetzt sagen, pro Bibliothek gibts eine Liste von Büchern, da braucht das Buch an sich keine Referenz auf die Bibliothek, aber was ist wenn das Buch-Objekt irgendwo abgelegt ist, wo es keine Verbindung mehr zur Bibliothek hat, dann muss es trotzdem noch zugeordnet werden könnten.

Mmh ich kann einfach nicht wirklich ausdrücken, was ich meine...

 

[bygones]

UML ist im Grunde sehr ähnlich mit Datenbanken - wenn du dich damit auskennst so hast du das Prinzip bzw. die Problematik der Diagrammerstellung begriffen.

Das wichtigste ist aber bei solchen Fragestellungen einem klar zu werden, welche informationen brauche ich. Es bringt nichts, wenn du nun alle möglichen Fälle modellierst, und dann auf Teufel komm raus Assoziationen erstellst, die möglicherweise nie relevant sind.

D.h. mach dir klar welche Szenarien du brauchst (in UML Sprache - schreib dir die Use Cases auf). Welche infos brauch ich wirklich, welche gar nicht. Wie sind die Abläufe.

In der Softwareentwicklung steht das Skizzieren der Diagramme und dadurch das Klassendesign an allerletzter Stelle (von Refactoring mal abgesehen). Diese ergeben sich logischerweise aus den Schritten vorher (z.b. Use Case Analyse).

Dadurch wäre es müsig nun zu diskutieren, wer welche assoziation braucht, da dies von Fall zu Fall verschieden ist

 

[Elephant]

Danke, ich glaub das ist grad mein Problem, die Modellierung. Ich modelliere schon ewig hin und her. Und hab schon sehr viel probiert und am Ende bin ich doch nicht zufrieden, weils entweder zu umständlich oder zu 'redundanzlastig' oder, oder, oder,... ist. Deswegen habe ich gedacht, es gibt irgendwelche Muster oder so. Wie bei den Design Patterns, die einem in etwa sagen können wie man etwas realisiert.

In meinem Fall ist es so, es gibt eine Liste von gleichartigen Objekten (also Bibliothek, die Bücher enthält). Jedes Buch, kann jetzt z.B. in einer Beziehung zu einem anderen Buch stehen (also jeweils zwei Bücher) oder als einzelnes Objekt dargestellt werden. Das heißt es ist eigentlich 'herausgelöst' aus der Bibliothek braucht aber noch eine Referenz auf ein Bibliotheks-Objekt. Naja, ich werde wohl nochmal überlegen müssen

 

[Elephant]

Ich habe nur noch eine Frage,

Setzt man 'Fremdschlüsselbeziehungen' in Java immer mit Referenzen auf die entsprechenden Objekte um oder auch indem man einfach die ID eines Objektes als int oder String etc. speichert und dann über eine Hashtable z.B. auf das Objekt zugreift?

 

[bygones]

im Normalfall würde ich eine Objektreferenz wählen. Man erspart sich somit das zusätzliche Mapping von ID -> Objekt

 

[Elephant]

Ok, danke!

 

[Elephant]

Entschuldigung, dass ich schon wieder frage, ich hoffe es nervt nicht. Ich habe noch eine Frage zu JTables/JTrees und Datenbanken.

Das war schon ziehmlich oft Thema hier im Forum, aber so richtig habe ich keine Antwort gefunden. Deshalb frag ich nur in dem Thread und mach nicht erst einen neuen auf.
Ist es sinnvoll, wenn man aus den Einträgen in der Datenbank Objekte erstellt, die dann im Hauptspeicher liegen, und auf die man dann zugreift um sie in verschiedenen JTables, JTrees z.B. darzustellen und zu aktualisieren und wenn man dann alles erst 'am Ende' zurückschreibt? Oder sollte zwar jede 'View' die Daten für sich 'cachen' aber Änderungen gleich zurückschreiben und die anderen 'Views' holen sie sich dann direkt aus der Datenbank?

 

[bygones]

ich befürchte auch hier ist keine generelle Lösunf möglich.

Handelt es sich um eine Datenmenge, die du ohne Probleme im Speicher halten kannst und schafft es dir Vorteile sie im Speicher zu halten, dann tu es.

Sind es aber Datenmengen, die den Speicher sprengen würdern oder im Grunde egal was mit ihnen passiert würde ich sie gleich "ablegen"

 

[Elephant]

Danke,
ich seh schon, da gehört eine ganze Menge Erfahrung dazu um die richtige Umsetzung für das richtige Problem zu wählen. Dann werde ich mir mal mehr Erfahrung erarbeiten

 

[bygones]

Danke,
ich seh schon, da gehört eine ganze Menge Erfahrung dazu um die richtige Umsetzung für das richtige Problem zu wählen. Dann werde ich mir mal mehr Erfahrung erarbeiten

ja - bei einer (guten) Projektentwicklung ist das eigentlich programmieren der kleinste Teil und ergibt sich logischerweise aus dem Haufen arbeit den man vorher gemacht hat.