2017년 9월 12일 화요일

데이터 웨어하우스 툴킷 - 2장

2장 킴벌 다차원 모델링 기법 개요

우리는 여러분이 이 장을 한 번에 처음부터 끝까지 읽을 것을 기대하지 않는다. :D
대신 이 장이 우리 기법들에 대한 참조 역할을 하길 바란다. :D
각각의 기법들에 관련해서는 활용 사례에 기반한 더 자세한 설명과 그림이 포함된 이후 장들의 위치를 추가하였다. :D

기본개념

비즈니스 요구 사항과 데이터 현황 수집

  • 비즈니스 요구 사항과 원천 데이터의 실상을 이해할 필요가 있다.
  • 현업 담당자와 회의를 통해 핵심성과지표(KPI), 당면한 비즈니스 이슈, 의사결정프로세스, 분석 요건 등을 들을 수 있고, 비즈니스 목표를 이해할 수 있다.
  • 원천 시스템 전문가와 협의하여 면밀한 데이터 프로파일링을 수행하고, 이를 통해 원천 데이터의 실상을 확인하여 데이터 가용성을 평가할 수 있다.

다차원 모델링 워크숍

  • 다차원 모델은 현업 업무 담당자와 데이터 거버넌스 담당자가 공동으로 참여하여 설계해야한다.
  • 다차원 모델은 비즈니스와 분석 요건을 전체적으로 이해하지 못한 사람들만으로 설계되어서는 안 된다. 
  • 협업은 핵심적인 요소이다.

4단계 다차원 설계 프로세스

  • 다차원 모델링에서 네 가지 핵심 의사결정 항목을 아래와 같다
  1. 비즈니스 프로세스를 선택하라.
  2. 그레인을 확정하라.
  3. 디멘션을 식별하라.
  4. 팩트를 식별하라.
  • 위의 질문들의 대한 대답은, 공동 모델링 회의에서 비즈니스 요구사항원천 데이터 실상을 고민하면서 결정된다.
  • 비즈니스 프로세스, 그레인, 디멘션, 팩트가 확정된 이후 설계팀은 테이블과 칼럼명, 샘플 데이터와 비즈니스 규칙을 결정하게 된다.

비즈니스 프로세스

  • 조직에서 수행되는 운영 업무 활동이며 예제로는 주문 접수나, 보험 클레임 처리, 수강신청, 매월 전 계좌를 결산하는 일 등이 있다.
  • 비즈니스 프로세스 이벤트는 팩트 테이블에 팩트들로 변환될 실적 수치를 생성하고 기록한다.
  • 팩트 테이블은 하나의 비즈니스 프로세스 결과에 초점을 둔다.
  • 프로세스 선택은 중요하다. 설계 대상을 정하는 일이고, 그에 따른 그레인, 디멘션, 팩트들의 확정이 뒤따르기 때문이다.
  • 각 비즈니스 프로세스는 전사 데이터 웨어하우스 버스 매트릭스에서 하나의 행에 해당된다.

그레인

  • 그레인 확정은 다차원 설계에서 중요한 단계이다.
  • 그레인은 팩트 테이블의 로우 하나가 정확히 무엇을 나타내는지를 정의한다.
  • 모든 후보 디멘션과 팩트가 그레인에 일관성을 가져야 하므로, 디멘션과 팩트를 선별하기 전에 그레인이 확정되어야만 한다.
  • 이러한 일관성은 BI애플리케이션 성능과 사용 편의성을 중시하는 다차원 설계가 전체적으로 동질성을 가지게 한다.
  • 최소단위 그레인은 비즈니스 프로세스에서 발생하는 데이터 중 가장 낮은 레벨을 의미한다.
  • 그레인 확정은 최소단위 그레인 데이터부터 시작하기를 권장한다.

