0

데이터에서 복합 자연 키를 받았습니다. composite_key = ID-PRODUCT_ID-CLIENT_ID-OFFICE_ID를 사용하여이 키를 하나의 서로 게이트 키로 변환하려고합니다. 예 : composite_key = 55-001-234-01에서 surrogate_key = 123; 이것은 일반적인 시나리오입니다. 때로는 사무실 코드가 변경 될 수 있지만 같은 Ex : composite_key = 55-001-234-02에서 surrogate_key = 123으로 레코드를 식별하고 싶습니다. 데이터웨어 하우스를 만들려면 어떻게해야합니까?대리 키 대용 키

추출의 합성 키를 다른 추출과 비교하고 필드가 변경되었는지 어떻게 알 수 있습니까?

+0

자연 키를 서로 게이트 키로 매핑하는 테이블이 필요합니다. 일반적으로 대리 키와 함께 고유 한 제약 조건이있는 자연스러운 키가 데이터 테이블에 있습니다. –

+0

좋아요,하지만 사무실과 같은 복합 키의 변경으로 인해 동일한 대리 키가 생기는 지 어떻게 알 수 있습니까? 이 경우 사무실 만 변경되었으므로 비즈니스 기록에서 볼 때이 기록을 동일하게 간주하면됩니다. – odew

+0

몇 가지 규칙을 작성해야합니다. 사용자 정의 함수는 좋은 방법 인 것 같습니다. –

답변

3

다른 OfficeID를 가진 두 멤버가 동일한 대리 키에 매핑해야하는 경우 OfficeID는 단순히 복합 키의 일부가 아니며 유형 2 (동작 바꾸기)의 표준 특성 일 뿐이라는 것을 의미합니다.

크기가 너무 크지 않은 경우 ETL 도구에서 사용할 수있는 간단한 천천히 변경하는 치수 구성 요소를 사용하는 것이 좋습니다. 이러한 구성 요소가없는 경우 차원에있는 멤버가 존재하는지 여부를 조회하기 만하면됩니다. 기존의 경우 삽입을 적용하지 않으면 OfficeID를 변경하기위한 업데이트를 적용합니다.

크기가 크고 성능 문제가있는 경우 속성 유형 2에 대한 체크섬을 계산하여 성능을 향상시키고 유용 할 수 있습니다. 조회에서이 체크섬을 반환하고 현재 체크섬과 비교해야합니다 열. ID가 동일하면 update 문의 실행이 필요하지 않습니다.

관련 문제