3

나는 전에 직면하지 않은 상황이 있습니다.치수 모델링 - 다양한 치수에서 사용되는 공통 속성 합성 키

동일한 ERP 시스템의 인스턴스가 여러 개 있는데, 위성 로캘에 따라 다릅니다. 각 로캘에는 고유 한 ID가 할당됩니다.

각 위성 위치 내에서 DB 스키마는 다른 것과 동일하며 동일한 테이블, 동일한 값입니다.

테이블을 결합 할 때 두 개 이상의 로캘의 파트가 자연 작동 키가 동일하지만 추가 특성 데이터가 다를 수 있다고 가정합니다. 그리고 위성 로케일을 기반으로 한 부품에 연결할 수 있어야하므로 컴포지트 키 (부품 ID 및 위성 ID)가 필요하다고 생각합니다.

이제이 단일 차원에서는 괜찮 으면서도이 Satellite ID는 다른 많은 차원의 다른 위치에서 동일한 방식으로 사용됩니다. 또한 많은 팩트 테이블을위한 주요 슬라이서입니다.

이 속성을 어떻게 처리해야합니까? 자체 차원과 눈송이에 넣으시겠습니까? 또는 값을 각 차원 (복제)으로 밀어 넣고 사실 테이블에 Satellite 차원에 유일한 FK를 보관하게할까요?

+0

"추가 특성 데이터가 다를 수 있음"은 무엇을 의미하는지 명확히 할 수 있습니까? 그리고 한 가지 예 (문제의 본질과 예외를 포착)를 보완해야합니다. –

+0

Satellite ID는 다르지만 Natural 키는 동일합니다. 설명, 측정 단위 및 상품 코드와 같은 다른 속성 데이터는 각 위성 로케일이 부품을 다른 부품과 약간 다르게 취급하므로 다를 수 있습니다. 희망이 명확하게. – Srixon

답변

2

가장 이상적인 해결책은 ETL 프로세스 중에 Natural Operational Keys을 각 PartID/SatelliteID (및 동일한 상황에있는 모든 차원에 대해 고유 한 대리 키)로 바꾸는 것입니다. 예를 들어, 시간 차원에서는 대리 키를 건너 뛸 수 있습니다).

물론 이것은 대리 테이블뿐만 아니라 사실 테이블에도이 대리 키를 추가해야합니다.

Satellite로보고해야하는 경우 위성 ID 열은 별도의 측정 기준으로 표시됩니다.

이것은 이상적인 솔루션입니다.

자연 키 옆에 Satellite ID가있는 추가 열을 추가하는 것이 빠르고 쉽습니다. 각 차원 (다시, 시간 차원 제외) 및 사실 테이블에이 열을 추가해야합니다. 그런 다음 가입 할 때마다 Satellite ID 열을 포함시켜야합니다.

보고 도구에서 Natural 운영 키와 Satellite ID로 구성된 복합 ID의 일부로 Satellite ID를 포함해야합니다.

또한 특정 위성에 대한 데이터를 선택할 때 사용할 수있는 특정 위성 치수를 만들 수 있습니다.