2017-12-22 71 views
0

데이터웨어 하우스를 구축하고 팩트 테이블의 기본 키로 서로 게이트 키를 사용하려고합니다. 하지만 문제는 필자의 경우 팩트 테이블을 업데이트해야한다는 것입니다.데이터웨어 하우스의 서로 게이트 키 관리

첫 번째 질문은 소스 시스템에서 자연어 키에 해당하는 자동 생성 된 대리 키를 어떻게 찾습니까? 나는 자연과 대용 키 사이의 통신을 저장하는 룩업 테이블을 언급하는 몇 가지 해답을 보았지만 정확하게 구현 된 방법을 이해하지 못했습니다. 이 테이블을 저장해야하는 위치 : 데이터웨어 하우스 자체 또는 다른 곳?

두 번째 질문이 있습니다. 소스 시스템에는 사실에 대한 대리 키가이 L 포함되어 있지만 16Y이 트인 UUID 데이터 유형이 있습니다. 사실 수는 최대 정수 값 (4 바이트)을 초과 할 가능성이 거의 없습니다. 소스 시스템에서 제공하는 UUID를 사용하여 ETL을 단순화해야합니까? 아니면 더 복잡한 ETL을 수행하고 성능을 높이기 위해 자체 정수 대용 키를 구현해야합니까?

+0

https://stackoverflow.com/questions/2496610/insert-into-a-star-schema/2499607#2499607 –

+0

댓글을 남겨주셔서 감사합니다! –

+0

남은 질문이 하나 더 있습니다. 데이터웨어 하우스 용으로 RDBMS를 사용할 예정이며 자동 증가 기본 키를 사용하려고합니다. 처음으로 테이블에 아무 것도 삽입 할 때 RDBMS에서 생성 된 기본 키를 어떻게 알 수 있습니까? 어떤 키가 생성되었는지 알기 위해 그것을 삽입 한 후 즉시 행을 선택해야합니까? –

답변

1

질문 : 행의 초기로드시 데이터웨어 하우스에서 대리 키를 생성하는 경우 키가 후속로드에서 이미 생성 된 경우 어떻게 결정합니까? 조회 테이블을 작성해야합니까? 그렇다면 어디에 위치시킬 것입니까?

주 : 가능한 경우 사용자가 필요하지 않다고하더라도 데이터웨어 하우스 목표 테이블의 소스 시스템에서 키를 포함하십시오. ETL 문제를 해결하는 데 매우 중요합니다.

두 가지 간단한 옵션 :

1. 는 (성능이 큰 테이블에 문제가 될 수 있습니다) 목표 테이블에 대해 직접 조회를 수행합니다.

2. ETL 프로세스에서만 사용되지만 데이터웨어 하우스에 저장되는 "etl 준비 조회"테이블을 작성하십시오. 이는보다 유연한 옵션이지만 ETL에 추가 단계를 추가합니다.

+0

왜 데이터웨어 하우스에 'ETL 스테이징 조회'테이블을 저장해야합니까? 그것을 메모리에 저장할 수 있습니까? –

+0

@DenisArharov - 저는 Postgres가 테이블을 메모리에 저장할 수 있다고 생각하지 않습니다. 임시 테이블을 언급하고 있습니까? – Phil

+0

아마도 파이썬 사전을 만들고 저장할 수 있습니다 (natural_key, surrogate_key). Postgres에서 검색하는 것보다 빠르지 않습니까? –

1

나머지는 이미 답변 된 것 같습니다. 대리 키를 관리하고 유지 관리하는 것에 대해 2 센트 씩 줄 것입니다.

Teradata에서 근무하는 동안 대리 키를 많이 사용했습니다. 다음은 대용품 키에 대해 지난 몇 년간 배운 몇 가지 모범 사례입니다.

  1. 당신은.하지 많은 API를 같은 도메인 값을 생성 허용해야합니다. 귀하의 경우 특정 API (단 승인 된 마스터 소스에서 대리 키를 생성 도메인에 대한 마스터 역할을하는 하나를 선택 값은. 예를 들어, 고객 번호는 일반적으로
  2. 당신은 & 저장소를 생성 참으로 조회 테이블이 (이것은 Customer_SGK)를 호출 할 수 있습니다) CRM 시스템에서 오는하고 마스터로 과금 시스템의 가능성이되지 않습니다. 일반적으로 이러한 대용 키 테이블은 inmon 또는 kimbal 접근 방식에서 최종 LDM/PDM의 일부가 아닙니다. 이러한 은 동일한 데이터베이스 서버 내에 있지만 기술적 인 메타 데이터 스키마에 있습니다. 의 당신은 유지하기 위해 각 마스터 소스 (source1_customerNO, source2_customerNO)와 타임 스탬프에 따라 서로 게이트 키 열 (예 : CUSTOMER_ID), 소스 자연 키 컬럼 (들)을 것 같은 조회 테이블에서 스키마 "My_Tec_Schema"
  3. 를 부르 자 a 이 키가 생성 된 시간입니다.
  4. 귀하의 PK는이 열에서 고유하지 않을 수있는 Customer_ID이므로 사용할 데이터 저장 기술에 따라 고유하거나 고유하지 않은 기본 색인/키 (예 : Teradata에서는 NUPI)로 분류해야 할 수 있습니다.
  5. 두 개의 서로 다른 원본 시스템에서 오는 서로 다른 두 개의 자연 키에 대해 동일한 고객 ID를로드하는 동안 동일한 고객을 의미하는 경우가 종종 있습니다.

  6. 이 조회 테이블을 사용하면 ETL 프로세스의 첫 번째 단계 테이블/소스에서 을로드 (생성) 할 수 있습니다. 그런 다음 왼쪽 외부 조인에서 Lookup 테이블을로드하여 Surrogate Key를 가져 와서 사실 테이블 에로드하고 자연스럽게 키를로드하십시오. (당신은 항상 을 가지고 있기를 원하기 때문에 가장 빈번하게 팩트 테이블에 고아가 생기고 유일한 빠른 & 신뢰할 수있는 방법으로 그 상황을 복구하면 사실 테이블의 자연 키와 PK 또는 PI를 사용하거나 전체 테이블이 아닌 스캔)

  7. 당신은 항상 를 통해 프리젠 테이션 계층보기 ( 응용 프로그램 & 사용자 소비에 의해 사용되는 뷰를 당신의 팩트 테이블에 자연 키를 숨길 수 있습니다 매우 빠른 색인 기반 업데이트 작업 ETL 목적으로 테이블을 유지하면서/ 기술자 만 가능)
  8. 자동 번호 생성 기술을 사용하므로, 한 환경에서 다른 환경으로 데이터를 마이그레이션하는 동안 및 주요 릴리스 중에 프로덕션 데이터를 마이그레이션하는 동안 특별한주의를 기울여야합니다. (당신은 충돌을 가지고 싶지 않습니다.)

나는 대리 키들을 계속해서 사용할 수 있습니다. 이 고수준 개요를 읽은 특정 질문을하십시오. 기꺼이 도와 드리겠습니다.