다음을 통해 공유

Microsoft Fabric 웨어하우스의 차원 모델링: 테이블 로드

  • 아티클

적용 대상:Microsoft Fabric의 ✅ SQL 분석 엔드포인트 및 웨어하우스

참고 항목

이 문서는 차원 모델링 시리즈 문서의 일부입니다. 이 시리즈는 Microsoft Fabric 웨어하우스의 차원 모델링과 관련된 지침 및 디자인 모범 사례에 중점을 둡니다.

이 문서에서는 차원 모델에 차원 테이블과 팩트 테이블을 로드하기 위한 지침 및 모범 사례를 제공합니다. 테이블 만들기 및 테이블 데이터 관리 등 많은 T-SQL 기능을 지원하는 환경인 Microsoft Fabric의 웨어하우스에 대한 실질적인 지침을 제공합니다. 따라서 차원 모델 테이블을 만들고 데이터로 로드하는 작업을 완벽하게 제어할 수 있습니다.

참고 항목

이 문서에서 Data Warehouse라는 용어는 조직 전반에 걸쳐 중요한 데이터를 포괄적으로 통합하는 엔터프라이즈 Data Warehouse를 의미합니다. 반면, 독립 실행형 용어 웨어하우스는 Data Warehouse를 구현하는 데 사용할 수 있는 SaaS(Software as a Service) 관계형 데이터베이스 제품인 Fabric 웨어하우스를 의미합니다. 명확하게 하기 위해, 이 문서에서 후자는 Fabric 웨어하우스로 언급됩니다.

팁

차원 모델링에 대한 경험이 부족한 경우 이 문서 시리즈를 첫 번째 단계로 고려해 보세요. 차원 모델링 디자인에 대한 완전한 토론을 제공하기 위한 것은 아닙니다. 자세한 내용은 Ralph Kimball의 Data Warehouse 도구 키트: 차원 모델링에 대한 결정적 가이드(2013년 3판)와 같은 널리 출판된 콘텐츠를 직접 참조하세요.

차원 모델 로드

차원 모델을 로드하려면 ETL(추출, 변환 및 로드) 프로세스를 주기적으로 실행해야 합니다. ETL 프로세스는 일반적으로 원본 데이터 스테이징, 차원 데이터 동기화, 팩트 테이블에 행 삽입, 감사 데이터 및 오류 기록과 관련된 다른 프로세스의 실행을 오케스트레이션합니다.

Fabric 웨어하우스 솔루션의 경우 데이터 팩터리를 사용하여 ETL 프로세스를 개발하고 실행할 수 있습니다. 이 프로세스에서는 원본 데이터를 차원 모델 테이블에 스테이징, 변환 및 로드할 수 있습니다.

특히 다음을 수행할 수 있습니다.

  • 데이터 파이프라인을 사용하여 워크플로를 빌드하여 ETL 프로세스를 오케스트레이션할 수 있습니다. 데이터 파이프라인은 SQL 스크립트, 저장 프로시저 등을 실행할 수 있습니다.
  • 데이터 흐름을 사용하여 수백 개의 데이터 원본에서 데이터를 수집하는 로우코드 논리를 개발합니다. 데이터 흐름은 여러 원본의 데이터를 결합하고, 데이터를 변환한 다음, 차원 모델 테이블과 같은 대상으로 로드하도록 지원합니다. 데이터 흐름은 Microsoft Excel 및 Power BI Desktop을 비롯한 많은 Microsoft 제품에서 현재 제공되는 친숙한 Power Query 환경을 사용하여 빌드됩니다.

참고 항목

ETL 개발은 복잡할 수 있으며, 개발 자체가 어려울 수 있습니다. Data Warehouse 개발 활동의 60~80%가 ETL 프로세스에 투입되는 것으로 추정됩니다.

오케스트레이션

