Power BI에서 스키마와 데이터 모델링

Source: Dev.to

데이터 모델링은 모든 성공적인 Power BI 솔루션의 건축적 기반입니다. 경영 대시보드를 만들든 복잡한 분석 엔진을 구축하든, 데이터의 구조적 완전성은 성능, 유연성 및 보고 정확성을 결정합니다.

스키마는 Star와 Snowflake라는 두 가지 주요 카테고리로 나뉘며, 이는 분석 및 BI에서 널리 사용되는 차원 모델링의 일반적인 관행을 따릅니다. 각각은 사실 테이블과 차원 테이블을 모델링하는 다른 방식을 정의하며, 단순성, 성능, 저장 효율성 및 모델링 유연성 사이의 균형을 맞춥니다. Star Schema는 읽기 성능을 쓰기 효율성보다 우선시하기 때문에 일반적으로 권장되는 접근 방식입니다.

스타 스키마

스타 스키마는 데이터를 여러 테이블로 구조화하는 것을 포함합니다:

• Fact 테이블은 측정하고자 하는 정량적 속성을 포함합니다.
• Dimension 테이블은 팩트 테이블의 데이터를 그룹화하고 분류하는 서술적 속성을 포함합니다.

팩트 테이블

팩트 테이블은 이벤트(거래)를 기록합니다. 동일한 유형의 이벤트가 여러 번 발생할 수 있기 때문에 중복은 정상이며, 차원 테이블에 비해 테이블이 자주 변경/업데이트됩니다.

-- Example fact table
FactTable_Visits (
    VisitID,
    PatientID,
    DoctorID,
    FacilityID,
    DateID,
    VisitCost,
    LengthOfStay
)

차원 테이블

차원 테이블은 팩트 테이블의 범주형 필드에 대한 정보를 보관하며 일반적으로 팩트 테이블보다 작습니다.

-- Example dimension tables
Dimension_Patient (PatientID, FullName, …)
Dimension_Doctor   (DoctorID,   FullName, …)
Dimension_Facility (FacilityID, Name,     …)
Dimension_Date     (DateID,     Date,     …)

관계 및 카디널리티

Power BI에서는 관계를 한 테이블의 열 하나와 다른 테이블의 열 하나를 매칭하여 구축하며, 각 차원 키를 팩트 테이블의 해당 키와 연결합니다. 예:

Patient[PatientID]   → FactVisits[PatientID]
Doctor[DoctorID]     → FactVisits[DoctorID]
Facility[FacilityID] → FactVisits[FacilityID]
Date[DateID]         → FactVisits[DateID]

고유성이 필드 조합(예: PatientID + DateID)에 의해 정의되는 경우, 결합 키를 생성합니다:

PatientDateKey = PatientID & "-" & DateID

그리고 해당 단일 열을 사용하여 테이블을 연결합니다.

카디널리티는 한 테이블의 행이 다른 테이블의 행과 몇 개 매치될 수 있는지를 설명합니다: 일대일, 일대다, 다대일, 다대다. 다대다 관계를 피할 수 없을 때는 브리지 테이블(연관 엔터티)을 사용하여 두 개의 일대다 관계로 변환합니다.

스노우플레이크 스키마

스노우플레이크 스키마는 차원 테이블을 여러 개의 관련 테이블로 정규화합니다. 스타 스키마처럼 모든 데이터를 하나의 큰 차원 테이블에 보관하는 대신, 설명 데이터를 더 작은 테이블로 분할하여 중복을 줄입니다. 차원들이 하위 차원으로 분기되어 층층이 구조를 이루기 때문에 “스노우플레이크”라고 부릅니다.

구조

• Fact Table(사실 테이블): 특정 Grain(세부 수준)에서 측정 가능한 이벤트/거래 데이터(수치 값)를 저장합니다.
• Dimension Tables(차원 테이블): 계층 구조를 나타내기 위해 여러 개의 연결된 테이블로 분할됩니다.

예시 (헬스케어):

• Patient → Ward → Department → Hospital
• Doctor → Specialty → Department

Fact Table: Visits

Dimension tables (정규화된 차원 테이블)

Patient   (PatientID, FullName, WardID)
Ward      (WardID, WardName, DepartmentID)
Department(DepartmentID, DepartmentName, HospitalID)
Hospital  (HospitalID, HospitalName)

Doctor    (DoctorID, FullName, SpecialtyID)
Specialty (SpecialtyID, SpecialtyName, DepartmentID)

관계

관계는 주로 일대다(one‑to‑many) 형태를 유지하지만, 차원은 여러 단계(예: Patient → Ward → Department → Hospital)를 통해 연결됩니다. 따라서 필터 경로가 스타 스키마보다 길어집니다.

좋은 데이터 모델링은 보고서의 효율성, 정확성 및 사용성을 직접 결정하기 때문에 매우 중요합니다. 명확한 관계와 중복 감소가 이루어진 잘 설계된 모델은 쿼리 성능을 향상시켜 데이터 규모가 커져도 대시보드 로드 속도를 빠르게 유지합니다. 데이터 무결성 제약을 적용하고 엔터티 간 논리적 연결을 정의하면 계산, 필터 및 집계가 시스템 전체에서 정확하게 유지되어 잘못된 인사이트를 초래할 수 있는 오류를 방지할 수 있습니다.