Normalizzazione dei dati

1) Destinazione

La normalizzazione elimina duplicati e anomalie degli aggiornamenti, definisce guide e chiavi comuni e rende i dati coerenti e economici accompagnati. Nel iGaming, questo è critico per GGR/NGR, AML/RG, rapporti regolatori, antifrode e ML.

2) Dove normalizzabile

Bronze (raw) - Non normalizzabile - Memorizzazione com'è (append-only) per forenziare.
Silver (clean/conform) - Normalizzazione di base (3NF/BCNF, guide, chiavi, SCD).
Gold (serve) - Vetrine di destinazione - È possibile denormalizzare controllata per lettura/BI.

3) Principi di base

1. Schema-first: tutte le tabelle hanno schemi e chiavi esplicite.
2. Identificatori unici: 'user _ pseudo _ id', 'sessions _ id', 'game _ id', 'provider _ id', 'communication _ id'.
3. Le linee guida sono valute, mercati/giurisdizioni, states KYC/RG, provider di giochi, canali di traffico.
4. Ora e valuta: memorizza «event _ time» (UTC) e normalizzato «amount _ base» + «fx _ source».
5. Evoluzione: versioni semantiche, solo modifiche compatibili senza interruzioni «silenziose».
6. Riduzioni PII: utente tramite pseudo-ID; Il mapping è conservato separatamente, l'accesso è limitato.

4) Forme normali rapidamente

1NF: valori atomici, senza array nelle colonne (array → child-table).
2NF: gli attributi dipendono dall'intera chiave composita.
3NF - Nessuna dipendenza transitiva (l'attributo dipende solo dalla chiave).
BCNF: ogni determinante è la chiave. Usa per «kernel» (payments/gameplay).

Prassi: Modelli silver di pagamento e attività di gioco manteniamo un minimo di 3NF; BCNF più rigoroso - per riferimenti e tabelle di riferimento.

5) Modello di dominio di riferimento (Silver)

5. 1 Guide

`dim. users '(pseudo-ID, paese, fascia di età, stato RG).
`dim. games '(game _ id, provider _ id, genere, RTP, volatilità).
`dim. provider '(provider _ id, tipo, licenza).
`dim. markets '(codice giurisdizione, regolatore).
`dim. fx_rates` (date, ccy_from, ccy_to, rate, fx_source).

5. 2 Fatti (tabelle di eventi/transazioni ristrette)