ETL 프로세스의 일반적인 워크플로는 다음과 같습니다.

  1. 선택적으로, 스테이징 테이블을 로드합니다.
  2. 차원 테이블을 처리합니다.
  3. 팩트 테이블을 처리합니다.
  4. 선택적으로, 종속 Fabric 콘텐츠(예: 의미 체계 모델)의 새로 고침을 트리거하는 등 사후 처리 작업을 수행합니다.

다이어그램은 이전 단락에 설명된 대로 ETL 프로세스의 네 단계를 보여줍니다.

마지막 ETL 프로세스 이후 원본 시스템에 추가된 차원 멤버를 포함하여 모든 차원 멤버가 저장되어 있는지 확인하기 위해 차원 테이블을 먼저 처리해야 합니다. 아웃리거 차원의 경우와 마찬가지로 차원 간에 종속성이 있는 경우 차원 테이블은 종속성 순서대로 처리되어야 합니다. 예를 들어 고객 차원과 공급업체 차원에서 사용하는 지역 차원은 다른 두 차원보다 먼저 처리되어야 합니다.

모든 차원 테이블이 처리되면 팩트 테이블을 처리할 수 있습니다.

모든 차원 모델 테이블이 처리되면 종속 의미 체계 모델을 새로 고칠 수 있습니다. 관련 직원에게 알림을 보내 ETL 프로세스의 결과를 알리는 것도 좋은 방법입니다.

데이터 스테이지

원본 데이터를 스테이징하면 데이터 로딩 및 변환 요구 사항을 지원하는 데 도움이 될 수 있습니다. 여기에는 원본 시스템 데이터를 추출하여 ETL 프로세스를 지원하기 위해 만든 스테이징 테이블에 로드하는 작업이 포함됩니다. 원본 데이터를 스테이징하는 것이 좋은 이유는 다음과 같습니다.

  • 운영 시스템에 미치는 영향을 최소화합니다.
  • ETL 처리를 지원하고 최적화하는 데 사용됩니다.
  • 원본 시스템에서 데이터를 다시 로드하지 않고도 ETL 프로세스를 다시 시작할 수 있는 기능을 제공합니다.

스테이징 테이블의 데이터는 비즈니스 사용자가 절대 사용할 수 없도록 해야 합니다. 이는 ETL 프로세스와만 관련이 있습니다.

참고 항목

데이터가 Fabric 레이크하우스에 저장된 경우 Data Warehouse에서 데이터를 스테이징할 필요가 없을 수 있습니다. medallion 아키텍처를 구현하는 경우 브론즈, 실버 또는 골드 계층에서 데이터를 소싱할 수 있습니다.

웨어하우스 staging라는 이름의 스키마를 만드는 것이 좋습니다. 스테이징 테이블은 열 이름 및 데이터 형식 측면에서 가능한 한 원본 테이블과 유사해야 합니다. ETL 프로세스를 시작할 때 각 테이블의 콘텐츠를 제거해야 합니다. 그러나 Fabric 웨어하우스 테이블은 잘라낼 수 없습니다. 대신, 데이터로 로드하기 전에 각 스테이징 테이블을 삭제하고 다시 만들 수 있습니다.

스테이징 전략의 일부로 데이터 가상화 대안을 고려할 수도 있습니다. 다음을 사용할 수 있습니다.

데이터 변환

원본 데이터의 구조는 차원 모델 테이블의 대상 구조와 유사하지 않을 수 있습니다. 따라서 ETL 프로세스에서는 차원 모델 테이블의 구조에 맞게 원본 데이터를 재구성해야 합니다.

또한 Data Warehouse는 정제되고 준수된 데이터를 제공해야 하므로 품질과 일관성을 보장하기 위해 원본 데이터를 변환해야 할 수 있습니다.

참고 항목

가비지 인, 가비지 아웃(garbage in, garbage out)의 개념은 데이터 웨어하우징에 확실히 적용되므로 가비지(저품질) 데이터를 차원 모델 테이블에 로드하지 않도록 해야 합니다.

