Häufig gestellte Fragen

Das erste Treffen ist ein offenes Gespräch. Wir stellen Fragen zum Geschäftskontext, zu aktuellen Problemen und zum erwarteten Ergebnis, Sie erzählen von Ihrer Vision. Am Ende haben beide Seiten ein Verständnis dafür, wie die Aufgabe angegangen werden sollte.

Wir können einen Tech-Stack oder eine Architektur empfehlen, eine Orientierung zu Budget und Zeitrahmen geben und Umsetzungsvarianten vorschlagen. Wenn Ihre Anfrage außerhalb unseres Kompetenzbereichs liegt, sagen wir das immer offen.

Ein Lakehouse verbindet die Prinzipien von Data Lake und Data Warehouse: Es erlaubt die Arbeit mit großen Mengen unterschiedlichster Daten und unterstützt zugleich strukturierte Analytik. Eine universell bessere Variante gibt es allerdings nicht: Die Wahl zwischen Data Lake, Data Warehouse und Data Lakehouse hängt von den Datentypen, den Analyseaufgaben und den Anforderungen an die Architektur ab.

Ja, wir unterzeichnen ein NDA in jeder Phase. Wir gehen respektvoll mit den Informationen unserer Kunden um und schätzen unseren eigenen Ruf. Wir haben eine eigene NDA-Vorlage, aber wenn der Kunde eine andere hat, stimmen wir sie ohne unnötige Komplikationen ab.

In einer vereinfachten Architektur lassen sich vier Hauptblöcke unterscheiden: Datenquellen und Integrationen, Speicher, die Analytik- und BI-Schicht sowie Governance – Regeln für Zugriff, Qualität und Datenverwaltung. In komplexeren Plattformen können auch Datenverarbeitung, Katalogisierung, Monitoring und Sicherheitswerkzeuge eigene Komponenten sein.

Der Support nach dem Release ist ein eigener Arbeitsbereich. Bei Bedarf unterzeichnen wir ein SLA und übernehmen die Verantwortung für Uptime, Fehlerbehebung und Updates. Das Format hängt vom Projekt ab: Mal ist eine Reaktion innerhalb einer Stunde nötig, mal reicht eine wöchentliche Durchsicht der Logs. Auch die Dauer ist flexibel: von einigen Monaten bis zur langfristigen Betreuung.

Schrittweise: zuerst ein Audit der bestehenden Systeme, um zu verstehen, welche Datenquellen kritisch sind. Danach – die Wahl der Architektur passend zur Größe des Unternehmens. Anschließend der Aufbau der ETL/ELT-Pipelines, die die Daten übertragen und transformieren. Und erst am Ende – die Anbindung der BI-Schicht für Dashboards und Berichte. Wird das Audit übersprungen oder gleich mit BI begonnen, steigt das Risiko, dass die Plattform auf widersprüchlichen Daten aufgebaut wird und schon nach dem Start überarbeitet werden muss.

Dem Auftraggeber, in vollem Umfang. Code, Dokumentation und Infrastruktur gehen nach Zahlung und Unterzeichnung der Dokumente an den Kunden über. Wenn im Projekt Drittanbieter-Bibliotheken oder Tools mit eigenen Lizenzbedingungen verwendet werden, wird das zu Beginn besprochen.

RLS beschränkt den Zugriff auf einzelne Zeilen des Datenmodells je nach Rolle des Nutzers. Deshalb kann ein und derselbe Bericht verschiedenen Personen unterschiedliche Daten anzeigen.

Ja, natürlich. Bevor wir ein solches Projekt übernehmen, führen wir ein Audit durch: Wir prüfen Code, Architektur, Zustand der Infrastruktur, Dokumentation und Zugänge. Danach geben wir eine ehrliche Einschätzung, was weiterentwickelt werden kann und was günstiger neu zu schreiben wäre. Wenn die Lösung tragfähig ist, übernehmen wir den Support, beheben die kritischen Stellen und bewegen uns schrittweise vorwärts.