상황을 설명하는 디멘젼

  • 디멘션 테이블은 설명 속성을 포함하며, bi애플리케이션에서 팩트의 그룹핑이나 값에 대한 필터링에 사용된다.
  • 디멘션 : "누가, 언제, 어디서, 무엇을, 어떻게, 왜"의 비즈니스 프로세스 이벤트를 둘러싼 배경을 설명한다.
  • 언제든지 하나의 팩트 로우에 연결하는 디멘션은 하나이 값이어야 한다.


측정을 위한 팩트

  • 팩트 : 비즈니스 업무 처리에서 발생하는 측정값으로 거의 대부분 숫자이다.
  • 하나의 팩트 테이블 로우는 팩트 테이블 그레인으로 기술되는 값 측정 처리와 일대일 관계를 갖는다.
  • 팩트 테이블 안에는 확정된 그레인과 부합하는 팩트들만이 허용된다.
  • 예를들면, 소매업 업무처리에서 판매된 제품의 수량과 가격은 정상적인 팩트이지만, 매장관리자의 월급은 팩트 테이블에 포함 되어서는 안된다.

스타 스키마와 OLAP 큐브

  • 스타 스키마 : 
    • RDBMS에서 구현되는 다차원 구조이다. 
    • 스타 스키마는 팩트 테이블과 관련된 디멘션의 키 참조를 통해 연결되는 것이 특징이다.
  • OLAP큐브 : 
    • 다차원 데이터베이스에서 구현되는 다차원 구조이다. 
    • OLAP큐브는 관계형 스타스키마로부터 파생되거나 동등할 수 있다.
    • OLAP큐브는 차원 속성과 팩트를 포함하지만 SQL보다 분석 기능과 성능이 뛰어난 XMLA, MDX같은 언어를 통해 접근한다.
    • OLAP큐브는 다차원 DW/BI시스템 구현의 마지막 단계에 해당되며, 최소 단위 관계형 스타스키마에 기초한 요약구조로서 존재할 수 있다.

다차원 모델의 유연한 확장성

  • 다차원 모델은 데이터 관계가 변화될 때 탄력적이다.
  • 이후에 오는 모든 변화는 기존 bi쿼리나 애플리케이션의 변경 없이 반영될 수 있고, 쿼리 결과도 영향을 받지 않는다.

  • 기존 팩트 테이블의 그레인에 부합하는 팩트는 신규 칼럼 생성을 통해 추가할 수 있다.
  • 디멘션은 기존 팩트 테이블에 참조 키 칼럼을 생성함으로써 추가 가능하다. 단, 팩트 테이블의 그레인을 훼손하지 않아야 한다.
  • 속성은 기존 디멘션 테이블에 신규 칼럼을 생성함으로써 추가할 수 있다.
  • 팩트 테이블의 그레인은 기존 디멘션 테이블에 속성을 추가함으로써 더욱 상세해질 수 있으며, 팩트와 디멘션 테이블에 기존하는 칼럼명을 유지하면서 더 낮은 그레인으로 팩트 테이블을 재정의할 수 있다.

팩트 테이블 기본 기법

팩트 테이블

  • 팩트 테이블은 실세계의 운영 업무 처리에 의해 생성되는 숫자로 된 측정값을 포함한다.
  • 숫자 측정값 외에도 팩트 테이블에는 항상 연계된 디멘션의 참조 키를 포함하고, 퇴화 디멘션 키와 날짜 및 시간정보도 포함한다.
  • 가장 낮은 그레인 레벨에서 팩트 테이블 로우는 운영 업무 처리 하나에 대응된다.
  • 그래서 팩트 테이블의 기초 설계는 결과적으로 생성될 리포트의 영향이 아닌, 물리적인 업무 활동에 기초해야 한다.

