DAX und Datenmodelle

Power BI Cross-Filter-Richtung: Typen und Best Practices

Die Cross-Filter-Richtung bestimmt, wohin Filter in einer Power-BI-Beziehung fließen. Einzeln oder Beide, wann Beide sinnvoll ist, CROSSFILTER in DAX.

Sajagan Thirugnanam

·

Aktualisiert

Die Cross-Filter-Richtung ist die Beziehungseinstellung, die bestimmt, in welche Richtung ein Filter zwischen zwei verbundenen Tabellen in einem Power-BI-Modell läuft. „Einzeln“ schickt Filter von der „Eins“-Seite (einer Dimension wie Product) zur „Viele“-Seite (einer Faktentabelle wie Sales). „Beide“ schickt sie zusätzlich von Sales zurück zu Product. Nutzen Sie standardmäßig „Einzeln“ und „Beide“ nur für einen konkreten Bedarf wie eine Bridge-Tabelle, denn „Beide“ kann mehrdeutige Pfade und langsamere Abfragen verursachen.

Arten der Cross-Filter-Richtung in Power BI

Welche Optionen Sie haben, hängt von der Kardinalität der Beziehung ab:

Kardinalität

Cross-Filter-Optionen

Eins-zu-viele (oder viele-zu-eins)

Einzeln oder Beide

Eins-zu-eins

Nur Beide

Viele-zu-viele

Einzeln in beide Richtungen oder Beide

Hat eine Beziehung eine „Eins“-Seite, fließen Filter immer von dieser Seite aus. Die Richtungseinstellung bestimmt nur, ob sie auch zurückfließen.

Cross-Filter in einer Richtung (Einzeln)

Bei „Einzeln“ erreicht ein Filter auf der Dimension die Faktentabelle, aber nicht umgekehrt. Wählen Sie „Bikes“ in einem Product-Slicer, zeigt Sales nur Fahrradumsätze. Wählen Sie eine Verkaufsregion, listet der Product-Slicer weiterhin alle Produkte auf, auch solche, die dort nie verkauft wurden.

Das ist die Standardeinstellung für Eins-zu-viele-Beziehungen und passt zu einem Sternschema:

  • Die Filterpfade sind vorhersehbar.

  • Ein Filter hat nur einen Weg zu jeder Tabelle.

  • Abfragen sind günstiger als mit „Beide“.

Bidirektionaler Cross-Filter (Beide)

Bei „Beide“ laufen Filter auch von der „Viele“-Seite zurück zur „Eins“-Seite. Dieselbe Regionsauswahl schränkt dann auch den Product-Slicer auf die Produkte ein, die in dieser Region verkauft wurden.

Berechtigte Einsatzfälle:

  • Eine Bridge-Tabelle für ein Viele-zu-viele-Design, etwa Kunden, die zu mehreren Kontengruppen gehören.

  • Eine Dimension, die nur Werte mit passenden Fakten zeigen soll, in einem kleinen Modell, in dem die Kosten vertretbar sind.

  • Row-Level Security, die von einer Sicherheitstabelle über eine Bridge fließen muss.

Vorteile und Herausforderungen bidirektionaler Filter

Vorteile bidirektionaler Cross-Filter

  • Eine Bridge-Tabelle kann in einem Viele-zu-viele-Design Filter zwischen zwei Dimensionen weitergeben.

  • Slicer zeigen nur Werte, zu denen Daten vorliegen, ohne zusätzliches DAX.

  • Sicherheitsfilter erreichen Tabellen, die sie sonst nicht erreichen würden, zusammen mit der unten genannten Sicherheitsoption.

Herausforderungen und Risiken

  • Mehrdeutige Pfade. Ist „Beide“ bei mehreren Beziehungen aktiv, kann es zwei Wege von einer Tabelle zur anderen geben. Power BI lehnt die Änderung dann ab oder wählt anhand eigener Prioritätsregeln einen Weg, der nicht der gemeinte sein muss.

  • Langsamere Abfragen. Microsoft gibt an, dass bidirektionale Beziehungen die Performance beeinträchtigen können, weil jeder Filter an mehr Stellen angewendet werden muss.

  • Überraschende Ergebnisse. Ein Slicer auf einem Wert der Faktenseite filtert unbemerkt Dimensionen. Das verändert Summen in Visuals, die mit diesem Slicer nichts zu tun haben.

  • Schwierigeres Debugging. Wirkt eine Zahl falsch, müssen Sie Filter in beide Richtungen durch jede Beziehung zurückverfolgen.

