1 장의 목표

2 요구사항에서 데이터 설계까지

3 STAR Schema

4 차원 테이블 특징

5 사실 테이블 특징

6 사실없는 사실 테이블(factless fact tables)

7 데이터 구체화 정도(data granularity)

8 스타 스키마의 장점

• 요구사항의 규정이 어떻게 데이터 설계를 결정하는지 명확히 이해
  
• 차원 모델링을 소개하고, 개체-관계 모델링과 대조
  
• 스타 스키마의 기본을 검토
  
• 사실 테이블의 내부와 차원 테이블의 내부가 무엇인지 알아본다
  
• DW를 위한 스타 스키마의 장점들을 정한다.
  
  

설계 결정

• 주제 선택
  
• 구체화정도 선택
  
• 차원을 확인하고 식별하기 (차원: 사실(fact)를 바라보는 관점, 분석하고자 하는 관점)
  
• 사실을 선택하기(사실: 분석하고자 하는 대상)
  
• 데이터의 생명주기 결정
  
  

차원 모델링 기초
앞서 설명한 Information Package(http://databaser.net/moniwiki/wiki.php/%EC%97%85%EB%AC%B4%EC%9A%94%EA%B5%AC%EC%82%AC%ED%95%AD%EA%B7%9C%EC%A0%95#s-3)에 근거하여 차원모델링을 한다.

• 정보 패키지의 하단의 측정치들을 작업의 후보가 된다.
  
• 측정치들 하나하나를 검토함으로써 하나의 자료 구조로 그룹지을 수 있다는 것을 발견할 것이다.
  
• 차원들(날짜, 제품, 지불방법, 고객인구통계, 딜러)은 사실(fact)을 바라보는 관점이다.
  
• 각 차원 테이블은 한 질의의 부분이 될 동등한 기회를 가진다.
  
  

차원 모델의 기준

• 가장 좋은 데이터 접근을 제공해야 한다.
  
• 전체 모델은 질의 중심적이어야 한다.
  
• 질의와 분석을 위해 최적화 되어야 한다.
  
• 차원와 사실의 상호작용함을 보여야 한다.
  
• 모든 차원이 사실 테이블과 동등하게 상호작용할 수 있는 방법으로 구조화 되어야 한다.
  
• 차원 계층들에 따라 드릴 다운이 나 롤 업하게 해야 한다.
  
  

스타스키마의 간단한 소개

• 차원 테이블은 중앙의 사실 테이블과 직접적인 관계를 가진다.
  
• 모든 차원 테이블의 속성들이 사실 테이블에 속한 속성들을 분석하기 위하여 하나의 질의에 참여하는 균등한 기회를 갖도록 한다.
  
• 차원 모델의 배치가 별모양
  

• 차원 테이블 키(dimension table key). 차원 테이블의 기본키는 테이블에서 각 행을 유일하게 식별
  
• 테이블은 넓다(table is wide). 많은 열을 가짐. 50개 이상의 열을 가지는 것은 특별한 것이 아님
  
• 텍스트로 된 속성(textual attributes). 수치값을 찾기 어려움. 속성들은 텍스트 형식
  
• 속성들은 직접 연관되지 않음(attirbues not directly related). 차원 테이블의 속성들과 그 테이블에 속성들과 직접 관련되어 있지 않음.
  
• 정규화 되어 있지 않다(not normalized).
  
• 드릴다운, 롤업(drilldown, rollup).
  
• 다수 계층(multiple hierachies)
  
• 더 작은 개수들의 레코드(fewer number of records).
  
  

• 합성된 키(concatenated key). 사실 테이블의 기본키는 모든 차원 테이블의 기본키(외부키)의 조합
  
• 데이터 구체화정도(data grain). 측정값(measure)의 상세함의 수준. 합성된 키의 수준.
  
• 완전 덧셈 측정치(fully additive measures).
  
• 반 덧셈 측정치(semiadditive measures).
  
• 테이블은 깊고, 넓지 않다(table deep, not wide)
  
• 희박 데이터(sparse data)
  
• 퇴화 차원(degenerate dimensions). 주문번호와 같은 measure도 아닌 metric(측정규준, 지표, 실판매가, 딜러공제, 옵션가격 등..)도 아닌 속성
  
  

• fact가 없는 테이블이다.
  
• 이런 형태는 사실 테이블이 사건을 나타내는 경우에 발생한다.
  
• count(*) 연산 위주
  
  

• 구체화 정도는 fact table의 상세 수준을 나타낸 정도
  
• 가장 낮은(atomic) 구체화 정도를 유지할 때의 장/단점
  
  • 운영 시스템으로 접근할 필요가 없이 사용자의 요구사항을 처리할 수 있음
    
    • 드릴다운, 롤업의 질의들을 효율적으로 수행
      
    • 데이터 마이닝(data mining) 어플리케이션들은 가장 낮은 구체화 정도를 요구함
      
  • 저장 및 유지면에서 비용이 많이 든다. 또한 필수적으로 집계 fact table을 만들어야 한다.
    
• 가장 낮은(atomic) 구체화 정도 = 차원의 기본키들의 조합 + 기타 fact table의 조합이 각각의 row를 식별할 수 있음.
  

관계형 모델이지만, 정규화된 모델은 아니다. 하지만 장점들은 어떤 단점들보다 더 가치가 있다.

• 사용자들이 이해하기 쉽다. (사용자들과 의사소통을 위한 매개물)
  
• 항해(navigation)를 위해 최적화한다.
  
• 질의 처리에 가장 적합하다.
  
• star join , star index