합산 가능, 부분 합산 가능, 합산 불가 팩트

  • 합산 가능한 팩트 : 
    • 가장 유연하고 유용한 팩트
    • 팩트 테이블과 연관된 어떤 디멘션으로도 합산 가능한다.
  • 부분 합산 가능 팩트 : 
    • 일부 디멘션에 대해서만 합산 가능하다. (예: 잔고금액, 재고스냅샷의 보유 재고량)
    • 재고 스냅샷 스키마에서 보유 재고량은 제품이나 지점 축을 통해 요약되어, 유효한 총계를 나타낼 수 있다.
    • 그러나 재고량은 어느 한 시점에서의 잔고 또는 재고의 스냅샷을 표현하기 때문에 시간에 걸쳐 합산할 수 있는 속성은 아니다.
    • 날짜를 통해 계좌 잔고나 재고 수준을 집계하는 가장 유용한 방법은 평균을 구하는것이다. 
    • 시간에 걸친 평균을 계산하기 위해 SQL문의 AVG함수를 사용할 수 없다.
  • 합산 불가 팩트 : 비율과같은 측정값은 완전히 합산 불가능한 것이다.

팩트 테이블의 널 값

  • 널 값이 포함된 측정값 칼럼은 팩트 테이블에서 아무런 문제가 없다.
  • 널 값은 팩트 테이블의 참조 키 칼럼에서는 피해야 한다. 
  • 참조 키 칼럼의 널 값은 자동적으로 참조 무결성 위배를 일으킨다.

표준 팩트

동일 측정값 칼럼이 서로 다른팩트 테이블에 나타난다면 팩트의 기술적 정의가 동일한지 확인해야한다.

트랜잭션 팩트 테이블

트랜잭션 팩트 테이블은 운영 업무 처리가 발생할 때만 로우가 생성되기 때문에 로우 수가 많을 수도 있고 적을 수도 있다.

주기적 스냅샷 팩트 테이블

  • 로우는 일 단위, 주 단위, 월 단위와 같은 일정 기간 동안 발생한 많은 측정 이벤트를 요약한다.
  • 그레인은 개별 트랜잭션이 아닌 기간이다.


점진적 스냅샷 팩트 테이블

  • 프로세스의 처음부터 끝까지 예측 가능한 단계마다 발생하는 측정 이벤트를 요약한다.
  • 주문 처리나 클레임 처리와 같은 파이프라인 또는 워크플로우 프로세스는 시작점, 중간단계, 종료가 정의되어 있으며, 이 단계들이 팩트 테이블 설계에 반영된다.
  • 팩트 테이블에는 프로세스 각 주요 단계에 해당하는 일자 참조 키들이 있다.
  • 점진적 스냅샷 팩트 테이블의 각 로우는 하나의 주문 라인에 해당되며, 주문 라인이 생성될 때 처음으로 추가된다.
  • 일련의 처리가 딘행되면서 점진적 스냅샷 팩트 테이블 행은 다시 처리되어 업데이트 된다. 
  • 점진적 스냅샷 팩트 테이블 로우의 지속적인 업데이트 과정은 세 가지 팩트 테이블 유형 중 유일하다.

팩트 없는 팩트 테이블

  • 많은 측정 이벤트들이 숫자 값으로 기록되지만 어떤 이벤트는 단지 그 시점에 관련된 디멘션 집합만으로도 기록할 수 있다.
  • 예를 들면, 학생의 강의 출석 처리는 숫자를 기록하지 않지만 팩트의 로우는 달력 일자, 학생, 강사, 장소 그리고 강좌의 참조 키 만으로도 잘 정의 될 수 있다.
  • 고객과의 의사소통은 이벤트이지만 관련된 측정값은 없을 수 있다.
  • 팩트 없는 팩트 테이블은 발생하지 않은 부분을 분석하는데 사용될 수 있다.
    • 이런 질의는 항상 두 개의 영역이 있는데 하나는 전체 대상 테이블로 모든 발생 가능한 이벤트를 포함하고,
    • 다른 하나는 활동 기록 테이블로 발생한 이벤트만을 포함한다.
    • 전체 대상 테이블에서 활동 기록 테이블을 빼면, 그 결과는 발생하지 않은 이벤트의 집합이 된다.
    • 프로모션 대상이지만 판매 되지 않은 제품은 무엇인가?
    • 판매 팩트 테이블은 실제 판매가 된 SKU를 기록한다. SKU가 판매되지 않았을 경우 0으로 판매 수량을 관리하는 팩트 로우는 생성되지 않는데, 만약 판매 수량이 0인 로우를 관리한다면 팩트 테이블의 크기가 너무 커지게 되기 때문이다.
    • 관계형 모델에서, 위와 같은 일어나지 않은 일에 대한 질문에 대답하기 위해 프로모션의 범위나 이벤트 관리를 위한 팩트 테이블이 필요하게 된다.

