Master-Detail mit many-to-many Relation

[Stevie]

Ich habe zwei Tabellen, die in einer many-to-many Beziehung stehen. Dies ist über eine dritte Tabelle abgebildet.

Ich habe drei Datasets, welche den Inhalt dieser Tabellen liefern. Diese möchte ich in einer Master-Detail Beziehung darstellen (in welchem Control sollte erstmal egal sein) Dabei möchte ich aber die Many-To-Many Datenmenge nicht darstellen. Diese Vorgaben sind unveränderbar. Wie löst man das am besten?

[mkinzler]

Bei Master-Detail ist doch unerheblich, ob der Detaildatensatz noch andere Master hat. Oder verstehe ich dich falsch?

[Stevie]

Mal ein ausgedachtes Beispiel: ich habe 3 Tabellen: Books, Authors und BookAuthors und möchte nun alle Authoren auflisten und als Detail die Bücher, wo sie Authoren sind. Dann kann ich Books nicht direkt über eine simple Master-Detail Beziehung zuordnen, sondern muss diese "künstliche" Tabelle als Zwischenebene haben, da eben ein Buch bei mehr als einem Author auftauchen kann. Das möchte ich aber in der Anzeige nicht sehen.

Tut mir leid, dass ich das etwas theoretisch halten muss, da ich an keinem konkreten Fall arbeite sondern an einer allgemeinen Lösung, mit der ich solche Relationen hierarchisch anzeigen kann ohne diese many-to-many Mengen als eigene Ebene anzuzeigen.

[p80286]

Was hast Du vor?
wenn ich Dich richtig verstanden habe, dann hast Du z.B. eine Tabelle mit Häusern, eine Tabelle mit Putzfrauen und die Verküpfung "Welche Putzfrau putzt wo und wann".
Dann willst Du als Ausgabe "Adresse"-"Putzfrau" oder umgekehrt haben?

SQL-Code:

selecttab1.wertA,tab3.WertB
from tab1,tab2,tab3
where tab1.id1=tab2.id1
  and tab3.id3=tab2.id3

gruß
K-H

P.S. welche anzeige?

[mkinzler]

Einfach einen Join verwenden

SQL-Code:

select
    b.* 
from
    books b
where
    b.id in ( select book from BookAuthor where autor = :autor);

[Stevie]

Wie man die Daten per SQL erhält, weiß ich sehr wohl

Zitat von Stevie:

Ich habe drei Datasets, welche den Inhalt dieser Tabellen liefern. ... Diese Vorgaben sind unveränderbar.

Zitat von mkinzler:

Einfach einen Join verwenden

SQL-Code:

select
    b.* 
from
    books b
where
    b.id in ( select book from BookAuthor where autor = :autor);

Mit diesem Ansatz hätte ich dann n+1 Abfragen (n = Anzahl der Authoren). Ziemlich unpraktisch. Von den redundanten Records bei Büchern, die mehr als einen Author haben, mal nicht zu reden.

Ziel ist es, einen universellen Ansatz zu haben, wie man 2 Datasets, die über ein 3. Dataset in einer many-to-many Beziehung stehen, in einer Hierarchie (z.B. treeview) darstellen kann. Die eigentliche Darstellung ist erstmal unerheblich, sondern nur die Aufbereitung bzw die Verbindung der Datasets zu regeln.

Ich greif nochmal mein Beispiel mit den Büchern auf:

Hätte ich ein Datenmodell, wo ein Buch nur einen Author haben kann (also ein AuthorId Feld in der Books Tabelle), dann würde man das Authors Dataset als Master nehmen und das Books Dataset als Detail und diese über AuthorId verbinden.

