Eine Tabelle verweist auf sich selbst

[Flogo]

Ich versuch grad meine erste Datenbankanwendung (Ein CD/Platten-Archiv) zu schreiben und bin dabei auf folgendes Problem gestoßen:


In einer Tabelle will ich die Künstler ablegen.
Jeder Künstler soll mit mehreren anderen Künstlern in Verbindung stehen können (Unterschiedliche Projekte von einem Künstler, Verwandschaften usw.)
Die Art der Beziehung ist dabei nicht wichtig. Es geht nur drum von einem Künstler auf eine Handvoll andere zugreifen zu können.

Wie kann ich diese Verknüpfung machen?
Ist eine Tabelle möglich die sich mit zwei verschiedenen Fremdschlüsseln auf den gleichen Hauptschlüssel bezieht?

Beziehung
=========
PK Beziehung_ID
FK Künstler_ID
FK Künstler_ID

[2_daniel]

hi!

Zitat:

In einer Tabelle will ich die Künstler ablegen.
Jeder Künstler soll mit mehreren anderen Künstlern in Verbindung stehen können (Unterschiedliche Projekte von einem Künstler, Verwandschaften Wink usw.)
Die Art der Beziehung ist dabei nicht wichtig. Es geht nur drum von einem Künstler auf eine Handvoll andere zugreifen zu können.

Wie kann ich diese Verknüpfung machen?

Wenn die Tabelle so asussieht...

Beziehung
=========
PK Künstler_ID ..dieser Künstler
FK Beziehung_ID ...hat diese Bezieuhng
ToKünstler_ID ...mit dieser Künstler

Dann...

SELECT Künstler_ID AS Künstler , ToKünstler_ID AS Bezieuhng_zu ...hier hast du dein Künstler und der Künstler zu dem er eine Bezuiehung hat.
FROM Beziehung
WHERE Bez.Beziehung_ID = <die Gewünschte Beziehung>
AND Künstler_id = < dein gesuhtes Künstler> ....hier das Wichtigste!!! so legst du fest wie die Verknüpfungen aussehen

..damit hast du einen Künstler ausgewählt und kriegst all seine PArtner mit der er in eine Beziehung steht.

wenn du ALLE mit ALLE ( kartesicher prodzukt aller Beziehungen ) dann:
Select bez1.Kpnstler _id, bez2.Künstler_ID
from Beziehung AS Bez1 , Beziehung As bez2
where bez1.ToKünstler_ID = bez2.Künstler_ID

..im Gross und Ganzen sieht deine Abfrage so aus. Jetzt kommen DB-abhängige Änderungen noch dazu .

gruss,
daniel

[Robert_G]

Zitat von Flogo:

Ist eine Tabelle möglich die sich mit zwei verschiedenen Fremdschlüsseln auf den gleichen Hauptschlüssel bezieht?

Sicher ist es das.

Aber doch nicht über solche kranken Namen! Wie willst du denn sowas in deinem Programm abbilden?
Mache nicht den Fehler dieser ganzen DB Hirnies, die damit später nicht arbeiten müssen. (oder wollen <g> )
*sich einen Spruch zu wohl 80% aller Datenbanken verkneift...*

Zitat:

Beziehung
=========
PK Beziehung_ID
FK Künstler_ID
FK Künstler_ID

Nehmen wir als Beispiel an du hast eine Tabelle für Künstler und willst nur deren Verwandtschaft abbilden.
Dafür könnte eine einfache Beziehung eines Künstlers zu einer Familie reichen:
Artits:

• ID
• Name
• Family -> Families
• ...

Families:

• ID
• Name
• ...

Hast du aber viele Beziehungen, Beziehungen mit mehreren übergeordneten elementen oder willst nchträglich Beziehungen hinzufügen sind Zwischentabellen ein gutes Werkzeug: (Hier besonders interessant, da Mutter & Vater unterschiedlichn Familien entstammen )

Artits:

• ID
• Name
• ...

Families:

• ID
• Name
• ...

FamilyMembers:

• ID
• Family -> Families
• Artist -> Artists

Der letzte ansatz dürfte in vielen Fällen der bevorzugte sein, da man die Ursprungsdaten möglichst weit von der Verwendung trennen kann. Dadurch lassen sich zu jeder Zeit neue Beziehungen und Eigenschaften einbauen ohne die Ursprungsdaten anfassen (==invalidieren) zu müssen.

Edit: Ich hatte meinen alten Beitrag blind editiert anstatt zu antworten.
*rekonstruiert...*

[Flogo]

@2_daniel:

Ich will ja wie gesagt auf eine Art der Beziehung verzichten (Das mit der Verwandschaft war nur eine Rechtfertigung warum ich überhaupt Beziehungen zwischen den Künstlern einführen will)

Könnte ich die Tabelle Beziehungen dann so anlegen:

Beziehungen
===========
PK Künstler_ID
FK ToKünstler_ID


Wenn ein Künstler mehrere Beziehungen haben kann muss die Tabelle dann so aussehen:

Beziehungen
===========
PK Beziehungen_ID
FK Künstler_ID
FK ToKünstler_ID

@Robert_G:
Was ist mit meinen Namen? Ich fange gerade erst an mit Datenbanken und hab die meisten Namen aus einem Buch übernommen in dem als Beispiel auch ein CD-Archiv beschrieben wird.

In deinem ersten Beispiel wäre dann jeweils ID der PK und Family ein FK auf die Tabelle Families, richtig?
d.h. wenn zwei Künstler was miteinander zu tun haben gründe ich eine Familie und steck sie da beide rein.
Könnte ich dann noch einem Künstler mehrere Beziehungen zuordnen?
Mit dem zweiten Beispiel geht das ja auf jeden Fall (soweit ich das sehe) aber da brauch man ja eine Tabelle mehr als mit einer Beziehungstabelle (vorrausgesetzt man darf das)

[Robert_G]

Zitat von Flogo:

@Robert_G:
Was ist mit meinen Namen? Ich fange gerade erst an mit Datenbanken und hab die meisten Namen aus einem Buch übernommen in dem als Beispiel auch ein CD-Archiv beschrieben wird.

Versuche mal diese Struktur, in der alles immer anders heißt, obwohl es eigentlch das gleiche ist. (ID, Name, ...) in Objekte abzubilden.
Du müsstest dann mit jeder Ableitung das Rad neu erfinden. Außerdem sieht es einfach unschön aus.

Zitat:

In deinem ersten Beispiel wäre dann jeweils ID der PK und Family ein FK auf die Tabelle Families, richtig?
d.h. wenn zwei Künstler was miteinander zu tun haben gründe ich eine Familie und steck sie da beide rein.

Richtig.

Zitat:

Könnte ich dann noch einem Künstler mehrere Beziehungen zuordnen?

Das genau das nicht geht, wollte ich damit zeigen. Du hast ja nur einen Schlüssel auf eine Familie pro Artist.

Zitat:

Mit dem zweiten Beispiel geht das ja auf jeden Fall (soweit ich das sehe) aber da brauch man ja eine Tabelle mehr als mit einer Beziehungstabelle (vorrausgesetzt man darf das)

Was meinst du mit "Beziehungstabelle"?
Der Trick mit den Zwischentabellen ist, dass du ganz easy weitere Eigenschaften an deine Ursprungsdaten hängen kannst.
Albums:

• ID
• Name
• ...

AlbumArtists

• ID
• Album -> Albums
• Artist -> Artists

Schon kannst du einen Artist an mehrere Alben hängen, die wiederum von mehreren Künstlern sind. (Du könntest es auch noch auf Songs von Künstler in Album erweitern...)

[Yadon]

Hi,

das Problem kenne ich, hatte ich selbst vor Jahren, als ich mir ein Archiv für CDs, Schallplatten etc. angelegt habe. Plötzlich wollte ich alle Informationen, die man so bekommt, speichern. Und Tabelle verweist auf sich selbst geht gar nicht so schwer. Ich versuche mal, jetzt ordentlich zu erklären, wie ich das gelöst habe.