집계 팩트 테이블과 OLAP 큐브

  • 집계 팩트 테이블은 오직 쿼리 성능을 향상시키기 위해서, 간단하게 최소단위 팩트 테이블 데이터의 수치 값 만을 롤업한 것이다.
  • 이런 집계 팩트 테이블은 최소단위 팩트 테이블과 더불어 BI어플리케이션에 이용되며, BI툴은 쿼리 수행 시 자연스럽게 적절한 집계 레벨을 선택할 수 있다.
  • 집계 내비게이션으로 알려진 이 처리 방식은 모든 리포트 작성자, 쿼리 툴, BI애플리케이션이 동일하게 성능의 이점을 활용할 수 있도록 제공되어야 한다.
  • 적절하게 설계된 집계 테이블들은 쿼리 성능을 향상시키는 데이터베이스 인덱스처럼 활용되지만, BI애플리케이션이나 비즈니스 사용자가 직접 활용하는 것은 아니다. 
  • 요약된 측정값을 포함하는 집계 OLAP큐브는 관계형 집계 테이블과 동일한 방법으로 만들어지지만, OLAP큐브는 비즈니스 사용자가 직접 접근하기 위한 것이다.

통합 팩트 테이블

  • 팩트들이 동일한 그레인으로 표현된다면, 여러 프로세스로부터 나온 팩트들을 하나의 통합 팩트 테이블에 함꼐 묶어 넣는 것이 편리할 수 있다.
  • 예를 들어, 판매 실적은 판매 예측과 통합하여 하나의 팩트 테이블에 통합해서 계획 대비 실적 분석 작업을 쉽고 빠르게 할 수 있다.
  • 통합 팩트 테이블은 ETL처리에 부담을 주지만, BI어플리케이션의 분석 부담은 완화시켜준다.

디멘션 테이블 기본 기법

디멘션 테이블 구조

  • 모든 디멘션 테이블은 PK 하나를 갖는다.
  • 이 기본 키는 관련 팩트 테이블에 FK로 삽입되어 디멘션 로우를 설명함으로써 팩트 테이블 로우의 의미를 분명하게 해준다.
  • 디멘션 테이블은 보통 카디널리티가 낮은 텍스트 속성 칼럼이 많은 반정규화 테이블이다.
  • 운영 코드와 분류 값이 속성이긴 하지만 텍스트 형태의 풍부한 설명을 포함해야 최상의 디멘션 속성이 된다.

디멘션 대체 키

  • 디멘션 테이블은 유일한 기본 키로 칼럼 하나를 이용한다.
  • 이 기본 키는 운영 시스템의 원천키를 그대로 사용하지 않는다.
  • 오랜 시간이 지난 후 어떤 변화를 추적할 떄 원천 키에 대한 여러 디멘션 로우가 발생할 수 있고, 하나의 디멘션의 원천 키가 여러 원천 시스템에서 생성될 때 불일치하거나 관리가 어려울 수 있다.
  • 모든 디멘션의 기본 키를 의미 없는 정수로 만들어야 한다.
  • 단 일자 디멘션은 이 대체 키 규칙에서 예외이다.

원천 키와 영속성 보장 대체 키.

  • 운영 원천 시스템에서 생성되는 원천 키는 DW/BI의 관리 밖의 비즈니스 규칙에서 적용된다.
  • 예를 들면, 사원이 퇴직한 후 재입사 한다면 사원번호(원천 키)는 변경될 수 있다.
  • 이런 직원에 대해 데이터 웨어하우스가 한 개의 키를 갖고자 할 때, 새로운 영속성 보장 대체 키가 생성될 수 있다.
  • 이 키는 비즈니스 프로세스에 독립적인 형태를 가지며, 1부터 시작하여 순차적으로 할당되는 간단한 정수여야 한다.
  • 한 사원에게 오랜 시간 프로파일 변경으로 많은 대체 키가 생기는 반면, 영속성이 보장 대체 키는 변하지 않는다.