Wer „Beide“ einschaltet, damit ein Visual „funktioniert“, hat meist ein Modell, dem eine Tabelle oder ein Measure fehlt.

Best Practices und Einsatzfälle

Best Practices

  • Nehmen Sie standardmäßig „Einzeln“.

  • Bauen Sie das Modell als Sternschema, sodass jede Dimension direkt mit den Faktentabellen verbunden ist.

  • Nutzen Sie „Beide“ nur aus einem benannten Grund, etwa für eine Bridge-Tabelle, und dokumentieren Sie diesen Grund beim Modell.

  • Braucht nur ein Measure einen Rückfilter, nutzen Sie CROSSFILTER in diesem Measure, statt die Beziehung zu ändern.

  • Prüfen Sie nach jeder Änderung auf jeder Seite Slicer und Summen auf unerwartete Filter.

Typische Einsatzfälle

In einem Sternschema deckt „Einzeln“ fast alles ab. Filter fließen von Date, Product und Customer nach Sales.

„Beide“ ist an drei Stellen berechtigt. Erstens ein Viele-zu-viele-Design über eine Bridge-Tabelle, bei dem die Beziehung zwischen Bridge und einer Dimension „Beide“ sein muss, damit der Filter die Faktentabelle erreicht. Zweitens Row-Level Security, die durch eine solche Bridge laufen muss. Drittens ein kleines Modell, in dem jeder Slicer nur Werte mit Daten zeigen soll und Sie die Kosten geprüft haben.

Brauchen Sie die Filterung von der Fakten- zur Dimensionstabelle nur innerhalb einer Berechnung, erledigt CROSSFILTER in DAX das, ohne das Modell zu ändern.

So legen Sie die Cross-Filter-Richtung fest oder ändern sie

Schritte zum Ändern der Cross-Filter-Richtung

  1. Öffnen Sie in Power BI Desktop die Modellansicht.

  2. Doppelklicken Sie auf die Linie zwischen zwei Tabellen, oder wählen Sie im Menüband Beziehungen verwalten und dann die Beziehung.

  3. Wählen Sie unter Kreuzfilterrichtung die Option Einzeln oder Beide.

  4. Haben Sie „Beide“ gewählt und nutzen Row-Level Security, entscheiden Sie, ob Sie Sicherheitsfilter in beide Richtungen anwenden aktivieren.

  5. Wählen Sie Speichern oder OK.

Visuelle Hinweise

  • Ein einzelner Pfeil an der Beziehungslinie zeigt die Richtung, in die Filter fließen.

  • Ein doppelter Pfeil zeigt eine bidirektionale Beziehung.

  • Eine gestrichelte Linie ist eine inaktive Beziehung, die nur ein Measure mit USERELATIONSHIP aktivieren kann.

Die Richtung in einem einzelnen Measure ändern

CROSSFILTER ändert die Richtung einer Beziehung nur für eine Berechnung. Die Funktion nimmt die beiden verbundenen Spalten und eine Richtung: ONEWAY, BOTH oder NONE.

Dieses Measure zählt Kunden, die im aktuellen Filterkontext etwas gekauft haben, etwa in einer gewählten Produktkategorie:

Customers Who Bought =
CALCULATE (
    DISTINCTCOUNT ( Customer[CustomerKey] ),
    CROSSFILTER ( Sales[CustomerKey], Customer[CustomerKey], BOTH )
)

Ohne CROSSFILTER erreicht ein Product-Filter die Tabelle Customer nie, das Measure würde also alle Kunden zählen. Oft gibt es einen einfacheren Weg. Zählt man den Schlüssel in der Faktentabelle, erhält man dieselbe Zahl ohne Richtungsänderung:

Customers Who Bought =
DISTINCTCOUNT ( Sales[CustomerKey] )

Nutzen Sie CROSSFILTER, wenn Sie weitere Spalten der Dimension brauchen, nicht nur den Schlüssel.

Praxisanwendungen und Beispiele

