Power BI Datenquellen: Welche es gibt – und wie du sie sauber anbaust

Definition

Power BI Datenquellen sind Systeme, Dateien oder Dienste, aus denen Power BI Desktop oder der Power BI Service Daten abruft, um Berichte und Dashboards zu erstellen. Dazu zählen zum Beispiel Excel/CSV-Dateien, SQL Server, Cloud-Dienste und Web-Schnittstellen.

Power BI ist keine Datenbank und kein Data Warehouse, sondern nutzt Konnektoren und Power Query zur Verbindung und Transformation; die Speicherung passiert je nach Modus im Dataset oder bleibt in der Quellsystem-Datenbank.

Einleitung

Wenn Reports daran scheitern, sind es selten die Visualisierungen – meist sind es die Power BI Datenquellen: Excel-Dateien auf dem Fileserver, wechselnde Tabellenspalten, ein persönliches Gateway oder eine SQL-Datenbank ohne klare Zuständigkeit. Ziel ist eine Verbindung, die automatisch aktualisiert, nachvollziehbar ist und nicht bei jedem Monatsabschluss manuell repariert werden muss.

Typische Power BI Datenquellen und Konnektoren

In der Praxis landen die meisten „ersten“ Power-BI-Berichte bei drei Klassen von Datenquellen:

• Dateien: Excel, CSV, manchmal JSON – schnell startklar, aber anfällig für Strukturwechsel (Spalten/Sheets) und Versionschaos.

• Datenbanken: typischerweise SQL Server oder Azure SQL – stabil, performant und gut für wiederkehrende Berichte.

• Cloud- und Web-Quellen: SharePoint/OneDrive, OData oder Web-APIs – praktisch für zentrale Ablagen und Integrationen.

Entscheidungsregel: Wenn mehrere Teams „dieselben“ KPIs nutzen sollen, sind Datenbanken oder zentral aufbereitete Cloud-Daten langfristig meist günstiger als viele Excel-Insellösungen.

Schritt für Schritt: Eine Datenquelle in Power BI Desktop anbinden

So baust du eine Verbindungsquelle sauber auf, ohne später im Chaos zu enden:

• 1) In Power BI Desktop: „Daten abrufen“ wählen, dann den passenden Connector (z. B. Excel, SQL Server, Web).

• 2) Authentifizierung festlegen: organisatorisches Konto/Servicekonto statt persönlicher Logins. Das ist die Grundlage für Betrieb und Refresh.

• 3) Im Navigator nur die wirklich benötigten Tabellen auswählen. Weniger ist schneller und wartungsärmer.

• 4) „Daten transformieren“ öffnen: Im Power Query Editor Datentypen setzen, unnötige Spalten entfernen, Schlüsselspalten prüfen und Umbenennungen konsistent halten.

• 5) Laden und prüfen: Beziehungen, Kardinalitäten und Filterrichtung sauber setzen, bevor DAX-Formeln gebaut werden.

Wichtig: Jede Transformation ist ein reproduzierbarer Schritt (M/M-Funktionen). Damit wird aus einmaliger „Excel-Handarbeit“ ein wiederholbarer Prozess.

Aktualität: Import, DirectQuery und Refresh richtig einordnen

Die Wahl des Modus bestimmt, wie „aktuell“ deine Berichte sind und wie stabil sie laufen:

• Import (Power BI): Daten werden ins Dataset geladen. Sehr performant für Berichte, gut für komplexe DAX-Berechnungen. Aktualität kommt über geplante Aktualisierung (Refresh).

• DirectQuery: Power BI fragt die Daten direkt in der Datenbank ab. Vorteil: näher an Echtzeit. Nachteil: Performance und Modellierung hängen stark von der Quelle und Abfrage-Last ab.

• Geplante Aktualisierung: Standard für Reporting. Entscheidend sind stabile Credentials, klarer Zeitplan und Monitoring, damit fehlerhafte Refreshes auffallen.