ETL 프로세스에서 수행할 수 있는 몇 가지 변환은 다음과 같습니다.

  • 데이터 결합: 서로 다른 원본의 데이터를 일치하는 키를 기준으로 통합(병합)할 수 있습니다. 예를 들어 제품 데이터는 다양한 시스템(예: 제조 및 마케팅)에 저장되지만 모두 공통 SKU(재고 유지 단위)를 사용합니다. 공통 구조를 공유할 때도 데이터를 추가할 수 있습니다. 예를 들어 판매 데이터는 여러 시스템에 저장됩니다. 각 시스템의 판매 합집합은 모든 판매 데이터의 상위 집합을 생성할 수 있습니다.
  • 데이터 형식 변환: 데이터 형식을 차원 모델 테이블에 정의된 데이터 형식으로 변환할 수 있습니다.
  • 계산: 계산을 수행하여 차원 모델 테이블에 대한 값을 생성할 수 있습니다. 예를 들어 직원 차원 테이블의 경우 이름과 성을 연결하여 전체 이름을 생성할 수 있습니다. 또 다른 예로, 판매 팩트 테이블의 경우 단가와 수량의 곱인 총 판매 매출을 계산할 수 있습니다.
  • 기록 변경 사항 감지 및 관리: 변경 내용을 감지하고 차원 테이블에 적절하게 저장할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 나오는 기록 변경 사항 관리를 참조하세요.
  • 집계 데이터: 집계를 사용하여 팩트 테이블 차원을 줄이거나 팩트의 세분성을 높일 수 있습니다. 예를 들어 판매 팩트 테이블은 판매 주문 번호를 저장할 필요가 없습니다. 따라서 모든 차원 키로 그룹화되는 집계 결과를 사용하여 팩트 테이블 데이터를 저장할 수 있습니다.

데이터 로드

다음 데이터 수집 옵션을 사용하여 Fabric 웨어하우스에 테이블을 로드할 수 있습니다.

  • COPY INTO(T-SQL): 이 옵션은 원본 데이터가 ADLS Gen2 또는 Azure Blob Storage와 같은 외부 Azure Storage 계정에 저장된 Parquet 또는 CSV 파일로 구성되어 있는 경우에 유용합니다.
  • 데이터 파이프라인: 데이터 파이프라인에는 ETL 프로세스를 오케스트레이션하는 것 외에도 T-SQL 문을 실행하거나, 조회를 수행하거나, 데이터 원본에서 대상으로 데이터를 복사하는 활동이 포함될 수 있습니다.
  • 데이터 흐름: 데이터 파이프라인의 대안으로, 데이터 흐름은 코드 없이 데이터를 변환하고 정리할 수 있는 환경을 제공합니다.
  • 웨어하우스 간 수집: 데이터가 동일한 작업 영역에 저장되면 웨어하우스 간 수집을 통해 서로 다른 웨어하우스 또는 레이크하우스 테이블을 조인할 수 있습니다. INSERT…SELECT, SELECT INTO 및 CREATE TABLE AS SELECT (CTAS)와 같은 T-SQL 명령을 지원합니다. 이러한 명령은 동일한 작업 영역 내의 스테이징 테이블에서 데이터를 변환하고 로드하려는 경우에 특히 유용합니다. 또한 차원 모델 테이블을 로드하는 가장 효율적이고 빠른 방법이 될 수 있는 집합 기반 작업입니다.

팁

모범 사례를 포함하여 이러한 데이터 수집 옵션에 대한 전체 설명을 보려면 웨어하우스에 데이터 수집을 참조하세요.

로깅

ETL 프로세스에는 일반적으로 전담 모니터링 및 유지 관리가 필요합니다. 이러한 이유로, ETL 프로세스의 결과를 웨어하우스의 무차원 모델 테이블에 기록하는 것이 좋습니다. 각 ETL 프로세스에 대한 고유 ID를 생성하고 이를 사용하여 모든 작업에 대한 세부 정보를 기록해야 합니다.