Nehmen Sie ein Modell mit der Faktentabelle Sales und drei Dimensionen: Product, Customer und Date. Alle drei Beziehungen sind Eins-zu-viele und „Einzeln“.

  • Ein Slicer für Product Category filtert Sales, und jedes Umsatz-Measure reagiert.

  • Derselbe Slicer filtert die Tabelle Customer nicht. Ein Customer-Slicer auf der Seite listet weiterhin jeden Kunden auf.

  • Ein Measure, das „Kunden, die diese Kategorie gekauft haben“ braucht, nutzt CROSSFILTER oder zählt Sales[CustomerKey], wie oben gezeigt.

Stellen Sie nun die Beziehung zwischen Sales und Customer auf „Beide“. Der Customer-Slicer schrumpft jetzt auf Kunden, die die gewählte Kategorie gekauft haben. Das kann genau das sein, was die Seite braucht. Aber der Product-Slicer filtert nun auch Customer, und Customer filtert Sales. Steht Date ebenfalls auf „Beide“, gibt es zwischen manchen Tabellen zwei Wege. Dort beginnt die Mehrdeutigkeit. Bleiben die Beziehungen auf „Einzeln“ und wird der Sonderfall in einem Measure gelöst, vermeiden Sie sie.

Beziehungseigenschaften und Kardinalität

Die Cross-Filter-Richtung ist eine von mehreren Beziehungseigenschaften. Die anderen sind:

  • Kardinalität, die bestimmt, welche Richtungsoptionen es gibt (siehe Tabelle oben).

  • Aktiv oder inaktiv, denn zwischen zwei Tabellen kann es nur einen aktiven Pfad geben.

  • Referenzielle Integrität voraussetzen, die es nur für DirectQuery-Beziehungen gibt.

Beziehungen über Spalten mit unterschiedlichen Datentypen oder über Datetime-Spalten mit Zeitanteil passen unabhängig von der Richtung womöglich nicht so zusammen, wie Sie erwarten. Mehr zu Kardinalität und ihrer Wirkung auf die Performance lesen Sie unter Power-BI-Beziehungen und Kardinalität.

Die Cross-Filter-Richtung ist eine Modelleinstellung. Sie unterscheidet sich von den Filtern und Slicern auf Report-Ebene, die in unserem Leitfaden zu Power-BI-Filtern behandelt werden. Zu Sicherheitsfiltern lesen Sie Power BI Row-Level Security.

FAQs

Wie wirkt sich die Kardinalität einer Beziehung auf die Cross-Filter-Richtung in Power BI aus?

Die Kardinalität bestimmt, welche Richtungen verfügbar sind. Eins-zu-viele-Beziehungen können „Einzeln“ oder „Beide“ sein. Eins-zu-eins-Beziehungen sind immer „Beide“. Viele-zu-viele-Beziehungen können in jeweils eine Richtung oder in „Beide“ filtern. Viele-zu-viele-Beziehungen sind außerdem „begrenzte“ Beziehungen, die Power BI erst zur Abfragezeit auswertet. Sie sind daher langsamer als Eins-zu-viele.

Können falsche Datentypen das Verhalten der Cross-Filter-Richtung beeinflussen?

Ja. Eine Beziehung filtert nur, wenn Werte übereinstimmen. Ist eine Spalte Text und die andere eine Zahl, oder die eine ein Datum und die andere ein Datetime mit Zeitanteil, passen die Werte womöglich nicht zusammen. Filter erreichen dann nicht die erwarteten Zeilen, egal welche Richtung gesetzt ist. Stellen Sie beide Spalten in Power Query auf denselben Typ.

Welche Rolle spielt die referenzielle Integrität für die Cross-Filter-Richtung?

Keine direkte. Referenzielle Integrität voraussetzen ist eine eigene Eigenschaft, die es nur für Beziehungen zwischen DirectQuery-Tabellen aus derselben Quelle gibt. Ist sie aktiv, sendet Power BI an die Quelle einen INNER JOIN statt eines OUTER JOIN, was meist schneller ist. Haben manche Faktenzeilen keine passende Dimensionszeile, verschwinden diese Zeilen aus den Ergebnissen. Schalten Sie sie daher nur ein, wenn die Daten sauber sind.

Quellen