드릴 다운

  • 드릴다운은 간단히 말하면 기존 쿼리에 로우 헤더를 추가하는 것이다.
  • 새로운 로우 헤더는 SQL GROUP BY 절에 추가되는 디멘션 속성이다.

퇴화 디멘션.

  • 때로는 디멘션에 기본 키를 제외하고 다른 내용이 없는 경우가 있다.
  • 예를 들면, 송장이 여러 라인 항목을 가질 때, 라인 항목 팩트 로우는 송장의 모든 디멘션 외래 키를 상송하고, 송장에는 다른컨텐츠가 없게 된다. 그러나 송장번호는 라인 항목 레벨의 팩트 테이블에서 유효한 디멘션 키로 남게 된다.
  • 퇴화 디멘션은 명시적으로 관련 디멘션 테이블이 없음을 인정한 채, 팩트테이블에 존재한다.
  • 퇴화 디멘션은 트랜잭션과 점진적 스냅샷 팩트 테이블에 흔하게 나타난다.

반정규화 디멘션

  • 다대일 관계의 고정 레벨 계층을 한 개의 로우에 여러 속성으로 반정규화 해야 한다.
  • 디멘션 반정규화는 다차원 모델링에 있어 간단하면서도 쿼리 속도가 빨라야 한다는 두 가지 목표를 달성하도록 해준다.

다중 계층을 가지는 디멘션

  • 많은 디멘션이 하나 이상의 계층을 갖는다.
  • 여러 계층은 동일 디멘션 테이블 내에 있을 수 있다.

플래그와 분류 값

  • 애매한 약어, 여부 플래그, 업무의 분류 값은 그 자체로도 의미가 있도록 원래의 전체 용어로 보완하여 디멘션 테이블에 담아야 한다.
  • 코드 안에 여러 의미를 갖는 운영 코드들은 각 코드를 분리하고, 각각의 딤네션 설명 속성으로 변경해야 한다.

디멘션의 널 속성

  • 디멘션 속성에 널 값은 데이터베이스마다 그룹핑과 제한 조건 시 처리하는 방식이 다르기 때문에 피해야 한다.

달력 디멘션

  • SQL 내에서 계산되기를 기대해서는 안 되며, 달력 디멘션에서 그것을 찾을 수 있도록 하는 편이 낫다.
  • 파티셔닝을 위해서, 일자 디멘션의 기본 키는 순번 형태의 대체 키 보다는 정수로 YYYYMMDD와 같은 형태로 표현하는 것이 좀 더 의미 있다.
  • 그러나 일자 디멘션 테이블은 '미정'이거나 '알 수 없음'을 표현할 수 있는 특별한 로우가 필요하다.
  • 일자/타입스탬프는 디멘션 테이블에 대한 연결 키가 아니라 팩트 테이블에 별도로 존재하는 칼럼으로 보는 것이 바람직한다.

롤 플레잉 디멘션

  • 한 개의 디멘션 물리 테이블이 하나의 동일 팩트 테이블에서 여러 번 참조될 수 있으며, 각 참조는 논리적으로 구별된 디멘션 역할로 인식한다.
  • 예를 들어, 팩트 테이블은 여러 일자를 가질 수 있다.

정크 디멘션

  • 트랜잭션 비즈니스 프로세스는 대체로 잡다하과, 카디널리티가 낮은 플래그나 구분자를 많이 만들어 낸다.
  • 이 각각의 플래그와 속성을 별도의 디멘션으로 만드는 것보다는 하나의 정크 디멘션에 모든 정보를 포함하여 생성하는 것이 좋을 것이다.
  • 모든 속성에 대한 전체 값의 조합으로 만들 필요는 없고, 원천 데이터에서 실제 발생하는 값들의 조합만 포함시키면 된다.

