Primärschlüssel, Composite Keys, Surrogate Keys und ID-Strategien im Data Warehouse

Einleitung

In der Welt der Datenmodellierung sind IDs das zentrale Element zur Verknüpfung und Identifikation von Datensätzen. Dabei gibt es verschiedene Typen von Schlüsseln, die je nach Anwendungsfall unterschiedliche Vor- und Nachteile mit sich bringen. In diesem Artikel werfen wir einen detaillierten Blick auf IDs aus Quellsystemen (auch “natürliche Schlüssel” genannt), zusammengesetzte Primärschlüssel (Composite Keys), Surrogate Keys, sowie moderne Methoden zur Schlüsselgenerierung wie Hashing und strukturierte numerische IDs. Ziel ist es, ein Verständnis für die richtige ID-Strategie zu vermitteln, um Speicher zu sparen, Performance zu verbessern und Datenmodelle wartbar zu halten.

Warum numerische IDs grundsätzlich sinnvoll sind

Bevor wir in die verschiedenen Arten von Schlüsseln eintauchen, lohnt es sich, einen Blick auf die grundlegende Frage zu werfen: Warum sollte man IDs überhaupt als numerische Werte – idealerweise als INT oder BIGINT – speichern?

Speicherbedarf

Numerische Werte wie INT (4 Byte) oder BIGINT (8 Byte) sind extrem kompakt. Im Vergleich dazu belegen Textschlüssel (z. B. VARCHAR(50)) ein Vielfaches an Speicherplatz – insbesondere bei hoher Kardinalität. In In-Memory-Modellen wie VertiPaq (Power BI) wird der Speicherbedarf für Dictionary, Indizes und Komprimierung maßgeblich durch die Art des Datentyps beeinflusst. Zahlen lassen sich deutlich besser komprimieren als Strings oder GUIDs.

Performance

Numerische Schlüssel sind in BI-Tools (z. B. Power BI, Analysis Services, SQL Server) in allen relevanten Operationen schneller:

• Joins laufen schneller, weil INT = INT effizienter als STRING = STRING ist
• Groupings und Filters auf numerischen Werten sind performanter
• Speicherzugriffe und Caching funktionieren besser, da die internen Datenstrukturen für Zahlen optimiert sind

GUIDs – ein Sonderfall mit Nachteilen

Globally Unique Identifiers (GUID, UNIQUEIDENTIFIER) sind zwar eindeutig und flexibel – aber in vielen Fällen ungeeignet für performante BI-Modelle:

• 16 Byte groß (im Vergleich zu 4 Byte bei INT)
• sehr schlecht komprimierbar (jede ID ist einzigartig → keine Wiederholung im Dictionary)
• unnatürlich verteilt → keine effiziente Sortierung
• schwierig zu lesen und zu verwenden

Selbst in Systemen, die GUIDs verwenden, ist es ratsam, im DWH einen numerischen Surrogate Key zu erzeugen und intern zu verwenden.

Kurzum: Wer speichereffiziente und performante Datenmodelle bauen möchte, sollte immer versuchen, mit kompakten numerischen Schlüsseln zu arbeiten – unabhängig davon, ob es sich um natürliche, surrogate oder generierte IDs handelt.

Natürliche Schlüssel (Business Keys)

Wichtig ist hier die Unterscheidung zwischen tatsächlichen, im Quellsystem vorhandenen Business Keys und konstruierten zusammengesetzten Schlüsseln, die erst im DWH erzeugt werden. Ein häufiger Irrtum ist es, verkettete Felder wie Company_Year_DocumentID_ItemNo als natürlichen Schlüssel zu interpretieren. Diese Art von ID wird zwar aus fachlich begründeten Bestandteilen gebildet, ist aber kein natürlicher Schlüssel im engeren Sinne, da sie:

• im Quellsystem oft nicht explizit als eine Spalte vorhanden ist,
• erst nachträglich im ETL-Prozess zusammengesetzt wird,
• technisch motiviert ist (z. B. für Hashing oder strukturierte IDs).

