2016-11-23 3 views
0

저는 데이터웨어 하우스 관행을 처음 접했고 학업 활동의 맥락에서 선택한 관심 분야의 데이터 세트를 사용하여 스타 스키마를 만들고 싶습니다. 그래서, 내 급우와 나는 한 해 동안 한 국가에서 자동차 사고의 데이터 세트를 선택했습니다.일대 다 관계 [Dim 1 : many Fact]가있는 경우 다중 값 차원을 스타 스키마에서 어떻게 표현할 수 있습니까?

대부분의 경우가 아니라면 많은 경우에 관련 차량이 두 개 이상 있습니다. 따라서 "운전자", "자동차", "사상자", "위치", "컨디션"등을 Dimentions로 사용하여 Fact Table로 "사고"사건을 선택하면 스타 스키마에서 어떻게 변형 될 수 있습니까? "Car", "Driver"및 "Casualties"치수가 다중 값을 갖는 경우? 예를 들어 나는 3 대의 자동차, 3 명의 운전자, 7 명의 사상자를 가질 수 있습니다. 스타 스키마의 사용이 필수적이라고 생각하십시오.

또한 필자가 아는 한 사실 테이블은 측정에서 숫자 값을 가질 수 있습니다. 그것은 또한 척도 변수를 측정 값으로 가질 수 있습니까?

+0

한 가지 방법은 '충돌'차원이라는 또 다른 차원이 있음을 인식하는 것입니다. 따라서 5 차를 사용하는 충돌은 동일한 단일 차원 레코드 (충돌 당 새로운 것이 생성됨)를 가리키는 사실에서 5 행을 얻습니다. 이것은 스타 스키마 아이디어를 위반하지 않고 스타 스키마의 헤더 - 디테일을 모델링하는 한 방법입니다. 합법적으로 '충돌'을 모델링하므로 충돌과 관련된 특성을 가진 자체 차원을 얻는 것이 좋습니다. 크래시 차원이 크래시 수준에서 다른 높은 수준의 사실에 합류 할 수 있다고 말할 수도 있습니다. –

+0

모델을 작성하는 또 다른 방법은 일부 (모든 것은 아님)보고 도구가 이중 계산을 중지하는 데 사용할 수있는 구조 인 브리지 테이블을 사용하는 것입니다. http://www.kimballgroup.com/2012/02/design-tip-142-building-bridges/ –

+0

답장을 보내 주셔서 감사합니다. 그래서, 제가 올바르게 이해한다면, 당신은 "사고"사실 테이블을 차원 테이블로 바꾸고 차원의 외래 키들로만 이루어진 테이블을 사실로 제안 할 것입니다. – avakas

답변

0
+0

브리지 테이블이 반드시 이에 대한 대답은 아닙니다. Kimball Group이 브리징 테이블을 사용하는 경우 : "마찬가지로 브리지 테이블을 사용하여 디자인에서 여러 차원의 차원 관계를 캡처하는 경우 드로잉 보드로 되돌아 가야합니다. 사실 테이블의 세밀성에 문제가있을 가능성이 있습니다. " (kimballgroup.com/2003/10/fistful-of-flaws) –

+0

또한 우리는 킴볼 그룹 (Kingball Group)의 말을 인용하여 브리지 테이블이이 상황에서 사용하는 것과 정확히 일치한다고 말할 수 있습니다. 사실 자연 곡물을 변경하거나 다리 테이블에 넣을 수 있습니다. 브리지 테이블은 흔히 두 가지 악의 양이 적으며 실제로 여기에 해당됩니다. – Rich

+0

@ 리치 킴볼 그룹은 분명히 자신들이 * 옵션 *이라고 말하고 있지만, 그들은 이러한 상황에 대한 유일한 해결책이 아니며, 모든 경우에 기본 해결책으로 다루어서는 안된다는 점을 강조합니다. 특정 시나리오에 가장 적합한 것이 무엇인지 결정하기 전에 모든 옵션을 고려해야한다는 것 이외에 다른 솔루션에 비해 선택해야한다고 말하는 곳이 없습니다. 브리지 테이블을 말하는 것은이 작은 정보를 가진 솔루션이므로 너무 일찍 결론에 도달했습니다. –

0