스노우플레이크 디멘션

  • 스노우플레이크가 계층 데이터를 정확히 보여주는 장점이 있지만 비즈니스 사용자의 이해가 어렵고, 스노우플레이크 구조상의 연결을 따라 다녀야 하는 불편함이 있다.
  • 더구나 쿼리 성능에 좋지 못한 영향을 준다.
  • 스노우플레이크가 아니어도 반정규화 디멘션 테이블에 동일한 정보를 정확히 포함시킬 수 있다.

아웃리거 디멘션

  • 디멘션은 또 다르디멘션의 참조를 포함할 수 있다.
  • 예를 들어, 은행계좌 디멘션은 계좌 개설 일자를 위해 별도의 일자 디멘션을 참조할 수 있다.
  • 이때, 이 두번째 참조 디멘션을 아웃리거 디멘션이라고 부른다.
  • 아웃리거 디멘션은 활용 가능하지만 가급적 활용하지 말아야 한다.
  • 많은 경우, 디멘션 간의 상관관계는 팩트 테이블로 내려서, 팩트 테이블에 두 디멘션의 기본키가 외래 키로 반영되어야 한다.

표준 디멘션을 통한 통합

다차원 모델링의 성공적인 접근 방법 중 하나는 여러 비즈니스의 데이터를 통합하는 간단하면서도 강력한 레시피를 정의하는 것이다.

표준 디멘션

  • 디멘션 테이블들은 서로 다른 디멘션 테이블의 속성이 동일한 칼럼명과 동일한 내용을 가질 때 표준 디멘션이 된다.
  • 두 팩트 테이블로부터의 정보는 양쪽 모두 포함된 표준 디멘션의 속성을 사용함으로써 하나의 리포트에 합칠 수 있다.
  • 표준 속성이 로우 헤더에(SQL쿼리의 그룹핑 칼럼으로) 사용될 떄, 두 팩트 테이블의 결과는 드릴 어크로스를 통해 하나의 로우에 나란히 표현될 수 있다.
  • 이것이 전사 DW/BI시스템에서 통합의 본질이다.

축소 디멘션

  • 축소 디멘션은 표준 디멘션으로 기본 디멘션의 로우 또는 칼럼의 부분집합 디멘션이다.
  • 축소 디멘션은 집계 팩트 테이블을 만들 때 필요하며, 그래뉼래러티 레벨이 높은 데이터를 양산하는 비즈니스 프로세스에도 당연히 필요하다.
  • 그 예로는 월별 브랜드별(판매 데이터에 포함되는 일자, 제품의 상세 레벨 대신) 에측 실적과 같은 것이다.
  • 표준 디멘션의 부분집합으로 또 다른 형태는 두 개의 디멘션이 동일한 상세 레벨이나 로우 데이터의 일부만을 가지는 경우이다.

드릴 어크로스

  • 드릴 어크로스는 동일한 표준 속성의 로우 헤더를 포함하는 두 개 이상의 팩트 테이블에 대해서 분할된 쿼리를 생성하는 것을 의미한다.

가치 사슬.

  • 가치사슬은 조직의 중심이 되는 비즈니스 흐름을 말한다.
  • 예를들어, 소매 판매의 가치 사슬은 구매, 재고, 판매로 구성된다. 회계 원장 가치 사슬은 예산, 집행, 지불로 이루어진다.
  • 운영 원천 시스템은 보통 가치 사슬의 각 단계마다 트랜잭션이나 스냅샷을 발생시킨다.
  • 각 프로세스마다 고유한 그래뉼래러티와 데이터 레벨, 고유한 시간 간격으로 발생하는 수치를 갖기 때문에, 각 프로세스는 적어도 하나의 최저 팩트 테이블에 데이터를 발생시킨다.

