[DW&BI] 제 0장 : Data Warehouse(DW) & Business Intelligence(BI)

[DW&BI] 카테고리의 게시물을 시작하기에 앞서, 이 게시물은 참고 도서 (The Warehouse Toolkit - 3rd Edition) 을 읽으며 정리한 게시물임을 밝힌다. 또한, 모든 내용을 정리하는 것이 아닌 점을 참고 바란다.

---

제 0장 : Data Warehouse & Business Intelligence

 

현재, 나는 다수 기업의 현장개발에 참여하며 BI 개발에 힘쓰고 있다.

Power BI 툴을 이용해 Dashboard 개발 중이며, BI 를 하다보니 개발 앞단에서 필요한 DW 구축에 욕심이 생겨 공부를 시작하게 되었다.

 

 본 도서에서는 DW/BI 의 목표를 이렇게 말하고 있다.

비즈니스 사용자도 쉽게 데이터에 접근할 수 있어야 한다.
단지 나에게 중요한 것만 보여줘라.

 

이렇듯이, DW/BI 시스템은 쉽게 접근이 가능하도록 만들어져야 하며, 항상 변화에 유연해야 한다.

그래야만 향상된 의사결정을 위해 신뢰할 수 있는 토대가 될 수 있을 것이다.

---

# 다차원 모델링

DW/BI 의 목표를 알아보았다면, 이제 다차원 모델링에 대해 알아보자.

다차원 모델링이란 무엇일까.

 

단순하게 말하자면 "데이터베이스를 단순하게 만드는 오래된 기법" 이다.

단순하다는 것은 사용자들이 쉽게 데이터를 이해할 수 있을 뿐만 아니라, 효율적으로 결과를 받을 수 있다는 것을 의미한다.

 

앨버트 아인슈타인은 다음과 같이 말했다.

다차원 모델링은 기본 철학을 잘 설명해준다.
모든 것을 더 이상 간단해질 수 없을 만큼 가능한 간단하게 만들어라.
- Alvert Einstein

 

다차원 모델은 자주 관계형 DBMS 에서 구현되지만, 데이터 중복 제거를 추구하는 3차 정규화와는 확연히 다르다.

 

 여기서 잠깐. 정규화? 관련 공부를 한 사람들은 어느정도 들어보거나 공부해 본 경험이 있을 것이다.

 하지만 나는 주입식 교육, 외우기 등으로 공부했다 보니 한번 더 알고 들어가야겠다고 생각하여 3차 정규화까지 정리하며 복습을 진행했다.

[Database] 정규화(Normalization)란?

만약, 정규화가 헷갈린다면 다음 링크를 참고하자.

 

업계에서는 3차 정규화 모델은 ER 모델로 불리기도 한다. ERD는 테이블간의 관계를 표현하는 그림(다이어그램)이라고 보면 된다. ERD 로 표현한다면 한 눈에 쉽게 테이블간의 관계를 파악할 수 있다. 본 과정에서는 3차 정규화 모델을 ER 모델로 칭하는 것을 지양하고, 정규화 모델이라고 부를 것이다.

 

---

Star Schema

 

 관계형 DMBS에서 구현되는 다차원 모델은 구조가 별 모양을 닮아 Star Schema 라 불린다. 또한, 다차원 데이터베이스 환경에서 구현되는 다차원 모델은 OLAP 큐브라 불린다. 

---

# FACT TABLE (팩트 테이블)

아마 가장 많이 들어본, 앞으로도 많이 들어볼 용어이다.

팩트 테이블은 조직의 운영, 성과 등의 값을 저장하며, "팩트" 라는 용어는 비즈니스 측정값을 말한다.

 

어느 한 마트에서 제품이 판매되는 것을 지켜보고 있다고 상상해보자.

제품을 판매할 때마다 제품의 수량과 금액이 기록된다. 

팩트 테이블의 각 행은 하나의 측정 이벤트에 해당되며, 각 행에는 grain 이라 불리는 특정한 상세 수준으로 데이터가 저장된다. 다차원 모델링의 핵심 중 하나는 하나의 팩트 테이블 안에 있는 모든 측정값 행은 모두 같은 그레인(grain)이어야 한다는 것이다.

 

그레인(grain)
- Fact Table 의 한 row 가 나타내는 비즈니스적 의미
- Fact Table 은 동일 그레인 집합이며, 서로 다른 그레인이 존재해서는 안됨

 

Demension 과 Fact 를 구분하기 위해 Fact 는 연속적인 값으로 설명되기도 한다. 이론적으로 측정되는 Fact 가 텍스트 형태일 수도 있으나, 그런 경우는 별로 존재하지 않는다. 설계자는 Text Data 를 다른 디멘션 속성들과 보다 효과적으로 연관되고, 가능한 적은 공간을 차지하도록 하는 디멘션에 넣기 위해 노력해야 한다. Fact Table에 중복해서 텍스트 정보를 저장하면 안된다. 텍스트가 Fact Table의 모든 로우에 대해서 모두 다르지 않는 이상, 그 텍스트들은 디멘션 테이블에 속해야 한다. 

 

그리고, Fact Table 에서 아무 이벤트가 발생하지 않는다고 하여 없음을 나타내려고 0을 저장하지 않는 것 또한 중요하다. 실제 발생한 활동에 대해서만 채워넣는 것이 최소한으로 경량화할 수 있다. 

 

모든 Fact Table의 그레인은 크게 셋 중에 하나이다.

• 트랜잭션(Transaction)
• 주기적 스냅샷(Periodic snapshot)
• 점진적 스냅샷(Accumulating snapshot)

트랜잭션이 가장 일반적인 Fact Table 이다. 모든 팩트 테이블은 디멘션 테이블의 기본 키와 연결되는 외래 키를 두 개 이상 갖는다. 예를 들어, 팩트 테이블에 있는 제품 키는 제품 디멘션 테이블의 특정 제품 키와 일치한다. 만약, 팩트 테이블의 모든 키가 관련 디멘션 테이블의 기본 키와 모두 연결될 때 각 테이블들은 참조 무결성(Referention Integrity)을 충족한다고 말할 수 있다. 

 

# Dimension Table(디멘션 테이블)

디멘션 테이블은 이벤트와 관련된 "누가, 언제, 어디서, 무엇을, 왜" 를 설명해준다.종종 많은 컬럼과 속성들을 가지며 DW/BI 시스템에서 필수적인 역할을 수행한다. 디멘션 속성은 모든 필터조건과 리포트 레이블에서 사용되기 때문에 결정적이라고 볼 수 있다.

 

속성은 축약어 대신 이해하기 쉬운 단어로 사용되는 것이 좋고, 더불어 코드도 명시적인 디멘션 속성으로 포함시키는 것이 좋다. 여러 측면에서 데이터 웨어하우스의 가치는 디멘션 속성에 의해 좌우된다.

 

 

다음과 같은 그림은 디멘션 테이블이 자주 계층관계를 나타내는 것을 보여준다.

예를 들어, 제품은 브랜드로, 브랜드는 카테고리로 말아 올라간다.

계층관련 설명 정보는 사용 용이성과 빠른 쿼리 성능을 제공하고자 중복적으로 저장한다. 이 때 별도의 테이블에 설명을 저장해야 하는 정규화 충동이 들 수 있다. 하지만 이러한 경우는 우리는 이렇게 부른다.

스노우플레이킹(Snowflaking)

디멘션 테이블은 3차 정규화를 하지 않고, 한 테이블 안에 다대일 관계를 납작하게 펼치는 반정규화가 일반적이다.