다음에 대한 로깅을 고려해야 합니다.

  • ETL 프로세스:
    • 각 ETL 실행에 대한 고유 ID
    • 시작 시간 및 종료 시간
    • 상태(성공 또는 실패)
    • 발생한 오류
  • 각 스테이징 및 차원 모델 테이블:
    • 시작 시간 및 종료 시간
    • 상태(성공 또는 실패)
    • 삽입, 업데이트 및 삭제된 행
    • 최종 테이블 행 개수
    • 발생한 오류
  • 기타 작업:
    • 의미 체계 모델 새로 고침 작업의 시작 시간 및 종료 시간

팁

ETL 프로세스를 전담으로 모니터링하고 분석하는 의미 체계 모델을 만들 수 있습니다. 프로세스 기간은 검토 및 최적화의 이점을 얻을 수 있는 병목 상태를 식별하는 데 도움이 될 수 있습니다. 행 수를 사용하면 ETL이 실행될 때마다 증분하는 로드의 크기를 파악할 수 있으며, Data Warehouse의 향후 크기(해당하는 경우 Fabric 용량을 확장하는 시기)를 예측하는 데 도움이 될 수 있습니다.

차원 테이블 처리

차원 테이블을 처리하려면 Data Warehouse 데이터를 원본 시스템과 동기화해야 합니다. 원본 데이터는 먼저 변환되어 해당 차원 테이블에 로드할 준비가 됩니다. 그런 다음, 이 데이터는 비즈니스 키에 조인하여 기존 차원 테이블 데이터와 일치시킵니다. 그러면 원본 데이터가 새 데이터인지 또는 수정된 데이터인지 확인할 수 있습니다. 차원 테이블에 SCD(느린 변경 차원) 유형 1이 적용되면 변경 사항은 기존 차원 테이블 행을 업데이트하여 수행됩니다. 테이블에 SCD 형식 2 변경 사항이 적용되면 기존 버전이 만료되고 새 버전이 삽입됩니다.

다음 다이어그램에서는 차원 테이블을 처리하는 데 사용되는 논리를 보여 줍니다.

다이어그램은 다음 단락에 설명한 대로 새 원본 행과 변경된 원본 행이 차원 테이블에 로드되는 방법을 설명하는 흐름을 보여 줍니다.

Product 차원 테이블의 프로세스를 고려해야 합니다.

  • 원본 시스템에 새 제품이 추가되면 Product 차원 테이블에 행이 삽입됩니다.
  • 제품이 수정되면 차원 테이블의 기존 행이 업데이트되거나 삽입됩니다.
    • SCD 유형 1이 적용되면 기존 행이 업데이트됩니다.
    • SCD 유형 2가 적용되면 현재 행 버전이 만료되도록 업데이트되고 현재 버전을 나타내는 새 행이 삽입됩니다.
    • SCD 유형 3이 적용되면 SCD 유형 1과 유사한 프로세스가 발생하여 새 행을 삽입하지 않고 기존 행을 업데이트합니다.

서로게이트 키

각 차원 테이블에 는 가능한 가장 작은 정수 데이터 형식을 사용해야 하는 서로게이트 키가 있는 것이 좋습니다. SQL Server 기반 환경에서는 일반적으로 ID 열을 만들어서 이를 수행하지만, Fabric 웨어하우스에서는 이 기능이 지원되지 않습니다. 대신 고유 식별자를 생성하는 해결 방법을 사용해야 합니다.

Important

차원 테이블에 자동으로 생성된 서로게이트 키가 포함되어 있는 경우, 이를 잘라내어 완전히 다시 로드해서는 안 됩니다. 이는 차원을 사용하는 팩트 테이블에 로드된 데이터가 무효화되기 때문입니다. 또한 차원 테이블이 SCD 유형 2 변경을 지원하는 경우 기록 버전을 다시 생성하지 못할 수 있습니다.

기록 변경 사항 관리

차원 테이블에 기록 변경 내용이 저장되어야 하는 경우 SCD(느린 변경 차원)를 구현해야 합니다.

참고 항목

