Tabellen, Views & Data Builder
Stand 2026-09-03
Der Data Builder trägt 80 % der CU-Kosten. Erfahrenes Muster: die 1/3/10-Regel (1 Analytic Model · 3 Fact Views · 10 Dimension Views), strikte Namenskonvention (Präfix T_/V_/AM_ pro Domäne), grafische Views für Standardarbeit, SQL-Views für performancekritische Fälle. Typen einmalig casten, explizit projizieren, Tabellen > 50 Mio. Zeilen partitionieren. Der Lineage-Graph ist das zweite Liefergut nach der ADR.
Was Sie lernen
- Zwischen lokalen Tabellen, grafischen Views und SQL-Views anhand von Persistenz-, Komplexitäts- und Performance-Kriterien wählen — nicht aus Gewohnheit
- Die 1/3/10-Regel und die T_/V_/AM_-Namenskonvention anwenden, um einen ad hoc gewachsenen Domain-Space in eine prüfbare Form zu refaktorieren
- Die wichtigsten CU-Kosten-Anti-Pattern (Self-Joins, erneutes Casting, SELECT *, fehlende Partitionierung, übermäßige Federation) vor dem Cost-Review eines Kunden diagnostizieren, nicht danach
- Eine Modellierungsempfehlung in eine für den Tagessatz relevante Sprache übersetzen, die ein Sponsor wiederholen kann
Modulüberblick
Der Data Builder ist der Ort, an dem die Datasphere-Modellierung tatsächlich stattfindet, und dort wird der Großteil der laufenden Capacity-Unit-Kosten eines Tenants entschieden, Monate bevor jemand eine Rechnung sieht. Capacity Units werden durch Query-Ausführung, Datenbewegung und Verarbeitungslast verbraucht, was bedeutet, dass jede Modellierungsentscheidung im Data Builder — wie viele Views zwischen Quelle und Konsument liegen, ob ein Join live föderiert oder einmal materialisiert wird, ob eine Berechnung einmal läuft und wiederverwendet oder von jedem nachgelagerten Konsumenten neu berechnet wird — ebenso eine Kostenentscheidung wie eine Designentscheidung ist. Erfahrenes Handwerk in diesem Modul heißt nicht „mehr Views schneller bauen“; es heißt „weniger Views bauen, mit saubereren Verträgen, die auch in sechs Monaten noch Sinn ergeben und performen, wenn ein CFO einen Kostenreview verlangt.“
Voraussetzungen
- Zuerst die Kernkonzepte durcharbeiten: C008, C004, C032
Lernergebnisse
- Lokale Tabellen, grafische Views und SQL-Views anhand von Persistenz, Komplexität und Performance-Profil unterscheiden.
- Einen Wildwuchs von 47 Views in die 1/3/10-Form refaktorieren und dabei die T_/V_/AM_-Namensgebung anwenden.
- Die Architektur und die Entscheidungspunkte für Tables, Views & Data Builder einem fachlichen Sponsor ohne technischen Hintergrund in zwei Minuten erklären.
- Ein wiederholbares ADR- + Model-Validation-Pack erstellen, das auf der Domäne eines anderen Kunden nutzbar ist.
Vollständiges Modul für Mitglieder. Das vollständige Modul ergänzt: den Entscheidungsrahmen · das durchgehende Szenario · die KPI-Scorecard · die Anti-Muster · die Codeblöcke · die Wissenskontrolle · die Schemata.