Verbindungstabelle/Zwischenatabelle - wozu?

Swirl

Neuer Benutzer
Beiträge
4
Hallo SQLler,

Bei der Frage fallen hier die meisten wahrscheinlich erst einmal vom Stuhl. Kommt ja gleich nach der Frage:
warum SQL? Vorneweg: ich will hier keinen veräppeln und ich habe auch schon mitbekommen, dass der erste
April 20 Tage zurück liegt. Und will mich als Newbee in diesem Forum natürlich auch nicht unbeliebt machen.

Ich wurde bisher - man glaubt es kaum - nicht mit der Fragestellung »n:m-Beziehungen« konfrontiert, obwohl
ich in den letzten Jahren 5 kleine Datenbankanwendungen geschrieben habe. (Lazarus/Free Pascal und SQLite)

Seit Mitte Mai 2017 muss ich mich jedoch mit »n:m-Beziehungen« vertraut machen und scheitere gedanklich
an einem - wahrscheinlich winzigen - Problem.

Ich habe, wie man das so schön macht, natürlich zu diesem Thema erstmal brav gegoogelt. Und dabei auch viel
Theoretisches gefunden. (Beispiele 1:n -> Mutter: Kinder / n:m -> Sprachen:Länder / zusammengesetzte
Schlüssel / etc.) Das »Warum« - n:m-Verbindung zu realisieren - habe ich nachvollziehen können. Doch nicht
das »Wozu«. Was mache ich damit? Wie nutze ich das Abfrage-mäßig? Die Frage mag banal sein, aber
ich vermute da eine Blockade meinerseits. Kann mir da einer auf die Sprünge helfen?

Liebe Grüße,
Michael
[aka Swirl]
 
Werbung:
Das »Warum« - n:m-Verbindung zu realisieren - habe ich nachvollziehen können. Doch nicht
das »Wozu«. Was mache ich damit?

Um Dein Datenmodell zu normalisieren. Tabelle Kunden und Aufträge: in der Kundentabelle stehen die Stammdaten des Kunden (Anschrift etc), in den Aufträgen die konkreten Aufträge. In der Auftrags-Tabelle hast Du nun nur noch einen Fremdschlüssel auf Kunden und sparst Dir damit, zu jedem Auftrag nochmals die Adresse zu erfassen und zu speichern. Damit hast Du auch keine redundanten Daten in der DB.
 
Das war aber fix!

Das mit der Normalisierung bringt mich der Sache schon näher.
Kannst Du mir noch ein kleines Abfrage-Bespiel geben, in dem ich
von der Verbindungstabelle »»profitiere««? Dann wäre, glaube ich,
der Knoten bei mir gelöst.

Besten Dank einstweilen, akretschmer.

LG
Swirl
 
Na, du joinst dann die Tabellen.

Beispiel (aus einem anderen Thread heute...)

Code:
test=*# \d master
  Tabelle »public.master«
 Spalte |  Typ  |  Attribute   
--------+---------+---------------------------------------------------------
 id  | integer | not null Vorgabewert nextval('master_id_seq'::regclass)
 name  | text  |
Indexe:
  "master_pkey" PRIMARY KEY, btree (id)
Fremdschlüsselverweise von:
  TABLE "detail" CONSTRAINT "detail_master_id_fkey" FOREIGN KEY (master_id) REFERENCES master(id)

test=*# \d detail
  Tabelle »public.detail«
  Spalte  |  Typ  | Attribute
-------------+---------+-----------
 master_id  | integer |
 detail_name | text  |
Fremdschlüssel-Constraints:
  "detail_master_id_fkey" FOREIGN KEY (master_id) REFERENCES master(id)

test=*# select * from master left join detail on master.id=detail.master_id;
 id | name  | master_id |  detail_name  
----+-------+-----------+---------------
  2 | name2 |  2 | detail name 2
  1 | name1 |  |
(2 Zeilen)

test=*#
 
Eigentlich ist eine n:m Beziehung ja auch nur die logische Darstellung von zwei 1:n Beziehungen. Technisch gibt es keine weiteren Funktionen als die, die du schon benutzt. Es sind nur mehr Tabellen und Joins involviert.
 
Werbung:
Zurück
Oben