차원 테이블 행이 유추된 멤버(팩트 로드 프로세스에 의해 삽입됨)인 경우 변경 내용을 SCD 변경 대신 늦게 도착하는 차원 세부 정보로 처리해야 합니다. 이 경우 변경된 모든 특성을 업데이트하고 유추된 멤버 플래그 열을 FALSE로 설정해야 합니다.

차원이 SCD 유형 1 및/또는 SCD 형식 2 변경을 지원할 수 있습니다.

SCD 유형 1

SCD 유형 1 변경이 감지되면 다음 논리를 사용합니다.

  1. 변경된 특성을 업데이트합니다.
  2. 테이블에 마지막으로 수정된 날짜와 열에 의해 마지막으로 수정됨이 포함되어 있는 경우 현재 날짜와 수정을 수행한 프로세스를 설정합니다.

SCD 유형 2

SCD 유형 2 변경이 감지되면 다음 논리를 사용합니다.

  1. 종료 날짜 유효성 열을 ETL 처리 날짜(또는 원본 시스템의 적절한 타임스탬프)로 설정하고 현재 플래그 FALSE로 설정하여 현재 버전을 만료시킵니다.
  2. 테이블에 마지막으로 수정된 날짜와 열에 의해 마지막으로 수정됨이 포함되어 있는 경우 현재 날짜와 수정을 수행한 프로세스를 설정합니다.
  3. 시작 날짜 유효성 열이 종료 날짜 유효성 열 값(이전 버전을 업데이트하는 데 사용됨)으로 설정되어 있고 현재 버전 플래그가 TRUE로 설정된 새 멤버를 삽입합니다.
  4. 테이블에 만든 날짜가 포함되어 있고 열에 의해 생성됨이 포함되어 있는 경우 현재 날짜와 삽입을 수행한 프로세스를 설정합니다.

SCD 유형 3

SCD 유형 3 변경이 감지되면 SCD 형식 1을 처리하는 것과 유사한 논리를 사용하여 특성을 업데이트합니다.

차원 멤버 삭제

원본 데이터에 차원 멤버가 삭제되었음을 나타내는 경우(원본 시스템에서 검색되지 않았거나 삭제된 것으로 플래그가 지정된 경우) 주의해야 합니다. 차원 멤버가 오류로 생성되었고 관련 팩트 레코드가 없는 경우를 제외하고는 차원 테이블과 삭제를 동기화해서는 안 됩니다.

원본 삭제를 처리하는 적절한 방법은 일시 삭제로 기록하는 것입니다. 일시 삭제는 차원 멤버를 더 이상 활성화되지 않음 또는 유효하지 않음으로 표시합니다. 이 사례를 지원하려면 차원 테이블에 IsDeleted와 같은 비트 데이터 형식을 갖는 부울 특성이 포함되어야 합니다. 삭제된 차원 멤버에 대해 이 열을 TRUE(1)로 업데이트합니다. 차원 멤버의 현재 최신 버전은 IsCurrent 또는 IsActive 열에 부울(비트) 값으로 유사하게 표시될 수 있습니다. 모든 보고 쿼리 및 Power BI 의미 체계 모델은 일시 삭제된 레코드를 필터링해야 합니다.

날짜 차원

캘린더 및 시간 차원은 일반적으로 원본 데이터가 없기 때문에 특수한 경우입니다. 대신 고정 논리를 사용하여 생성됩니다.

매년 초에 날짜 차원 테이블을 로드하여 행을 특정 연도까지 확장해야 합니다. 회계 연도 데이터, 휴일, 주 번호와 같은 정기적으로 업데이트할 다른 비즈니스 데이터가 있을 수 있습니다.

날짜 차원 테이블에 상대 오프셋 특성이 포함된 경우 ETL 프로세스를 매일 실행하여 현재 날짜(오늘)를 기준으로 오프셋 특성 값을 업데이트해야 합니다.

날짜 차원 테이블을 확장하거나 업데이트하는 논리는 T-SQL로 작성하고 저장 프로시저에 캡슐화하는 것이 좋습니다.

팩트 테이블 처리

