Anzeige
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Power Query - Gruppieren nach Stufen

Forumthread: Power Query - Gruppieren nach Stufen

Power Query - Gruppieren nach Stufen
16.08.2024 11:52:37
Bernd Fuchs
Hallo Excel-Gemeinde,
ich habe ein kleines Anliegen, was mir seit einiger Zeit Kopfzerbrechen bereitet.
Über PQ frage ich Daten aus einer DB ab, die ungefähr so aussehen. In der Spalte A stehen Nummern, die auch in Spalte B stehen können. Allerdings können nur Nummern in Spalte A stehen, die auch zur Kategorie b gehören. Zirkelbezüge gibt es nicht (1 - 5 / 5 - 1).
Ich würde die Liste gerne so transformieren, dass jede Nummer, die auch eine Kategorie b Nummer in Spalte B stehen hat und falls diese auch eine Kategorie b Nummer hat in Spalten nebeneinander angeordnet werden.

https://www.herber.de/bbs/user/171653.xlsx

Vielen Dank

Bernd Fuchs
Anzeige

14
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
AW: das sich Deines Problems noch niemand angenommen hat ...
17.08.2024 19:33:37
neopa C
Hallo Bernd,

... liegt womöglich daran, das die PQ-Profis ein verlängertes WE haben oder Ihnen unklar ist, wie Deine vorgegebene zweite 5 in der "3. Stufe". Ich meine, dass diese für Deine vorgegebenen Datenwerte nicht zutreffend ist. Wenn doch, bedarf es Deiner näheren Erklärung, warum dies so sein soll.

Nachfolgend zunächst mal (m)eine reine Formellösung, die auch in älteren XL-Versionen noch zum Einsatz kommen kann. Wenn es sich jedoch im Original um eine Massendatenauswertung handeln sollte (mehre tausende Datensätze), dann ist eine PQ-Lösung natürlich die bessere Lösungsvariante.

Nachfolgende Formel für Daten bis z.B. max Zeile 999 einfach weit genug nach unten und rechts ziehen kopieren.

Arbeitsblatt mit dem Namen 'Tabelle1'
 ABCDEFGHI
4NummerNummer 2Kategorie Nummer (1. Stufe)2. Stufe3. Stufe4. Stufe5. Stufe
5110a 145  
6120a 24   
7130a 35   
8140a 45   
914b      
10160a      
11170a      
12210a      
13270a      
142100a      
152101a      
1624b      
1735b      
18360a      
19370a      
20410a      
2145b      
225100a      
23         

ZelleFormel
E5=WENNFEHLER(AGGREGAT(15;6;A$5:A$1000/(C$5:C$1000="b")/(ZÄHLENWENN(E$4:E4;A$5:A$1000)=0)/SUCHEN(1;E$4)^0;1);WENNFEHLER(AGGREGAT(15;6;$B$5:$B$1000/($A$5:$A$1000=D5)/($C$5:$C$1000="b")/(ZÄHLENWENNS(E$4:E4;$B$5:$B$1000;D$4:D4;D5)=0);1);""))
Verwendete Systemkomponenten: [Windows (32-bit) NT 6.02] MS Excel 2010
Diese Tabelle wurde mit Tab2Html (v2.6.0) erstellt. ©Gerd alias Bamberg

Gruß Werner
.. , - ...
Anzeige
AW: für PQ-Lösung ab 3. Stufe thread weiter offen, denn ...
18.08.2024 13:41:44
neopa C
Hallo Bernd, hallo PQ-Profis,

... die Ergebnisspalte der 2. Stufe ist ja in PQ mittels Filtern der Spalte "Kategorie" nach "b" ja ganz einfach ermittelt.

Aber ich fand bisher leider keinen interaktiven Ansatz zur Ermittlung der gewünschten Folgestufen in PQ. Möglicherweise ist dies dann auch nur durch direkten Einsatz von M-Code zu ermitteln. Persönlich würde mich jedoch vorrangig ein interaktiver Lösungsansatz dafür interessieren, wenn es denn möglich sein sollte.