Ich habe zwei Tabellen:

Artist - hier sind sämtliche Künstler eingetragen

• Artist_ID
• Artist_Name
• ... sonstewas

ArtistByArtist - hier trage ich nur die IDs der Künstler ein und die Art der Verbindung etc.

• Artist_ID
• ByArtist_ID
• ...egal was für die Beziehung wichtig ist

Dann habe ich mir ein zweites Form angelegt, welches vom Hauptform aufgerufen wird.
Damit ist auch automatisch der erste Künstler festgelegt und dessen ID bekannt.

Auf dem zweiten Form habe ich dann sicherheitshalber oben noch mal den Namen des aufrufenden Künstlers vermerkt, damit ich das auch noch weiß, wenn ich im Hauptform schon andere Dinge tue.
Weiterhin liegt dort ein DBGrid, in dem die Einträge niedergelegt werden und eine DBLookupComboBox. Wenn ich aus der Look..Box einen Namen auswähle, dann wird er direkt ins Grid eingetragen. Und die Beziehungen stelle ich folgendermaßen her:

Dem DBGrid liegt eine Query zugerunden mit folgender SQL:

Delphi-Quellcode:

SELECT 
  Artist_ByArtist.*, Artist.Artist_Name, Artist_ID
FROM 
  Artist, Artist_ByArtist
WHERE
  (ByArtist_ID = Number OR  Artist_ID = Number)
AND  
  (Artist.Artist_ID <> Number 
AND
  (ByArtist_ID = Artist.Artist_ID OR Artist_ID = Artist.Artist_ID))
ORDER BY 
  Artist_Name

Den Parameter Number übergebe ich bei Aufruf des zweiten Forms.

Die Loo....Box nutzt folgende Query:

Delphi-Quellcode:

SELECT
  Artist_ID, Artist_Name
FROM 
  Artist
ORDER BY 
  Artist_Name

Das ganze klappt seit Jahren einwandfrei, hab allerdings 'ne Weile rumgefrickelt, bis ich es hatte und mir auch von schlauen Leuten helfen lassen.

Oh, beinahe hätte ich's vergessen, nutze ADO und ACCESS.
Gute Nacht!

[Flogo]

Zitat von Robert_G:

Versuche mal diese Struktur, in der alles immer anders heißt, obwohl es eigentlch das gleiche ist. (ID, Name, ...) in Objekte abzubilden.
Du müsstest dann mit jeder Ableitung das Rad neu erfinden. Außerdem sieht es einfach unschön aus.

Die Sachen heißen doch immer gleich bzw sind unterschiedlich. Ich halte mich im Moment noch ziemlich streng an das Buch, in dem steht dass der PK einer Tabelle immer [TabellenName]_ID heißen soll und ein FK auf diesen möglichst genauso (Das kann ich ja zum Beispiel dann nicht durchhalten wenn ich eine Beziehungstabelle mache, weil darin sonst zweimal Künstler_ID stehen müsste).

Zitat von Robert_G:

Was meinst du mit "Beziehungstabelle"?

Die Zwischentabelle, die ich mir nach Daniels Beispiel gebastelt hab

Beziehungen
===========
PK Beziehungen_ID
FK Künstler_ID
FK ToKünstler_ID

Ich denke damit werde ich es jetzt versuchen. Wenn ich deinen letzten Beitrag richtig verstehe schlägst du sowas in der Art auch (für Künstler <-> Album) vor.
Und auch das was Yadon gepostet hat deckt sich fast damit (welches Feld ist denn bei dir (Yadon) in der Tabelle ArtistByArtist der PK ?)

[OT]

Zitat von Yadon:

Oh, beinahe hätte ich's vergessen, nutze ADO und ACCESS.

Werde ich tun, weil das zufällig im Buch auch benutzt wird
[/OT]

[Robert_G]

Zitat von Flogo:

Die Sachen heißen doch immer gleich bzw sind unterschiedlich.