Typischer Fehler: „Echtzeit“ zu fordern, obwohl „täglich um 6 Uhr“ für Entscheidungen reicht. Das spart Kosten, reduziert Risiko und macht die Berichte schneller.

Gateway, Automatisierung und Betrieb

Sobald Datenquellen on-premises liegen (z. B. SQL Server im Firmennetz), braucht es meist ein Power BI Gateway für den Power BI Service. Für einen stabilen Betrieb zählen drei Dinge:

• Kein persönliches Gateway: Es blockiert Planungssicherheit (Urlaub, Passwortwechsel, Rechner aus).

• Technische Owner und Runbook: Wer reagiert bei Refresh-Fehlern, wo stehen Logs, was ist die Eskalation?

• Klare Trennung: Entwicklung (Power BI Desktop) vs. Betrieb (Service) mit sauberem Deployment.

Automatisierung heißt hier nicht „mehr Technik“, sondern: weniger manuelle Eingriffe, weniger stille Fehler, messbar weniger Aufwand pro Reporting-Zyklus.

ETL-Grundlagen: Dataflows vs. Datasets (und wann was Sinn ergibt)

Dataflows und Datasets werden oft verwechselt, erfüllen aber unterschiedliche Aufgaben:

• Dataflows: zentralisierte ETL mit Power Query im Power BI Service. Ideal, wenn mehrere Berichte dieselbe Aufbereitung brauchen (z. B. gleiche Kontenlogik, gleiche Kundentabelle).

• Datasets: das semantische Modell für Berichte, inklusive Beziehungen, Measures und DAX. Hier entsteht die „Wahrheit“ für KPIs.

Einsatzszenarien: Dataflows für wiederverwendbare Bereinigung/Standardisierung; Datasets für Performance, Modelllogik und konsistente Kennzahlen. Wer alles in jedem Report neu transformiert, bezahlt später mit Wartung und inkonsistenten Zahlen.

Datenmodellierung, Qualität und Governance: die schnellen Hebel

Damit Berichte nicht auseinanderlaufen, helfen ein paar harte Leitplanken:

• Star Schema statt „eine Tabelle mit allem“: Fakten und Dimensionen trennen, Beziehungen sauber halten. Das macht Berichte schneller und verständlicher.

• Namens- und KPI-Standards: Gleiche Begriffe, gleiche Logik, dokumentierte Measures statt Copy/Paste-DAX.

• Datenqualität als Prozess: Pflichtfelder, Dubletten, Datentypen, Plausibilitätschecks. Sonst entsteht nur schnellerer „Garbage in, garbage out“.

Mini-Story: Ein Finanzreport aus DATEV-Exporten und mehreren Excel-Dateien kann monatlich Stunden binden, weil Kontenstrukturen wechseln und Tabellen manuell konsolidiert werden. Mit einer zentralen Aufbereitung (Dataflow) und einem gemeinsamen Dataset werden die Regeln einmal gebaut – und danach automatisch angewendet, inklusive Drilldown in Berichten statt Excel-Suche.

Wann externe Unterstützung sinnvoll wird

Externe Hilfe lohnt sich, wenn du nicht „noch einen Report“, sondern eine tragfähige Basis willst. Typische Auslöser:

• Mehrere Datenquellen (Excel, SQL, Cloud) sollen konsistent zusammengeführt werden, ohne manuelle Zwischenschritte.

• Refreshes sind unzuverlässig (Gateway, Credentials, Timeouts) und blockieren Entscheidungen.

• Wildwuchs droht: viele Datasets, widersprüchliche KPIs, keine Governance, hoher Pflegeaufwand.

Der ROI kommt dabei selten aus „schöneren Dashboards“, sondern aus weniger wiederkehrender Handarbeit, weniger Fehlerkorrekturen und schnellerer Steuerung durch verlässliche Berichte.