`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).

I fatti ↔ i manuali delle chiavi stabili. Tutti gli importi vengono duplicati nella «valuta di origine» e in «base di base», fissando «fx _ source».

6) Dimensioni che cambiano lentamente (SCD)

Tipo I - Correzioni ortografiche/non.
Type II (cronologia): 'valid _ from/valid _ to/is _ current', controllo delle modifiche (ad esempio, cambio di stato RG).
Type III (colonna alternativa): «prima/dopo» per brevi confronti.

Raccomandazione per RG/KYC/canale di marketing - SCD II; per le guide dei giochi (RTP) - SCD II con validazione dell'influenza.

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) Deduplicazione e chiavi

Chiavi surrogate (BIGINT/UUID) per le relazioni interne.
Chiavi naturali (ad esempio, «communication _ id» di PSP) - convalida e memorizza separatamente.
Deadup per '(event _ id, source)' su ingest + in chiave aziendale in Silver.

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) Standardizzazione delle valute e timesone

«event _ time» è sempre UTC; per le vetrine aggiungiamo locale/timesone del mercato.
Valute: 'amount _ orig'e'amount _ basé (ad esempio, EUR) +' fx _ source ',' fx _ rate _ used '.
Fissazione quotidiana dei corsi: 'dim. fx _ rat'con sorgente e firma hash.

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) Consistenza delle guide

Un unico registro di riferimento (games, provider, markets, currencies).
Validi DQ: 'in _ set', riferimenti FK, unicità, coerenza SCD.
Generazione automatica di dimensi «sottili» da fonti esterne (provider di giochi, paesi, PSP).

10) Quando Denormalizzare

• ripetizioni «ampie» stabili (GGR, vetrine a rischio);
• Accelerazione delle richieste BI/dashboard
• realtime-vetrine (ClickHouse/Pinot) sotto la lettura SLA.

• La fonte della verità rimane Silver.
• Campi denormalizzati - calcolati/copiati da Silver; versioning logica.
• Ogni denormalizzazione viene documentata e testata correttamente.

11) Modello stella e fiocco di neve

Stella: un dato + misure piatte - più facile e veloce di lettura, più costoso di scrittura/negoziazione.
Fiocco di neve: le misure sono normalizzate (elenchi di riferimento collegati) - Meno duplicati, più complesse le richieste.

La raccomandazione è che la Gold è più una stella, la Silver è un fiocco di neve normalizzato.

12) Evoluzione dei circuiti (safe changes)

Back-compatibile - Aggiunge colonne nullabili; nuovi valori di riferimento con i flag.
Breaking: rinominazione/tipo/spostamento semantico - solo attraverso «/v2 »e doppio record per il periodo di migrazione.
Contratti: schemi JSON/Avro in registry, consumer-test di compatibilità.

13) Controlli DQ per la normalizzazione

• Le chiavi sono uniche: 'communication _ id', 'bet _ id'.
• Integrità dell'arbitro: FK à dim ".
• Valute: 'currency'da whitelist,' fx _ rate _ used'non NULL, 'amount _ base> = 0'.
• Ora: 'event _ time'in una finestra ragionevole; l'assenza di eventi futuri.
• SCD corretto: intervalli non intersecati 'valid _ from/valid _ to'.

14) Esempi di modelli SQL

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) Privacy e compliance

Alias utente in Silver; i collegamenti con l'ID reale sono in un tracciato protetto separato.
RLS/CLS e masking dei campi (e-mail/PAN non disponibili nell'analisi).
Regionalizzazione di directory/chiavi, controllo DPO per l'estensione dei circuiti.

16) Osservabilità e lineage

Data lineage di Bronze → Silver → Gold, trasformazioni e contratti.
Metriche: completeness, validity, errori FK, duplicati, buchi nel tempo, costo della query.
Alert per interruzioni di guide e fonti FX.

17) RACI

R: Data Engineering (modelli Silver/Gold), Data Platform (minuscolo diagramma, DQ).
A: Head of Data/Architecture.
C: Compliance/DPO (PII/retention), Finance (FX/GGR), Risk (RG/AML).
I: BI/Prodotto/Marketing/Operazioni.

18) Road map di implementazione

1. Registro delle guide (markets, currencies, provider, games).

2. Modelli silver fact. payments`, `fact. bets ',' dim '(3NF), SCD II per'dim. users`.

3. Regolazione valuta/timesone, regole DQ di base (FK/uniqueness/in _ set).

4. Prima vetrina Gold (GGR Daily) e test di saldatura.

• Estensione SCD, copertura eventi di gioco, modelli di connettività di provider.
• Modelli di compatibilità automatica, simulatore di migrazione, catalogo di metadati.
• Ottimizzazione delle chiavi/partiture, clustering/Z-order.

• Politiche di denormalizzazione per Gold, SLA/costo; templati stella/fiocco di neve.
• Generazione automatica della documentazione, grafico lineage in dashboard.
• Cartelle regionali e chiavi di crittografia, esercitazioni DR.

19) Assegno-foglio di qualità

• Chiavi e guide unificate approvate.
• Silver in 3NF, SCD applicato a misure «lente».
• Le valute/timeson sono normalizzate; 'fx _ source' viene rilevato.
• Le regole DQ (FK/uniqueness/range/in _ set) sono attive.
• Denormalizzazioni documentate, test di correttezza superati.
• La linea e le metriche di freschezza/completezza sono visibili sui dashboard.

20) Errori frequenti e come evitarli

Miscelazione PII nell'analisi: separa i mapping, applica CLS/RLS.
Scarsa normalizzazione Silver: porta a 3NF, altrimenti supporto costoso e errori di fusione.
FX in base al report: i corsi devono essere registrati su un evento e non in modo retroattivo.
Nessuna SCD per le misure chiave: si perde la cronologia RG/KYC/canali.
Sovralimentazione Gold, eccesso di join's, denormalizzazione controllata.
Evoluzione opaca degli schemi: utilizzare registry e consumer-test.

21) Totale

La normalizzazione è una disciplina del livello Silver: chiavi e guide unificate, 3NF/BCNF per i fatti e le misurazioni, storia corretta (SCD) e standardizzazione del tempo/valuta. Con questo scheletro, le vetrine Gold diventano prevedibili, i rapporti sono comparabili e il costo di proprietà è controllato.