Gruß Werner
.. , - ...
Anzeige
Dann nachfolgend mal...
19.08.2024 01:02:40
Case
Moin Bernd, :-)

... ein Ansatz: ;-)
https://www.herber.de/bbs/user/171682.xlsx

Man könnte hier auch mit einer Rekursiven Funktion arbeiten. Je nach Stufenanzahl kann das "Durchiterieren" dann etwas dauern. ;-)

Servus
Case
Anzeige
AW: Power Query - Gruppieren nach Stufen
19.08.2024 21:15:03
Yal
Hallo Bernd,

ich dachte zuerst, es wäre einfach ein Baum, das in Parent-Child aufgestellt ist. Aber manche "children" haben mehrere "Parent" (m-zu-n-Beziehungen). Aber vielleicht ist es nur deine Testdaten geschuldet.

Es wird daher schwierig, eine Stufenstruktur zu erzeugen. Höchstens kannst Du eine Matrix aufbauen. Das erreichst Du am einfachste mit einer Pivottabelle.

@all: ein Baum wird, solang die Tiefe nicht vorher festgelegt ist, rekursiv aufgebaut. Da bin ich mir nicht sicher, ob Rekursivität mit PQ handelbar ist.

VG
Yal
Anzeige
AW: Dann nachfolgend mal...
19.08.2024 11:35:01
Luschi
Hallo Case,

ich habe die folgende Schleife aus Deinem M-Code getestet:
ExSt = List.Accumulate({1..MaxStufe}, StartT, (sIST, akt) =>

let
Erweitert = Table.ExpandListColumn(sIST, "Stufe" & Text.From(akt)),
Join = Table.NestedJoin(Erweitert, {"Stufe" & Text.From(akt)}, Filtb, {"Nummer"}, "NeueStufe"),
Expand = Table.ExpandTableColumn(Join, "NeueStufe", {"Nummer2"}, {"Stufe" & Text.From(akt + 1)}),
Entf0 = Table.SelectRows(Expand, each List.NonNullCount(Record.FieldValues(_)) > 0),
Gruppe = Table.Group(Entf0, {"Nummer"}, {{"Stufe" & Text.From(akt + 1), each List.Distinct(List.RemoveNulls(Record.Field(_, "Stufe" & Text.From(akt + 1)))), type list}}),
Umbenannt = Table.RenameColumns(Gruppe, {{"Nummer", "NummerTemp"}}),
JoinedTable = Table.Join(sIST, "Nummer", Umbenannt, "NummerTemp", JoinKind.LeftOuter),
OhneN = Table.RemoveColumns(JoinedTable, {"NummerTemp"})
in
OhneN),
Und zwar so, daß nur der 1. Durchlauf von List.Accumulate() simuliert wird:
    akt = 1,

sIST = StartT,
Erweitert = Table.ExpandListColumn(sIST, "Stufe" & Text.From(akt)),
Join = Table.NestedJoin(Erweitert, {"Stufe" & Text.From(akt)}, Filtb, {"Nummer"}, "NeueStufe"),
Expand = Table.ExpandTableColumn(Join, "NeueStufe", {"Nummer2"}, {"Stufe" & Text.From(akt + 1)}),
Entf0 = Table.SelectRows(Expand, each List.NonNullCount(Record.FieldValues(_)) > 0),
Gruppe = Table.Group(Entf0, {"Nummer"}, {{"Stufe" & Text.From(akt + 1),
each List.Distinct(List.RemoveNulls(Record.Field(_, "Stufe" & Text.From(akt + 1)))), type list}}),
Umbenannt = Table.RenameColumns(Gruppe,{{"Nummer", "NummerTemp"}}),
JoinedTable = Table.Join(sIST, "Nummer", Umbenannt, "NummerTemp", JoinKind.LeftOuter),
OhneN = Table.RemoveColumns(JoinedTable, {"NummerTemp"}),