Ein solcher Schlüssel ist somit eher ein verketteter Composite Key, auch wenn er fachlich interpretierbare Inhalte enthält. Für Speicher- und Performancezwecke ist es oft besser, daraus entweder eine strukturierte numerische ID oder einen Surrogate Key zu erzeugen.

Natürliche Schlüssel sind IDs, die bereits im Quellsystem existieren und aus fachlicher Sicht eine eindeutige Identifikation bieten. Beispiele sind Personalnummern, Kundennummern, oder zusammengesetzte IDs wie Company_Year_DocumentID_ItemNo.

Vorteile:

• Direkt verständlich, da semantisch bedeutsam
• Benötigen keine separate Erzeugung
• Können für externe Schlüsselvergleiche genutzt werden

Nachteile:

• Häufig lang und schlecht komprimierbar (z. B. Strings)
• Ändern sich mitunter, z. B. bei Migrationen
• Führen zu hoher Kardinalität und Speicherverbrauch in BI-Modellen

Composite Keys

Composite Keys sind zusammengesetzte Primärschlüssel, die mehrere Spalten zur eindeutigen Identifikation eines Datensatzes kombinieren. Dabei lassen sich drei Hauptformen unterscheiden:

1. Klassische Composite Keys (mehrere Spalten)

Diese Form besteht aus einer Kombination von Feldern wie CustomerID, OrderDate und ItemNo, die gemeinsam die Eindeutigkeit eines Datensatzes sicherstellen. Sie kommen insbesondere in relationalen Datenbanken zum Einsatz, wo zusammengesetzte Primärschlüssel direkt unterstützt werden.

Vorteile:

• Eindeutigkeit direkt aus den Daten abgeleitet
• Häufig natürlich in operativen Systemen vorhanden

Nachteile:

• Erfordern komplexe Joins über mehrere Spalten
• In analytischen Systemen wie Power BI weniger performant
• Hoher Speicherverbrauch, insbesondere bei hoher Kardinalität

2. Verkettete Composite Keys (technisch zusammengesetzter Text)

Hierbei werden mehrere Felder zu einer einzigen Zeichenkette zusammengefügt, z. B. Company_Year_DocumentID_ItemNo. Diese Form ist technisch gesehen ein Composite Key, jedoch existiert er meist nicht als solche Spalte im Quellsystem.

Vorteile:

• Einfach zu erzeugen, z. B. zur Verwendung in Hashing oder strukturierter ID-Bildung
• Eindeutigkeit bleibt erhalten

Nachteile:

• Als Text schlecht komprimierbar
• Für Joins ineffizient
• Keine fachlich semantische Bedeutung als Spalte
• Kann bei sehr langen Werten zu Performanceverlust führen

3. Strukturierte numerische Composite Keys

Diese Form basiert ebenfalls auf der Kombination mehrerer fachlicher Felder, wird jedoch nicht als Text, sondern in ein strukturiertes numerisches Format überführt. Beispiel:

Company = 2000, Year = 2024, DocumentNo = 100000022, ItemNo = 000002 → wird zu: 2000202410000002200002

Diese ID kann als BIGINT oder DECIMAL(38,0) gespeichert werden.

Vorteile:

• Kompakt, eindeutig und sehr gut komprimierbar in VertiPaq
• Reversibel (bei festgelegter Struktur mit fixer Zeichenlänge)
• Bessere Performance als Text-IDs oder klassische Composite Keys
• Keine Kollisionen wie bei Hashing-Verfahren

Nachteile:

• Implementierung etwas aufwändiger (Padding, Formatierung)
• Disziplin erforderlich beim Aufbau und bei der Rückübersetzung
• Eingeschränkte Lesbarkeit

