의미 체계 모델을 위한 별모양 스키마 디자인

완료됨

데이터가 의미 체계 모델로 흐르는 방식을 선택했습니다. 이제 명확하고 성능이 좋은 쿼리를 위해 스타 스키마를 설계하십시오. 별표 스키마는 관계를 통해 팩트 테이블을 차원 테이블에 연결하여 보고서 및 AI 사용량이 의존하는 필터 경로를 만듭니다. Power BI Desktop에서 별모양 스키마를 빌드하는 데 익숙한 경우 이 단원에서는 모델의 복잡성과 규모가 증가함에 따라 중요한 관계 디자인 결정에 중점을 둡니다.

의미 체계 모델의 별모양 스키마

별표 스키마에서 팩트 테이블은 측정 가능한 비즈니스 이벤트(예: 판매 트랜잭션, 주문 라인 및 웹 방문)를 저장하고 차원 테이블은 설명 컨텍스트(예: 제품 세부 정보, 고객 정보 및 날짜 특성)를 제공합니다. 차원 테이블은 관계를 통해 팩트 테이블을 필터링하므로 사용자가 설명이 포함된 특성별로 메트릭을 조각화할 수 있습니다.

가운데에 있는 팩트 테이블과 별 모양으로 구성된 관계로 연결된 여러 차원 테이블을 보여 주는 다이어그램

Fabric 의미 체계 모델에서 이 패턴은 보고서와 AI 사용 모두에 대해 클린 필터 전파를 제공합니다. Copilot 또는 데이터 에이전트가 자연어 쿼리를 생성하는 경우 잘 구성된 별 스키마는 AI에 올바른 데이터에 대한 명확한 경로를 제공합니다. 모호하거나 순환적인 관계는 보고서 소비자와 AI 도구를 모두 혼동합니다.

스토리지 모드가 관계에 미치는 영향

의미 체계 모델의 관계는 스토리지 모드에 따라 다르게 동작합니다. 이러한 차이점을 이해하는 것은 다양한 시나리오에서 잘 작동하는 스타 스키마를 디자인하는 데 필수적입니다.

Direct Lake 관계

Direct Lake 모드에서 엔진은 델타 테이블 메타데이터에서 직접 관계를 읽습니다. 관계는 다음 경우에 가장 잘 작동할 때는.

  • 차원 키 열의 카디널리티는 팩트 테이블의 행 수에 비해 낮습니다.
  • 참조 무결성은 원본 데이터에서 유지 관리됩니다. 참조 무결성이 유지되면 엔진은 LEFT OUTER 조인 대신 INNER 조인을 사용하여 쿼리 성능을 향상시킵니다.
  • 관계에 사용되는 열은 기본 델타 테이블에 인덱싱됩니다.

메모

쿼리에 모델이 메모리 제한을 초과하거나 지원되지 않는 작업을 사용하는 관계가 포함된 경우 Direct Lake는 DirectQuery로 돌아가고 관계 동작은 DirectQuery 의미 체계와 일치하도록 변경됩니다.

원본 간 관계

Fabric 의미 체계 모델은 서로 다른 데이터 저장소의 테이블을 연결할 수 있습니다. 레이크하우스의 팩트 테이블은 웨어하우스의 차원 테이블 또는 SQL 분석 엔드포인트를 통해 액세스되는 테이블과 관계를 가질 수 있습니다. 이러한 원본 간 연결은 복합 모델 기능을 사용합니다.

테이블이 서로 다른 원본에서 온 경우 각 테이블의 스토리지 모드는 쿼리 시 관계의 작동 방식을 결정합니다. 엔진은 각 측면을 독립적으로 확인하고 결과를 조인합니다.

관계 유형

일대다 관계

별 스키마에서 가장 흔한 관계 유형은 일 대 다입니다. 차원 테이블의 고유한 값 중 하나는 팩트 테이블의 여러 행과 관련이 있습니다. 예를 들어 Product 차원의 한 제품 행은 Sales 팩트 테이블의 수천 개의 주문 행과 일치합니다.

일대다 관계를 구성할 때, 필터 방향이 차원(즉, "일" 측면)에서 팩트 테이블(즉, "다" 측면)로 흐르도록 설정합니다. 표준 별표 스키마 필터 패턴입니다.

다대다 관계

두 테이블 모두 관계 열에 고유 값이 없는 경우 다대다 관계가 필요합니다. 브리지 테이블을 사용하여 이러한 관계를 해결합니다. 브리지 테이블은 두 테이블 사이에 있으며 각 쪽에서 키의 고유한 조합을 보유합니다.

예를 들어 고객이 여러 계정을 가질 수 있고 계정이 여러 고객에 속할 수 있는 경우 Customer-Account 브리지 테이블이 관계를 확인합니다. 브리지 테이블에는 고객 테이블과 계정 테이블 모두에 대한 일대다 관계가 있습니다.

필터 방향

별모양 스키마의 대다수 구현에서는 차원 테이블에서 팩트 테이블로 향하는 단방향 필터링 방식을 채택하고 있습니다. 이렇게 하면 예측 가능한 필터 전파가 제공되고 쿼리 결과의 모호성이 방지됩니다.

양방향 필터링은 차원 테이블의 값을 기반으로 팩트 테이블을 필터링하거나, 다 대 다 관계에서 상호 필터링이 필요할 때 사용됩니다. 양방향 필터는 쿼리 성능을 저하시키고 보고서에서 예기치 않은 필터 동작을 만들 수 있으므로 드물게 사용합니다.

