Normalisierung der Daten

1) Ernennung

Die Normalisierung beseitigt Duplikate und Anomalien von Updates, legt einheitliche Verzeichnisse und Schlüssel fest und macht die Daten konsistent und kostengünstig. In iGaming ist dies kritisch für GGR/NGR, AML/RG-Analysen, regulatorische Berichterstattung, Betrugsbekämpfung und ML.

2) Wo wir normalisieren

Bronze (raw): nicht normalisierbar - Speicherung wie es ist (append-only) für forensics.
Silber (clean/conform): grundlegende Normalisierung (3NF/BCNF, Verzeichnisse, Schlüssel, SCD).
Gold (serve): Zielvitrinen - geführte Denormalisierung unter Lesen/BI möglich.

3) Grundprinzipien

1. Schema-first: Alle Tabellen haben explizite Schemas und Schlüssel.
2. Einheitliche Kennungen: 'user _ pseudo _ id', 'session _ id', 'game _ id', 'provider _ id', 'transaction _ id'.
3. Einheitliche Verzeichnisse: Währungen, Märkte/Gerichtsbarkeiten, KYC/RG-Status, Spieleanbieter, Verkehrskanäle.
4. Zeit und Währung: Speichern Sie' event _ time'(UTC) und normalisiert 'amount _ base' + 'fx _ source'.
5. Evolution: semantische Versionen, nur kompatible Änderungen ohne „stille“ Brüche.
6. PII-Minimierung: Benutzer - über Pseudo-ID; Das Mapping wird separat gespeichert, der Zugriff ist eingeschränkt.

4) Normale Formen schnell

1NF: Atomwerte ohne Arrays in Spalten (Arrays → Child-Tabellen).
2NF: Attribute hängen vom gesamten zusammengesetzten Schlüssel ab.
3NF: Es gibt keine transitiven Abhängigkeiten (das Attribut hängt nur vom Schlüssel ab).
BCNF: Jede Determinante ist der Schlüssel. Für den „Kern“ (Zahlungen/Gameplay) anwenden.

Praxis: Silbermodelle von Zahlungen und Spielaktivitäten halten ein Minimum an 3NF; strengere BCNF - für Nachschlagewerke und Referenztabellen.

5) Referenzdomänenmodell (Silber)

5. 1 Verzeichnisse

`dim. Benutzer'(Pseudo-ID, Land, Altersspanne, RG-Status).
`dim. games'(game_id, provider_id, Genre, RTP, Volatilität).
`dim. providers'(provider_id, Typ, Lizenz).
`dim. markets'(Zuständigkeitscode, Regulierungsbehörde).
`dim. fx_rates` (date, ccy_from, ccy_to, rate, fx_source).

5. 2 Fakten (enge Ereignis-/Transaktionstabellen)

`fact. payments` (transaction_id, user_pseudo_id, amount_orig, currency, amount_base, market, event_time, psp_ref, method).
`fact. bets` (bet_id, user_pseudo_id, game_id, stake_base, stake_ccy, outcome, event_time).
`fact. payouts` (payout_id, user_pseudo_id, game_id, amount_base, event_time).

Links: Fakten ↔ Handbücher zu stabilen Schlüsseln. Alle Beträge werden in der „Quellwährung“ und in der „Basiswährung“ (amount_base) durch Fixierung von „fx _ source“ dupliziert.

6) Langsam wechselnde Messungen (SCD)

Typ I (Überschreiben): Rechtschreib-/unkritische Korrekturen.
Typ II (Historie): 'valid _ from/valid _ to/is _ current', Prüfung von Änderungen (z.B. RG-Statusänderungen).
Typ III (alternative Spalte): „vorher/nachher“ für kurze Vergleiche.

Empfehlung: für RG/KYC/Marketingkanal - SCD II; für Spielführer (RTP) - SCD II mit Influencer-Validierung.

sql
CREATE TABLE dim. users_scd (
user_pseudo_id STRING,
country STRING,
rg_status STRING,
valid_from TIMESTAMP,
valid_to  TIMESTAMP,
is_current BOOLEAN
);

7) Deduplizierung und Schlüssel