Einsatzempfehlung: Strukturierte numerische Composite Keys sind ideal, wenn ein hoher Wert auf Speicher- und Performanceoptimierung gelegt wird, die ursprüngliche Semantik aber teilweise erhalten bleiben soll. Sie lassen sich gut mit Lookup-Tabellen kombinieren, in denen die Originalbestandteile gespeichert sind (z. B. via DirectQuery abrufbar).

Hinweis: Strukturierte numerische IDs sind streng genommen eine Sonderform verketteter Composite Keys – sie basieren auf denselben Informationen, werden jedoch als komprimierter, interpretierbarer Zahlwert gespeichert.

Surrogate Keys (technische Schlüssel)

Surrogate Keys sind künstlich erzeugte, in der Regel numerische IDs, die als Ersatz für natürliche oder zusammengesetzte Schlüssel dienen.

Vorteile:

• Sehr performant (numerisch, konstant)
• Optimal komprimierbar
• Entkoppeln das Data Warehouse vom Quellsystem
• Unterstützung für Slowly Changing Dimensions (Typ 2)
• Einheitliche Joins zwischen Fakt- und Dimensionstabellen
• Schutz vor Duplikaten und Konflikten bei Quellensystem-Zusammenführungen

Nachteile:

• Keine fachliche Bedeutung mehr
• Zusätzliche Pflege notwendig (z. B. Lookup-Tabellen)
• Mapping-Fehler möglich, wenn nicht sauber implementiert

Auch sinnvoll bei bereits numerischen, natürlichen Keys

Selbst wenn ein natürlicher Schlüssel im Quellsystem bereits als INT vorliegt, kann ein Surrogate Key sinnvoll sein. Gründe dafür sind:

• Systemunabhängigkeit: Bei Migrationen oder Quellsystemwechseln bleibt der Surrogate Key stabil, auch wenn sich der natürliche Key ändert.
• Integration mehrerer Systeme: Zwei unterschiedliche Systeme könnten dieselbe ID verwenden – ein Surrogate Key verhindert Kollisionen.
• Historisierung: Auch bei konstanten numerischen Keys können sich Zustände (z. B. Name, Adresse) ändern, die über unterschiedliche Surrogate Keys erfasst werden.
• Zentrale Pflege: Einheitliches Format und zentrale Verwaltung erleichtern Datenmanagement und Datenqualitätssicherung.

Hashing von natürlichen Schlüsseln

Hashing ist eine Technik zur Generierung kompakter, technischer Schlüssel aus einem oder mehreren Attributen, die zusammen einen natürlichen oder zusammengesetzten Schlüssel bilden. Dabei wird eine Hashfunktion verwendet, um aus einem beliebigen Eingabewert (z. B. CustomerID, Company_Year_DocumentID_ItemNo) einen numerischen oder binären Hashwert zu erzeugen.

Diese Methode eignet sich besonders, wenn man keine Surrogate Keys verwenden möchte, aber dennoch mit einem effizient speicherbaren und performanten Schlüssel arbeiten will. Insbesondere dann, wenn natürliche Schlüssel nicht in strukturierte numerische Composite Keys überführt werden können – etwa weil sie alphanumerische oder freie Textbestandteile enthalten – kann Hashing eine effektive Lösung sein.

Ein großer Vorteil des Hashings liegt in seiner Deterministik: Aus demselben Eingabewert wird immer derselbe Hashwert erzeugt. Dadurch kann ein natürlicher Schlüssel konsistent in ein technisches Format überführt werden, das sich hervorragend zur Verwendung in Datenmodellen eignet.

Allerdings ist zu beachten, dass gehashte Werte in der Regel nicht reversibel sind. Das bedeutet: Aus dem Hash lässt sich der ursprüngliche Textwert nicht mehr zurückgewinnen. Hashing ist also keine Transformation, sondern eine Einweg-Funktion.

Typische Implementierungen:

• CHECKSUM() in SQL Server erzeugt einen INT, ist jedoch nicht kollisionssicher (mehrere verschiedene Eingaben können denselben Wert ergeben).
• HASHBYTES('SHA1', ...) erzeugt einen VARBINARY(20)-Wert mit extrem geringer Kollisionswahrscheinlichkeit und ist damit für produktive Umgebungen deutlich geeigneter.

Hashing ist besonders dann sinnvoll, wenn:

• mehrere Felder zu einem eindeutigen technischen Key kombiniert werden sollen,
• der natürliche Schlüssel sehr lang ist oder komplexe Zeichenketten enthält,
• man keinen expliziten Surrogate Key einführen möchte, aber dennoch von den Vorteilen kompakter numerischer IDs profitieren will.
• Ideal, wenn natürliche Keys zu groß für den Speicher sind, aber nicht geopfert werden sollen
• HASHBYTES für produktive Systeme, CHECKSUM nur für Tests/Temporäres

Einleitung

In der Welt der Datenmodellierung sind IDs das zentrale Element zur Verknüpfung und Identifikation von Datensätzen. Dabei gibt es verschiedene Typen von Schlüsseln, die je nach Anwendungsfall unterschiedliche Vor- und Nachteile mit sich bringen. In diesem Artikel werfen wir einen detaillierten Blick auf IDs aus Quellsystemen (auch “natürliche Schlüssel” genannt), zusammengesetzte Primärschlüssel (Composite Keys), Surrogate Keys, sowie moderne Methoden zur Schlüsselgenerierung wie Hashing und strukturierte numerische IDs. Ziel ist es, ein Verständnis für die richtige ID-Strategie zu vermitteln, um Speicher zu sparen, Performance zu verbessern und Datenmodelle wartbar zu halten.

Warum numerische IDs grundsätzlich sinnvoll sind

Bevor wir in die verschiedenen Arten von Schlüsseln eintauchen, lohnt es sich, einen Blick auf die grundlegende Frage zu werfen: Warum sollte man IDs überhaupt als numerische Werte – idealerweise als INT oder BIGINT – speichern?

Speicherbedarf

Numerische Werte wie INT (4 Byte) oder BIGINT (8 Byte) sind extrem kompakt. Im Vergleich dazu belegen Textschlüssel (z. B. VARCHAR(50)) ein Vielfaches an Speicherplatz – insbesondere bei hoher Kardinalität. In In-Memory-Modellen wie VertiPaq (Power BI) wird der Speicherbedarf für Dictionary, Indizes und Komprimierung maßgeblich durch die Art des Datentyps beeinflusst. Zahlen lassen sich deutlich besser komprimieren als Strings oder GUIDs.

Performance

Numerische Schlüssel sind in BI-Tools (z. B. Power BI, Analysis Services, SQL Server) in allen relevanten Operationen schneller:

• Joins laufen schneller, weil INT = INT effizienter als STRING = STRING ist
• Groupings und Filters auf numerischen Werten sind performanter
• Speicherzugriffe und Caching funktionieren besser, da die internen Datenstrukturen für Zahlen optimiert sind

GUIDs – ein Sonderfall mit Nachteilen

Globally Unique Identifiers (GUID, UNIQUEIDENTIFIER) sind zwar eindeutig und flexibel – aber in vielen Fällen ungeeignet für performante BI-Modelle:

• 16 Byte groß (im Vergleich zu 4 Byte bei INT)
• sehr schlecht komprimierbar (jede ID ist einzigartig → keine Wiederholung im Dictionary)
• unnatürlich verteilt → keine effiziente Sortierung
• schwierig zu lesen und zu verwenden

Selbst in Systemen, die GUIDs verwenden, ist es ratsam, im DWH einen numerischen Surrogate Key zu erzeugen und intern zu verwenden.

Kurzum: Wer speichereffiziente und performante Datenmodelle bauen möchte, sollte immer versuchen, mit kompakten numerischen Schlüsseln zu arbeiten – unabhängig davon, ob es sich um natürliche, surrogate oder generierte IDs handelt.