참조 무결성

참조 무결성 가정 설정은 관계 간에 쿼리할 때 LEFT OUTER 조인이 아닌 INNER 조인을 사용하도록 엔진에 지시합니다. Direct Lake 및 DirectQuery 모드에서 이 설정은 엔진이 처리하는 행 수를 줄여 성능을 크게 향상시킬 수 있습니다.

팩트 테이블의 모든 외래 키 값에 차원 테이블에 일치하는 값이 있다고 확신하는 경우 이 설정을 사용하도록 설정합니다. 참조 무결성을 위반하면 일치하지 않는 키가 있는 행이 쿼리 결과에서 자동으로 사라집니다.

비활성 관계 및 USERELATIONSHIP

한 번에 두 테이블 사이에는 하나의 활성 관계만 존재할 수 있습니다. 여러 관계 경로(예: 주문 날짜 및 동일한 날짜 차원과 관련된 배송 날짜)가 필요한 경우 한 관계를 활성화하고 다른 관계는 비활성 상태로 만듭니다.

DAX의 함수를 USERELATIONSHIP 사용하여 계산 내에서 비활성 관계를 활성화합니다.

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

이 패턴은 동일한 데이터에 대한 여러 분석 관점을 지원하면서 모델을 깨끗하게 유지합니다.

의미 체계 모델에서 눈송이 스키마 처리

원본 데이터는 차원 테이블이 여러 관련 테이블로 분할되는 정규화된 눈송이 스키마에 도착하는 경우가 많습니다. 예를 들어 Product 차원은 각각 외장 키를 통해 연결된 Product, Subcategory 및 Category 테이블로 구분될 수 있습니다.

의미 체계 모델에는 눈송이를 별모양 스키마로 평면화하거나 정규화된 구조를 유지하는 두 가지 옵션이 있습니다.

별표 스키마로 평면화

평면화는 정규화된 차원 테이블을 비정규화된 단일 차원 테이블로 결합하는 것을 의미합니다. Product 테이블에는 하위 범주 및 범주 열이 직접 포함되어 추가 테이블과 관계를 제거합니다.

평면화 시기:

  • 결합된 차원 테이블은 팩트 테이블에 비해 상대적으로 작습니다(이는 차원 테이블의 경우 거의 항상 그렇습니다).
  • 차원에서 팩트로 이어지는 필터 경로를 더 단순화하기를 원합니다. 각 필터는 체인 대신 하나의 관계를 통해 이동합니다.
  • AI 사용이 우선 순위입니다. 테이블 수가 줄어들고 관계가 더 간단해지면 Copilot 데이터 에이전트가 올바른 데이터에 대한 경로를 더 명확하게 할 수 있습니다.

레이크하우스 또는 데이터 흐름에서 데이터를 준비하는 동안 데이터가 의미 체계 모델에 도달하기 전에 차원 테이블을 평면화합니다. 파워 쿼리 병합, SQL 조인 또는 Notebook 변환을 사용하여 정규화된 테이블을 단일 차원으로 결합합니다.

눈송이 구조 유지

경우에 따라 정규화된 구조를 유지하는 것이 좋습니다.

  • 차원 계층 구조에는 여러 수준이 있으며 평면화하면 수십 개의 중복 열이 생성됩니다.
  • 여러 팩트 테이블은 하위 하위 테이블(예: Sales 및 Inventory 팩트에서 사용되는 공유 범주 테이블)을 공유하며 비정규화는 일관성 없는 복사본을 만듭니다.
  • 행 수준 보안은 계층 구조의 특정 수준에서 적용해야 합니다.

눈송이 구조를 유지하는 경우 관계를 신중하게 구성합니다. 체인의 각 관계는 필터가 올바르게 전파되도록 가장 바깥쪽 테이블에서 팩트 테이블로의 단방향 필터링을 사용해야 합니다. 범주에 대한 필터는 하위 범주를 거쳐 제품을 통해 팩트 테이블로 전달되어야 합니다.

메모

대부분의 의미 체계 모델 시나리오에서 차원을 별모양 스키마로 평면화하는 것이 더 좋습니다. 테이블 수가 적으면 관계가 줄어들고 DAX가 더 간단하며 쿼리가 빨라지고 AI 사용량이 향상됩니다. 눈송이 구조를 유지할 강력한 이유가 있는 경우에만 눈송이 구조를 유지합니다.

원본 간 시나리오에 복합 모델을 사용하는 경우

별모양 스키마가 여러 Fabric 데이터 저장소에 걸쳐 있거나 외부 원본을 포함하는 경우 복합 모델을 사용합니다. 일반적인 시나리오는 다음과 같습니다.

  • 레이크하우스 내의 팩트 테이블과 창고에서 유지 관리되는 차원 테이블.
  • 레이크하우스의 기록 데이터와 결합된 이벤트하우스의 실시간 스트리밍 데이터입니다.
  • 외부 원본(가져오기)의 참조 데이터와 Fabric 네이티브 팩트 테이블(Direct Lake)의 결합입니다.

이러한 시나리오에서는 각 테이블에 대한 스토리지 모드를 독립적으로 구성하고 원본 간 관계가 예상 데이터 볼륨에서 허용 가능한 방식으로 수행되는지 확인합니다.