Der App-Source-Code liegt sicher verwahrt in der Source-Code-Verwaltung. Was ist mit der SQL-Datenbank? Lose Skript-Sammlung oder nur eine operative Datenbankinstanz? Welche Skripte sind aktuell? Was passiert, wenn die Datenbankinstanz beschädigt wird oder verloren geht? Wie können Änderungen vorgenommen werden ohne dabei unbemerkt Fehler an anderen Stellen einzubauen?
Hier helfen SQL-Datenbankprojekte. Egal ob operative Datenbank oder Data Warehouse, die gesamte Struktur der SQL-Datenbank (Tabellen, Sichten, gespeicherte Prozeduren, etc.) wird in Form einzelner SQL-Objekte in einem SQL-Datenbankprojekt verwaltet. Dadurch kann die Datenbank ebenfalls als Quellcode in einer Versionsverwaltung abgelegt und mit CI/CD-Pipelines automatisch in verschiedenen Umgebungen bereitgestellt werden.
Zum ausführlichen Vergleich der Feature-Sets auf Microsoft Learn.
Fabric Lakehouse und Fabric Warehouse sind zwar besonders, da sie nur einen SQL Analytics Endpoint bereitstellen und intern mit Parquet-Dateien arbeiten. Aber auch diese Objekte lassen sich in einem SQL Datenbank Projekt verwalten, wobei bestimmte Einschränkungen zu berücksichtigen sind.
Für dieses Beispiel haben wir vorab in Fabric ein Warehouse "SampleDWH" erstellt und mit den Beispieldaten von Microsoft beladen.
In VS Code (SQL Database Projects Extension) können wir das Schema des Warehouses über das Feature "Create Project From Database" importieren.
Da wir für eine detailliertere Analyse zusätzliche Kennzahlen benötigen, erweitern wir die View "vw_PaymentAnalysis" um die noch fehlenden Spalten.
Das Erstellen des Projekts gibt uns sofort die Rückmeldung, dass wir einen Fehler in unserem Source-Code haben. Es gibt ein Problem mit einer der neu hinzugefügten Spalten in der bearbeiteten View. Die referenzierte Spalte [TollAmount] kann nicht aufgelöst werden.
Nach kurzer Prüfung ist klar, wir haben einen Tippfehler. Der Spaltenname wird zu [TollsAmount] korrigiert und die erneute Erstellung des Projekts ist erfolgreich.
Abschließend können wir das geänderte Datenbank Schema auf der Zielplattform bereitstellen.
Dazu müssen wir zunächst eine Verbindung zur Zielplattform herstellen. Durch einen Abgleich zwischen dem Schema im SQL Projekt und der Datenbank-Instanz werden die Unterschiede identifiziert.
Die notwendigen Änderungen können wir entweder als SQL Statements in einem Skript generieren lassen, das wir anschließend manuell gegen die Datenbank-Instanz ausführen. Oder wir veröffentlichen die Änderungen direkt.
Schauen wir anschließend in Fabric mit dem Explorer in das Warehouse Schema, sehen wir die neu hinzugefügten Spalten.
Alle Informationen zu SQL-Datenbankprojekten gibt es auf Microsoft Learn.
Du entwickelst auf der Produktivumgebung oder hast zwar eine Entwicklungsumgebung aber immer nur den aktuellen Entwicklungsstand?
Was, wenn diese eine Version versehentlich gelöscht wird oder der Admin ein Backup vom Server einspielen muss und damit einen alten Stand wiederherstellt? Wie kommst Du zu einem lauffähigen Entwicklungsstand zurück, wenn eine Deiner letzten Änderungen zu einem Fehler an ganz anderer Stelle geführt hat und das erst eine Woche später aufgefallen ist? Wie hältst Du den Überblick über unzählige Kopien und Zwischenstände Deiner Entwicklungsarbeit?
Was das Backup für die Datenbank ist, ist die Versionskontrolle für Deine Entwicklung! Diese hilft Dir, Deine Entwicklungsarbeit zu sichern und zu versionieren, auch im Team. Die Nachverfolgung aller Änderungen ist problemlos möglich und jederzeit kannst Du auf einen älteren Entwicklungsstand zurückgreifen.
Entwicklung mit Netz und doppeltem Boden!
Bei Entwicklungsprozessen, die auf einer gemeinsamen zentralen Umgebung aufsetzen, wie beispielsweise einem Fabric-Arbeitsbereich, muss darauf geachtet werden, dass sich Entwickler nicht gegenseitig in ihrer Arbeit stören. Grundsätzlich lassen sich zwei Szenarien unterscheiden.
Lokale Entwicklung mit Client-Tools
Entwicklung in isoliertem Arbeitsbereich
Alle Informationen zu Microsoft Fabric-Git-Integration gibt es auf Microsoft Learn.
Das neue Feature ist implementiert. Die DWH-Datenbank ist erweitert. Der Lade-Prozess ist angepasst. Wie bekommst Du die Änderungen zuerst in die Test-Umgebung, damit der Fachbereich sie dort testen kann? Und wie kommen später nur diese getesteten Änderungen in die Produktiv-Umgebung?
Deine Bereitstellung ist jedes Mal ein Eier-Tanz? Du spielst Änderungen manuell in die Ziel-Umgebung und musst regelmäßig nacharbeiten? Du sammelst vor jeder Bereitstellung einen Berg von Änderungsskripten?
Deployment Pipelines sind der standardisierte Prozess, Deine neuen Features automatisiert in der Ziel-Umgebung bereitzustellen!
Ein standardisierter und automatisierter Prozess ohne fehleranfällige manuelle Schritte. Egal, ob Entwicklungs-, Test- oder Produktiv-Umgebung, alle Umgebungen werden gleich bereitgestellt. Keine manuellen Skripte mehr, da nur bereitgestellt wird, was in der Quellcode-Verwaltung liegt.
Deployment Pipelines ermöglichen eine standardisierte Automatisierung. Alle Deine Ziel-Umgebungen können auf die gleiche Weise bereitgestellt werden. Du kannst sicher sein, dass keine Änderung in die Produktiv-Umgebung gelangt, die nicht vorher auch in der Test-Umgebung zum Testen bereit stand.
Es gibt verschiedene Optionen. Abhängig von den Rahmenbedingungen im Projekt passt nicht nur die eine oder die andere, sondern es ist auch eine Kombination aus mehreren Optionen möglich.
Azure Pipelines
Alle Informationen zu Azure Pipelines gibt es auf Microsoft Learn.
Git-basiertes Deployment (Fabric)
Git-basiertes Deployment mit Build-Umgebungen (Fabric)
Fabric Deployment Pipelines
Alle Informationen zu Fabric CI/CD-Workflowoptionen sowie die Bild-Quelle gibt es auf Microsoft Learn.
Bei der Erstellung eines Warehouse oder Lakehouse erstellt Fabric automatisch auch ein Default Power BI Semantic Model. Erkennbar am Suffix "(default)" in der Typbezeichnung.
Das Default Semantic Model erbt die Objekte und Beziehungen aus dem zugehörigen Warehouse bzw. dem SQL Analytics Endpoint des Lakehouse und soll dadurch die direkte Darstellung und Analyse der enthaltenen Daten in Power BI in nur wenigen Schritten ermöglichen.
Das klingt auf den ersten Blick vielversprechend! Aber wie gut ist das Default Semantic Model wirklich? Was können wir automatisiert erstellen lassen und wo müssen wir manuell nacharbeiten?
Standardmäßig werden Warehouse und Default Semantic Model nicht automatisch synchronisiert. Im Warehouse neu hinzugefügte Objekte müssen manuell in das Modell aufgenommen werden.
Die automatische Synchronisierung kann über die Warehouse Einstellungen konfiguriert werden. Dadurch wird ein Hintergrundprozess angestoßen, der OneLake-Nutzungskosten verursacht.
Für diesen Versuch erstellen wir in Fabric ein Warehouse und beladen es mit den Beispieldaten von Microsoft. Dadurch wird automatisch ein gleichnamiges Default Power BI Semantic Model erzeugt.
Bevor wir einen Report erstellen können, müssen wir definieren, welche Objekte in das Default Semantic Model aufgenommen werden sollen. Es können alle Tabellen und Sichten in das Modell übernommen werden oder nur ausgewählte.
Wir wählen nur Tabellen und erhalten ein sofort in Power BI verwendbares Modell.
Der erste Report ist allerdings weniger überzeugend. In jedem Monat derselbe Umsatz lässt vermuten, dass Beziehungen fehlen oder falsch sind.
Ein Blick in das Default Semantic Model bestätigt unsere Vermutung. Es existieren keinerlei Beziehungen zwischen den Tabellen.
Per SQL legen wir Primary-Keys in den Dimensions-Tabellen und Foreign-Key-Beziehungen von der Fakten-Tabelle zu den Dimensions-Tabellen an. Dadurch werden automatisch die logischen Beziehungen im Default Semantic Model synchronisiert.
Ob die Beziehungen im Warehouse per SQL erstellt oder im Default Semantic Model per Drag-and-Drop modelliert werden, ist tatsächlich nicht wichtig. Fabric hält beide Definitionen synchron.
Da wir das Default Semantic Model ohne manuelle Nacharbeiten möglichst weit bringen wollen, definieren wir die Beziehungen per SQL. Dies könnte beispielsweise auch über ein SQL Database Project erfolgen.
Die doppelt vorhandenen Beziehungen zwischen der Fakten-Tabelle und zwei Dimensions-Tabellen irritieren noch, aber dieses Modell liefert schon einmal plausiblere Werte.
Um die doppelten Beziehungen loszuwerden und erweiterte Auswertungsmöglichkeiten im Modell bereitzustellen, legen wir per SQL für jede Role-Playing-Dimension eine eigene View auf die Dimensions-Tabelle an.
Anschließend müssen noch die Primary- und Foreign-Keys angepasst und die neuen Views ins Default Model übernommen werden.
Damit erhalten wir tatsächlich ein sauberes Star-Schema in unserem Default Power BI Semantic Model, das so alleine mit der Definition in SQL sofort in Power BI einsetzbar ist und per Direct Lake Mode auf die Daten zugreift.
Die Bezeichnungen für Tabellen und Spalten werden aus dem Warehouse geerbt und grundsätzlich sind alle Spalten erst einmal sichtbar. Um das Modell anwenderfreundlicher zu gestalten und z.B. technische Spalten auszublenden oder Hierarchien und Measures hinzuzufügen, muss das Modell weiter bearbeitet werden.
Row-Level-Security wird im Default Semantic Model nicht unterstützt. Dazu muss ein separates Semantic Model angelegt werden, das dann aber nicht mehr mit dem Warehouse oder SQL Analytics Endpoint des Lakehouse verbunden ist.
Die Idee war, ein Fabric Warehouse per SQL soweit vorzubereiten, dass das automatisch generierte Default Semantic Model möglichst ohne weitere oder zumindest nur mit sehr wenigen manuellen Schritten sofort einsatzbereit ist.
Herausgestellt hat sich:
Alle Informationen zum Default Power BI Semantic Model gibt es auf Microsoft Learn.