Natürliche Schlüssel (Business Keys)

Wichtig ist hier die Unterscheidung zwischen tatsächlichen, im Quellsystem vorhandenen Business Keys und konstruierten zusammengesetzten Schlüsseln, die erst im DWH erzeugt werden. Ein häufiger Irrtum ist es, verkettete Felder wie Company_Year_DocumentID_ItemNo als natürlichen Schlüssel zu interpretieren. Diese Art von ID wird zwar aus fachlich begründeten Bestandteilen gebildet, ist aber kein natürlicher Schlüssel im engeren Sinne, da sie:

• im Quellsystem oft nicht explizit als eine Spalte vorhanden ist,
• erst nachträglich im ETL-Prozess zusammengesetzt wird,
• technisch motiviert ist (z. B. für Hashing oder strukturierte IDs).

Ein solcher Schlüssel ist somit eher ein verketteter Composite Key, auch wenn er fachlich interpretierbare Inhalte enthält. Für Speicher- und Performancezwecke ist es oft besser, daraus entweder eine strukturierte numerische ID oder einen Surrogate Key zu erzeugen.

Natürliche Schlüssel sind IDs, die bereits im Quellsystem existieren und aus fachlicher Sicht eine eindeutige Identifikation bieten. Beispiele sind Personalnummern, Kundennummern, oder zusammengesetzte IDs wie Company_Year_DocumentID_ItemNo.

Vorteile:

• Direkt verständlich, da semantisch bedeutsam
• Benötigen keine separate Erzeugung
• Können für externe Schlüsselvergleiche genutzt werden

Nachteile:

• Häufig lang und schlecht komprimierbar (z. B. Strings)
• Ändern sich mitunter, z. B. bei Migrationen
• Führen zu hoher Kardinalität und Speicherverbrauch in BI-Modellen

Composite Keys

Composite Keys sind zusammengesetzte Primärschlüssel, die mehrere Spalten zur eindeutigen Identifikation eines Datensatzes kombinieren. Dabei lassen sich drei Hauptformen unterscheiden:

1. Klassische Composite Keys (mehrere Spalten)

Diese Form besteht aus einer Kombination von Feldern wie CustomerID, OrderDate und ItemNo, die gemeinsam die Eindeutigkeit eines Datensatzes sicherstellen. Sie kommen insbesondere in relationalen Datenbanken zum Einsatz, wo zusammengesetzte Primärschlüssel direkt unterstützt werden.

Vorteile:

• Eindeutigkeit direkt aus den Daten abgeleitet
• Häufig natürlich in operativen Systemen vorhanden

Nachteile:

• Erfordern komplexe Joins über mehrere Spalten
• In analytischen Systemen wie Power BI weniger performant
• Hoher Speicherverbrauch, insbesondere bei hoher Kardinalität

2. Verkettete Composite Keys (technisch zusammengesetzter Text)

Hierbei werden mehrere Felder zu einer einzigen Zeichenkette zusammengefügt, z. B. Company_Year_DocumentID_ItemNo. Diese Form ist technisch gesehen ein Composite Key, jedoch existiert er meist nicht als solche Spalte im Quellsystem.

Vorteile:

• Einfach zu erzeugen, z. B. zur Verwendung in Hashing oder strukturierter ID-Bildung
• Eindeutigkeit bleibt erhalten

Nachteile:

• Als Text schlecht komprimierbar
• Für Joins ineffizient
• Keine fachlich semantische Bedeutung als Spalte
• Kann bei sehr langen Werten zu Performanceverlust führen

3. Strukturierte numerische Composite Keys

Diese Form basiert ebenfalls auf der Kombination mehrerer fachlicher Felder, wird jedoch nicht als Text, sondern in ein strukturiertes numerisches Format überführt. Beispiel:

Company = 2000, Year = 2024, DocumentNo = 100000022, ItemNo = 000002 → wird zu: 2000202410000002200002