Die Cross-Filter-Richtung ist die Beziehungseinstellung, die bestimmt, in welche Richtung ein Filter zwischen zwei verbundenen Tabellen in einem Power-BI-Modell läuft. „Einzeln“ schickt Filter von der „Eins“-Seite (einer Dimension wie Product) zur „Viele“-Seite (einer Faktentabelle wie Sales). „Beide“ schickt sie zusätzlich von Sales zurück zu Product. Nutzen Sie standardmäßig „Einzeln“ und „Beide“ nur für einen konkreten Bedarf wie eine Bridge-Tabelle, denn „Beide“ kann mehrdeutige Pfade und langsamere Abfragen verursachen.

Arten der Cross-Filter-Richtung in Power BI

Welche Optionen Sie haben, hängt von der Kardinalität der Beziehung ab:

Kardinalität

Cross-Filter-Optionen

Eins-zu-viele (oder viele-zu-eins)

Einzeln oder Beide

Eins-zu-eins

Nur Beide

Viele-zu-viele

Einzeln in beide Richtungen oder Beide

Hat eine Beziehung eine „Eins“-Seite, fließen Filter immer von dieser Seite aus. Die Richtungseinstellung bestimmt nur, ob sie auch zurückfließen.

Cross-Filter in einer Richtung (Einzeln)

Bei „Einzeln“ erreicht ein Filter auf der Dimension die Faktentabelle, aber nicht umgekehrt. Wählen Sie „Bikes“ in einem Product-Slicer, zeigt Sales nur Fahrradumsätze. Wählen Sie eine Verkaufsregion, listet der Product-Slicer weiterhin alle Produkte auf, auch solche, die dort nie verkauft wurden.

Das ist die Standardeinstellung für Eins-zu-viele-Beziehungen und passt zu einem Sternschema:

  • Die Filterpfade sind vorhersehbar.

  • Ein Filter hat nur einen Weg zu jeder Tabelle.

  • Abfragen sind günstiger als mit „Beide“.

Bidirektionaler Cross-Filter (Beide)

Bei „Beide“ laufen Filter auch von der „Viele“-Seite zurück zur „Eins“-Seite. Dieselbe Regionsauswahl schränkt dann auch den Product-Slicer auf die Produkte ein, die in dieser Region verkauft wurden.

Berechtigte Einsatzfälle:

  • Eine Bridge-Tabelle für ein Viele-zu-viele-Design, etwa Kunden, die zu mehreren Kontengruppen gehören.

  • Eine Dimension, die nur Werte mit passenden Fakten zeigen soll, in einem kleinen Modell, in dem die Kosten vertretbar sind.

  • Row-Level Security, die von einer Sicherheitstabelle über eine Bridge fließen muss.

Vorteile und Herausforderungen bidirektionaler Filter

Vorteile bidirektionaler Cross-Filter

  • Eine Bridge-Tabelle kann in einem Viele-zu-viele-Design Filter zwischen zwei Dimensionen weitergeben.

  • Slicer zeigen nur Werte, zu denen Daten vorliegen, ohne zusätzliches DAX.

  • Sicherheitsfilter erreichen Tabellen, die sie sonst nicht erreichen würden, zusammen mit der unten genannten Sicherheitsoption.

Herausforderungen und Risiken

  • Mehrdeutige Pfade. Ist „Beide“ bei mehreren Beziehungen aktiv, kann es zwei Wege von einer Tabelle zur anderen geben. Power BI lehnt die Änderung dann ab oder wählt anhand eigener Prioritätsregeln einen Weg, der nicht der gemeinte sein muss.

  • Langsamere Abfragen. Microsoft gibt an, dass bidirektionale Beziehungen die Performance beeinträchtigen können, weil jeder Filter an mehr Stellen angewendet werden muss.

  • Überraschende Ergebnisse. Ein Slicer auf einem Wert der Faktenseite filtert unbemerkt Dimensionen. Das verändert Summen in Visuals, die mit diesem Slicer nichts zu tun haben.

  • Schwierigeres Debugging. Wirkt eine Zahl falsch, müssen Sie Filter in beide Richtungen durch jede Beziehung zurückverfolgen.

Wer „Beide“ einschaltet, damit ein Visual „funktioniert“, hat meist ein Modell, dem eine Tabelle oder ein Measure fehlt.

Best Practices und Einsatzfälle