Beim PQ-Schritt: Gruppe = Table.Group... erscheint in der Spalte 'Stufe2' überall 'Error' mit der Fehlerbeschreibung:
Expression.Error: Ein Wert vom Typ "Table" kann nicht in den Typ "Record" konvertiert werden.
ABER: der nächste PQ-Schritt: Umbenannt = Table.RenameColumns(Gruppe,{{"Nummer", "NummerTemp"}})
behebt erstaunlicher Weise diesen Fehler in der Spalte 'Stufe2'
Erfolgt die Umbenennung vor der Gruppierung, dann ist beim Einzeltest alles i.O.
Also so:
Erweitert = Table.ExpandListColumn(sIST, "Stufe" & Text.From(akt)),

Join = Table.NestedJoin(Erweitert, {"Stufe" & Text.From(akt)}, Filtb, {"Nummer"}, "NeueStufe"),
Expand = Table.ExpandTableColumn(Join, "NeueStufe", {"Nummer2"}, {"Stufe" & Text.From(akt + 1)}),
Entf0 = Table.SelectRows(Expand, each List.NonNullCount(Record.FieldValues(_)) > 0),
Umbenannt = Table.RenameColumns(Entf0, {{"Nummer", "NummerTemp"}}),
Gruppe = Table.Group(Umbenannt, {"NummerTemp"}, {{"Stufe" & Text.From(akt + 1),
each List.Distinct(List.RemoveNulls(Record.Field(_, "Stufe" & Text.From(akt + 1)))), type list}}),
JoinedTable = Table.Join(sIST, "Nummer", Gruppe, "NummerTemp", JoinKind.LeftOuter),
OhneN = Table.RemoveColumns(JoinedTable, {"NummerTemp"}),

Und aus diesem Grund habe ich auch im PQ.Schritt 'ExSt' diese Umbenennung angepaßt. Aber hast Du eine Erklärung für dieses Verhalten?

Gruß von Luschi
aus klein-Paris
Anzeige
AW: dazu nachgefragt ...
19.08.2024 13:50:43
neopa C
Hallo Case,

... Deine Lösung (die ich aktuell mangels ausreichender Kenntnis nur teilweise nachvollziehen kann, ermittelt in der Beispieldatei exakt das vorgegebene.
Für Dich ist also die zweite 5 in der 3. Stufe somit verständlich. Welche Begründung gibt es für diese aus Deiner Sicht? Ich würde gern zunächst das verstehen wollen.

Gruß Werner
.. , - ...
Anzeige
Meine Interpreatation...
19.08.2024 15:55:09
Case
Moin, :-)

Also 1, 2, 3, 4 haben b in Nummer. 1, 2 , 3 sind nicht in Nummer2 - Stufe1.
4 ist in Nummer mit b und mit b in Nummer2. 5 nur in Nummer2 - Sufe2.
5 ist als einzige Zahl 2 mal in Nummer2 mit b - Stufe3.

Das ist meine Interpretation.

Ich habe allerdings keine Lust auf lange Diskussionen ala "Was wäre wenn...". ;-)
Für mich ist das Thema abgehakt.

Servus
Case
Anzeige
AW: verstanden ...
19.08.2024 16:57:02
neopa C
Hallo Case,

... dank Dir.

@ Bernd,

nun würde mich noch Deine Erklärung interessieren.
Mit einer Kürzung meiner bereits eingestellten Formel, könnte ich natürlich auch zum gleichen Ergebnis gelangen.

In E3:
=WENNFEHLER(AGGREGAT(15;6;B$5:B$99/(D$5:D$99="b")/(ZÄHLENWENN(F$4:F4;B$5:B$99)=0)/SUCHEN(1;F$4)^0;1);WENNFEHLER(AGGREGAT(15;6;$B$5:$B$99/($A$5:$A$99=E5)/($C$5:$C$99="b");1);"")) und diese nach rechts und unten ziehend kopieren.

In neueren Excelversion (welche ich nicht habe) dürfte die Formel durch den Einsatz von FILTER() und EINDEUTIG() wohl noch kürzer werden.

Gruß Werner
.. , - ...
Anzeige
Ein Versuch mit Filter
19.08.2024 18:06:44
BoskoBiati2
Hi,

