데이터 정규화

1) 목적

정규화는 업데이트의 중복 및 이상을 제거하고 균일 한 디렉토리 및 키를 설정하며 데이터를 일관되고 저렴하게 유지 관리합니다. iGaming에서는 GGR/NGR, AML/RG 분석, 규제보고, 사기 방지 및 ML에 중요합니다.

2) 우리가 정규화하는 곳

청동 (원시): 정규화되지 않음-법의학 (추가 전용) 과 같은 저장.
은 (깨끗함/준수): 기본 정규화 (3NF/BCNF, 디렉토리, 키, SCD).
금 (서브): 목표 상점-읽기/BI에 대한 통제 된 비정규화가 가능합니다.

3) 기본 원칙

1. 스키마 우선 테이블에는 명시 적 스키마와 키가 있습니다.
2. 단일 식별자: 'user _ pseudo _ id', 'setion _ id', 'game _ id', 'provider _ id', 'tragement _ id'.
3. 일반적인 디렉토리: 통화, 시장/관할 구역, KYC/RG 상태, 게임 제공 업체, 트래픽 채널.
4. 시간 및 통화: '이벤트 _ time' (UTC) 을 저장하고 정규화 된 'amount _ base' + 'fx _ source'.
5. 진화: 시맨틱 버전, "자동" 중단없이 호환 가능한 변경 사항 만 있습니다.
6. PII 최소화: 사용자 - pseudo-ID를 통한; 매핑은 별도로 저장되며 액세스가 제한됩니다.

4) 정상적인 형태 빠르게

1NF: 원자 값, 열에 배열 없음 (배열 → 하위 테이블).
2NF 속성은 전체 화합물 키에 따라 다릅니다.
3NF: 전이 종속성이 없습니다 (속성은 키에만 따름).
BCNF: 각 결정 요인이 핵심입니다. "커널" (결제/게임 플레이) 에 사용하십시오.

실습: 실버 모델의 결제 및 게임 활동은 최소 3NF를 유지합니다. 참고 도서 및 참조 테이블에 대한보다 엄격한 BCNF.

5) 참조 도메인 모델 (실버)

5. 1 참고서

'어두운. 사용자 (의사 ID, 국가, 연령 범위, RG 상태).
'어두운. 게임 '(게임 _ id, 제공자 _ id, 장르, RTP, 변동성).
'어두운. 공급자 (provesser _ id, 유형, 라이센스).
'어두운. 시장 (관할권 코드, 규제 기관).
'어두운. fx _ rates '(날짜, ccy _ from, ccy _ to, rate, fx _ source).

5. 2 사실 (좁은 이벤트/트랜잭션 테이블)

'사실. 결제 '(trange _ id, user _ pseudo _ id, m액 _ orig, 통화, m액 _ base, 시장, 이벤트 _ time, psp _ ref, 메소드).
'사실. 베팅 '(bet _ id, user _ pseudo _ id, game _ id, stake _ base, stake _ ccy, 결과, 이벤트 _ time).
'사실. 지불금 '(payout _ id, user _ pseudo _ id, game _ id, amount _ base, 이벤트 _ time).

링크: 안정적인 키 가이드. 'fx _ source' 를 수정하여 "소스 통화" 와 "베이스" (amount _ base) 에 모든 금액을 복제합니다.

6) 천천히 변화하는 측정 (SCD)

타입 I (덮어쓰기): 철자/비 임계 수정.
유형 II (기록): '유효한 _ from/유효한 _ to/is _ current', 감사 변경 (예: RG 상태 변경).
III 형 (대체 열): 짧은 비교를 위해 "전/후".

추천: RG/KYC/마케팅 채널 - SCD II; 영향 검증을받은 게임 참조 도서 (RTP) -SCD II.

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) 중복 제거 및 키

내부 링크에 대한 대리 키 (BIGINT/UUI).
자연 키 (예: PSP의 'trange _ id') -별도로 검증 및 저장됩니다.
'(이벤트 _ id, 소스)' 에 의해 실버의 비즈니스 키에 의해 + 섭취되도록 결정됩니다.

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) 통화 표준화 및 에스코트

'이벤트 _ time' - 항상 UTC; 상점 창의 경우 시장의 로케일/시간대를 추가하십시오.
통화: 'amount _ orig' 및 'mount _ base' (예: EUR) + 'fx _ source', 'fx _ rate _ used'.
코스의 일일 수정: 소스 및 해시 서명이있는 'dim. fx _ rates'.

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) 참고 도서의 일관성

통합 디렉토리 등록 (게임, 공급자, 시장, 통화).
DQ 유효성 검사기: 'in _ set', FK 참조, 독창성, SCD의 일관성.
외부 소스 (게임 제공 업체, 국가, PSP) 에서 "얇은" 차원의 자동 생성.

10) 비정규화 시점

비정규화는 다음을 위해 금으로 허용됩니다

안정적인 "와이드" 보고서 (GGR, 위험 쇼케이스);

BI 쿼리/대시 보드의 가속

