DW 용어 및 설명
DB CAFE
thumb_up 추천메뉴 바로가기
- DBA { Oracle DBA 명령어 > DBA 초급 과정 > DBA 고급 과정 }
- 튜닝 { 오라클 튜닝 목록 }
- 모델링 { 데이터 모델링 가이드 }
Data Modeling
목차
1 ER 데이터 모델링[편집]
- 데이터 모델링은 현실세계에 불규칙하게 흩어져 있는 데이터들을 정리하여 컴퓨터 세계에 표현하기 위한 중간 과정이다.
- 데이터 모델링은 개념적 모델, 논리적 모델, 물리적 모델의 순서로 진행된다.
- OLTP 시스템에서의 데이터 모델링의 주된 관점은 데이터의 중복성 배제와 데이터의 일치성을 보장하는 것이다.
2 DW 데이터 모델링[편집]
- 데이터웨어하우스 시스템에서의 데이터 모델링은 특정 업무 또는 목적으로 축적된 데이터를 사용자가 사용하기 편리한 데이터 활용에 초점을 두고 있다.
- Fact와 Dimension으로 구성
- 데이터 중복을 허용
- MDB는 Cube Model이라는 형식의 다차원 모델을 생성함
- RDB는 Star Schema 혹은 Snowflake Schema와 같은 모델링을 생성함
- RDB인 경우에는 ER모델을 그림
- Start Schema 혹은 Snowflake Schema는 ER 모델의 특정한 형태임
3 기존 시스템[편집]
- 각 업무 기능별로 데이터를 구성하며 업무를 지원하기 위한 여러 플래그 정보가 많이 포함되어 있다.
- 수치정보도 업무 지원에 맞추어 업무별로 분산되어 있는 경우가 많다.
4 데이터 웨어하우스[편집]
- 주로 실적 정보나 각 업무 주제별로 데이터가 통합되는 경우가 대부분이다.
- 통합과정에서 데이터웨어하우스에 필요 없는 데이터는 제거되고 또한 수치 데이터는 적절하게 요약되고 계산되는 과정을 DW 데이터 모델링이라고 할 수 있다.
5 다차원 정보와 다차원 모델링[편집]
- 기본적으로 기업의 업무구조는 다차원적이며, 비즈니스 사용자가 필요로 하고 활용하는 대부분의 정보는 다차원 정보이다.
- 다차원 정보는 사용자들에 의해 이해되는 기업의 실제 차원을 반영하는 정보이다.
- 데이터는 목적을 가질 때 비로소 정보로서 가치를 가지게 된다.
- 정보란 본질적으로 비교를 나타내는데, 다차원 정보는 다양한 각도 즉 차원의 관점에서 이러한 비교를 가능하게 한다.
6 Dimension[편집]
- 데이터를 분석하는 기준이 되는 측면으로 보통 기간별, 제품별과 같이 “~별”이라는 말로 표현이 된다.
7 Fact[편집]
- 숫자적으로 표현되는 값 즉 측정 대상이 되는 데이터로 데이터베이스에 저장이 되는 항목을 의미한다.
8 Cube[편집]
- 차원은 사용자가 정보를 분석하고자 하는 하나의 관점을 나타내는 것인데 이것은 사용자의 분석 목적에 적합하게 생성되어야 한다.
- 다차원 모델은 흔히 Cube로 표현되며 이것은 축과 좌표로 구성된다.
백화점의 매출금액을 분석하는 예를 들어 Cube를 표현 한 것이다.
9 Hypercube 방식[편집]
- 하나의 모델을 하나의 큐브로 표현한다.
- 각각의 차원들을 구성하는 모든 항목들의 조합 수 만큼 셀이 존재하게 된다.
- 즉 Cube를 구성하는 모든 Fact들은 동일한 차원을 공유하며, Cube를 구성하는 모든 셀 역시 동일한 차원을 가진다.
- 모델 구축이 용이
- Cube 내에 의미 없는 셀이 존재할 수 있음
10 Multicube 방식[편집]
- 하나의 모델을 여러 개의 Cube로 표현하는 방식
- 멀티큐브 방식은 다시 Block멀티큐브 방식과 시리즈멀티큐브 방식으로 구분해 볼 수 있다.
11 일반적인 다차원 모델[편집]
11.1 변수 차원[편집]
- 대부분의 다차원 모델에 존재.
- 변수 차원은 비용, 수익, 판매량, 자산, 부채, 재고량 등과 같은 다양한 측정치와 관련된 정보를 가지며, 이러한 항목들은 기업의 주요 성공 요소들이 많이 포함된다.
- 변수 차원은 다른 차원들의 존재기반이 된다.
- 대부분 차원들은 계층적인 구조만으로 항목들 사이의 관계가 충분히 표현되는 반면, 변수 차원은 많은 비즈니스적인 관계가 반영이 되어 매우 복잡한 관계식도 가지게 된다.
11.2 기간 차원[편집]
- 다차원 모델에서 기간 차원은 매우 의미 있는 중요한 차원이다.
- 대부분의 의사결정자는 항상 기업의 성과가 기간에 걸쳐 어떻게 변화되어 왔는지 그 추이에 관심을 가지고 있다.
- 이 달의 영업이익이 지날 달과 비해 상승했는지 하락했는지 혹은 작년 동기에 비해 어떠한가와 같은 기간별 변호를 보고자 할 것이다.
- 기간 차원은 연속적인 데이터를 순차적으로 비교 가능해야 한다.
11.3 계획/실적 차원[편집]
- 실적, 예산, 계획, 추정 등과 같은 항목을 가진다.
- 사실 혹은 기간 차원에 비해 구성 항목의수 적으며, 항목들 사이의 관계식은 비교적 단순하다.
- 많은 다차원 모델에서 공통적으로 나타나고 있으며, 각 항목들 사이의 차이를 통해서 의사결정자는 기업의 경영전략을 수정한다.
12 다차원 모델 검증 절차[편집]
1. 사용자 요구 검증
- 설계된 데이터모델이 사용자요구를 충족시킬 수 있는지를 정보요구 사항과 데이터모델을 비교하여 적정성 검토
2. 기존 시스템 항목 추출 검증
- 데이터웨어하우스 모델에 적재할 원천자료의 검증을 실시
- 운영시스템에서의 모든 항목이 데이터웨어하우스를 지원할 수 있는가에 대하여 추출 항목 및 방법 검토
3. 데이터모델 검토 및 승인
- 설계된 데이터모델은 사용자와의 검토를 거쳐서 데이터웨어하우스 모델로 설정됨
13 Star Schema[편집]
- Dimension Table과 Fact Table로 구성됨
- 각 차원 테이블의 Key 열은 사실 테이블의 키가 됨
- 간단한 스타 스키마의 경우 하나의 사실 테이블과 여러 개의 차원 테이블로 구성되며, 복잡한 경우 수백 개의 사실 테이블과 차원 테이블을 가질 수도 있음.
- 사실 테이블 내에 있는 데이터에 대한 검색 기준으로 차원 테이블의 열을 사용함으로써 응답에 필요한 조인의 횟수를 최소화 시킴
- 어플리케이션의 확장성과 유연성이 제한됨.
- 사실 테이블에 대한 직접적인 질의를 허용하지만, 질의에 대한 유연성이 많이 떨어짐.
- 사실테이블은 외래키 열과 상세 데이터 값을 가지는 열로 구성, 외래키들은 차원 테이블과의 조인에 사용됨
- 차원테이블은 역정규화된 데이터구조를 취함, 각 속성은 사용자에게 의미가 있고 실제로 사용자가 질의를 통해 볼 수 있는 형태의 값을 가짐
14 Snowflake Schema[편집]
- 차원 테이블이 정규화된 형태를 가진다.
- 데이터를 저장하는 데 필요한 저장공간을 최소화 시킴
- 어플리케이션의 유연성이 증가됨.
- 많은 데이블로 인해 구조 복잡
- 사용자의 질의에 대한 결과를 정확히 검증하기 어려움