Best Practices

  • Nehmen Sie standardmäßig „Einzeln“.

  • Bauen Sie das Modell als Sternschema, sodass jede Dimension direkt mit den Faktentabellen verbunden ist.

  • Nutzen Sie „Beide“ nur aus einem benannten Grund, etwa für eine Bridge-Tabelle, und dokumentieren Sie diesen Grund beim Modell.

  • Braucht nur ein Measure einen Rückfilter, nutzen Sie CROSSFILTER in diesem Measure, statt die Beziehung zu ändern.

  • Prüfen Sie nach jeder Änderung auf jeder Seite Slicer und Summen auf unerwartete Filter.

Typische Einsatzfälle

In einem Sternschema deckt „Einzeln“ fast alles ab. Filter fließen von Date, Product und Customer nach Sales.

„Beide“ ist an drei Stellen berechtigt. Erstens ein Viele-zu-viele-Design über eine Bridge-Tabelle, bei dem die Beziehung zwischen Bridge und einer Dimension „Beide“ sein muss, damit der Filter die Faktentabelle erreicht. Zweitens Row-Level Security, die durch eine solche Bridge laufen muss. Drittens ein kleines Modell, in dem jeder Slicer nur Werte mit Daten zeigen soll und Sie die Kosten geprüft haben.

Brauchen Sie die Filterung von der Fakten- zur Dimensionstabelle nur innerhalb einer Berechnung, erledigt CROSSFILTER in DAX das, ohne das Modell zu ändern.

So legen Sie die Cross-Filter-Richtung fest oder ändern sie

Schritte zum Ändern der Cross-Filter-Richtung

  1. Öffnen Sie in Power BI Desktop die Modellansicht.

  2. Doppelklicken Sie auf die Linie zwischen zwei Tabellen, oder wählen Sie im Menüband Beziehungen verwalten und dann die Beziehung.

  3. Wählen Sie unter Kreuzfilterrichtung die Option Einzeln oder Beide.

  4. Haben Sie „Beide“ gewählt und nutzen Row-Level Security, entscheiden Sie, ob Sie Sicherheitsfilter in beide Richtungen anwenden aktivieren.

  5. Wählen Sie Speichern oder OK.

Visuelle Hinweise

  • Ein einzelner Pfeil an der Beziehungslinie zeigt die Richtung, in die Filter fließen.

  • Ein doppelter Pfeil zeigt eine bidirektionale Beziehung.

  • Eine gestrichelte Linie ist eine inaktive Beziehung, die nur ein Measure mit USERELATIONSHIP aktivieren kann.

Die Richtung in einem einzelnen Measure ändern

CROSSFILTER ändert die Richtung einer Beziehung nur für eine Berechnung. Die Funktion nimmt die beiden verbundenen Spalten und eine Richtung: ONEWAY, BOTH oder NONE.

Dieses Measure zählt Kunden, die im aktuellen Filterkontext etwas gekauft haben, etwa in einer gewählten Produktkategorie:

Customers Who Bought =
CALCULATE (
    DISTINCTCOUNT ( Customer[CustomerKey] ),
    CROSSFILTER ( Sales[CustomerKey], Customer[CustomerKey], BOTH )
)

Ohne CROSSFILTER erreicht ein Product-Filter die Tabelle Customer nie, das Measure würde also alle Kunden zählen. Oft gibt es einen einfacheren Weg. Zählt man den Schlüssel in der Faktentabelle, erhält man dieselbe Zahl ohne Richtungsänderung:

Customers Who Bought =
DISTINCTCOUNT ( Sales[CustomerKey] )

Nutzen Sie CROSSFILTER, wenn Sie weitere Spalten der Dimension brauchen, nicht nur den Schlüssel.

Praxisanwendungen und Beispiele

Nehmen Sie ein Modell mit der Faktentabelle Sales und drei Dimensionen: Product, Customer und Date. Alle drei Beziehungen sind Eins-zu-viele und „Einzeln“.

  • Ein Slicer für Product Category filtert Sales, und jedes Umsatz-Measure reagiert.

  • Derselbe Slicer filtert die Tabelle Customer nicht. Ein Customer-Slicer auf der Seite listet weiterhin jeden Kunden auf.

  • Ein Measure, das „Kunden, die diese Kategorie gekauft haben“ braucht, nutzt CROSSFILTER oder zählt Sales[CustomerKey], wie oben gezeigt.