Ersatzschlüssel (BIGINT/UUID) für interne Verbindungen.
Natürliche Schlüssel (z.B. 'transaction _ id' von PSP) - separat validieren und speichern.
Dedup durch'(event_id, Quelle) 'auf ingest + durch Geschäftsschlüssel in Silber.

sql
CREATE TABLE silver. payments AS
SELECT EXCEPT(rn) FROM (
SELECT p., ROW_NUMBER() OVER (PARTITION BY transaction_id ORDER BY event_time) rn
FROM bronze. payment_events p
)
WHERE rn = 1;

8) Währungsstandardisierung und Zeitzone

'event _ time' - immer UTC; Für die Schaufenster fügen wir die lokale/Zeitzone des Marktes hinzu.
Währungen: 'amount _ orig' und 'amount _ base' (z.B. EUR) + 'fx _ source', 'fx _ rate _ used'.
Tägliche Kursbefestigung: 'dim. fx_rates' mit Quelle und Hash-Signatur.

sql
SELECT t. transaction_id,
t. amount_orig,
t. currency,
r. rate AS fx_rate_used,
t. amount_orig r. rate AS amount_base
FROM bronze. payment_events t
JOIN dim. fx_rates r
ON r. date = DATE(t. event_time) AND r. ccy_from = t. currency AND r. ccy_to = 'EUR';

9) Konsistenz der Verzeichnisse

Ein einziges Verzeichnis von Verzeichnissen (Spiele, Anbieter, Märkte, Währungen).
DQ-Validatoren: 'in _ set', FK-Referenzen, Eindeutigkeit, SCD-Konsistenz.
Autogenerierung von „dünnen“ Dimensien aus externen Quellen (Spieleanbieter, Länder, PSPs).

10) Wann denormalisieren

• stabile „breite“ Berichterstattung (GGR, Risikovitrinen);
• Beschleunigung von BI-Abfragen/Dashboards;
• realtime-Schaufenster (ClickHouse/Pinot) unter SLA lesen.

• Die Quelle der Wahrheit bleibt Silber.
• Denormalisierte Felder - berechnet/kopiert aus Silver; Versionierung der Logik.
• Jede Denormalisierung wird dokumentiert und auf Korrektheit geprüft.

11) Modell „Stern“ und „Schneeflocke“

Stern: eine Tatsache + flache Messungen - einfacheres und schnelleres Lesen, teureres Schreiben/Verhandeln.
Schneeflocke: Messungen sind normalisiert (angeschlossene Unterverzeichnisse) - weniger Duplikate, komplexere Abfragen.

Empfehlung: in Gold häufiger „Stern“, in Silber normalisierte „Schneeflocken“.

12) Entwicklung von Schaltungen (sichere Änderungen)

Back-compatible: nullable Spalten hinzufügen; neue Referenzwerte mit Flags.
Breaking: Umbenennung/Typisierung/semantische Verschiebungen - nur über '/v2 'und Double Write für den Zeitraum der Migration.
Verträge: JSON/Avro-Systeme in der Registry, Consumer-Tests auf Kompatibilität.

13) DQ-Kontrollen zur Normalisierung

• Die Einzigartigkeit der Schlüssel: 'transaction _ id', 'bet _ id'.
• Referenzielle Integrität: FK auf 'dim.'.
• Währungen: 'currency' aus Whitelist, 'fx _ rate _ used' nicht NULL, 'amount _ base> = 0'.
• Zeit: 'event _ time' in einem vernünftigen Fenster; Fehlen von „zukünftigen“ Ereignissen.
• SCD-Korrektheit: Nicht überlappende Bereiche' valid _ from/valid _ to'.

14) Beispiele für SQL-Modelle

sql
CREATE TABLE silver. fact_bets (
bet_id STRING PRIMARY KEY,
user_pseudo_id STRING NOT NULL,
game_id STRING NOT NULL,
stake_ccy DECIMAL(18,2) NOT NULL,
currency CHAR(3) NOT NULL,
stake_base DECIMAL(18,2) NOT NULL,
market CHAR(2) NOT NULL,
event_time TIMESTAMP NOT NULL
);