Diese ID kann als BIGINT oder DECIMAL(38,0) gespeichert werden.

Vorteile:

• Kompakt, eindeutig und sehr gut komprimierbar in VertiPaq
• Reversibel (bei festgelegter Struktur mit fixer Zeichenlänge)
• Bessere Performance als Text-IDs oder klassische Composite Keys
• Keine Kollisionen wie bei Hashing-Verfahren

Nachteile:

• Implementierung etwas aufwändiger (Padding, Formatierung)
• Disziplin erforderlich beim Aufbau und bei der Rückübersetzung
• Eingeschränkte Lesbarkeit

Einsatzempfehlung: Strukturierte numerische Composite Keys sind ideal, wenn ein hoher Wert auf Speicher- und Performanceoptimierung gelegt wird, die ursprüngliche Semantik aber teilweise erhalten bleiben soll. Sie lassen sich gut mit Lookup-Tabellen kombinieren, in denen die Originalbestandteile gespeichert sind (z. B. via DirectQuery abrufbar).

Hinweis: Strukturierte numerische IDs sind streng genommen eine Sonderform verketteter Composite Keys – sie basieren auf denselben Informationen, werden jedoch als komprimierter, interpretierbarer Zahlwert gespeichert.

Surrogate Keys (technische Schlüssel)

Surrogate Keys sind künstlich erzeugte, in der Regel numerische IDs, die als Ersatz für natürliche oder zusammengesetzte Schlüssel dienen.

Vorteile:

• Sehr performant (numerisch, konstant)
• Optimal komprimierbar
• Entkoppeln das Data Warehouse vom Quellsystem
• Unterstützung für Slowly Changing Dimensions (Typ 2)
• Einheitliche Joins zwischen Fakt- und Dimensionstabellen
• Schutz vor Duplikaten und Konflikten bei Quellensystem-Zusammenführungen

Nachteile:

• Keine fachliche Bedeutung mehr
• Zusätzliche Pflege notwendig (z. B. Lookup-Tabellen)
• Mapping-Fehler möglich, wenn nicht sauber implementiert

Auch sinnvoll bei bereits numerischen, natürlichen Keys

Selbst wenn ein natürlicher Schlüssel im Quellsystem bereits als INT vorliegt, kann ein Surrogate Key sinnvoll sein. Gründe dafür sind:

• Systemunabhängigkeit: Bei Migrationen oder Quellsystemwechseln bleibt der Surrogate Key stabil, auch wenn sich der natürliche Key ändert.
• Integration mehrerer Systeme: Zwei unterschiedliche Systeme könnten dieselbe ID verwenden – ein Surrogate Key verhindert Kollisionen.
• Historisierung: Auch bei konstanten numerischen Keys können sich Zustände (z. B. Name, Adresse) ändern, die über unterschiedliche Surrogate Keys erfasst werden.
• Zentrale Pflege: Einheitliches Format und zentrale Verwaltung erleichtern Datenmanagement und Datenqualitätssicherung.

Hashing von natürlichen Schlüsseln

Hashing ist eine Technik zur Generierung kompakter, technischer Schlüssel aus einem oder mehreren Attributen, die zusammen einen natürlichen oder zusammengesetzten Schlüssel bilden. Dabei wird eine Hashfunktion verwendet, um aus einem beliebigen Eingabewert (z. B. CustomerID, Company_Year_DocumentID_ItemNo) einen numerischen oder binären Hashwert zu erzeugen.

Diese Methode eignet sich besonders, wenn man keine Surrogate Keys verwenden möchte, aber dennoch mit einem effizient speicherbaren und performanten Schlüssel arbeiten will. Insbesondere dann, wenn natürliche Schlüssel nicht in strukturierte numerische Composite Keys überführt werden können – etwa weil sie alphanumerische oder freie Textbestandteile enthalten – kann Hashing eine effektive Lösung sein.

