사실 열로 거의 변경되지 않는 diminesions 축소

Question

스타 스키마 설계에서 팩트 테이블의 차원 테이블은 거의 필수입니다. 많은 비즈니스 사례에서 모델러는 일정한 치수 값이 제어없이 변경되지 않는다는 것을 신뢰할 수 있다고 가정 할 수 있습니다. 예를 들어, 성별은 사실 팩트 테이블의 열이 될 수있는 차원으로 사용되기도합니다.

나는 사람들이 항상 이것을 생각하는지 잘 모르겠다. 차원을 추가하고 생각하지 않는 것이 더 쉽습니다. 그러나 킴볼 규칙 중 하나 인 사실 테이블에 너무 많은 치수를 두어서는 안됩니다 (필자는 그가 제안한 숫자가 약 20 개라고 생각합니다).

나는 예를 들어 성별을했다,하지만 거기에 다른 많은 등 국가 이름, 도시 이름, 신용 카드 종류, 같은

내 질문은 :

어떤 규칙 하나가 여부를 결정하는 데 사용한다 팩트 테이블에 값을 임베드/축소하려면 별도의 차원을 갖는가? 몇 가지 가능한 대답은 다음과 같습니다. 1. 변경되지 않은 경우 (예 : 성별). 2. 값이 거의없고 길이가 짧은 경우?

그 밖의 무엇? 내가 대답 질문을 고려하더라도

편집

, 나는 여전히 연구를 촉진 갔다. 에 크기를 사용하는 경우가 있습니다. 이 사례는 여기에 있습니다 : "SQL Server Analysis Services (SSAS)의 드릴 스루 작업을 수행하려면 차원에서 특성을 선택해야하므로 사실 차원이 드릴 스루 작업을 지원하는 데 자주 사용됩니다. 그들은 훈련을 통해, 당신은 차원에서 그 분야가 있어야합니다. "

위

여기 Degenerate Dimensions

에서 인용되었다 나는 피사체가 관심있는 사람 (들)에 대한 추가 분석이 필요합니다 생각합니다.

Answer 1

킴볼이 "축퇴 차원"이라고 부르는 것, 즉 사실 값 테이블에 차원 값을 직접 저장하는 것처럼 들리는 것 같습니다. 킴볼 자신이 이것을 취하는 것은 당신이 단지 그 차원을위한 하나의 기둥을 가지고있을 때 그것들을 사용한다는 것입니다. 그것은 종종 사실과 함께 매우 낮은 카디널리티의 무언가입니다. 좋은 예는 구매 주문과 같은 것입니다. 구매 주문 사실 테이블이 있고 사실과 일대일로 이루어지는 구매 주문 차원이 아니라 실제로 축퇴 차원 인 PurchaseOrderReference라는 열이 있습니다.

그러나 차원 수를 상당히 낮게 유지하는 이유는 사실 테이블이 너무 넓어지는 것을 막기 위해서입니다. 그리고 차원 열을 사실에 넣기 시작하면 훨씬 더 넓어지고 성능이 떨어집니다. 예를 들어, 큰 문자열 열 또는 특정 숫자 형식을 추가하는 경우이 값은 차원 키 열보다 클 수 있습니다. 단일 차원 키로 벗어날 수있는 여러 열을 추가하면 그 영향은 훨씬 커집니다.

이 문제에 대한 해결책은 치수의 비정규 화입니다. 당신은 주 및 도시를 언급합니다 - 이것들은 함께 하나의 위치 측정 항목에 들어갈 수 있습니다. 그런 다음 사실에서 위치 측정 항목까지 두 가지 대신 하나의 차원 키가 있습니다 (하나는 도시로, 하나는 상태로). 성별에 대한 귀하의 사례는 퇴화 된 차원의 후보가 될 수 있지만, 성별이 귀하가 저장하는 사람들에 대한 유일한 속성 인 경우에만 가능합니다.사람 치수가 있거나 사람들에 대한 여러 속성 (성별, 신장, 머리카락 색 등)이있는 경우 함께 한 차원에서 더 나을 수 있습니다.

많은 사람들이 이런 식으로 설계하지 않는다는 것이 맞습니다. 많은 도시 사람들이 별도의 도시와 주 테이블이 정상적으로 (그리고 올바른) 더 정규화 된 데이터베이스에 익숙해 져 있기 때문에 이것이 잘못된 것이라고 생각합니다. 보다 폭이 넓은 차원이 더 좋은 특성을 가진 많은 차원을 만듭니다.