![[-]](/moniwiki/imgs/plugin/arrup.png "[-]")
![[+]](/moniwiki/imgs/plugin/arrdown.png "[+]")
[edit]
1 장의 목표 #
- 요구사항의 규정이 어떻게 데이터 설계를 결정하는지 명확히 이해
- 차원 모델링을 소개하고, 개체-관계 모델링과 대조
- 스타 스키마의 기본을 검토
- 사실 테이블의 내부와 차원 테이블의 내부가 무엇인지 알아본다
- DW를 위한 스타 스키마의 장점들을 정한다.
[edit]
2 요구사항에서 데이터 설계까지 #
설계 결정
앞서 설명한![[http]](/moniwiki/imgs/http.png)
Information Package에 근거하여 차원모델링을 한다.
- 주제 선택
- 구체화정도 선택
- 차원을 확인하고 식별하기 (차원: 사실(fact)를 바라보는 관점, 분석하고자 하는 관점)
- 사실을 선택하기(사실: 분석하고자 하는 대상)
- 데이터의 생명주기 결정
앞서 설명한
Information Package에 근거하여 차원모델링을 한다. 
- 정보 패키지의 하단의 측정치들을 작업의 후보가 된다.
- 측정치들 하나하나를 검토함으로써 하나의 자료 구조로 그룹지을 수 있다는 것을 발견할 것이다.
- 차원들(날짜, 제품, 지불방법, 고객인구통계, 딜러)은 사실(fact)을 바라보는 관점이다.
- 각 차원 테이블은 한 질의의 부분이 될 동등한 기회를 가진다.
- 가장 좋은 데이터 접근을 제공해야 한다.
- 전체 모델은 질의 중심적이어야 한다.
- 질의와 분석을 위해 최적화 되어야 한다.
- 차원와 사실의 상호작용함을 보여야 한다.
- 모든 차원이 사실 테이블과 동등하게 상호작용할 수 있는 방법으로 구조화 되어야 한다.
- 차원 계층들에 따라 드릴 다운이 나 롤 업하게 해야 한다.
- 차원 테이블은 중앙의 사실 테이블과 직접적인 관계를 가진다.
- 모든 차원 테이블의 속성들이 사실 테이블에 속한 속성들을 분석하기 위하여 하나의 질의에 참여하는 균등한 기회를 갖도록 한다.
- 차원 모델의 배치가 별모양
[edit]
4 차원 테이블 특징 #
- 차원 테이블 키(dimension table key). 차원 테이블의 기본키는 테이블에서 각 행을 유일하게 식별
- 테이블은 넓다(table is wide). 많은 열을 가짐. 50개 이상의 열을 가지는 것은 특별한 것이 아님
- 텍스트로 된 속성(textual attributes). 수치값을 찾기 어려움. 속성들은 텍스트 형식
- 속성들은 직접 연관되지 않음(attirbues not directly related). 차원 테이블의 속성들과 그 테이블에 속성들과 직접 관련되어 있지 않음.
- 정규화 되어 있지 않다(not normalized).
- 드릴다운, 롤업(drilldown, rollup).
- 다수 계층(multiple hierachies)
- 더 작은 개수들의 레코드(fewer number of records).
[edit]
5 사실 테이블 특징 #
- 합성된 키(concatenated key). 사실 테이블의 기본키는 모든 차원 테이블의 기본키(외부키)의 조합
- 데이터 구체화정도(data grain). 측정값(measure)의 상세함의 수준. 합성된 키의 수준.
- 완전 덧셈 측정치(fully additive measures).
- 반 덧셈 측정치(semiadditive measures).
- 테이블은 깊고, 넓지 않다(table deep, not wide)
- 희박 데이터(sparse data)
- 퇴화 차원(degenerate dimensions). 주문번호와 같은 measure도 아닌 metric(측정규준, 지표, 실판매가, 딜러공제, 옵션가격 등..)도 아닌 속성
[edit]
6 사실없는 사실 테이블(factless fact tables) #
- fact가 없는 테이블이다.
- 이런 형태는 사실 테이블이 사건을 나타내는 경우에 발생한다.
- count(*) 연산 위주
[edit]
7 데이터 구체화 정도(data granularity) #
- 구체화 정도는 fact table의 상세 수준을 나타낸 정도
- 가장 낮은(atomic) 구체화 정도를 유지할 때의 장/단점
- 운영 시스템으로 접근할 필요가 없이 사용자의 요구사항을 처리할 수 있음
- 드릴다운, 롤업의 질의들을 효율적으로 수행
- 데이터 마이닝(data mining) 어플리케이션들은 가장 낮은 구체화 정도를 요구함
- 드릴다운, 롤업의 질의들을 효율적으로 수행
- 저장 및 유지면에서 비용이 많이 든다. 또한 필수적으로 집계 fact table을 만들어야 한다.
- 운영 시스템으로 접근할 필요가 없이 사용자의 요구사항을 처리할 수 있음
- 가장 낮은(atomic) 구체화 정도 = 차원의 기본키들의 조합 + 기타 fact table의 조합이 각각의 row를 식별할 수 있음.