팩트 테이블을 처리하려면 Data Warehouse 데이터를 원본 시스템 팩트와 동기화해야 합니다. 원본 데이터는 먼저 변환되어 해당 팩트 테이블에 로드할 준비가 됩니다. 그런 다음, 각 차원 키에 대해 조회를 통해 팩트 행에 저장할 서로게이트 키 값을 결정합니다. 차원이 SCD 유형 2를 지원하는 경우 차원 멤버의 현재 버전에 대한 서로게이트 키를 검색해야 합니다.

참고 항목

일반적으로 서로게이트 키는 YYYYMMDD 또는 HHMM 형식을 사용해야 하므로 날짜 및 시간 차원에 대해 계산할 수 있습니다. 자세한 내용은 캘린더 및 시간을 참조하세요.

차원 키 조회가 실패하면 원본 시스템에 무결성 문제가 있을 수 있습니다. 이 경우에도 팩트 행은 팩트 테이블에 삽입되어야 합니다. 유효한 차원 키도 계속 저장되어야 합니다. 한 가지 접근 방식으로 특수 차원 멤버(예: 알 수 없음)를 저장하는 방법이 있습니다. 이 접근 방식을 사용하려면 나중에 알려졌을 경우 실제 차원 키 값을 올바르게 할당하기 위해 업데이트가 필요합니다.

Important

Fabric 웨어하우스는 외세 키를 적용하지 않으므로 ETL 프로세스에서 데이터를 팩트 테이블에 로드할 때 무결성을 확인하는 것이 중요합니다.

자연 키가 유효하다는 확신이 있는 경우 적합한 또 다른 접근 방식은 새 차원 멤버를 삽입한 다음 서로게이트 키 값을 저장하는 것입니다. 자세한 내용은 이 섹션의 뒷부분에 있는 유추된 차원 멤버를 참조하세요.

다음 다이어그램에서는 팩트 테이블을 처리하는 데 사용되는 논리를 보여 줍니다.

다이어그램은 이전 단락에 설명한 대로 새 원본 행이 팩트 테이블에 로드되는 방법을 설명하는 흐름을 보여 줍니다.

가능하다면 팩트 테이블을 증분 방식으로 로드해야 합니다. 즉, 새 팩트가 감지되고 삽입됩니다. 증분 로드 전략은 확장성이 더 높으며 원본 시스템과 대상 시스템 모두에 대한 워크로드를 줄입니다.

Important

특히 대규모 팩트 테이블의 경우 팩트 테이블을 잘라내고 다시 로드하는 것은 최후의 수단이어야 합니다. 이러한 접근 방식은 프로세스 시간, 컴퓨팅 리소스, 원본 시스템의 중단 가능성 측면에서 비용이 많이 듭니다. 팩트 테이블 차원이 SCD 유형 2를 적용하는 경우에도 복잡성이 수반됩니다. 이는 차원 멤버 버전의 유효 기간 내에 차원 키 조회를 수행해야 하기 때문입니다.

원본 시스템 식별자 또는 타임스탬프를 사용하여 새 팩트를 효율적으로 감지할 수 있기를 바랍니다. 예를 들어 원본 시스템이 순서대로 판매 주문을 안정적으로 기록하는 경우 검색된 최신 판매 주문 번호(상위 워터마크라고 함)를 저장할 수 있습니다. 다음 프로세스에서는 해당 판매 주문 번호를 사용하여 새로 만든 판매 주문을 검색하고, 다음 프로세스에서 사용할 수 있도록 검색된 최신 판매 주문 번호를 저장할 수 있습니다. 생성 날짜 열을 사용하여 새 주문을 안정적으로 감지할 수도 있습니다.