SLA 판독 값에 따라 실시간 상점 (ClickHouse/Pinot).

• 은은 진실의 근원으로 남아 있습니다.
• 비정규화 된 필드-은에서 계산/복사; 버전 논리.
• 모든 비정규화는 문서화되고 정확성을 테스트합니다.

11) 별과 눈송이 모델

별: 하나의 사실 + 평평한 측정-더 쉽고 빠른 읽기, 더 비싼 쓰기/일치.
눈송이: 측정이 정규화 (연결된 하위 디렉토리) -더 적은 중복, 더 복잡한 쿼리.

추천: 금에서 더 자주 "별", 은에서 - 정규화 된 "눈송이".

12) 계획의 진화 (안전한 변화)

역 호환: 널링 가능한 열 추가; 플래그가있는 새로운 참조 값.
속보: 마이그레이션 기간 동안 '/v2 '및 이중 항목을 통해서만 이름 변경/타이핑/의미 변경.
계약: 레지스트리의 JSON/Avro 체계, 호환성에 대한 소비자 테스트.

13) 정규화를위한 DQ 컨트롤

• 키는 고유합니다: 'trange _ id', 'bet _ id'.
• 참조 무결성: '희미한' FK..
• 통화: 화이트리스트의 '통화', 'fx _ rate _ 는' not not ', amount _ base> = 0' 을 사용했습니다.
• 시간: 합리적인 창에서 '이벤트 _ time'; "미래" 이벤트가 없습니다.
• SCD- 올바른: 겹치지 않는 범위는 '유효한 _ from/유효한 _ to' 입니다.

14) 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) 개인 정보 보호 및 준수

실버에서 사용자 할당; 별도의 보호 회로에서 실제 ID와의 연결.
RLS/CLS 및 현장 마스킹 (분석에서는 이메일/PAN을 사용할 수 없음).
디렉토리/키의 지역화, 스키마 확장을위한 DPO 제어.

16) 관찰 및 계보

Bronze → Silver → Gold의 데이터 계보, 변환 및 계약 버전.
지표: 완전성, 유효성, FK 오류, 중복, 시간의 "구멍", 요청 비용.
디렉토리 및 FX 소스에서 중단 될 때 경고합니다.

17) RACI

R: 데이터 엔지니어링 (실버/골드 모델), 데이터 플랫폼 (회로 레지스터, DQ).
A: 데이터/아키텍처 책임자.
C: 준수/DPO (PII/보존), 금융 (FX/GGR), 위험 (RG/AML).
I: BI/제품/마케팅/운영.

18) 구현 로드맵

1. 디렉토리 등록 (시장, 통화, 공급자, 게임).

2. 실버 모델의 사실. 지불 ',' 사실. 베팅 ',' 희미합니다. '(3HF), SCD II for' dim. 사용자.

3. 통화 정규화/시간대, 기본 DQ 규칙 (FK/고유성/in _ set).

4. 최초의 골드 쇼케이스 (GGR Daily) 및 조정 테스트.

• SCD 확장, 게임 이벤트 범위, 공급자 컨 포멀 모델.
• 스키마 호환성 오토 테스트, 마이그레이션 시뮬레이터, 메타 데이
• 키/파티 최적화, 클러스터링/Z- 순서.

• 금, SLA/가치에 대한 비정규화 정책; 별/눈송이 템플릿.
• 문서의 자동 생성, 대시 보드의 계보 그래프.
• 지역 디렉토리 및 암호화 키, DR 연습.

19) 품질 점검표

• 단일 키 및 디렉토리가 승인되었습니다.
• 3NF의은, SCD는 "느린" 측정에 적용되었습니다.
• 통화/우주선이 정규화되었습니다. 'fx _ source' 가 수정되었습니다.
• DQ 규칙 (FK/고유성/범위/in _ set) 이 활성화되어 있습니다.
• 비정규화 문서화, 정확성 테스트가 통과되었습니다.
• 대시 보드에는 선형 및 신선도/충만 지표가 표시됩니다.

20) 빈번한 실수와 피하는 방법

분석의 PII 혼합: 별도의 매핑, CLS/RLS 사용.
실버의 정규화 불충분: 3NF, 그렇지 않으면 값 비싼 지원 및 조정 오류가 발생합니다.
FX "보고서 당": "후진" 이 아닌 이벤트에서 요금을 캡처해야합니다.
핵심 치수에 대한 SCD 없음: RG/KYC/채널 기록 손실.
금 재 정규화: 중복 결합 → 관리 된 비정규화.
체계의 불투명 한 진화: 레지스트리 및 소비자 테스트 사용.

21) 결론

정규화는 균일 한 키 및 참고 서적, 사실 및 측정을위한 3NF/BCNF, 올바른 기록 (SCD) 및 시간/통화의 표준화와 같은은 수준의 분야입니다. 이러한 "골격" 으로 골드 케이스가 예측 가능 해지고 보고서가 비슷하며 소유 비용이 통제됩니다.