Ein großer Vorteil des Hashings liegt in seiner Deterministik: Aus demselben Eingabewert wird immer derselbe Hashwert erzeugt. Dadurch kann ein natürlicher Schlüssel konsistent in ein technisches Format überführt werden, das sich hervorragend zur Verwendung in Datenmodellen eignet.

Allerdings ist zu beachten, dass gehashte Werte in der Regel nicht reversibel sind. Das bedeutet: Aus dem Hash lässt sich der ursprüngliche Textwert nicht mehr zurückgewinnen. Hashing ist also keine Transformation, sondern eine Einweg-Funktion.

Typische Implementierungen:

• CHECKSUM() in SQL Server erzeugt einen INT, ist jedoch nicht kollisionssicher (mehrere verschiedene Eingaben können denselben Wert ergeben).
• HASHBYTES('SHA1', ...) erzeugt einen VARBINARY(20)-Wert mit extrem geringer Kollisionswahrscheinlichkeit und ist damit für produktive Umgebungen deutlich geeigneter.

Hashing ist besonders dann sinnvoll, wenn:

• mehrere Felder zu einem eindeutigen technischen Key kombiniert werden sollen,
• der natürliche Schlüssel sehr lang ist oder komplexe Zeichenketten enthält,
• man keinen expliziten Surrogate Key einführen möchte, aber dennoch von den Vorteilen kompakter numerischer IDs profitieren will.
• Ideal, wenn natürliche Keys zu groß für den Speicher sind, aber nicht geopfert werden sollen
• HASHBYTES für produktive Systeme, CHECKSUM nur für Tests/Temporäres

Vergleich der Methoden

Kriterium	Natürlicher Key	Composite Key	Surrogate Key	Hashing	Strukturierte ID
Speicherbedarf	Hoch	Sehr hoch	Niedrig	Mittel (hoch bei SHA)	Niedrig
Performance in BI-Modell	Niedrig	Niedrig	Hoch	Hoch	Hoch
Eindeutigkeit garantiert	Ja	Ja	Ja	Nur bei SHA	Ja
Reversibel	Ja	Ja	Nein	Nein	Ja
Lesbarkeit	Hoch	Hoch	Niedrig	Niedrig	Mittel

Fazit

Die Wahl der richtigen ID-Strategie ist ein zentrales Element jeder nachhaltigen Datenarchitektur. Sie beeinflusst nicht nur die Performance und Speicherökonomie eines Datenmodells, sondern auch dessen Wartbarkeit, Flexibilität und Zukunftsfähigkeit.

Natürliche Schlüssel bieten sich durch ihre fachliche Verständlichkeit und direkte Nutzbarkeit in vielen operativen Szenarien an. Für analytische Modelle wie Power BI sind sie jedoch oft ungeeignet, da sie entweder sehr lang sind, schlecht komprimierbar oder sich bei Systemwechseln ändern können. Auch zusammengesetzte Schlüssel, ob als separate Spalten oder als verketteter String, bringen in Power BI häufig Nachteile in Bezug auf Speicherbedarf und Join-Performance mit sich.

Surrogate Keys gelten als Best Practice in Data Warehouses. Sie bieten exzellente Performance, lassen sich ideal historisieren (SCD Typ 2) und machen das Modell unabhängig von Veränderungen in den Quellsystemen. Auch bei bereits numerischen, stabil wirkenden Business Keys bieten sie Vorteile, etwa wenn mehrere Systeme zusammengeführt werden oder sich die Semantik einzelner Datensätze im Zeitverlauf verändert.

Hashing wiederum bietet eine elegante Möglichkeit, aus natürlichen Schlüsseln kompakte, technische Schlüssel zu erzeugen – besonders wenn man bewusst auf Surrogate Keys verzichten möchte, der natürliche Schlüssel aber aus nicht-numerischen oder schwer speicherbaren Bestandteilen besteht. Es ermöglicht die konstante Erzeugung eines effizienten Schlüssels, der aber nicht reversibel ist und in bestimmten Fällen auf Kollisionsfreiheit überprüft werden muss.