Ein PK, ist ein PK, ist ein PK,...
Und wenn etwas einen Namen hat, warum sollte man so dumm sein und ihn immer wieder anders nennen?
Solange man Quick'nDirty nur DataSets und keinerlei Abbildung in Klassen verwendet mag das nur dumm aussehen, versucht man es aber mal vernünftig zu machen lässt es sich auch noch dumm damit arbeiten.

Zitat von Flogo:

Ich halte mich im Moment noch ziemlich streng an das Buch, in dem steht dass der PK einer Tabelle immer [TabellenName]_ID heißen soll und ein FK auf diesen möglichst genauso

Kannst du mir vielleicht auch noch den Autor verraten? Schließlich muss ich wissen welche Bücher ich _nicht_ empfehlen kann.
Ich glaube man merkt hier deutlich, dass ich deshalb schon öfter Zank mit solchen DB Hanseln hatte, die irgendwas hinschludern, Spalten immer wieder anders nennen, nur weil sie zu faul/unfähig sind Aliase in Abfragen zu verwenden. (Da ist so ein Punkt auf den ich etwas allergisch reagiere...)

Zitat:

Ich denke damit werde ich es jetzt versuchen. Wenn ich deinen letzten Beitrag richtig verstehe schlägst du sowas in der Art auch (für Künstler <-> Album) vor.
Und auch das was Yadon gepostet hat deckt sich fast damit (welches Feld ist denn bei dir (Yadon) in der Tabelle ArtistByArtist der PK ?)

Ich habe im zweiten Beitrag nur eine weitere Möglichkeit gezeigt, wie man das Ganze einfach um Alben erweitern kann.

Zitat:

Zitat von Yadon:

Oh, beinahe hätte ich's vergessen, nutze ADO und ACCESS.

Werde ich tun, weil das zufällig im Buch auch benutzt wird

Willst du einen easy Einstieg dann wäre da Access nur mit Access zu benutzen, oder eine richtige Mini-DB (wie Firebird) mit Delphi. Den Sinn in der Kombi Jet (Access) und Delphi habe ich noch nie kapiert.
DB Design geht mit IbExpert und Firebird IMHO sogar einfacher und schneller.

[Flogo]

Es ist ja nicht so, dass das ganze nur hingeschludert ist und kein System hat. Es ist halt ein anderes System.
Dadurch das im PK der Tabellenname mit drinsteckt kann man den FK eben genauso nennen. Wenn alle nur ID heißen muss man sich für den FK einen neuen Namen ausdenken.
Aber ich will mich mit dir hier nicht über die Namesgebung streiten (vor allem weil das meine erste Datenbank ist ). Ich nehme das alles einfach erst mal als Anregung auf und mache dann vielleicht die nächste DB nach diesen Kriterien.
Im Moment will ich jedoch erstmal bei dem bleiben was das Buch mir anbietet (sowohl die Namen als auch die Kombination Access und ADO) damit ich mich daran entlangarbeiten kann und nicht dauernd überlegen muss "Was wäre das dann in meinem Fall?"

Das hier ist übrigens das Buch von dem ich die ganze Zeit rede:

[Robert_G]

Zitat von Flogo:

Im Moment will ich jedoch erstmal bei dem bleiben was das Buch mir anbietet (sowohl die Namen als auch die Kombination Access und ADO) damit ich mich daran entlangarbeiten kann und nicht dauernd überlegen muss "Was wäre das dann in meinem Fall?"

Sorry, ich hatte es so aufgefasst, dass du neben dem Lernen im Buch bereits deine erste kleine Anwendung schreiben wolltest.
Deshalb ja meine Hinweise mit den Benennungen und FB.
Außerdem habe ich nie behauptet, dass kein System darin wäre, aber eine Namenskonvention, die dich bestraft objektorientiert gegen die DB zu programmieren ist ein Paradebeispiel für "hingeschludert".
Ignoriere das meinetwegen beim Arbeiten mit dem Buch, aber behalte es im Hinterkopf, wenn du selbst etwas anfängst.