sql
CREATE VIEW gold. ggr_daily AS
SELECT
DATE(b. event_time) AS event_date,
m. market,
g. provider_id,
SUM(b. stake_base) AS stakes_eur,
SUM(p. amount_base) AS payouts_eur,
SUM(b. stake_base) - SUM(p. amount_base) AS ggr_eur
FROM silver. fact_bets b
LEFT JOIN silver. fact_payouts p
ON p. user_pseudo_id = b. user_pseudo_id
AND p. game_id = b. game_id
AND DATE(p. event_time) = DATE(b. event_time)
JOIN dim. markets m ON m. code = b. market
JOIN dim. games g  ON g. game_id = b. game_id
GROUP BY 1,2,3;

15) Datenschutz und Compliance

Pseudonymisierung des Benutzers in Silver; Kommunikation mit der realen ID - in einer separaten sicheren Schleife.
RLS/CLS und Feldmaskierung (E-Mail/PAN nicht in der Analytik verfügbar).
Regionalisierung von Verzeichnissen/Schlüsseln, DPO-Kontrolle zur Erweiterung von Schaltungen.

16) Beobachtbarkeit und Lineage

Data Lineage von Bronze → Silver → Gold, Versionen von Transformationen und Verträgen.
Metriken: Vollständigkeit, Gültigkeit, FK-Fehler, Duplikate, „Löcher“ in der Zeit, Kosten der Anfrage.
Alerts bei Lücken in Verzeichnissen und FX-Quellen.

17) RACI

R: Data Engineering (Silber-/Goldmodelle), Data Platform (Schaltungsregister, DQ).
A: Head of Data/Architecture.
C: Compliance/DPO (PII/retention), Finance (FX/GGR), Risk (RG/AML).
I: BI/Produkt/Marketing/Betrieb.

18) Fahrplan für die Umsetzung

1. Verzeichnis der Verzeichnisse (Märkte, Währungen, Anbieter, Spiele).

2. Silver-Modelle' fact. payments`, `fact. bets', 'dim.' (3NF), SCD II für 'dim. users`.

3. Währungsnormalisierung/Zeitzone, grundlegende DQ-Regeln (FK/uniqueness/in_set).

4. Erste Gold-Vitrine (GGR Daily) und Sweep-Tests.

• SCD-Erweiterung, Abdeckung von Spielevents, Anbieter-konforme Modelle.
• Schema-Kompatibilitäts-Autotests, Migrationssimulator, Metadatenkatalog.
• Schlüssel-/Partitionsoptimierung, Clustering/Z-Order.

• Denormalisierungsrichtlinien für Gold, SLA/Kosten; Stern/Schneeflocke-Templates.
• Auto-Generierung der Dokumentation, Zeilengraph in Dashboards.
• Regionale Verzeichnisse und Verschlüsselungsschlüssel, DR-Übungen.

19) Qualitätscheckliste

• Einheitliche Schlüssel und Verzeichnisse genehmigt.
• Silber in 3NF, SCD auf „langsame“ Messungen angewendet.
• Währungen/Zeitzonen sind normalisiert; 'fx _ source' ist festgelegt.
• DQ-Regeln (FK/uniqueness/range/in_set) sind aktiv.
• Denormalisierungen werden dokumentiert, Korrektheitstests bestanden.
• Die Linearität und die Frische/Vollständigkeit Metriken sind auf Dashboards sichtbar.

20) Häufige Fehler und wie man sie vermeidet

PII-Mix in der Analytik: Muppings trennen, CLS/RLS anwenden.
Unzureichende Normalisierung Silber: Führen Sie zu 3NF, sonst teure Unterstützung und Fehler von Pfeifen.
FX „on the fact of the report“: Die Kurse sollten auf die Veranstaltung und nicht „rückwirkend“ festgelegt werden.
Kein SCD für Schlüsselmessungen: RG/KYC/Channel History geht verloren.
Gold-Renormalisierung: Übermäßige Join's → kontrollierte Denormalisierung.
Undurchsichtige Entwicklung von Schemata: Verwenden Sie Registry und Consumer-Tests.

21) Das Ergebnis

Normalisierung ist eine Silver-Level-Disziplin: einheitliche Schlüssel und Handbücher, 3NF/BCNF für Fakten und Messungen, korrekte Historie (SCD) und Standardisierung von Zeit/Währungen. Mit einem solchen „Skelett“ werden Gold-Vitrinen vorhersehbar, Berichte vergleichbar und die Betriebskosten kontrollierbar.