ich habe, obwohl ich das System nicht verstanden habe, mal einen Versuch mit Filter gestartet. Ging allerdings nicht mit einer Formel und braucht wahrscheinlich bei anderen Gegebenheiten für jede Spalte eine eigene Formel:

https://www.herber.de/bbs/user/171704.xlsx

Gruß

Edgar
Anzeige
AW: wenn dem so ist ...
19.08.2024 19:35:38
neopa C
Hallo Edgar,

... würde ich für mich momentan als einfachste Lösung eine Kombination aus PQ (für 1. und 2. Stufe) und ab der 3. Stufe ein Teil meiner aufgezeigten Formel nutzen, welcher nach nach rechts und unten ziehend kopiert wird, wenn nicht gerade zehntausende Datensätze auszuwerten sind.

Gruß Werner
.. , - ...
Anzeige
Also hier dann...
19.08.2024 13:03:45
Case
Moin Luschi, :-)

… der Versuch einer Erklärung:

Die Schritte hatte ich auch andersrum. Habe dann aber festgestellt, dass PQ da sehr fehlertolerant ist (also nicht in der Syntax, aber in der sequentiellen Abarbeitung).

Der Fehler würde nur zum tragen kommen, wenn ich direkt im Anschluss auf z. B. ein einzelnes Feld der "List" zugreifen würde bzw. irgendetwas anderes mit den "Records" machen würde. Das ist aber nicht der Fall. Ich vermute, dass PQ durch das Umbenennen die Tabelle wieder als Ganzes betrachtet, also hier eine gewisse Fehlertoleranz vorhanden ist - er also in der sequentiellen Abarbeitung wieder in der Spur ist.

Und ich habe einiges mit einer Rekursiven Funktion probiert. Dann wieder andersrum. Irgendwann wurde es mir zu spät. ;-)

Dann habe ich ein kleines .NET Programm, welches mir meinen M-Code nacheinander in eine Datei im Editor speichert. Das ist noch ausbaufähig. Da verliere ich auch schnell mal den Überblick.

So habe ich zum Schluss einfach einen rauskopiert. War ja wie geschrieben nur als Ansatz gedacht. ;-)

Man könnte den M-Code auf ein paar Zeilen kürzen. Habe das mit dem Umbenennen (Stufe1, Stufe2...) nur als Spielerei mit drin. Würde ganz anders aussehen, wenn man gleich "oben" Nummer in Stufe1 umbenennt.
Aber ich dachte - lass mal alles drin, der Themenersteller soll was draus machen.

Servus
Case
Anzeige
AW: Also hier dann...
19.08.2024 13:45:41
Luschi
Hallo Case,

danke für Dein Erklärungsversuch, so was i.d.A. hatte ich vermutet. Das Testen eines Durchlaufes in List.Accumulate() mache ich auch in meinen PQ-Abfragen zur Kontrolle; denn dieses Schleifenkonstrukt benutze ich sehr gern, um Schrittfolgen kompakt zu straffen.

Gruß von Luschi
aus klein-Paris
Anzeige
Bezogen auf deinen...
19.08.2024 17:07:09
Case
Moin Luschi, :-)

... Hinweis auf "List.Accumulate". Darauf bin ich letztes Jahr hier gestossen: ;-)
https://gorilla.bi/power-query/list-accumulate/

Eine sehr mächtige Funktion. Wie überhaupt gute Hinweise meist auf englischsprachigen Seiten zu finden sind. Der deutschsprachige Raum ist da eher dünn besetzt. ;-)

Servus
Case
Anzeige
;

Forumthreads zu verwandten Themen

Anzeige
Anzeige
Anzeige
Anzeige
Entdecke relevante Threads

Schau dir verwandte Threads basierend auf dem aktuellen Thema an

Alle relevanten Threads mit Inhaltsvorschau entdecken

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Entdecke mehr
Finde genau, was du suchst

Die erweiterte Suchfunktion hilft dir, gezielt die besten Antworten zu finden

Suche nach den besten Antworten
Unsere beliebtesten Threads

Entdecke unsere meistgeklickten Beiträge in der Google Suche

Top 100 Threads jetzt ansehen
Anzeige