차원 모델링에서 매우 중요한 개념은 곡물의 인을 사용하는 것입니다. 랄프 킴볼 (Ralph Kimball) (차원 모델링에 대해 배우고 있다면 반복적으로 작업 할 것입니다)에서는 가능한 가장 낮은 입자를 모델링하는 것이 정말 중요하다고 강조합니다. 이를 통해 가능한 한 많은 방법으로 데이터를 슬라이스 앤 다이스 (Dice) 할 수 있습니다.

모든 것이 다 대다라고 여겨지는이 문제 중 하나를 자주 발견하면 문제는 사실 사실 테이블에서 잘못된 그레인을 선택했다는 것입니다. Nick.McDermaid (의견에서이 세분성 변경을 제안한 사람)에게 사과하면서 "사고에 개인을 참여시키는 것"은 "사고"보다 세분화되어 사실 테이블의 세분화 수준을 최소한 그 수준으로 낮추었습니다. 사고 차원을 만드는 것은 많은 의미가 있습니다.

가장 작은 입도는 아니지만 가능합니다. 예를 들어 데이터 세트가 부상을 추적하는 경우 각 참가자는 여러 번 부상을 입을 수 있습니다. 따라서 사실 테이블 곡물은 "사고 중에 지탱되는 부상"보다 좋을 수 있습니다.이 경우 상해를 입지 않은 참가자를 포함 시키려면 상해 발생이 없음을 나타내는 행이 상해 발생 차원에서 필요합니다. 그래서 당신이해야 할 첫 번째 일은 당신의 사실 테이블이 무엇인지를 결정하는 것이 아니라, 데이터를 살펴보고 가장 작은 세밀도가 무엇인지 알아 내려고합니다. 일단 그렇게하면, 팩트 테이블을 모델링하고 필요한 차원을 잘 관리해야합니다.

차원 모델링은 여러 가지 방법으로 작업 할 수 있기 때문에 까다로운 부분이 될 수 있습니다. 가장 정확한 방법은 종종 매우 명확하지 않습니다. 특히 배경에서 보다 정규화 된 데이터 구조에 익숙합니다. 무엇보다도 가장 기본적인 테이블 유형 (예 : 눈송이, 교량 테이블 등을 피하기 위해)을 모델로 삼아 모델을 만들 것을 제안합니다. 그런 트릭을 피할 수있는 솔루션을 생각해 낼 수 있는지 확인하십시오. 매우 자주 사용하면 더 나은 모델 (탐색하기가 더 쉽고 쿼리 성능이 향상되며 더 많은 질문에 답변 할 수있는 모델)로 이어질 수 있습니다.

Nick.McDermaid의 조언은 다른 가정을 시도하고 시도하는 것은 견고합니다. 초기 가정에서 벗어나는 데 도움이 될 수 있습니다. 때로는 잠재적 인 디자인이 여러 가지 있습니다 - 철저하게 모두가 최선인지 결정할 필요가 있다고 생각합니다.

0

저는 회사에서 바로이 모델을 모델링해야했습니다.

인시던트 & 차량은 자체 곡물입니다. FactIncidentVehicle이 FactIncident &이 필요합니다. 이를 통해 사건의 각 차량에 대한 사건 (날짜, 위치, 유형) 및 속성과 관련된 속성을 연결할 수 있습니다.

인시던트 차원은 거의 변하지 않는 차원으로, 경찰 보고서 번호와 같은 IncidentID가있는 몇 가지 특성 만 포함합니다.

인시던트 차량 차원에는 견인 차량과 같이이 인시던트에만 해당되는 몇 가지 속성 만 있습니다.

사고 차량 사람은 또 다른 곡물입니다. 데이터가 비 차량 사고 (예 : & 추락)를 허용하는 경우 '알 수없는'차량뿐만 아니라 '차원없는 차량'차량 기록이 필요합니다.

정크 차원이 플래그 (Y, N, UNK) 등 부상과 같은 질문을 유지하는 데 유용 등

이 방법은 잘 작동하고, 사고가 0을 가질 수 있습니다 소유자, 드라이버, 인용 동일한 차량이나 차량이 하나 이상의 사고 (차량/직원 기록)에 참여할 수있을 때뿐만 아니라 많은 차량과 1 대 다수의 사람들에게 제공됩니다.