전사 데이터 웨어하우스 버스 아키텍쳐

  • 전사 데이터 웨어하우스 버스 아키텍처는 전사 DW/BI 시스템을 위한 점진적 구축방법을 제공한다.
  • 이 아키텍처는 비즈니스 프로세스 단위의 관리 가능한 범위로 DW/BI시스템을 구축할 수 있도록 도와주는 반면, 재사용되는 표준 디멘션을 통해 프로세스간 통합을 꾀한다.
  • 버스 아키텍처는 기술이나 데이터베이스 플랫폼에 종속되지 않으며, 관계형 DB나 OLAP다차원 구조에 둘 다 적용 가능하다.

전사 데이터 웨어하우스 버스 매트릭스

  • 전사 데이터 웨어하우스 버스 매트릭스는 전사 데이터 웨어하우스 버스 아키텍처를 설계하고, 의사소통할 떄 유용한 도구이다.
  • 매트릭스의 행은 비즈니스 프로세스이고, 열은 디멘션이다.
  • 매트릭스의 색칠해진 셸은 해당하는 행과 열에 해당하는 비즈니스 프로세스와 디멘션의 관련 여부를 나타낸다.

상세 구현 버스 매트릭스

  • 상세 구현 버스 매트릭스는 각 비즈니스 프로세스 행을 팩트 테이블이나 OLAP큐브에 레벨을 상세화한 버스 매트릭스다.
  • 이 상세 레벨에서, 각 팩트들의 정확한 그레인이 기술될 수 있다.

기회 및 이해관계자 매트릭스

  • 전사 데이터 웨어하우스 버스 매트릭스 행이 식별된 후 디멘션 열 대신 마케팅, 영업, 재무와 같은 비즈니스 기능으로 바까ㅜ고, 비즈니스 프로세스 행과 비즈니스 기능이 연관 있을 시 해당하는 셀을 칠하면 다르매트릭스를 그릴 수 있다.
  • 이 매트릭스는 각 프로세스 행에 해당하는 비즈니스 그룹을 알 수 있어 공동 설계 회의가 필요할 경우 참석 대상 비즈니스 그룹을 식별하는데 유용하다.


---------------------------------------------------------------------------- 여기까지 :ㅇ

디멘션 이력 관리 속성 다루기

타입0 : 최초값 유지
타입1 : 덮어쓰기
타입2 : 신규 로우 추가
타입3 : 신규 속성 추가
타입4 : 미니 디멘션 추가
타입5 : 미니 디멘션 타입과 타입 1 아웃리거 추가
타입6: 타입1 속성을 타입2 디멘션에 추가
타입7 : 타입1과 타입2 디멘션 병행


디멘션 계층 다루기

고정 레벨 계층
소규모 불규칙/가변 레벨 계층
브리지 테이블을 활용한 불규칙/가별 레벨 계층
전체 경로 속성을 가지는 불규칙/가변 레벨 계층


고급 팩트 테이블 기법

팩트 테이블 대체 키
지네 팩트 테이블
애트리뷰트와 팩트로 쓰이는 숫자 값
시간차이(Lag)/소요시간 팩트
헤더/라인 팩트 테이블
배부 팩트
배부를 활용한 손익 팩트 테이블
다중 통화 팩트
다중 측정단위 팩트
년 누적 팩트
팩트 테이블간 조인을 피아히 위한 다중 경로(multi pass) SQL
팩트 테이블의 시간 범위 추적
지연 처리 팩트


디멘션 고급기법


디멘션 테이블 간 조인
다주아 값 디멘션과 브리지 테이블
시간에 따라 변하는 다중 값 브리지 테이블
행동 태그 시계열
행동연구그룹
디멘션 속성으로서의 집계 팩트
동적 값 구간
텍스트 주석 디멘션
다중시간대
측정값 분류 디멘션
진행 단계 디멘션
핫 스와퍼블 디멘션
추상화 범용 디멘션
감사 디멘션
지연 처리 디멘션

특수 목적 스키마

이기종 상품을 위한 슈퍼타입과 서브타입 스키마
실시간 팩트 테이블
오류 처리 스키마



댓글 없음:

댓글 쓰기