Erstellen Sie eine RLS-Rolle, definieren Sie die Filterregel, testen Sie sie, veröffentlichen Sie das Modell und weisen Sie der Rolle im Power BI Service Nutzer oder Gruppen zu. Prüfen Sie zusätzlich ihre Rechte im Arbeitsbereich und den Zugriff auf den Bericht.

Sicherheit wird vom ersten Tag an in die Architektur eingebaut. Zugriffsmodelle, Rollenkontrolle, Verschlüsselung und Aktionsprotokollierung sind Grundelemente, die selbst in relativ einfachen Projekten vorhanden sind.

In internen Systemen beschränken wir Zugriffe und implementieren mehrstufige Autorisierung. Im BI-Bereich isolieren wir Umgebungen und kontrollieren Berechtigungen bis auf die Ebene einzelner Dashboards. Im E-Commerce — API-Schutz, Zahlungsverschlüsselung, Traffic-Audit. Wir haben mit Banken, Behörden und Kanzleien gearbeitet, wo die Sicherheitsanforderungen besonders streng sind.

Bei statischem RLS ist die Filterregel fest an eine Rolle gebunden. Bei dynamischem RLS kann sie sich je nach Nutzer ändern, zum Beispiel über USERPRINCIPALNAME() und eine Zuordnungstabelle.

Dafür wird RLS Power BI verwendet: die Regeln des Modells legen fest, welche Daten der Nutzer nach der Anmeldung sieht.

Verwenden Sie in Power BI Desktop View as, um den Bericht im Namen einer Rolle zu prüfen. Nach der Veröffentlichung kann die Rolle auch im Power BI Service getestet werden.

Typische Fehler: ein Fehler im DAX-Filter, falsch zugewiesene Rollen im Arbeitsbereich, eine veraltete Zuordnungstabelle und der Versuch, RLS durch gewöhnliche Filter im Bericht zu ersetzen.

DAX (Data Analysis Expressions) ist die Formelsprache für Berechnungen in Power BI. DAX arbeitet mit den Tabellen, Spalten und Beziehungen des Datenmodells, und das Ergebnis einer Kennzahl ändert sich je nach den aktuellen Filtern im Bericht.

Mit DAX lassen sich eigene Business-Kennzahlen erstellen: zum Beispiel die Marge berechnen, Werte zwischen Zeiträumen vergleichen oder eine kumulierte Summe bilden. Power BI funktioniert auch ohne eigene DAX-Formeln, aber DAX in Power BI wird für Berechnungen gebraucht, die in den Quelldaten nicht vorhanden sind und sich je nach Berichtsfiltern ändern müssen.

Eine berechnete Spalte wird bei der Datenaktualisierung berechnet, ihre Werte werden im Modell gespeichert. Eine Kennzahl (Measure) wird während der Arbeit mit dem Bericht berechnet und reagiert auf die aktuellen Filter, etwa auf die gewählte Region oder den Zeitraum. Für dynamische Werte nutzt man in der Regel Kennzahlen, berechnete Spalten braucht man für Berechnungen auf Zeilenebene.

Es genügt, den Grundstock sicher zu beherrschen: CALCULATE (Änderung des Filterkontexts), SUM und SUMX (Aggregation), DIVIDE (sichere Division) sowie die Zeitintelligenz-Funktionen — SAMEPERIODLASTYEAR, DATESYTD, TOTALYTD.

CALCULATE berechnet einen Ausdruck, nachdem die Filterbedingungen geändert wurden. So lassen sich zum Beispiel die Umsätze einer bestimmten Kategorie ermitteln, indem der aktuelle Filter durch die Produktkategorie ersetzt wird, während die übrigen Berichtsfilter erhalten bleiben. Deshalb ist das Verständnis von CALCULATE die Grundlage für viele komplexere DAX-Formeln.