. Grouping
차원 중에서 속성도 별로 없으면서 키값이 엄청 많은 차원들에 사용하면 유용
DiscretizationMethod와 DiscretizationBucketCount 속성을 사용하면 자동으로 Grouping을 지원하며 아래와 같은 모양이 나온다.
적당하게 그룹핑을 해주는데 사실 이게 맘에 안들면 걍 SQL을 이용해서 별도 속성을 만들면 원하는대로 만들 수 있다.
CASE WHEN Weight IS NULL OR Weight<0 THEN 'N/A'
WHEN Weight<10 THEN '0-10Kg'
WHEN Weight<20 THEN '10-20Kg'
ELSE '20Kg or more'
END
|
이런 식으로...
. Banding
Grouping은 차원에서의 그룹화라면 Banding은 Fact를 건드려서 만들어내는 그룹화 방법이다. 그래서 자연스럽게 Grouping은 차원의 키의 개수나 값은 변화가 없지만 Banding은 변화가 온다.
Banding은 Band를 묶는 조건을 고객이 바꾸길 원할때 팩트 테이블을 전부 다시 말아야 하는 불상사가 생길 수 있는데 다음과 같은 경우다.
왼쪽이 팩트고 오른 쪽이 디멘전인데 OR값을 그냥 Surrogate키로 의미없이 땄을때 만약 9815값이 MEDIUM이었다가 LOW라고 정의를 바꾸려면 팩트테이블의 OR컬럼을 모두 2에서 1로 UPDATE가 들어간다.
이 때 디멘전의 Surrogate키를 만약 의미를 가지고 따게 되면 (가령 Order Value/100) 대리키 RANGE정의가 바뀌더라도 차원만 UPDATE하게 되므로 간편하다!
. Modeling Slowly Changing Dimension
차원의 속성이 변하지 않는다면 좋겠지만... 그런일은 일어나지 않는다. 속성이 변하는 차원을 관리하기 위한 대표적인 모델링 기법을 SCD I~III 이라고 부른다. 실제로는 한 차원안에서도 속성 별로 1~3유형이 달라지도록 모델링해야 할 수 있다.
. Type I SCDs
가장 흔하고 가장 간단하고 별로 할일이 없다. 속성이 변하면 그냥 단순히 과거의 값을 UPDATE하고 끝난다. RDB의 집계테이블이라면 모든 집계테이블을 재집계해야겠지만 Analysis Services는 그럴 필요가 없이 차원만 UPDATE해주면 된다.
항상 현재기준의 속성값으로 과거 팩트가 제공된다.
(다만 집계디자인을 사용하는 경우에는 집계테이블과 마찬가지 원리로 집계값들이 DROP된다.)
만약 해당 팩트가 발생한 시점의 차원의 속성값을 알고 싶다면 Type I을 사용해선 안된다.
가장 흔한 예로 주문한 "고객의 주소 별 주문액" 값이라면 고객차원의 주소는 항상 현재 주소를 가지고 있으므로 주문 당시의 주소별 주문액은 Type I으로는 알수가 없는 것이다.
Type I의 속성값들은 MDX쿼리에서 함부로 사용해서는 안된다. 값이 변경되면 무의미해질 수 있다.
. Type II SCDs
차원의 속성이 변하는 이력을 모두 관리하는 모델링 기법이다. Surrogate키가 필수적으로 요구되고 다음 3가지 컬럼이 일반적으로 항상 요구된다.
1. Current/Pervious 여부컬럼
2. 유효시작일시
3. 유효종료일시
Surrogate키는 고객이 보기에는 의미없는 컬럼이므로 AttributeHierarchyVisibleState속성은 False로 둔다. 그리고 특성관계에서 실제 의미를 가지는 키값으로 집계구조를 생성한다.
그리고 시점별로 달라지는 속성들을 위해서 또 고객에게 노출되지 않는 중간집계컬럼을 둬서 쿼리 속도를 향상시킬 수 있다.
. Type III SCDs
현재 속성 값과 직전(또는 최초) 속성 값 2가지만을 가지는 차원인데 실제로는 쓸일이 거의 없다. 특성관계만 보고 넘어가자
. Modeling junk dimension
속성이 달랑 1개이고 속성값도 몇개가 안되는 자잘한 차원들이 설계하다보면 많이 나오는데 이를 모두 별도의 차원으로 할 경우... 성능에도 안좋고 고객도 사용하기 어렵다.
이런 차원들을 모아서 1개의 차원으로 만드는 것을 junk dimension이라고 한다.
보통 팩트테이블을 가지고 가능한 조합을 추출해내고 Surrogate키를 따서 하나의 차원테이블을 만들어서 구현한다. Surrogate키는 역시 고객에게는 Visible False이다.
junk 차원에서 일부 차원이 분리되어 나가거나 할때는 기존 팩트값에 꽂힌 Surrogate키가 충돌이나거나 하지 않게 세심하게 작업해야 한다.
. Modeling ragged hierarchies
레벨깊이가 일정하지 않은 부모/자식구조를 갖는 차원을 말한다.
재귀적으로 부모/자식 관계를 갖는 테이블이 대표적인데 정해진 level depth가 정해져 있지 않기 때문에 골치 덩어리다.
- Usage 속성값이 Parent인 컬럼이 부모컬럼이다.
- NamingTempate속성값으로 레벨이름을 명명할 수 있다. (예: 대;중;소;세)
사용자계층에 대해서 HideMemberIf 속성을 사용하면 재귀테이블이 아니더라도 Ragged hierarchies를 표현할 수 있는데 테이블 구조는 다음과 같다.
테이블 구조
특정 레벨 이하의 리프가 상위 값을 가진다.
생성된 계층
위와 같이 상위값이 다른 경우 Level이 하나씩 당겨지는 방식이다.
두번째 방법이 조금 낫긴 하지만 ragged hierarchies는 최대한 피해야 한다.
쿼리속도, 처리속도, 설계난이도, MDX개발 난이도 어느 것 하나 좋지 않다.
집계디자인도 필수적으로 IsAggregateable: False처리하라.
