터칭 데이터

DBT - Database Normalization 본문

Airflow 고급 기능, dbt, Data Catalog

DBT - Database Normalization

터칭 데이터 2024. 1. 4. 02:45

 

 

4. dbt (Data Build Tool)


떠오르는 ELT 툴!

 

 

 

 

 

 

 

 

 

Contents


1. ELT의 미래는?
2. Database Normalization
3. dbt 소개
4. dbt 사용 시나리오
5. dbt 설치와 환경 설정
6. dbt Models: Input
7. dbt Models: Output
8. dbt Seeds
9. dbt Sources
10. dbt Snapshots
11. dbt Tests
12. dbt Documentation
13. dbt Expectations
14. 마무리

 

 

 

 

 

 

 

 

 

 

 

ELT의 미래는?


ETL을 하는 이유는 결국 ELT를 하기 위함이며 이 때 데이터 품질 검증이 중요해짐

 

 

 

 

 

 

데이터 품질의 중요성 증대

 

입출력 체크

 

더 다양한 품질 검사

 

리니지 체크

 

데이터 히스토리 파악

 

데이터 품질 유지 -> 비용/노력 감소와 생산성 증대의 지름길

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Database Normalization


1NF, 2NF, 3NF 등의 Normalization과 SCD Type들에 대해 배워보자

 

 

 

 

 

 

Data Maturity Model and Reality

 

 

 

 

 

 

 

 

 

 

 

 

Database Normalization

 

데이터베이스를 좀더 조직적이고 일관된 방법으로 디자인하려는 방법

데이터베이스 정합성을 쉽게 유지하고 레코드들을 수정/적재/삭제를 용이하게 하는 것

 

Normalization에 사용되는 개념

Primary Key
Composite Key
Foreign Key (PK가 여러 컬럼)

 

 

 

 

 

 

 

 

 

 

 

 

 

 

1NF (First Normal Form)

 

한 셀에는 하나의 값만 있어야함 (atomicity)

 

Primary Key가 있어야함

 

중복된 키나 레코드들이 없어야함

 


목표는 중복을 제거하고 atomicity를 갖는 것

 

 

 

 

 

 

 

 

 

 

1NF (First Normal Form) 예제

 

Employee 테이블

 

 

 

 

 

 

 

 

 

 

 

2NF (Second Normal Form)

 

일단 1NF를 만족해야함

 

다음으로 Primary Key를 중심으로 의존결과를 알 수 있어야함

 

부분적인 의존도가 없어야함

즉 모든 부가 속성들은 Primary key를 가지고 찾을 수 있어야함
That is, all non-key attributes are fully dependent on a primary key

 


목표는 중복을 제거하고 atomicity를 갖는 것

 

 

 

 

 

 

 

 

 

2NF (Second Normal Form) - 예제

 

 

 

 

 

 

 

 

 

 

 

 

 

 

3NF (Third Normal Form)

 

일단 2NF를 만족해야함

 

전이적 부분 종속성을 없어야함

2NF의 예에서 state_code과 home_state가 같이 Employees 테이블에 존재

 

 

 

 

 

 

 

 

 

 

 

3NF (Third Normal Form) - 예제

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Slowly Changing Dimensions (1)

 

DW나 DL에서는 모든 테이블들의 히스토리를 유지하는 것이 중요함

보통 두 개의 timestamp 필드를 갖는 것이 좋음
    - created_at (생성시간으로 한번 만들어지면 고정됨)
    - updated_at (꼭 필요 마지막 수정 시간을 나타냄)

 

이 경우 컬럼의 성격에 따라 어떻게 유지할지 방법이 달라짐

SCD Type 0
SCD Type 1
SCD Type 2
SCD Type 3
SCD Type 4

 

 

 

 

 

 

 

 

 

Slowly Changing Dimensions (2)

 

 

일부 속성들은 시간을 두고 변하게 되는데 DW Table쪽에 어떻게 반영해야하나? 

 

 

 

현재 데이터만 유지

 

vs.

 

처음부터 지금까지 히스토리도 유지

 

 

 

 

 

 

 

 

 

 

SCD Type 0

 

한번 쓰고 나면 바꿀 이유가 없는 경우들

 

한번 정해지면 갱신되지 않고 고정되는 필드들

 

예) 고객 테이블이라면 회원 등록일, 제품 첫 구매일

 

 

 

 

 

 

 

 

 

 

 

SCD Type 1

 

데이터가 새로 생기면 덮어쓰면 되는 컬럼들

 

처음 레코드 생성시에는 존재하지 않았지만 나중에 생기면서 채우는 경우

 

예) 고객 테이블이라면 연간소득 필드

 

 

 

 

 

 

 

 

 

 

 

SCD Type 2

 

특정 entity에 대한 데이터가 새로운 레코드로 추가되어야 하는 경우

 

예) 고객 테이블에서 고객의 등급 변화

tier라는 컬럼의 값이 “regular”에서 “vip”로 변화하는 경우
변경시간도 같이 추가되어야함

 

 

 

 

 

 

 

 

 

 

 

 

 

SCD Type 3

 

SCD Type 2의 대안으로 특정 entity 데이터가 새로운 컬럼으로 추가되는 경우

 

예) 고객 테이블에서 tier라는 컬럼의 값이 “regular”에서 “vip”로 변화하는 경우

previous_tier라는 컬럼 생성
변경시간도 별도 컬럼으로 존재해야함

 

 

 

 

 

 

 

 

 

 

 

 

SCD Type 4

 

특정 entity에 대한 데이터를 새로운 Dimension 테이블에 저장하는 경우

 

SCD Type 2의 변종

 

예) 별도의 테이블로 저장하고 이 경우 아예 일반화할 수도 있음

 

 

 

 

 

 

'Airflow 고급 기능, dbt, Data Catalog' 카테고리의 다른 글

DBT - Input  (0) 2024.01.04
DBT - 사용 시나리오  (0) 2024.01.04
Airflow 운영과 대안  (0) 2024.01.04
Dynamic Dags  (0) 2024.01.03
Task Groups  (0) 2024.01.03