Stellen Sie nun die Beziehung zwischen Sales und Customer auf „Beide“. Der Customer-Slicer schrumpft jetzt auf Kunden, die die gewählte Kategorie gekauft haben. Das kann genau das sein, was die Seite braucht. Aber der Product-Slicer filtert nun auch Customer, und Customer filtert Sales. Steht Date ebenfalls auf „Beide“, gibt es zwischen manchen Tabellen zwei Wege. Dort beginnt die Mehrdeutigkeit. Bleiben die Beziehungen auf „Einzeln“ und wird der Sonderfall in einem Measure gelöst, vermeiden Sie sie.

Beziehungseigenschaften und Kardinalität

Die Cross-Filter-Richtung ist eine von mehreren Beziehungseigenschaften. Die anderen sind:

  • Kardinalität, die bestimmt, welche Richtungsoptionen es gibt (siehe Tabelle oben).

  • Aktiv oder inaktiv, denn zwischen zwei Tabellen kann es nur einen aktiven Pfad geben.

  • Referenzielle Integrität voraussetzen, die es nur für DirectQuery-Beziehungen gibt.

Beziehungen über Spalten mit unterschiedlichen Datentypen oder über Datetime-Spalten mit Zeitanteil passen unabhängig von der Richtung womöglich nicht so zusammen, wie Sie erwarten. Mehr zu Kardinalität und ihrer Wirkung auf die Performance lesen Sie unter Power-BI-Beziehungen und Kardinalität.

Die Cross-Filter-Richtung ist eine Modelleinstellung. Sie unterscheidet sich von den Filtern und Slicern auf Report-Ebene, die in unserem Leitfaden zu Power-BI-Filtern behandelt werden. Zu Sicherheitsfiltern lesen Sie Power BI Row-Level Security.

FAQs

Wie wirkt sich die Kardinalität einer Beziehung auf die Cross-Filter-Richtung in Power BI aus?

Die Kardinalität bestimmt, welche Richtungen verfügbar sind. Eins-zu-viele-Beziehungen können „Einzeln“ oder „Beide“ sein. Eins-zu-eins-Beziehungen sind immer „Beide“. Viele-zu-viele-Beziehungen können in jeweils eine Richtung oder in „Beide“ filtern. Viele-zu-viele-Beziehungen sind außerdem „begrenzte“ Beziehungen, die Power BI erst zur Abfragezeit auswertet. Sie sind daher langsamer als Eins-zu-viele.

Können falsche Datentypen das Verhalten der Cross-Filter-Richtung beeinflussen?

Ja. Eine Beziehung filtert nur, wenn Werte übereinstimmen. Ist eine Spalte Text und die andere eine Zahl, oder die eine ein Datum und die andere ein Datetime mit Zeitanteil, passen die Werte womöglich nicht zusammen. Filter erreichen dann nicht die erwarteten Zeilen, egal welche Richtung gesetzt ist. Stellen Sie beide Spalten in Power Query auf denselben Typ.

Welche Rolle spielt die referenzielle Integrität für die Cross-Filter-Richtung?

Keine direkte. Referenzielle Integrität voraussetzen ist eine eigene Eigenschaft, die es nur für Beziehungen zwischen DirectQuery-Tabellen aus derselben Quelle gibt. Ist sie aktiv, sendet Power BI an die Quelle einen INNER JOIN statt eines OUTER JOIN, was meist schneller ist. Haben manche Faktenzeilen keine passende Dimensionszeile, verschwinden diese Zeilen aus den Ergebnissen. Schalten Sie sie daher nur ein, wenn die Daten sauber sind.

Quellen

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

Zeigen Sie uns Ihren Report, dem niemand traut.

1 · Ein Gespräch von 30 Minuten.

2 · Wir sehen uns gemeinsam Ihre aktuellen Reports an.

3 · Wir sagen Ihnen, was wir tun würden.

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut – auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut – auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch

CaseWhen ist eine BI-Beratung aus Berlin. Wir bauen Reporting, dem die Geschäftsführung vertraut – auf dem Microsoft-Stack: Power BI, Fabric und Azure.

Berlin, Deutschland

© CaseWhen Consulting GmbH

Deutsch