Strukturierte numerische IDs bieten eine spannende Hybridlösung. Sie behalten die Struktur der Quellinformationen bei, sind aber als Zahl kodiert – ideal für Performance und Komprimierung. Sie sind reversibel, eindeutig und performant, verlangen aber disziplinierte Implementierung und Pflege.

Letztlich gilt: Die perfekte Lösung gibt es nicht. Die Entscheidung für eine ID-Strategie sollte sich immer an den konkreten Anforderungen orientieren:

• Wie viele Systeme sind beteiligt?
• Müssen historische Zustände erfasst werden?
• Welche Performance-Ziele hat das BI-System?
• Ist Speicherverbrauch ein kritischer Faktor?

Ein bewusstes, strategisch geplantes ID-Design trägt wesentlich zum Erfolg von Datenmodellen bei. Es erleichtert nicht nur die technische Umsetzung, sondern auch die Kommunikation mit Fachbereichen, die Weiterentwicklung von Modellen und die langfristige Wartung im Betrieb.

Ein kluger Umgang mit Schlüsselkonzepten ist daher keine technische Nebensache – sondern eine der wichtigsten Grundlagen für moderne, belastbare BI-Architekturen.

Performance Vergleiche (externe Ressourcen)

SQL-Datenbanken: INT vs. VARCHAR bei Joins

1. SQLServerCentral – „JOINS – int vs. varchar performance“
   Ein Nutzer führte einen Vergleich durch, bei dem zwei Tabellen mit jeweils 1 Million Datensätzen entweder über INT– oder VARCHAR-Spalten gejoint wurden. Das Ergebnis zeigte, dass Joins auf INT-Spalten etwa doppelt so schnell waren wie auf VARCHAR-Spalten. Dies wurde auf die kompaktere Speicherung und effizientere Verarbeitung von INT-Werten zurückgeführt. SQLServerCentral
2. Stack Overflow – „Performance of string comparison vs int join in SQL“
   In dieser Diskussion wird betont, dass Joins auf INT-Spalten in der Regel schneller sind als auf VARCHAR-Spalten, insbesondere bei großen Datenmengen. Die effizientere Verarbeitung von numerischen Werten und die bessere Indexnutzung werden als Hauptgründe genannt. Stack Overflow
3. Experts Exchange – „Join via int vs varchar(200)“
   Ein Experte erklärt, dass bei gleichen Indexbedingungen Joins auf INT-Spalten eine leicht bessere Performance bieten, da mehr Daten pro Indexseite gespeichert werden können, was zu weniger Seitenzugriffen führt. Experten Austausch

Power BI / Tabulare Modelle: Auswirkungen auf Performance und Speicher

1. Max Wikström – „Power BI data types in relationships – Does it matter?“
   Der Autor führte Benchmarks durch, bei denen er Modelle mit unterschiedlichen Datentypen in Beziehungsspalten verglich. Die Ergebnisse zeigten, dass Modelle mit INT-Schlüsseln eine bessere Performance und geringeren Speicherbedarf aufwiesen als solche mit VARCHAR– oder GUID-Schlüsseln. maxwikstrom.se
2. Power BI Community – „String vs Number Join Performance“
   In dieser Diskussion wird bestätigt, dass bei großen Datensätzen Joins auf numerischen Schlüsseln (INT) performanter sind als auf langen Zeichenketten (VARCHAR). Dies liegt an der effizienteren Verarbeitung und geringeren Speicherbelastung. Power BI forums
3. Microsoft Fabric Community – „Relationship Performance: Mapping based on String or Number?“
   Ein Nutzer berichtet, dass das Ersetzen langer Zeichenketten-Schlüssel durch numerische Schlüssel in einem 10-GB-Dataset zu einer verbesserten Modellgröße und Performance führte, insbesondere bei der Vermeidung von Speicherengpässen. Microsoft Fabric Community