Beziehungsarten in Power Query: Welche Beziehung wann? (Mit vielen Beispielen)
Power Query ist ein mächtiges ETL-Tool (Extract, Transform, Load) in Excel und Power BI, das es ermöglicht, Daten aus verschiedenen Quellen zu transformieren und miteinander zu verknüpfen. Ein zentrales Konzept dabei sind Beziehungen zwischen Tabellen, die man in Power Query über Join-Vorgänge umsetzt.
In diesem Artikel erkläre ich die verschiedenen Arten von Beziehungen in Power Query anhand von praktischen Beispielen – damit du die richtige Beziehungsart im richtigen Moment einsetzen kannst.
Was ist eine Beziehung in Power Query?
In Power Query gibt es keine „klassischen Beziehungen“ wie in relationalen Datenbanken (diese kommen erst später in Power BI). Stattdessen verknüpfst du Tabellen über Join-Operationen – also Zusammenführungen basierend auf einem oder mehreren Schlüsselfeldern.
Die 6 Join-Arten in Power Query
Beim Kombinieren von Tabellen über „Abfragen zusammenführen“ stehen dir folgende Optionen zur Verfügung:
| Join-Typ (Beziehungsart) | Beschreibung | Typische Verwendung |
|---|---|---|
| Inner Join (Nur Übereinstimmungen) | Gibt nur Zeilen zurück, bei denen in beiden Tabellen ein Match gefunden wird. | Wenn du nur Daten möchtest, die in beiden Tabellen vorkommen. |
| Left Outer Join (Alle aus erster, passende aus zweiter) | Behalte alle Zeilen der linken Tabelle, ergänze Daten aus rechter Tabelle nur bei Übereinstimmung. | Standardfall: Primärtabelle soll vollständig bleiben. |
| Right Outer Join (Alle aus zweiter, passende aus erster) | Umgekehrter Left Join. | Wenn die rechte Tabelle die Haupttabelle ist. |
| Full Outer Join (Alle Zeilen aus beiden Tabellen) | Alle Zeilen aus beiden Tabellen, mit NULL bei fehlenden Entsprechungen. | Bei Analysen, bei denen keine Information verloren gehen soll. |
| Anti Join (Left Anti) | Nur Zeilen aus erster Tabelle, die keinen Match in der zweiten haben. | Finden von Datensätzen ohne Partner, z. B. „fehlende Produkte“. |
| Anti Join (Right Anti) | Nur Zeilen aus zweiter Tabelle, die keinen Match in der ersten haben. | Umgekehrte Analyse wie oben. |
| Inner Anti (nicht offiziell genannt, ergibt sich aus Filterlogik) | Kombination aus Anti Joins – selten nötig, aber logisch kombinierbar. | Bei komplexen Fehleranalysen oder Abgleichen. |
Beispiel-Szenario: Kunden und Bestellungen
Datenbasis:
Tabelle: Kunden
| Kunden-ID | Name |
|---|---|
| 1 | Müller |
| 2 | Schmidt |
| 3 | Meier |
| 4 | Schulz |
Tabelle: Bestellungen
| Bestell-ID | Kunden-ID | Produkt |
|---|---|---|
| A001 | 1 | Laptop |
| A002 | 2 | Maus |
| A003 | 2 | Tastatur |
| A004 | 5 | Monitor |
Beispiel 1: Inner Join
Ziel: Finde alle Kunden mit Bestellungen.
→ Nur Kunden 1 und 2 erscheinen, weil sie in beiden Tabellen vorkommen.
| Kunden-ID | Name | Produkt |
|---|---|---|
| 1 | Müller | Laptop |
| 2 | Schmidt | Maus |
| 2 | Schmidt | Tastatur |
Gut für Analysen mit vollständigen Datensätzen, bei denen nur gültige Kombinationen zähle
Beispiel 2: Left Outer Join
Ziel: Zeige alle Kunden, auch wenn sie nichts bestellt haben.
→ Kunde 3 und 4 erscheinen trotzdem – ohne Produktinfo.
| Kunden-ID | Name | Produkt |
|---|---|---|
| 1 | Müller | Laptop |
| 2 | Schmidt | Maus |
| 2 | Schmidt | Tastatur |
| 3 | Meier | null |
| 4 | Schulz | null |
Nützlich, wenn deine linke Tabelle Hauptreferenz ist (z. B. Kundenliste, Stammdaten).
Beispiel 3: Right Outer Join
Ziel: Zeige alle Bestellungen, auch wenn der Kunde fehlt (z. B. historische Daten ohne Kundenzuordnung).
→ Bestell-ID A004 wird angezeigt, obwohl Kunde nicht in der Kundentabelle ist.
| Kunden-ID | Name | Produkt |
|---|---|---|
| 1 | Müller | Laptop |
| 2 | Schmidt | Maus |
| 2 | Schmidt | Tastatur |
| null | null | Monitor |
Sinnvoll in Szenarien mit externen Daten, z. B. Logdateien, Exporten ohne vollständige Stammdaten.
Beispiel 4: Full Outer Join
Ziel: Alle Informationen, auch wenn keine Verbindung vorhanden ist.
→ Kunden ohne Bestellungen und Bestellungen ohne Kunden erscheinen.
| Kunden-ID | Name | Produkt |
|---|---|---|
| 1 | Müller | Laptop |
| 2 | Schmidt | Maus |
| 2 | Schmidt | Tastatur |
| 3 | Meier | null |
| 4 | Schulz | null |
| null | null | Monitor |
Sehr gut für Datenabgleiche, um Lücken in den Beziehungen sichtbar zu machen.
Beispiel 5: Left Anti Join
Ziel: Finde Kunden ohne Bestellungen.
→ Liefert Kunde 3 und 4.
| Kunden-ID | Name |
|---|---|
| 3 | Meier |
| 4 | Schulz |
Ideal für Fehlersuche, Datenqualität, oder gezielte Follow-ups („Welche Kunden sind inaktiv?“).
Beispiel 6: Right Anti Join
Ziel: Finde Bestellungen ohne gültigen Kunden.
→ Liefert Bestell-ID A004.
| Kunden-ID | Produkt |
|---|---|
| 5 | Monitor |
Wichtig z. B. bei Datenimporten, um zu sehen, ob Stammdaten fehlen oder IDs veraltet sind
Entscheidungshilfe: Wann welche Beziehung?
| Ziel | Wähle diese Join-Art |
|---|---|
| Nur passende Kombinationen | Inner Join |
| Alle aus Haupttabelle, ggf. Ergänzungen | Left Outer Join |
| Alle aus zweiter Tabelle, mit Anreicherung | Right Outer Join |
| Alles zeigen, Lücken sichtbar machen | Full Outer Join |
| Zeilen ohne Gegenstück (links) | Left Anti Join |
| Zeilen ohne Gegenstück (rechts) | Right Anti Join |
Tipp: Bei großen Datenmengen effizient arbeiten
- Filtere Tabellen vor dem Join, um die Datenmenge zu reduzieren.
- Wähle nur benötigte Spalten – das spart Speicher und verbessert Performance.
- Ersetze komplexe Full Joins durch zwei Outer Joins + Append (wenn nötig).
- Nutze Anti Joins regelmäßig zur Qualitätskontrolle!
Beziehungen in Power BI vs. Power Query
In Power BI erstellst du Beziehungen zwischen Tabellen im Datenmodell. In Power Query dagegen kombinierst du Daten direkt durch Transformation. Beide haben ihren Platz – aber:
- In Power Query arbeitest du zeilenbasiert mit Abfragen.
- Im Power BI-Modell definierst du relationale Verknüpfungen mit Kardinalitäten.
Power Query = Transformationsebene
Power BI-Modell = Analyseebene
Fazit
Die Kunst in Power Query besteht darin, die richtige Beziehungsart zum richtigen Zweck zu wählen. Mit den hier gezeigten Beispielen solltest du nun klar erkennen können, wann welcher Join der richtige ist. Nutze Joins bewusst – sie sind der Schlüssel zu sauberen, zuverlässigen Datenmodellen!