원본 시스템 데이터를 사용하여 새 팩트를 효율적으로 감지할 수 없는 경우 원본 시스템의 기능을 사용하여 증분 로드를 수행할 수 있습니다. 예를 들어 SQL Server 및 Azure SQL Managed Instance에는 CDC(변경 데이터 캡처)라는 기능이 있으며, 이를 통해 테이블의 각 행에 대한 변경 내용을 추적할 수 있습니다. 또한 SQL Server, Azure SQL Managed Instance 및 Azure SQL Database에는 변경 내용 추적이라는 기능이 있으며, 이를 통해 변경된 행을 식별할 수 있습니다. 이 기능을 사용하도록 설정하면 데이터베이스 테이블에서 새 데이터 또는 변경된 데이터를 효율적으로 검색하는 데 도움이 될 수 있습니다. 삽입, 업데이트 또는 삭제된 테이블 레코드의 키를 저장하는 트리거를 관계형 테이블에 추가할 수도 있습니다.

마지막으로, 특성을 사용하여 원본 데이터와 팩트 테이블의 상관 관계를 지정할 수 있습니다. 예를 들어 판매 주문 번호와 판매 주문 줄 번호입니다. 그러나 대규모 팩트 테이블의 경우 새 팩트, 변경된 팩트 또는 삭제된 팩트를 검색하는 데 비용이 매우 많이 들 수 있습니다. 원본 시스템이 운영 데이터를 보관하는 경우에도 문제가 될 수 있습니다.

유추된 차원 멤버

팩트 로드 프로세스에서 새 차원 멤버를 삽입하면 이를 유추된 멤버라고 합니다. 예를 들어 호텔 게스트가 체크인할 때 호텔 체인의 로열티 회원으로 가입하라는 요청이 표시됩니다. 멤버십 번호는 즉시 발급되지만, 게스트가 서류를 제출할 때까지(있는 경우) 게스트의 세부 정보가 나오지 않을 수도 있습니다.

차원 멤버에 대해 알려진 것은 자연 키뿐입니다. 팩트 로드 프로세스는 알 수 없음 특성 값을 사용하여 새 차원 멤버를 만들어야 합니다. 중요한 점은 IsInferredMember 감사 특성을 TRUE로 설정해야 한다는 것입니다. 이렇게 하면 늦게 도착하는 세부 정보가 소싱되면 차원 로드 프로세스에서 차원 행에 필요한 업데이트를 수행할 수 있습니다. 자세한 내용은 이 문서의 기록 변경 사항 관리를 참조하세요.

팩트 업데이트 또는 삭제

팩트 데이터를 업데이트하거나 삭제해야 할 경우가 있을 수 있습니다. 예를 들어 판매 주문이 취소되거나 주문 수량이 변경되는 경우입니다. 팩트 테이블 로드에 대해 앞에서 설명한 대로, 변경 내용을 효율적으로 감지하고 팩트 데이터를 적절하게 수정해야 합니다. 취소된 주문에 대한 이 예시에서는 판매 주문 상태가 열림에서 취소됨으로 변경됩니다. 이러한 변경을 수행하려면 행을 삭제하는 것이 아니라 팩트 데이터를 업데이트해야 합니다. 수량 변경의 경우 팩트 행 수량 측정값을 업데이트해야 합니다. 일시 삭제를 사용하는 이 전략은 기록을 보존합니다. 일시 삭제는 행을 더 이상 활성화되지 않음 또는 유효하지 않음으로 표시하며 모든 보고 쿼리 및 Power BI 의미 체계 모델은 일시 삭제된 레코드를 필터링해야 합니다.

팩트 업데이트 또는 삭제가 예상되는 경우 팩트 테이블에 수정할 팩트 행을 식별하는 데 도움이 되는 특성(예: 판매 주문 번호 및 판매 주문 줄 번호)을 포함해야 합니다. 효율적인 수정 작업을 지원하려면 이러한 열을 인덱싱해야 합니다.

마지막으로, 특수 차원 멤버(예: 알 수 없음)를 사용하여 팩트 데이터를 삽입한 경우 이러한 팩트 행에 대한 현재 원본 데이터를 검색하고 차원 키를 유효한 값으로 업데이트하는 주기적인 프로세스를 실행해야 합니다.

관련 콘텐츠

Fabric 웨어하우스에 데이터를 로드하는 방법에 대한 자세한 내용은 다음을 참조하세요.