Da ich aber nun 2 Ebenen von 1 zu n Beziehungen habe würde das wie folgt aussehen:
Master1: Authors
Detail1: BookAuthors (DetailKey = AuthorId, MasterKey = AuthorId

Master2: BookAuthors
Detail2: Books (DetailKey = BookId, MasterKey = BookId)

Aus diesen 2 1-to-n Beziehungen möchte ich aber wieder eine n-to-n Beziehung bauen.
Das sähe etwa so aus:
Master: Authors
Detail: Books (DetailKey = BookId, MasterKey = bookauthors.bookid where bookauthors.authorid = authors.authorid)

Hoffe, das Problem ist etwas klarer geworden.

[WM_CLOSE]

Ich habe das jetzt mal so verstanden:

Du hast eine Tabell Bücher
Buchdaten | BuchId

Eine Tabelle Autoren
AutorId | Autordaten

Und eine Tabelle mit den Verweisen
BuchId | AutorId

Du willst z.B. alle Bücher eines Autors haben:

Code:

SELECT Buchdaten FROM BuchTabelle JOIN VerweisTabelle ON (BuchTabelle.BuchId=VerweisTabelle.BuchId) WHERE (VerweisTabelle.AutorId=AutorId)

Ohne Gewähr, dass das Query richtig rum ist

[FredlFesl]

Lies doch einfach die drei Tabellen in den Speicher.
Du hast doch eine Master-Detail-Beziehung. Dann zwei Grids, links Autoren, rechts die Bücher, Filter in den Büchern setzen, fertig.
Gut der Filter in der Bücher-Tabelle ist nicht ganz trivial, aber mit einer Hashmap wirklich schnell umgesetzt.
Sei BooksAndAuthors die Relationstabelle mit zwei Spalten (na gut, 3, aber den PK vergessen wir) "AuthorID" und "BookID".
Dann erstellst Du eine <Int, List<Int>>Hashmap. Key ist die AuthorID und pro Author wird eine Liste der BookIDs in der Map abgelegt.
Wenn du durch die Autoren scrollst, dann filterst Du die Bücher einfach jeweils neu, indem Du beim Scrollen die zum fokussierten Autoren-datensatz gehörende jeweilige BookID-Liste aus der Hashmap holst und dann nur die Bücher anzeigst, die in der Liste sind.

Das geht auch ohne Hashmap, weil eine gute DB das auch (fast) in Echtzeit hinbekommt. Bei jedem scrollen in der Autorentabelle einfach ein

Code:

Select b.* from Books b join BooksAndAuthors ba on b.bookid = ba.bookID where ba.AuthorID = :AuthorID

absetzen... des ist fast genauso schnell. Cachen kann man das auch noch, falls Du die Amerikanische Staatsbibliothek mit der Software ausrüsten willst...

Oder hab ich dein Problem nicht verstanden?

[Stevie]

Ums nochmal klar zu machen: Ich brauch und will kein SQL Statement.

Ich möchte eine Möglichkeit haben, beliebige Datenmengen (Datasets), die in Relationen stehen, hierarchisch darzustellen und weitergehend auch beliebig gruppieren zu können.

Der Ansatz mit der Hashmap geht schonmal in eine brauchbare Richtung. Allerdings will ich meine Daten nicht in Grids anzeigen, sondern in einem einzigen Tree Control. Dazu möchte ich aber die Datenstruktur nicht komplett auf Objektebene oder so neu aufbauen, sondern beim Aufbau der Nodes die Daten über eine vorher festgelegte Struktur aus den Datasets auslesen.
Bei dem Bücher Beispiel wäre dass in der ersten Ebene Authors und zweite Ebene Books. Die Relation dieser beiden Ebenen (also, welche Bücher unter welchem Author aufgelistet werden) wird dann über die many to many Relation abgebildet. Das ganze soll so flexibel sein, dass ich z.b. das ganze auch umgruppieren kann und z.B. in der ersten Ebene das Genre, zweite Ebene Bücher und dritte Ebene Authoren abbilde.

Das ganze wird wohl auf ein Filtern des untergeordneten Datasets der jeweils im Aufbau befindlichen Node hinauslaufen.

[FredlFesl]

Hi. Das SQL-Statement war eher für andere Leser gedacht und diente der Verdeutlichung meiner Idee. Das Du SQL kannst, hast Du ja nun bereits erwähnt.

Ich sitze derzeit an einem ähnlichen Problem. Bei mir geht es auch nur um die Darstellung. Ich verwende das TcxGrid, womit man ganz brauchbar gruppieren kann. Ich stelle also im Grid die komplette Autor-Bücher Beziehung dar (Autoren und Bücher kommen dann mehrfach vor). Ich kann angeben, das in einer Spalte ein mehrfach hintereinander vorkommender Wert nur 1x dargestellt wird.

Sortiere ich nach Autoren, erhalte ich pro Autor (linke Spalte) alle Bücher, etwa so:

Code:

Autor  v| Buch
===================
Autor-1 | Buch-1-A1
        | Buch-2-A1
-------------------
Autor-2 | Buch-1-A2
        | Buch-2-A1   <<<--- Achtung, Buch kommt doppelt vor

Sortiere ich nach Büchern, erhalte ich:

Code:

Autor   | Buch    v
===================
Autor-1 | Buch-1-A1
-------------------
Autor-2 | Buch-1-A2
-------------------
Autor-1 | Buch-2-A1
Autor-2 |

Das ist ja sowas wie ein Baum, nur als Grid.

Google mal nach "Pivot-Grid" und schau dir diese Look&Feel Ansätze an. Im Grunde genommen ist das etwas Ähnliches (zumindest vom der Problematik, das man hierarchische Abhängigkeiten konfigurieren und darstellen muss).